Global SAP Access and Operations Workplan v7-2017 ERP

IT Testing Area
Competence & Authority
System Level IT Risk Assessment Classification
Control Performer(s) & Title
Risk Arising from IT (RAIT) RAIT Risk Classification
Production systems, programs, and/or jobs result in

inaccurate, incomplete or unauthorized processing of data.
Users have access privileges beyond those necessary to
perform their assigned duties, which may create improper
segregation of duties.
Systems are not adequately configured or updated to restrict
system access to properly authorized and appropriate users.
SAP Access and Operation Workplan
If RAIT Risk Classification differs

from System Level IT Risk Control ID New Control ID
Classification, document Rationale
SAP001 SAP.15
SAP016 SAP.27
SAP002 SAP.16
SAP003 SAP.06
SAP005 SAP.07
SAP006 SAP.17
SAP007 SAP.18
SAP008 SAP.19
SAP010 SAP.01
SAP009a SAP.11
SAP011 SAP.02
SAP012 SAP.04
SAP013 SAP.03
SAP015 SAP.20
OPTIONAL
New
SAP.28
SAP004 SAP.09
SAP009 SAP.05
Evaluation of Competence and Authority
Risk Associated with

Control Description Test Approach Design Conclusion
Control
Only authorized users have access to update the batch jobs

(including interface jobs) in SAP.
IDOCS are monitored and identified issues are resolved timely.

Access to make changes to the IDOCs is granted appropriately
based on job responsibilities.
Critical jobs are monitored, and processing errors are corrected to

ensure successful completion.
Access to security administrative functions is authorized and

appropriately restricted.
Table update access is restricted based on specific business need.

Users with table edit transaction access are restricted to defined
tables based on job responsibilities.
Users are authorized to execute programs based on their job

responsibilities and restricted to specific programs required.
Access to all transaction codes is not granted to users.
Powerful profiles SAP_ALL and SAP_NEW are adequately

secured by ensuring no dialog or service user has access to these
profiles.
Remote access to SAP for software maintenance for the SAP

vendor is restricted, approved by management, and removed in a
timely manner. Access to the SAP Support IDs is appropriately
controlled when IDs are not in use.
Management approves the nature and extent of user-access
privileges for new and modified user access, including standard
application profiles/roles, critical financial reporting transactions,
and segregation of duties.
Access to change the password parameters is granted

appropriately based on job responsibilities.
Access for terminated and/or transferred users is removed or

modified in a timely manner.
Segregation of duties is monitored and conflicting access is either

removed or mapped to mitigating controls, which are documented
and tested.
User access is periodically reviewed.
Emergency access to SAP is permitted only with prior approval,

logged, monitored by someone other than users who administer
the access and removed in a timely manner.
Access granted to privileged-level shared and/or generic accounts

is appropriately secured, and passwords to such accounts are
modified on a periodic basis (such as when employees with
knowledge of the password leave the company).
The default passwords for standard SAP IDs have been changed
in all clients and secured appropriately. If access to one of these
powerful user accounts is required, the request is documented,
approved by management, and access is removed upon
completion of the request.
Access is authenticated through unique user IDs and passwords or

other methods as a mechanism for validating that users are
authorized to gain access to the system. Password parameters
meet company and/or industry standards (e.g., password minimum
length and complexity, expiration, account lockout).
Final Operating
Interim Operating Effectiveness Final Risk
Interim Risk Conclusion Effectiveness Deficiencies Noted?
Conclusion Conclusion
Conclusion
Control Activity SAP.01
Management approves the nature and extent of user-access privileges for new and modified user access, including standard application profiles/roles,
Description
critical financial reporting transactions, and segregation of duties.
Evaluation of Design Procedures Evaluation of Design Testing Results

Inquire with management to understand the process in which new access and modifications to access is requested and approved. Specifically, consider obtaining an understanding of the following attributes, as
appropriate:
• Policies and procedures related to user access provisioning;
• Individuals or groups responsible for approving access;
• Individuals or groups responsible for administering access;
• How user access requests are submitted, approved and documented;
• Whether a tool is used to provision new access and how that tool is controlled;
• Determine whether there is a segregation of duties between the approver and the person granting the access in the system
• Whether there is a different processes for access provisioning of non-employees (such as vendors, contractors, etc.) and if there are differences, understand what those differences are
• Whether segregation of duties is considered upon user provisioning (note this attribute maybe considered at control SAP.04 or SAP.04A SOD monitoring instead)
• Policies and procedures for changes to roles
Review evidence to corroborate the design of the control, such as approval documentation for a newly added user.
Note: If the client uses SAP GRC or similar tools for provision of access, consider testing, Admin access to the approval workflow, Security over the ID used to provision access, Approval hierarchy within the workflow,
Configuration settings for e.g. user cannot approve a role for themselves or once role is rejected it will not be provisioned to the user etc.
Inquire with management to understand the process in which new access and modifications to access is requested and approved. Specifically, consider obtaining an understanding of the following attributes, as
appropriate:
• Policies and procedures related to user access provisioning;
• Individuals or groups responsible for approving access;
• Individuals or groups responsible for administering access;
• How user access requests are submitted, approved and documented;
• Whether a tool is used to provision new access and how that tool is controlled;
• Determine whether there is a segregation of duties between the approver and the person granting the access in the system
• Whether there is a different processes for access provisioning of non-employees (such as vendors, contractors, etc.) and if there are differences, understand what those differences are
Review evidence to corroborate the design of the control, such as approval documentation for a newly added user.
Evidence used to corroborate the design of the control
Design Factor 1: Appropriateness of the Purpose of the Document considerations of the appropriateness of the purpose of the control and correlation to the IT risk identified.
Control and its Correlation to the Risk
Design Factor 2: Competence and Authority of the Person(s) Control Owner(s) - Document considerations of the appropriateness of authority and competence of the process owner(s) to perform the control, Refer to the Summary worksheet for the evaluation of the competence and authority for individuals or groups performing the control.
Performing the Control including consideration of segregation of duties (as applicable)
Design Factor 3: Frequency and Consistency with Which the Frequency of Control Operation
Control is Performed
Design Factor 4: Level of Aggregation and Predictability Document considerations of the appropriateness of the levels of aggregation and/or predictability given the risk addressed
Design Factor 5: Criteria for Investigation and Process for Document considerations of the appropriateness of the criteria used for investigation (i.e., threshold) and the process for follow-up
Follow-up
Evaluation of Design Conclusion
RAIT Risk Classification

Risk Associated with the Control
Basis for the conclusion on the risk associated with the
control
Test Approach
Dependency on Other Control(s) or Information Is the control dependent upon other controls or information?
Include a description of the IUC and identify the controls that address the accuracy and completeness of the IUC, where the IUC is tested and the
conclusions reached as a result of that testing. Consider source data, parameters and report logic.
Information used as Audit Evidence Is the information used as audit evidence to test the control?
Include a description of the IPE and details regarding how it was generated (i.e., who provided the IPE and the date it was generated). Describe
procedures performed to address completeness and accuracy. Consider source data, parameters and report logic.
Recommended Tools to obtain data ACTT

Tools used to obtain data
SAP.01 (SAP010) Page 13 of 87

Interim Operating Effectiveness Testing (This includes a test of implementation)
Identify the Population & Time Period of Coverage
Number & Description of Selections (Sample Size)
Test Procedure Number Operating Effectiveness Test Procedure (including Implementation) Operating Effectiveness Test Results (including Implementation)
1 a. Obtain the population of users created during the audit period by using transaction SUIM --> change document for users. Apply audit period as the
date range and check the selection box "User created". Alternatively, use ACTT Populations report rule "ITGC 112".
b. Obtain the population of users with roles assignment changes during the audit period (Ad Hoc Changes) by using transaction SUIM --> change
document for users. Apply audit period as the date range and check selection boxes "Roles" and "Profiles", and "User created". Download the report and
flag any role assignments that did not occur on the same date as user creation date because roles are usually assigned at the same time when users are
created and the population of new users is already covered in step a. Alternatively, use ACTT Populations report "ITGC 111 and 114"
2 Make a selection of new and modified users and test the following attributes:
• The user's access request was approved by appropriate management;

• Requested access is consistent with access granted in the system;
• Access granted is commensurate with the user's assigned duties and enforces appropriate segregation of duties
Note 1: When testing this attribute, it is important to consider the privileges within the role that a user has been granted.
Note 2: If there is an SOD monitoring control in place that covers this attribute, we may refer to that control rather than testing it within the provisioning
control.
• Segregation of duties is maintained between the approver and the person granting the access in the system.
Note: It is possible to determine if the user granted access to his/her own account by Using the ACTT Populations report rule "ITGC 112".
3 ROLES CHANGES
Note 1: If the ability to change roles is not granted to users in production as tested in control SAP.06, do not execute this step #3 as role changes will be
part of the change management process (tested in SAP.10).
Note 2: If there is a distinct process for role changes, perform the test steps below to ensure the changes are authorized through an established change
process. Note that role changes should typically not be performed directly in production.
Obtain a listing of changes made to roles during the testing period, select a sample of changed roles based on the sampling guidance based on
population and assess whether changes made were documented and properly approved.
Utilize ACTT Populations report, rule "ITCG 113 and ITGC 110" or
a. Execute SUIM - Change Documents - For Roles
i. Enter the appropriate date range
ii. Enter * in Change By Field
iii. Select All Change Documents Technical View -- Enter CD1251
4. Preventive SOD Check Note: If the client uses GRC for access provisioning and has preventive SOD check is configured, consider testing the below configuration parameters
within GRC. Configuration parameters are not tested via ACTT, engagement teams will have to generate these independently from the GRC system.
Assess whether an SOD check is performed prior to granting new user access or changing user access.
1. Setting for critical risks only
Execute Transaction SPRO-> GRC -> Access Control -> Maintain Configuration Settings or table GRACV_CONFIGSET:
Ascertain whether the value for parameter 1072: Mitigation of critical risk required before approving the request is set to 'YES' to ensure that new users
or changes with unmitigated SOD conflicts are not added to the system.
2. For all other risk types, SOD check requirement is configured within the workflow. Assess whether the automated SOD check has been implemented
through observation with the client of the error message when approving the user's access with unmitigated risks. Additionally, the configuration can be
reviewed (GRFNMW_CONFIGURE_WD --> Step 5: maintain paths->, last step in the path --> Task setting "Approve Despite Risk" - should be
unchecked).
Mitigating Procedures
Interim Operating Effectiveness Conclusion

