You are on page 1of 38

How to Prepare for a Comprehensive

System Audit and Technical Review


of SAP Access Control 10.0
by Kehinde Eseyin, Senior SAP GRC Consultant, Turnkey
Consulting Ltd.
October 28, 2013
SAPexperts/GRC
Learn invaluable tricks and tips for overcoming top
auditing issues specific to an SAP Access Control 10.0
system.
Learning Objectives
By reading this article you will be able to:
Identify the areas of SAP Access Control that can cause
concerns during an audit of SAP Access Control
Understand the strategies and best practices to prepare
for an audit of SAP Access Control
Maintain segregation of duties (SoD) rule sets and
workflow

Key Concept
A system audit is an exercise performed to gain assurance
that defined controls work as intended, thereby eliminating
the likelihood of fraudulent or malicious activities in the
enterprise system. It involves the verification of conformance
to policies and procedures through acute review of objective
and empirical evidences. The review of the SAP Access
Control 10.0 system is usually performed pre- and post-golive, as well as on an ongoing basis to ensure continuous
compliance. An SAP system audit normally involves
checking the controls defined in the system against what is
defined in the security policies of an organization.

Over the years, I have been involved with the implementation,


audit, and review of SAP Access Control systems. In my
experience on these assignments, some functional experts and
end users do not give proper attention to specific activities that
could expose the SAP Access Control system and connected
back-end systems to undue risk. Based on this, I share some
important areas that need attention when planning,
implementing, and operating SAP Access Control 10.0.
SAP Access Control runs on the standard SAP ABAP
framework with an optional SAP Java infrastructure that can
be integrated with other SAP and non-SAP systems.
Therefore, the conventional audit and technical review
applicable to other SAP system landscapes applies to SAP
Access Control.
However, in this special report, I focus on the core capabilities

of the SAP Access Control system and the areas that can
present audit concerns during a system review. I also explore
both functional and technical areas that, if not properly
managed, can expose SAP Access Control to threats and
vulnerability.
After an overview of the necessities for a thorough system
review, I discuss top strategies and best practices that you
can adopt to gain insight into different control objectives as
they relate to the audit of SAP Access Control, including the
following topics:
Technical installation validation
Activation of Internet Communication Framework (ICF)
services
Definition and maintenance of the segregation of duties
(SoD) rule set
Workflow maintenance
Change request management
Data archiving
Authorization management of technical users
Firefighter ID log-in prohibition
Management of SoD role authorization
Background job administration and monitoring
Integration with back-end systems
Performance optimization
Missing indexes
Business continuity and disaster recovery
Time zone setting
Documentation

The Importance of a System


Review
A technical system review should be an ongoing function to
ensure that participating systems continue to operate optimally
and with no bottlenecks. More important, the system that is
used to manage compliance issues (i.e., SAP Access Control)
should also be compliant.
The objective is to highlight specific controls that should be in
place to safeguard the infrastructure on which the user access
control compliance tool of an organization rests. This is
important because users (e.g., employees, both permanent
and contract) can expose the system to malicious activities
and events through their actions or inactions, which can have
a negative impact on your enterprises business operation.
Therefore, the application used to control user access to
systems needs to be foolproof.
As the access control application is designed to be the
gateway and entry point for users to gain access to the
system, you need to secure and protect this system with
defined and infallible controls. The risk and implications of
access control system noncompliance to defined controls can
be so grave that it can lead to the payment of large fines or
the inability of a business to continue to operate, in extreme

cases.
Exposing the compliance system to risks can also lead to loss
of goodwill for an organization. In fact, the failure of internal
control as it relates to user access control has necessitated
the creation of regulations, such as the Sarbanes-Oxley Act
(with different country versions, such as J-Sox), that have
continued to drive the definition of internal controls that should
be in place for management to be confident that enterprise
systems are not subjected to malicious acts.
The SAP Access Control tool offers functionality to address
four broad areas of access provisioning and user
management; namely, Access Risk Analysis, Access Request
Management, Business Role Management, and Emergency
Access Management. These areas present different risk levels
to the access control infrastructure that should be mitigated by
adequate compensating configuration controls and best
practices.
The SAP Access Control system is designed to address
access control risk issues in the areas of risk detection, risk
remediation and mitigation, risk prevention, and risk reporting.
Therefore, you should adopt a risk management approach to
evaluate the threats, vulnerability, and risk implications of a
compromise of any kind to implemented controls in your
system.

Technical Installation Validation


A major risk during technical installation is that the system
might be error prone and unusable. The preventive measures
you can take include ensuring that the systems run the correct
software components and that the current support package or
patch level is installed.
The technical installation of SAP Access Control requires the
installation of a number of certain software components,
depending on the use case. The following software
components are mandatory for installing SAP Access Control
10.0-specific software components:
SAP_ABACross-Application Component (Support
Package 06)
SAP_BASISSAP Basis Component (Support Package
06)
PI_BASISBasis Plug-In (Support Package 06)
SAP_BWSAP Business Warehouse (Support
Package 06)
The software for SAP Access Control 10.0 is bundled with
Process Control and Risk Management in the add-on
GRCFND_A V1000 (GRC Foundation). You must install this
component on the SAP GRC server. You also need to install
two plug-ins, GRCPIERP and GRCPINW, on the back-end
system that connect to the GRC system. The specific
component of the plug-in component installed depends on the
SAP Basis version of the back-end system.

The back-end system can also be the SAP GRC system;


however, the GRCPIERP software component requires
SAP_ABA and SAP_HR software components. An important
audit concern with the installation of the SAP Access Control
foundation software component and the plug-in software
component is that they must be on the same Support Package
level. The need to have the SAP GRC foundation component
and the plug-in component on the same Support Package
level is still relevant for systems with less than Support
Package 10.
Suffice to say that backward compatibility is in place from
Support Package 10. The backward compatibility adherence
implies that you can upgrade the Support Package level of the
GRCFND_A V1000 software component without necessarily
upgrading the back-end plug-in software components
GRCPIERP and GRCPINWas long as the minimum Support
Package level is 10. Therefore, a technical system reviewer
will be interested in gaining assurance about this consistency
and synchronization requirement with the Support Package
levels of the foundation components and plug-in components.
Furthermore, it is a best practice to update the Support
Package level of the systems in your landscape to the current
Support Package level, as they contain fixes for known issues.
This fact makes the currency of the Support Packages of SAP
components a serious audit concern during a technical system
review.
I recommend that you extend this to confirm if the SAP kernel
is up to date. The SAP kernel is a core component (database
dependent and database independent) of the SAP engine that
contains the executable files (i.e., .exe files) used to start
different processes. The patching of the system should not be
limited to only the SAP components; you must also patch the
underlying database system.
I recommend that you also extend a technical review to gain
assurance that other relevant software components are
installed, especially as part of the post-installation validation
activity. For example, if you need to generate a PDF-based
report, you need to have Adobe Document Service (ADS) set
up in the Java instance connected to the ABAP system on
which the SAP GRC system runs.
To display the Support Package level of your SAP Access
Control system, enter transaction code SPAM. In the screen
that appears (Figure 1), click the Package level button.