Roll-Forward Testing
Test Procedure Number Roll-Forward Test Procedure Roll-Forward Testing Results
RF Basis Additional procedures required
RF Test Procedure 1 Inquire with the process owners and/or control owners on the following:
- The status of deficiencies identified at interim, including new or modified controls to respond to the deficiencies
- Significant changes to control performers, existing processes, or IT systems supporting the control.
RF IPE Procedures Identify and describe test procedures performed over IPE at RF.
RF Test Procedure 2
RF Mitigating Procedures If applicable, perform mitigating procedures for any deviations/deficiencies identified during RF testing or for open interim deficiencies.
Final Operating Effectiveness Conclusion
Evaluation of Deficiencies
Deficiencies noted:
Deficiency Description (if applicable)
Reference to evaluation of deficiencies over internal
control (e.g., form 2342(S))

Control Activity
Description
Evaluation of Design Procedures

Inquire with management to understand the controls related to removing access to the application for terminated users. Specifically, consider obtaining an u
attributes, as appropriate:
• Policies or procedures related to user provisioning;
• How IT Management is notified of terminated users;
• How access is removed or adjusted upon termination and if the same process is used for employees and non-employees (such as vendors, contractors, e
• Whether the process for removing access is manual or automated
• Whether a tool is used to de-provision access
• The method for removing access to the application (e.g., disabled or deleted);
• Who has responsibility for security administration and changing user access when terminations occur;
• What are the expectations for timely removal of user access (i.e., from date of separation to effective date of access modification).
Review evidence to corroborate the design of the control, such as evidence of a terminated employee notification and subsequent access removal.

Design Factor 1: Appropriateness of the Purpose of the Control
and its Correlation to the Risk
Design Factor 2: Competence and Authority of the Person(s)
Performing the Control
Design Factor 3: Frequency and Consistency with Which the
Design Factor 4: Level of Aggregation and Predictability
Design Factor 5: Criteria for Investigation and Process for

Follow-up

control
Test Approach
Dependency on Other Control(s) or Information
Information used as Audit Evidence
Recommended Tools to obtain data


Test Procedure Number

1
In lower risk IT environments, this procedure is not typically

performed if there is additional testing of the user access review
(SAP.03), as the review control would cover access for
transferred users
RF Basis
RF Test Procedure 1
RF IPE Procedures
RF Test Procedure 2
RF Mitigating Procedures
Deficiencies noted:
Reference to evaluation of deficiencies over internal control
(e.g., form 2342(S))
SAP.02
Access for terminated and/or transferred users is removed or modified in a timely manner.
ols related to removing access to the application for terminated users. Specifically, consider obtaining an understanding of the following
ng;
ers;
ation and if the same process is used for employees and non-employees (such as vendors, contractors, etc.);
nual or automated
on (e.g., disabled or deleted);

n and changing user access when terminations occur;
user access (i.e., from date of separation to effective date of access modification).
control, such as evidence of a terminated employee notification and subsequent access removal.
ntrol
Document considerations of the appropriateness of the purpose of the control and correlation to the IT risk identified.
Control Owner(s) - Document considerations of the appropriateness of authority and competence of the process owner(s) to
perform the control, including consideration of segregation of duties (as applicable)
Frequency of Control Operation
Document considerations of the appropriateness of the levels of aggregation and/or predictability given the risk addressed
Document considerations of the appropriateness of the criteria used for investigation (i.e., threshold) and the process for follow-
up
Is the control dependent upon other controls or information?
Include a description of the IUC and identify the controls that address the accuracy and completeness of the IUC, where the
IUC is tested and the conclusions reached as a result of that testing. Consider source data, parameters and report logic.
Is the information used as audit evidence to test the control?
Include a description of the IPE and details regarding how it was generated (i.e., who provided the IPE and the date it was
generated). Describe procedures performed to address completeness and accuracy. Consider source data, parameters and
report logic.
ACTT
includes a test of implementation)
Operating Effectiveness Test Procedure (including Implementation)

Obtain a listing of terminations for employees and contractors for the period of intended reliance from Human Resources.
Make a selection of users that were terminated. For each user selected, test the following attributes:
• Access privileges for the terminated user are no longer active in the system. Such access was removed, deleted or disabled
in a timely manner (based on the effective date of the termination).
Note 1: If a common key or field can be used to compare the termination listing to the listing of users, teams may consider
performing a 100% test of all terminated users.
Note 2: Where tools (such as Tivoli Identity Management or others) are utilized to automatically remove access upon
termination, teams may consider testing the termination control as an automated control. Additionally, if SAP authentication is
integrated with the network operating system, this procedure may be covered as part of testing at the OS layer (Active
Directory).
Note 3: Listing of active users can be obtained through table USR02 or SUIM report or from ACTT raw output tables USR02,
USR02CC, ADRP.
Obtain a listing of transfers for employees and contractors for the period of intended reliance from Human Resources. Make a
selection of users that were transferred or changed roles. For each user selected, test the following attributes:
• Access privileges that were no longer required, as a result of the employee transfer, were removed in a timely manner.
Note: Listing of active users and their associated roles can be obtained through tables USR02 and AGR_USERS or SUIM
report or from ACTT tables USR02, USR02CC, ADRP, AGR_USERS.
Roll-Forward Test Procedure

Additional procedures required
Inquire with the process owners and/or control owners on the following:
Identify and describe test procedures performed over IPE at RF.
If applicable, perform mitigating procedures for any deviations/deficiencies identified during RF testing or for open interim
deficiencies.
Evaluation of Design Testing Results
Refer to the Summary worksheet for the evaluation of the competence and authority for individuals or groups
performing the control.
Operating Effectiveness Test Results (including Implementation)

Roll-Forward Testing Results
Control Activity
Description
Note: In lower risk environments, we typically would identify preventative or detective access controls to address the IT risk. If we have tested t
preventative provisioning and termination controls that encompasses end-users (Controls 01 & 02) and such controls are operating effectively,
may not need to test the detective access review control.

Inquire with management to understand the process to review user access to the application. Specifically, consider obtaining an understanding of the follow
• Policies, procedures, standards, and guidance for access security for the application;
• Procedures and responsible individuals to review access for the application;
• Frequency of the access review;
• Scope of review (e.g., employees, vendors, contractors, guests and generic/system accounts) and what is considered to be an exception;
• Whether the review includes users AND their associated access roles, including role-based segregation of duties and privileged access
• What level of detail the review is performed at;
• How the review is documented ;
• Whether a tool is used in performing the access review and how that tool is controlled;
• Whether the review includes steps for ensuring requested changes to access are completed timely
Review evidence to corroborate the design of the control, such as evidence that shows a request for a review of access to responsible personnel.



Follow-up

control
Test Approach


1
RF Basis
RF Test Procedure 1
RF IPE Procedures
RF Test Procedure 2
Deficiencies noted:
(e.g., form 2342(S))
SAP.03
User access is periodically reviewed.
would identify preventative or detective access controls to address the IT risk. If we have tested the
trols that encompasses end-users (Controls 01 & 02) and such controls are operating effectively, then we
ew control.
ss to review user access to the application. Specifically, consider obtaining an understanding of the following
or access security for the application;

w access for the application;
ractors, guests and generic/system accounts) and what is considered to be an exception;

sociated access roles, including role-based segregation of duties and privileged access
review and how that tool is controlled;

equested changes to access are completed timely
control, such as evidence that shows a request for a review of access to responsible personnel.
ntrol
Document considerations of the appropriateness of the purpose of the control and correlation to
the IT risk identified.
Control Owner(s) - Document considerations of the appropriateness of authority and competence
of the process owner(s) to perform the control, including consideration of segregation of duties (as
applicable)
Document considerations of the appropriateness of the levels of aggregation and/or predictability

given the risk addressed
Document considerations of the appropriateness of the criteria used for investigation (i.e.,
threshold) and the process for follow-up
Include a description of the IUC and identify the controls that address the accuracy and
completeness of the IUC, where the IUC is tested and the conclusions reached as a result of that
testing. Consider source data, parameters and report logic.
Include a description of the IPE and details regarding how it was generated (i.e., who provided the
IPE and the date it was generated). Describe procedures performed to address completeness
and accuracy. Consider source data, parameters and report logic.
ACTT

Perform inquiries with management responsible for performing the user access review control and
obtain evidence that management sufficiently reviewed the information. This may include
reperformance and/or inspection of documentation to ascertain the following:
• User access review included a complete and accurate population of users;
• Review was properly documented and performed at the appropriate level of detail to ascertain
whether access was consistent with each user's current job responsibilities;
• Review was performed by appropriate management personnel with proper segregation of duties
enforced;
• System access was appropriately modified in a timely manner for users flagged as exceptions
during the review.

- The status of deficiencies identified at interim, including new or modified controls to respond to
the deficiencies
- Significant changes to control performers, existing processes, or IT systems supporting the
control.
If applicable, perform mitigating procedures for any deviations/deficiencies identified during RF

testing or for open interim deficiencies.

Control Activity
Description
Note: The relevance of this control depends on the functionality within SAP that the entity is utilizing and if there are any relevant SOD conflicts
on preventive role-based access to segregate access, as control SAP.01 may be sufficient to address end-user SOD for lower risk IT environmen
Note: IF SAP GRC V10 OR GREATER IS USED, REFER TO TAB SAP.04-GRC 10x (INSTEAD OF THIS TAB)