Figure 1
The initial screen of the Support Package
Manager
The next screen shows the installed components and the
corresponding Support Package levels (Figure 2).

Figure 2
Support Package levels for different software
components
To review the Kernel patch level of your SAP system, log on
to the SAP Easy Access Menu. Follow menu path System >
Status. In the System: Status screen and then click the other
kernel info icon (Figure 3).

Figure 3
SAP system status and information
The next screen displays the kernel patch level (Figure 4).

Figure 4

Kernel information

Activation of ICF Services


The major risk is that the system might be vulnerable to
Internet (i.e., external) browser-based attacks. The preventive
measure is to enforce control in the activation of ICF services.
The SAP Access Control system runs on the SAP ABAP
engine. After the installation of the ABAP component, ICF
services are all in an inactive status. As part of postinstallation activities, you need to activate a number of ICF
services. The activation of ICF services is performed via
transaction code SICF.
The SAP Access Control system runs via a browser-based
front-end component, which makes the activation of ICF
services an important post-installation activity. The status
(active or inactive) of ICF services is of serious audit concern
because of the security risk associated with directly accessing
active ICF services via HTTP from the Internet. Therefore, it is
a best practice not to activate SICF services that are not
needed. You should activate ICF services on a need basis.
The system review interest for the system auditor is to check
that the system is not exposed to external vulnerabilities as a
result of the activation of unnecessary ICF services. You
should review activated ICF services to ensure that a loophole
capable of introducing threats and vulnerabilities to the system
landscape does not exist. Typically, SAP recommends that
you activate all ICF services within the following ICF service
nodes for use of the SAP Access Control tool:
/sap/public
/sap/bc
/sap/grc
It is also possible to explicitly assign a user to an ICF service.
This is common when end-user logon functionality is
implemented. You must adequately control the authorization
assigned to the user in the system.

Definition and Maintenance of


SoD Rule Set
The major risk is that access risk violations might be
underreported or overreported. As a preventive measure, you
can ensure that SoD and sensitive access rule sets reflect the
approved risk perception of the enterprise.
Auditors usually want to be assured that the SoD rule set is
well defined and properly maintained. The SoD rule set is a
group of data elements that collectively form the segregation of
duties risks and sensitive access risks in an enterprise system.
It is the basis for risk analysis in an enterprise system. SAP
standard SoD rule sets are fashioned after best practices for

risk analysis based on optimal SoD in SAP and non-SAP


systems.
The SAP Access Control system comes with predelivered SoD
rule sets that you can make available in the system by
activating the appropriate business configuration (BC) sets
using transaction code SCPR20. For the SAP system, the
standard rule sets are targeted at specific software
components (for example, SAP ERP Human Capital
Management [SAP ERP HCM] or SAP Customer Relationship
Management [SAP CRM]). BC sets related to SoD rule sets in
the SAP Access Control system include the following:
GRAC_RA_RULESET_COMMONSoD rules set
GRAC_RA_RULESET_JDEJDE rules set
GRAC_RA_RULESET_ORACLEOracle rules set
GRAC_RA_RULESET_PSOFTPeopleSoft rules set
GRAC_RA_RULESET_SAP_APOSAP Advanced
Planning & Optimization (APO) rules set
GRAC_RA_RULESET_SAP_BasisSAP BASIS rules
set
GRAC_RA_RULESET_SAP_CRMSAP CRM rules
set
GRAC_RA_RULESET_SAP_ECCSSAP Enterprise
Controlling Consolidation System (SAP EC-CS) rules
set
GRAC_RA_RULESET_SAP_HRSAP ERP HCM rules
set
GRAC_RA_RULESET_SAP_NHRSAP R/3 less HR
Basis rules set
GRAC_RA_RULESET_SAP_R3SAP R/3 AC rules
set
GRAC_RA_RULESET_SAP_SRMSAP Supplier
Relationship Management (SAP SRM) rules set
During post-installation activities, you activate only the BC sets
that you need. As part of the technical system review, you
need to review the activation log generated after the activation
of BC sets for specific SoD rule sets to ensure that there were
no errors that could lead to data inconsistencies as a result of
the BC set activation. To review the activation log generated
during the activation of a BC set, execute transaction code
SCPR20.
In the initial screen for activation of BC sets, enter a value for
the BC sets field by choosing a set as shown in Figure 5.
You can use the input help by pressing F4. The Short Text
field is automatically populated.

Figure 5
Define a BC set in the initial screen for BC
set activation
Click the activation log icon . In the next screen, you can see
the activation logs grouped by an activation timestamp (Figure
6).

Figure 6
Timestamp for BC set activation log
Expand a specific node of the timestamp to see details of the
activation log, as shown in Figure 7.

Figure 7
Detailed log of BC set activation for an SoD
ruleset
It is important that errors are not reported or generated during
the activation. If an error is generated, it can lead to data
inconsistencies. You can review warning messages for
appropriateness and ignore them if they do not represent a
catastrophic event.
Note
If you have an existing SoD ruleset that has been validated

and operational, you do not need to perform this postinstallation task and therefore the review of the SoD ruleset
BC set activation log is not applicable.
It is not sufficient to simply activate the BC set containing the
standard SoD rule set. The standard rule set may not
necessarily be fit for the purpose, and therefore, needs to be
maintained and validated by appropriate personnel. The
validation of the rule set normally involves the review of
dependent master data elements of a SoD rule set, such as
risks and functions (actions and permissions).
The purpose of the review of the SoD rule set content is to
gain assurance that the content of the rule set is correct and a
precise representation of the risk appetite and the perception
of enterprise access risks. The review of rule set content
needs to be very detailed to address not only the associated
transaction codes (i.e., actions) but also the correctness of the
absolute value defined for the corresponding authorization
objects. For example, in the definition of authorization object
value, 1 is not synonymous to 01.
In the same vein, the use of the value asterisk (*), for
example, does not equal any value. Rather, it means * itself.
Therefore, if you want to make a permission definition
applicable to all purchasing groups, you do not use *. Instead,
you either deactivate the field for the assignment or be explicit
(i.e., list the explicit purchasing group values). Another option
is to use the value $.
You also need to check that the operators (AND, OR, and
NOT) used in the rule set definition are properly defined. The
maintenance of the wrong value might not necessarily cause
an error message, but it affects the reporting of access risks
because you are underreporting or overreporting, as the case
may be. Furthermore, adequate understanding of the operator
is important because most users are quick to misunderstand
the reporting output of the operators. For example, when the
NOT operator is used in permission-definition logic, it reports
users that have any value except the value in the rulenot
the users who do not have the value defined.
Part of the review of the SoD rule set content should address
the correct assignment of the access risk to the appropriate
business process. Similarly, you need to validate the access
risk level to ensure correct master data attributes (e.g., risk
levels) are maintained.
You should not maintain a high access risk element as
medium. This is because the risk levels can have serious
implications in the analysis of the access risk exposure
reporting to management, especially as it relates to selection
criteria definition. Furthermore, the incorrect maintenance of
risk levels can lead to the failure of configured controls and
the incorrect evaluation of Business Rule Framework plus
(BRFplus) business rules. For example, if you define a
business rule using the request mitigation access control
application to enforce the mitigation of an access risk level
defined as high, but the attribute (i.e., risk level) of the

dependent master data (i.e., access risk) is incorrectly


maintained, the result is control ineffectiveness because the
business logic does not evaluate correctly.
Note
The quick tip Seamlessly Configure Request Mitigation
Policy Rules in SAP Access Control 10.0 defines the
strategy for configuring request mitigation policy rules based
on access risk attributes, such as access risk level.
Another audit concern in the technical review of the SoD rule
set is checking for completeness. This implies that no data
(including standard transaction codes) that can affect the SoD
risk reporting should be left out of the SoD rule set. It is
commonplace to have defined custom transaction codes in
your system. As expected, the standard rule set does not
contain custom transaction codes. As a matter of fact, custom
transaction codes are often built to address a critical system
requirement that is not met by standard system functionality.
This assertion gives credence to the fact that the access risk
issues associated with custom transactions should be treated
seriously and included in the SoD rule set. You should
approach the business process owner of the custom
transaction code to gain an understanding of the associated
risks of the custom transaction code and then analyze it for
SoD violation possibilities.
Table TSTSC, which can be accessed via transaction code
SE16, contains all transaction codes defined in the system.
You can use the prefix adopted for custom transactions in the
organization to filter out the custom transaction codes and
confirm if they are defined in the SoD rule set.
Note
The article Update the SAP BusinessObjects Access
Control Rule Set with Custom Transactions by Selva
Kumar, vice president, Auditbots, defines the technical
details of the inclusion of custom transaction codes in the
access control SoD rule set.
The maintenance of an SoD rule set is a continuous process
aimed at ensuring that the rule set is a true reflection of the
risk exposure of an enterprise at any point in time. One of the
control objectives of the technical review of the SAP system is
the existence of an effective policy and procedure ensuring
that changes to the access rule set are made in a controlled
manner. This should cover adherence to best practices of
approving changes before the changes are moved to the
production environment from pre-production systems.
This requirement is discussed in detail under the Change
Request Management section. You can perform the
maintenance of an access rule set directly in the back-end
system (IMG of the access control) or via the front end (SAP
NetWeaver Business Client [NWBC]). Because of the
sensitivity and criticality of SoD rule set data, it is important to

ensure that the authorization to maintain the rule set data is


controlled as much as possible.
You can perform the following maintenance activities for an
SoD rule set via customizing (IMG):
Download SoD Rules: This allows you to download a
rule set using the program
GRAC_DOWNLOAD_ACCESS_RULES
Upload SoD Rule: This allows you to upload an SoD
rule set using the program
GRAC_UPLOAD_ACCESS_RULE
Generate SoD Rule: This allows you to generate an
SoD rule set after an SoD rule set upload or transport
using the program
GRAC_GENERATE_ACCESS_RULE
Delete SoD Rule: This allows you to delete specific
SoD rule set data via the program
GRAC_DELETE_ACCESS_RULES. Another program
you can use to delete an SoD rule set is
GRAC_DELETE_ACCESS_RULES_ALL, but this
program should be used with utmost care as it cleans
up all SoD rule set-related master data from the
system.
Transport SoD Rule: This activity allows you to
transport an SoD rule from the development system to
the destination systems. The maintenance of the rule
set should be treated as a transportable activity to
ensure adherence to change control best practices.
You can perform the above maintenance activities via menu
path SPRO > SAP Reference IMG > SAP Customizing
Implementation Guide > Governance, Risk and Compliance >
Access Control > Access Risk Analysis > SoD Rules.
When rule set data is maintained directly via NWBC, you need
to activate the change log functionality so that the audit trail is
available for an auditor to review changes made to the
elements of the rule set. The activation of the change log is
made by setting the configuration parameters 1001 and 1002
for functions and access risk to YES in customizing, as shown
in Figure 8.

Figure 8
Change log setting for function and risk
To display the corresponding parameter settings for the
change log, follow menu path SPRO > SAP Reference IMG >
SAP Customizing Implementation Guide > Governance, Risk
and Compliance > Access Control > Maintain Configuration
Settings. Figure 9 shows a sample change log for a function

that reports on the change type, timestamp, old value, and


new value.

Figure 9
Change log report for a function
Furthermore, you can activate workflow as part of your
strategies to ensure that risk and functions that are an integral
part of the SoD rule set go through the appropriate approval
requirements before changes are successfully made. This is
controlled by the Function Approval workflow
(SAP_GRAC_FUNC_APPR) and Risk Approval Workflow
(SAP_GRAC_RISK_APPR) processes, which you can maintain
in the Multi-stage Multi-path (MSMP) Workflow Process wizard
maintenance screen (Figure 10). To access this screen use
transaction code grfnmw_configure_wd.

Figure 10
The process global settings phase in MSMP
workflow configuration
You can refer to the Workflow Maintenance section for more
information on workflow.
Following are some of the dependent configuration parameters
that can influence workflow settings for risk and functions
maintenance in the SAP Access Control system:
Parameter
Parameter
Parameter
Parameter
Parameter
Parameter
Parameter

1062:
1064:
1101:
1102:
1103:
1104:
1105:

Risk Maintenance
Function Maintenance
Create Request for Risk Approval
Update Request for Risk Approval
Delete Request for Risk Approval
Create Request for Function Approval
Update Request for Function Approval

Parameter 1106: Delete Request for Function Approval


Note
The quick tip 2 Options for Maintaining Rule Sets in SAP
Access Control 10.0 by Alpesh Parmar, managing partner,
ultimumIT Inc., in the SAPexperts GRC hub provides insight
into the different approaches to maintaining an SoD rule set.