Inquire with management to understand the controls related to segregation of duties within the application. Specifically, consider obtaining an understanding
• Policies, procedures, standards, and guidance for the segregation of duties;
• Documented segregation of duties matrices that identify conflicting access combinations within the system that should not be granted;
• Adequacy of the matrix to identify if conflicts related to financial reporting are appropriately identified and if allowed, are mapped to mitigating controls, whi
• Whether a tool is used to monitor segregation of duties and how that tool is controlled;
• How management prevents or monitors segregation of duties conflicts, including the frequency of review, that are disallowed per the matrix or policy;
• Who is responsible for SOD monitoring activities and the performance of mitigating controls.
Review evidence to corroborate the design of the control, such as communications on the SOD monitoring control and examples of resolution of conflicts (i

Follow-up

control
Test Approach



1
(controls over IUC)
RF Basis
RF Test Procedure 1
RF IPE Procedures
RF Test Procedure 2
Deficiencies noted:
(e.g., form 2342(S))
SAP.04
Segregation of duties is monitored and conflicting access is either removed or mapped to mitigating controls, which are documented and tested.
n the functionality within SAP that the entity is utilizing and if there are any relevant SOD conflicts within system. Also consider whether the entity relies
access, as control SAP.01 may be sufficient to address end-user SOD for lower risk IT environments.
D, REFER TO TAB SAP.04-GRC 10x (INSTEAD OF THIS TAB)
ols related to segregation of duties within the application. Specifically, consider obtaining an understanding of the following attributes, as appropriate:
or the segregation of duties;
identify conflicting access combinations within the system that should not be granted;
ted to financial reporting are appropriately identified and if allowed, are mapped to mitigating controls, which are documented and performed by management;
duties and how that tool is controlled;
tion of duties conflicts, including the frequency of review, that are disallowed per the matrix or policy;
and the performance of mitigating controls.
control, such as communications on the SOD monitoring control and examples of resolution of conflicts (if applicable).
ntrol
Control Owner(s) - Document considerations of the appropriateness of authority and competence of the process owner(s) to perform the control,
including consideration of segregation of duties (as applicable)
Document considerations of the appropriateness of the criteria used for investigation (i.e., threshold) and the process for follow-up
ACTT

Obtain evidence of management's SOD matrix, ascertain whether it includes relevant conflicts, and evaluate if information in the matrix is consistent
with the system. Note that ACTT or query in SAP may be used for this purpose.
Note 1: IF SAP GRC10.x USED, REFER TO TAB SAP.04-GRC 10x.
Note 2: if a tool is used for performance of the control, assess relevant controls over the tool such as authentication, administrative access and change
management for the ruleset.
Make a selection of SOD reviews and obtain evidence that management sufficiently performed the control. This may include reperformance and/or
inspection of documentation to ascertain the following:
• The monitoring process was properly documented and performed at the appropriate level of detail to ascertain whether segregation of duties conflicts
exist;
• Monitoring was performed by appropriate management personnel;
• Corrective action was taken in a timely manner to resolve conflicts identified through the monitoring process;
• Management has documented, tested and determined the effectiveness of mitigating controls.

If applicable, perform mitigating procedures for any deviations/deficiencies identified during RF testing or for open interim deficiencies.
Include in inquiry and corroboration whether custom transactions are being used and included in the SOD analysis
Refer to the Summary worksheet for the evaluation of the competence and authority for individuals or groups performing the control.

Access is authenticated through unique user IDs and passwords or other methods as a mechanism for validating that users are authorized to gain
Description access to the system. Password parameters meet company and/or industry standards (e.g., password minimum length and complexity,
expiration, account lockout).

Inquire with management to understand the authentication controls (e.g. password minimum length, complexity, expiration and account lockout) relevant to the application. Specifically, consider
obtaining an understanding of the following attributes, as appropriate:
• Policies, procedures, standards, and guidance regarding authentication controls and password requirements;
• Where does authentication reside (e.g is there a separate application log in or is integrated with the operating system or enterprise portal);
• Whether a valid network account is required for a user to access the application log in screen;
• Whether the settings are enforced for all users (system-wide setting) or if the settings vary per user or user type (implementation of SECPOL);
• Design of the authentication controls for the application for all types of accounts defined on the system (e.g., end-user, system accounts, administrators);
• The specific settings that are enforced (length, complexity, password change, and account lockout) and the consistency of those settings with industry standards;
Review evidence to corroborate the design of the control, such as evidence that settings are enforced for an individual user or system-wide.

Design Factor 1: Appropriateness of the Purpose of Document considerations of the appropriateness of the purpose of the control and correlation to the IT risk identified.
the Control and its Correlation to the Risk
Design Factor 2: Competence and Authority of the Control Owner(s) - Document considerations of the appropriateness of authority and competence of the process owner(s) to perform the control, Refer to the Summary worksheet for the evaluation of the competence and authority for individuals or groups performing the
Person(s) Performing the Control including consideration of segregation of duties (as applicable) control.
Design Factor 3: Frequency and Consistency with Frequency of Control Operation
Which the Control is Performed
Design Factor 4: Level of Aggregation and Document considerations of the appropriateness of the levels of aggregation and/or predictability given the risk addressed
Predictability
Design Factor 5: Criteria for Investigation and Document considerations of the appropriateness of the criteria used for investigation (i.e., threshold) and the process for follow-up
Process for Follow-up

Basis for the conclusion on the risk associated
with the control
Test Approach



Note Where the password parameters are tested - may vary depending on which authentication method application is using. For example, if
Enterprise Portal is used password parameters should be tested for both at the portal and in the SAP system. Additionally, if Active directory or
Single Sign-On methodology is used, ensure that the testing approach is adjusted based on the design of the control.
Note: If the client uses Single Sign-On determine how SSO is configured, if users log into the SAP system using SNC then generate the output of
table USRACL to determine if can use SAP GUI for password logon.
1 Assess whether password settings are configured to a value consistent with company and/or professional policies and standards.
Identify active servers relevant to the assessment. Utilize ACTT SAP Basis Report or execute Transaction code SM51 or SE16N->Table
SAPWLSERV to identify active servers
b. Execute Transaction code SE16 or SE16N to extract table PAHI with filtering criteria on State (PARSTATE) with value "A" and Host Name
(Hostname) including active servers as identified in step a above.
For each of the parameters listed below, test for the following attributes:
• Password parameters are configured in accordance with the company policy.
• login/failed_user_auto_unlock (0)
• login/fails_to_user_lock (<=6)
• login/min_password_diff (>=1)
• login/min_password_digits (>=1)
• login/min_password_letters (>=1)
• login/min_password_lng (>=8)
• login/min_password_specials (1) (Optional; if required per company policy)
• login/password_expiration_time (<=90)
• login/password_history_size (>=12) only available in SAP NetWeaver 7.0
• rdisp/gui_auto_logout 1800 (Optional; this could be enforced by Active Directory)
• rsau/enable = 1 (Optional; if this is set to 1, SM20 audit log could be enabled for performing mitigating procedures)
2 SAP NetWeaver 7 Enhancement Pack 3 (SAP_BASIS 7.03) introduced a concept of making user-specific settings for password rules, password
changes, the password change requirement, and logon restrictions. If your client has implemented this functionality:.
Utilize ACTT SAP Basis Report or execute steps below:
A. Execute SE16N-> table SEC_POLICY_RT and identify if any security policies are configured.
B. To identify which security policies are assigned to which user, SE16N-> table USR02, see column "Security Policy" (SECURITY_POLICY).
C. If new policies exists per step A and are assigned to any users per step B, evaluate whether the parameters of security policy are appropriate.
RF Test Procedure 2
Deficiencies noted:
Reference to evaluation of deficiencies over
internal control (e.g., form 2342(S))

Description Access to security administrative functions is authorized and appropriately restricted.

Inquire with management to understand the controls related to security administration level access. Specifically, Include in inquiry and corroboration whether custom transactions are being used for this
consider obtaining an understanding of the following attributes, as appropriate: functionality that may need to be included in scope
• Policies related to information security and protecting privileged level access;
• Organizational structure of the security administration function;
• Description of user roles assigned privileged level access;
• Individuals with the authority to use privileged level access;
• Determine that individuals assigned privileged access does no have conflicting privileges which lead to a segregation
of duties conflict (i.e. security administrator privileges have no been granted to business users).
• Security access in SAP is restricted to users having access to the following:
- Create and Change Roles
- Assign roles/profiles to users
- User maintenance
• Whether Central User Administration (CUA) is used for administering access
Review evidence to corroborate the design of the control, such as reviewing one user that has been assigned privileged
access and determining the access is commensurate with the user's job responsibilities.

Design Factor 1: Appropriateness of the Purpose Document considerations of the appropriateness of the purpose of
of the Control and its Correlation to the Risk the control and correlation to the IT risk identified.
Design Factor 2: Competence and Authority of Control Owner(s) - Document considerations of the appropriateness Refer to the Summary worksheet for the evaluation of the competence and authority for
the Person(s) Performing the Control of authority and competence of the process owner(s) to perform the individuals or groups performing the control.
control, including consideration of segregation of duties (as
applicable)
Design Factor 3: Frequency and Consistency Frequency of Control Operation

with Which the Control is Performed
Design Factor 4: Level of Aggregation and Document considerations of the appropriateness of the levels of
Predictability aggregation and/or predictability given the risk addressed
Design Factor 5: Criteria for Investigation and Document considerations of the appropriateness of the criteria used
Process for Follow-up for investigation (i.e., threshold) and the process for follow-up
Dependency on Other Control(s) or Is the control dependent upon other controls or information?
Information
Include a description of the IUC and identify the controls that
address the accuracy and completeness of the IUC, where the IUC
is tested and the conclusions reached as a result of that testing.
Consider source data, parameters and report logic.
Include a description of the IPE and details regarding how it was

generated (i.e., who provided the IPE and the date it was
generated). Describe procedures performed to address
completeness and accuracy. Consider source data, parameters
and report logic.

with the control
Test Approach


Identify the Population & Time Period of
Coverage
Number & Description of Selections (Sample
Size)
Note If Central User Administration is used, refer to SAP.06_CUA Practice Aid for customized test steps 3, 4, 5, 6, 7.

1 Identify users who have SAP Security Administration access by using the ACTT SAP Basis Report, executing transaction SUIM => Users By Complex Selection Criteria (report RSUSR002) with the following authorizations.
For each account identified as having the access below, assess the following attributes:
• Access privileges are authorized and appropriate for user’s assigned duties based on inquiries with management (indicate the persons we inquired with)
• Access privileges are authorized and appropriate for user’s assigned duties based on inspection of their job function (include reference to corroborating source, such as an organizational chart)
a. Access to create roles:

Authorization object: S_TCODE
Transaction Code: PFCG
AND
i. Authorization object: S_USER_AGR
Field Values: 01 AND 02 AND 64
AND
ii. Auth. Object: S_USER_PRO
Field Values: 01
AND
( iii a. Auth. Object: S_USER_TCD
Field Values: *
OR
iii b. Auth. Object: S_USER_VAL
Field Values: * )
b. Access to create / maintain profiles that are created outside the Profile Generator via OVZ6 OR SU02:

Transaction Code: OVZ6 OR SU02
AND
Authorization object: S_USER_PRO
Activity: 01 OR 02 AND 03 AND 07
PROFILE: *
2 Access to modify roles:

AND
i. Auth. Object: S_USER_AGR
Field Values: 02 AND 64
AND
ii a. Auth. Object: S_USER_TCD
Field Values: *
OR
ii b. Auth. Object: S_USER_VAL
Field Values: *
3 Access to create and change user master records (not including role / profile assignments)
i. Authorization object: S_TCODE
Transaction Code: SU01 or SU01_NAV or SU10 or SU12 or OY27 or OY30 or OY28 or OY29 or OOUS or OTZ1 or OMDL or OMEH or OMWF or OPF0 or GCE1 (note some of these transactions could be locked,
which can be viewed in report RSAUDITC)
AND
ii. Authorization object: S_USER_GRP
Activity: 01 or 02
Note related to steps 4, 5, 6 Queries in steps 4, 5 and 6 depend upon the configuration values in the PRGN_CUST table described below. Depending on the results of steps below, queries in steps 4,5, and 6 are required to be customized.
Note: ACTT Basis report already includes this analysis, therefore, if using ACTT, procedures listed below are not required.
Execute SE16N and enter table PRGN_CUST and obtain the value of the parameters ASSIGN_ROLE_AUTH and CHECK_S_USER_SAS and identify the values of the parameters.
If any of the parameters do not exist or have the value "BLANK" in table PRGN_CUST, execute SE16N and enter table SSM_CIDT, execute (hit F8) using following filters and values:
1. Language: EN
2. Table Name: PRGN_CUST
3. Name: ASSIGN_ROLE_AUTH or CHECK_S_USER_SAS depending on which parameter does not exist or has the value "BLANK"
Based on field (TEXT), identify the default value for the parameters. Possible scenarios are listed below:
1. If default value of parameter ASSIGN_ROLE_AUTH is ASSIGN and if the parameter does not exist or has the value "BLANK" in table PRGN_CUST, the parameter value is inherently ASSIGN.
2. If default value of parameter ASSIGN_ROLE_AUTH is CHANGE and if the parameter does not exist or has the value "BLANK", the parameter value is inherently CHANGE.
3. If default value of parameter CHECK_S_USER_SAS is YES and if the parameter does not exist or has the value "BLANK" in table PRGN_CUST, the parameter value is inherently YES.
4. If default value of parameter CHECK_S_USER_SAS is NO and if the parameter does not exist or has the value "BLANK", the parameter value is inherently NO.

4 Access to assign roles to users
Transaction Code: SU01 or SU01_NAV or SU10 or SU12 or OY27 or OY30 or OY28 or OY29 or OOUS or OTZ1 or OMDL or OMEH or OMWF or OPF0 or GCE1
AND
Activity: 02
AND
iii Depending on if S_USER_SAS is YES or NO and if ASSIGN_ROLE_AUTH is CHANGE or ASSIGN:
[AA] If S_USER_SAS is YES
Authorization object: S_USER_SAS
Activity: 22
[BB] If S_USER_SAS is NO AND ASSIGN_ROLE_AUTH is ASSIGN

Authorization object: S_USER_AGR
Activity: 22
AND
Authorization object: S_USER_GRP
Activity: 22
AND
Activity: 22
[CC] If S_USER_SAS is NO AND ASSIGN_ROLE_AUTH is CHANGE

Activity: 02
AND
Activity: 22
AND
Activity: 22
5 Access to assign profiles to users

Transaction Code: SU01 or SU01_NAV or SU10 or SU12 or OY27 or OY30 or OY28 or OY29 or OOUS or OTZ1 or OMDL or OMEH or OMWF or OPF0 or GCE1 (note some of these transactions could be locked,
which can be viewed in report RSAUDITC)
AND
Activity: 02
AND
iii Depending on if S_USER_SAS is YES or NO:
[AA] If S_USER_SAS is YES
Activity: 22
[BB] If S_USER_SAS is NO,
Activity: 22
AND
Activity: 22

6 Access to assign roles to users via PFCG (Profile Generator Tcode):
i Authorization object: S_TCODE
AND
ii. Depending on if S_USER_SAS is YES or NO and if ASSIGN_ROLE_AUTH is CHANGE or ASSIGN:
[AA] If S_USER_SAS is YES"
Activity: 22
AND
Activity: 02 OR 03
[BB] If S_USER_SAS is NO AND ASSIGN_ROLE_AUTH is ASSIGN
Activity: 22
AND
Activity: 02 OR 03
AND
Activity: 22
AND
Activity: 22
[CC] If S_USER_SAS is NO AND ASSIGN_ROLE_AUTH is CHANGE
Activity: 02
AND
Activity: 22
AND
Activity: 22
7 Access to lock / unlock users, change passwords by executing transaction SUIM => Users By Complex Selection Criteria (report RSUSR002) with the following authorizations:
Transaction Code: SU01 or SU01_NAV or SU10 or SU12 or OY27 or OY30 or OY28 or OY29 or OOUS or OTZ1 or OMDL or OMEH or OMWF or OPF0 or GCE1 (note some of these transactions could be locked, which
can be viewed in report RSAUDITC)
AND
Auth. Object: S_USER_GRP
Field Values: 05
RF Test Procedure 1 Inquire with the process owners and/or control owners on the
following:
- The status of deficiencies identified at interim, including new or
modified controls to respond to the deficiencies
- Significant changes to control performers, existing processes, or
IT systems supporting the control.
RF Test Procedure 2
RF Mitigating Procedures If applicable, perform mitigating procedures for any
deviations/deficiencies identified during RF testing or for open
interim deficiencies.
Deficiencies noted:


Table update access is restricted based on specific business need. Users with table edit transaction access are restricted to defined tables
Description
Note: This control is not typically tested for lower risk environments, as a majority of the standard tables require the client to be open for changes which reduces the risk of
inappropriate table updates if such controls are operating effectively (refer to SAP.23). Consider table maintenance transaction codes specific to the entity in determining
the related dependencies and applicability of this control. This includes consideration of the following:
Automated controls: Each configured control will be dependent on the table in which configuration is stored. Configurations can either be stored in standard tables or
custom tables based on client implementation.
Data in System Generated Reports: A majority of transactions are based on source data held in tables. Data is either stored in standard tables or custom tables based on
client implementation.
BASIS Controls: SAP Basis controls may be reliant on table data. If the client is using the standard SAP transaction codes / process, none of the tables are modifiable in
current versions of SAP for GITCs reliant on table data.

Inquire with management and understand controls related to access to table maintenance access. Specifically, consider obtaining an understanding of the following attributes, as Include in inquiry and corroboration whether custom transactions are being used for this functionality that may need to be
appropriate: included in scope
• Policies related to information security and protecting privileged level access, specifically for table maintenance;
• Controls in place to ensure that access to all tables is not granted;
• If access to tables is required, controls in place to ensure that access is granted to only specific tables using authorization groups or table names and granted to users requiring such
access for job responsibilities.
Review evidence to corroborate the design of the control, such as reviewing one user that has been granted table maintenance access and determine whether the access is
commensurate with the user's job responsibilities.

Design Factor 1: Appropriateness of the Document considerations of the appropriateness of the purpose of the control and correlation to the IT risk identified.
Purpose of the Control and its
Correlation to the Risk
Design Factor 2: Competence and Control Owner(s) - Document considerations of the appropriateness of authority and competence of the process owner(s) to perform the Refer to the Summary worksheet for the evaluation of the competence and authority for individuals or groups performing the
Authority of the Person(s) Performing the control, including consideration of segregation of duties (as applicable) control.
Control
Design Factor 3: Frequency and Frequency of Control Operation
Consistency with Which the Control is
Performed
Design Factor 4: Level of Aggregation Document considerations of the appropriateness of the levels of aggregation and/or predictability given the risk addressed
and Predictability
Design Factor 5: Criteria for Document considerations of the appropriateness of the criteria used for investigation (i.e., threshold) and the process for follow-up
Investigation and Process for Follow-up
Dependency on Other Control(s) or Is the control dependent upon other controls or information?
Information
Include a description of the IUC and identify the controls that address the accuracy and completeness of the IUC, where the IUC is tested and
the conclusions reached as a result of that testing. Consider source data, parameters and report logic.

Include a description of the IPE and details regarding how it was generated (i.e., who provided the IPE and the date it was generated).
Describe procedures performed to address completeness and accuracy. Consider source data, parameters and report logic.
Basis for the conclusion on the risk

associated with the control
Test Approach
ACTT
Completeness and Accuracy of Information Produced by the Entity (IPE) used as audit evidence
Reference Number IPE Description IPE Test Procedures

Identify the Population & Time Period
of Coverage
Number & Description of Selections
(Sample Size)

1 Identify users with ability to update SAP standard or customized tables, by using ACTT SAP Basis Report or by executing transaction SUIM =>
Users By Complex Selection Criteria (report RSUSR002) with the following authorizations:
• Access privileges are authorized and appropriate for user’s assigned duties based on inquiries with management (indicate the persons we
inquired with)
• Access privileges are authorized and appropriate for user’s assigned duties based on inspection of their job function (include reference to
corroborating source, such as an organizational chart)
Note: Access to maintain all tables is typically inappropriate.
Users with access to ALL tables:

( Authorization object: S_TABU_DIS (Table Maintenance)
Activity: 02
Authorization Group (DICBERCLS): "*"
OR
Authorization object: S_TABU_NAM (Table Maintenance)
Activity: 02
Table Name (TABLE): "*" )
AND
Transactions Codes: SM30 or SM31
2 Users with Access to One or More tables:

(Authorization object: S_TABU_DIS (Table Maintenance)
Activity: 02
OR
Authorization object: S_TABU_NAM (Table Maintenance)
Activity: 02 )
AND
Transactions Codes: SM31 or SM30
NOTE: Note: Tables in SAP are typically assigned to authorization groups. While granting direct update access to tables is not recommended, the
engagement team could consider limiting the testing to particular critical tables / table authorization groups if the client has a process in place to
identify the critical tables / table authorization groups. For example, if the client's control consists of granting access to update particular
Finance-related tables to select Finance team members, the testing of specific tables / table authorization groups may be appropriate.
In order to identify what table authorization groups or tables if S_TABU_NAM is used are granted to users, utilize ACTT SOD Keystone report,
filtered view. Finally, use table "TDDAT" to identify the tables assigned to the table authorization groups.

RF Test Procedure 2
Deficiencies noted:
Reference to evaluation of
deficiencies over internal control (e.g.,
form 2342(S))

The default passwords for standard SAP IDs have been changed in all clients and secured appropriately. If access to one of
Description these powerful user accounts is required, the request is documented, approved by management, and access is removed upon
completion of the request.

Inquire with management and understand the controls related to the standard/default SAP IDs. Specifically, consider obtaining an understanding of the following attributes, as
appropriate:
• Policies related to information security and protecting privileged level access;
• Whether standard ID passwords have been changed from default;
• Process followed by Management to limit password knowledge to active default accounts. As part of this process, also understand Management's process for managing default
account passwords and the process for periodically changing these password & how the changed password is communicated to only those with a supported business case.
• If default IDs are used, understand the controls in place related to management of the accounts including documentation, approval and removal/password change upon completion of
the request.

Design Factor 1: Appropriateness of the Purpose of Document considerations of the appropriateness of the purpose of the control and correlation to the IT risk identified.
the Control and its Correlation to the Risk
Design Factor 2: Competence and Authority of the Control Owner(s) - Document considerations of the appropriateness of authority and competence of the process owner(s) to Refer to the Summary worksheet for the evaluation of the competence and authority for individuals or groups
Person(s) Performing the Control perform the control, including consideration of segregation of duties (as applicable) performing the control.
Predictability
Design Factor 5: Criteria for Investigation and Document considerations of the appropriateness of the criteria used for investigation (i.e., threshold) and the process for follow-
Process for Follow-up up
Include a description of the IUC and identify the controls that address the accuracy and completeness of the IUC, where the IUC
is tested and the conclusions reached as a result of that testing. Consider source data, parameters and report logic.
report logic.

with the control
Test Approach


1 Utilize ACTT SAP Basis Report or Execute the following:
a. Transaction Code: S_ALR_87101194 or SA38 to run report RSUSR003
b. Assess whether passwords had been changed from the default, and are not trivial for all clients on the production instance.
Review the following:
i. SAP*
ii. DDIC
iii. SAPCPIC
iv. EARLYWATCH
v. TMSADM (note, this ID will be displayed in RSUSR003 report only if note 1552894 is applied. To check whether this ID
exists otherwise and has the default password, use table USR02, or transaction SUIM)
2 (PRODUCTION CLIENT ONLY) If any of the default IDs mentioned above are user types ‘S’ (Service) or ‘A’ (Dialog), which
indicates they can be used to log into the system, identify whether IDs have been used during the audit period and obtain
evidence of approvals and supporting documentation.
Note: if client has a preventive or detective monitoring control over use these IDs, test client's control leveraging steps a-d
instead. User DDIC should either be set as type 'B' or Locked. DDIC is needed for certain tasks in installation and upgrade,
software logistics, and for the ABAP Dictionary.
Utilize ACTT SAP Basis Report or execute the following:

a. obtain the last logon information SE16N -> USR02 table
b. if the ID logged on during the audit period, obtain change history for ID (SUIM -> User Change Documents) and/or review
transaction logs such as SM20, ST03N, STAD to obtain population of usage of the IDs
c. select a sample of changes based on the sampling guidelines and obtain evidence of approval and supporting
documentation.
d. assess whether passwords were changed after use
3 (PRODUCTION CLIENT ONLY)

Assess whether SAP* ID is secured appropriately. Utilize ACTT SAP Basis Report or execute the following:
a. SE16N->Table PAHI, filter for active servers (which are identified in SAP.05) and active parameters. Inspect the current
value of login/no_automatic_user_sapstar and ensure it is set to 1.
b. OPTIONAL - ONLY IF SAP* IS DELETED

If SAP* is deleted in the production client, as tested in Step 1, obtain change log for login/no_automatic_user_sapstar for the
period (SE16N->Table PAHI, filter for active servers and dates for the audit period) and assessed whether the parameter was
set to "0" throughout the period, which indicates that SAP* could have been logged into with the standard password.

RF Test Procedure 2
RF Mitigating Procedures If applicable, perform mitigating procedures for any deviations/deficiencies identified during RF testing or for open interim
deficiencies.
Deficiencies noted:

Description Access to change the password parameters is granted appropriately based on job responsibilities.
Note: this control is not typically tested for lower risk environments considering passwords are tested in SAP.05 and changes to password parameters follow the change management process and would require system
restart for the configuration to take effect.

Inquire with management and understand controls related to access to change profile (password) parameters and access to modify and assign security policies (if applicable). Specifically, consider obtaining an understanding of the Include in inquiry and corroboration whether custom transactions are being used for this functionality that may
following attributes, as appropriate: need to be included in scope
• Policies related to information security and protecting privileged level access, specifically for changes to profile (password) parameters;
• Controls in place to related to granting access to change profile (password) parameters;
• Who should have access to change profile (password) parameters;
If per design of control SAP.05, individual security policies are assigned:

• Policies and procedures related to information security and protecting privileged level access, specifically for changes to security policies and security policies assignment;
• Who should have access to create or change security policies and assign policies to users.
Review evidence to corroborate the design of the control, such as reviewing one user that has been granted access and determine whether access is commensurate with the user's job responsibilities.

Design Factor 1: Appropriateness of the Purpose of the Control Document considerations of the appropriateness of the purpose of the control and correlation to the IT risk identified.
Design Factor 2: Competence and Authority of the Person(s) Control Owner(s) - Document considerations of the appropriateness of authority and competence of the process owner(s) to perform the control, including consideration of Refer to the Summary worksheet for the evaluation of the competence and authority for individuals or groups
Performing the Control segregation of duties (as applicable) performing the control.
Follow-up
Include a description of the IUC and identify the controls that address the accuracy and completeness of the IUC, where the IUC is tested and the conclusions reached as a
result of that testing. Consider source data, parameters and report logic.
Include a description of the IPE and details regarding how it was generated (i.e., who provided the IPE and the date it was generated). Describe procedures performed to
address completeness and accuracy. Consider source data, parameters and report logic.

control
Test Approach


SAP.11 (SAP009a) Page 47 of 87

1 Identify users with access to change profile (password) parameters by utilizing ACTT SAP Basis Report or execute transaction SUIM => Users By Complex Selection
Criteria (report RSUSR002) with the following authorizations:
• Access privileges are authorized and appropriate for user’s assigned duties based on inspection of their job function (include reference to corroborating source, such as an
organizational chart)
Authorization object: S_RZL_ADM

Activity: 01
AND
Authorization object: S_DATASET
Activity: 33 AND 34
Program: SAPLSPFL
AND
Transactions Codes: RZ10
2 TEST STEPS 2 AND 3 ONLY IF INDIVIDUAL SECURITY POLICIES HAVE BEEN IMPLEMENTED AS TESTED AT CONTROL SAP.05, STEP 2.
Assess whether access to Create/Maintain security policy is restricted appropriately by using ACTT SAP Basis Report or execute transaction SUIM => Users By Complex
Selection Criteria (report RSUSR002) with the following authorizations:
Transaction Code: SECPOL

AND
Authorization object: S_SECPOL
ACTVT: 03 AND 02 AND 01
AND
(Authorization object: S_TABU_DIS
Authorization group(DICBERCLS): SPOL
Activity: 02 AND 03
OR
Authorization object: S_TABU_NAM
TABLE: V_SEC_POLICY_CUS AND V_SEC_POLICY_RT
Activity: 02 AND 03)
AND
Authorization object: S_CTS_ADMI
CTS_ADMFCT: TABL
3 Assess whether access to Assign security policy to users is restricted appropriately by using ACTT SAP Basis Report or execute transaction SUIM => Users By Complex
Selection Criteria (report RSUSR002) with the following authorizations:
Transaction code: SU01 or SU01_NAV or SU10 or SU12 or OY27 or OY30 or OY28 or OY29 or OOUS or OTZ1 or OMDL or OMEH or OMWF or OPF0 or GCE1 (note
some of these transactions could be locked, which can be viewed in report RSAUDITC)
AND
Authorization Object: S_USER_GRP
ACTVT:02
AND
Authorization Object: S_SECPOL
ACTVT:22

RF Test Procedure 2
Deficiencies noted:
(e.g., form 2342(S))

Description Only authorized users have access to update the batch jobs (including interface jobs) in SAP.
Note: Consider if the entity is using SAP for scheduling relevant jobs or if other third party software is utilized when making a determination as to whether this control is applicable. Furthermore, this control is not typically tested for
lower risk environments (such as when there are a small number of financial related jobs, and the relevant interfaces are already addressed by direct controls).

Inquire with management to understand the controls related to access to job scheduling. Specifically, consider obtaining an understanding of the following attributes, as appropriate: Include in inquiry and corroboration whether custom transactions are being used for this functionality that may need to be included in scope
• Policies, procedures, standards, and guidance for the use of the job scheduler;
• Extent to which the job scheduler is used;
• Procedures for updating master schedule;
• Who should have access to the job scheduler;
• Whether tools outside SAP are used for job scheduling.
Review evidence to corroborate the design of the control, such as reviewing a user who has access to the job scheduling software and determine the access is commensurate with job responsibilities.

Design Factor 2: Competence and Authority of the Control Owner(s) - Document considerations of the appropriateness of authority and competence of the process owner(s) to perform the control, including consideration of segregation of duties Refer to the Summary worksheet for the evaluation of the competence and authority for individuals or groups performing the control.
Person(s) Performing the Control (as applicable)
Design Factor 3: Frequency and Consistency with Which Frequency of Control Operation
the Control is Performed
Follow-up

Basis for the conclusion on the risk associated with
the control
Test Approach
Include a description of the IUC and identify the controls that address the accuracy and completeness of the IUC, where the IUC is tested and the conclusions reached as a result of that
Include a description of the IPE and details regarding how it was generated (i.e., who provided the IPE and the date it was generated). Describe procedures performed to address
completeness and accuracy. Consider source data, parameters and report logic.


1 For each account identified as having the access below, assess the following attributes:
• Access privileges are authorized and appropriate for user’s assigned duties based on inspection of their job function (include reference to corroborating source, such as an organizational
chart)
Utilize ACTT SAP Basis Report or Execute transaction SUIM => Users By Complex Selection Criteria (report RSUSR002) with the following authorizations:
Note: If the client is on SAP Netweaver Release 7.4, and above, S_BTCH_ADM is a required object, query a and query c will not be relevant for testing the control.
Change Job Schedules under ONE OR MORE IDs

a.
T_CODE SM36
AND
S_BTCH_NAM BTCUNAME *
AND
S_BTCH_JOB JOBACTION RELE AND MODI
b.
T_CODE SM36
AND
AND
S_BTCH_ADM BTCADMIN Y

Change Job Schedules under ALL IDs
c.
T_CODE SM36
AND
S_BTCH_NAM BTCUNAME "*"
AND
d.
T_CODE SM36
AND
AND
2 For each account identified as having the access below, assess the following attributes:
• Access privileges are authorized and appropriate for user’s assigned duties based on inspection of their job function (include reference to corroborating source, such as an organizational
chart)
Utilize ACTT SAP Basis Report or Execute transaction SUIM => Users By Complex Selection Criteria (report RSUSR002) with the following authorizations:
Change Job Schedules under ONE OR MORE IDs

a.
S_TCODE SM37
AND
AND
b.
S_TCODE SM37
AND
AND
Change Job Schedules under ALL IDs
c.
S_TCODE SM37
AND
AND
d.
S_TCODE SM37
AND
AND
Note: in SAP Netweaver Release 7.4, additional values were introduced for S_BTCH_ADM object (such as A, B, C, P). If your client has updated security model to take advantage of the new
functionality, the test above may require further modification.
RF Test Procedure 2
Deficiencies noted:


Control Activity
Description
Note: Consider if the entity is using SAP for scheduling relevant jobs or if other third party software is utilized when making a determination as
applicable. Furthermore, this control is not typically tested for lower risk environments (such as when there are a small number of financial rela
interfaces are already addressed by direct controls).

Inquire with management to understand how critical systems, programs, and/or jobs are monitored, and processing errors are corrected to ensure successf
• Policies, standards, and guidance for job scheduling and monitoring;
• Restart and resolution procedures for failed jobs (including expectations for timeliness of resolution);
• The specific evidence retained to demonstrate resolution for failed jobs;
• Job scheduling and monitoring tools that are used;
• Frequency of review and criteria defined for investigation.
Review evidence to corroborate the design of the control, such as evidence of resolution of a recent job failure.


Follow-up

control
Test Approach



1
RF Basis
RF Test Procedure 1
RF IPE Procedures
RF Test Procedure 2
Deficiencies noted:
(e.g., form 2342(S))
SAP.16
Critical jobs are monitored, and processing errors are corrected to ensure successful completion.
cheduling relevant jobs or if other third party software is utilized when making a determination as to whether this control is
pically tested for lower risk environments (such as when there are a small number of financial related jobs, and the relevant
trols).
al systems, programs, and/or jobs are monitored, and processing errors are corrected to ensure successful completion. Specifically, consider
tes, as appropriate:
ling and monitoring;
(including expectations for timeliness of resolution);
esolution for failed jobs;
d;
stigation.
control, such as evidence of resolution of a recent job failure.
ntrol
Document considerations of the appropriateness of the criteria used for investigation (i.e., threshold) and the process for follow-
up
Include a description of the IUC and identify the controls that address the accuracy and completeness of the IUC, where the
IUC is tested and the conclusions reached as a result of that testing. Consider source data, parameters and report logic.
report logic.
ACTT

Obtain a system generated list of job statuses or failures. Based on the risk associated with the control and frequency of
changes, make a selection of job statuses or failures and test the following attributes:
Job Monitoring - Option 1: (This option applies when we make a sample of days and test the job status for those days)
• Job ran successfully without errors;
• In case of error, an alert was generated, appropriate personnel notified, and corrective action taken to resolve the error.
Job Monitoring - Option 2: (This option applies when we make a sample of tickets/cases from a population of job errors/abends)
• Corrective action was taken to resolve the error in a timely manner
Job Monitoring - Automated Control: (This test attribute may or may not be applicable, depending upon the client's
technologies. Likely need to combine with another test attribute that pertains to resolution of the error.)
• The system automatically creates a ticket and alerts management when a job fails/abends
For SAP, list of job abends can be generated through ACTT Populations Report or transaction SM37 (cancelled jobs) or Table
TBTCO. Note: Typically, the job logs are retained in the system for a short period of time. Additionally, 3rd party tools may
be used to schedule and monitor jobs and should be considered in this test.
OR
Based on the frequency and risk of management's job monitoring reviews, select a sample of reviews and obtain evidence to
test for the following attributes:
• The job monitoring information used in performance of the control was complete and accurate;
• The review was performed per the frequency required by management;
• The individuals performing the job monitoring control were appropriate based on their defined roles within the organization;
• The review was performed completely and evidence existed that demonstrated appropriate follow-up actions were taken.

deficiencies.

Users are authorized to execute programs based on their job responsibilities and restricted to specific programs. Access to all transaction codes is not granted
Description
to users.

Inquire with management and understand controls related to access to direct program execution and access to all transaction codes (S_TCODE *). Specifically, consider obtaining an understanding of the Include in inquiry and corroboration whether custom transactions are being used for this functionality that may
following attributes, as appropriate: need to be included in scope
• Policies related to information security and protecting privileged level access, specifically for program execution;
• Controls in place to ensure that access to execute all programs is not granted;
• If access to execute programs is required, controls in place to ensure that access is granted to only specific programs using authorization groups or program names and granted to users requiring such access for
job responsibilities;
• Whether any additional controls related to authority checks in the code of key custom programs have been implemented.
Review evidence to corroborate the design of the control, such as reviewing one user that has been granted program execution access and determine whether access is commensurate with the user's job
responsibilities.

Design Factor 1: Appropriateness of the Purpose Document considerations of the appropriateness of the purpose of the control and correlation to the IT risk identified.
of the Control and its Correlation to the Risk
Design Factor 2: Competence and Authority of the Control Owner(s) - Document considerations of the appropriateness of authority and competence of the process owner(s) to perform the control, including Refer to the Summary worksheet for the evaluation of the competence and authority for individuals or groups
Person(s) Performing the Control consideration of segregation of duties (as applicable) performing the control.
Predictability
Design Factor 5: Criteria for Investigation and Document considerations of the appropriateness of the criteria used for investigation (i.e., threshold) and the process for follow-up
Process for Follow-up

with the control
Test Approach
Include a description of the IUC and identify the controls that address the accuracy and completeness of the IUC, where the IUC is tested and the conclusions
reached as a result of that testing. Consider source data, parameters and report logic.
Include a description of the IPE and details regarding how it was generated (i.e., who provided the IPE and the date it was generated). Describe procedures
performed to address completeness and accuracy. Consider source data, parameters and report logic.


Identify the Population & Time Period of
Coverage
Number & Description of Selections (Sample
Size)

1 Identify users have the ability to execute programs by using ACTT SAP Basis Report or execute transaction SUIM => Users By Complex Selection Criteria
(report RSUSR002) with the following authorizations:
• Access privileges are authorized and appropriate for user’s assigned duties based on inspection of their job function (include reference to corroborating source,
such as an organizational chart)
Note that access to execute ALL programs is typically not appropriate.
a. Access to execute programs without authorization group or certain programs with authorization groups via SA38:
Authorization Object: S_PROGRAM
P_ACTION: SUBMIT or BTCSUBMIT
P_GROUP = *
Authorization Object: S_TCODE
Transaction Code: SA38
b. Access to execute ALL programs regardless the programs are assigned authorization groups or not via SA38:
P_GROUP = "*"
Transaction Code: SA38
Additional transactions that can be utilized to execute programs if used by the client:
c. Access to execute programs without authorization group or certain programs with authorization groups via EWFM OR EWFZ OR OODR:
P_GROUP = *
Transaction Code: EWFM OR EWFZ OR OODR
d. Access to execute ALL programs regardless the programs are assigned authorization groups or not via EWFM OR EWFZ OR OODR:
P_GROUP = "*"
Transaction Code: EWFM OR EWFZ OR OODR
e. Additional transactions that can be utilized to Execute Programs if used by the client:
Access to execute programs via START_REPORT OR TBC1 OR FA39

Transaction code: START_REPORT OR TBC1 OR FA39
Note related to Steps 2-5 Utilize ACTT SAP Basis Report or execute the following to determine which step is applicable for testing in client's environment.
Testing of access to execute programs with SE38 and SE80 will be customized if the client implemented SAP note 1596907.
SAP Note 1596907 was delivered in several SAP_BASIS support packages listed below.
Look up the matching release number for correct support package name.
To check the release number, System-> Status-> Component version.
Support Packages| Release| Package Name
SAP_BASIS| 46C| SAPKB46C63
SAP_BASIS| 620| SAPKB62071

2 IF NOTE IS APPLIED AND WHEN PROGRAMS ARE NOT ASSIGNED AUTHORIZATION GROUPS:
a. Access to execute certain programs without authorization groups via SE38 or SE80:
Authorization Object: S_DEVELOP
ACTVT= 16 and 03
OBJTYPE=PROG
OBJNAME = *
DEVCLASS = *
Transaction Code: SE38 OR SE80
b.Access to execute “ALL” programs without authorization groups via SE38 or SE80:
ACTVT = 16 and 03
OBJTYPE =PROG
OBJNAME = “*”
DEVCLASS = "*"
3 IF NOTE IS APPLIED AND WHEN PROGRAMS ARE ASSIGNED AUTHORIZATION GROUPS:

a. Access to execute certain programs with assigned authorization groups via SE38 or SE80:
ACTVT = 16 and 03
OBJTYPE = PROG
OBJNAME = *
P_GROUP = *
DEVCLASS = *
AND
Activity Value: SUBMIT
P_GROUP = *
b. Access to execute “ALL” programs with assigned authorization groups via SE38 or SE80:
ACTVT = 16 and 03
OBJTYPE = PROG
OBJNAME = “*”
P_GROUP = “*”
DEVCLASS = “*”
AND
Activity Value: SUBMIT
P_GROUP = “*”

Additional transactions that could also be utilized to execute programs if used by the client:
c. Access to execute certain programs with assigned authorization groups via SAT:
Transaction Code: SAT
ACTVT = 16 and 03
OBJTYPE = PROG AND SYST
OBJNAME = *
P_GROUP = *
DEVCLASS = *

d. Access to execute “ALL” programs with assigned authorization groups via SAT:
Transaction Code: SAT
ACTVT = 16 and 03
OBJTYPE = PROG AND SYST
OBJNAME = “*”
P_GROUP = “*”
DEVCLASS = “*”
4 IF NOTE IS NOT APPLIED AND WHEN PROGRAMS ARE NOT ASSIGNED AUTHORIZATION GROUPS:
- N/A for certain program access, as authorization check will not be performed by SAP, users are allowed to execute ALL programs not assigned authorization
groups.
- Access to execute programs without auth groups:

AND
ACTVT = 03
OBJTYPE = PROG
5 IF NOTE IS NOT APPLIED AND WHEN PROGRAMS ARE ASSIGNED AUTHORIZATION GROUPS:
a. Access to execute certain programs with assigned authorization groups via SE38 or SE80:
ACTVT = 03
OBJTYPE = PROG
AND
AND
P_ACTION: SUBMIT
P_GROUP = *
b. Access to execute "ALL" programs with assigned authorization groups via SE38 or SE80:
ACTVT = 03
OBJTYPE = PROG
AND
AND
P_ACTION: SUBMIT
P_GROUP = "*"

NOTE: Note: In SAP, programs are typically assigned to authorization groups. While granting direct program execute access is not recommended, the engagement
team could consider limiting the testing to certain critical programs / program authorization groups if the client has a process in place to identify critical
programs / program authorization groups. For example, if the client's control consists of granting access to execute particular Finance programs to select
Finance team members, the testing of this control may be appropriate.
In order to identify what program authorization groups are granted to users, utilize ACTT SOD Keystone report, filtered view. Use system table "TRDIR" to
identify the programs assigned to the program authorization groups.
6 Identify users with access to all transactions by utilizing ACTT SAP Basis Report or executing transaction SUIM => Users By Complex Selection Criteria (report
RSUSR002) with the following authorizations:
a. Populate “*” in S_TCODE. (Access to all SAP transaction codes) . Execute.
Note: S_TCODE * standing access should not be granted to dialog and service users.
RF Test Procedure 2
Deficiencies noted:

Powerful profiles SAP_ALL and SAP_NEW are adequately secured by ensuring no dialog or service user has
Description
access to these profiles.

Inquire with management and understand the controls related to the standard profiles SAP_ALL and SAP_NEW. Specifically, consider obtaining an understanding of the following
• Policies related to information security and protecting privileged level access including standard profiles SAP_ALL and SAP_NEW and access to all transactions to ensure this
access is not granted to dialog and service accounts;
• Whether this access is granted to any dialog or service accounts which can be used to log into the system;
• If any custom SAP_ALL profiles are created (e.g. Z_SAP_ALL)
• Controls related to assignment of SAP_ALL/SAP_NEW access if required for emergency purposes, including documentation, authorization, monitoring and access removal.
Review evidence to corroborate the design of the control, such as reviewing users granted access to SAP_ALL/SAP_NEW.

Design Factor 1: Appropriateness of the Purpose of the Control Document considerations of the appropriateness of the purpose of the control and correlation to the IT risk
and its Correlation to the Risk identified.
Design Factor 2: Competence and Authority of the Person(s) Control Owner(s) - Document considerations of the appropriateness of authority and competence of the Refer to the Summary worksheet for the evaluation of the competence and authority for individuals or groups
Performing the Control process owner(s) to perform the control, including consideration of segregation of duties (as applicable) performing the control.
Design Factor 4: Level of Aggregation and Predictability Document considerations of the appropriateness of the levels of aggregation and/or predictability given the risk
addressed
Design Factor 5: Criteria for Investigation and Process for Follow- Document considerations of the appropriateness of the criteria used for investigation (i.e., threshold) and the
up process for follow-up

control
Test Approach
Include a description of the IUC and identify the controls that address the accuracy and completeness of the
IUC, where the IUC is tested and the conclusions reached as a result of that testing. Consider source data,
parameters and report logic.
Include a description of the IPE and details regarding how it was generated (i.e., who provided the IPE and the
date it was generated). Describe procedures performed to address completeness and accuracy. Consider
source data, parameters and report logic.


1 a. Current Profile Assignment - Identify dialog and service users assigned to profiles SAP_ALL and
SAP_NEW by utilizing ACTT SAP Basis Report or executing transaction SUIM => Users By Complex
Selection Criteria (report RSUSR002) with the following authorizations.
In the portion of the screen noted as “Profile name”, click on the yellow arrow icon and enter the following:
i. SAP_ALL
ii. SAP_NEW
Note: a custom SAP_ALL profile (e.g. Z_SAP_ALL can be created with similar authorities and should also be
considered in testing of this control.)
2 Profile Assignment history - Obtain change history for profile assignments and assess whether SAP_ALL
and/or SAP_NEW have been assigned to any users during the testing period. If any occurrences are found,
In lower risk IT environments, this procedure is not typically test whether change has been authorized by management, documented, monitored and access was removed
performed if there is additional testing of the user provisioning once no longer required.
(SAP.01), as the provisioning control would cover users assigned
SAP_ALL and SAP_NEW.
NOTE NOTE: Standing Access with profile SAP_ALL and SAP_NEW should not be granted to dialog (User type: 'A')
or service users (User Type: 'S'). If granted, access should be authorized for a short period of time, logged
and monitored and removed once no longer required. If service accounts have dialog access due to system
requirements, determine if the elevated SAP_ALL/SAP_NEW profile is necessary for the service account and if
the password to the service account is appropriately controlled.
If client has a monitoring control over this access, test the monitoring control leveraging testing steps above for
IUC evaluation.
- The status of deficiencies identified at interim, including new or modified controls to respond to the
deficiencies
RF Test Procedure 2
RF Mitigating Procedures If applicable, perform mitigating procedures for any deviations/deficiencies identified during RF testing or for
open interim deficiencies.
Deficiencies noted:
(e.g., form 2342(S))

Remote access to SAP for software maintenance for the SAP vendor is restricted, approved by management, and removed in a timely manner.
Description
Access to the SAP Support IDs is appropriately controlled when IDs are not in use.
Note: Consider remote access to SAP software maintenance specific to the entity in determining the related risk and applicability of this control. This includes consideration of the following:
- Are support IDs are only used for external purpose or internal support purpose?
- Do support IDs have SAP_ALL?
- Are users locked after usage and passwords are secured for such users / users are only provided with display only access is production?

Inquire with management and understand the controls related to remote access granted to the SAP for software maintenance (SAP Technical Support such as OSS* user accounts). Specifically, consider
• Policies related to SAP vendor's access to SAP;
• Procedures for granting vendor's access, including approvals, documentation, level of access and removal of access once no longer required;
• Understand the IDs used for vendor's access;
• Consider procedures for opening the port and RFC connection for the SAP vendor;
• Other generic vendor accounts for providing vendor's access to the system.
Review evidence to corroborate the design of the control, such as reviewing one instance of use of SAP vendor support accounts and determine whether access is commensurate with the user's job
responsibilities.

Design Factor 2: Competence and Authority of the Control Owner(s) - Document considerations of the appropriateness of authority and competence of the process owner(s) to perform the control, Refer to the Summary worksheet for the evaluation of the competence and authority for individuals or groups
Person(s) Performing the Control including consideration of segregation of duties (as applicable) performing the control.
Design Factor 3: Frequency and Consistency with Which Frequency of Control Operation
Follow-up

control
Test Approach


1 Determine if any remote access for Generic Vendor accounts (SAP Technical Support) was granted within the testing period and verify correct
process was followed as outlined in client's policy.
a. Obtain change history for the IDs used as Generic Vendor accounts (i.e., naming conventions used for Generic Vendor accounts and
passwords are activated when SAP Consultants are needed...the accounts may be named as "OSS*", *SAPSUPPORT* or others).
b. For the testing period, select a sample of instances of Generic Vendor accounts activations based on sampling guidance. (Obtain SAP
SUPPORT ID activations through SUIM -> Change Documents -> User -> "ID" Dates: Testing period).
c. Obtain and assess management's approval and supporting documentation.
d. Ascertain that the password to user accounts associated with Generic Vendor accounts (e.g. Technical Support or other) are reset in a timely
manner after the fix is completed per client's policy.
NOTE Note 1: Other generic vendor accounts could be used in addition to OSS* or SAPSUPPORT*. Inquire management to understand whether
additional generic vendor accounts are used and include in testing above if these accounts are not already covered in other controls.
RF Test Procedure 2
Deficiencies noted:

Control Activity
Description
Note: IF SAP GRC V10 OR GREATER IS USED, REFER TO TAB SAP.20 GRC 10.x (INSTEAD OF THIS TAB)

Inquire with management to understand the controls over Emergency Access. Specifically, consider obtaining an understanding of the following attributes, a
appropriate:
• Policies, procedures, standards, and guidance for emergency access to the application;
• Whether a tool is used for managing emergency access and how that tool is controlled;
• What IDs or roles are used for emergency access;
• Individuals responsible to use, approve and/or review emergency access including SOD between these responsibilities;
• Frequency of use of emergency access;
• Procedures related to granting, removing and/or monitoring of emergency access
• If use of emergency access is monitored, what level of detail the review is performed at and how the review is documented;
• Whether the review includes steps for follow-up in case discrepancies are identified;
• Frequency and timing of the reviews.
Review evidence to corroborate the design of the control, such as evidence that shows an instance of use of emergency access.



Follow-up

control
Test Approach

1. SOD
2. Admin Access (control over IUC)
3. Emergency Access Monitoring
4. Configuration (control over IUC)
RF Basis
RF Test Procedure 1
RF IPE Procedures
RF Test Procedure 2
Deficiencies noted:
(e.g., form 2342(S))
SAP.20
Emergency access to SAP is permitted only with prior approval, logged, monitored by someone
other than users who administer the access and removed in a timely manner.
, REFER TO TAB SAP.20 GRC 10.x (INSTEAD OF THIS TAB)
ols over Emergency Access. Specifically, consider obtaining an understanding of the following attributes, as
or emergency access to the application;

access and how that tool is controlled;
s;
eview emergency access including SOD between these responsibilities;
monitoring of emergency access

evel of detail the review is performed at and how the review is documented;
n case discrepancies are identified;
control, such as evidence that shows an instance of use of emergency access.
ntrol
Document considerations of the appropriateness of the purpose of the control and correlation to
the IT risk identified.
Control Owner(s) - Document considerations of the appropriateness of authority and competence
of the process owner(s) to perform the control, including consideration of segregation of duties (as
applicable)
Document considerations of the appropriateness of the levels of aggregation and/or predictability

given the risk addressed
Document considerations of the appropriateness of the criteria used for investigation (i.e.,
threshold) and the process for follow-up
Include a description of the IUC and identify the controls that address the accuracy and
completeness of the IUC, where the IUC is tested and the conclusions reached as a result of that
Include a description of the IPE and details regarding how it was generated (i.e., who provided the
IPE and the date it was generated). Describe procedures performed to address completeness
and accuracy. Consider source data, parameters and report logic.

Assess whether appropriate segregation of duties exists between the administrators of the
emergency IDs, users of emergency IDs, and reviewers (controllers) of the activity of the
emergency IDs so that a user does not use an emergency ID, then review their own activity.
Assess whether access to administer emergency access or firefighters is appropriate; note this
maybe already covered by control SAP.06.
Obtain change history for the IDs used as emergency user accounts or firefighter activity logs and
select a sample of instances of emergency user activations based on sampling guidance.
Perform inquiries with management responsible for performing the review of activities performed
by emergency IDs and obtain evidence that management sufficiently reviewed the information.
This may include performance and/or inspection of documentation to ascertain the following:
• Review included a complete and accurate population of activities performed by emergency
users;
• Review was properly documented and performed at the appropriate level of detail to ascertain
whether activities were consistent with each request of usage of emergency user;
• Review was performed by appropriate management personnel with proper segregation of duties
enforced;
• Appropriate follow up were made for exceptions noted during the reviews and remediated on a
timely basis
Note: If emergency roles are assigned to users, obtain change history for emergency roles
assignments assess whether roles have been assigned to any users during the testing period.
If the emergency access is assigned using an automated tool, obtain the configuration or change
history of configurations to assess whether configurations are set up correctly or have not been
inappropriately changed for the audit year.

- The status of deficiencies identified at interim, including new or modified controls to respond to
the deficiencies
- Significant changes to control performers, existing processes, or IT systems supporting the
control.
If applicable, perform mitigating procedures for any deviations/deficiencies identified during RF

testing or for open interim deficiencies.

Control Activity
Description
Note: Consider if the entity is using IDOCS (and if IDOCS may be covered in SAP.16) when making a determination as to whether this control is
is not typically tested for lower risk environments (such as when there are a small number of financial related jobs, and the relevant interfaces a
controls).

Inquire with management to understand the controls related to IDOCs. Specifically, consider obtaining an understanding of the following attributes, as appro
• Policies, procedures, standards, and guidance related to IDOCS management;
• Extent to which the IDOCs are used for ICFR and if a listing of critical IDOC types is maintained;
• Procedures creating, editing, processing and monitoring IDOCs for successful postings;
• Who should have access to manage IDOCS;
• Whether tools outside SAP are used for IDOCS monitoring and tracking;
• Key error message types that require monitoring and resolution if failed.
Review evidence to corroborate the design of the control, such as reviewing a user who has access to IDOCS and determine the access is commensurate
error and how it was resolved.


Follow-up

control
Test Approach


1
RF Basis
RF Test Procedure 1
RF IPE Procedures
RF Test Procedure 2
Deficiencies noted:
(e.g., form 2342(S))
SAP.27
IDOCS are monitored and identified issues are resolved timely. Access to make changes to the IDOCs is granted appropriately
nd if IDOCS may be covered in SAP.16) when making a determination as to whether this control is applicable. Furthermore, this control
nts (such as when there are a small number of financial related jobs, and the relevant interfaces are already addressed by direct
ols related to IDOCs. Specifically, consider obtaining an understanding of the following attributes, as appropriate:
elated to IDOCS management;
d if a listing of critical IDOC types is maintained;
nitoring IDOCs for successful postings;
monitoring and tracking;

and resolution if failed.
control, such as reviewing a user who has access to IDOCS and determine the access is commensurate with job responsibilities and IDOC in
ntrol
Include a description of the IUC and identify the controls that address the accuracy and completeness of the IUC, where the IUC
is tested and the conclusions reached as a result of that testing. Consider source data, parameters and report logic.
report logic.
ACTT

Identify a population of failed IDOCS through IDOC history of Table "EDIDS" through transaction SE16/SE16N; filter on the field
"Status" with value: 51. Additional error types could be relevant, review error codes listing as noted in the table TEDS2.
Select a sample of IDOCS with errors and obtain evidence that the failure was identified and resolved appropriately.
Message Type and Basic Type of IDOCs should be considered for scoping purposes. Message Type and Basic Type describe
the nature and content of the IDOC document. For example, Message Type "FI*" stands for entire FI document (i.e., accounting
documents); Message Type "INVOIC* stands for "Invoice/Billing document". The list of Message Types and Basic Types can be
found in tables EDMSG and EDBAS. For the IDOC population, Table EDIDC lists the current status of IDOCs and the Message
Types and Basic Types information, whereas table EDIDS lists the change history of IDOCs.
Identify users with access to maintain IDOCS by utilizing ACTT SAP Basis Report or execute transaction SUIM => Users By
Complex Selection Criteria (report RSUSR002) with the following authorizations:
• Access privileges are authorized and appropriate for user’s assigned duties based on inquiries with management (indicate the
persons we inquired with)
• Access privileges are authorized and appropriate for user’s assigned duties based on inspection of their job function (include
reference to corroborating source, such as an organizational chart)
a. Access to create a copy of an existing IDOC and edit and process the copy of the IDOC:
Transaction Code: WE19
AND
Authorization Object: S_IDOCCTRL
Transaction Code (EDI_TCD): WE19
Activity: 16
AND
Authorization Object: S_IDOCMONI
Transaction Code (EDI_TCD): WE19
Activity: 02 AND 03
b. Edit and process IDOCs

Transaction Code: BD87
AND
Authorization Object: S_IDOCMONI
Activity: 02 AND 03
Transaction (EDI_TCD): WE02

deficiencies.
Include in inquiry and corroboration whether custom transactions are being used for this functionality that may
need to be included in scope
Note: Users Would need additional underlining access

This Control is Optional
Control Activity
Description

Inquire with management and understand the controls related to access granted to privileged-level shared and/or generic accounts to the SAP . Specifically
following attributes, as appropriate:
• Policies and procedures round the purpose of generic IDs and how they are used
• Users with access to the generic IDs
• Procedures for managing, communicating, storing and changing the passwords of the IDs
• Monitoring usage of the IDs
Review evidence to corroborate the design of the control, such as procedures related to generic ID monitoring

Design Factor 1: Appropriateness of the Purpose of the
Design Factor 2: Competence and Authority of the
Person(s) Performing the Control
Design Factor 3: Frequency and Consistency with Which

Follow-up

control
Test Approach



1
RF Basis
RF Test Procedure 1
RF IPE Procedures
RF Test Procedure 2
Deficiencies noted:
OPT - Generic User Control. This control can be tested for efficiency purposes rather than testing the same generic IDs throughout
separate controls in the framework. It only covers generic IDs with privileged access, specifically, those identified as a result of
testing access in the various controls in this framework.
SAP.28
Access granted to privileged-level shared and/or generic accounts is appropriately secured, and passwords to such accounts are modified on a
periodic basis (such as when employees with knowledge of the password leave the company).
controls related to access granted to privileged-level shared and/or generic accounts to the SAP . Specifically, consider obtaining an understanding of the
of generic IDs and how they are used
toring and changing the passwords of the IDs
the control, such as procedures related to generic ID monitoring
e control
Control Owner(s) - Document considerations of the appropriateness of authority and competence of the process owner(s) to perform the control,
including consideration of segregation of duties (as applicable)
ACTT
his includes a test of implementation)