Workflow Maintenance
Another major risk is that an approval request might not be
treated in a timely manner and by the correct approver. The
preventive measure you can take is to ensure that the
workflow mechanism is properly configured and the approver
master data is properly maintained.
To use the workflow capability of the SAP Access Control
system, it is necessary to perform a few post-installation
activities. These include:
Automatic workflow customizing
Task-specific customizing
Following the execution of these workflow-related
customizations, you need to gain assurance that the workflow
engine is working. To do this, perform a workflow verification
activity. Follow the steps below to gain preliminary assurance
that the workflow engine is working properly.
Note
This section does not explain how to execute the different
customizing activities. Refer to the appropriate
documentation on the Service Marketplace on how to
perform the different workflow activation tasks.
Enter transaction code SWU3 in the command line. In the
screen that appears, click the start verification icon (Figure
11).

Figure 11
The initial screen for automatic workflow
customization
The next screen displays a dialog box, as shown in Figure 12.

Figure 12
Start of workflow verification notification
Click the green check mark icon and navigate to the business
workplace view by clicking the business workplace icon . A
new message appears in your inbox (Figure 13).

Figure 13
Business workplace inbox
Highlight the message First step in workflow verification and
click the execute icon. In the next screen, click the Execute
background step immediately button (Figure 14).

Figure 14
First step in workflow verification
The next screen displays a message in your inbox that the
verification of workflow was completed correctly (Figure 15).

Figure 15
Inbox folder showing the status of the
workflow verification in the message body
Workflow is designed to ensure that activities within the
system are properly reviewed and approved by the designated
individuals before changes are made to specific information or
processes. This can include granting access to users or
changes to master data, such as functions or assignment of
mitigating controls to users and roles. The auditors interest in
a workflow process is who the actor (i.e., approver) is. This
audit concern is important because the appropriate user must
be set up in the system to ensure that the correct person
performs the required responsibility. The approver must be
reviewed for correctness and currency at defined intervals. In
the context of SAP Access Control, the approvers are known
as agents. Broadly, agents can act as approvers and as
notification recipients of workflow-related events.
Note
The approver can be correct, but not current (e.g., in the
approver-delegation relationship). A delegate can be correct
as an approver, but not current.
It is expected that an auditor will be interested in how the
agent master data is maintained to ensure that the workflow
approval requests are routed to the appropriate approvers and
that approval requests are attended to promptly. Different
workflow-driven activities require you to set up agents in the
system. The source of the agent master data depends on the
defined agent type, which can be any of the following:
Directly mapped users: The agents are determined
based on a defined list of approvers who are associated
with an approver group ID.
Transaction code PFCG roles: The agents are
determined based on the assignment of a specific
PFCG role.
PFCG user group: The agents are determined based
on their assignment to a defined user group on the
groups tab of the user master data (transaction code
SU01).
GRC Application Programming Interface (API) rules:
The approvers are determined based on business rules
defined via any of the rule types (i.e., BRFplus,

BRFplus flat rule, Function module, and ABAP class).


Irrespective of the method adopted to determine the approver,
the approver master data needs to be reviewed for
correctness and currency at specific intervals. Adequate
procedures and policies must guide the process of making
changes to the agent master data. The change management
process should be leveraged as much as possible when
changes are made to the agent master. Refer to the Change
Management section later in this article for more information
about enforcing effective change management best practices.
Another audit concern is how the delegation of authority is
managed within the enterprise. The approval delegation
capability is laudable because it allows another user to act in
the primary approvers capability for a defined period of time,
usually during a vacation. As a best practice, it is ideal for
actors (e.g., approvers) in a business process to be
unavailable over a period of time. It is a management strategy
to prevent fraud and identify lapses in the business process as
a result of the unavailability of the principal actor. It is common
to see individuals who are supposed to be approvers
delegating their approving rights to their subordinates without
any genuine reason.
Ideally, approving responsibilities should be delegated in
special situations when the main approver is not available to
act on an approval request. Figure 16 shows a typical
approval delegation table. You can display the approval
delegation table by following menu path NWBC: Access
Management > Access Requests Administration > Admin
Delegation.

Figure 16
Approval delegation table
An auditor should review this table to gain assurance that
every approval delegation entry is justifiable. More important,
you need to establish that the delegated employee has the
requisite knowledge and skill set to perform this responsibility
appropriately.
The technical review should cover the delivery of notification
messages to intended recipients. This is to ensure that agents
(not necessarily the approvers) are only notified about
approval events that have taken place. This is important in
certain circumstances. For example, a group of users might
need to know about the access provisioning activities of
specific access request attributes in order to perform specific
follow-on activities outside of SAP Access Control, such as

manual maintenance of data in non-SAP systems.


Also, notifications ensure that users are informed about
pending approval decision requests in their inboxes on time to
prevent unnecessary delays. To facilitate the sending of
emails, you need to define settings in transaction code SCOT,
such as the node type, mail server host, mail server post,
address type, and recipients list (Figure 17).

Figure 17
Define settings for the SMTP node of
SAPconnect
To review the status of email messages that are generated in
the system over a period of time, use transaction code SOST
(Figure 18). You need to review the entries in the table
appropriately to ensure that email messages are not going
unnoticed.

Figure 18
Monitor the status of email messages
Furthermore in an environment in which email messages must
be sent to users as part of the configured process flow or
business requirement, the technical review should make
provision for checking that all users have their email
addresses maintained accordingly for example, in
transaction code SU01 where the SAP system is the data
source of the user email address attribute.

Change Request Management


Another major risk you could encounter is data and
customization setting inconsistencies that make the system
error prone. To prevent this, you can enforce control in the
promotion of changed data or customizations across the
system landscape by avoiding performing customizing
activities directly in the production system.
You must configure the system landscape of the access
control system to adhere to at least the three-system
landscape, typically made up of the development, quality
assurance, and production systems. It is possible to include a
test system to enforce additional control in the system
landscape.
Figure 19 shows a typical transport route for a three-system
landscape. The transport route diagram provides assurance
that the three-system landscape is configured and that an
auditor can check it by following menu path transaction code
STMS > Overview > Transport Routes. An auditor will be
interested in ascertaining that all configuration changes,

including master data (rule sets and BRFplus rules such as


logic and master data, approvers, or user defaults) are tested
before the changes are promoted to destination or subsequent
systems in the landscape.

Figure 19
Transport route for a three-system
landscape
This architecture discourages people from making
modifications directly in the production system. You should
configure the production system in such a way that direct
modification in the production environment is impossible. You
can review production client settings for appropriateness via
transaction code SCC4.
As I stated earlier, all transportable configuration and master
data must be transported across the system landscape. This
includes the BRFplus application. BRFplus is at the heart of
the SAP Access Control system and drives the behavior of the
business workflow process. To make BRFplus applications
transportable, you first need to create a development package
via transaction code SE21, which is consequently associated
with the application. Note that BRFplus applications created as
local objects cannot be transported. Figure 20 shows a
BRFplus application created as a local package with the
Transport button grayed out (therefore, it is not transportable).

Figure 20

A BRFplus application created as local


object and not transportable
Figure 21 shows a development package (ZGRAC)
associated with a BRFplus application with the Transport
button active and therefore transportable.

Figure 21
A BRFplus application created as a
transportable object
A number of master data items cannot be transported in SAP
Access Control. They include reason codes, access control
owners definition, coordinators, and firefighter master data.
You should use the authorization concept in conjunction with
the SoD concept to enforce control in the management of
non-transportable master data. You should also review this
master data on a periodic basis for currency and correctness.
Furthermore, when there is a change request, a control
process must be in place that objectively reviews the impact
of such changes on all dependent business processes and
end users. You should also secure the development and
quality assurance systems appropriately. A defined security
policy should address access rights, modification, and data
composition of the non-production systems.

Data Archiving
When you are archiving data, there is a potential risk that
system performance might be impaired and data retention
policies might be flaunted. As a preventive measure, you can
archive data at defined intervals based on corresponding

regulations.
In a typical organization, aside from business requirements
and corporate policies, prevailing legal and regulation
requirements influence data retention strategies adopted by an
enterprise. Further, data archiving has a laudable implication
as it relates to enhancing system performance. These reasons
make the issue of data archiving an important technical
system review concept. SAP Access Control provides
standard archiving objects you can use to archive specific data
in the system.
A system auditor will be interested in understanding the
archiving strategy of an organization and applying that to gain
assurance that data is properly archived as scheduled using
the appropriate tools. SAP Access Control supports the
standard archiving process of data via transaction code SARA
(Archive Administration). The following archiving objects are
available to archive access control-specific data:
GRFNMSMPArchiving for SAP Access Control 2010
requests
SPM_AU_LOGSPM audit log archive
SPM_CH_LOGChange log archive
SPM_LOGArchiving for SPM log reporting
SPM_OC_LOGSPM OS command log archiving
SPM_SY_LOGSPM system log archival
The archiving process dumps the archive files in the defined
archive directory. Besides the issue of compliance with the
archiving calendar or schedule, the security and protection of
the archive file destination can represent an audit concern.
The integrity of the storage location of the archived data is
important to consider during your review of the system.
Note
SAP Note 1719967How to archive in GRC Access Control
10.0 provides step-by-step instructions on how to archive
objects in SAP Access Control 10.0.

Authorization Management of
Technical Users
The major risk here is that the technical user account might
be used for malicious activities in the system. To prevent this,
ensure that there is control in the authorization assignment of
technical users.
To operate SAP Access Control normally, you need to create
some system users and assign them to specific authorizations.
Examples of these system users are Remote Function Call
(RFC) users and WF-BATCH users. A typical SAP Access
Control system landscape is made up of the SAP Access
Control system itself and dependent back-end systems (e.g.,
SAP ERP or SAP SRM). To establish communication between
the SAP Access Control system and the back-end systems,

you need to set up an RFC connection (connector) between


these systems via transaction code SM59.
The type of back-end system typically determines the type of
RFC destination. For example, to connect to an ABAP-based
system, you need to create an RFC of type 3 (ABAP
connection). On the other hand, to connect to SAP NetWeaver
Portal, you need to create an RFC of the type G (HTTP
connection to external server). Normally, RFC destinations
need a user account that is used to authenticate the call to the
destination system. Figure 22 shows a user assignment to the
RFC destination of the ABAP connection type.

Figure 22
User assignment to an RFC destination
The RFC user can be a powerful user because it can
establish a remote connection (logon) to a destination system.
Therefore, the authorization assigned to an RFC user must be
properly controlled. SAP recommends that you assign the
following authorization objects and values to the RFC user for
SAP Access Control functions:
ACTVT: 16
RFC_NAME: /GRCPI/GRIA, BAPT, RFC1, SDIF,
SDIFRUNTIME, SDTX, SUSR, SUUS, SU_USER,
SYST, SYSU
RFC_TYPE: FUGR

The WF-BATCH user is a communication user that is required


to run the workflow engine. You must assign the standard
delivered role SAP_GRAC_ALL (or its copy) to the WFBATCH user. The authorization assigned to this user must
also be well controlled.
Note
SAP Note 1251255 provides information about authorization
management for the WF-BATCH user.
The system audit should cover the review of the authorization
assigned to technical users, especially the RFC user and the
workflow user (WF-BATCH). Under no circumstance should
you assign the SAP_ALL profile (or its flavor) to these
technical users.

Firefighter ID Login Prohibition


An additional major risk is that a firefighter ID (with privileged
authorization) might be used to log on directly to the back-end
system to perform malicious activities, and the logs will not be
captured. As a preventive measure, you can implement the
user exit described in SAP Note 1545511.
Firefighting refers to the act of using privileged user accounts
in times of emergency. This functionality is one of the most
important capabilities of SAP Access Control, as it seeks to
control the assignment of excessive authorization (including
SAP_ALL) to users. SAP Access Control allows a user to
firefight using either the firefighter ID strategy or a role-based
strategy.
Note
In the webinar Role- or ID-Based Firefighting: Which Option
Is Best for Your SAP Systems Landscape?, I describe a
number of concepts that you should consider when deciding
on the firefighting strategy to adopt in an enterprise. View
the webinar

00:00
00:00

Role- or ID-Based Firefighting: Which Option Is Best for


Your SAP Systems Landscape?
.
With the firefighter ID strategy, the ID is the user with elevated
privileges allowing them to perform a firefighting session in the
system. The firefighter ID is typically identified via the
assignment (in the back-end system) of the role maintained in
parameter 4000 in the SAP GRC system. You should log the
activities performed by a firefighter ID and enhance the
process to send these logs to a controller via workflow for
review and approval.
Because the firefighter ID possesses elevated privileges, it
should not be used directly in the system. Instead, it should
be used via the assigned firefighter user. To enforce control
around the use of the firefighter ID directly in the back-end
system, you can implement a user exit in the back-end system
where the firefighter ID resides. The user exit prevents the
firefighter ID from logging on directly to the back-end system.
SAP Note 1545511 defines the steps to create this user exit.
It is still possible to log on with a firefighter ID after the user
exit has been implemented if dependent configuration settings
(SPM application type and FFID role name in the plug-in
system and the SAP GRC system) are not yet maintained
appropriately or if the plug-in software component level in
SAP GRC differs from that of the back-end system. Therefore,
the best way to review if this user exit has been implemented
is to execute a test that attempts to log in directly to the backend system using a firefighter ID. This action should trigger
the display of a dialog box as shown in Figure 23.