a. Identify generic accounts with privileged access in the SAP BASIS Framework. For the accounts identified, determine the purpose of the
accounts and whether the use of the generic/vendor account is limited to activities that require such access.
b. Determine whether the password to the generic accounts are restricted to individuals who require access which is commensurate with their
job responsibilities. Additionally determine whether passwords are appropriately managed and stored for these accounts.
Note: in SAP, generic accounts should typically be configured as type B (Batch) or type C (Communication), rather than A (Dialog) or S
(Service)

If applicable, perform mitigating procedures for any deviations/deficiencies identified during RF testing or for open interim deficiencies.

Global SAP Access and Operations Workplan v7-2017 ERP

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Global SAP Access and Operations Workplan v7-2017 ERP

Uploaded by

Copyright:

Available Formats

IT Testing Area

Competence & Authority

System Level IT Risk Assessment Classification

Control Performer(s) & Title

Risk Arising from IT (RAIT) RAIT Risk Classification

Production systems, programs, and/or jobs result in

If RAIT Risk Classification differs

Risk Associated with

Only authorized users have access to update the batch jobs

IDOCS are monitored and identified issues are resolved timely.

Critical jobs are monitored, and processing errors are corrected to

Access to security administrative functions is authorized and

Table update access is restricted based on specific business need.

Users are authorized to execute programs based on their job

Powerful profiles SAP_ALL and SAP_NEW are adequately

Remote access to SAP for software maintenance for the SAP

Access to change the password parameters is granted

Access for terminated and/or transferred users is removed or

Segregation of duties is monitored and conflicting access is either

User access is periodically reviewed.

Emergency access to SAP is permitted only with prior approval,

Access granted to privileged-level shared and/or generic accounts

Access is authenticated through unique user IDs and passwords or

Evaluation of Design Procedures Evaluation of Design Testing Results

Evidence used to corroborate the design of the control

RAIT Risk Classification

Recommended Tools to obtain data ACTT

SAP.01 (SAP010) Page 13 of 87

Number & Description of Selections (Sample Size)

• The user's access request was approved by appropriate management;

1. Setting for critical risks only

SAP.01 (SAP010) Page 14 of 87

SAP.01 (SAP010) Page 15 of 87

Evaluation of Design Procedures

Evidence used to corroborate the design of the control

Design Factor 5: Criteria for Investigation and Process for

RAIT Risk Classification

Dependency on Other Control(s) or Information

Information used as Audit Evidence

Recommended Tools to obtain data

Interim Operating Effectiveness Testing (This includes a test of implementation)

Test Procedure Number

In lower risk IT environments, this procedure is not typically

Final Operating Effectiveness Conclusion

on (e.g., disabled or deleted);

Is the control dependent upon other controls or information?

Is the information used as audit evidence to test the control?

includes a test of implementation)

Operating Effectiveness Test Procedure (including Implementation)

Roll-Forward Test Procedure

Identify and describe test procedures performed over IPE at RF.

Operating Effectiveness Test Results (including Implementation)

Evaluation of Design Procedures

Evidence used to corroborate the design of the control

Design Factor 3: Frequency and Consistency with Which the

Design Factor 5: Criteria for Investigation and Process for

RAIT Risk Classification

Dependency on Other Control(s) or Information

Information used as Audit Evidence

Recommended Tools to obtain data

Interim Operating Effectiveness Testing (This includes a test of implementation)

Final Operating Effectiveness Conclusion

or access security for the application;