Figure 23
Dialog box confirming the prohibition of
direct login with a firefighter ID

The dialog box displays briefly (for about two seconds) and
states that you are not allowed to log on with a firefighter ID.
A review of this requirement is important for giving assurance
that the firefighter ID cannot be used in the system without
being monitored and reported as part of emergency access
management reporting, thereby eliminating the possibility of
the perpetration of malicious activities in the system.

Segregation of Duties
Another risk you can encounter is the perpetration of malicious
activities as a result of the possession excessive authorization.
To prevent this, employ the principle of least privilege in
authorization assignments. Authorization should be granted on
a need-to-know basis.
SoD is included in the requirements of many regulations,
including Sarbanes-Oxley. The idea is to prevent the
concentration of authority to carry out critical activities in the
system with specific users. One of the use cases of the SAP
Access Control system is to ensure that duties are properly
segregated in the enterprise systems connected to it. You
should also extend this capability to the SAP Access Control
system itself.
It is a best practice to form a set of incompatible SoD matrices
for the SAP Access Control system (i.e., SAP Access Control
itself should have a set of activities that are segregated). For
example, when a user who creates a function (a component of
an access risk) is also the approver of the function, control
becomes a serious issue because this compromises the entire
process of SoD rule maintenance. In the same vein, internal
control can also be a huge audit concern if the person who
creates a mitigating control can also maintain the mitigating
control or assign the mitigating control to users or roles.
Therefore, it is important for a system auditor to be assured
that responsibilities are adequately segregated in the SAP
Access Control system and performed with a sense of
independence.
SoD control is closely interwoven with user management,
especially as it relates to roles and profile assignments. A
technical review should seek to establish that the authorization
assigned to specific job roles is optimal and does not create a
conflict that is unmitigated.
A number of standard configurable controls are designed to
enforce SoD. These configuration settings should be reviewed
for correctness and appropriateness. Examples are:
The approver cannot approve his own request
The firefighter ID owner can submit a request for a
firefighter ID owned
The firefighter ID controller can submit a request for a
firefighter ID controlled
Note
Every firefighter ID has an owner and controller. The owner

maintains the ID and approves the assignment. The


controller reviews the log associated with the firefighter ID.
The approver cannot approve his own request. This is
configured in the customizing activity in which you can
maintain End User Personalization (EUP) fields by following
menu path SPRO > SAP Reference IMG > SAP Customizing
Implementation Guide > Governance, Risk and Compliance >
Access Control > User Provisioning > Maintain End User
Personalization. Figure 24 shows an example of a typical
setting to prevent the approver from approving his or her
request.

Figure 24
EUP setting for Approve/Reject Own
Requests
You can assign the EUP setting to an approval stage in the
MSMP workflow customizing to influence the behavior of
different stages in a workflow path.
Following is an explanation of the parameter settings for
scenarios in which the firefighter ID owner submits a request
to access an owned firefighter ID, and in which a firefighter ID
controller submits a request to access a controlled firefighter
ID:
The firefighter ID owner can submit a request for a
firefighter ID owned: When parameter 4013 is set to no,
it disallows a firefighter ID owner from submitting an
access request for a firefighter ID for which he is the
owner. To set this parameter, follow menu path SPRO
> SAP Reference IMG > SAP Customizing
Implementation Guide > Governance, Risk and
Compliance > Access Control > Maintain Configuration
Settings.
The firefighter ID controller can submit a request for a
firefighter ID controlled: When parameter 4014 is set to
no, it disallows a firefighter ID controller from submitting
an access request for a firefighter ID for which he is
the controller. To set this parameter, follow the same
menu path referenced above.
If you cannot adequately segregate duties, the auditor should
seek to gain assurance that effective compensating controls
are in place. This might be the case when there are certain
constraints, such as organizational structures an inadequate
number of employees.

Background Jobs Administration

and Monitoring
When you are considering background jobs administration and
monitoring, a major risk is data inconsistencies between the
SAP GRC system and the satellite system. In addition, smooth
running of the system might be affected if administrative
background jobs are not scheduled and executed successfully.
As a preventive measure, you can schedule (in the correct
order) and monitor background jobs for successful completion.
Background jobs define programs or a collection of programs
that are executed by background work processes. Various
background jobs are normally scheduled in the system to
ensure that activities are performed properly. To achieve this,
specific ABAP programs are scheduled as background jobs via
transaction code SM36. You should always have a defined
naming convention for background jobs. When you are
determining a naming convention, the following elements can
be useful:
Prefix: Indicate if the job contains customer coding (Z)
or SAP standard coding (S)
System/client: Indicate the involved system and client
combination (e.g., PRD100)
Organization: Indicate the involved organizational
information, such as abbreviations for regions
(Americas, Europe, Asia) or countries (e.g., US, DE,
and FR)
Component: Involved component or application area,
such as ARM, EMA, and BRM
Job description: Specify a speaking name for the job
itself (e.g., SPM_WORKFLOWSYNC)
Frequency: job frequency, such as Hourly (H), Daily
(D), Weekly (W), Monthly (M), Quarterly (Q)
For example, a standard job in the PRD system for client 100
in the United Kingdom for the SPM component for workflow
synchronization that runs hourly will look similar to
S_PRD100_UK_SPM_WORKFLOWSYNC_H. A meaningful
job naming convention is important for finding the correct and
appropriate application knowledge for further support as
quickly as possible. Also, the job frequency at the end of the
job name provides basic insight about the urgency of a
background job.
A typical SAP GRC system is made up of the GRC server and
a number of connected satellite systems. The satellite systems
need to be in sync with the GRC server, so you need to
schedule standard background jobs in the SAP Access Control
system to synchronize data between the SAP GRC system
and the satellite systems. This is designed to ensure data
currency and consistency between the SAP Access Control
system and the satellite systems. Here are the major master
data elements that you need to synchronize in the SAP
Access Control system:
PFCG authorization
Profile
Roles

Users
Action usage
Role usage
The implications of failed synchronization jobs can be grave,
especially when the currency of data can expose the system
to fraudulent activities. For example, if one of the attributes
coming from the back-end system drives the approver of an
access request, and this information is not in sync with the
SAP GRC system, the access request might be routed to the
wrong approverwho might approve the access request
based on inadequate knowledge of the risk exposure.
Similarly, the detective control associated with the review of
firefighter logs can be impaired if the background job
responsible for collecting firefighting session logs and sending
them to the controller fails to execute successfully.
An auditor will be interested in ascertaining that background
jobs that drive data synchronization are always executed
successfully as scheduled. The sequence of execution of
these background jobs is also an important consideration
during a technical review. SAP recommends that you adopt
the following order when scheduling background jobs in the
SAP Access Control system:
PFCG Authorization: Program
GRAC_PFCG_AUTHORIZATION_SYNC
Repository data (profiles, roles and users): Program
GRAC_REPOSITORY_OBJECT_SYNC. Note that you
can synchronize the repository data (profiles, roles and
users) with programs
GRAC_ROLEREP_PROFILE_SYNC,
GRAC_ROLEREP_ROLE_SYNC, and
GRAC_ROLEREP_USER_SYNC, respectively.
Action Usage: Program
GRAC_ACTION_USAGE_SYNC
Role Usage: Program GRAC_ROLE_USAGE_SYNC
Other programs that you should schedule as background jobs
are:
Batch risk analysis: Program
GRAC_BATCH_RISK_ANALYSIS
Firefighter logs collection: Program
GRAC_SPM_LOG_SYNC_UPDATE
Firefighter workflow synchronization: Program
GRAC_SPM_WORKFLOW_SYNC
IDM schema update: Program
GRAC_SCHEMA_UPDATE
EAM Master Data: Program GRAC_SPM_SYNC
For the system to operate normally and optimally from a
technical perspective, you should schedule some databasedependent administrative background jobs to run at intervals.
A technical system auditor should be informed that the
required background jobs that are scheduled for different
underlying databases. For example, you should execute the
following database management-related background jobs for a
Microsoft SQL Server database:

Computing Center Management System (CCMS)


blocking database locks statistics
CCMS check database (DBCCdatabase consistency
checker)
CCMS update table statistics
MS SQL COLLECTOR
The status of all these background jobs should be reviewed
via transaction code SM37 as part of technical system review
activities.
Variants are used to eliminate the need to define the same
values in selection criteria fields every time you execute a
report. This functionality is designed to reduce both data entry
time and system processing time, which makes it common in
every SAP system environment. You should also review
variants for correctness and currency. Ideally, you should
discontinue or adjust variants that are no longer relevant in the
system. You can review the entries in table TBTCP to access
the currency and relevance of defined variants.

Integration with Back-End


Systems
The next major risk is that vulnerabilities and data inaccuracy
in the back-end system can impact the operation of the SAP
GRC system. The preventive measure you can take is to
ensure that appropriate security and data accuracy is enforced
in satellite systems.
A typical SAP GRC system is not made up of just the SAP
GRC box alone; rather, it contains other back-end systems
such as SAP ERP, SAP SRM, SAP NetWeaver Portal, or
Microsoft Active Directory. These back-end systems play
different roles in the system landscape. In some cases, the
SAP GRC system is used to provision access to the back-end
system, or the back-end system is used as the data source
for user authentication and user details in SAP Access
Control. The seriousness to be accorded the SAP Access
Control system in terms of system review should also be given
to the back-end system.
This is important because security breaches in any of the
dependent back-end systems can have an impact on the
integrity of the SAP Access Control system. For example, if
the SAP ERP HCM system is designed as the source of user
details (e.g., personnel area) that drives the assignment of the
approval agent, and the data maintained in the SAP ERP
HCM system is not accurate, an access request can be routed
incorrectly (even though the configuration of the logic in SAP
Access Control is correct).
Therefore, a system auditor naturally wants to gain assurance
that systems connected to the SAP GRC system are
performing their role as intended in terms of functionality
delivery and data accuracy. If the SAP ERP HCM system is
the source of a mandatory field in access request and SAP

ERP HCM is unavailable, the implication is that the SAP


Access Control system is unavailable because it also will not
be useful for access provisioning.

Performance Optimization
A major performance risk is slowness or unavailability of the
system. To prevent this, you must create appropriate and
optimal configuration settings and parameterization.
It is important to perform preliminary sizing before the
implementation of the SAP Access Control solution. This is to
ensure that you have an idea of the hardware requirements,
including disk size, network bandwidth, physical memory, CPU
processing power, and I/O capacity based on the business
requirement and environment. There should be an IT-balanced
scorecard designed to measure IT performance. If you do not
define empirical performance indicators, senior management
might be misled on the true implications of performance
impairment.
Here are some examples of indicators to measure the optimal
performance of your SAP Access Control system:
System performance: The number of active users,
maximum dialog steps per hour, average response time
in a dialog task, average response time at peak dialog
hour, average response time in an RFC task, average
RFC response time at peak work hour, and maximum
number of RFCs per hour
Hardware capacity: Maximum CPU utilization on
database server
Database performance: Average database request time
in update task, average database request time in dialog
task, and average database time in RFC
Database space management: Database size and
growth over a defined period
Broadly, the performance of the SAP Access Control system is
dependent on the following:
Master data volume
Transaction data volume
Configuration settings (customizing)
Number of concurrent users
Size of the system landscape (number of systems and
available system resources)
The reality of the business environment can also have an
impact on performancefor example, the average number of
permission level violations per object, the total number of
access risk and rules, and the complexity of the approval
workflow process. The measurement of optimal system
performance requires technical skills and standard tools such
as SAP Solution Manager. The ability to interpret standard
performance-related reports and indicator settings is very
useful. For example, if you have an average CPU load that is
more than 90 percent, a system reviewer should be able to
deduce that this represents an adverse CPU problem.

The performance of SAP Access Control can raise serious


audit questions. Even though performance management
sounds more like a technical requirement, if performance is
degraded, it can lead to system unavailability and
consequently affect functional use of the application.
The period of downtime might represent a window to
perpetrate malicious activities, especially when there are no
adequate processes and controls in place to address the
challenge. Therefore, a system auditor will be interested in
ascertaining that the basic configurations that can enhance
system performance are in place. For example, if the
configuration option Enable Offline Risk Analysis is set to Yes,
the tables holding the action and permission level details for
all risk analysis performed will be parsed. It can become very
large (i.e., millions of records) and significantly affect your
system performance adversely.
As I asserted earlier, configuration settings can influence
system performance. This makes the review of configuration
settings an important activity during system review. An
example is the exclusion of users and critical roles. This is to
ensure that risk analysis runs completely and successfully in a
suitable amount of time, without significantly affecting system
resources. I acknowledge that system resources differ from
one installation to another; however, unless there is specific
need to act otherwise, it is a best practice to:
Set the default user type for risk analysis to DIALOG
Parameter 1026
Include locked users (Parameter 1031), include expired
users (Parameter 1028), and include mitigated risks
(Parameter 1030) should be set to NO.
Set ignore critical roles and profiles to YES
Parameter 1031
You can perform the aforementioned configurations
parameters in configuration settings by following menu path
SPRO > SAP Reference IMG > SAP Customizing
Implementation Guide > Governance, Risk and Compliance >
Access Control > Maintain Configuration Settings.
You also need to execute some administrative background
jobs to ensure that the system perform optimally. An example
of a background job is report RSBTCDEL (delete batch job).
You must schedule this job in the system to ensure that the
spool object and obsolete jobs are deleted in the system. For
more information on this program and other standard
background jobs (e.g., standard jobs or reorganization jobs),
consult SAP Note 16083.
Another performance-related configuration is the definition of
the index for fields MANDANT, UTIME, UDATE, and
USERNAME in table CDHDR, as shown in Figure 25. This
ensures that performance is not impeded during firefighting
session report generation. SAP Note 1039144 provides
information on how to create this index. To improve the
performance of the reporting tool for emergency access
management, you must index the fields MANDANT, UTIME,

UDATE, and USERNAME of table CDHDR as recommended


in SAP Note 1741151.

Figure 25
Index for table CDHDR
Another area of technical interest is the management of
memory in the SAP Access Control system. This phenomenon
is an audit interest because if your hardware cannot optimize
the maximum memory consumption, you will have memoryrelated problems and consequently impaired system
performance. In most cases, the default settings of memoryrelated parameters are not optimal. The following profile
parameters should be reviewed via program RSPARAM in
transaction code SE38 for adequacy:
abap/heap_area_dia (limit of heap memory per dialog
work process)
abap/heap_area_nondia (limit of heap memory per nondialog work process)
abap/heap_area_total (limit of heap on application
server)
em/initial_size_MB (initial size of extended memory
pool)
abap/buffersize (program buffer size)

Missing Indexes
Another major risk is the possibility of data inconsistencies. To
prevent this, simply make sure that there are no missing
indexes. Indexes are important objects in the management of
database systems. It is essential that there are no missing
indexes at the database level of the SAP Access Control
system. Because tables in the SAP environment are so large,
data is often accessed via indexes to enhance system
performance. The concept of missing indexes can present an
audit concern, especially because it can lead to data
inconsistences in the system. You can review missing indexes
via transaction code DB02.

Business Continuity and Disaster


Recovery
Data loss or inability to continue business operation in the
event of a disaster is another risk. To prevent this, ensure that

an appropriate business continuity plan and disaster recovery


plan exist and are tested at defined intervals.
The impact of the unavailability of the SAP GRC system
should be analyzed at some point. Appropriate plans should
exist to counter possible unavailability issues with the system
in the SAP Access Control landscape, both planned and
unplanned. When developing a disaster recovery plan, you
need to perform a business impact analysis to ascertain the
implications of the unavailability of the SAP Access Control
system in terms of qualitative and quantitative measures. For
example, in a global implementation, what is the implication of
not being able to provision emergency access for the sales
team when needed? You can quantify the financial loss
implications and help to advise an optimal countermeasure.
Adequate and effective backup and restore strategies must
exist to ensure business continuity.
This strategy must be tested periodically to ensure that there
are no disappointments when you restore the system. Usually,
a system auditor will be interested in reviewing the back-up
log directly in the system via transaction code DB12. Figure
26 shows the backup log history with return code 0000, which
shows that the backup was successful for the period shown.

Figure 26
Overview of a back-up log

A technical review should also cover storage of backup media


and other conventional backup and recovery audit concerns.

Time Zone Setting


The major risk here is that the difference in time zone is
capable of affecting log collection, which consequently affects
correct reporting of firefighting session activities in the satellite
system. The result is erosion of the detective control
capability. The preventive measure is to ensure that the time
zone of the operating system and the SAP NetWeaver engine
are in sync in the SAP GRC system and the satellite systems.
The output of some of the log reports generated for EAM is
based on the input in transaction code STAD (SAP Workload:
Business Transaction Analysis) in the plug-in system. The
reports in transaction code STAD are based on operating
system time. Therefore, it is important that the time zone of
the operating system and the SAP NetWeaver system be in
sync.
If the time zone of the operating system and the SAP
NetWeaver system are not the same, there is a possibility that
Emergency Access Management log reports will show no
records when executedeven though log data actually exists.
Consequently, an auditor will be interested in ascertaining that
the appropriate operating system time zone setting is
maintained in the SAP GRC system and the back-end system.
It is a best practice to have the same setting for:
The time zone of the operating system and the SAP
NetWeaver system in the SAP GRC system
The time zone of the operating system and the SAP
NetWeaver system in the plug-in system (e.g., SAP
ERP system)
However, the time zone setting of the SAP GRC system and
the plug-in system do not necessarily need to be the same.
You can check the time zone setting of the SAP NetWeaver
system via report TZONECHECK (Check Time Zone Data for
Consistency), as shown in Figure 27.

Figure 27
A time zone data report

Note
Time zone settings present a challenge because the
timestamp is assigned to transaction codes committed in the
individual system (i.e., between the operating system level
and the SAP NetWeaver level) and not necessarily across
different systems (e.g., SAP GRC and SAP ERP).
To maintain the time zone settings in your SAP NetWeaver
system, start by entering transaction code STZAC in the
command line. Figure 28 displays with a dialog box.

Figure 28
Dialog box to maintain time zone settings
Click the Yes button. In the screen that appears, maintain the
values for the System Time Zone and Users Default Time
Zone fields (Figure 29). Also, activate the time zone setting by
selecting the Times Zones Active check box. Click the save
icon and restart the instance to activate the new time zone
setting.

Figure 28
Dialog box to maintain time zone settings

Note
For more information on time zone settings in the SAP
environment, you can review the following SAP Notes:
Note 198411: Current data and information about time
zones
Note 481835: Analyzing the time zone settings

Documentation
The last major risk is that a knowledge gap may exist related
to system design, configuration, and operational activities,
which can consequently impact the optimal support of the
system. To prevent this, ensure that documentation
deliverables are agreed upon at the projects inception and
consequently approved by senior management.
Documentations are an integral part of any business solution
delivery, serving as part of the knowledge transfer
requirement. As part of a comprehensive system review
process, it is expected that documentation related to the
project is assessed for completeness and correctness. These
documentations are designed to serve as a reference guide on
the build, design, and operation of the business solution.
Ideally, there should be documentation related to the technical
installation, blueprint and system design, support and
operation guide, security and authorization design, testing
materials, and user guide. More importantly, these documents
must be approved by a designated individual with at least one
representative from senior management or the project steering
committee. This goes a long way toward demonstrating
management commitment to the project.
Also, when changes are made to these documents at different
stages of the project life cycle, you need to approve and
version these changes accordingly. Review the security of
where the documents are stored to gain assurance that they
cannot be tampered with. This document management
capability can be harnessed via SAP Solution Manager.