A case study into the applicability of a good

practice SAP (Access) Security Design

Framework

Dennis Wessing
Post Graduate IT Audit, Compliance & Advisory
Vrije Universiteit Amsterdam
September 2015
Preface
The last 10-15 years, whether or not enforced by stricter legislation (e.g., Sarbanes-Oxley Act of 2002), there is
a significant increase in attention within organizations for internal control and risk management in ERP systems
such as SAP. However, in daily practice, authorizations as part of the internal control within SAP – for the
majority of the organizations - are still not in order. There are undesirable combinations of tasks assigned to
users and relatively many users are authorized to access critical functional transactions or system functionality.
Management has often taken initiatives in the past to redesign the authorization concept. Unfortunately, too
often it appears that problems with granted authorizations have re-emerged after a few years, causing
unwanted segregation of duties conflicts to exist again, users being able to perform (critical and/or sensitive)
tasks they should not be authorized to and authorization management being too costly.

The market has responded in recent years to these issues, causing a variety of integrated access control
applications (such as SAP GRC Access Control1) to be launched. These integrated applications provide extensive
capabilities to manage (emergency) users, roles, and the (automated) assignment of roles to users. In addition,
through the reports and dashboards these applications provide, a clear and single view can be outlined with
regard to access and associated risks of the users.

According to EY2, enabling a SAP GRC AC solution can help organizations:

 lower the cost of access management and related audit activities through centralization and automation;
 improve sustainability by centralizing and standardizing methodologies, processes and components;
 increase effectiveness of access processes through integration with other SAP GRC modules and focus on
critical foundational components such as role design and organizational alignment.

Based on practical experience gained in implementing SAP GRC AC, quite some professional publications have
already appeared in which requirements for a successful SAP (Access) Security Design Framework - or more
specifically the requirements for a successful implementation of SAP GRC AC - are outlined. Most of the times,
these publications are written by the 'Big Four', SAP itself or SAP GRC specialized consultancy firms. The
applicability of a - based on an extensive consultation of available professional and / or academic literature - to
be established Good Practice SAP (Access) Security Design Framework for a case study object represents the
core of this thesis. The case study object involves a large multinational organization.

Graduating from the post graduate IT Audit, Compliance & Advisory (RE) program was an exciting, but
rewarding experience. Without a doubt this study will help me in my career pursuits and has helped me grow
on both a personal as well a knowledge level. This thesis could not have been created without help and
support. Therefore I would like to thank the people who helped me to complete this thesis. First of all, I would
like to thank Mr. Paul Harmzen RA RE my thesis supervisor, for his advice and support throughout the process
of writing this thesis. Second, I would like to thank my in-company thesis supervisor for his advice and time to
review this thesis.

Last but not least, I would like to thank my wife Ingrid and 2 children Merel and Sven, for their unconditional
support throughout my educational pursuits. Your support is invaluable to me.

Zaandam, September 2015

Dennis Wessing

1
From now on referred to as SAP GRC AC.
2
EY (2014): Turning risk into results, enabling access management with SAP GRC.

1
Table of Contents

1 Introduction and Research Question............................................................................................. 4

1.1 Introduction .................................................................................................................................... 4
1.2 Case study object and its programme for the global roll out of SAP ERP ..................................... 4
1.2.1 Background of Case study object .............................................................................................................. 4
1.2.2 Case Study Object’s SAP+ Program: Achieve One Global ERP system ....................................................... 5
1.2.3 Case Study Object and the implementation of SAP GRC AC (integrated with SAP IdM) ........................... 7
1.3 Governance, Risk Management and Compliance (GRC)................................................................ 8
1.4 SAP Security (Solutions), SAP GRC AC and SAP IdM ...................................................................... 8
1.5 Thesis Objective and Research Question(s) ................................................................................. 15
1.6 Scoping .......................................................................................................................................... 16
1.7 Research Methodology................................................................................................................. 16

2 Theoretical framework: SAP (Access) Security Design Components Explained ...............................20

2.1 Introduction .................................................................................................................................. 20
2.2 (I) SAP Security Architecture (Authorization Concept) explained............................................... 20
2.3 (II) SAP Security & Provisioning Processes (including SAP GRC AC) explained .......................... 24
2.3.1 SAP GRC AC processes (modules) ............................................................................................................ 25
2.3.2 SAP Access Risk Analysis (ARA) ................................................................................................................ 26
2.3.3 SAP GRC Emergency Access Management (EAM) ................................................................................... 28
2.3.4 SAP Access Request Management (ARM) ............................................................................................... 28
2.3.5 SAP GRC Business Role Management (BRM) ........................................................................................... 29
2.3.6 SAP GRC AC and SAP IdM integration ...................................................................................................... 30
2.4 (III) SAP Security Organizational Structure & Governance and (IV) Ongoing Management &
Monitoring of the SAP Security Environment explained ........................................................................ 33

3 Good Practice SAP (Access) Security Design Framework ...............................................................36

3.1 Introduction .................................................................................................................................. 36
3.2 Good practices regarding implementation of Access Control and Access Control Applications36
3.2.1 Step 0: Define and Deploy Organizational Change Management Approach ........................................... 40
3.2.2 Step 1: Define SoD Policies and Rule Design ........................................................................................... 41
3.2.3 Step 2: Initial Role and User Design ......................................................................................................... 44
3.2.4 Step 3: Role Build and User Assignment .................................................................................................. 49
3.2.5 Step 4: Role and User Access Risk Analysis .............................................................................................. 51
3.2.6 Step 5: Security Testing and Go-Live Preparation ................................................................................... 55
3.2.7 Step 6: Move to Production and Support ................................................................................................ 56
3.2.8 Step 7: SAP GRC AC Post Go-Live and Ongoing Management & Monitoring of the Security Environment
56
3.2.9 Good practices regarding SAP GRC AC and SAP IdM integration (Step 8: Compliant Identity
Management) ........................................................................................................................................................ 68
3.2.10 Good Practices Based on consulting well-known IT and/or Information Security Control Frameworks 71
3.3 Conclusion ..................................................................................................................................... 73

2
4 Case Study: Applicability of Good Practice SAP (Access) Security Design Framework .....................95
4.1 Introduction .................................................................................................................................. 95
4.2 Case Study: Applicability of Good Practice SAP (Access) Security Design Framework .............. 95
4.2.1 Step 0: Define and Deploy Organizational Change Management Approach ........................................... 95
4.2.2 Step 1: Define SoD Policies and Rule Design ........................................................................................... 96
4.2.3 Step 2: Initial Role and User Design ......................................................................................................... 99
4.2.4 Step 3: Role Build and User Assignment ................................................................................................ 105
4.2.5 Step 4: Role and User Access Risk Analysis ............................................................................................ 108
4.2.6 Step 5: Security Testing and Go-Live Preparation ................................................................................. 113
4.2.7 Step 6: Move to Production and Support .............................................................................................. 114
4.2.8 Step 7: SAP GRC AC Post Go-Live and Ongoing Management & Monitoring of the Security Environment
115
4.2.9 Step 8: Compliant Identity Management ............................................................................................. 119
4.3 Conclusions ................................................................................................................................. 121
4.3.1 Conclusions with regard to Framework Applicability (including Recommended Changes to the
Framework) ......................................................................................................................................................... 121
4.3.2 Key Reasons causing not all Requirements from the Framework being applied .................................. 121
4.3.3 Recommendations and/or Lessons Learned with regard to the Case Study Object ............................. 124

5 Conclusion, Evaluation and Summary ........................................................................................ 129

5.1 Introduction ................................................................................................................................ 129
5.2 Conclusion, Evaluation and Summary........................................................................................ 129
5.3 Recommendations for Future Research .................................................................................... 130

Appendix 1: List of literature ............................................................................................................ 132

Appendix 2: Revised good practice SAP (Access) Security Design Framework (post check) .................. 134
Appendix 3: COBIT 5 on Access Rights ............................................................................................... 159
Appendix 4: Definition of terms applied ............................................................................................ 164
Appendix 5: SAP GRC AC Business Processes ..................................................................................... 165

3
1 Introduction and Research Question

1.1 Introduction
Application security, especially in enterprise resource planning (ERP) systems such as SAP, tends to be complex
and fragmented across organizational silos. Because of the lack of ownership and knowledge of associated
technologies, security controls are often inconsistent and manually enforced. The result is increased and
unnecessary exposure to many risks, including, but not limited to, internal fraud, data breaches, loss of
intellectual property, damage to brand reputation, and compliance violations. According to a Protiviti article3,
decentralized efforts to assign access, reset passwords and update roles in ERP systems are typically
redundant, wasteful and inefficient.

Organizations are vulnerable to fraud and mistakes if they are unable to manage the risk of users having too
much access to business applications. Access risk management describes the set of processes and controls that
are put in place to manage this risk — including processes to manage segregation of duties (SoD) and critical
access, super user access, the compliant provisioning of users, periodic user and role certifications, and the
design and maintenance of compliant roles. To effectively manage access risk, companies must be able to
assess risk not only within each application, but across all applications.

The results of a poorly executed SAP security design process are many: unauthorized access, increased
potential for fraud, inefficient access provisioning for end users, and numerous audit issues. All too frequently,
companies that have not proactively identified and addressed potential security issues face expensive and
challenging redesign projects within one or two years of the initial SAP rollout. This also applies to
organisations that have integrated systems due to mergers or acquisitions or otherwise performed SAP
integrations without an overall SAP security strategy. The pitfalls of a bad strategy not only include frequent
projects to mitigate security exposures, but also a loss in productivity due to loss in granting access.

The case study object is currently rolling out SAP ERP globally4. In addition to rolling out SAP ERP, the case
study object has also chosen to implement SAP GRC AC (SAP GRC AC version 10.0) integrated with SAP
NetWeaver Identity Management5 (SAP NW IdM version 7.2).

The case study object is embarking on a journey to bolster access related controls, the goals of which are to
successfully deliver the following objectives:-
 Case study object’s goal is to manage access risks and conflict of duties for its core business processes:
Proper SoD is a long-established method of preventing fraud and maintaining checks and balances within a
company. However, the recent regulatory focus on public companies has driven businesses to truly
understand what access their employees have within their application portfolio. Control-driven
regulations, like Sarbanes-Oxley in the United States for instance, have not only imposed an
unprecedented rigor around controls, they also underscore the importance of an integrated IT and
financial controls approach to managing risk within a company6.
 Implementation of SAP GRC AC to automate user and role management, and
 Implement a more appropriate SAP Authorisation concept and remove identified conflicts in the SAP
authorization concept by a role re-design.

1.2 Case study object and its programme for the global roll out of SAP ERP

1.2.1 Background of Case study object

Because of confidentiality reasons this thesis has been made anonymous. Hence no detailed background
information can be provided. Case study object is a diversified manufacturing company that is operating
globally. In the previous decennium the company has become a global player by means of a few large

3
Protiviti (2013): SAP-Access-Management-Governance: Getting-It-Right, Making It Sustainable.
4
Global roll out of SAP ERP/ECC (ERP Central Component) within the case study object is actually an ERP instance
consolidation program. In the context of this thesis, this program is called the SAP+ Program.
5
From now on referred to as SAP IdM.
6
Ernst & Young (2010): A risk-based approach to segregation of duties - Insights on governance, risk and compliance.

4
acquisitions. Nowadays the company operates in more than 40 countries across the world and has 60
manufacturing and compounding plants in locations across the world.
For simplicity’s sake, in this thesis I assume the company consists of three major Strategic Business Units
(SBUs)7: SBU ‘A’ which operates in Europe, SBU ‘B’ which operates globally and SBU ‘C’ which operates in the
company’s home country.

1.2.2 Case Study Object’s SAP+ Program: Achieve One Global ERP system
Case study object's investments and acquisitions over the years have resulted in an environment where nearly
1000 legacy systems are used, such as finance/accounting, sales and services, human resources,
manufacturing, and customers/sales systems to manage the organization. Multiple legacy systems make
retrieving and analysing business data, needed for decision-making, a time-intensive activity.

SAP ERP system is one, global business process system that will connect the entire case study organization
together so that information can be retrieved easier to make business decisions; thereby, improving the case
study's profitability and maintaining its competitive advantage in the market. Case Study’s SAP+ Program will
impact around 18,000 employees who will use the system across 40 countries.

An ERP system is the heart of any large company. It enables all the critical business processes, from
procurement, payment and transport to human resources management, product management and financial
planning. All of the data stored in ERP systems is of great importance, and any illegal access can mean
enormous losses, potentially leading to termination of business processes.

The case study object’s SAP+ transformation program would be the largest global organization wide 'Business
Process Transformation' undertaken by the case study object in its history. The primary objective of the
programme is to roll out SAP business processes globally – i.e. rolling out SAP which is already implemented in
SBU ‘C’. No changes will be made to the system unless there is overwhelming reason to do so. Here one should
think of changes that need to be made to preserve an existing competitive advantage. Under no circumstances
the SAP+ program will distort the case study object’s 'SAP practices' processes to preserve old ways of doing
things. The entire thrust of the SAP+ program is to achieve global optimization, not local sub-optimization.
Priority will be given to SBU ‘A’ and ‘B’. All other business units already operate in the SAP system of SBU ‘C’.

The first phase of SAP+ go-live in SBU ‘A’ has been postponed from 1-Jan-2015 to 1-Jun-2015. For SBU ‘B’ in all
geographies the go-live has been postponed to 31-Mar-2016.

In order to understand different challenges that are faced by each of the main case study object SBUs in the
global roll out of SAP, it is crucial to also understand different starting points that characterizes each SBU:
 SBU ‘C’ moving from SAP to SAP+, whereby the design of the already existing SBU ‘C’ system will represent
the starting point for the business blue print discussions that are being held in the other SBUs where SAP+
will be rolled out. Since the objective is to create just one worldwide instance of SAP, this will implicate
that once the other SBUs will go-live with SAP+ this will also impact the end/business users in SBU ‘C’.
 SBU ‘B’ moving from multiple non-SAP legacy systems to single instance SBU ‘C’ SAP+ system: The large
amount of legacy systems implies that different from what occurred at SBU ‘A’ – where a few weeks after
new SAP+ system go-live due to serious problems in the Order-to-Cash process it was decided to roll back
to the legacy SAP system – the actual go-live with SAP+ at SBU ‘B’ is actually irreversible. Also the large
amount of different legacy systems implies that the different end-to-end processes (e.g., Procure-to-Pay,
Order-to-Cash) are far from harmonized. Implementation of SAP+ can therefore also be seen as instrument
to enable such harmonization. It is obvious that this requires an adequate and thorough organizational and
human change management approach to be in place.
 SBU ‘A’ moving from 3 different instances of SAP to single instance SBU ‘C’ SAP+ system: In comparison
to SBU ‘B’, the SBU ‘A’ SAP legacy system was already far more homogeneous with the number of different
SAP instances being limited to three. Each main production site in SBU ‘A’ had its own instance of SAP.

7
A Strategic Business Unit (SBU) is a profit center which focuses on product offering and market segment. A SBU may be a
business unit within a larger corporation, or it may be a business into itself or a branch. Corporations may be composed of
multiple SBUs, each of which is responsible for its own profitability.

5
According to the case study object’s SAP+ Program Board communications, SAP+ allows the case study object
to operate as one global business and it improves the case study object’s competitive position as a world-
leader in the industry. Primary benefits include:
 Improved Decision Making: The case study object can make faster, smarter decisions that impact the
bottom line with easier access to the needed information.
 Increased Productivity: The case study object has more time to focus on core business functions with less
time spent on data entry into multiple systems.
 Simplicity: Interactions with customers, vendors and suppliers within one global system are streamlined.
 Improved Decision Making: The cost of running and maintaining one system is much less than the case
study object is currently spending on over 900 systems.
Furthermore, in other case study object’s Program Board communications, it is assumed that the move to one
global ERP system through the SAP+ project will deliver the following benefits to the case study object:
 One global organization, one language, one method for working
 Standardised platform
 Simplified business analysis
 Stronger image with customers
 Faster sharing of information across geographies, better decisions
 More transactions, handled automatically
 Easier reformatting of jobs, tools, and analytics
 Removal of unsupported legacy systems
 Transparency and greater accountability
 Acceleration to best practices

Below overview shows how the SAP modules (process areas) do integrate with (map to) the case study object’s
business.

SAP+

Figure 1. Overview that shows how the different SAP modules (process areas) do integrate with (map to) the case study
object’s business.

Below overview contains description of the different process areas - equivalent to SAP modules - in scope for
the case study object’s SAP+ project.
Process Area Description

Financial Accounting and
Controlling (FICO)
Investment Management /
Project Systems (IM/PS)
The Financial Accounting (FI) and Controlling (CO) modules provide accurate financial
information for stakeholders and managers to gain valuable insight into business unit
functions and performance.
The Investment Management and Project Systems modules allow management of all
capital investment budgeting and project management activities

6
 Process Area Description

Logistics Execution (LE)
Materials Management (MM)
Plant Management (PM)
Product Lifecycle Management
/ Environmental Health and
Safety (PLM/EHS)
Production Planning (PP)
The Logistics Execution module manages the operative logistical & warehouse
management tasks such as storage, retrieval, packaging, shipping and/or control of
internal transport.
The Materials Management module is the foundation for the procurement of goods
and services throughout the company.
The Plant Management module works on the case study object’s plants and
equipment. Integration with other SAP modules ensures that the data is kept and that
the necessary maintenance processes are automatically triggered in other areas.
The Product Lifecycle Management covers a variety of processes related to raw
materials, and the Environmental Health and Safety module supports the case study
object’s product safety and regulatory compliance processes.
The Production Planning module is used in all industry areas and supports numerous
planning strategies to establish the entire production process.

Sales and Distribution (SD)
Human Capital Management
(HCM)
Quality Management (QM)
Advanced Planning &
Optimization (APO)
Supplier Relationship
Management (SRM)
Figure 2. SAP ERP modules applied within the case study’s object SAP+ project explained
The Sales and Distribution module supports the entire sales process, from contracts
and orders to delivery and invoicing, with important data about products, services and
the case study object’s business partners.
The Human Capital Management module provides a comprehensive industry-leading
HR/Payroll solution.
The Quality Management module covers planning, notifications, inspections, and
reporting and supports ISO 9000’s global standards.
The APO application is at the heart of the Supply Chain Management (SCM) and offers
planning and optimization functionalities.
The SRM module allows users to purchase predefined products from approved
vendors using an on-line catalogue. Users browse through the on-line catalogue,
selecting products and required quantities that are subsequently put into a user’s
Shopping Cart.

To highlight the program utmost criticality and importance and to ensure its success to fulfil the program
objectives, the SAP+ Program senior executive is reporting to the CFO, however he has another reporting line
to the SAP+ Executive Steering Committee that is overseeing the program. SAP+ Executive Steering Committee
is composed of the company’s Executive Vice Presidents (EVP) and is chaired by the CFO. Committed EVP
sponsorship and their line management is seen as a must to drive the change program required in their
organization globally.

1.2.3 Case Study Object and the implementation of SAP GRC AC (integrated with SAP IdM)
The primary risks relating to access security involve unnecessary, unauthorized, conflicting or excessive access
resulting in unauthorized transactions and/or a degradation of the integrity of the underlying application data.
Experience has shown that many security configurations create exposure relating to SoD issues and/or
excessive access to sensitive transactions due to the following reasons 8:
 Application security is intended to ensure that the organization’s personnel are able to perform only the
activities that are necessary to discharge their job responsibilities and to help an organization
appropriately segregate conflicting duties. However, often during the implementation of a significant
application, security is viewed as an enabler instead of a control. That is, as functionality issues arise and
deadlines draw near, many organizations enable increased access to transactions or functions in an effort
to facilitate resolution of problems. This problem-solving approach defeats the primary purpose of
application security, particularly if sustained post-implementation, as is discussed further below.
 Commonly, prior to go-live, “super user” access is activated for implementation members who will serve in
a support function post-implementation. These individuals utilize these roles to quickly diagnose and
resolve problems experienced in the newly implemented application. While the need for these roles is
understandable and easily defended, they compromise effective security and represent potentially
significant control weaknesses going forward.
 During the implementation of an application, not always proper emphasis is placed on access controls. For
example, the integrator relied/relies upon the user to define the security settings and role definitions that

8
Protiviti (2006): Guide to the Sarbanes-Oxley Act: Managing Application Risks and Controls.

7
 are necessary to allow for efficient processing. These situations oftentimes err on the side of too much
access versus not enough.
 Situations arise where the change control and security administration processes are not robust enough to
ensure that the initial intended security design is maintained period after period. Without an effective
general security administration process, the specific security controls at the application-level are
effectively rendered irrelevant over time.

The case study object's vision for improving access to information is to improve security processes by
developing an efficient, sustainable approach for assigning and monitoring access to information systems by
utilizing a risk-based approach, aligned with business processes. Following prerequisites do apply:
• Simple: Rationalize the number of access roles
• Scalable: Standardize processes driving efficiencies and lower costs
• Sustainable: Increase capabilities for governing

In the context of implementing SAP GRC AC, business requirements have been identified and are categorised in
the table shown at the highest level and mapped to the appropriate SAP GRC AC module.

Requirement Category Category Overview SAP GRC 10.0 Module

SoD and critical risk
management
Emergency access to systems
Automated and compliant
user provisioning
SAP roles and authorisations
governance
SoD and critical risk management to provide visibility of risk Access Risk Analysis
exposure created by inappropriate SAP access and provide
assurance to the business that these risks are being
appropriately managed
Safer provision of elevated access to SAP with ability to Emergency Access
monitor the actions of privileged users Management
Automation of provisioning process with enforced Segregation Access Request
of Duties check built into the process. Management
SAP roles authorisations governance and management. Business Role
Enforce role build methodology over the long term and invoke Management
enforced SoD checks into the role development process

1.3 Governance, Risk Management and Compliance (GRC)

Gartner applies following definition of GRC:
GRC is neither a project nor a technology, but a corporate objective for improving governance through more-
effective compliance and a better understanding of the impact of risk on business performance. Governance,
risk management and compliance have many valid definitions.

Furthermore Gartner uses the following definitions to illustrate the relationship of the three terms:
 Governance — the process by which policy is set and decision making is executed.
 Risk Management —the process for preventing an unacceptable level of uncertainty in business objectives
with a balance of avoidance through reconsideration of objectives, mitigation through the application of
controls, transfer through insurance and acceptance through governance mechanisms. It is also the process
to ensure that important business processes and behaviours remain within the tolerances associated with
policies and decisions set through the governance process.
 Compliance — the process of adherence to policies and decisions. Policies can be derived from internal
directives, procedures and requirements, or external laws, regulations, standards and agreements.

The Open Compliance and Ethics Group (OCEG) defines Governance, Risk Management and Compliance (GRC),
as “the capability to achieve objectives (governance), whilst addressing uncertainty (risk management) and
acting with integrity (compliance)”.

SAP’s integrated GRC suite is seen a comprehensive solution that helps organizations manage each area in a
unified way using automation, with monitoring and reporting in real-time.

1.4 SAP Security (Solutions), SAP GRC AC and SAP IdM

The primary risks relating to access security involve unnecessary, unauthorized, conflicting or excessive access
resulting in unauthorized transactions and/or a degradation of the integrity of the underlying application data.

8
Security configurations may create exposure relating to segregation of duties (SoD) issues and/or excessive
access to sensitive transactions due to the following reasons:9
 Application security is intended to ensure that the organization’s personnel are able to perform only the
activities that are necessary to discharge their job responsibilities and to help an organization
appropriately segregate conflicting duties. However, often during the implementation of a significant
application (like SAP ECC), security is viewed as an enabler instead of as a control. That is, as functionality
issues arise and deadlines draw near, many organizations enable increased access to transactions or
functions in an effort to facilitate resolution of problems. This problem-solving approach defeats the
primary purpose of application security.
 Commonly, prior to go-live, "super user" access is activated for implementation members who will serve in
a support function post-implementation. These individuals utilize these roles to quickly diagnose and
resolve problems experienced in the newly implemented application. While the needs for these roles is
understandable and easily defended, they compromise effective security and represent potentially
significant control weaknesses going forward.
 During the implementation of an application, Protiviti has encountered several instances where the proper
emphasis was not placed on access controls. For example, the integrator (implementer) relying upon the
user or client to define the security settings and role definitions that are necessary to allow for efficient
processing. These situations often err on the side of too much access versus not enough.
 Situations arise where the change control and security administration processes are not robust enough to
ensure that the initial intended security design is maintained period after period. Without an effective
general security administration processes, the specific security controls at the application-level are
effectively rendered irrelevant over time.

ERPScan, a global operating Business Application Security provider, has identified three different areas of SAP
Security:10
 Business logic security (SoD): Prevents attacks or mistakes made by insiders
 Custom code security: Prevents attacks or mistakes made by developers
 Application platform security: Prevents unauthorized access both within corporate network and from
remote attackers

The results of a poorly executed SAP Security Design process are many: unauthorized access, increased
potential for fraud, inefficient access provisioning for end users, and numerous audit issues. All too frequently,
companies that have not proactively identified and addressed potential security issues face expensive and
challenging redesign projects within one or two years of the initial SAP rollout. This also applies to
organizations that have integrated systems due to mergers or acquisitions or otherwise performed SAP
integrations without an overall SAP security strategy. The pitfalls of a bad security design not only include
frequent projects to mitigate security exposures, but also loss of productivity due to delays in granting access.
11

SAP Security objectives are as follows:

 Confidentiality: preventing users from viewing and disclosing confidential information
 Integrity: ensure the accuracy of the information in the company's system
 Availability: preventing the accidental or deliberate loss or damage of the company's information
resources.

In below overview, security solutions offered by SAP are shown. In the context of this thesis only SAP GRC AC
and SAP IdM are covered. SAP IdM is covered from the perspective of providing an integrated user provisioning
solution when combined with SAP GRC AC.

9
Protiviti (2006): Guide to the Sarbanes-Oxley Act: Managing Application Risks and Controls.
10
Alexander Polyakov (2014): SAP Security Landscape: How to protect (Hack) your (Their) big business, ERPScan, 21-
October-2014.
11
Protiviti (2014): Designing-SAP-Application-Security: Leveraging SAP Access Monitoring Solutions During SAP
Implementations, Upgrades Or Redesign Projects.

9
Figure 3. SAP Security Solutions: SAP NetWeaver Identity Management (SAP NW IdM), SAP NetWeaver Single Sign On (SAP
NW SSO), SAP GRC AC (SAP GRC AC), SAP ID Services.12

SAP Security is becoming ever more critical due to a constantly evolving compliance landscape and increasingly
complex business environments. Restrictions required by legislation, upgrades to systems, centralization of
functions within businesses and continually changing role responsibilities, increase the importance of having a
well-designed security management process. The increasing complexity of SAP’s software applications, with
evolving technology, new functionality and solutions based on web infrastructure just adds to the risk of
security threats. Ultimately, it is becoming more and more important that organizations can ensure that users
have the information they need in a timely manner while complying with the challenges above in an efficient
and optimal manner.13

To secure SAP, it is not sufficient to rely on appropriate security controls that need to be enforced inside SAP
only. Obviously, the supporting infrastructure needs to be secured as well. Infrastructure security which
comprises the following components14 falls outside the scope of this thesis:
 Network: routers, switches and firewalls
 Server: application server and database server
 PCs/laptops/smartphones: presentation layer of the SAP system

SAP has developed a software solution (SAP GRC) that should help organizations getting an integrated GRC
system. In the basis, the SAP GRC solution consists of following individual modules15:
 Access Control specifically looks at what access people have in an organisation. It may seem basic but with
starters, movers and leavers, appropriate access can be a real concern. Employing proper segregation of
duties, governing enterprise roles, provisioning users, and granting audited emergency access for super
users is key to managing organisational risk.
 Process Control acts as a central control hub that automates tasks, monitors activity and reports in real-
time. It provides a continuous insight into the compliance status of the controls in place across an

12
Henk Peter Wind (2015): SAP Netweaver Identity Management & SAP GRC AC, Integrc, February 12, 2015.
13
PwC (2012): SAP Security Solutions: Is your business protected?
14
Mantran Consulting (2011): SAP Security: Clearing the Confusion and Taking a Holistic Approach, ISACA Singapore, 2
March 2011.
15
This is a simplified representation of reality. In reality, SAP GRC also contains following modules Fraud Management,
Global Trade Services.

10
 organization's business processes, aligning them with risk prevention. In conjunction with well-defined
controls that eradicate duplication and simplify assurance, SAP GRC Process Control can become a
powerful capability.
 Risk Management helps organizations integrate and coordinate risk management activities, gain a deeper
understanding of risk, and plan timely, reliable responses. It provides insightful information to help
organizations manage risk in a responsible way. Additionally, it helps organizations assess threats and
opportunities, so they can make better decisions to positively impact the performance of their business.

Below overview shows SAP solutions for Governance, Risk Management, and Compliance:16

SAP Access SAP Process SAP Risk

Control Control Management

Manage access risk Ensure effective Preserve and

and prevent fraud controls and ongoing grow value
compliance

Figure 4. SAP Solutions for Governance, Risk, and Compliance

PwC17 has identified following benefits of implementing SAP GRC:

SAP GRC AC SAP Process Control SAP Risk Management

• Real-time analysis of SoD and
sensitive access violations.
• Transparency of access risks.
• Self-service access requests and
password resets.
• Streamlined user and role access
reviews.
• Centralized audit documentation.
• Super user access management
(mitigates the most common audit
issue).
• Customizable methodology for role
definition.
 Preventative compliance.
• Protecting investment through
developing a way to sustain newly
designed processes and controls.
• Optimize controls through
rationalization, improving control
process efficiency and further
automation of controls.
• Centralized reporting and better
visibility through documenting and
testing controls once and sharing
assurance across departments.
• Integrated compliance
management through developing a
centralized multi-compliance
framework.
• Supporting the transition “above
market” through effective
management of controls from
central functions and shared service
centers.
• Reduced cost of internal and
external assurance through
improved integration of audit
efforts.
• Transform Risk Management
process from a silo approach to a
more coordinated and oriented
approach.
• Consolidate risks at higher levels of
the organization and evaluate
global risk exposure.
• Respond intelligently by focusing on
key risks, creating cross-
organizational resolution strategies,
and tracking response costs.
• Improve visibility and optimize
decision making by aligning risks to
strategic priorities and business
objectives (enhance risk
communications to the board).
• Monitor key risks in a proactive way
through a standardized and
centralized Key Risk Indicator
framework.

16
Protiviti (2014): Optimizing User Administration in SAP, ISACA Geek Week – Atlanta, August 13, 2014.
17
PwC (2012): SAP Security Solutions: Is your business protected?

11
SAP GRC AC application is being implemented by the case study object to:
• Effectively manage security, segregation of duties (SoD) and privacy across the case study object’s global
SAP environment.
• Effectively manage and automate applicable components of user provisioning / security administration for
SAP.
• Enhance the effectiveness and appropriateness of the case study object’s SAP security architecture.
• Identify and remediate existing security and SoD violations in the case study object’s SAP production
system.
• Establish an effective process for proactive identification and remediation of security and SoD violations
for the different SAP implementation projects within the case study object.
• Encourage transparency and accountability, as it relates to SAP security, SoD and access to sensitive data.

According to ISACA report issued by Coca-Cola Company18, use of SAP GRC AC gives visibility into SoD issues,
inheritance issues, and can prevent the assignment of roles that create issues:
• Ability to validate that no violations of an SoD rule set exist within single roles
• Identify and review sensitive access assigned to users
• Workflow can be implemented to require risk analysis to be completed prior to new role assignments
(preventative control)

SAP IdM provides a comprehensive solution for managing user accounts and privileges across enterprise
landscapes. Appropriate Identity Management ensures that the right users have the right access to the right
systems at the right time across all systems and applications. Business drivers for Identity Management are
shown below:19

Figure 5. Business Drivers for Identity Management.

Below overview shows the Identity Lifecycle:

18
ISACA (2012): Auditing SAP GRC (The Coca-Cola Company), ISACA-August 17, 2012.
19
SAP (2014): SAP Identity Management: Overview, October 2014.

12
Figure 6. Identity Lifecycle.

Below overview shows a comparison of the key features of both SAP GRC AC and SAP IdM user provisioning
solutions20. Through green or red coloring I have indicated which pros (colored in green) or cons (colored in
red) do differentiate both solutions from each other.

Different areas for user
provisioning
Managing Identities: support
Identity Lifecycle Process
Managing Roles
Password management / Self
Services
Workflow and provisioning
SAP GRC AC (SAP GRC AC)
 Per System
 Link to AD (Active Directory)
 Possible link with SAP CUA
(Central User Administration)
 Possible link with HR system
 Role management for ABAP22
roles on detailed level
 Define attributes per role
 Business roles across systems
 SoD checking on role level
 Password Self-service
 Customizable request forms
 Workflows for:
- user management
- role management
SAP NetWeaver Identity
Management (SAP NW IdM)
 Central user repository
 Link to and update AD
 Synchronize across systems
 Possible link with HR system
and other source systems
 Identity Federation21
 Import roles per system with
flexible role mapping
 Define attributes per role
 Business roles across systems
 Password Self-service /
Password synchronization
 Link to support tool
 Custom request forms
 Customizable workflow
 Flexible workflow approval
steps

20
Henk Peter Wind (2015): SAP Netweaver Identity Management & SAP GRC AC, Integrc, February 12, 2015.
21
Identify Federation allows the end users to use the same set of credentials to obtain access to multiple resources. This
gives an advantage to the software systems that utilize Identify Federation, both from security and usability perspective –
the end users do not have to maintain multiple sets of credentials. Yet, the users have to provide their credentials to each
one of the participating resources. SSO (Single Sign On), on the other hand, allows the end users to provide their credentials
once and obtain access to multiple resources.
22
ABAP (Advanced Business Application Programming) is a high-level programming language created by SAP. It is currently
positioned, alongside the more recently introduced Java, as the language for programming the SAP Application Server, part
of its NetWeaver platform for building business applications.

13
 Different areas for user
provisioning
Compliance, reporting and
auditing
Connectors and integration
SAP GRC AC (SAP GRC AC)
- emergency access
management
 Flexible workflow approval
steps
 SoD analysis in workflow steps
 Automatic or manual
provisioning
 SoD analysis and simulation on
detailed (transaction/object/
field) level for users and roles
 Mitigating controls
 Emergency Access Management
 Reporting and dashboards in
GRC AC
 Reporting for user/roles on
connected systems
 SAP BW (Business Warehouse)
content
 Integration with SAP GRC
Process Controls and Risk
Management
 Standard connectors available
for number of ERP systems
 Custom connectors need third
party support (Greenfield)
 Connectors provide
functionality for (detailed) SoD
analysis and provisioning
SAP NetWeaver Identity
Management (SAP NW IdM)
 Assignment of context
dependent roles
 Automatic or manual
provisioning
 No detailed SoD checking
 Check possible based on
conflicting role matrix
 Flexible customizable reporting
facilities
 Link to BW for reporting
 Connectors available for large
number of non-SAP systems
 New connectors easy to define
 Connectors give no support for
SoD checking
 Supports multiple standard
protocols

Below overview23 shows the different roles that both SAP Security solutions (i.e., SAP GRC AC and SAP IdM) do
have and how they complement each other: SAP GRC AC very much focused at the business layer (business
controls) and SAP IdM focusing on the IT infrastructure (system(s) access).

23
Henk Peter Wind (2015): SAP Netweaver Identity Management & SAP GRC AC, Integrc, February 12, 2015.

14
Figure 7. Different roles that SAP Security solutions ‘SAP GRC AC’ and ‘SAP IdM’ do have.

1.5 Thesis Objective and Research Question(s)

Main objective of this thesis is to:
Develop a 'good practice' framework for SAP (Access) Security Design and assess/ validate the applicability of
this framework by means of a case study. Case study object is represented by a large multinational firm
which is currently rolling out SAP ECC (one instance) and SAP GRC AC globally. Outcome of this assessment
will be:
• The identification of reasons and/or practical problems that (might) hinder the application of the SAP
(Access) Security Design framework by the case study object;
• A conclusion with regard to the applicability of the SAP (Access) Security Design framework to the
specific case study object;
• An overview of modifications that need to be made to the developed SAP (Access) Security Design
framework;
• A set of recommendations for the case study object itself
Main focus will be on SAP (Access) Security Design with regard to the different type of SAP Security Processes
(access controls processes) and the ongoing Management & Monitoring of the SAP (Access) Security
Environment.

Main research question is as follows:

To what extent is the 'good practice' framework for SAP (Access) Security Design - that will be developed on
the basis of a literature study - applicable to the case study object, what are practical problems in applying
the framework to the case study object and which modifications to the framework can/should be made
based on the outcome of the assessment/validation into the applicability of the framework?

Derived from the above, following sub questions have been defined:

1. According to professional literature and academic literature research, what is SAP (Access) Security Design,
what are the main building blocks for SAP Security Design and how does SAP GRC AC software application
and related access controls processes fit in such a design?

2. According to professional literature and/or academic literature research, what are considered good
practices with regard to key components of an effective SAP Security Design:
 SAP Security Design: SAP Authorization Concept
 SAP Security Processes: User Provisioning, Role Change Management, Emergency Access
 SAP Security Organizational Structure & Governance: Ownership, Policies, and Accountability

15
  Ongoing Management & Monitoring of the Security Environment: KPIs, Recertification24, “Get Clean &
Stay Clean”
 Implementation of SAP GRC AC.
Deliverable from answering these sub questions will be a 'good practice' framework for SAP (Access)
Security Design and related to this the implementation of SAP GRC AC application.

3. To what extent is the good practice SAP (Access) Security Design Framework applicable to the case study
object? The outcome of the assessment/validation into this applicability should provide an answer to the
following questions:
 What can be concluded with regard to the applicability of the SAP (Access) Security Design framework to
the specific case study object?
 What kind of reasons and/or practical problems can be identified, which (might) hinder the application
of the SAP (Access) Security Design framework by the case study object?
 Are there any modifications to be made to the developed SAP (Access) Security Design framework that
may enhance the framework and/or its applicability?
 Which recommendations can be made with regard to the case study object itself?

1.6 Scoping
As indicated in section 1.4, scope of this thesis is around security controls in SAP. Infrastructure security
controls are not in scope. Regarding security controls in SAP the following type of controls are also not in scope
in this thesis:
 Basis Controls: these controls represent the technical controls in SAP itself. Basis controls do include
password controls, user administration, privileged users, auditing, change controls, batch job
management, and direct access to data through tables.25
 Business Process Controls: these controls refer to automated and (IT dependent) controls available in SAP
for various business processes such as purchasing, sales, financial reporting, inventory, HR, etc. Business
Process Controls can be broadly classified under the following three categories:
 Inherent controls: enforced by default in SAP (e.g., sales order cannot be created with invalid
customer)
 Configurable controls: 'switches' that can be set by turning them on or off based on the business
requirements (e.g., tolerance limits for three way match, PO approval hierarchy)
 Procedural controls: IT dependent controls (e.g., review of exception reports)

In conclusion, scope of this thesis is restricted to processes and related controls that ensure:
 Access to conflicting duties, critical activities and sensitive activities/access are controlled;
 User access is appropriate (i.e., based on their roles and responsibilities);
 Roles are appropriate (i.e., authorizations within roles are as per the role definition).

1.7 Research Methodology

The method and structure applied in this thesis – and therefore the basis for answering the main research
question and the derived sub-questions - follows the research approach of Robert K. Yin, described in the book
"Case study research, design and methods”26. The case study method is particularly interesting when the
studied phenomenon is: not clearly or not sufficiently theorized and/or complex (several actors, assignments,
procedures, goals, etc.). For the subject of applicability of a 'good practice' SAP (Access) Security Design
framework, both criteria are met.

Furthermore, the case study typology chosen can be seen as a combination of a single case design and an
embedded (multiple units) case study. Embedded case study analysis focuses on different sub-units of a
specific phenomenon (e.g., SAP Access Security Design consists of several components or sub-units), which is

24
Recertification: Periodic certification of authorizations by conducting periodic user-access reviews and ensuring SoD
mitigations are effective on a regular basis.
25
Mantran Consulting (2011): SAP Security: Clearing the Confusion and Taking an Holistic Approach, , ISACA Singapore, 2
March 2011.
26
Yin R. (2014): Case Study Research: Design and Methods, 5th edition (first edition, 1984), Sage, Los Angeles.

16
especially useful to confront rival interpretations and strengthen internal validity. According to Yin27, single
case design is appropriate when the case is (i) critical to test a specific theory with a clear set of propositions
(e.g., good practice SAP Access Security Design framework that is to be developed from the literature research)
and (ii) representative of a situation (e.g., large multinational organization that is rolling out SAP ERP and SAP
GRC AC globally).

Finally, the case study typology applied in this thesis can be regarded as a combination of an exploratory case
study and a confirmatory case study. The purpose of an exploratory case study is to better understand an
emerging phenomenon and/or to propose new theoretical insights to generate new ideas and hypotheses. Also
the case for applying an exploratory case study is particularly strong when existing theories are incomplete or
unable to provide a satisfactory representation of the studied phenomenon. The purpose of a confirmatory
case study is to evaluate the robustness or the weakness of a clearly defined theory (or theoretical conjecture).
A conflicting case might be used to falsify a theory by giving examples of events contradicting some theoretical
statements. The falsified theory, in a specific context, must then be modified.

Below overview shows the different phases in the case study research methodology of Yin:

Figure 8. Case Study Research Methodology.

1) Plan: this phase includes the determination of the main research question and sub questions, the research
methodology applied in this thesis as well as the scoping for the research.

2) Design: this phase comprises the literature research that provides the input for the design of a good
practices SAP (Access) Security Design framework. Literature research comprises both academic (scientific)
and professional literature around SAP Security Design and the 4 main components 28 of SAP Security
Design. Outcome of this part of the literature study has delivered input for both the Theoretical
Framework section (Chapter 2) as well as for the section in which 'good practices' framework for building
and/or maintaining an effective SAP Security Design is developed (Chapter 3). As part of consulting
academic and professional literature, I have also considered good practice approaches around the
implementation of SAP GRC AC and related access controls processes.
Whilst searching the Internet for relevant professional and academic literature with regard to SAP (Access)
Security Design and its underlying components, it appeared that available literature was almost entirely
limited to professional literature and that vast majority of these 'professional' articles and presentations
were issued by the Big Four Audit Firms, SAP itself and a few smaller niche players who are operating in –
subfields in - the GRC working field and/or SAP Security (e.g., InteGRC 29, Protiviti, ERPScan). Very few
academic literature sources - that cover scientific research on the subject of SAP (Access) Security Design -
that are available, were mainly restricted to thesis papers for post graduate IT Audit courses at different

27
Yin R. (2014): Case Study Research: Design and Methods, 5th edition (first edition, 1984), Sage, Los Angeles.
28
Four main components of SAP (Access) Security Design is being referred to in sub question 2 in § 1.5
29
In June 2015, InteGRC was acquired by EY.

17
 universities in the Netherlands. Also worth mentioning is that vast majority of the literature I have found
and used for this thesis, was actually issued from 2013 onwards. From this, it can be concluded that SAP
security is (i) gaining more and more attention in professional literature – albeit the number of resources
still being very limited – and (ii) not yet receiving any significant attention from a scientific research point
of view. In combination with my observation that the number of professional articles issued seems to
accelerate in the last 1-2 years, I do note that SAP Access Security Design is apparently an emerging
phenomenon.
In addition to the literature research, input for the framework has also come from:
- A reference visit to DSM to obtain understanding of the SAP GRC AC approach applied as well as lessons
learned regarding the implementation, the immediate post go-live (support) phase and the live &
maintain phase within the global DSM organization.
- A 3 day visit to the SAP GRC conference in Nice (June 16 to 18, 2015) which was organized by SAPInsider
and where I have attended several workshop sessions and where several SAP GRC AC case studies were
addressed.

3) Prepare: this phase mainly consists of the choice and design of a proper methodology to assess the
applicability of the good practice SAP (Security) Access Design framework at the case study object.
Framework resulting from the design phase (literature research) will be set up as a number of (preliminary)
good practices and /or requirements per key component of an effective SAP Security Design.
Subsequently, applicability of these good practices/requirements will be validated/assessed through the
following different research methods:
- Literature research: case study object specific documentation has been consulted to obtain a better
understanding of the applicability of the good practice SAP (Access) Security Design framework, whether
any modifications need to be made in the good practices framework and which recommendations can
be made with regard to the case study object itself (with regard to the global roll-out of respectively SAP
ERP, SAP GRC AC, an integrated SAP GRC AC – SAP IdM solution and related access control processes).
- Participant-Observation: Within the case study object/organization's Enterprise Risk Management
(ERM) department, I do have a coordinating and driving role to ensure SAP GRC AC and related access
controls processes are properly designed and implemented across the global organization. Having this
real-life role in the scene being studied also has provided me with valuable input that I have applied in
this thesis. The observations that I have as a participant in the SAP GRC AC global roll out project have
supported me in collecting data that is required to answer the research questions around the
applicability of the framework.
- Interviews: The interview method has been used to test the good practices/requirements from the
framework among experts in the field within the case study organization. Because of the anonymous
nature of this thesis an overview of the persons who have been consulted along with their roles has
been left out in this document. Through my role in the SAP GRC AC project within the case study object,
frequently I am liaising with a variety of stakeholders (e.g., Business Process Owners in all main SBUs, IT
Security, IT Functional Team leads, PMO, Internal and External Auditors).

4) Collect: this phase comprises the collection of qualitative data and evidence from the literature research,
participant-observation and interviews research methods referred to above. During the collection period -
which covered the period from Nov-2014 to Aug-2015 - a good balance has been safeguarded between
obtaining input from individual experts through 'interviews' with case study experts versus obtain input
through case study 'literature research' and my own 'participant-observation'. Where necessary,
adjustments are made in the research methods applied.

5) Analyse: this phase contains a detailed analysis of the qualitative data collected in the previous phase.
Data analysis will performed to validate/assess the applicability of each recommendation and/or
proposition from the good practice framework. The analyse phase (which will be addressed in chapter 4
and 5) will provide input for:
- the identification of any reasons and/or practical problems that (might) hinder the application of the
SAP (Access) Security Design framework by the case study object;
- (preliminary) conclusions with regard to the applicability of the individual recommendations/
propositions that underlie the SAP (Access) Security Design framework, as well as a (preliminary)
conclusion with regard to the overall applicability of the framework;

18
 - the identification of any modifications that need to be made to the developed SAP (Access) Security
Design framework;
- a preliminary set of recommendations for the case study object itself
As an additional quality control, preliminary results of the 'analyse' phase will be aligned with some experts
within the case study object. Especially when there are significant deviations between the requirements
from the good practices framework versus the practices that are being applied within the case study object
itself, then additional (individual) interviews will be held to align on these deviations. The amount of
additional interviews required (as well as the selection of specific interviewees), largely depends on the
outcome of the analysis.

 Share: this phase involves sharing the results of the - preliminary - results of the analysis phase with the
case study object interviewees. Sharing also comprises aligning with experts within the case study object
on the - feasibility of - the recommendations that can be made with regard to the case study object itself.
Based on such alignment sessions, recommendations may have to be rewritten to ensure practicality of
the recommendations for the case study object itself. Finally, this phase also covers coming up with useful
ideas for scientific research around a good practice SAP (Access) Security Design framework and the
applicability of such a framework in other businesses.

19
2 Theoretical framework: SAP (Access) Security Design Components Explained

2.1 Introduction
At its most fundamental level, SAP (Access) Security Design refers to the architectural structure of SAP security
roles (see §2.2 SAP Security Architecture). However, effective security design cannot be achieved solely by an
appropriate SAP Security Architecture. An effective security design to be truly achieved and maintained,
requires the convergence of role architecture as well as:30
 SAP Security Processes (see §2.3): User Provisioning, Role Change Management, Emergency Access
 SAP Security Organizational Structure & Governance (see §2.4): Ownership, Policies, and Accountability
 Ongoing Management & Monitoring of the Security Environment (see §2.4): KPIs, Recertification, “Get
Clean & Stay Clean”
Below overview shows adverse effects and/or potential flaws that might occur due to an inadequate and/or
ineffective design in one or more of the four main components ('building blocks') of the SAP Security Design.
Components referred to above/below also represent the section layout for explaining the different SAP
Security components.

• Misalignment of IT vs Business
Objectives
• User provisioning process with insufficient • Lack of strategic security design
automation & information Org decisions
• Role Change Mgmt lacks risk and quality Structure &
Governance • No role or security design ownership
controls Security &
Provisioning (§2.4)
• Inefficient emergency support process Processes
(§2.3) • Overly complex Security Design
• Lacks flexibility to respond to on-going
SAP Security
changes
Architecture
• Management KPIs for Security Design are (§2.2) • Lacks scalability to grow with
not established organization
• Lack of automation for ongoing monitoring • Inefficient role build approach
& recertification procedures
• No documentation of security control
• Insufficient SoD and/or Mitigating control points
frameworks
• Inherent Segregation of Duties risk

Management (§2.5)
(§2.5)
Figure 9. Building Blocks for an Effective SAP Security Design.

2.2 (I) SAP Security Architecture (Authorization Concept) explained

Security within the SAP application is achieved through the authorization concept. The authorization concept is
to help establish maximum security, sufficient privileges for end users to fulfil their job duties, and easy user
maintenance.
The authorization concept of SAP represents the fundamental security function of the system. All relevant
security functions are controlled via the authorization concept, as for example the adjustments of system
modifications or the segregation of duties within the modules. The main principle, on which the concept is set
up, is the protection of individual fields. Every SAP users works with screens that again consist of several fields.
It should not be possible for every user to have unrestricted access to all fields including all potential values.
The users should only get access to the fields in a way that this complies with a work related need. This way
fields are protected from unauthorized access.

30
IIA Los Angeles SAP Security Presentation, PwC, March 2015.

20
With regard to this, authorization objects were created in the SAP system that again were laid over the
individual fields, the same as a mask. This mask can exist of up to ten fields. In this mask, the options that will
be assigned to the user are maintained. Example below shows an analysis of an authorization object:
Authorization Authorization Authorization Description
object field value
F_KNA1_BUK ACTVT BUKRS 03 Determination activity

$BUKRS Determine in which company code dependent part of the master

data, the activity defined ahead, may be executed.
In the above example an authorization object is listed that controls the access to the company code data of the
general customer master data. This authorization object consists of two fields. First, the field ACTVT, in which is
determined which activities may be executed. In this example, 03, a display authorization is established. The
second field BUKRS, enables that the access is only provided to selected company codes with the assigned
activity. The company codes can be explicitly entered to this field, for example 0001.
Are the just named values assigned to the authorization object, then the field company code can only be
brought to display for the company code 0001. With the assignment of values to the participating fields in this
authorization object, an authorization to this object is created. SAP works transaction controlled. That means
that basically every application within SAP is represented by a transaction.
To every authorization object, an unlimited number of authorizations can be created, resulting from the
diverse combination possibilities of the field values with one another. An authorization cannot be assigned
directly to a user instead authorizations are collected in a profile. The profiles, in which authorizations are
collected, are also called single profiles. Starting with the profile level, an assignment to users can succeed. SAP
allows furthermore that profiles may be combined in composite profiles. In composite profiles, no
authorizations are combined, only other profiles. The most well-known composite profile is the SAP_ALL
profile, which contains all authorizations of the SAP system. Composite profiles are assigned to users, just like
single profiles. The users then receive all authorizations that are contained in the profiles of the composite
profiles.
A role is similar to a container for one or more profiles that are generated and contain the defined
authorizations. Roles may be combined as composite roles. Roles as well as composite roles may be assigned to
users.31

Below overviews both explain the main components of the SAP Authorization Concept:

Figure 10. Main Components of the SAP Authorization Concept.32

31
Marie-Luise Wagner (2008): Practical Guide for SAP Security, SAP.
32
IIA Los Angeles SAP Security Presentation, PwC, March 2015.

21
 Transaction
code

Authorization
object

Authorization

Composite
Role Profile
profile

Composite role User

Figure 11. The elements of the SAP Authorization Concept.33

The decisive components of the authorization concept are:

 Authorization objects: For objects that are to be protected, as applications within SAP, there are
authorization objects created. These objects contain fields that are meaningful to protect, and that can be
restricted within the authorizations, that are created based on the respective authorization objects. All the
relevant elements are already equipped from SAP with authorization objects per default. Additional
authorization objects should only be developed for company specific developments.
 Authorizations: An arbitrary number of authorizations can be created based on every already existing
authorization object. They are the actual carriers of the access key. Here also, authorizations are delivered
by SAP per default that is not limited on any organizational level.
 Profiles: SAP delivers standard profiles for all typical tasks within the SAP environment. Single and
composite profiles will be distinguished; the last-named contain again further single or composite profiles.
Included in the profiles are the necessary authorizations for the individual concept task.
 Activity Groups/Roles: An activity group represents a collection of activities that describe a certain
working area. It contains transactions as well as reports and can be extended through the generation of a
user menu. A role is a release dependent synonym for an activity group. Activity groups can be combined
in composite activity groups, roles in composite roles.
 User master data: User master records have to be created and managed individually in every client,
provided with authorization profiles or transported from the test client into the production client. No users
exist per default, other than some SAP standard users like for example SAP* and DDIC34.

Below overview shows the basic SAP Authorization Concept which consists of three levels of security in SAP:35

33
Marie-Luise Wagner (2008): Practical Guide for SAP Security, SAP.
34
User DDIC is a user with special authorizations for installation, software logistics, and the ABAP dictionary.
35
IIA Los Angeles SAP Security Presentation, PwC, March 2015.

22
Figure 12. SAP Authorization Concept: Three levels of security in SAP.

Below overview shows the standard authorization structure within the SAP authorization concept:36

SAP is delivered with

about 1500 authorization
objects

An object is a structure
provided by SAP to grant
access to a data element
or a task in a specific
content.

Figure 13. SAP Authorization Concept: Authorization Structure.

When a user logs onto SAP, all the authorization objects and fields that have been assigned to them through
roles and profiles are loaded into their “user master” record. When a user attempts to execute an action in
SAP, the authorization objects and fields from the user master are checked programmatically. Within the fields
of the authorization objects a user can among others be restricted to (many other restrictions are based on
individual object):
 Display vs. Maintain
 Specific items classified by company codes (or many other groupings)

36
IIA Los Angeles SAP Security Presentation, PwC, March 2015.

23
Many organizations struggle with managing authorizations in SAP. Assigning authorization roles and preventing
segregation of duties conflicts are for many organizations, a time-consuming, complex and last but not least
costly exercise. Common problems include:37
 presence of a large quantity (unknown) and not mitigated segregation of duties conflicts within the SAP
system;
 authorizations not in line with the functions and responsibilities in the organization;
 managers and other "special" users having too wide authorizations.
In general, these problems can be traced to the following causes:
 insufficient understanding of the contents of SAP authorization roles (this applies to both the business as
well as the IT organization;
 insufficient recognition of the SAP authorization roles;
 insufficient insight into the assigned SAP authorizations;
 insufficient insight into impact of (organization) changes on SAP authorizations;
 insufficient insight into segregation of duties and segregation of duties conflicts;
 lack of ownership with regard to control measures;
 responsibilities within the organization have not been allocated and / or defined, so it is unclear who is
allowed to do what in the SAP system;
 lack of knowledge with regard to SAP authorizations in order to prevent and solve 'problems', coupled with
the complexity of the SAP Authorization concept;
 lack awareness/knowledge of risks within business processes among staff;
 non-compliance and/or bypassing (time-consuming) procedures;
 insufficient attention for SAP authorizations in case of changes (in IT and organization).

2.3 (II) SAP Security & Provisioning Processes (including SAP GRC AC) explained
To describe authorization management, I use the definition of Fijneman et al:38
“Authorization management comprises all activities related to defining, maintaining, assigning, revoking and
overseeing or monitoring authorizations in the system.”

The authorization management process can be divided into the following sub-processes:
 User Management: All activities, including controls, for the provisioning and revoking of authorizations as
well as the registration of the user in the system. The registration of the user is performed on the basis of
source data, which is recorded, for example, in a HR system. User management also comprises the issuance
of passwords and management of special users, such as system and emergency users. In some cases an
additional separation is applied within user management, where the provisioning and revoking of powers is
referred to as "Access Management" and the registration of users as "User Management. Also the periodic
assessment of the assigned authorizations are an important element of user management.
 Role Management: All activities, including control measures to define and maintain authorizations within
the system by making available authorization roles. The role management process has a strong correlation
with the IT change management process, and also here periodic monitoring of the content of the
authorization roles is of importance.
Assigning authorizations to a person or to objects in a SAP system often occurs on the basis of previously
reached agreements in (for example) a company policy. These agreements are generally made by management
and are almost always focused on ensuring that risks or threats to an organization are mitigated to an
acceptable level.
Authorizations are also part of the internal control of an organization. In relation to internal controls and
authorizations, often the concept of segregation of duties is used. Segregation of duties is based on the
principle that conflicting interests are created within an organization with the aim of preventing one single
person being able to perform several (critical) sequential tasks within a business process. One individual being
able to perform such (critical) sequential tasks can lead to (intentional / unintentional) irregularities that are
not detected timely and/or not detected over the normal course of (the) business (process). For an
organization, it is important to identify any segregation conflicts and take action.

37
Drs. Ivan Spruit, Jasper Schutte MSc en Sander van der Zon MSc (2013): Access Control applicaties voor SAP, KPMG, ,
Compact, 2013-3.
38
Fijneman, Roos Lindgreen en Veltman (2005): Grondslagen IT Auditing, Fijneman, Roos Lindgreen en Veltman.

24
2.3.1 SAP GRC AC processes (modules)
SAP GRC AC is an access governance solution that automates the processes associated with managing access to
business applications. SAP GRC AC supports processes and audit records that track who has access, who
approved access, when access was granted, and if the access assignments are still required.
SAP GRC AC is designed to bridge the gap between obtaining the technical definitions of system authorizations
and facilitating the process of associating the correct system authorization or entitlement with the appropriate
user. SAP GRC AC includes the following four (five) modules to accomplish this:39
 Access Request Process – integrated workflow process to orchestrate approvals, SoD analysis, account
actions (i.e. create, delete, lock, unlock, etc.), and automated role assignment
 Risk Analysis and Remediation – enables analysis of Segregation-of-Duty (SoD) violations by role, business
process through ad-hoc queries or integrated with the access request. The integrated risk analysis enables
stakeholders to resolve conflicts and reduce risk by mitigating the violation by changing the role assignment
or through a mitigating control.
 Business Role Management – supports management of SAP technical and business role lifecycle
management. SAP Business Role Management enables the centralized management of SAP technical roles
across multiple systems using a role methodology. This process ensures that roles are subjected to
appropriate testing and approvals prior to deployment. Business roles in SAP BRM are groups of
entitlements that can be associated with job functions for easily assignment to business users.
 Emergency Access Management – a complete solution for managing access for privileged user access with
integrated monitoring and log review.
 (User, Role, and Risk Certification – supports a periodic review process for existing user assignments, role
definitions, and access risks required by several compliance regulations).
Detailed context of the activities that will be executed by various organizational users in SAP GRC AC on a day-
to-day basis (for each of the four modules) are shown in appendix 5.

SAP GRC AC is built on SAP ABAP technology and is supported using standard SAP basis and transport
processes. SAP GRC AC is intentionally built as a stand-alone solution to support integrated compliance and
access provisioning for SAP ERP systems. In brief, SAP GRC AC application enables organizations to manage
segregation of duties (SoD), critical and sensitive access, and super user access effectively and efficiently. It
automates the compliant provisioning of users, periodic user and role certifications, and the maintenance of
compliant roles. SAP GRC AC is an application that helps manage access risk and prevent fraud. See below
overview:40

Figure 14. SAP GRC AC application explained.

39
Swetta Singh, Chris Radkowski, Keith Grayson (2012): How to leverage SAP NetWeaver Identity Management and SAP
Access Control combined solutions, SAP Solution Management, December 6, 2012.
40
Erwin Albers (2015): Rethinking Segregation of Duties: Where Is Your Business Most Exposed?, SAP Netherlands.

25
In conclusion, SAP GRC AC consists of 4 interacting modules, which are depicted in overview below41. In this
overview also the name of each module is shown (both for SAP GRC AC version 10.0 and version 10.1).

10.0 Emergency Access

Management

10.1 Emergency Access 10.0 Access Risk Analysis

10.1 Analyse Risks

10.0 Business Role

Management
10.0 Access Request
10.1 Manage Roles Management

10.1 Compliant Access

Figure 15. SAP GRC AC submodules explained (SAP GRC AC release 10.0 versus SAP GRC AC 10.1)

2.3.2 SAP Access Risk Analysis (ARA)

SAP Access Risk Analysis (ARA) is the SAP GRC AC reporting tool that will provide organizations with a real time
position of Segregation of Duties (SoD) and critical risk conflicts across connected systems. Table below
provides an overview of the module and its business benefits to organizations:42
Module Module Overview Business Benefits

SAP Access • ARA leverages a set of
Risk defined rules to identify
Analysis access risk exposure
(ARA) within SAP/Non SAP
technical roles.
• The module provides a
number of reports that
can be used to benchmark
metrics and identify access
risks at user, role, profile
and user group level.
Reduce time evaluating requests by:-
• Real time SoD check, or as frequently as required
• Alleviating the need for manual human intervention in SoD compliance
checks - instead the risk analysis can be handled automatically and
would only require approval or rejection from the Responsible Owner
• Integration with provisioning module (ARM) to prevent access
requests from being approved if an access risk is identified
Provides functionality to improve visibility of potential fraud risk and
control over access, helps resolve these access issues and ensures that
they are not re-introduced by
• Identifying access to critical roles or transactions
• Reducing requirements for further full reviews and redesigns
• Highlighting unacceptable SoD to be removed from current roles
and/or users
• Ensuring on-going compliance through automated risk analysis during
user provisioning to prevent SoD being created
Better reporting of access risks through integration with reporting tools
by:-
• Simplifying and combining all risk and control information into
Dashboards for easier interpretation by senior management
• Identifying changes in access risk over time and across divisions

Access Risk Analysis – Ruleset

41
Erwin Albers (2015): Rethinking Segregation of Duties: Where Is Your Business Most Exposed?, SAP Netherlands.
42
Fahri Batur (2013): Access Control Product: High Level Design, InteGRC, 4th November 2013.

26
The core engine of ARA is its ruleset. The ruleset is used to report on SoD and single sided risks at the role,
profile, user and user group level. The ruleset is made up of multiple groupings of transaction codes and
authorisation objects across a set of business processes that companies will monitor in the form of risks. The
ruleset is effectively a set of rules that are used to analyse roles and users to identify risk exposure.
SAP GRC AC is delivered with a standard ruleset that reflects years of best practice thinking in terms of risk
identification and definition.43

How the SoD ruleset breaks down is shown below:

Company X
Rule Set Rule set

Risk 1: Maintain
Purchase Orders
Risk Vs. Manage
Risk 2 Risk n
Goods Receipt

Maintain Manage Goods

Functions Purchase Orders Receipt

MB01 – Post
ME21N – Create ME22N – Change MIGO – Goods
Actions Purchase Order Purchase Order Movement
Goods
Receipt on PO

Create PO for Create PO for Create GR for Create GR for

Permissions company codes purchasing area company code purchasing area

Figure 16. Ruleset explained

Access Risk Analysis – Mitigating Controls

The concept of mitigating risks is important in the business as usual process of SoD risk management. The goal
is to have as few SoD risks present in the production system as possible but some risks will be unavoidable. In
these cases, it will be paramount to be able to prove to auditors that any residual risk is mitigated, i.e. that
there are business controls in place that will identify if a user is able to or has used their conflicting access in a
way that is detrimental to the organization.
In ARA, controls are mapped to risks and can be assigned to users or roles. It is then possible to report on which
risks are mitigated and which are still unmitigated. This is an important distinction as unmitigated risk is
inherently bad as fraudulent activity could go undetected. The process of running mitigating controls will be
executed outside of ARA. Mitigating Controls for access based risks will be determined once the risks in the
ruleset have been agreed.44

In conclusion, Access Risk Analysis (ARA) module enables detecting and reporting of risk. Furthermore this
module offers following functionality and/or helps ensure:
 Clear communication between Business & IT
 Auditable change management of SoD definitions
 Centralized definition of SoD conflicts & critical actions
 Integration with SU2445 settings for rule generation
 Real-time risk analysis (user &role level)
 Cross-landscape detection of SoD violations
 Proactive detection of SoD issues by simulation

43
Fahri Batur (2013): Access Control Product: High Level Design, InteGRC, 4th November 2013.
44
Fahri Batur (2013): Access Control Product: High Level Design, InteGRC, 4th November 2013.
45 SU24 is one of the most important security codes in SAP Security. It is used to maintain authorization objects that are

checked during the execution of a particular transaction code.

27
2.3.3 SAP GRC Emergency Access Management (EAM)
Emergency Access Management (EAM) is used to manage elevated access to critical business processes across
connected systems. The table below provides an overview of the module and its business benefits to
organizations.46
Module Module Overview Business Benefits
SAP Emergency The SAP GRC module that Centralised Emergency Access Management
Access manages access to SAP in an • Centralised platform to manage and provision emergency access to
Management emergency that is typically SAP systems
(EAM) outside an end users • Centralised reporting on all connected SAP systems
business as usual Better placed for interaction with newer SAP technologies such as
responsibility. analytics, mobile platform and in-memory computing
Enhanced control over what users do whilst logged on with enhanced
access. This can reduce the risk of data confidentiality issues, data
integrity issues and system availability issues

Two different Fire Fighter or Emergency Access Application types can be identified: the ID-based Fire Fighter
versus the Role-based Fire Fighter. Only one option can be chosen for all remote systems.
ID-based Fire Fighter Role-based Fire Fighter
• The Fire Fighter ID created in the remote system will be • The Fire Fighter roles created in the remote system will
assigned to the user in the GRC system either manually be assigned to the user in the GRC system
or via an access request. • The user directly logs into the remote system using their
• The User accesses their assigned Fire Fighter ID in the regular user ID and performs activities which are
GRC system using the SAP GUI and transaction provided in the user’s role and Fire Fighter role assigned
GRAC_SPM / GRAC_EAM. to the user
• All Fire Fighter IDs for all remote systems assigned to
the User will be displayed and can be accessed from this
transaction.

Fire Fighter ID is a User ID with elevated privileges, it can only be accessed in the GRC server using transaction
GRAC_SPM. Fire Fighter Owner is a user responsible for a Fire Fighter ID and the assignment of Controllers and
Fire Fighters. Fire Fighter Controller reviews and approves (if necessary) the log files generated by a Fire
Fighter.47

Emergency Access Management – Master Data

Mapping of end users, fire fighter ids, controllers and owners will need to be identified during the project.
Recommended that this will be documented in a Master Data Design product.

In conclusion, Emergency Access Management (EAM) module enables removal of (Z)SAP_ALL. Furthermore
this module offers following functionality and/or helps ensure:
 Pre-approved emergency access
 Automatic e-mail notification when emergency access is activated
 Audit trails of performed actions
 Web-based log reports in central platform
 Integration with User Provisioning for approval of activation

2.3.4 SAP Access Request Management (ARM)

SAP Access Request Management (ARM) is the provisioning tool that will provide organizations with the ability
to manage SAP user access management and role assignments within connected systems. SAP access requests
are created online in the tool by requestors and submitted for approval. The requestor would be responsible
for selecting the roles required by the user. Once submitted, the request is routed online by workflow to
relevant approvers.
An integrated and enforced SoD check is carried out during the process in order to help avoid introducing SoD
risks into the environment. Where a SoD is identified by this enforced check, the approver has to make a

46
Fahri Batur (2013): Access Control Product: High Level Design, InteGRC, 4th November 2013.
47
Dina Shahin (2015): Leading Strategies to Enforce Your Organisation’s Access Policies Using Emergency Access
Management in SAP Access Control, Customer Advisory Group.

28
decision on how the request should proceed. Once all approval conditions are met, the request is submitted for
provisioning where ARM auto provisions the access to the user in the relevant target system(s).

The table below provides an overview of the module and its business benefits to organizations:48
Module Module Overview
SAP Access • Access Request Management manages
Request the access of users to SAP and non-SAP
Management systems. This solution automates the new
(ARM) joiners (account creation), movers,
(provisioning of roles) and leavers
(deactivation of user accounts) process.
• ARM integrates with EAM to automatically
provision elevated access to end users by
utilising workflow.
• ARM also integrates with ARA allowing
potential SoD and critical risk conflicts to
be identified prior to assignment.
Business Benefits
Significant improvements in provisioning solution
e.g. usability, workflow, flexibility, speed,
maintenance, implementation and system
performance
Dynamic workflow decision making leveraging the
multi stage, multi path (MSMP) and SAP BRF+
(Business Rule Framework plus) capability
A number of ready to use out of the box workflows
for ARM integration with EAM and ARA
Pro-active avoidance of unmitigated SoD risks by
enforced SoD check, thus reducing fraud risk

In conclusion, Access Request Management (ARM) module enables automation, control and documentation.
Furthermore this module offers following functionality and/or helps ensure:
 Standardized process for user access requests
 Automated management approval (workflow)
 Risk analysis before request approval
 Automated user provisioning to ERP systems (SAP, JD Edwards, Oracle, etc.)
 Automatic logging of request approvals and modifications
 Self Service Password resets

2.3.5 SAP GRC Business Role Management (BRM)

SAP Business Role Management (BRM) governs the end to end technical role development process. The tool
applies a role build methodology against all connected systems according to configuration based upon the
organization's requirements. BRM will also enforce a SoD check each time a role is saved thus helping to
prevent the introduction of SoD risks into roles.

The table below provides an overview of the module and its business benefits to organizations:49
Module Module Overview Business Benefits

SAP Business • Business Role Provides a single enterprise role repository for role design, testing
Role Management governs the and maintenance to enforce consistency and standardisation
Management end-to-end processes for Facilitates the role design process with a pre-defined (and
(BRM) SAP ABAP role customisable) design methodology and workflow
development from Supports the definition and documentation of role information,
inception to production authorisations and testing results
usage.
Supports integration with ARA to enforce the risk analysis during role
• BRM integrates with ARA design to prevent risks from entering application systems
and ARM. Reduces fraud risk by pro-active avoidance of SoD risks at the role
level. ISACA write that it is 7 times more expensive to fix security
related issues after the event than to put preventative measures in
place to avoid them
Allows preventative measures to be carried out far quicker than
manual alternative (using GRC simulation functionality)
Using the business roles concept can enhance business ownership of
roles and related concepts as they aid better understanding of the
provision of access to users

48
Fahri Batur (2013): Access Control Product: High Level Design, InteGRC, 4th November 2013.
49
Fahri Batur (2013): Access Control Product: High Level Design, InteGRC, 4th November 2013.

29
Business Role Management – Role Mapping
A business role is a virtual container for roles that span across multiple systems. Business roles can be used to
determine the access necessary for the function or process the user is involved with, helping organisations
better manage changes to access. Once Business roles have been mapped with the appropriate job tasks,
organisations can easily control compliance or business risk by running their rules against the requests.
Business roles are system independent. An example is, when an organization creates a business role that has
assigned two technical roles, one for system A, and one for system B. When this business role is assigned to the
user (having two technical roles from two different systems) it is not necessary to select the system for the
business role itself. The request will automatically provision to both the technical role's systems. This approach
makes it more straightforward for understanding, requesting and approving access to SAP. 50

In conclusion, Business Role Management (BRM) module enables enforcement of concept rules. Furthermore
this module offers following functionality and/or helps ensure:
 Central documentation of SAP authorization concept
 Preventive risk analysis for authorization roles
 Approval workflow for changes
 Automatic role generation in SAP
 Audit trails and reporting of all changes

2.3.6 SAP GRC AC and SAP IdM integration

SAP IdM provides a comprehensive solution for managing user accounts and privileges across enterprise
landscapes. Enterprise landscapes include a variety of applications and systems such as Microsoft Active
Directory, Microsoft Exchange, SAP Business Suite, and custom applications. SAP IdM is capable of integrating
with these systems to support identity management and provisioning through a combination of out-of-the-box
connectors, standards-based integration, connectors provided by partners and connectors custom-developed
using the SAP IdM's published connector API (Application Programming Interface).
SAP IdM supports the functionality to manage the user lifecycle from initial on-boarding, change, and
termination. Below automated identity management processes – supported through SAP IdM - for on-boarding
(figure 17), position change (figure 18) and termination (figure 19) are shown:51

Figure 17. Business Process Driven Identity Management using SAP IdM - On-Boarding.

50
Fahri Batur (2013): Access Control Product: High Level Design, InteGRC, 4th November 2013.
51
SAP (2014): SAP Identity Management: Overview, October 2014.

30
Figure 18. Business Process Driven Identity Management using SAP IdM – Position Change.

Figure 19. Business Process Driven Identity Management using SAP IdM – Termination.

Below overview shows functionality that is provided by SAP IdM:52

52
Henk Peter Wind (2015): SAP Netweaver Identity Management & SAP Access Control, Integrc, February 12, 2015.

31
Figure 20. SAP NetWeaver Identity Management functionality.

An integrated solution based on SAP GRC AC and SAP IdM combines access governance and identity
management capabilities to support automation of identity and access processes and compliance
requirements.
 SAP GRC AC solution is based on ABAP technology and integrates with the native SAP ERP, Oracle,
PeopleSoft, and JDE interfaces to support access governance capabilities. As explained in the previous
section (§2.3.1), these capabilities include features such as administration of the access request process and
approval process with integrated SoD analysis.
 SAP IdM is based on Java technology and is designed to support administration of user identities, user
provisioning, and single sign-on across IT systems and applications.
SAP GRC AC provides highly specialized functionality required to administer access and manage accounts to
meet requirements for financial regulations and company policies. SAP IdM provides specific features designed
to automate identity administration across multiple systems. When IdM is integrated with SAP GRC AC, SoD
analysis capabilities can be integrated with the approval processes within IdM to ensure that role assignments
are compliant with financial regulations.53

Below figure shows the features of an integrated SAP GRC AC – SAP IdM solution. Features are related to (i)
Access Governance, (ii) Administration and Identity Management and (iii) Access Management:54

53
Swetta Singh, Chris Radkowski, Keith Grayson (2012): How to leverage SAP NetWeaver Identity Management and SAP
Access Control combined solutions, SAP Solution Management, December 6, 2012.
54
Swetta Singh, Chris Radkowski, Keith Grayson (2012): How to leverage SAP NetWeaver Identity Management and SAP
Access Control combined solutions, SAP Solution Management, December 6, 2012.

32
Figure 21. Features of integrated integrated SAP GRC AC – SAP IdM solution.

2.4 (III) SAP Security Organizational Structure & Governance and (IV) Ongoing Management &
Monitoring of the SAP Security Environment explained
Below table provides a highlight of the common issues with SAP Access Security (in particular: user
administration) that often times are experienced in organizations that have not dealt adequately with following
two SAP (Access) Security Design Components:55
• SAP Security Organizational Structure & Governance,
• Ongoing Management & Monitoring of the SAP Security Environment
Hence, in explaining what both design components comprise, I will focus on SAP Access Security - with regard
to user provisioning - key risks that might occur and where root causes are in design component(s) referred to
above. Furthermore, distribution has been made with regard to the domain where the issue relates to: SAP
(Access) Security related versus SAP GRC AC related.

Domain Common Key Risks Root cause

issue (root cause is related to inadequate design
and/or inadequate operating effectiveness of one
or both of the following design components:
 SAP Security Organizational Structure &
Governance
 Ongoing Management & Monitoring of the
SAP Security Environment)
SAP Standardized  Role-level SoD issues  Inconsistent role standards
(Access) Role  Inappropriate organizational level  Lack of role governance
Security Architecture restrictions  Roles not managed globally
Related  Duplicative transaction assignments  Unintuitive role naming convention
 Powerful roles with unnecessary  Lack of role documentation
access
 Excessive number of transactions
granting unintended access to end
users
 Increased efforts of the Security
Team for role maintenance and user
provisioning
SAP IT Change  Lack of Change Management can  Lack of IT Change Management
(Access) Management impact role maintenance which is
Security critical to maintaining a secure SAP
Related environment and standardized role
architecture
 Roles unaligned with the new and
existing global business processes

55
Protiviti (2014): Optimizing User Administration in SAP, ISACA Geek Week – Atlanta, August 13, 2014.

33
 Domain Common Key Risks Root cause
issue (root cause is related to inadequate design
and/or inadequate operating effectiveness of one
or both of the following design components:
 SAP Security Organizational Structure &
Governance
 Ongoing Management & Monitoring of the
SAP Security Environment)
SAP Development  Lack of functionality knowledge  Absence of SAP customizing governance
(Access) of Custom  Circumventing security & gaining processes
Security Transactions, unauthorized access to sensitive  Poor design documentation and/or lack of
Related Objects, data communication
Programs, &  Bypass organizational level security  Custom program coded to call powerful
Tables restrictions transactions (i.e. SE38, SA38, SM30, etc.)
 Excessive privileges within the scope  Authorization checks not coded in custom
of the specific transaction program
 Unauthorized execution of programs  Not assigning custom programs to custom
transactions
SAP Backend There are several security related Security related backend tables and
(Access) System backend tables and configurations that configuration that are critical to maintaining a
Security Configura- are critical to maintaining a controlled controlled security environment that are
Related tions security environment that are often overlooked. For example:
overlooked or maintained which could  SU24 (Display transaction VA0156)
become a significant security risk.  SE54 (Change View Authorization)
 RSCSAUTH (Maintain/Restore Authorization
Groups)
 RSPARAM (Display Profile Parameter)
SAP GRC User  Assignment of excessive and/or  The user does not know the appropriate role
AC Provisioning sensitive access to select due to current naming convention
Related  Documenting appropriate approvals  User provisioning is a manual process
for compliance purposes  Approvals are documented offline or via email
 Delay in provisioning or  Master data has not been maintained
deprovisioning appropriately
 Selection of correct roles
 User access reviews
SAP GRC Segregation  A user with excessive or sensitive  Over the course of time a user may switch job
AC of Duties access within the system has the functions
Related (SoD) ability to perform fraudulent activity  It may be necessary for the user to have the
 Internal controls may be access within SAP to perform both business
circumvented by excessive access functions during the transition period
 After the transition period is over the user may
still retain this excessive access
 SoD violations can quickly spiral out of control
because in some organizations users submit
access requests by replicating a user
performing the same job function
SAP GRC Management  Super user or privileged access  Certain sensitive or critical transactions are
AC of Temporary should be approved and reviewed in necessary to keep the system running
Related / Emergency a timely manner smoothly
Access  A user can perform critical actions  Restricting and monitoring sensitive access
either accidentally or maliciously to within the system is a top audit concern
interrupt system availability  Log review is a very tedious and time
consuming process
 Some users are assigned the profile SAP_ALL
granting unrestricted access

In addition to specific root causes referred to in above table, there are a few generic root causes that can be
linked to multiple key risks shown above. These more generic root causes – including the SAP (Access) Security
Design Component that these root causes relate to – are shown in below table:

56
VA01: Create Sales Order

34
Generic Root Cause Related SAP Access Security Design Component
• Misalignment of IT vs Business Objectives
• SAP Security Organizational Structure & Governance
• Lack of Strategic Security Design Decisions
• No Role or Security Design Ownership
• Management KPIs for Security Design are not
established • Ongoing Management & Monitoring of the SAP Security
• Lack of automation for ongoing monitoring & Environment
recertification procedures
• Insufficient SoD and/or Mitigating control frameworks

35
3 Good Practice SAP (Access) Security Design Framework

3.1 Introduction
The fundamental purpose of SAP access management is to establish an effective SoD framework; ensure
minimal but appropriate access approvals; and minimize risks relating to granting, changing and removing
access. To accomplish all of the above, effective organizations often take steps referred to in this section.
This section reflects good practices and considerations from the perspective of organizations that are
(re)defining their SAP security design framework in the context of a SAP implementation, upgrade and/or re-
implementation. The case study object does reflect a similar scenario. Because of this similar scenario, it is fair
to assess if the good practices that are being identified in this section are indeed applicable to the case study
object (the outcome of this ‘applicability check’ is addressed in chapter 4 and 5).
Some of the topics that – to the extent professional and/or academic literature has identified good practices
around these topics - will be addressed in this section are:
 What kind of good practices do ensure that SAP GRC AC supports companies in appropriately managing
their access controls processes?
 What are good practices that ensure organizations get clean, stay clean and stay in control on access
controls whilst implementing ('get clean') and/or having implemented ('stay clean and stay in control') SAP
GRC AC?
 How to best customize the standard SAP GRC AC rule set and how to ensure customized rule set is
appropriately maintained?
 What are good practices with regard to structuring roles and responsibilities of the different actors in the
access controls processes?
 What is/ are appropriate organizational structure(s) that is/are required to enable appropriate governance
and management of access controls processes?
 What kind of guidelines (policies, procedures, etc.) are required to enable appropriate governance and
management of access controls processes?

3.2 Good practices regarding implementation of Access Control and Access Control Applications
Defining SAP security requirements in the early phase of a SAP implementation, upgrade or reimplementation
can help ensure efficiency and achievement of a 'clean state' with regard to mitigation of security risks prior to
go-live. It is also important to leverage access management technology, such a SAP GRC AC or similar solutions,
to monitor whether security design requirements and SoD restrictions are properly maintained throughout the
system build, deployment and go-live phases. Below overview shows two approaches to building SAP
Application (Access) Security: Top-Down or Proactive Approach versus Bottom-Up or Reactive Approach.
According to global consultancy firm Protiviti57 - and based on their extensive experience in the 'field' - the Top-
Down or Proactive approach is clearly preferred.

Figure 22. Approaches to Building SAP Application Security.

57
Protiviti (2014): Designing SAP Application Security: Leveraging SAP Access Monitoring Solutions during SAP
Implementations, Upgrades or Redesign Projects.

36
 Below overview displays recommended approach by Spruit, et al.58 for an Access Control deployment. In their
article they recommend that an implementation is not limited to the design of the application itself. Often the
goal of an Access Control application implementation project is also to clean up the current authorizations, and
to improve the processes, supported by an Access Control application. In my view the approach recommended
by Spruit et al (hereafter referred to as ‘KPMG’ approach) can therefore be seen as a hybrid approach: it
contains detailed steps for the deployment of an Access Control application as well as the implementation of
access control in general.

D.
Element A. Design B. Realisation C. Test
Implementation
1.  Define rule set and  Configure Access  Validate using  Configure
Monitoring mitigating control Control applications (KPMG) SoD Background
SoD and strategy  Activate and monitoring jobs
critical tasks configure workflows tools  Linking mitig.
 Set up test scripts  User Accep- controls to risks
A1 B1 tance C1  Train D1
Test
2.  Define user rights with  Configure Access  User  Configure
①Lay User regard to user access Management Acceptance Background
 Risk Recognition
the Management request process application Test jobs
 Technical  Define Role owners  Configure workflows  Train
foun-
Realization and ‘Approvers’  Set up master data for
dation
 Define workflow and Role owners and
mail integration Approvers
A2 B2 C2 D2
②  Set up testscripts
 Risk Analysis 3.  Define role  Configure Role  User  Support
 Risk remediation Get Role maintenance process Management- Acceptance development/
 Risk mitigation clean Management and role naming application Test design
convention  Set up testscripts  Train
A3 B3 C3 D3
 Define workflows
③ 4.  Define Firefighter  Configure Emergency  User  Train
 Continuous Managing process Management- Acceptance
Management & Stay Emergency  Define authorizations/ application Test
Monitoring clean Access Users roles for Firefighter  Set up masterdata for
 Define firefighter Firefighter owners
A4 B4 C4 D4
owners & users and monitors
5.  Document and / or update governance model, roles and responsibilities with respect to
Governance users and authorization management, maintenance of GRC solution, maintenance of SoD
Model ruleset in GRC, SAP security policy
&  Document and / or update procedures / work instructions 5
Procedures  Set up procedures for periodic monitoring of SoD & effectiveness of mitigating controls
Project management 6
Figure 23. Recommended Approach according to KPMG for implementation Access Control (Application).

According to EY59, most successful SoD initiatives consist of five phases: business definition, technical
definition, testing, mitigation and remediation (see overview below).

58
Drs. Ivan Spruit, Jasper Schutte MSc en Sander van der Zon MSc (2013): Access Control applicaties voor SAP, KPMG,
Compact, 2013-3.
59
Ernst & Young (2010): A risk-based approach to segregation of duties - Insights on governance, risk and compliance.

37
 Phase1 Phase2 Phase3 Phase4 Phase5

5.
1.Business 2.Technical 4.
3.Testing Remedia-
definition definition Mitigation
tion

Figure 24. EY risk-based approach to segregation of duties

All three approaches (Protiviti, KPMG and EY) in my view do not (explicitly) take on board the importance of
having an adequate organizational change management approach. Perhaps the only exception that comes
close to including this is the KPMG approach, where not so much the importance of organizational change
management is being referred to, but at least reference is made to having a project management approach.
Also reflecting a FrieslandCampina case study presentation60, I have therefore chosen to include the activity to
‘Define and Deploy an Organizational Change Management Approach’ in the overall good practice SAP Access
Security Design Framework I am developing in this section.

Below table shows the relationship between the different steps in all three approaches:
 The Protiviti Top-Down approach for building SAP (Access) Security or implementing SAP (Access) Security
Design (step 1 to step 7), versus
 The KPMG recommended approach for implementing access control as well the recommended approach
for the implementation of an Access Control Application, whereby the different steps in the KPMG
approach are depicted through the coding as reflected in figure above (A1…A4, B1…B4, C1…C4, D1...D4
and 5).
 EY risk-based approach to segregation of duties
Also, in below table in the utmost right column, the relationship is shown between the different elements or
steps under the 3 different implementation approaches versus the related SAP Access Security Design
component(s) as explained in the previous chapter.

Protiviti61 KPMG62 EY63 SAP Related SAP Access Security Design

Top-Down approach Related steps Related steps under Related steps GRC Component(s)
to building SAP under KPMG KPMG recommended under EY risk- AC
(Access) Security recommended approach for based Go-
approach for implementing Access approach to live
implementing Control application segregation phase
Access Control of duties
Step 064: Define and - 6 - Pre  III. SAP Security Organizational
Deploy Organizational go-live Structure & Governance
Change Management
approach (§ 3.2.1)
Step 1: Define SoD 1.Lay the A1 & 5 1.Business Pre  II.SAP Security & Provisioning
Policies and Rule foundation – Risk definition go-live processes
Design (§ 3.2.2) Recognition &  III. SAP Security Organizational
Definition Structure & Governance

60
Ron Veldhuizen (2015): Case Study: How FrieslandCampina Embedded a Sound Change Management Strategy into Its
SAP Access Control Implementation Project to Ensure Success, FrieslandCampina.
61
Protiviti (2014): Designing-SAP-Application-Security: Leveraging SAP Access Monitoring Solutions During SAP
Implementations, Upgrades Or Redesign Projects.
62
Drs. Ivan Spruit, Jasper Schutte MSc en Sander van der Zon MSc (2013): Access Control applicaties voor SAP, KPMG, ,
Compact, 2013-3.
63
Ernst & Young (2010): A risk-based approach to segregation of duties - Insights on governance, risk and compliance.
64 Step 0 is not included in the Protiviti Top-Down Approach to building SAP (Access) Security. However for presentation

purposes and because I consider this step to be a crucial step to start the process of building SAP (Access) Security, I have
included this step in the first column in this table. This step is derived from the Change Management strategy
FrieslandCampina has deployed in its implementation project of SAP GRC AC.

38
 Protiviti61 KPMG62 EY63 SAP Related SAP Access Security Design
Top-Down approach Related steps Related steps under Related steps GRC Component(s)
to building SAP under KPMG KPMG recommended under EY risk- AC
(Access) Security recommended approach for based Go-
approach for implementing Access approach to live
implementing Control application segregation phase
Access Control of duties
Step 2: Initial Role - A2 - Pre  I. SAP Security Authorization concept
and User Design go-live
(§ 3.2.3)

Step 3: Role Build and 2.Lay the A3, B1 to B4 (with 2.Technical Pre  I. SAP Security Authorization concept
User Assignment foundation – regarding to configuring definition go-live  II.SAP Security & Provisioning
(§ 3.2.4) Technical work flows and setting processes (Access Risk Analysis(ARA),
Realization up master data related User Provisioning)
to requesters, owners,
approvers)
Step 4: Role and User 3.Get Clean – Risk C1 (validate using SoD Pre  II.SAP Security & Provisioning
Access Risk Analysis Analysis monitoring tool), 5 4.Mitigation go-live processes
(§ 3.2.5) 4.Get Clean – Risk 5.Remedia-  III. SAP Security Organizational
Remediation tion Structure & Governance
5.Get Clean – Risk
Mitigation
Step 5: Security - C1, C2, C3 & C4, Pre  II.SAP Security & Provisioning
Testing and Go-Live (B1 to B4 with regard to 3.Testing go-live processes
Preparation (§ 3.2.6) Set-up of test scripts)
Step 6: Move to - D1, D2, D3 & D4 - Go-  II.SAP Security & Provisioning
Production and live processes (including Access Risk
Support (§ 3.2.7) Analysis (ARA)and Emergency Access
Management (EAM)
 III. SAP Security Organizational
Structure & Governance
Step 7: Ongoing 6. Stay Clean - 5 - Post  IV. Ongoing Management &
Management & Continuous go-live Monitoring of the Security
Monitoring of the Management Environment
Security Environment 7. Stay Clean –
(§ 3.2.8) Continuous
Monitoring

Although all three approaches (i.e., Protiviti, KPMG and EY) do have clear overlap with regard to the steps they
recommend for designing, implementing, and maintaining SAP (Access) Security, it can be concluded that the
Protiviti approach has a wider and more complete scope. Protiviti's approach not only contains recommended
steps for implementing a SAP GRC AC Application, it also covers detailed steps for (re)designing SAP
authorization roles and/or (re)designing an organization's SAP Security Authorization concept. Since the case
study object's SAP+ project – with regard to the authorization roles – also includes such a redesign, I have
decided to use the Protiviti approach as a stepping stone to determine a good practice SAP (Access) Security
Design Framework. However, in identifying the good practices for each step - wherever possible - I will also
consider good practices that are referred to in the recommended approaches by KPMG and EY as well as
professional literature issued by other sources.
Also notable in above comparison is that under the KPMG recommended approach the Risk Remediation step
(step 4) precedes the Risk Mitigating step (step 5), whilst under the EY recommended approach it is the other
way around.

The different steps with regard to the ‘Top-down approach for SAP (Access) Security Design’ are explained
more in detail in below subsections. These steps – as shown in above table in the utmost right column – would
also cover the different SAP Access Security Design Component(s) which have been explained in the previous
chapters.

39
3.2.1 Step 0: Define and Deploy Organizational Change Management Approach
John Kotter in his book “Our iceberg is melting” sets out an eight stage change management model. Kotter sets
out 8 steps for managing change which managers and change leaders should follow if a change initiative is to
succeed:
 step 1: establish a sense of urgency
 step 2: create a guiding coalition
 step 3: develop a vision and strategy
 step 4: communicate the change vision
 step 5: empower employees for broad-based action
 step 6: generating short-term wins
 step 7: consolidate gains and produce more change
 step 8: anchor new approaches in the culture
FrieslandCampina has successfully applied the above eight steps to their SAP GRC AC implementation project:65
Change Detailed activities
Management Step
1. Creating a Sense Push: Executive Board emphasizes importance on internal controls:
of Urgency  Internal control effectiveness in performance evaluation of management
 Transparent company-wide reporting on IC successes and issues of Operating Companies
(OpCos)
 On quarterly agenda, top-down support visible
Pull: SoD requirements in place before SAP GRC:
 More comprehensive SoD matrix and reporting
 Freeze on upgrading current tools/processes
 Frequent communication of benefits of SAP GRC
 Business sees SAP GRC as opportunity (no threat)
2.Establishing the Assemble a powerful coalition
Guiding Team  Identify the true leaders and key stakeholders
 Include stakeholders throughout the whole organization:
- ERM
- Finance Directors and/or Controllers of businesses
- Authorization team, Internal Audit, ICT
3.Developing the Technical implementation – “Big Bang”
Change Vision and  Compact technical implementation for all Access Control sub-modules
Strategy  Limited period (at FrieslandCampina this was six months) including alignment of all key
stakeholders in blueprint and acceptance testing
Organizational implementation – Phased rollout
 Start with deployment of Access Risk Analysis (ARA) and Emergency Access Management
(EAM) for central IT functions
 Have a pilot for the roll out of the remaining SAP GRC AC modules in an OPCO (or business
unit) that is eager to implement and that has a large exposure within the organization (quick
win)
 Subsequently have an OPCO by OPCO roll out of these remaining SAP GRC AC modules
4.Communicating  Communication plan and dedicated Change Manager
the Vision for Buy  FD/Controllers and management within business units communicate the (importance of)
In change in their organization
 Communication tailored to stakeholders
- Various communication channels and moments: email, face-to-face, workshops,
Yammer, Skype, WebEx, Newsletters, etc.
- Focus on facilitating and supporting end users, growing their confidence
 Corporate Communication involvement
5.Empowering the  Define clear responsibility based on RACI66 model
Team to Implement  Dedicated roles in the project (project management, change management, technical,
functional, trainers, quality assurance)

65
Ron Veldhuizen (2015): Case Study: How FrieslandCampina Embedded a Sound Change Management Strategy into Its
SAP Access Control Implementation Project to Ensure Success, FrieslandCampina.
66
The RACI model or matrix is a formal way of establishing the role for each stakeholder/participant whenever multiple
parties are involved. In a nutshell: R(esponsible) – Who is responsible for actually doing it?, A(ccountable) – Who has
authority to approve or disapprove it?, C(onsulted) – Who has needed input about the task? and I(Informed, kept) – Who
needs to be kept informed about the task?

40
 Change Detailed activities
Management Step
 Inspire stakeholders to adopt new ways of working
 Encourage non-traditional ideas
 Remove barriers to change and improve
6.Producing and Plan quick visible performance improvement
Showing Short-  Break up the project in smaller parts
Term Wins  Start with quick wins (e.g., reduction of fire fighters, simplifying reporting, OpCo pilot success)
 Communicate and celebrate quick wins – give team members a sense of accomplishment while
getting the others interested
 Gain confidence
Project perspective
 Start with Analyse Risks module to clean your data, reduce SoD conflicts and show quick wins
7. Not Letting Up Keep looking for improvements
 Analyse Risks is just the first part
 Keep end-state in mind
 Keep communicating
Evaluation
 Periodic evaluations (what went right and what can be improved)
 Learn from the past and show you apply learnings in future rollouts
 Don’t change winning approaches
8. Making the Embed SAP GRC AC in the core of the organization
Change Stick  Define deliverables
 Quick Reference Guides
 Newsflashes
 SharePoint
 Distribute deliverables
Keep involving the end users
 Schedule periodic evaluation sessions with the end users to monitor the project
Create a single point of truth for new people

In addition to the above, SAP itself67 – with regard to implementation of SAP GRC AC - has stressed the
importance of identifying the right internal resources:
 Active executive participation
 Need a good project manager
 Need decision makers
 Need collaboration between all parties
 Need to know the business processes
 Employee and company knowledge are essential

3.2.2 Step 1: Define SoD Policies and Rule Design

The first step in implementing SAP application security using the top-down approach is to work with business
process owners (BPOs), SAP functional leads, and risk & compliance function(s) to identify business
processes and applications in-scope of the SAP+ project and determine how the different SAP ECC modules
(e.g., Financials and Controlling, Materials Management) and SAP Applications (e.g., SAP Supplier Relationship
Management (SAP SRM), SAP NetWeaver Master Data Management (SAP MDM), SAP Advanced Planner and
Optimizer (SAP APO)) would be utilized for each business process. A series of meetings and validation
workshops should be conducted to establish an agreed-upon and written SoD management framework (see
figure below), including SoD policies with respective risk descriptions, risk ratings, and compliance and audit
requirements.68

67
Erwin Albers (2015): Rethinking Segregation of Duties: Where Is Your Business Most Exposed?, SAP Netherlands.
68
Protiviti (2014): Designing SAP Application Security: Leveraging SAP Access Monitoring Solutions During SAP
Implementations, Upgrades Or Redesign Projects.

41
Figure 25. Key Components of a SoD Management Framework.

As part of this framework definition process, SoD policies should be outlined and classified into risk levels
such as critical, high, medium and low risk, as described in table below.69 This will help management prioritize
areas of focus during role build or security remediation phases:
Risk level Description of risk level

Critical risk  Represents significant impact to company operations or company value

 Risk cannot be mitigated, it requires remediation
High risk  Represents a direct financial misstatement risk or significant profit and loss (P&L) impact
 Affects corporate image
 Represents a deviation on standard best-practice processes or noncompliance with laws
 Generates inconsistencies on master data governance or transactional data
 Causes loss or theft
 May be mitigated with an effective management-level report, or may require remediation
Medium risk  Causes a financial statement reclassification risk
 Represents medium P&L impact
 Risk cannot be mitigated, it requires remediation
Low risk  Represents significant impact to company operations or company value

These definitions vary from company to company based on the organization and industry-specific criteria. After
these SoD policies and risks are defined, SAP standard and custom transactions should be evaluated to
identify those that provide the ability to create, modify, post or delete data related to any of the identified
risks. Ultimately, these SAP transactions are grouped into job functions (e.g. Create a GL Account, Post
Payments) and should be configured in an automated SAP security monitoring solution (such as SAP GRC AC)
as “rule sets”, which are used to analyse SoD conflicts at the role or user level.
Most SAP Access Management solutions include a standard/predefined set of SoD rules; however, these rules,
along with the risk ranking (critical, high, medium, low), need to be adjusted to reflect the company’s risk

69
Protiviti (2014): Designing SAP Application Security: Leveraging SAP Access Monitoring Solutions During SAP
Implementations, Upgrades Or Redesign Projects.

42
profile. In addition, it is important to note that these standard rule sets may report on false positives if the
security parameters (i.e., authorization objects) are not adjusted to reflect the company’s security design. 70

In conclusion, a company implementing SAP GRC AC should reconfigure and tailor the SAP GRC rule set to the
specific risks of the company. This should include the following activities:71
 Definition of risk levels (i.e. what constitutes a high, medium, and low risk).
 Deactivation of risks for functions that will not be utilized.
 Modification of the risk levels to be consistent with the risk levels defined by the company.
 Identify and adjust the SAP GRC rule set for potential risks that are not included in the current rule set.
 Analyse custom transaction codes, created since the codes were previously analysed, for potential
inclusion in the SAP GRC rule set.
 Review transaction codes utilized by the company which are not included / defined within SAP GRC, for
potential inclusion in the rule set.
 Review authorization object configuration of the SAP GRC rule set to eliminate false positives and ensure
that segregation of duties are identified appropriately.
 Analyse role-level and user-level segregation of duties to identify false positives and adjust the rule set as
required.
 Define and configure sensitive access to be monitored by SAP GRC.

In addition to SoD policies and risk definitions, companies should also define, group and classify sensitive SAP
transactions to enable monitoring and reporting on SAP roles and users who have add, modify or even
display access to the company’s sensitive information, such as vendor pricing lists, customer lists, bills of
materials (BOMs), sensitive SAP tables, financial data, and human resources (HR) information. 72
A formal requirements document should be completed based on discussions with business process
management. The requirements document should include to-be workflows, business owners / approvers,
user access request form fields, custom fields, field mapping between source systems and SAP GRC, user
master data source, email notification wording and settings, and any gaps identified including the approaches
to handling the gaps. Once the requirements document is completed, a formal sign-off should be obtained to
validate that the document accurately reflects the company’s business requirements for the SAP GRC tool. 73

KPMG: Step 1. Lay the foundation – Risk Recognition and Definition

In this phase, the desired segregation of duties is established, as well as the policy on how to deal with a
breach of the segregation of duties and the use of emergency users.

EY: Phase 1 - Business definition

According to EY74 the objective of the business definition phase is to gain an understanding of the scope of
sensitive transactions and conflicts that drive the company’s key business processes. These are also the
transactions that pose the greatest fraud risk to the organization should someone possess excessive access.
During this phase, thresholds are determined based on the risk and impact to the company for each potential
SoD conflict pairing. As this step lays the foundation for everything that follows; proper execution is critical.
Many companies fail in this early stage by taking on too many conflict pairings that do not meet the threshold
level of risk, resulting in onerous requirements that ultimately cannot be met or are excessively costly for the
risks they are attempting to manage. For example, a company may be concerned with allowing the same
individual to both create a vendor purchase order and modify the customer pricing master file. However, the
combination of the two may constitute such a low risk that it does not warrant inclusion in the company’s
conflict matrix. It might be more appropriate to include potential conflicts for a user who could modify the

70
Protiviti (2014): Designing SAP Application Security: Leveraging SAP Access Monitoring Solutions During SAP
Implementations, Upgrades Or Redesign Projects.
71
Los Angeles Unified School District - Office of the Inspector General Internal Audit (2012): Audit Report - GRC
Implementation Review.
72
Protiviti (2014): Designing SAP Application Security: Leveraging SAP Access Monitoring Solutions During SAP
Implementations, Upgrades Or Redesign Projects.
73
Los Angeles Unified School District - Office of the Inspector General Internal Audit (2012): Audit Report - GRC
Implementation Review.
74
Ernst & Young (2010): A risk-based approach to segregation of duties - Insights on governance, risk and compliance.

43
vendor master file, create a vendor purchase order and issue payment to vendors as the combination
represents the higher risk to the company.
The output of the business definition phase is a matrix of potential conflicts (Conflict matrix), independent of
the supporting IT application driving each transaction, but including the corresponding risk statement related
to each conflict. The risk statement answers the question, “Why do we care about this transaction pairing or
combination?” and demonstrates what could go wrong should someone have enough access or authority. The
risk statement might say, “A user could create a fictitious vendor or make unauthorized changes to vendor
master data, initiate purchases to this vendor and issue payment to this vendor.” In this case, the “vendor”
might be the fraudulent employee with an excessive and inappropriate level of access in the system.
Generally, the matrix and corresponding risk statements differ among companies, industries, business
models and even locations within the same company, depending on what processes are significant. It is not
uncommon for a large global company to have more than one matrix due to differences in the business
processes by location or business unit. For example, a company may have a manufacturing business unit with a
large amount of inventory, requiring a SoD matrix that focuses on specific inventory transactions. They may
also have a service-based business unit necessitating a focus on project accounting, requiring a different SoD
matrix. Though knowledge of similar businesses and industries can help to establish the conflict matrix, each
business unit must perform a customized analysis of its conflicting transactions in order to capture the real
risk for that particular business model.

Good practices and recommendations from other sources

 SAP75 emphasizes that "Risk definition" is one of the most important tasks in a SAP GRC AC implementation
project. SAP proposes the following approach and related DOs to be deployed:
Step DOs
Step 1: Document Access Risks  Should be done in business language
 Risk statement should clearly state the actions and the negative results that
will occur if the undesired access is exploited
Step 2: Classify Access Risks  Assess the severity of the risk to the organization if exploited
 Assign/review risk ranking (critical, high, medium, low)
Step 3: Identify Risk Owners  Risks belong to the business; risk owners should be business personnel (not
IT!)
 Assign owners to each risk
Step 4: Translate into Technical  Enlist the help of IT to assist with technical risk definitions
Risks  Remember to include both standard and custom transactions
Step 5: Publish and Deploy  Publish risk definitions
Technical Risk Definitions  Upload risk definitions into AC and generate rules

 With regard to risk definition, SAP GRC consultancy firm InteGRC 76 recommends that standard ruleset will
be leveraged as a starting point to facilitate conversations with the organization's stakeholders
regarding identification of risks applicable to the organisation through risk identification workshops.

3.2.3 Step 2: Initial Role and User Design

The next step after establishing the SoD policies and rule sets in SAP GRC AC includes the initial design of SAP
roles. This step starts by reviewing “to-be” business processes and conducting a preliminary analysis of
individual tasks and SAP transactions that will be performed once the new system goes live. At this point, the
SAP application security team will group transactions into the beginning stages of SAP roles. This step could be
challenging without predefined role templates due to the lack of available documentation to perform the role
design related to transaction functionality.
Another approach for defining the set of SAP transactions to include in the updated SAP roles is to review the
SAP transaction history. This method is applicable to SAP upgrade or security redesign projects only, since no
transactional history will be available for new SAP implementations. In this approach, transaction logs are
analysed to determine the set of monthly, quarterly and year-end transactions that should be included in the
newly designed SAP roles
The next step after the initial transaction grouping is to conduct workshops with BPOs to validate that the
respective SAP transaction groups are aligned with the “to-be” business processes in case of new SAP

75
Erwin Albers (2015): Rethinking Segregation of Duties: Where Is Your Business Most Exposed?, SAP Netherlands.
76
Fahri Batur (2013): Access Control Product: High Level Design, InteGRC, 4th November 2013.

44
implementations or existing business processes in case of security redesign projects. At this stage, the “role
templates” will be documented. These consist of the role's technical name and the underlining transaction
codes. They may also include key information related to security restrictions, such as company codes, cost
centers or document types.
The next key step within the role and user design phase is to define “role owners” for each role template. Role
owners are typically part of the functional implementation, or business teams, and usually “own” or are
responsible for managing and reporting on the data being updated by the SAP transactions and roles they own.
For instance, a corporate controller would own finance-related roles. Responsibilities for role owners include
review and approval of SAP transactions to be included in the role and ongoing maintenance of the role (e.g.,
transaction additions, deletions, and approval of mitigating controls if conflicts occur).77

Good practices and recommendations from other sources

According to SAP78, a good authorization concept should have the following characteristics:
 Reliability: the range of authorization has to correspond with the operational responsibility of the end user
 Security: it has to be guaranteed that no unauthorized users have access to sensitive data or programs
 Testability: the concept has to be comprehensive and transparent both for internal as well as for external
auditors.
 Flexibility: it should be easy adaptable, if for example organizational changes occur or new modules have
to be integrated
 Comprehensibility: it should be easily comprehensible for all those involved, as for example according to
name conventions for users, authorizations and profiles.

Good practices regarding selection of Appropriate Role Architecture

The organization’s role architecture should be designed to reduce access risks, but also flexible enough to
support business objectives (e.g., company growth, mergers, and consolidations). A well-designed architecture
can help support an efficient provisioning process and assist in the removal of SoD violations from the system.
When defining a security architecture, it is important to consider how to balance business priorities, such as
the need for flexibility and control, and keep in mind the importance of minimizing the number of security roles
to keep maintenance efforts to a minimum. Involving business process owners in the design and ownership of
roles will help ensure the roles truly reflect business functions and will be sustainable in the longer term.
To help design and keep roles free of SoD conflicts over time, many companies use a security and compliance
solution such as SAP GRC AC, which can automate the periodic review of users, identify risks within roles before
granting access to productive systems, and streamline associated audits and reporting the security risks. It is
also important to consider the naming conventions and role groupings. These need to be intuitive not only to IT
security experts, but also to business approvers and reviewers.79
Also according to Provititi80, it is important that adequate choices are being made in order to ensure
appropriate role architecture is in place. Some key SAP security considerations are related to:
 Job Based versus Task Based roles
 Single versus Composite roles
 Derived versus Enabler roles
 Custom or Pre-delivered SAP Roles
 HR or position-based design versus functional design

Ad. Job Based versus Task Based

In the authorization concept a choice can be made between a task-based versus a job-based Security Design
(see below overview). Actually the first key decision to make during the actual design of SAP Security is
whether to use "job-based" versus "task-based" roles. The intention of job-based roles is to give each user one
role (e.g., Accounts Payables Manager) that encompasses all of that person’s activities. This approach utilizes

77
Protiviti (2014): Designing SAP Application Security: Leveraging SAP Access Monitoring Solutions During SAP
Implementations, Upgrades Or Redesign Projects.
78
Marie-Luise Wagner (2008): Practical Guide for SAP Security, SAP.
79
Protiviti (2013): SAP-Access-Management-Governance: Getting-It-Right, Making It Sustainable.
80
Protiviti (2014): Optimizing User Administration in SAP, ISACA Geek Week – Atlanta, August 13, 2014.

45
fewer roles, but also gives users access to transaction codes they might not need. Also, the roles themselves
might have SoD conflicts due to the large number of transactions assigned.81
The intention of task-based roles is to give each user multiple roles, each representing one job task (e.g.,
Release Purchase Requisition). This approach utilizes more roles, but will limit user access to the respective
tasks performed. The decision around using a job based or task-based approach will depend on the overall job
consistency of job positions, and the maturity of HR departments in relation to the integration between SAP
access requests and employee hiring, transfer and termination processes.
Below overview(s) shows some of the characteristics of the Job Based versus the Task Based Security Design: 82

Job Based: Task Based:

• Security is built based on positions/jobs • Security is built based on small, definable

within the organization, such as AR credit
associate.
• Provisioning access is based on job
responsibilities.
• Smaller number of roles per user –
increased risk for granting functionality
more than once.
• Transaction codes and authorizations
typically duplicated in many roles.
• Users may be granted more access than
necessary as a result of “additional job” or
backup responsibilities.
• Appropriate for static organizations.
tasks, executed by the user, such as process
cash receipts.
• Larger number of roles per user – decreased
risk of duplicate access.
• Transaction codes in one roles with minimal
exceptions
• User assignment flexibility – simple to grant
additional access to only the tasks necessary.
• Supports future growth and sustainability –
role modification decreased as a result of
functionality improvements and rollouts.
• Appropriate for dynamic organizations.

Figure 26. Task Based vs. Job Based Security Design.

In a Job Based Security Design, security roles are built based on positions/jobs for a group of users (e.g.
Accounts Payable Clerk):
 Security roles are built based on positions/jobs for a group of users (e.g. Accounts Payable Clerk).
 A single role contains the access to perform a job.
 Transaction codes and authorizations typically duplicated in many roles.

Figure 27. Role-Based Security Design: A single role contains the access to perform a job.

A Task Based design begins by bucketing transactions into one of 4 access tiers: General, Display, Functional
and Control Point. Task-based roles contain access to only one of these tiers.

81
Protiviti (2014): Designing SAP Application Security: Leveraging SAP Access Monitoring Solutions During SAP
Implementations, Upgrades Or Redesign Projects.
82
Jonathan Levitt (2015): IIA Los Angeles SAP Security Presentation, PwC, March 2015.

46
Figure 28 Task-Based Security Design: 4 Access Tiers.

A Task-Based Security Design has the following characteristics:

 Security roles are built based on positions/jobs for a group of users (e.g. Accounts Payable Clerk).
 User are assigned to the tasks needed to perform his/her job (not a job-based role)
 User receives multiple single roles
 Flexibility to each individual user’s role assignments

Figure 29. Task-Based Security Design: User receives multiple single roles.

Below overview shows the advantages that are related to a Job-Based versus a Task-Based Security Design:83
Criteria Advantage
Job-based Task-based
 Restrictive Security +
 Scalability / Ability to Sustain Change +
 Ability to maintain a compliant (e.g. SoD free) environment +
 Limited number of roles per user +
 Limited time to analyse and create roles +
 Ease of Creation / Design of Roles Initially +
 Ability to support identity management tools for user provisioning +
 Ability to support role management / ownership process +
 Avoid functionality duplicated in roles +
 Transparency of security in role +
Figure 30. Advantages Job-based versus Task-based Authorization Concept.

Ad. Single versus Composite Roles

83
Protiviti (2013): SAP-Access-Management-Governance: Getting-It-Right, Making It Sustainable.

47
Another decision to make is whether to use composite roles, which are a grouping of roles held within another
role. It is common for job-based roles to consist of several task-based roles (composite roles). The main
advantage in composite roles is that they provide a simpler user provisioning process since the user will receive
one role. The main disadvantage of composite roles is that users may be granted more access than required
due to additional tasks or backup responsibilities being included in the composite role.

Based on the key SAP security considerations that were explained above (Job Based versus Task Based roles
and Single versus Composite roles), three different design variants for the Role Architecture can be identified.
Below table shows the pros and cons of these three role architecture design variants: (1) Job-based Single
roles, (2) Job-based Composite roles and (3) Task-based Single roles:84

Category Job Single Job Composite Task Singles

Request Access  Simple – 1 role  Simple – 1 role  Complex – multiple; however, more
flexible

Buffer Size  Small, as authorisations not  Can contain duplicate  Can become very large over time
duplicated authorisations
Role Build  Difficult – no shared  Moderate, as utilisation of tested  Straight forward; no knock on affect
functionality components
Role Update  Pro – no impact analysis for  Pro – mass change easy for shared  Easy – change isolated to component
shared single roles components
 Con – change not isolated to
component; large manual  Con – detailed impact analysis
effort for mass change required for changes
GRC Risk  Easy – no duplication  Moderate – multiple singles  No enforced user job standard
Analysis

GRC Mitigation  Possible at role level  Possible at role level  Only at user level

Remediation  Role Update on Large role
Process  Transactions duplicated in
Overview (Who design with specific
can do what?) configuration for each role
 Simple/challenging depending on  Easy if component driven as
design flexibility down to user level
 If task roles utilised in job mapping,  Transparent with task-based roles;
then difference in job function easy however, lack of overall consistency

Ad. Derived versus Enabler roles

While task-based roles determine what users can do, enablers determine where they can do it. From a
technical perspective, an enabler is an authorization only role that grants access to the “where.” They are
similar to derived roles except they have a one-to-many relationship with task roles (whereas derived roles
have a one-to-one relationship with task roles). In its purest form, one enabler role grants the “where” access
for all the “what” roles that a user has assigned to them. The enabler concept is simple to maintain and very
transparent about what controlled information a user has access to. The model works well when going through
upgrades — from an enabler perspective, the key activity when upgrading is to compare the objects in the
enabler to the new objects the upgrade or support pack introduced to ensure the crucial ones are there. 85

Ad. Custom or Pre-delivered SAP Roles

It is also important to note that each SAP system comes pre-delivered with out-of-the-box roles, and an
organization can decide to implement those instead of tailoring their security design. However, it is not
recommended that out-of-the-box be used as a long term strategy to maintain SAP security. These roles are
designed to as one size fits roles, meaning that they have such a wide range of job activities combined in a

84
Dean Platt (2015): Designing and Building Compliant Roles within SAP GRC 10.x: How to Take the First Step, Turnkey
Consulting.
85
PwC Research and Insights (2014): Security Roles: Technical Insights from PwC.

48
single role that it will be nearly impossible to provision these roles to a user without granting excessive access.
Also, out-of-the-box roles may not meet all business access requirements and control restrictions.

Ad. HR or position-based design versus functional design

Another consideration when designing SAP security is the level of integration with HR processes (e.g., hiring,
termination) and overall consistency with job descriptions and positions. In an ideal scenario, SAP roles should
reflect job responsibilities, but if HR departments and positions are not mature or consistent, an independent
security design based purely on job functions may be the best option. For organizations to apply a position-
based design, HR job descriptions would have to be well-defined and consistent across the company. Also,
"Hire-to-Retire" processes would need to be in a mature stage to enable integrated provisioning.

According to Turnkey Consulting86, keys to a successful SAP role architecture or authorization concept are as
follows:
 Follow a risk-based approach
- Least privileged principal with sensitive processes
- Split display and change access
 Plan for the future
- You might not plan on creating derivations for that role now
- Easy to set up, harder to maintain
- Make sure your naming convention allows for future expansions and complexities
 Have a strategy and stick to it
 Automate provisioning of generic access where possible
 Keep it simple (or as simple as allowed …)

3.2.4 Step 3: Role Build and User Assignment

Once the initial SAP role templates have been designed and approved, the roles can be built in SAP and
subsequently assigned to end users. The technical design phase starts with building “master roles” or
“template roles” including the grouped transactions. Building master roles requires close coordination with
the systems integrator and BPOs so that all standard and custom SAP transactions and objects being used as
part of the role design are understood in terms of functionality (e.g., create master data, update financial
statements) and are also properly incorporated in the template roles. The second step in designing SAP roles is
to create “derived” or “child” roles, which is where security restrictions are applied (e.g., company code and
cost center limitations).
Designing roles that are free from SoD conflicts early in the SAP+ project can lead to increased granularity and
more restrictive access, as well as increased transparency related to the authorizations given to a user. In
addition, it can reduce ongoing security maintenance because it makes it easier to respond to changes in user
responsibilities resulting from the implementation of new SAP functionality and/or organizational alignment.
End user role assignment is a critical step when designing SAP application security, due to the different
restrictions that must be applied to users (e.g., some users need access to one, multiple or all company codes
or cost centers, in case of shared service departments).
During these steps, it is also important to leverage SAP GRC AC to confirm that roles are SoD-conflict –free
before assigning them to end users. If master roles have inherent SoD conflicts, all derived roles and
subsequently assigned users also will have conflicts.87

86
Dean Platt (2015): Designing and Building Compliant Roles Within SAP GRC 10.x: How to Take the First Step, Turnkey
Consulting.
87
Protiviti (2014): Designing SAP Application Security: Leveraging SAP Access Monitoring Solutions During SAP
Implementations, Upgrades Or Redesign Projects.

49
 Figure 31. SAP Role Build and User Assignment Process

Configured workflow for user access change requests should not only include the approval of access by a role
owner as well as the security team. The required approvals should also include the following best practice
workflow approval steps:88
 An approval by the user’s manager. This requires that the user’s manager is also tracked in Active Directory
(alternatively allow for the user’s manager to be specified on the user request form).
 A review and approval of segregation of duties, including the assignment of mitigating controls.

KPMG: Step 2. Lay the foundation – Technical Realization

In this phase, the defined segregation of duties rules are technically translated into authorization objects and
transaction codes in accordance with the design of the SAP system. The system is configured to be able to
monitor the segregation of duties rules and the emergency user functionality is configured to realize a quick
win in the Get Clean-phase.

EY: Phase 2 - Technical definition

The company or business unit must map each sensitive transaction to its associated access rights in the
application that enable that transaction. This critical step feeds the data analysis when setting up access
during implementation or to yield the testing results in live environments. While this mapping task may appear
to be trivial, this step is often where many companies encounter problems due to a lack of understanding of
the potential ways a transaction could be executed in a particular application.
Above mapping is the rule-set by which sensitive transactions are tested in the relevant system. For example,
vendor-update rights may be executed through a series of menus within a given application. The presence of
these menus assigned to specific users should be mapped, walked-through and documented in order for the
company to accurately test for a particular conflict. The challenge is that in most modern applications there is
more than one way to execute the same transaction. For example, there may be 20 ways to pay a vendor in
an application, but the company may use only five of them. Moreover, the company is typically not aware of
the other 15 ways and usually does not restrict access to or control these other methods to execute a vendor
payment.
The risk-based SoD process requires a company to discover all the potential methods for executing a
transaction in order to understand the full potential for fraud, not just the limited view of the known
methods. Mapping all of the ways a user could potentially execute a transaction is critical to accurately
depicting SoD.89

88
Los Angeles Unified School District - Office of the Inspector General Internal Audit (2012): Audit Report - GRC
Implementation Review.
89
Ernst & Young (2010): A risk-based approach to segregation of duties - Insights on governance, risk and compliance.

50
Figure 32. SoD Mapping matrix

One of the key fallacies in menu (or access) mapping is that one only needs to map the transactions that are
actually used in the application. While this method will usually capture many of the executed transactions, it
will fail to identify the menus business users do not use but could use to execute a particular transaction. Even
though menus may be deactivated or not provisioned to a set of business users, they must be mapped to be
able to demonstrate they have been considered and it is possible to see the entire rule-set by which SoD
conflicts are being tested.
Exclusions refer to the user IDs and menus or access rights intentionally omitted in the SoD analysis. Not
every user ID that appears in the analysis represents a real conflict. Often system or process accounts, IT
administrators, IT operations and support personnel may have access to multiple conflicting menus. This may
not actually represent a conflict if the goal is to only capture the business users with SoD conflicts.
Alternatively, to facilitate continuous controls monitoring, companies often include IT users in reports on
standard sensitive transaction usage and SoD conflicts. Typically, read-only or inquiry functionality in the
application should be excluded as it does not permit execution of sensitive transactions. Regardless of the
treatment of the transaction exclusion, it is vital to document all omissions, their rationale and to communicate
this information to regulators and compliance stakeholders.90

3.2.5 Step 4: Role and User Access Risk Analysis

At this stage, SAP GRC AC should be leveraged to perform periodic role and user analysis to determine if the
newly designed SAP roles are in compliance with SoD policies. This is done by simulating and monitoring
changes affecting SAP security design, and providing timely feedback to BPOs in case potential conflicts arise.
Risk analysis should be run on a periodic basis, especially after unit and integration testing, which is when the
SAP system design will be updated to accommodate process improvements. It is important to note that the
defined SAP rule set in SAP GRC AC also may change during the course of the SAP+ project, given that new
SAP transactions may be added to “to-be” processes or new custom transactions may be developed.
To ensure SAP environment is “clean” or “conflict-free” post go-live, a sound SAP security provisioning process
must be designed and implemented. This includes procedures that require SAP security teams to perform a
risk simulation in SAP GRC AC prior to granting user access or modifying a role. This simulation will determine if
role or user changes are posing SoD or excessive access security risks. In addition, continuous monitoring
procedures must be established and followed as the project go-live date approaches. Detective SAP security
monitoring processes also should be designed (and established), including generating periodic SoD violation
reports reviewed by BPOs and role owners to validate security changes. For SAP upgrade or security redesign
projects, post go-live activities may also include additional change management processes to assign and
manage new roles and, over time, to discontinue the use of legacy roles. 91

90
Ernst & Young (2010): A risk-based approach to segregation of duties - Insights on governance, risk and compliance.
91
Protiviti (2014): Designing SAP Application Security: Leveraging SAP Access Monitoring Solutions During SAP
Implementations, Upgrades Or Redesign Projects.

51
It also recommended that management define and document a formal process to govern the changes to the
SAP GRC rule set. This process should include the approval of changes by relevant business owners as well as
an overall business owner for certain types of changes (e.g. deactivation of risks, changes that cross business
functions, etc.):92
 In addition to establishing a formal change management process for modifications to the rule set, a process
should be defined to periodically review the rule set to confirm that the risks defined are still relevant and
to adjust the rule set as required based upon changes within the case study object organization.
 Finally, a process should be established as part of the SAP change management process to analyse new
custom transaction codes to determine if they should be included in the SAP GRC rule set.
 Risks for business functions that are not planned to be utilized after the implementation of the ERM
projects would not be disabled. Not disabling would result in the potential reporting of irrelevant risks.

KPMG: Step 3. Lay the foundation – Technical Realization

In this phase, based on the defined ruleset it is determined to which extent the desired segregation of duties is
actually present. Breaches of the segregation of duties are reported in this phase.

KPMG: Step 4. Lay the foundation – Risk Remediation

The objective at this stage is to eliminate the identified risks by making changes to granted authorizations or
by making changes in the authorization concept. Quick wins can be achieved through the deployment of
advanced data analysis techniques. These analyses go beyond determining whether a transaction code is
started, and determine whether and, if so, what changes or bookings a user actually executed.

KPMG: Step 5. Lay the foundation – Risk Mitigation

The objective at this stage is to mitigate the remaining risks, whereby compensating control measures should
be established and documented in the application.

EY: Phase 4 - Mitigation

According to EY93, the objective of the mitigation step is to limit the potential impact of a SoD conflict violation.
This mitigation phase can be completed concurrently with remediation; or depending on the objectives and
compliance time frame, mitigation can be performed last, when conflicts have been reduced to their absolute
minimum. Mitigation looks at each of the identified SoD conflicts and asks, “Which control is in operation to
reduce the residual risk of a particular SoD conflict such that it does not pose a significant threat to the
business?” In other words, can the company identify any existing controls that will prevent or detect the
unauthorized or fraudulent activity? Many companies will choose to mitigate every potential conflict in order
to have a safety net of control in place should a conflict arise. This is a sound and practical strategy for
companies looking to control unforeseen or unpredictable risk.
Mitigation does not fix or correct the conflict; rather, it allows for the conflict to exist in the system and creates
or cites existing controls that compensate for the risk of excessive access. When a company chooses to mitigate
a SoD conflict, it accepts the risk associated with that conflict and attempts to compensate through the use of
application, IT-dependent or manual controls (or some combination thereof). For example, a mitigating control
typically seen in the vendor master update or vendor payment scenario is the use of automated approvals for
vendor check writing or the use of month-end vendor reconciliations or reviews. These detective controls may
provide management the comfort needed to allow the SoD conflict to exist while catching unauthorized activity
through its financial controls.
When leveraging mitigating controls, management should develop a conflict-by-conflict analysis to document
the existence of specific key controls that mitigate the risk related to the particular conflict. Management and
the auditors can assess the strength of the mitigating controls and conclude the appropriate level of reliance to
be placed on the controls’ ability to manage — to an acceptable level — risk. This important aspect of the risk-
based approach enables management to accept that certain conflicts will exist within their pre-defined
tolerated levels of risk, thereby determining their residual risk threshold.
Some (additional) mitigating controls considerations or good practices that can be applied are:
 For financial risks, document the financial statement assertions related to the conflict risk. Specifically,
the assertions and objectives addressed by the cited mitigating controls are: (1 Completeness, (2) Rights

92
Los Angeles Unified School District - Office of the Inspector General Internal Audit (2012): Audit Report - GRC
Implementation Review.
93
Ernst & Young (2010): A risk-based approach to segregation of duties - Insights on governance, risk and compliance.

52
 and obligations, (3) Valuation or allocation, (4) Existence or occurrence and (5) Presentation and disclosure.
This is important as it enables the company to demonstrate that the assertions related to the mitigating
controls adequately address the assertions related to the conflict risk.
 More than one mitigating control can address a conflict. Implementing a balance of preventative and
detective controls helps manage the risk should one control fail and supports the use of a risk-based
approach. Mitigating controls should address a precise risk. Generally, it is insufficient to deploy “budget
to actual reviews” as the mitigating control for all SoD conflicts as this control is too general; granularity of
controls is important when attempting to detect and prevent fraud or material misstatement. The conflict
matrix should document precisely why each control mitigates the specific conflict risk. This will enable
management to more effectively address risk and serves as a justification to auditors and regulators as to
why the control was selected and its relevance as a mitigating factor.
 List who (name and job title) performs each of the mitigating controls in the company, since it is
important to know if the person performing the mitigating control is also one of the conflicted users. The
level of reliance that can be placed on the mitigating control is greatly reduced (if not eliminated entirely)
when personnel who are in the conflicted population also perform the mitigating controls. Ideally, this
scenario should be remedied through reassignment of the control to another non-conflicted user or
elimination of the user from one or both of the conflicting sensitive transactions.

EY: Phase 5 - Remediation

The goal of the remediation phase is the permanent correction of SoD conflicts. Remediation techniques
include role redesign, role clean-up, user appropriateness review and SoD tool implementation. A combination
of people, process and technology changes help sustain effective control and compliance. There is no
proscribed leading practice or method for remediating conflicts. Every scenario is unique, based on the degree
of complexity and extent of the conflicts in a given environment.
Remediation initiatives generally fall into two categories: tactical clean-up of the user population and
strategic role redesign. The tactical component represents the items that can be addressed quickly, while role
development typically involves a full complement of organizational changes in people, process and technology.
The choice of tactical or strategic paths is not an either-or proposition; most companies execute a combination
of approaches in a phased time frame. The decision to pursue a particular remediation path depends on the
complexity, degree of severity of the SoD conflicts and the mandated time line.
 Tactical role clean up: Tactical user population clean up refers to the process of reviewing the role or
security model to evaluate whether both sides of the conflicting transactions are required for a particular
user to do his or her job. This clean-up process requires the company to analyse a particular role and the
conflicts that exist within that role in order to establish a clean, conflict-free role or security model.
Misconfigured roles and security models are often the source of SoD conflicts. For example, some
applications are configured for maximum flexibility and agility — in other words, anyone can do anything.
While this creates a very easy-to-use and flexible system, it can also result in control deficiencies if access is
not separated through the customization of roles. Many companies have developed the security aspects of
enterprise roles without considering the sensitive transactions that must be segregated. Roles alone cannot
be used to test for SoD conflicts; rather, a company must look to the lowest level of security (i.e., menu
item, screen, executable, transaction code) that make up a particular role to understand what transactions
a user can execute. However, roles can be leveraged to correct SoD conflicts by creating a known effective
role model, thereby establishing consistent enforcement of that model through the application’s security
controls. This short-term tactical role redesign can often easily correct many conflicts, while leaving the
more difficult user conflicts to be addressed through a strategic approach.
 Strategic role redesign: Strategic role redesign seeks to define what constitutes SoD conflict free access
across the company. It maps job function and responsibility in the business to the required access rights in
the system. This approach is typically used when the existing role model is heavily conflicted and cannot be
salvaged through clean-up initiatives. Strategic role design builds sustainable capabilities and processes that
serve to maintain the “cleaned” role structure.
Once remediation is completed, relevant people, process and technology governance activities must remain
in place to help ensure the situation does not arise again. It is critical to assign accountability for the tasks
of role maintenance, user administration and SoD rule definitions. Periodic testing and conflict checks
should be incorporated into provisioning processes. A critical success factor is to support the redesigned
processes with the appropriate technology.
Some (additional) remediation considerations or good practices that can be applied are:

53
 Default access — Star or default access (known by many names depending on the system) provides the
standard set of access rights to every user registered on that application. This default access provides a
user with the system’s standard minimum functionality. For example, all users of a particular system
should be able to see the log-in screen, help menu and policy banner screen. These three screens or menus
would be considered default access. Risk arises when companies assign default access to sensitive
menus, transactions or security levels. Default access should be assigned sparingly and careful
consideration given to any menu or security level to which it has been assigned.
 Reviews — User appropriateness reviews provide an easy and effective way to reduce the number of SoD
conflicts revealed in the testing process. The activities of users without proper authorization and
documented access can make it difficult for the company to define proper user access levels. Companies
often find that users are granted additional access over time as their responsibilities and job functions
change, but the de-provisioning of unnecessary (or inappropriate) access does not always happen, thereby
further compounding the SoD problem. A careful review of the user population — determining whether
users should have access to a particular role or group — can correct this situation. A simple check of the
user population, in the context of job title or function, can be used to identify such SoD conflicts. Once
identified, such SoD conflicts can be eliminated.
 Non-standard IDs — Non-standard user IDs and accounts indicate deviations from the standard naming
conventions of the company. These accounts should be investigated for inappropriate access and
potentially changed to meet company policy naming conventions. For example, if the standard naming
convention is the first initial of the first name plus the last name (i.e., John Smith is jsmith), specific
attention should be paid to naming conventions outside this policy. Thus, if instead of seeing “jsmith” one
noted “john.smith,” this should raise an alarm and be investigated for inappropriate access. The risk is that
this user may have multiple accounts that, when used in combination, constitute inappropriate access per
the defined SoD business definition.
 Terminated employees — Though expired and terminated user accounts fall within the realm of logical
access, examining the current user population for terminated employees from the human resources (HR)
list is vital. This step not only reduces the number of users to be analysed, but establishes the population
on which to base the SoD testing and may even help reduce licensing costs.
 System access — Users with direct access (system access) to the lowest level of security (i.e., menus,
screens, transaction codes) should be carefully analysed. This represents a potential security loophole
since individual users may be able to gain access rights without following the standard user administration
process. The problem often occurs when consultants, contractors or specialists require access to specific
system functionality and bypass roles in favour of assignment to individual menu items or screens outside
the normal provisioning process.
 System accounts — Generic, shared and powerful system accounts (that users can log into) present a
challenge as it is impossible to tell with certainty who has used that specific account. Since the SoD analysis
is concerned with individual users who have the ability to execute sensitive transactions, generic or shared
accounts (especially shared super user accounts) negate the aim of the analysis. Powerful system accounts
only present a problem when these accounts are not locked-down and can be logged into by users of the
system. These unsecure accounts limit the ability to monitor who is executing which sensitive transaction.
All that is known is the responsible account, not the actual user. To prevent unauthorized activity, the
company should ensure that it is not possible for a user to log into the system or process accounts.
 Master record source — When a company establishes a master record source, it has taken the first step
in understanding the conflicting access rights in the system. A master record source is a single view of
the user population and all associated access rights of users. Since many companies maintain disparate
and disconnected user databases, this task is often more challenging than it sounds. The undertaking is
easier when supported by policies such as standard user ID naming conventions. This makes it less
difficult to compare a user ID for conflicting access across multiple systems. Otherwise, user IDs with a
common identifying trait — such as employee number, email address and user ID — must be linked across
various systems. For a company with thousands of employees and dozens of systems, this process can be
tedious but it is necessary for an accurate view of the conflicts.

Good practices and recommendations from other sources

According to InteGRC94 it is recommended that:

94
Fahri Batur (2013): Access Control Product: High Level Design, InteGRC, 4th November 2013.

54
 Workshops are held within the organization to identify mitigating controls and where appropriate,
leverage existing controls based on business processes.
 Specific details on the parameter configuration of the Access Risk Analysis (ARA) submodule will be
included in a (detail level) design document.
 The assignment of Emergency Access Management IDs (EAM or FireFighter IDs) to end users (once in
business as usual) will be facilitated by SAP Access Request Management submodule.
 A suitable and sustainable role naming convention is in place so that BRM can be configured to leverage
the naming convention.

3.2.6 Step 5: Security Testing and Go-Live Preparation

SAP security Unit Testing (UT) and User Acceptance Testing (UAT) are critical steps to ensure users
experience minimal access issues prior to go-live. SAP security testing includes executing all SAP transactions
within a role to confirm that the role has required transactions and authorization objects to complete the
process (e.g., display, update and post a financial transaction). These steps should be performed in conjunction
with project functional testing (during SAP implementations or upgrades) or before assigning the new role in
the production environment (during security redesign projects). Security testing also should include formal
SoD and sensitive access reviews to confirm the newly created or updated SAP roles are as SoD conflict-free
as possible, and that access to key functions (e.g. update vendor master data, update chart of accounts) is
properly restricted.
Involving SAP security teams in early stages of the functional testing phase allows the discovery of potential
security issues before it is too late – or costly – to modify roles. It is also very important for the final UAT
process to create test users in the Quality Assurance environment with the SAP roles to be used in the
production environment (i.e., users with accurate SAP role assignments). This will allow proper identification
and remediation of security changes, including verification of “authorized conflicts” and resolution of
“unauthorized conflicts” prior to going live with the SAP+ project.
Working closely with BPOs, role owners and the SAP security team to remediate unauthorized conflicts by
regrouping the transaction codes within the conflicting role(s) or reassigning the roles for the conflicting
user. For SoD conflicts that cannot be resolved for a business-approved reason, such as limited headcount,
mitigating controls should be identified and documented. 95

EY: Phase 3 - Testing

The testing phase draws on data from the business definition and technical definition phases to produce an
analysis of users with SoD conflicts. The results highlight the SoD conflicts in a number of ways — by user and
by role for example — and shows the extent of the conflicts among the company’s user population. This
analysis, in combination with the business and technical definitions, typically serves as the compliance testing
package disclosed to management, audit parties and regulators.
Very few companies have just one system or one single platform on which key sensitive transactions are
executed. Transactions and financial statements are often processed through an interconnected portfolio of
applications and automated business processes. Typically, users have access to numerous systems when
executing a particular job function. This access across multiple systems often yields the potential for fraud and
control issues. Consequently, it is essential that the company not only perform intra-application (i.e., within
one application) testing, but cross-application (i.e., between two or more applications) testing to reveal the
underlying risk of a SoD conflict.
When a single individual is able to execute end-to-end processing of a transaction, this indicates a lack of
control over the multiple steps within a single business process. Typically, in this scenario, a user can complete
a whole process — from initiation and authorization to approval and execution — without any checks or
balances. This type of systemic problem can occur in lean workforces or departments where job responsibilities
are shared (i.e., anyone can serve as a backup for anyone else). Data analysis may detect the same users in
multiple conflict tests within a particular business process. If this scenario arises, the company may need to
place special emphasis on the use of mitigating controls or consider fully remediating the issue by
redesigning the process entirely. This issue is especially important to company workforce downsizing. When
employees who are in charge of key processes are released (and not replaced), job functions or roles are often
combined. What was once a segregated access model now becomes a heavily conflicted population of users
with significant control issues. Smart companies assess the SoD impact of employee terminations and plan

95
Protiviti (2014): Designing SAP Application Security: Leveraging SAP Access Monitoring Solutions During SAP
Implementations, Upgrades Or Redesign Projects.

55
accordingly prior to actual termination of personnel. Where formerly segregated processes must be
combined, strong mitigating controls should be applied and monitored in the interim.
No two SoD conflicts are equal; each conflict poses a different risk to the business and ideally, each conflict
should be rated according to the likelihood and impact of a user executing the conflicting transactions.
Companies have adopted many schemes and notations for risk-ranking their conflicts. Companies have defined
tiers of high, medium and low based on the output of their risk calculation. It is not uncommon to see conflicts
deemed “prohibited” within the risk criteria, indicating conflicts that are unconditionally barred from
provisioning. These are typically transactions that — when executed together — have no potential for
mitigation, or there is no business justification for an assignment of conflicting access rights. Whatever the
classification notation may be, it is important for the company to prioritize the conflicts so that remediation
and management of the user population can be focused on those conflicts with the greatest potential for risk
reduction. The correct assessment and definitions of how to manage each of the risk ratings is a key factor in
delivering benefits from a risk-based approach.
Some (additional) testing considerations or good practices that can be applied are:
 The tone at the top drives the level of commitment from all personnel. Many companies fail by placing
little emphasis on SoD, resulting in significant concerns or worse, pervasive fraud and control breakdown.
 IT, finance and other management stakeholders must take co-ownership of the SoD process. Finance
understands the financial impact associated with the business processes, risks and mitigating controls
better than any other function. Business management will have the clearest view on the operational
impact. IT understands how to translate that into system data, reporting and technical remediation. Either
way, one organization cannot simply point to the other or transfer responsibility to the other party.
 Where the driver for a SoD initiative has been an audit finding, it becomes extremely important for the
company to work with its auditors on a regular basis. The auditors can often provide advice and feedback,
helping to keep the process focused on risk rather than over-compliance.
 SoD is not a project, but a process. It needs to continue into the future. The longer term undertaking is
much easier if tasks are performed properly early on, thus an investment in sound practices and processes
today will inevitably yield savings down the road.
 Where a specific compliance deadline is driving an organization to address SoD, the timing of testing is
critical. A company should not wait until the last minute to conduct the activities. Allowing for adequate
time can help when controls need to be remediated and retested, or user access needs to be modified in
the system. The testing timeline should be developed with the input of key business and IT stakeholders
and the audit team(s). Proactive involvement of the auditors helps prevent unnecessary audit fees and
allows for streamlined, efficient testing and reporting.

3.2.7 Step 6: Move to Production and Support

Once testing is complete, the newly designed SAP roles can be migrated to the production environment
according to the organization’s change management policy and users can be assigned. No matter how well UT
and UAT are performed, it is very likely that access issues will be encountered during go-live, stabilization, and
the post go-live period due to the overall complexity of implementing or changing ERP systems and processes
in an organization.
It is critical to establish a support team specifically assigned to address any SAP access issues during go-live
and stabilization activities. This team not only can help resolve access issues on a timely basis, but also run
access risk reports to determine if security changes will result in SoD or other access risks. Also, a
communication plan should be established to ensure affected users are aware of any changes and support
protocols related to go-live of the SAP system.
A common practice during SAP implementation and upgrade projects is to allow for temporary broader access
for “power users” during the go-live and stabilization period. This is done to help with stabilization of the new
system, to ensure users are capable of performing job functions during and after go-live, and often is
performed using SAP GRC AC to review transaction and super-user action logs. It is important to review and
remove this temporary broader access after the new implementation is stable.96

3.2.8 Step 7: SAP GRC AC Post Go-Live and Ongoing Management & Monitoring of the Security

96
Protiviti (2014): Designing SAP Application Security: Leveraging SAP Access Monitoring Solutions During SAP
Implementations, Upgrades Or Redesign Projects.

56
 Environment
Centralizing and automating the user provisioning process as much as possible leads to greater efficiency and
control (see figure below). Most governance leaders choose to deploy a standard access management solution,
such as SAP GRC AC, which can be complemented with an identity management tool, like SAP NetWeaver
Identity Management, to automate user access management tasks. These tools can help ensure required
approvals are consistently and efficiently obtained during the provisioning process, test security changes for
potential SoD violations prior to granting access, and apply mitigating controls prior to moving the change into
the production environment. In addition, these tools can allow for significant gains in efficiency by automating
the creation of users and the associated access once all approvals have been obtained.97
In the past, it often was perceived that the IT organization owned or was responsible for access rights
pertaining to business users. While IT plays a critical role, it is primarily a business responsibility to ensure that
management of user access activities (i.e. authorizing and initiating additions, modifications and
terminations to user access tables) does not result in inappropriate conflicts or access to sensitive
information. In complex ERP systems, IT personnel can provide critical expertise on how best to establish and
build user access profiles according to the organization’s business requirements.
While IT departments should ensure employees in the IT group have adequate access consistent with sound
segregation of duties principles and appropriate limitations on access to sensitive functions, these
employees should not be responsible for interpreting business user access requests for propriety.
Procedures should be defined for: (1) handling authorization requests which compromise the defined rules,
(2) obtaining appropriate approval of specific exceptions and (3) modifying the requested access in such a
way that the defined rules are not compromised. Procedures also should be in place regarding notification of
management personnel for identified compliance exposures due to a user’s system privileges.98
Below overview99 shows the key elements in the security provisioning process. According to Protiviti,
centralizing and automating the provisioning process as much as possible leads to greater efficiency and
control. Deploying a standard access management solution, such as SAP GRC AC, which can be complemented
with an identity management tool, like SAP IdM, enables automating user access management tasks and
delivers visibility across the enterprise. These tools can help ensure required approvals are consistently and
efficiently obtained during the provisioning process, test security changes for potential SoD violations prior to
granting access, and apply mitigating controls prior to moving the change into the production environment.

Figure 33. Key Elements in the Security Provisioning Process

According to Protiviti, an effective program with regard to SAP Access governance structure and processes –
and which can help ensure SAP security will be maintained for the long term - has several core pillars, as shown
in below figure:100

97
Protiviti (2013): SAP-Access-Management-Governance: Getting-It-Right, Making It Sustainable.
98
Protiviti (2006): Guide to the Sarbanes-Oxley Act: Managing Application Risks and Controls.
99
Protiviti (2013): SAP-Access-Management-Governance: Getting-It-Right, Making It Sustainable.
100
Protiviti (2013): SAP-Access-Management-Governance: Getting-It-Right, Making It Sustainable.

57
Figure 34. SAP Access Management Organizational Pillars

The first step to building a sustainable SAP security environment is to develop a strategic vision for access
management that aligns with business requirements and risk tolerance. This will enable security to be
addressed in an organized, efficient and proactive way, while minimizing exposure to major access
management risks. Organizations also need to identify policies that make access management standards clear,
as well as procedures to enforce those standards. It is necessary to check periodically that policies are relevant,
understood and followed.
Key performance indicators (KPIs) and metrics that enable the governance committee to manage the
governance process also must be established. Examples include statistics on user SoD violations, role SoD
violations, provisioning of service-level agreements (SLAs), and remediating tracking. A few KPIs are:101
• # users having high/critical violations
• Total # of high/critical violations at user level
Managing users •Average lead time for processing 'create', 'change' and/or
'remove' access requests
• Average transactions per user

• # (single/master, composite or job) roles having High or Critical

SoD violations built into them
Managing roles • # roles not been assigned to users
• # of transactions per single/master role
• # duplicate transaction codes between roles

• How many firefighter and user accounts exist by functional area?

• How often are firefighter accounts being used?
Managing emergency access
• Are firefighter logs being reviewed in a timely manner, and are
issues addressed appropriately?

Figure 35. Overview of KPIs with regard to SAP-Access-Management-Governance.

Based on the above, I envision the benefits from a SAP GRC AC implementation (whether or not in combination
with a SAP Authorization Role Redesign project) to be presented in a format as shown in below overview.
Values shown are hypothetical data and do not reflect the case study object.

101
Protiviti (2013): SAP-Access-Management-Governance: Getting-It-Right, Making It Sustainable.

58
 Before Security and GRC Redesign After Security and GRC Redesign % Reduction

Lead time for provisioning role to New Lead time for provisioning role to
15 days 4 hours 98. 9%
User New User

# of transactions per single/master

# of transactions per single/master role 77 7.3 90.5%
role

Average transactions per user 2,281 Average transactions per user 371 83.7%

Total # of high/critical violations at Total # of high/critical violations at

13,054,616 3,149 99.98%
user level user level

Intra Job Role SoD Conflicts 94,458 Intra Job Role SoD Conflicts 3 99.997%

In addition to the elements above, it is essential to work with Business Process Owners (BPOs) and secure their
buy-in throughout the development of the governance processes. This helps ensure the governance initiative
will add value to the business.
Furthermore, periodic self-reviews of the governance process will ensure it continues to accomplish the core
objectives. For example, in addition to monitoring the KPIs above for unexpected anomalies or trending to
evaluate the efficiency of performance, there should be a periodic review of each area to evaluate quality of
performance (e.g., reviewing a sample of management waivers for SoD risks to determine whether the issue is
properly considered and mitigating actions are being taken). Another consideration is whether the reasons for
emergency access checkouts are consistent with approved use (or whether elevated access is misused).
Overview below shows the organizational structure that, according to Protiviti102 is optimal for the long-term
success of access management controls. As shown in the overview, at its center is a governance lead: a
subject matter expert who reports to executive management. This person drives the day-to-day access tasks
for access management, coordinates policy changes, and is the primary contact for the business. The
governance lead also coordinates the governance committee, which consists of stakeholders from the various
organizations, such as information systems (IS), finance, internal audit, and the BPOs. The governance team
designs, implements and executes controls. It also owns the description of roles and responsibilities.
Information from the governance team is communicated to the user community and supported though access
management single point of contact within the business and associated BPOs.

102
Protiviti (2013): SAP-Access-Management-Governance: Getting-It-Right, Making It Sustainable.

59
Figure 36. SAP Access Management Governance Organization

Furthermore according to Protiviti103, a security governance policy should be in place that contains standards
for the SAP ECC production environments to ensure consistency and minimize significant risk to the
environment. The policy should be designed to create standards around the following key areas:
 User Access Management
 Custom Program and Table Security Requirements
 Backend System Configurations
 Role Creation and Maintenance Standards
 Password Management
 Security Parameters

Furthermore, independent reviews of user access rights should be performed periodically and should
consider multiple elements. These elements include, among other things:104
 Evidence of the application and data owners' approval and monitoring of the propriety of the access
“touch points” identified.
 Appropriate consideration of system administration access for the transactions being reviewed.
 Evidence that critical segregation of duties rules are not being violated due to personnel access
modifications since the prior review.
 Organizational policies regarding access provisioning are being followed.
 Evidence that specific critical transactions were not inappropriately accessed since the previous review.
If changes are needed based on these reviews, a standard process should be in place to ensure these changes
are handled in an expedient manner. If there are findings in the access security area that evidence a
breakdown in the security administration process, a root-cause analysis should be undertaken and the matters
resolved on a timely basis.

KPMG: Step 6. Stay Clean – Continuous Management

The objective of this phase is to optimize the user management and role management process through the use
of Access Control application functionality.

103
Protiviti (2014): Optimizing User Administration in SAP, ISACA Geek Week – Atlanta, August 13, 2014.
104
Protiviti (2006): Guide to the Sarbanes-Oxley Act: Managing Application Risks and Controls.

60
KPMG: Step 7. Stay Clean – Continuous Monitoring
This stage involves the assignment of responsibilities and defining procedures for periodic monitoring of
assigned authorizations and breaches with regard to segregation of duties.
A number of the Access Control-applications that are available in the market, offers the possibility to integrate
them with Continuous Control Monitoring (CCM) applications. SAP GRC AC can thus be integrated with SAP
Process Control, whereby, for example, the effectiveness of the mitigating controls that were assigned in SAP
GRC AC can be determined. By making use of the 'test of effectiveness' functionality in SAP Process Control, it is
possible to determine if the mitigation controls have actually been executed and it can also be determined
whether the control is effective.

Good practices and recommendations from other sources: (1) Governance

An appropriate governance is important to the long term relevance of GRC as it helps to: (1) incorporates
changes in the environment, (2) establish ownership and responsibility and (3) drives remediation decisions.
Key areas to consider for a governance team should be around:105
 Ownership (GRC risks, SAP roles, mitigating controls)
 Risk level of GRC risks and expectations
 New functionality

Governance Issue Sub issue / Sub questions

Domain
Ownership Who approves access?  Based on roles, Manager, GRC Risk
Who approves assigning a mitigating control
Who defines the risk/function and approves  What is included in a GRC risk/function (how is this
changes? determined)?
 What is the defined risk level?
Risk level What does each risk level mean  Are users allowed to access certain transactions at all?
(low/medium/high/critical)?
What are the expectations for each risk level  # of violations
 Remediation timeframe
New What is the process to identify new  T-Codes
functionality functionality added to the system?  New Modules
 Custom & New Authorization Objects
How are these analysed and included (if
needed) into a ruleset?
Ongoing Access Provisioning 
Preventative SoD/sensitive access analysis
processes 
Appropriate approvals (role owner, manager)
Periodic Access Reviews 
Detective SoD/sensitive access analysis
Mitigating Control Reviews 
Review of users with sensitive access based on
business need
Figure 1. Key areas to consider for an Access Control governance team

Since changes (e.g., role changes, custom transactions, new business processes, configuration changes) can/do
happen every day, it is important that organizations make sure that the rules/ruleset does reflect changes in
the organization's environment. SAP106 therefore recommends to establish and document a change
management process for modifying risks/rules in AC. According to SAP, it is critical that an organization's rule
change process is formally documented to provide proof to management and auditors that the rules are
appropriately controlled. SAP has listed the following considerations when organizations do update their
ruleset:
Functional Technical

What was your starting point? What was your starting point?
 Did you deactivate any business processes, risks during  Did you deactivate any t-codes, authorization objects
your initial implementation? during your initial implementation?
 Should they still be deactivated?  Should they still be deactivated?

105
ISACA (2012): Auditing SAP GRC (The Coca-Cola Company), ISACA-August 17, 2012.
106
Erwin Albers (2015): Rethinking Segregation of Duties: Where Is Your Business Most Exposed?, SAP Netherlands.

61
 Functional Technical

What has changed since your last review? What has changed since your last review?
 New business units  New systems in the landscape
 New business processes  New authorizations or t-codes in use
 New business process owners
 SoD vs. sensitive access risks

Good practices and recommendations from other sources: (2) Fire Fighter or Emergency Access
According to the Customer Advisory Group107, the following pros and cons can be identified with regard to the
Role-Based Fire Fighter concept versus the Fire Fighter ID concept:
Role-Based Fire Fighter Comment / Explanation (with regard to typical risks with
Fire Fighters IDs the Role-Based Fire Fighter Concept)
Assignment to users done  While using the Fire Fighters role-based concept no
centrally reason code can be entered and no comment be made.
Fire Fighter Access is In contrast to the Fire Fighter ID concept, the user does
maintained in remote NOT enter the information. The controller who has to
system check and verify the logs does not know why a change is
SoD analysis possible for being made.
user including FireFighter
access  Under the Fire Fighters role-based concept, the end
Fire Fighter Assignment users do not know they are using Fire Fighter roles. Due
reduces number of SoD- to the missing log on, the end users do not see any
Conflicts for users difference between using a Fire Fighter role and the
other regular roles assigned to them. This can lead to
Fire Fighters can be easily extensive use/ misuse of the Fire Fighter roles.
split up
Functionality can be  The role-based access does not provide logs for systems
grouped to reduce number where the access is given based on authorization
of logs objects and not on transaction code level.

Customer Advisory Group recommends Fire Fighter or Emergency Access to be used for:
Activities for which FF or Comments and/or examples
Emergency Access is to
be used
1. Emergency Access  System Issues (Administration usually does not have global access rights with their
regular user ID)
 Ability to replace colleagues who are out of office (unplanned)
2. Critical  Open/Close system for Customizing/Development
Access/Access Rarely  Year-End Closing activities
Required  Upload of data into PROD systems
 Import of transports into PROD systems
 Depreciation run
3. Helpdesk and  Helpdesk and Support usually have display access with their regular user ID but must
Support have change access from time to time to test issues the end users are having
4. Instead of  If a user has a SoD issue with the regular user ID, part of the access can be given using
Mitigations the Fire Fighter concept instead of assigning a mitigating control. This option should be
considered only if the activity is rarely carried out (e.g., 6 times per year review of Fire
Fighter logs versus 12 monthly mitigation control activities).
5. Performance Critical  E.g., MRP run
Activities, which
should be carried out
only by one person
at a time

According to Customer Advisory Group some common mistakes with regard to the content of Fire Fighter or
Emergency access are as follows:
 The access given to Fire Fighters is too wide

107
Dina Shahin (2015): Leading Strategies to Enforce Your Organisation’s Access Policies Using Emergency Access
Management in SAP Access Control, Customer Advisory Group.

62
 - The access given does not reflect the organization’s needs
- Controllers are not able to review the logs appropriately
- Owners do not understand the content of the Fire Fighters
 Too many Fire Fighter IDs are set up
- More Fire Fighters are set up than required
- The maintenance of those Fire Fighters is work intensive

Derived from above common mistakes, the recommendations shown below can be made with regard to the
content of Fire Fighter access. Recommendations 1 to 5 do address common mistake with regard to the access
given to Fire Fighters being too wide, whereas recommendations 6 to 8 address the common mistake of setting
up too many Fire Fighter IDs.108
Recommendation Comment / Clarification Benefit

1. A Fire Fighter can be   Logs are shorter and easier to review

set up for modules  Access time for Fire Fighters is shorter, because of the Fire
or sub-modules or Fighter restrictions
according to  Fire Fighters can be assigned more appropriately because
organizational the content is more restricted (also the users who should
requirements get access to the Fire Fighters are more restricted)
 Fire Fighter Controller is able to read and understand the
logs
2. A Fire Fighter can be   Sensitive Actions are not buried in long logs
set up for sensitive  Fire Fighter Controller has a good overview of what is going
actions on
3. Fire Fighters can be  E.g., if a user only requires certain  Instead of performing a mitigating control once per
used instead of transactions only once in a while and this month/per week for that user, only the Fire Fighter logs
mitigating controls transaction is a risk together with the have to reviewed once in a while
access required on a daily basis, the
transactions only required once in a
while can be given out using a Fire
Fighter
4. A Fire Fighter should  Investigations of a problem in Display  Separation ensures also that the users are not using the Fire
not contain mode can be done using the regular user Fighter all day long
“Display” or ID. Only if changes must be done, a Fire
“Reporting” access Fighter can be used
5. Fire Fighters can be   This assignment ensures that the Fire Fighter is in place
assigned to users for when required
a long time
6. For performance of  This applies to access to functionality 
Critical Access, set that can or should be carried out only by
up only ONE Fire one person at a time (e.g. MRP Run,
Fighter ID SSC4 (i.e., open/close a Production
system for customizing/development)
7. Fire Fighter IDs can  Fire Fighter IDs should only be used for  Avoid setting up too many Fire Fighter IDs
be shared and a very limited time to fix issue that  Discourage users to use a Fire Fighter ID all day long or users
should be shared cannot be fixed with the regular user using it unnecessarily for hours
ID.
8. Fire Fighter IDs with   This ensures that if a Fire Fighter ID is in use another Fire
the same Fighter can be used
functionality can be
set up multiple times
and be assigned to
the same group of
users

108
Dina Shahin (2015): Leading Strategies to Enforce Your Organisation’s Access Policies Using Emergency Access
Management in SAP Access Control, Customer Advisory Group.

63
Customer Advisory Group recommends that Emergency Access Management Review consists of the following
elements:109
 Review of Fire Fighter Users
- Sometimes assigning a Fire Fighter ID may be the quicker solution to a missing access problem. The
users accumulate access to Fire Fighter IDs. Once a year a review should be done on if the roles
required by a user using a Fire Fighter ID can be assigned directly to him/her.
 Review of Fire Fighter Access
- Once per year a review should be carried out and the executed transactions – using Fire Fighter
Access - should be checked on whether they are included in roles that can be requested by end
users. Many users may use Fire Fighters because requesting a role change is too complicated or takes
too much time.
- Organizations may find a group of Fire Fighter Users using the same transactions and another group of
Fire Fighter Users using another group of transactions. This can/should result in a split of Fire Fighter
IDs that are more appropriate to those 2 groups. This review can be carried out using the FF-logs and
Pivot tables showing the clusters of users and transactions
 Review of Fire Fighter Assignments
- Once per year a review should be carried out to find out which users have access to which Fire
Fighters, but also to ensure that (i) obsolete access is removed (e.g., user is not responsible for the
task any longer) and (ii) unnecessary assignments are removed (e.g., Fire fighter access was granted
in case the user has to replace a colleague, but the department has grown since that time and a
replacement is in place)
 Review of Fire Fighter Logs
- After a Fire Fighter was used, logs are created that contain the changes done using the Fire Fighter. It
is recommended that it is defined how the logs are generated, to avoid Controllers waiting for logs or
not knowing that a Fire Fighter was used and not reviewing the logs. Recommended to define a
standard Notification Type for the organization.
- Usage of the EAM workflow in SAP GRC AC is recommended, so the Fire Fighter Controllers receive a
Workflow notification and the reviews done are recorded centrally.
- After the implementation of new Fire Fighters (IDs), and once per year, a review should be carried
out. Logs should be reviewed for (i) length (number of entries) and (ii) for the length of time a Fire
Fighter was used by a person
- A policy should be in place that forbids users to use Fire Fighters extensively. Users should either use
their own regular user ID or request missing roles. Fire Fighters should only be used in emergency
cases or exceptional cases, not for hours.

Good practices and recommendations from other sources: (3) Access Violations Management
According to Greenlight Technologies Inc.110, organizations that have implemented SAP GRC AC still face
challenges with access management:
 For existing SAP GRC AC customers, staying clean still requires a lot of effort to mitigate SoD violations.
Mitigating controls are mostly manual controls and there is no ability to manage by exception.
 Lack of understanding with regard to the risks associated with SoD that remain: there is a lack of visibility
to true financial exposure.
 Enterprise-Wide Access Compliance. More than ever before companies are also enforced to focus on risk
in applications outside ERP more than ever before and looking to extend SAP GRC AC to govern:
- Non-ABAP applications like SAP BPC, MDM, MDG111
- Cloud-based applications like Ariba, SuccessFactors, Salesforce.com
- Non-SAP applications like Oracle, JD Edwards, Hyperion
Organizations that are deploying and/or have deployed SAP GRC AC commit a lot of resources to managing SoD
compliance (Defining risks and identifying User SoD, Remediating user conflicts, Role redesign, Implementing
preventive controls using compliant provisioning). However the last step of the process – which is mainly

109
Dina Shahin (2015): Leading Strategies to Enforce Your Organisation’s Access Policies Using Emergency Access
Management in SAP Access Control, Customer Advisory Group.
110
Susan Stapleton (2015): Apply Existing Risk and Compliance Processes Across Both SAP and Non-SAP Systems with SAP
Access Violation Management, Greenlight Technologies.
111
SAP BPC, MDM, MDG: SAP Business Planning and Consolidation (BPC), SAP Master Data Management (MDM), SAP
Master Data Governance (SAP MDG).

64
about (i) Ensuring controls are established and (ii) Business taking ownership of SoD compliance - remains a
challenge. To illustrate the above, below overview shows some typical examples of the mitigating process that
organizations have in place (i.e. organizations that have implemented SAP GRC AC) around defining and
monitoring manual mitigating controls.

Figure 2. Typical mitigating process around defining and monitoring manual mitigating controls

According to Greenlight Technologies Inc., automating compliance activities for the business and compliance
can result in a big win by means of the following transformation initiatives:
 Reducing the amount of time business is required for compliance activities by providing an end-to-end,
online, exception-based process that makes compliance tasks as efficient as possible
 Due to an independent reporting source, compliance and Audit can confidently review status of controls
online
Greenlights Technologies Inc. recommends organizations to move to Exception-Based SoD Monitoring112 and
to focus on actual access violations. Below overview shows the differences versus 'regular' SoD monitoring
which is provided by SAP GRC AC:

Figure 3. Moving to Exception-Based SoD Monitoring

Below overview shows the Access Management Capabilities with Access Violation Management (AVM) application:

112
Greenlight Technologies Inc. (a SAP software solution and technology partner) has launched Access Violation
Management (AVM) application which provides Exception-Based SoD Monitoring.

65
 Enterprise-Wide
Access Compliance

Figure 4. Access Management Capabilities with Access Violation Management (AVM) application

Below overview shows the recommended mitigating control execution process which is focusing only on actual
violations:113

Figure 41. Recommended mitigating control execution process focusing only on actual violations

The overview above is illustrated by a practical example: 114

113
Erwin Albers (2015): Rethinking Segregation of Duties: Where Is Your Business Most Exposed?, SAP Netherlands.
114
Erwin Albers (2015): Rethinking Segregation of Duties: Where Is Your Business Most Exposed?, SAP Netherlands.

66
Automated by
SAP GRC AC
tomated

Automated by
SAP AVM

Automated by
SAP AVM

Exceptions-handling
with SAP AVM

Figure 42. Practical example with regard to recommended mitigating control execution process focusing only on actual
violations

Below overview shows the recommended automated mitigation processes for defining and monitoring
mitigating controls:115

Figure 43. Recommended automated mitigation processes for defining and monitoring mitigating controls.

Reflecting the above, the following recommendations can be derived for the good practice SAP (Access)
Security Design Framework:

115
Susan Stapleton (2015): Apply Existing Risk and Compliance Processes Across Both SAP and Non-SAP Systems with SAP
Access Violation Management, Greenlight Technologies.

67
  Summarize the monetary value of
actual SoD violations
 Clearly articulate the financial
exposure that broad user access
has on the business
 Drive change where the impact
exceeds the materiality threshold
 Automate identification and review of  Extend the capabilities of the SAP
actual SoD violations GRC AC application across
 Alert business owners only when enterprise systems
exceptions occur, reducing manual  Enable business ownership of
control efforts and eliminating false access governance and
positives remediation activities
 Use a comprehensive library of
automated SoD controls across
business processes
 Have centralized tracking,
investigation, and resolution of SoD
violations

3.2.9 Good practices regarding SAP GRC AC and SAP IdM integration (Step 8: Compliant Identity
Management)
Below overview shows how integration between SAP GRC AC and SAP IdM integration can help ensure
Compliant Identity Management116. An integrated SAP GRC AC-SAP IdM solution combines access governance
and identity management capabilities to support automation of identity and access processes and compliance
requirements.

Figure 44. SAP GRC AC and SAP IdM integration: Compliant Identity Management

Regardless of the SAP GRC AC – SAP IdM integration scenario chosen, compliant business-driven Identity
Management (i.e. automated, position-based role management while ensuring compliance) should have the
following characteristics:117

116
Henk Peter Wind (2015): SAP Netweaver Identity Management & SAP Access Control, Integrc, February 12, 2015.
117
Chris Radkowski and Fedya Toslev (2015): Access Governance for the Enterprise: Integrating SAP Identity Management
with SAP Access Control, SAP.

68
Figure 45. Compliant Business-driven Identity Management Process Steps

When exploring potential integration scenarios, following items and/or questions need to be considered:118
Item
Request submission source
Provisioning roles
Approval workflow
SoD Risk analysis
Request status and audit
trails
Existing functionality and
change control
Figure 46. Items and/or questions to be considered when exploring different SAP GRC AC-SAP IdM integration scenarios
Item explained
 From where will the provisioning request be initiated (HR System and/or SAP GRC AC
and/or SAP IdM)?
 Role source: Where will the roles for provisioning be maintained (AC and/or IdM)?
 Preferred approach is to have one role source for SAP roles
 Going forward it is expected that SAP will build-in business role synchronization
between SAP GRC AC and SAP IdM, making this issue not/less relevant
 Do you want to use approval workflow within AC and/or IdM?
 Need to consider user notifications from AC and/or IdM
 When provisioning new users, the request does not have to be submitted to AC for risk
analysis, and no polling is required. IdM can retrieve the result by also polling the risk
analysis web service with Request ID.
 When provisioning existing users, risk analysis can be called by IdM
 Consider requirements for request status and audit trails while defining the integration
solution (web services can only pass certain fields, while more details may be viewed
natively in AC or IdM)
 IdM’s change control policy and its impact on solution and implementation: Are
changes to the current IdM process realistic?

Below two potential good practice scenarios for possible SAP NW IDM and SAP GRC AC integration are
shown:119
 Scenario 1: IdM-Driven User Provisioning with Access Control Integration;
 Scenario 2: Access Control-Driven User Provisioning with IdM Integration.

118
Chris Radkowski and Fedya Toslev (2015): Access Governance for the Enterprise: Integrating SAP Identity Management
with SAP Access Control, SAP.
119
Chris Radkowski and Fedya Toslev (2015): Access Governance for the Enterprise: Integrating SAP Identity Management
with SAP Access Control, SAP & Henk Peter Wind (2015): SAP Netweaver Identity Management & SAP Access Control,
Integrc, February 12, 2015.

69
Figure 47. Scenario 1: IdM-Driven User Provisioning with Access Control Integration

Figure 48. Scenario 1: IdM-Driven User Provisioning with Access Control Integration

70
Figure 49. Scenario 2: Access Control-Driven User Provisioning with IdM Integration

Figure 50. Scenario 2: Access Control-Driven User Provisioning with IdM Integration

3.2.10 Good Practices Based on consulting well-known IT and/or Information Security Control Frameworks
In addition to searching professional literature which is explicitly focusing on building and maintaining SAP
Access Security (via deployment of an Access Control application), I have also considered well-known IT and/or

71
Information Security Control Frameworks (i.e., ISO/IEC 27001120, COBIT 5121, NIST SP 800-53 Rev. 4.122, ISA/IEC
62443123, CCS-CSC124). In general, these frameworks have a wider scope and do not focus specifically on SAP
Access Security. Below overview – which was derived from the NIST Cybersecurity Framework (CSF) Reference
Tool - shows which sections of these well-known IT and/or Information Security Control Frameworks do
provide standards and/or requirements that can be directly linked to building and maintaining SAP Access
Security.
Function Category Subcategory Informative References
· CCS CSC 16
· COBIT 5 DSS05.04, DSS06.03
· ISA 62443-2-1:2009 4.3.3.5.1
PR.AC-1: Identities and credentials are · ISA 62443-3-3:2013 SR 1.1, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR
managed for authorized devices and users 1.8, SR 1.9
· ISO/IEC 27001:2013 A.9.2.1, A.9.2.2, A.9.2.4, A.9.3.1, A.9.4.2,
A.9.4.3
Access Control (PR.AC): Access to assets · NIST SP 800-53 Rev. 4 AC-2, IA Family
and associated facilities is limited to · COBIT 5 APO13.01, DSS01.04, DSS05.03
authorized users, processes, or devices, · ISA 62443-2-1:2009 4.3.3.6.6
and to authorized activities and
PR.AC-3: Remote access is managed · ISA 62443-3-3:2013 SR 1.13, SR 2.6
transactions. · ISO/IEC 27001:2013 A.6.2.2, A.13.1.1, A.13.2.1
· NIST SP 800-53 Rev. 4 AC‑17, AC-19, AC-20
· CCS CSC 12, 15
PR.AC-4: Access permissions are managed, · ISA 62443-2-1:2009 4.3.3.7.3
incorporating the principles of least · ISA 62443-3-3:2013 SR 2.1
privilege and separation of duties · ISO/IEC 27001:2013 A.6.1.2, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4
· NIST SP 800-53 Rev. 4 AC-2, AC-3, AC-5, AC-6, AC-16
· CCS CSC 9
Awareness and Training (PR.AT): The · COBIT 5 APO07.03, BAI05.07
organization’s personnel and partners are PR.AT-1: All users are informed and trained · ISA 62443-2-1:2009 4.3.2.4.2
PROTECT (PR)
provided cybersecurity awareness · ISO/IEC 27001:2013 A.7.2.2
education and are adequately trained to · NIST SP 800-53 Rev. 4 AT-2, PM-13
perform their information security-related · CCS CSC 9
duties and responsibilities consistent with · COBIT 5 APO07.02, DSS06.03
PR.AT-2: Privileged users understand roles
related policies, procedures, and · ISA 62443-2-1:2009 4.3.2.4.2, 4.3.2.4.3
& responsibilities
agreements. · ISO/IEC 27001:2013 A.6.1.1, A.7.2.2
· NIST SP 800-53 Rev. 4 AT-3, PM-13
Maintenance (PR.MA): Maintenance and PR.MA-2: Remote maintenance of · COBIT 5 DSS05.04
repairs of industrial control and information organizational assets is approved, logged, · ISA 62443-2-1:2009 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.4.4.6.8
system components is performed and performed in a manner that prevents · ISO/IEC 27001:2013 A.11.2.4, A.15.1.1, A.15.2.1
consistent with policies and procedures. unauthorized access · NIST SP 800-53 Rev. 4 MA-4
· COBIT 5 DSS05.02
· ISA 62443-2-1:2009 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4,
4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3,
Protective Technology (PR.PT): Technical
4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1,
security solutions are managed to ensure PR.PT-3: Access to systems and assets is
4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4
the security and resilience of systems and controlled, incorporating the principle of
· ISA 62443-3-3:2013 SR 1.1, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR
assets, consistent with related policies, least privilege 1.7, SR 1.8, SR 1.9, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 2.1, SR 2.2, SR
procedures, and agreements. 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7
· ISO/IEC 27001:2013 A.9.1.2
· NIST SP 800-53 Rev. 4 AC-3, CM-7
Figure 51. Standards and/or requirements – coming from well-known IT and/or Information Security Control Frameworks
(e.g. COBIT5, ISO27001) - that can be linked to building and maintaining SAP Access Security.

Whilst going through these frameworks I conclude that - although these frameworks do provide standards that
could be applied by organizations that would like to ensure they build and/or maintain appropriate SAP Access
Security – the standards provided are too generic in comparison to the tailored recommendations that are

120
ISO/IEC 27001: 2013: International Organization for Standardization (ISO)/ International Electrotechnical Commission
Code of practice for information security controls which provides requirements for standards for an Information Security
Management System (ISMS).
121
COBIT 5: Control Objectives for Information and Related Technology (COBIT) is a framework created by ISACA for
information technology (IT) management and IT governance. It is a supporting toolset that allows managers to bridge the
gap between control requirements, technical issues and business risks.
122
NIST Special Publication 800-53 Revision 4: Special Publication sponsored by the National Institute of Standards and
Technology (NIST) containing Recommended Security and Privacy Controls for Federal Information Systems and
Organizations.
123
ISA/IEC-62443 is a series of standards, technical reports, and related information that define procedures for
implementing electronically secure Industrial Automation and Control Systems (IACS). This guidance applies to end-users,
system integrators, security practitioners, and control systems manufacturers responsible for manufacturing, designing,
implementing, or managing industrial automation and control systems.
124
CCS-CSC: The Critical Security Controls for Effective Cyber Defense which have been issued by the Council on Cyber
Security

72
described in the professional literature (see § 3.2.1 to § 3.2.9) specifically aimed at implementing Access
Control applications (SAP GRC AC in particular). Support for this conclusion can be found in appendix 3, where I
have created an overview of relevant management practices and/or risk controls from the COBIT 5 framework,
which can be linked to building and maintaining application security. Those COBIT 5 management practices
which are related to building and maintaining an appropriate SAP (Access) Security are marked in yellow in
appendix 3. Based on this conclusion, I have decided to build vast majority of the good practice SAP (Access)
Security Design Framework around the recommendations which have been described in § 3.2.1 to § 3.2.9.
Relevant standards (see table above) from the well-known IT and/or Information Security Control Frameworks
will only be considered when these frameworks make reference to standards and/or requirements that are
omitted from the recommendations in § 3.2.1 to § 3.2.9. However boundary condition is that the
recommendations should remain within the scope of this thesis as described in § 1.6.

3.3 Conclusion
Defining, configuring and implementing SAP Access Security is a complex and resource-intensive endeavour.
Companies should consider their approach to building SAP Application Security in the early stages of SAP
projects. Embedding proper security requirements during the system build process helps to avoid the need for
a redesign later. Using automated security design solutions such as SAP GRC AC and applying best practices
can increase efficiency and acceleration of the security design and the implementation of conflict-free SAP
roles, and dramatically reduce the possibility of having to redesign SAP security in the future.125

Based on recommendations that have been identified in the previous sections of this chapter the following
overall good practice SAP (Access) Security Design Framework has now been developed:

125
Protiviti (2014): Designing SAP Application Security: Leveraging SAP Access Monitoring Solutions During SAP
Implementations, Upgrades Or Redesign Projects.

73
SAP Access Reference to Top- Good Practice (I) Detailed description of good practice standard and/or (II) Objective of applying good practice Source
Security Domain Down 8 step standard
approach to
building SAP
(Access) Security
III.SAP Security Step 0: Define 0.1 Define and Deploy  Establish a sense of urgency Friesland-
Organizational and Deploy Organizational Change - Push: Executive Board emphasizes importance on internal controls Campina
Structure & Organizational Management Approach - Pull: SoD requirements in place before SAP GRC AC deployment (2015)
Governance Change  Create a guiding coalition
Management - Assemble a powerful coalition
Approach  Develop a vision and strategy
- Technical implementation – “Big Bang”
- Organizational implementation – Phased rollout
 Communicate the change vision
- Communication plan and dedicated Change Manager
- SBU FD/Controllers and management within business units communicate the (importance of)
change in their organization
- Corporate Communication involvement
 Empower employees for broad-based action
- Define clear responsibilities (RACI)
- Dedicated roles in the project (e.g., project management, change management, technical,
functional, trainers, quality assurance)
- Remove barriers to change
 Generate short-term wins
- Plan quick visible performance improvement (e.g., reduction of fire fighters, simplified
reporting, OpCo pilot success) and communicate and quick wins
- Project perspective: start with Analyse Risks module to clean your data, reduce SoD conflicts
and show quick wins
 Consolidate gains and produce more change
- Keep looking for improvements: Keep end-state in mind and keep communicating
- Evaluation: have periodic evaluations (what went right and what can be improved), learn from
the past and show you apply learnings in future rollouts
 Anchor new approaches in the culture
- Embed SAP GRC AC in the core of the organization: define and distribute deliverables, Quick
Reference Guides, Newsflashes, SharePoint/LiveLink
- Keep involving the end users: schedule periodic evaluation sessions with the end users to
monitor the project
III.SAP Security Step 0: Define 0.2 Identify the right internal  Active executive participation SAP
Organizational and Deploy resources  Need a good project manager Netherlands
Organizational  Need decision makers

74
SAP Access Reference to Top- Good Practice (I) Detailed description of good practice standard and/or (II) Objective of applying good practice Source
Security Domain Down 8 step standard
approach to
building SAP
(Access) Security
Structure & Change  Need collaboration between all parties , Erwin
Governance Management  Need to know the business processes Albers, 2015
Approach  Employee and company knowledge are essential
II.SAP Security & Step 1: Define 1.1 Define in scope SAP  Work with BPOs, SAP functional leads, and compliance organizations to identify business Protiviti
Provisioning SoD Policies and applications processes and applications in-scope of the SAP+ project. (2014a)
processes Rule Design  Determine how the different SAP modules (e.g., FICO, MM) and SAP Applications (e.g., (SAP SRM,
III. SAP Security SAP MDM, SAP CRM) would be utilized for each business process.
Organizational
Structure &
Governance
II.SAP Security & Step 1: Define 1.2 Establish an agreed-upon  SoD management framework shall contain: Protiviti
Provisioning SoD Policies and and signed-off SoD - Business risk: definition of overall risk that drive the SoD rule and security controls (2014a), EY
processes Rule Design management framework - Risk description: definition of what a user could do if allowed certain access in the SAP system (2010), SAP
III. SAP Security (‘ruleset’) - SoD and Sensitive Access Policies: job functions that represent or increase risk if provided to a NL (2015)
Organizational user without proper monitoring
Structure & - Job function: tasks assigned to a specific user
Governance - SoD rule: SAP transactions and respective authorization objects related to the conflicting job
functions
 Documenting Access Risks should be done in business language
 Element of the SoD management framework is a matrix of potential conflicts (Conflict matrix),
which is independent of the supporting (SAP) application (e.g., ECC, SRM, APO) driving each
transaction
II.SAP Security & Step 1: Define 1.3 Classify SoD risks into risk  Define the different risks levels that will be deployed. This will help management prioritize areas Protiviti
Provisioning SoD Policies and levels (e.g., critical, high, of focus during role build or security remediation phases: (2014a), EY
processes Rule Design medium and low risk) (2010), SAP
III. SAP Security NL (2015)
Organizational
Structure &
Governance
II.SAP Security & Step 1: Define 1.4 Evaluate SAP standard  SAP standard and custom transactions (i.e., transaction codes) should be evaluated to identify Protiviti
Provisioning SoD Policies and and custom transactions those that provide the ability to create, modify, post or delete data related to any of the (2014a),
processes Rule Design identified risks. SAP NL
III. SAP Security  Subsequently, these SAP transactions are grouped into job functions (e.g. Create a GL Account, (2015)
Organizational Post Payments)
 Enlist the help of IT to assist with technical risk definitions

75
SAP Access Reference to Top- Good Practice (I) Detailed description of good practice standard and/or (II) Objective of applying good practice Source
Security Domain Down 8 step standard
approach to
building SAP
(Access) Security
Structure &
Governance
II.SAP Security & Step 1: Define 1.5 SoD ruleset needs to  Any standard/predefined set of SoD rules (which are included in most SAP Access Management Protiviti
Provisioning SoD Policies and reflect the company’s risk solutions) needs to be adjusted, along with the risk ranking, to reflect the company’s risk profile. (2014a), EY
processes Rule Design profile.  In those cases where standard/predefined ruleset is used as a starting point, ensure security (2010),
III. SAP Security parameters (i.e., authorization objects) in ruleset are adjusted to reflect the company’s security InteGRC
Organizational design. (2013)
Structure &  Each BU must perform a customized analysis of its conflicting transactions in order to capture the
Governance real risk for that particular business model
II.SAP Security & Step 1: Define 1.6 Define Sensitive Access  In addition to SoD policies and SoD risk definitions, also define, group and classify sensitive and Protiviti
Provisioning SoD Policies and and Critical Actions Policies critical SAP transactions to enable monitoring and reporting on SAP roles and users who have (2014a)
processes Rule Design add, modify or even display access to the company’s sensitive information
III. SAP Security
Organizational
Structure &
Governance
II.SAP Security & Step 1: Define 1.7 A formal (SAP) AC  Requirements document includes to-be workflows, business owners / approvers, user access Protiviti
Provisioning SoD Policies and application requirements request form fields, custom fields, field mapping between source systems and SAP GRC AC, user (2012)
processes Rule Design document should be master data source, email notification wording and settings, etc.
III. SAP Security completed (including sign-off)  Formal sign-off should be obtained to validate that the document accurately reflects the
Organizational based on discussions with company’s business requirements for the SAP GRC AC tool
Structure & business process
Governance management
II.SAP Security & Step 1: Define 1.8 Identify Risk Owners  Risks belong to the business; risk owners should be business personnel (not IT!) SAP NL
Provisioning SoD Policies and  Assign risk owners to each risk (2015)
processes Rule Design
III. SAP Security
Organizational
Structure &
Governance
II.SAP Security & Step 1: Define 1.9 Policy on how to deal KPMG
Provisioning SoD Policies and with a breach of the (2013)
processes Rule Design segregation of duties is
III. SAP Security determined
Organizational

76
SAP Access Reference to Top- Good Practice (I) Detailed description of good practice standard and/or (II) Objective of applying good practice Source
Security Domain Down 8 step standard
approach to
building SAP
(Access) Security
Structure &
Governance
II.SAP Security & Step 1: Define 1.10 Policy on how to deal  Going-live with Emergency user functionality in SAP GRC AC (or similar access control application) KPMG
Provisioning SoD Policies and with the use of emergency - along with being able to monitor the segregation of duties rules - can provide a quick win in the (2013)
processes Rule Design users is determined (see Get Clean-phase.
III. SAP Security
Organizational
Structure &
Governance
I.SAP Security Step 2: Initial Role 2.1 A good authorization  Reliability: the range of authorization has to correspond with the operational responsibility of the SAP (2008),
Authorization and User Design concept should have the end user Protiviti
concept following characteristics:  Security: it has to be guaranteed that no unauthorized users have access to sensitive data or (2013)
Reliability, Security, programs
Testability, Flexibility, and  Testability: the concept has to be comprehensive and transparent both for internal as well as for
Comprehensibility. external auditors.
 Flexibility: it should be easy adaptable, if for example organizational changes occur or new
modules have to be integrated
 Comprehensibility: it should be easily comprehensible for all those involved, as for example
according to name conventions for users, authorizations and profiles.
I.SAP Security Step 2: Initial Role 2.2 Involve business process  When defining an authorization concept, it is important to balance business priorities, such as Protiviti
Authorization and User Design owners in the design and the need for flexibility and control, and keep in mind the importance of minimizing the number of (2013)
concept ownership of roles to ensure security roles to keep maintenance efforts to a minimum.
the roles truly reflect business
functions and will be
sustainable in the longer term
I.SAP Security Step 2: Initial Role 2.3 Define the set of SAP  Transaction logs are analysed to determine the set of monthly, quarterly and year-end Protiviti
Authorization and User Design transactions to be included in transactions that should be included in the newly designed SAP roles (2014a)
concept the updated SAP roles by
reviewing the SAP
transaction history126.

126
Good practice # 2.1 is applicable to SAP upgrade or security redesign projects only. The case study object in 2 of the 3 SBUs (i.e., SBU ‘A’ and ‘C’) has the characteristics of a SAP upgrade
project. For new SAP implementations, since no transactional history will be available, alternative good practice would be to review “to-be” business processes and conducting a preliminary
analysis of individual tasks and SAP transactions that will be performed once the new system goes live.

77
SAP Access Reference to Top- Good Practice (I) Detailed description of good practice standard and/or (II) Objective of applying good practice Source
Security Domain Down 8 step standard
approach to
building SAP
(Access) Security
I.SAP Security Step 2: Initial Role 2.4 Conduct workshops with  Role templates, consisting of the role's technical name and the underlining transaction codes, will Protiviti
Authorization and User Design BPOs to validate that the be documented. (2014a)
concept respective SAP transaction  Role templates may also include key information related to security restrictions, such as company
groups are aligned with the codes, cost centers or document types.
“to-be” business processes in
case of new SAP
implementations or existing
business processes in case of
security redesign projects
I.SAP Security Step 2: Initial Role 2.5 Define “role owners” for  Role owners are typically part of the functional implementation, or business teams, and usually Protiviti
Authorization and User Design each role template “own” or are responsible for managing and reporting on the data being updated by the SAP (2014a)
concept transactions and roles they own (e.g., a corporate controller would own finance-related roles).
 Responsibilities for role owners include review and approval of SAP transactions to be included in
the role and ongoing maintenance of the role (e.g., transaction additions, deletions, and approval
of mitigating controls if conflicts occur).
I.SAP Security Step 2: Initial Role 2.6 Role naming conventions Protiviti
Authorization and User Design and role groupings need to (2014a)
concept be intuitive not only to IT
security experts, but also to
business approvers and
reviewers
I.SAP Security Step 2: Initial Role 2.7 Deploy an access  Access management solutions such as SAP GRC AC, can automate the periodic review of users, Protiviti
Authorization and User Design management solution (such identify risks within roles before granting access to productive systems, and streamline (2013)
concept as SAP GRC AC) to help associated audits and reporting the security risks.
design and keep roles free of
SoD conflicts over time
I.SAP Security Step 2: Initial Role 2.8 Make adequate and clear  Some key SAP security considerations are related to: Provititi
Authorization and User Design choices with regard to key - Job Based versus Task Based roles (2014a),
concept SAP security considerations - Single versus Composite roles (PwC,
to ensure appropriate role - Derived versus Enabler roles 2015),
architecture is in place. - Custom or Pre-delivered SAP Roles Turnkey
- HR or position-based design versus functional design Consulting
(2015)

78
SAP Access Reference to Top- Good Practice (I) Detailed description of good practice standard and/or (II) Objective of applying good practice Source
Security Domain Down 8 step standard
approach to
building SAP
(Access) Security
I.SAP Security Step 2: Initial Role 2.9 First key decision to make  Intention of job-based roles is to give each user one role (e.g., Accounts Payables Manager) that Provititi
Authorization and User Design during the actual design of encompasses all of that person’s activities. This approach utilizes fewer roles, but also gives users (2014a),
concept SAP Security is whether to access to transaction codes they might not need. Also, the roles themselves might have SoD (PwC,
use "Job-based" versus conflicts due to the large number of transactions assigned. 2015),
"Task-based" roles  Intention of task-based roles is to give each user multiple roles, each representing one job task Turnkey
(e.g., Release Purchase Requisition). This approach utilizes more roles, but will limit user access Consulting
to the respective tasks performed. (2015)
 Decision around using a job based or task-based approach will depend on the overall job
consistency of job positions, and the maturity of HR departments in relation to the integration
between SAP access requests and employee hiring, transfer and termination processes.
I.SAP Security Step 2: Initial Role 2.10 Decide on whether to  Composite roles are a grouping of roles held within another role Provititi
Authorization and User Design use Composite roles or Single  Main advantage in composite roles is that they provide a simpler user provisioning process since (2014a),
concept roles the user will receive one role. PwC,
 Main disadvantage of composite roles is that users may be granted more access than required (2015),
due to additional tasks or backup responsibilities being included in the composite role. Turnkey
Consulting
(2015)
I.SAP Security Step 2: Initial Role 2.11 Chose appropriate  Based on the two key SAP security considerations that were referred to in 2.8 and 2.9 above (Job Turnkey
Authorization and User Design design variant for the Role Based versus Task Based roles and Single versus Composite roles), three different design variants Consulting
concept Architecture for the Role Architecture can be identified: (i) Job-based Single roles, (ii) Job-based Composite (2015)
roles and (iii) Task-based Single roles.
 Organization’s choice with regard to the appropriate design variant should consider the pros and
cons for each variant (see overview provided by Turnkey Consulting) and the best fit to the
organization’s requirements.
I.SAP Security Step 2: Initial Role 2.12 Decide on whether to  While task-based roles determine what users can do, enablers determine where they can do it. PwC (2014)
Authorization and User Design use Derived versus Enabler  From a technical perspective, an enabler is an authorization only role that grants access to the
concept roles “where.” They are similar to derived roles except they have a one-to-many relationship with
task roles (whereas derived roles have an one-to-one relationship with task roles).
 In its purest form, one enabler role grants the “where” access for all the “what” roles that a user
has assigned to them. The enabler concept is simple to maintain and very transparent about
what controlled information a user has access to.
 Enabler model works well when going through upgrades — from an enabler perspective, the key
activity when upgrading is to compare the objects in the enabler to the new objects the upgrade
or support pack introduced to ensure the crucial ones are there.

79
SAP Access Reference to Top- Good Practice (I) Detailed description of good practice standard and/or (II) Objective of applying good practice Source
Security Domain Down 8 step standard
approach to
building SAP
(Access) Security
I.SAP Security Step 2: Initial Role 2.13 Decide on whether to  Not recommended that out-of-the-box are used as a long-term strategy to maintain SAP security. Provititi
Authorization and User Design use Custom or Pre-delivered  Pre-delivered SAP Roles are designed to as one size fits roles, meaning that they have such a wide (2014a)
concept SAP Roles range of job activities combined in a single role that it will be nearly impossible to provision these
roles to a user without granting excessive access.
 Also, out-of-the-box roles may not meet all business access requirements and control
restrictions.
I.SAP Security Step 2: Initial Role 2.14 Decide on whether to  Another consideration when designing SAP security is the level of integration with HR processes Provititi
Authorization and User Design use HR or position-based (e.g., hiring, termination) and overall consistency with job descriptions and positions. (2014a)
concept design versus functional  In ideal scenario, SAP roles should reflect job responsibilities, but if HR departments and
design positions are not mature or consistent, an independent security design based purely on job
functions may be the best option.
 Prerequisites for organizations to apply a position-based design are:
- HR job descriptions are well-defined and consistent across the company, and
- "Hire-to-Retire" processes is in a mature stage to enable integrated provisioning.
I.SAP Security Step 2: Initial Role 2.15 Apply recognized  Follow a risk-based approach Turnkey
Authorization and User Design enablers for a successful - Least privileged principal with sensitive processes Consulting
concept SAP authorization concept - Split display and change access (2015)
 Plan for the future
- Be aware of ‘Easy to set up, harder to maintain’
- Make sure naming convention allows for future expansions and complexities
 Have a clear authorization concept (role architecture) strategy and stick to it
 Automate provisioning of generic access where possible
 Keep it simple (or as simple as allowed …)

I.SAP Security Step 3: Role Build 3.1 First step in the technical  Building master roles requires close coordination with the systems integrator and BPOs so that all Provititi
Authorization and User role design phase is to build standard and custom SAP transactions and objects being used as part of the role design are (2014a)
concept / II.SAP Assignment “master roles” or “template understood in terms of functionality (e.g., create master data, update financial statements) and
Security & roles”. are also properly incorporated in the template roles
Provisioning
processes
(ARA/user
provisioning)
I.SAP Security Step 3: Role Build 3.2 Second step in designing  “Derived” or “child” roles is where security restrictions are applied (e.g., company code and cost Provititi
Authorization and User SAP roles is to create center limitations) (2014a)
concept / II.SAP Assignment “derived” or “child” roles

80
SAP Access Reference to Top- Good Practice (I) Detailed description of good practice standard and/or (II) Objective of applying good practice Source
Security Domain Down 8 step standard
approach to
building SAP
(Access) Security
Security &
Provisioning
processes
I.SAP Security Step 3: Role Build 3.3 Designing roles that are  Doing so can lead to increased granularity and more restrictive access. Also it can reduce ongoing Provititi
Authorization and User free from SoD conflicts early security maintenance because it makes it easier to respond to changes in user responsibilities (2014a)
concept / II.SAP Assignment in the SAP+ project resulting from the implementation of new SAP functionality and/or organizational alignment
Security &
Provisioning
processes
I.SAP Security Step 3: Role Build 3.4 Leverage SAP GRC AC to  If master roles have inherent SoD conflicts, all derived roles and subsequently assigned users also Provititi
Authorization and User confirm that roles are SoD- will have conflicts (2014a)
concept / II.SAP Assignment conflict –free before
Security & assigning them to end users
Provisioning
processes
I.SAP Security Step 3: Role Build 3.5 Configured workflow for  Required workflow approval steps do comprise: Provititi
Authorization and User user access change requests - approval by the user’s manager. This requires that the user’s manager is also tracked in Active (2014a)
concept / II.SAP Assignment should include required Directory (alternatively allow for the user’s manager to be specified on the user request form).
Security & approvals from user's - approval of access by a role owner
Provisioning manager, role owner, - approval of access by the security team
processes security team, and should - A review and approval of segregation of duties, including the assignment of mitigating controls
also include review and
approval of SoD
I.SAP Security Step 3: Role Build 3.6 Risk-based SoD process  Mapping all of the ways a user could potentially execute a transaction is critical to accurately EY (2010)
Authorization and User requires a company to depicting SoD
concept / II.SAP Assignment discover all the potential  For example, vendor-update rights may be executed through a series of menus within a given
Security & methods for executing a application. The presence of these menus assigned to specific users should be mapped, walked-
Provisioning transaction in order to through and documented in order for the company to accurately test for a particular conflict
processes understand the full potential  One of the key fallacies in menu (or access) mapping is that one only needs to map the
for fraud transactions that are actually used in the application. While this method will usually capture
many of the executed transactions, it will fail to identify the menus business users do not use but
could use to execute a particular transaction.
I.SAP Security Step 3: Role Build 3.7 Regardless of the  Exclusions refer to the user IDs and menus or access rights intentionally omitted in the SoD EY (2010)
Authorization and User treatment of any exclusions analysis.
concept / II.SAP Assignment in the SoD analysis, it is vital

81
SAP Access Reference to Top- Good Practice (I) Detailed description of good practice standard and/or (II) Objective of applying good practice Source
Security Domain Down 8 step standard
approach to
building SAP
(Access) Security
Security & to document all omissions,  Often system or process accounts, IT administrators, IT operations and support personnel may
Provisioning their rationale and to have access to multiple conflicting menus. This may not actually represent a conflict if the goal is
processes communicate this to only capture the business users with SoD conflicts. Alternatively, to facilitate continuous
information to regulators and controls monitoring, companies often include IT users in reports on standard sensitive
compliance stakeholders. transaction usage and SoD conflicts.
 Typically, read-only or inquiry functionality in the application should be excluded from the SoD
analysis as it does not permit execution of sensitive transactions
II.SAP Security & Step 4: Role and 4.1 SAP GRC AC (or similar  This is done by simulating and monitoring changes affecting SAP security design, and providing Provititi
Provisioning User Access Risk application) should be timely feedback to BPOs in case potential conflicts arise. (2014a),
processes Analysis leveraged to perform  Based on the defined ruleset it is determined to which extent the desired segregation of duties is KPMG
III.SAP Security periodic role and user actually present. Breaches of the segregation of duties are reported (2013),
Organizational analysis to determine if the  Risk analysis should be run on a periodic basis, especially after unit and integration testing, which InteGRC
Structure & newly designed SAP roles are is when the SAP system design will be updated to accommodate process improvements. (2013)
Governance in compliance with SoD  Specific details on the parameter configuration of the Access Risk Analysis (ARA) submodule are
policies included in a (detail level) design document.
II.SAP Security & Step 4: Role and 4.2 Management should  Defined SAP rule set in SAP GRC AC may change during the course of the SAP+ project, given that Provititi
Provisioning User Access Risk define and document a new SAP transactions may be added to “to-be” processes or new custom transactions may be (2014a),
processes Analysis formal process to govern the developed. It is critical that an organization's rule change process is formally documented to Provititi
III.SAP Security changes to the SAP GRC rule provide proof to management and auditors that the rules are appropriately controlled. (2012), SAP
Organizational set.  The formal change management process for modifications to the rule set should include the NL (2015)
Structure & approval of changes by relevant business owners as well as an overall business owner for certain
Governance types of changes (e.g. deactivation of risks, changes that cross business functions, etc.)
 In addition to establishing a formal change management process, a process should be defined to
periodically review the rule set to confirm that the risks defined are still relevant and to adjust
the rule set as required based upon changes within the case study object organization.
 Considerations that do apply when organizations do update their ruleset can be both functional
(e.g., new business units, new business processes) as well as technical (e.g., new systems in the
landscape, new authorizations or t-codes in use) in nature.
II.SAP Security & Step 4: Role and 4.3 To ensure SAP  SAP security provisioning process includes procedures that require SAP security teams to perform Provititi
Provisioning User Access Risk environment is “clean” or a risk simulation in SAP GRC AC prior to granting user access or modifying a role. This simulation (2014a), EY
processes Analysis “conflict-free” post go-live, a will determine if role or user changes are posing SoD or excessive access security risks. (2010)
III.SAP Security sound SAP security  It is important for the company to prioritize the conflicts so that remediation and management
Organizational provisioning process must be of the user population can be focused on those conflicts with the greatest potential for risk
Structure & designed and implemented reduction. The correct assessment and definitions of how to manage each of the risk ratings is a
Governance key factor in delivering benefits from a risk-based approach.

82
SAP Access Reference to Top- Good Practice (I) Detailed description of good practice standard and/or (II) Objective of applying good practice Source
Security Domain Down 8 step standard
approach to
building SAP
(Access) Security

II.SAP Security & Step 4: Role and 4.4 Risk Remediation:  Remediation techniques include role redesign, role clean-up, user appropriateness review and KPMG
Provisioning User Access Risk eliminate the identified risks SoD tool implementation. (2013), EY
processes Analysis by making changes to  Quick wins can be achieved through the deployment of advanced data analysis techniques. These (2010)
III.SAP Security granted authorizations or by analyses go beyond determining whether a transaction code is started, and determine whether
Organizational making changes in the and, if so, what changes or bookings a user actually executed.
Structure & authorization concept  Remediation initiatives generally fall into two categories: tactical clean-up of the user population
Governance and strategic role redesign:
- Tactical role clean up: Tactical user population clean up refers to the process of reviewing the
role or security model to evaluate whether both sides of the conflicting transactions are
required for a particular user to do his or her job. Roles alone cannot be used to test for SoD
conflicts; rather, a company must look to the lowest level of security (i.e., menu item, screen,
executable, transaction code) that make up a particular role to understand what transactions a
user can execute.
- Strategic role redesign: Strategic role redesign seeks to define what constitutes SoD conflict
free access across the company. It maps job function and responsibility in the business to the
required access rights in the system. This approach is typically used when the existing role
model is heavily conflicted and cannot be salvaged through clean-up initiatives. Strategic role
design builds sustainable capabilities and processes that serve to maintain the “cleaned” role
structure.
II.SAP Security & Step 4: Role and 4.5 User appropriateness  Examining the current user population for terminated employees from the human resources (HR) EY (2010)
Provisioning User Access Risk reviews provide an easy and list is vital. This step not only reduces the number of users to be analysed, but establishes the
processes Analysis effective way to reduce the population on which to base the SoD testing
III.SAP Security number of SoD conflicts  Furthermore, a careful review of the user population can be applied to determine whether users
Organizational (revealed in the testing should have access to a particular role or group. A simple check of the user population, in the
Structure & process) context of job title or function, can be used to identify SoD conflicts. Once identified, such SoD
Governance conflicts can be eliminated.
II.SAP Security & Step 4: Role and 4.6 Once remediation is  It is critical to assign accountability for the tasks of role maintenance, user administration and EY (2010)
Provisioning User Access Risk completed, relevant people, SoD rule definitions.
processes Analysis process and technology  Periodic testing and conflict checks should be incorporated into provisioning processes.
III.SAP Security governance activities must  A critical success factor is to support the redesigned processes with the appropriate technology.
Organizational remain in place to help
Structure & ensure the situation does not
Governance arise again

83
SAP Access Reference to Top- Good Practice (I) Detailed description of good practice standard and/or (II) Objective of applying good practice Source
Security Domain Down 8 step standard
approach to
building SAP
(Access) Security
II.SAP Security & Step 5: Security 4.7 Working closely with  Working closely to remediate unauthorized conflicts by regrouping the transaction codes within Protiviti,
Provisioning Testing and Go- BPOs, role owners and the the conflicting role(s) or reassigning the roles for the conflicting user. (2014a)
processes Live Preparation SAP security team to  For SoD conflicts that cannot be resolved for a business-approved reason, such as limited
III.SAP Security remediate unauthorized headcount, mitigating controls should be identified and documented.
Organizational conflicts
Structure &
Governance
II.SAP Security & Step 4: Role and 4.8 Default access should be  Risk arises when companies assign default access (also known as star access) to sensitive menus, EY (2010)
Provisioning User Access Risk assigned sparingly and transactions or security levels.
processes Analysis careful consideration given to
III.SAP Security any menu or security level to
Organizational which it has been assigned.
Structure &
Governance
II.SAP Security & Step 4: Role and 4.9 Non-standard user IDs  Non-standard user IDs and accounts indicate deviations from the standard naming conventions EY (2010)
Provisioning User Access Risk and accounts should be of the company. Risk is that a single user may have multiple accounts that, when used in
processes Analysis investigated for combination, constitute inappropriate access per the defined SoD business definition.
III.SAP Security inappropriate access and
Organizational potentially changed to meet
Structure & company policy naming
Governance conventions
II.SAP Security & Step 4: Role and 4.10 Users with direct access  Shared and powerful system accounts (that users can log into) present a challenge as it is EY (2010)
Provisioning User Access Risk (system access) to the lowest impossible to tell with certainty who has used that specific account. Powerful system accounts
processes Analysis level of security (i.e., menus, only present a problem when these accounts are not locked-down and can be logged into by
III.SAP Security screens, transaction codes) users of the system.
Organizational should be carefully analysed  To prevent unauthorized activity, the company should ensure that it is not possible for a user to
Structure & log into the system or process accounts.
Governance
II.SAP Security & Step 4: Role and 4.11 Risk Mitigation:  Risk mitigation phase can be completed concurrently with remediation; or depending on the KPMG
Provisioning User Access Risk objective at this stage is to objectives and compliance time frame, mitigation can be performed last, when conflicts have (2013), EY
processes Analysis mitigate the remaining risks, been reduced to their absolute minimum. (2010),
III.SAP Security whereby compensating  Many companies will choose to mitigate every potential conflict in order to have a safety net of InteGRC
Organizational control measures should be control in place should a conflict arise. This is a sound and practical strategy for companies (2013)
Structure & established and documented looking to control unforeseen or unpredictable risk.
Governance in the application

84
SAP Access Reference to Top- Good Practice (I) Detailed description of good practice standard and/or (II) Objective of applying good practice Source
Security Domain Down 8 step standard
approach to
building SAP
(Access) Security
 When a company chooses to mitigate a SoD conflict, it accepts the risk associated with that
conflict and attempts to compensate through the use of application, IT-dependent or manual
controls (or some combination thereof).
 Workshops are held within the organization to identify mitigating controls and where
appropriate, leverage existing controls based on business processes.
 When leveraging mitigating controls, management should develop a conflict-by-conflict analysis
to document the existence of specific key controls that mitigate the risk related to the particular
conflict.
II.SAP Security & Step 4: Role and 4.12 Mitigating controls  Generally, it is insufficient to deploy “budget to actual reviews” as the mitigating control for all EY (2010)
Provisioning User Access Risk should address a precise risk SoD conflicts as this control is too general; granularity of controls is important when attempting
processes Analysis to detect and prevent fraud or material misstatement.
III.SAP Security  More than one mitigating control can address a conflict. Implementing a balance of preventative
Organizational and detective controls helps manage the risk should one control fail and supports the use of a
Structure & risk-based approach.
Governance  The conflict matrix should document precisely why each control mitigates the specific conflict
risk. This will serve as a justification to auditors and regulators as to why the control was
selected.
II.SAP Security & Step 4: Role and 4.13 Mitigating controls  Knowing who is performing each mitigating control is relevant since it is important to know if the EY (2010)
Provisioning User Access Risk should list who (name and person performing the mitigating control is also one of the conflicted users.
processes Analysis job title) performs each of
III.SAP Security the mitigating controls in the
Organizational company.
Structure &
Governance
II.SAP Security & Step 4: Role and 4.14 Continuous monitoring  Detective SAP security monitoring processes should be designed (and established), including Provititi
Provisioning User Access Risk procedures must be generating periodic SoD violation reports reviewed by BPOs and role owners to validate security (2014a)
processes Analysis established and followed (as changes.
III.SAP Security the project go-live date
Organizational approaches)
Structure &
Governance
II.SAP Security & Step 5: Security 5.1 SAP security Unit Testing  SAP security testing includes executing all SAP transactions within a role to confirm that the role Provititi
Provisioning Testing and Go- (UT) and User Acceptance has required transactions and authorization objects to complete the process (e.g., display, (2014a)
processes Live Preparation Testing (UAT) are critical update and post a financial transaction).
steps to ensure users

85
SAP Access Reference to Top- Good Practice (I) Detailed description of good practice standard and/or (II) Objective of applying good practice Source
Security Domain Down 8 step standard
approach to
building SAP
(Access) Security
experience minimal access  Security testing also should include formal SoD and sensitive access reviews to confirm the newly
issues prior to go-live. created or updated SAP roles are as SoD conflict-free as possible, and that access to key functions
(e.g. update vendor master data, update chart of accounts) is properly restricted.
 Involving SAP security teams in early stages of the functional testing phase allows the discovery
of potential security issues before it is too late – or costly – to modify roles.
II.SAP Security & Step 5: Security 5.2 Company shall not only EY (2010)
Provisioning Testing and Go- perform intra-application
processes Live Preparation (i.e., within one application)
testing, but also cross-
application (i.e., between
two or more applications)
testing to reveal the
underlying risk of a SoD
conflict.
II.SAP Security & Step 5: Security 5.3 The tone at the top drives  Many companies fail by placing little emphasis on SoD, resulting in significant concerns or worse, EY (2010)
Provisioning Testing and Go- the level of commitment pervasive fraud and control breakdown
processes Live Preparation from all personnel.
II.SAP Security & Step 5: Security 5.4 IT, Finance and other  Finance understands the financial impact associated with the business processes, risks and EY (2010)
Provisioning Testing and Go- management stakeholders mitigating controls better than any other function. Business management will have the clearest
processes Live Preparation must take co-ownership of view on the operational impact. IT understands how to translate that into system data, reporting
the SoD process. and technical remediation. Either way, one organization cannot simply point to the other or
transfer responsibility to the other party.

II.SAP Security & Step 5: Security 5.5 Testing timeline should  Proactive involvement of the auditors helps prevent unnecessary audit fees and allows for EY (2010)
Provisioning Testing and Go- be developed with the input streamlined, efficient testing and reporting.
processes Live Preparation of key business and IT
stakeholders and the audit
team(s).
II. SAP Security & Step 6: Move to 6.1 Once testing is Provititi
Provisioning Production and completed, the newly (2014a)
processes Support designed SAP roles can be
III. SAP Security migrated to the production
Organizational environment according to
Structure & the organization’s change
Governance

86
SAP Access Reference to Top- Good Practice (I) Detailed description of good practice standard and/or (II) Objective of applying good practice Source
Security Domain Down 8 step standard
approach to
building SAP
(Access) Security
management policy and
users can be assigned
II. SAP Security & Step 6: Move to 6.2 Establish a support team  This team not only can help resolve access issues on a timely basis, but also run access risk Provititi
Provisioning Production and specifically assigned to reports to determine if security changes will result in SoD or other access risks. (2014a)
processes Support address any SAP access issues  Also, a communication plan should be established to ensure affected users are aware of any
III. SAP Security during go-live and changes and support protocols related to go-live of the SAP system
Organizational stabilization activities.
Structure &
Governance
II. SAP Security & Step 6: Move to 6.3 During SAP  This is done to help with stabilization of the new system, to ensure users are capable of Protiviti,
Provisioning Production and implementation and upgrade performing job functions during and after go-live, and often is performed using SAP GRC AC to (2014a)
processes Support projects allow for temporary review transaction and super-user action logs.
III. SAP Security broader access for “power  Review and remove this temporary broader access after the new implementation is stable.
Organizational users” during the go-live and
Structure & stabilization period.
Governance
IV. Ongoing Step 7: SAP GRC 7.1 It is primarily a business  User access activities comprises authorizing and initiating additions, modifications and Protiviti,
Management & AC Post Go-Live responsibility to ensure that terminations to user access tables (2013)
Monitoring of the and Ongoing management of user access  While IT departments should ensure employees in the IT group have adequate access consistent
Security Management & activities does not result in with sound segregation of duties principles and appropriate limitations on access to sensitive
Environment Monitoring of the inappropriate conflicts or functions, these employees should not be responsible for interpreting business user access
Security access to sensitive requests for propriety.
Environment information.  In complex ERP systems, IT personnel can provide critical expertise on how best to establish and
build user access profiles according to the organization’s business requirements.
IV. Ongoing Step 7: SAP GRC 7.2 Deploy a standard access  Deployment of Access Control application functionality enables optimization of the user Protiviti,
Management & AC Post Go-Live management solution, such management and role management process. It enables automating user access management (2013),
Monitoring of the and Ongoing as SAP GRC AC, which can be tasks and delivers visibility across the enterprise. Also, centralizing and automating the KPMG
Security Management & complemented with an provisioning process leads to greater efficiency and control. (2013)
Environment Monitoring of the identity management tool,  Furthermore deployment helps ensure:
Security like SAP NetWeaver Identity - required approvals are consistently and efficiently obtained during the provisioning process
Environment Management. - security changes for potential SoD violations are being tested prior to granting access, and
- mitigating controls are applied prior to moving the change into the production environment.

IV. Ongoing Step 7: SAP GRC 7.3 Develop a strategic vision  Having a strategic vision will enable security to be addressed in an organized, efficient and Protiviti,
Management & AC Post Go-Live for access management that proactive way, while minimizing exposure to major access management risks. (2013)

87
SAP Access Reference to Top- Good Practice (I) Detailed description of good practice standard and/or (II) Objective of applying good practice Source
Security Domain Down 8 step standard
approach to
building SAP
(Access) Security
Monitoring of the and Ongoing aligns with business
Security Management & requirements and risk
Environment Monitoring of the tolerance.
Security
Environment
IV. Ongoing Step 7: SAP GRC 7.4 Identify/define policies  Procedures should be defined for: (1) handling authorization requests which compromise the Protiviti,
Management & AC Post Go-Live that make access defined rules, (2) obtaining appropriate approval of specific exceptions and (3) modifying the (2006),
Monitoring of the and Ongoing management standards clear, requested access in such a way that the defined rules are not compromised. Protiviti,
Security Management & as well as procedures to (2013)
Environment Monitoring of the enforce those standards
Security
Environment
IV. Ongoing Step 7: SAP GRC 7.5 Establish Key  Examples (see below) include statistics on user SoD violations, role SoD violations, provisioning of Protiviti,
Management & AC Post Go-Live performance indicators service-level agreements (SLAs), and remediating tracking. (2013)
Monitoring of the and Ongoing (KPIs) and metrics that  Managing users:
Security Management & enables management of the - # users having high/critical violations,
Environment Monitoring of the access management - Total # of high/critical violations at user level,
Security governance process (by the - Average lead time for processing 'create', 'change' and/or 'remove' access requests,
Environment governance committee or - Average transactions per user
equivalent thereof).  Managing roles:
- # (single/master, composite or job) roles having High or Critical SoD violations built into them,
- # roles not been assigned to users,
- # of transactions per single/master role,
- # duplicate transaction codes between roles
 Managing emergency access:
- How many firefighter and user accounts exist by functional area?
- How often are firefighter accounts being used?
- Are firefighter logs being reviewed in a timely manner, and are issues addressed appropriately?
IV. Ongoing Step 7: SAP GRC 7.6 Work with Business  This helps ensure the governance initiative will add value to the business. Protiviti,
Management & AC Post Go-Live Process Owners (BPOs) and (2013)
Monitoring of the and Ongoing secure their buy-in
Security Management & throughout the development
Environment Monitoring of the of the access management
Security governance processes.
Environment

88
SAP Access Reference to Top- Good Practice (I) Detailed description of good practice standard and/or (II) Objective of applying good practice Source
Security Domain Down 8 step standard
approach to
building SAP
(Access) Security
IV. Ongoing Step 7: SAP GRC 7.7 Perform periodic self-  This will ensure it continues to accomplish the core objectives Protiviti,
Management & AC Post Go-Live reviews of the access (2013)
Monitoring of the and Ongoing management governance
Security Management & process
Environment Monitoring of the
Security
Environment
IV. Ongoing Step 7: SAP GRC 7.8 Deploy organizational  At the center is a governance lead: a subject matter expert who reports to executive Protiviti,
Management & AC Post Go-Live structure that is optimal for management. This person drives the day-to-day access tasks for access management, (2013)
Monitoring of the and Ongoing the long-term success of coordinates policy changes, and is the primary contact for the business.
Security Management & access management controls.  The governance lead also coordinates the governance committee, which consists of stakeholders
Environment Monitoring of the from the various organizations, such as information systems (IS), finance, internal audit, and the
Security BPOs.
Environment  The governance team designs, implements and executes controls. It also owns the description of
roles and responsibilities. Information from the governance team is communicated to the user
community and supported though access management single point of contact within the
business and associated BPOs.
IV. Ongoing Step 7: SAP GRC 7.9 Key areas to consider for  Ownership: ISACA
Management & AC Post Go-Live a governance team should - Who approves access? (2012)
Monitoring of the and Ongoing be around Ownership, Risk - Who approves assigning a mitigating control?
Security Management & Level, New functionality and - Who defines the risk/function and approves changes?
Environment Monitoring of the Ongoing Processes  Risk level:
Security - What does each risk level mean (low/medium/high/critical)?
Environment - What are the expectations for each risk level?
 New functionality:
- What is the process to identify new functionality added to the system?
- How are these analysed and included (if needed) into a ruleset?
 Ongoing processes:
- Access Provisioning (Preventative SoD/sensitive access analysis)
- Appropriate approvals (role owner, manager)
- Periodic Access Reviews (detective SoD/sensitive access analysis)
- Mitigating Control Reviews (review of users with sensitive access based on business need)
IV. Ongoing Step 7: SAP GRC 7.10 A security governance  Such a policy is to ensure consistency and minimize significant risk to the environment Protiviti,
Management & AC Post Go-Live policy should be in place that  Policy should be designed to create standards around the following key areas: User Access (2013)
Monitoring of the and Ongoing contains standards for the Management, Custom Program and Table Security Requirements, Backend System

89
SAP Access Reference to Top- Good Practice (I) Detailed description of good practice standard and/or (II) Objective of applying good practice Source
Security Domain Down 8 step standard
approach to
building SAP
(Access) Security
Security Management & SAP ECC production Configurations, Role Creation and Maintenance Standards, Password Management, Security
Environment Monitoring of the environments Parameters.
Security
Environment
IV. Ongoing Step 7: SAP GRC 7.11 Independent reviews of  Review should consider multiple elements which include, among other things: Protiviti,
Management & AC Post Go-Live user access rights should be - Evidence of the application and data owners' approval and monitoring of the propriety of the (2006),
Monitoring of the and Ongoing performed periodically access “touch points” identified. KPMG
Security Management & - Appropriate consideration of system administration access for the transactions being (2013)
Environment Monitoring of the reviewed.
Security - Evidence that critical segregation of duties rules are not being violated due to personnel access
Environment modifications since the prior review.
- Organizational policies regarding access provisioning are being followed.
- Evidence that specific critical transactions were not inappropriately accessed since the previous
review.
 If changes are needed based on these reviews, a standard process should be in place to ensure
these changes are handled in an expedient manner.
 If there are findings in the access security area that evidence a breakdown in the security
administration process, a root-cause analysis should be undertaken and the matters resolved on
a timely basis.

IV. Ongoing Step 7: SAP GRC 7.12 Integrate Access  SAP GRC AC can be integrated with SAP Process Control, whereby, for example, the effectiveness KPMG
Management & AC Post Go-Live Control-application with of the mitigating controls that were assigned in SAP GRC AC can be determined. By making use of (2013)
Monitoring of the and Ongoing Continuous Control the 'test of effectiveness' functionality in SAP Process Control, it is possible to determine if the
Security Management & Monitoring (CCM) mitigation controls have actually been executed and it can also be determined whether the
Environment Monitoring of the application control is effective.
Security  As part of the stay clean – continuous monitoring phase, important prerequisite is also to assign
Environment responsibilities and define procedures for periodic monitoring of assigned authorizations and
breaches with regard to segregation of duties.

IV. Ongoing Step 7: SAP GRC 7.13 Decide on using Fire Typical risks with the Role-Based Fire Fighter Concept are: Customer
Management & AC Post Go-Live Fighter ID concept versus  While using the Fire Fighters role-based concept no reason code can be entered and no comment Advisory
Monitoring of the and Ongoing Role-Based Fire Fighter be made. In contrast to the Fire Fighter ID concept, the user does NOT enter the information. The Group
Security Management & concept for Emergency controller who has to check and verify the logs does not know why a change is being made. (2015)
Environment Monitoring of the Access or Fire Fighter  Under the Fire Fighters role-based concept, the end users do not know they are using Fire Fighter
functionality roles. Due to the missing log on, the end users do not see any difference between using a Fire

90
SAP Access Reference to Top- Good Practice (I) Detailed description of good practice standard and/or (II) Objective of applying good practice Source
Security Domain Down 8 step standard
approach to
building SAP
(Access) Security
Security Fighter role and the other regular roles assigned to them. This can lead to extensive use/ misuse
Environment of the Fire Fighter roles.
 The role-based access does not provide logs for systems where the access is given based on
authorization objects and not on transaction code level.
IV. Ongoing Step 7: SAP GRC 7.14 Define/Identify activities It is recommended that Fire Fighter or Emergency Access is to be used for: Customer
Management & AC Post Go-Live for which Emergency Access  Emergency Access: Advisory
Monitoring of the and Ongoing Management (EAM)127 or - System Issues (Administration usually does not have global access rights with their regular user Group
Security Management & Fire Fighter (FF) functionality ID) (2015)
Environment Monitoring of the is to be used. - Ability to replace colleagues who are out of office (unplanned)
Security  Critical Access/Access Rarely Required:
Environment - Open/Close system for Customizing/Development
- Year-End Closing activities
- Upload of data into PROD systems
- Import of transports into PROD systems
- Depreciation run
 Helpdesk and Support:
- Helpdesk and Support usually have display access with their regular user ID but must have
change access from time to time to test issues the end users are having
 Instead of Mitigations:
- If a user has a SoD issue with the regular user ID, part of the access can be given using the Fire
Fighter concept instead of assigning a mitigating control. This option should be considered only
if the activity is rarely carried out (e.g., 6 times per year review of Fire Fighter logs versus 12
monthly mitigation control activities).
 Performance Critical Activities, which should be carried out only by one person at a time:
- E.g., MRP run
IV. Ongoing Step 7: SAP GRC 7.15 Emergency Access  Review of Fire Fighter Users: Customer
Management & AC Post Go-Live Management Review is to be - Sometimes assigning a Fire Fighter ID may be the quicker solution to a missing access problem. Advisory
Monitoring of the and Ongoing deployed and should consist The users accumulate access to Fire Fighter IDs. Once a year a review should be done on if the Group
Security Management & of the following elements: (1) roles required by a user using a Fire Fighter ID can be assigned directly to him/her. (2015)
Environment Monitoring of the Review of Fire Fighter Users,  Review of Fire Fighter Access:
Security (2) Review of Fire Fighter - Once per year a review should be carried out and the executed transactions – using Fire Fighter
Environment Access, (3) Review of Fire Access - should be checked on whether they are included in roles that can be requested by end

127
EAM is a submodule within the SAP GRC AC application that can be used to manage – temporary- emergency or firefighter access.

91
SAP Access Reference to Top- Good Practice (I) Detailed description of good practice standard and/or (II) Objective of applying good practice Source
Security Domain Down 8 step standard
approach to
building SAP
(Access) Security
Fighter Assignments and (4) users. Many users may use Fire Fighters because requesting a role change is too complicated or
Review of Fire Fighter Logs takes too much time.
- Organizations may find a group of Fire Fighter Users using the same transactions and another
group of Fire Fighter Users using another group of transactions. This can/should result in a split
of Fire Fighter IDs that are more appropriate to those 2 groups. This review can be carried out
using the FF-logs and Pivot tables showing the clusters of users and transactions
 Review of Fire Fighter Assignments:
- Once per year a review should be carried out to find out which users have access to which Fire
Fighters, but also to ensure that (i) obsolete access is removed (e.g., user is not responsible for
the task any longer) and (ii) unnecessary assignments are removed (e.g., Fire fighter access was
granted in case the user has to replace a colleague, but the department has grown since that
time and a replacement is in place)
 Review of Fire Fighter Logs:
- After a Fire Fighter was used, logs are created that contain the changes done using the Fire
Fighter. It is recommended that it is defined how the logs are generated, to avoid Controllers
waiting for logs or not knowing that a Fire Fighter was used and not reviewing the logs.
Recommended to define a standard Notification Type for the organization.
- Usage of the EAM workflow in SAP GRC AC is recommended, so the Fire Fighter Controllers
receive a Workflow notification and the reviews done are recorded centrally.
- After the implementation of new Fire Fighters (IDs), and once per year, a review should be
carried out. Logs should be reviewed for (i) length (number of entries) and (ii) for the length of
time a Fire Fighter was used by a person
- A policy should be in place that forbids users to use Fire Fighters extensively. Users should
either use their own regular user ID or request missing roles. Fire Fighters should only be used
in emergency cases or exceptional cases, not for hours.
IV. Ongoing Step 7: SAP GRC 7.16 Deploy Exception-  Enable exception-based monitoring of SoD violations: Greenlight
Management & AC Post Go-Live Based SoD Monitoring and - Automate identification and review of actual SoD violations Technolo-
Monitoring of the and Ongoing focus on actual access - Alert business owners only when exceptions occur, reducing manual control efforts and gies (2015)
Security Management & violations eliminating false positives
Environment Monitoring of the - Use a comprehensive library of automated SoD controls across business processes
Security - Have centralized tracking, investigation, and resolution of SoD violations
Environment  Assess the financial exposure of SoD violations:
- Summarize the monetary value of actual SoD violations
- Clearly articulate the financial exposure that broad user access has on the business
- Drive change where the impact exceeds the materiality threshold

92
SAP Access Reference to Top- Good Practice (I) Detailed description of good practice standard and/or (II) Objective of applying good practice Source
Security Domain Down 8 step standard
approach to
building SAP
(Access) Security
 SAP Access Violation Management (AVM) offers the functionality that is required to deploy
Exception-Based SoD Monitoring and focus on actual access violations (also taking into
consideration the financial exposure of such actual SoD violations
IV. Ongoing Step 7: SAP GRC 7.17 Reduce governance  Extend the capabilities of the Access Control application across all relevant enterprise systems Greenlight
Management & AC Post Go-Live costs of enterprise-wide (i.e. also focus on risk in applications outside ERP), e.g.,: Technolo-
Monitoring of the and Ongoing access by extending the - Non-ABAP applications like SAP Business Planning and Consolidation (BPC), SAP Master Data gies (2015)
Security Management & capabilities of the Access Management (MDM), SAP Master Data Governance (SAP MDG)
Environment Monitoring of the Control application across all - Cloud-based applications like Ariba, SuccessFactors, Salesforce.com
Security relevant enterprise systems - Non-SAP applications like Oracle, JD Edwards, Hyperion
Environment (SAP and non-SAP)  SAP Access Violation Management (AVM) analyses transactions and user activities across
business applications (SAP and non-SAP) to detect and prevent risks that can materialize in SoD
violations
IV. Ongoing Step 8 8.1 Facilitated through SAP  Two good practice scenarios for possible SAP NW IDM and SAP GRC AC integration are as follows: InteGRC
Management & Compliant GRC AC and SAP IdM - Scenario 1: IdM-Driven User Provisioning with Access Control Integration; (2015), SAP
Monitoring of the Identity integration, provide - Scenario 2: Access Control-Driven User Provisioning with IdM Integration. (2015)
Security Management automated, position based
Environment role management while also
ensuring business rules (SoD)
compliance.
IV. Ongoing Step 8 8.2 When exploring potential  Request submission source SAP (2015)
Management & Compliant SAP GRC AC – SAP IdM - From where will the provisioning request be initiated (HR System and/or SAP GRC AC and/or
Monitoring of the Identity integration scenarios, do SAP IdM)?
Security Management considered items like:  Provisioning roles
Environment Request submission source, - Role source: Where will the roles for provisioning be maintained (AC and/or IdM)?
Provisioning roles, Approval - Preferred approach is to have one role source for SAP roles
workflow, SoD Risk analysis, - Going forward it is expected that SAP will build-in business role synchronization between SAP
Request status and audit GRC AC and SAP IdM, making this issue not/less relevant
trails, Existing functionality  Approval workflow
and change control - Do you want to use approval workflow within AC and/or IdM?
- Need to consider user notifications from AC and/or IdM
 SoD Risk analysis
- When provisioning new users, the request does not have to be submitted to AC for risk
analysis, and no polling is required. IdM can retrieve the result by also polling the risk analysis
web service with Request ID.
- When provisioning existing users, risk analysis can be called by IdM

93
SAP Access Reference to Top- Good Practice (I) Detailed description of good practice standard and/or (II) Objective of applying good practice Source
Security Domain Down 8 step standard
approach to
building SAP
(Access) Security
 Request status and audit trails
- Consider requirements for request status and audit trails while defining the integration
solution (web services can only pass certain fields, while more details may be viewed natively
in AC or IdM)
 Existing functionality and change control
- IdM’s change control policy and its impact on solution and implementation: Are changes to the
current IdM process realistic?

94
4 Case Study: Applicability of Good Practice SAP (Access) Security Design Framework

4.1 Introduction
Chapter 4 describes the applicability of the good practice SAP (Access) Security Design Framework - as shown in
§ 3.3 - at the case study object. The applicability of each recommendation from the good practice framework is
being validate/assessed. Outcome of this validation will provide input for:
 Conclusions with regard to the applicability of the individual recommendations/requirements that underlie
the good practices SAP (Access) Security Design framework, as well as a (preliminary) conclusion with
regard to the overall applicability of the framework;
 Identification of any adjustments and/or additions that need to be made to the developed SAP (Access)
Security Design framework;
 Identification of any reasons and/or practical problems that (might) hinder the application of the SAP
(Access) Security Design framework by the case study object;
 Set of recommendations for the case study object itself
Outcome of the ‘practical validation/assessment’ will be structured in line with each step within the Top-Down
8 step approach (see chapter 3) to building SAP (Access) Security. The outcome is explained for each of these
steps in a separate (sub) paragraph.

4.2 Case Study: Applicability of Good Practice SAP (Access) Security Design Framework

4.2.1 Step 0: Define and Deploy Organizational Change Management Approach

Control 0.1: Define and Deploy Organizational Change Management Approach

Case study object situation: Although the importance of organizational change management is increasingly
recognized within the case study object as a key enabler for deploying SAP GRC AC, it currently lacks a (defined
or formalized) organizational change management approach. Ad hoc – and often unconsciously – few elements
of an organizational change management approach are applied. As an example: for the Procurement activities
within SBU ‘C’ SAP, SAP GRC AC (integrated with SAP IdM) is currently being piloted. By achieving a quick and
visible performance improvement (e.g., reduction of SoD conflicts, simplified automated user provisioning
process), and communicating these quick wins, a better foundation can be created for the wider roll-out of SAP
GRC AC (and SAP IdM) in the other SBUs within the case study object.
However, progressive insight within the case study object has learned that such ad hoc initiatives are not
sufficient and that a formal change management model (e.g., Kotter’s 8 stage model) is to be deployed for the
Access Control change initiative to succeed. Both at case study object executive and business level, there are
simply too many issues competing for priority, making it necessary that – as one of the first steps in deploying
an organizational change management approach – a sense of urgency is established that ensures both pull (i.e.
by the business itself) and push factors (by executive leadership) are in place. Similar to the need for creating a
sense of urgency, the need for other organizational change management elements is increasingly recognized
and acknowledged. Here one can think of developing a communication plan and bringing in specific change
management expertise.
Conclusion: control assessed to be valid, no need to revise control description. Considering the wide impact
the Access Control initiative will have on the business (i.e. once SAP GRC AC-SAP IdM has gone live) and -
therefore - the business support and involvement that is required in the project, the Access Control initiative
should not be regarded as a project for which involvement of second line functions as risk management,
compliance and/or IT Security is sufficient. Business (and executive management) support and involvement is
required and needs to be established through the definition and deployment of an organizational change
management approach. In my view this control is not only valid for the case study object, but can be applied to
all kind of multinational organizations that are deploying SAP GRC AC across the organization.

Control 0.2: Identify the right internal resources

Case study object situation: Importance of this control is fully recognized and acknowledged within the case
study object. However with regard to active executive participation as well as having good collaboration
between all parties, improvement is required.
Neither the company CFO and/or CEO are participating in the oversight of the Access Control project (i.e. it
lacks a project governance structure in which either the CFO or the CEO has a clear oversight role). For the
global SAP+ program such a governance structure – in which both the company CEO and CFO have an oversight

95
role - is in place. Unfortunately, the Access Control initiative is not an integral part of the scope of the SAP+
program and its underlying SBU SAP+ projects. As a consequence the Access Control related activities are/were
seen – both by the case study object’s SAP+ Project Management Organization (PMO) as well as the business
representatives in the SAP+ project - as activities that come on top-off the actual SAP+ program and projects.
Since SAP is rolled out per SBU - as a lesson learned from the SBU ‘A’ project – for the SBU ‘B’ SAP+ project
there is tendency to make sure that as much as possible the activities around Access Control are considered as
integral activities of the SBU ‘B’ SAP+ project that need to be considered early in the project.
Furthermore the collaboration between all parties also requires improvement. Too often it appears that where
the presence of decision maker(s) are required in Access Control project meetings, such presence is actually
lacking. These absences not only lead to a lack of alignment between the different functions in the Access
Control project, but also lead to situations where the decision maker who has chosen not to attend the project
meeting(s) may choose to decide and act differently from what was agreed in the meeting. I strongly belief that
people acting in such a way is not specific to the case study object situation, but is typical for multinational
organizations in which cultural differences may determine the way people do act.
Conclusion: control assessed to be valid, additional guidance in control description/explanation is required. In
addition to the explanation already provided in the good practice framework for this control (see § 3.3), I
conclude that awareness about cultural differences (in case of multinational organizations) is inserted as an
attention point in order to ensure the right internal resources are identified and that there is good
collaboration between all parties. Because of these cultural differences, there is no one-size fits all approach
that can ensure the right internal resources are identified and that there is good collaboration between all
parties. Moreover, the need to tailor the approach based on cultural differences can/should also be applied to
the organizational change management approach referred to in control 0.1.

4.2.2 Step 1: Define SoD Policies and Rule Design

Control 1.1: Define in scope SAP applications

Case study object situation: Relevant SAP ERP/ECC modules and SAP applications – that ought to be in scope
for the Access Control project - have been determined. Different from the control description which describes
that this needs to be done in liaison with Business Process Owners (BPOs) and the SAP functional leads, within
the case study object the definition of ECC modules and applications in scope has been performed by the ERM
function relatively independently. Initial focus on the Access Control project was on SAP ECC modules only, the
other SAP applications follow(ed) later. To illustrate this, the case study object business ruleset (containing risks
with regard to SoD conflicts, critical actions and sensitive access) initially only covers the SAP ERP/ECC modules.
Later on in the project, the business ruleset will also cover access risks related to other SAP applications like
SRM and APO128 that also are being implemented as part of the case study object’s SAP+ program.
Furthermore, there is a chance that access risks with regard to a specific SAP application are not covered timely
or that a risk-based approach (i.e. first focus on key access risks and key access controls) is not deployed.
Conclusion: control assessed to be valid, additional guidance in control description/explanation is required.
Recommended that - explanation/guidance to - the control (description) also notes that to ensure that the
Access Control project applies a risk-based approach. It is not sufficient that risk management and compliance
functions work with BPOs and SAP functional leads to define the SAP modules and applications in scope for the
Access Control project, also the order in which these modules and applications are dealt with within the
Access Control project, need to be agreed upon. To clarify, it is very likely that any SoD conflicts with regard to
some SAP ECC modules do have a lower risk profile than vast majority of the SoD conflicts with regard to SRM
and/or CRM.

Control 1.2: Establish an agreed-upon and signed-off SoD management framework (‘ruleset’)
Case study object situation: A global SoD management framework (‘ruleset’) has been agreed upon with
relevant business representatives in the different SBUs. For each business process, SoD matrices have been
developed and aligned with business representatives. However, obtaining sign-off of the SoD management
framework seems to be a hurdle. It is acknowledged by ERM - that is driving the Access Control project - that
such sign-off is to be achieved. Especially in SBU ‘C’, where case study object headquarters are located, the
sign-off of documents like frameworks, policies and procedures is seen as a crucial step in the formal
endorsement and ratification of such documents. However I can imagine a formal sign-off to be less relevant in

128
SAP APO: SAP Advanced Planning & Optimization.

96
some other cultures, where it is sufficient to have business representatives’ verbal commitment that they
agree with the framework document.
Conclusion: control assessed to be valid, no need to revise control

Control 1.3: Classify SoD risks into risk levels (e.g., critical, high, medium and low risk)
Case study object situation: Three different risk levels (critical, high and low) have been defined and each
access risk has been assigned a risk rating. Within the case study object, because the risk management function
(ERM) was finding it a challenge to differentiate between follow-up actions required for low versus medium
risks (e.g., remediate, mitigate, accept), it was decided that there is no added value in having both a medium
and low risk rating in place. Depending on the risk rating assigned to a specific access risk, the access risk is
either not allowed within the authorization roles (hence it should be remediated), a mitigating control should
be in place to ensure any error, compliance and/or fraud issues are detected timely or – in case of a low risk
rating – the access risk is recognized mainly for information purposes only.
Conclusion: control assessed to be valid, no need to revise control

Control 1.4: Evaluate SAP standard and custom transactions

Case study object situation: Control is completely applicable to the case study object situation. In addition to
the SAP standard transaction codes, with the support of the IT SMEs all customized Z and Y transaction codes
are evaluated to determine their importance from an access risk point of view. Both custom transactions from
the SBU ‘C’ SAP system as well as any newly build custom transactions that have been and/or are being created
for the SBU ‘A’ SAP+ and SBU ‘B’ SAP+ project are being evaluated and dependent on the outcome of this
evaluation being assigned to a specific function in the SoD ruleset. Custom transactions that involve display
only functionality are being filtered out and ignored for SoD ruleset purposes. However, this approach ignores
the fact that there can be access risks coming from sensitive access (which do not even require transactions
that provide the ability to create, modify, post or delete data).
Conclusion: control assessed to be valid, additional guidance in control description/explanation is required.
Recommended that - explanation/guidance to - the control (description) also notes that further to evaluating
SAP standard and custom transactions to identify those that provide the ability to create, modify, post or
delete data related to any of the identified risks, it is recommended that also ‘display only’ custom
transactions are being considered. Those display only custom transactions that are related to sensitive
access – in consultation with IT SMEs (and BPOs) - should be added to the business ruleset as well.

Control 1.5: SoD ruleset needs to reflect the company’s risk profile.
Case study object situation: Control is completely applicable to the case study object situation. The risk rating
for each access risk within a business process has been aligned with the different SBU BPOs for that specific
process. In case SBU BPO risk ratings for one and the same access risk do vary, the risk management function
(ERM) has chosen to select the most prudent risk scoring from the different scores and have this scoring
included in the global case study object ruleset. Alternative approach could be to have different rulesets per
SBU. Especially from a maintainability point of view this alternative approach is not preferred.
Conclusion: control assessed to be valid, additional guidance in control description/explanation is required.
Recommended that - explanation/guidance to - the control (description) also notes that for multinational
organizations that don’t have all their business processes completely harmonized (yet), it may be considered
to have different rulesets per region or per SBU. This is to be considered when - for one and the same
business processes - the access risks identified and/or the risk scorings assigned by the different
regional/SBU BPOs, do (significantly) vary between the different regions and/or SBUs.

Control 1.6: Define Sensitive Access and Critical Actions Policies

Case study object situation: Control is completely applicable to the case study object situation.
Conclusion: control assessed to be valid, no need to revise control

Control 1.7: A formal (SAP) GRC AC application requirements document should be completed (including sign-off)
based on discussions with business process management
Case study object situation: Control is completely applicable to the case study object situation.
Conclusion: control assessed to be valid, no need to revise control

Control 1.8: Identify Risk Owners

97
Case study object situation: Although risk owners have not been formally identified and assigned, there is no
misunderstanding that the BPOs are the actual risk owners. However, since the case study object SAP+
program is also used as an enabler to achieve more harmonization in business processes between the different
SBUs, it is not always clear anymore (among the BPOs) whether the SBU BPOs should still be regarded as the
risk owners for the access risks in their business processes in their SBU. In the legacy situation in which all SBUs
had their own ERP system and in which there was little to none business process harmonization between SBUs,
it was clear that the SBU BPOs were responsible for the access risks in their SBU. Albeit that in the legacy
situation (in which each SBU had its own approach for dealing with access risks and controls), there are large
differences in the extent to which BPOs actually took ownership of the risks and whether they act accordingly.
Such differences could be recognized between SBUs but also between BPOs in one and the same SBU.
In addition, the idea of establishing global BPOs has only recently captured serious attention within the case
study object. Prior to the case study object SAP+ program – due to the lack of business process harmonization –
for the majority of the business processes, there was no urgent need for establishing global BPOs.
Conclusion: control assessed to be valid, additional guidance in control description/explanation is required.
Recommended that - explanation/guidance to - the control (description) also notes that for multinational
organizations that aim to achieve business processes harmonization or standardization facilitated through a
SAP129 consolidation project (i.e., a project that is aimed at reducing the number of SAP instances) or SAP
migration project (i.e. a project aimed at moving from different legacy systems to SAP), it is important that risk
ownership for access risks both at global level as well as at regional/SBU level is clearly assigned. Especially,
when the consolidation or migration project leads to a shift of access risk ownership from regional/SBU BPOs to
global BPOs it is important that this is made explicit and formalized. Furthermore, it is important that the
organizational change management approach – as referred to in control 0.1 – also captures necessary steps
to ensure the effect these changes will have on both the regional/SBU BPOs as well as the global BPOs are
effectively managed. Not only is there a risk of regional/SBU BPOs resisting the change since they will lose
some responsibilities, there is also a risk that global BPOs will be wary of having to make decisions about access
risks and access controls that involve users in other regions/SBUs and in other cultures.

Control 1.9: Policy on how to deal with a breach of the segregation of duties is determined
Case study object situation: ERM has developed an ‘Access Risk Remediation & Mitigation Guideline’ that
describes the rules and processes to identify, mitigate and monitor access rights related risks caused by SoD
conflicts, critical actions or sensitive access in the case study object’s SAP+ system. The objective of this
guideline is to ensure that no critical combination of activities will be assigned to a user or - if the assignment is
required from an operational or business perspective - compensating controls are defined and assigned to
mitigate the risks related to the SoD conflict. Also the guideline requires that controls have to be implemented
to periodically review assigned authorizations and SoD conflicts to users as well as the execution of the
assigned mitigating controls, if any.
The ‘Access Risk Remediation & Mitigation Guideline’ does not describe how to deal with an actual breach of
the segregation of duties. This policy document does not provide clarity regarding any follow-up actions when
something out-of-policy occurs. No (visible) reference is being made to a compliance management system that
monitors all activity relative to the business policies of the case study object organization and that ensures
immediate remedial action is taken - from shutting down user access to the SAP application(s) to sending e-
mail notifications to the security team.
On the other hand, in the case study object’s ‘Access Management Policy’ document that is owned by IT
Security, it is explicitly stated that “lack of compliance with this policy regarding the proper access, use,
dissemination or security of company data by anyone in case study object’s IT Shared Services organization
will be reported to the appropriate manager and may result in engagement of the case study object’s Human
Resources or others as deemed necessary”. Since this only refers to IT Shared Services employees (including
temps and contractors), I do recommend that in the case study object Access Management Policy it is made
clear that any follow-up actions when something out-of-policy occurs (i.e. in particular a breach of SoD), will
not be limited to anyone in the IT Shared Services organization, but is applicable to the anyone in the case
study object organization (including temps and contractors).
Conclusion: control assessed to be valid, additional guidance in control description/explanation is required.
Recommended that - explanation/guidance to - the control (description) also lists some potential immediate
remedial actions (e.g. shutting down user access to the SAP application(s), sending e-mail notifications to the
security team) that can be referred to in the policy. Furthermore, it should also be noted that any SoD

129 Instead of SAP, here one can also read other well-knows ERP systems such as Oracle, JD Edwards, etc.

98
breaches are investigated as soon as possible. Of course, this additional guidance does not preclude that the
decision about the actual remedy and potential disciplinary consequences is to be defined by the organization.

Control 1.10: Policy on how to deal with the use of emergency users is determined
Case study object situation: Until the SAP GRC AC project, ERM has had no involvement with the Fire Fighter
(FF) or Emergency Access process. This process used to be the domain of the IT Security department and
therefore initially IT Security was not very receptive to ERM – albeit in liaison with themselves - setting the
standards for the new FF or Emergency Access process supported by the SAP GRC AC Emergency Access
Management (EAM) submodule. As a consequence, design and deployment of a revised FF or Emergency
Access process using SAP GRC AC EAM is being picked up as one of the last elements of the SAP GRC AC project.
Similar to some of the other controls that implicate a change from the previous ‘way of working’, having an
organizational change management approach seems to be an important element in ensuring these kind of
required changes are managed effectively. Nevertheless, key design issues with regard to a revised – and more
controlled - FF or Emergency Access are currently agreed upon between ERM and IT Security and will be set out
in a (revised) FF or Emergency Access policy.
Conclusion: control assessed to be valid, additional guidance in control description/explanation is required.
Recommended that - explanation/guidance to - the control (description) also lists some specific items that
should be addressed in the emergency access policy. The following items should be considered (see also
control 7.13, 7.14 and 7.15 which address controls and considerations related to Emergency Access
Management in SAP GRC AC):
- Scope of the emergency access policy: (i) include reference to the SAP applications in scope and (ii) provide clarity over
whether the policy comprises both functional IT users as well as business end users.
- Define Fire Fighter (FF) or Emergency Access use: listing the different activities for which FF or Emergency Access is to
be used. See also control 7.14
- FF ID concept versus Role-Based FF concept: make clear which FF concept is being applied as well as the underlying
rationale and what the implications are. Some of these matters not necessarily have to be included in a policy, however
arguments for choosing one of both concepts at least should be set out in a decision paper. See also control 7.13
- Define process for requesting FF or Emergency Access: preferably this includes a flow chart along with roles and
responsibilities.
- Define process for reviewing FF or Emergency Access: See also control 7.15
- Define process for administration of FF or Emergency Access users: policy should list who is responsible for the
administration of FF or Emergency Access users. Furthermore, it should describe how is being dealt with escalations
that become relevant when there are errors in workflows and/or workflow items are not responded to.

4.2.3 Step 2: Initial Role and User Design

Control 2.1: A good authorization concept should have the following characteristics: Reliability, Security,
Testability, Flexibility, and Comprehensibility.
Case study object situation: Case study object’s IT Security department has developed the authorization
concept and naming convention for the ‘new SAP+’ authorization roles set-up. Main objectives of the newly
designed case study object SAP Security Authorization concept are to ensure that (i) authorization roles and
assigned authorization roles to users are conflict free or mitigated before SBU ‘A’ SAP+ and SBU ‘B’ SAP+ Go-
live and (ii) that the authorization roles do facilitate (legal) compliance with confidentiality agreements. The
authorization concept is the Function/Task-based concept, which is commonly used by large entities. The role
structure is: master role (task) - derived role - composite role (function) - job role. Therefore, the concept on

99
paper looks adequate. Below overview shows most common authorization objects.
Function / Task based Concept Function based Concept Task based Concept

Composite Role
All functions specific Single Role
transaction codes are
Single Role combined in 1 single role

Single Role
Single Role

Single Role

All tasks in the organization are
combined in single roles. The
single roles are assigned to
composite roles, which represent a
function.
Some organizations apply the
business role concept; introducing
an additional layer above the
composite
Each function in the
organization has 1 single
role, which contains all
activities.
This authorization concept is
not recommended
All tasks in the organization
are combined in separate
single roles. These singles
roles contain logically
grouped transaction codes.

Figure 52. Most common authorization concepts

However, in practice IT Security has created the master roles based on the existing ‘old’ SBU ‘C’ SAP roles. As a
result the newly build master roles are not ‘task’ but ‘function’ based. Typical risks related to this function
based approach are:
- Legal non-compliance with for example export controlled materials;
- Complex to maintain;
- High risk on segregation of duty conflicts, and complex to remediate;
- For SBU ‘A’ SAP+, IT Security has chosen to assign multiple ‘master roles’ to individuals to cover the legacy
SAP SBU ‘A’ SAP roles, which will result in many critical SoD conflicts.
Below overview shows the differences between the Function/Task-based authorization concept and the SBU
‘A’ SAP+ concept that has actually been built and deployed.

Figure 53. Newly Build SBU ‘A’ SAP+ Authorization Concept versus Function / task concept

100
To illustrate the above: within SBU ‘C’ SAP rebate handling is done within the Sales & Distribution (SD)-module
in SAP (supply chain role), in the SBU ‘A’ situation this is/was done within the FICO module in SAP (a finance
role). If rebate handling would be a ‘small’ task based role in SBU ‘C’ SAP+, than in SBU ‘C’ that role could be
assigned to a supply chain role, in SBU ‘A’ SAP+ it could be assigned to a finance role, and when processes are
globally standardized it would be easy to re-assign this task.
Furthermore, because of a hybrid approach applied by IT Security in the actual deployment of the SBU ‘A’ SAP
Authorization Concept, meeting the characteristics of a good authorization concept is being seriously
jeopardized. This hybrid approach implies that SBU ‘A’ SAP+ composite roles will be composed of newly built
SBU ‘A’ SAP+ master/single roles (so-called ZM-XX roles)130, SBU ‘A’ legacy SAP master roles (so-called ZM-EU
roles) and even a combination of the two. Especially in the last scenario, I foresee significant amount of
duplication and perhaps even worse, users being assigned too wide access and there being a risk that the range
of authorizations exceeding the operational responsibility of the end user.
I also conclude that this hybrid approach does negatively affect the transparency and uniformity: not only since
a combination of newly built SBU ‘A’ SAP+ roles as well as SBU ‘A’ legacy roles is being used, but also because at
composite role level all SBU ‘A’ SAP+ roles – regardless of whether they were derived/composed from newly
built SBU ‘A’ SAP+ master/single roles (‘ZM-XX’ roles), from SBU ‘A’ legacy SAP master roles (‘ZM-EU’ roles) or
from a combination of the two – do have the same naming (i.e. ‘ZC-EU’).
Also the adaptability of the authorization concept is undermined by this hybrid approach. Authorization
concept needs to flexible so that the authorization roles can be relatively easily adapted to organizational
changes and/or new SAP modules or applications that have to be integrated. These kind of events may require
changes in an SBU ‘A’ SAP+ composite role. However because of the hybrid approach, it might be a difficult task
to recognize where a change in a specific master role (i.e., newly built SBU ‘A’ SAP+ master/ZM-XX role versus
SBU ‘A’ Legacy SAP master/ZM-EU role) is required and then identify who needs to approve (SBU ‘A’ BPO
versus global BPO).
Based on the above I conclude that although from a design point of view the case study object SAP+
authorization concept may be adequate, deployment of the concept is not in line with the design and therefore
does has some serious flaws with regard to authorization concept quality criteria like reliability, security,
testability, flexibility, and comprehensibility.
Conclusion: control assessed to be valid, additional guidance in control description/explanation is required.
Authorization concept quality criteria (i.e. reliability, security, testability, flexibility, and comprehensibility) that
are being referred to in the explanation to control 2.1 can be seen as a useful reference for designing a (new)
authorization concept. However, this control in itself is not sufficient: it also needs to be secured and
monitored that meeting these criteria is ensured in the actual deployment (i.e., build and roll out) of the
authorization concept. Assessing compliance with these quality criteria would be enabled by ensuring
measurable quality criteria for an authorization concept are defined.

Control 2.2: Involve business process owners in the design and ownership of roles to ensure the roles truly
reflect business functions and will be sustainable in the longer term
Case study object situation: Prior to the SBU ‘A’ SAP+ go-live, neither by the case study object’s SAP+ program
Security Team nor by the IT Security department, significant involvement has been sought from SBU ‘A’ BPOs in
the design of the SBU ‘A’ SAP+ authorization roles. In the context of designing authorization roles, SBU ‘A’ BPO
involvement has been limited to those few business processes where relevant SBU ‘A’ BPOs have pro-actively
taken the initiative to ensure roles indeed reflect their business functions and is sustainable. For SBU ‘B’, the
situation is different and the SAP+ program Security Team and IT Security have contacted the SBU ‘B’ BPOs
timely in the design of the authorization roles.
Conclusion: control assessed to be valid, no need to revise control

Control 2.3: Define the set of SAP transactions to be included in the updated SAP roles by reviewing the SAP
transaction history
Case study object situation: In the context of building new SBU ‘C’ SAP+ Master roles that could be rolled out
globally, IT Security has started a cleansing exercise with regard to the SBU ‘C’ SAP roles. The intention is that
SBU ‘C’ SAP transaction logs are being analyzed to determine any transaction codes that have not been used by
any users for a long time and by doing so also determine the set of transactions that should be included in the

130
Newly built SBU ‘A’ SAP+ master/single and derived roles have been derived from newly built SBU ‘C’ SAP+ master/single
roles.

101
newly designed SAP roles. However this cleansing exercise on the SBU ‘C’ SAP roles has started only after the
SBU ‘A’ SAP+ project was completed. Hence for SBU ‘A’ this cleansing exercise has come too late.
Conclusion: control assessed to be valid, no need to revise control

Control 2.4: Conduct workshops with BPOs to validate that the respective SAP transaction groups are aligned
with the “to-be” business processes in case of new SAP implementations or existing business processes in case
of security redesign projects
Case study object situation: No workshops with SBU ‘A’ BPOs have been held (see also comment to control 2.2)
Conclusion: control assessed to be valid, no need to revise control

Control 2.5: Define “role owners” for each role template

Case study object situation: For each SBU role owners have been identified. Role owners are presented by the
SBU BPOs.
Conclusion: control assessed to be valid, no need to revise control

Control 2.6: Role naming conventions and role groupings need to be intuitive not only to IT security experts, but
also to business approvers and reviewers
Case study object situation: Case study object design for the role naming convention – for SAP business
applications using SAP GRC AC - is shown in overview below:

In the role name pre-specified abbreviations are being used to specify a customized role (role starting with a
‘Z’) as well as a role type (‘S’ for single roles, ‘D’ for derived roles and ‘C’ for composite roles).
It is also recognized that without self-explanatory naming convention, distinction of roles for different regions,
countries and sites cannot be made. Therefore an organizational value map and naming convention for regions,
countries and sites has been agreed upon. It has been made clear which short description needs to be used in
the naming convention of the Organizational Value Map. The naming convention provides for identification of
the continent level, country level (i.e. continent – country level) and city level (i.e. continent – country – city
level) to which the role provides access. For the continental use of roles the following values are in place: AP =
Asia / Pacific, EU = Europe, NA = North America, SA = South America, ME = Middle East / Africa and GLOBALXX
= Global. For countries the ISO 3166 standard list is being used. The next 3 characters can be used to identify
the city in the country. The last 3 characters will be free text used to pinpoint a specific location in a city. For
example a specific factory or storage location.
In the role name pre-specified abbreviations will be used to specify (sub) processes (actually reference is being
made to SAP ECC modules) and activity type and subjects the role is authorized for. For SAP modules, the
standard SAP abbreviations will be used. For Instance: MM for Material Management, SD for Sales &
Distribution and FI for Finance. Abbreviations for activities will be indicated by 1 character: ‘C’ for roles
containing create, ‘M’ for roles containing Change / Maintain / Delete, ‘D’ for Display / View and ‘A’ for
Approve / Release authorization.
In conclusion, the company has a clear naming convention which is documented, applied and supervised by the
IT Security Team.
Conclusion: control assessed to be valid, additional guidance in control description/explanation is required.
Recommended that - explanation/guidance to - the control (description) also notes that an appropriate design
for the naming convention should facilitate identification of:
- User-defined role versus SAP-delivered roles
- Role type
- Organizational unit (continent, country, city, site/location)
- SAP application (e.g. ECC, SRM, CRM, BW) and/or SAP ECC module (e.g., MM, FI, SD)

102
 - Activity type
Furthermore it is recommended that additional guidance notes the importance of having a role naming
convention that is future proof and can handle multiple SAP applications (i.e. not only SAP ECC, but also other
SAP applications like SRM, CRM, Product Lifecycle Management (PLM), etc.) as well as multiple organizational
areas across the world.

Control 2.7: Deploy an access management solution (such as SAP GRC AC) to help design and keep roles free of
SoD conflicts over time
Case study object situation: SAP GRC AC is being deployed
Conclusion: control assessed to be valid, no need to revise control

Control 2.8: Make adequate and clear choices with regard to key SAP security considerations to ensure
appropriate role architecture is in place.
Case study object situation: See comments to control 2.1 above and 2.10 to 2.14 bellow.
Conclusion: control assessed to be valid, no need to revise control

Control 2.9: First key decision to make during the actual design of SAP Security is whether to use "Job-based"
versus "Task-based" roles
Case study object situation: See comments to control 2.1 above
Conclusion: control assessed to be valid, no need to revise control

Control 2.10: Decide on whether to use Composite roles or Single roles

Case study object situation: A single role is used as a template role. In SAP GRC AC, master role is referred or
used as single role. The purpose is to create one single role and to derive roles from that single role. The
derived roles will inherit all the transactions, reports and authorization objects, but not the organizational field
values. Benefit of the use of the single – derived role is the easy maintenance. Only the single role has to be
changed. All the derived roles are changed in exactly the same manner as the single role. The only change that
has to be applied on the derived role is the changing of values for the organizational fields in the derived roles.
However, within case study object general authorization role design principle is that a single role is not
assigned to users. Only the derived roles out of the single role are assigned to users via a composite role. A
composite role is a container for one or more derived roles. The composite role does not contain authorization
objects itself. All the derived roles in one composite role should match the activities related to a specific
organizational function.
With regard to SBU ‘A’ SAP+ authorization roles, instead of consistently using newly build SBU ‘C’ SAP+ master
or single roles as the basis for defining derived and composite roles that are required for SBU ‘A’ SAP+ , it was
decided to also ‘lift & shift’ authorization roles from the legacy SAP system. Below overview shows the current
set up of the SBU ‘A’ SAP+ authorization roles. SBU ‘A’ SAP+ authorizations have been setup with a hybrid
approach: SBU ‘A’ users do have access similar to legacy system roles and also they have new SAP SBU ‘A’ roles
(like for MM, PS, PM, HR modules) which may cause SoD conflicts and is complex to handle in “run and
maintain” phase.

103
Figure 54. Current Hybrid Set Up of SBU ‘A’ SAP+ Authorization Roles

For SBU ‘B’ SAP+, the approach is to completely adhere to the design principle that SBU ‘B’ SAP+ derived roles
are created out of SBU ‘C’ SAP+ master or single roles and are assigned to users via a composite role. Since, SBU
‘B’ used to have a variety of legacy systems (not SAP), the option to lift & shift legacy roles is actually not
available.
Conclusion: control assessed to be valid, no need to revise control.

Control 2.11: Chose appropriate design variant for the Role Architecture (Job-based Single roles versus Job-
based Composite roles versus Task-based Single roles)
Case study object situation: Based on the two key SAP security considerations that were referred to in 2.8 and
2.9 above (Job Based versus Task Based roles and Single versus Composite roles), three different design
variants for the Role Architecture can be identified: (1) Job-based Single roles, (2) Job-based Composite roles
and (3) Task-based Single roles.
Design variant chosen for the case study object SAP+ authorization role architecture is the Job-based
Composite roles variant. However in the actual deployment for SBU ‘A’ SAP+ project (due to time- and capacity
restraints), decision was made to deploy a combination of different design variants. In addition to the Job-
based Composite Role variant also SBU ‘A’ SAP-legacy roles were lifted and shifted (see also comments to
control 2.1, and 2.10).
Conclusion: control assessed to be valid, additional guidance in control description/explanation is required.
Control 2.11 requires additional guidance. It needs to be secured and monitored that the design variant
chosen is actually deployed (i.e., build and roll out). In doing so, it can be prevented that soon after go-live a
major restructuring of the authorization roles is required.

Control 2.12: Decide on whether to use Derived versus Enabler roles

Case study object situation: Case study object has chosen to deploy the derived roles concept.
Conclusion: control assessed to be valid, additional guidance in control description/explanation is required.
Recommended that - explanation/guidance to - the control (description) also notes that both approaches have
strengths and weaknesses that must be weighed for an organization’s specific SAP environment and business
and security objectives. The enabler concept yields the greatest value in environments with very deep and
fluid/changing organizational security requirements. In these situations the enabler concept allows
organizations manage more efficiently the authorization roles when the pure economies of managing derived
roles across the security landscape become burdensome (enabler roles significantly reduce the number of roles
the organization has to maintain).

Control 2.13: Decide on whether to use Custom or Pre-delivered SAP Roles

104
Case study object situation: Case study object has chosen to tailor their security design and use customized
SAP roles. Out-of-the-box roles pre-delivered by the SAP system are not being implemented.
Conclusion: control assessed to be valid, no need to revise control

Control 2.14: Decide on whether to use HR or position-based design versus functional design
Case study object situation: Since job descriptions and positions as maintained by HR are not well-defined
and/or consistent across the company - and job roles have not been created yet - case study object has chosen
not to deploy the HR or position-based design (yet).
However, going forward – through SAP GRC AC and SAP IdM integration - the objective is to have automated,
position-based role management in which role entitlements for a new hire (i.e. a starter) or mover are
calculated based on the position recorded in the SAP ERP HR system. It is recognized within the case study
object that having such a solution in place would simplify and automate role assignment.
Conclusion: control assessed to be valid, additional guidance in control description/explanation is required.
Recommended that - explanation/guidance to - the control (description) also notes that having HR or position
based design also requires job roles to be defined (and maintained). Pre-requisite for defining job roles that
can be deployed globally is that business processes are globally harmonized across the company.

Control 2.15: Apply recognized enablers for a successful SAP authorization concept.
Case study object situation: Most recognized key enablers are applied. Exceptions are the clear authorization
concept (role architecture) strategy that is not complied with (for SBU ‘A’ SAP+). As a consequence of this,
uniformity and - in particular maintainability – of the concept is significantly reduced.
Reasoning for these recognized enablers not being applied is that the SBU ‘A’ BPOs have not been consulted
timely and sufficiently by the case study object SAP+ Program Security team and the IT Security department in
the design and build phase of the SAP+ authorization roles.
For SBU ‘B’ SAP+, the situation seems to be somewhat different: SBU ‘B’ BPOs have been consulted and
involved timely to ensure that authorization roles do not only meet BPO requirements but also to ensure that
the case study object SAP+ authorization concept is actually being deployed and complied with.
Conclusion: control assessed to be valid, additional guidance in control description/explanation is required.
Recommended that - explanation/guidance to - the control (description) also emphasizes the importance of
timely involvement of the BPOs and business process harmonization.

4.2.4 Step 3: Role Build and User Assignment

Control 3.1: First step in the technical role design phase is to build “master roles” or “template roles”.
Case study object situation: Control is completely applicable to the case study object situation.
Conclusion: control assessed to be valid, no need to revise control

Control 3.2: Second step in designing SAP roles is to create “derived” or “child” roles
Case study object situation: Control is completely applicable to the case study object situation.
Conclusion: control assessed to be valid, no need to revise control

Control 3.3: Designing roles that are free from SoD conflicts early in the SAP+ project
Case study object situation: Although SoD risk analyzes - using SAP GRC AC Access Risk Analysis (ARA)
submodule - have been performed during the design and build phase of the SBU ‘A’ SAP+ authorization roles, it
cannot be concluded that the SBU ‘A’ SAP+ environment was “clean” or “conflict-free” upon go-live and post
go-live, let alone that roles have been designed that were free from SoD conflicts early in the case study object
SAP+ project already.
Based on the SoD risk analyzes performed (both at master, derived and composite role level), remediation
actions have been proposed by ERM. Subsequently, IT Security would consult with the relevant role owner(s) to
discuss the SoD conflicts identified and reach agreement over the proposed remediation action(s). However,
such alignment was impeded due to various factors. In my opinion, one of the most important factors being
that within the scope of the SBU ‘A’ SAP+ project it apparently lacked a clear objective to ensure the SBU ‘A’
SAP environment was “clean” or “conflict-free” upon or post go-live. One would expect that the case study
object SAP+ Program Security team (lead) would be assigned responsibility to ensure such an objective is
achieved. Also the fact that the SAP GRC AC project (and ERM who is coordinating its deployment) was not part
of the scope of the SBU ‘A’ SAP+ project in my view has contributed to SBU ‘A’ SAP environment not being SoD
conflict free post go-live.

105
Another important factor being the concept of business process ownership – as well the formal responsibilities
that come with it – which is relatively new to case study object’s businesses in SBU ‘C’ / its home country.
Illustrative is perhaps that the SAP+ project governance is/was very much SAP module driven instead of End-to-
End process driven.
Conclusion: control assessed to be valid, additional guidance in control description/explanation is required.
Recommended that - explanation/guidance to - the control (description) also emphasizes that a prerequisite
for ensuring that roles that are designed are free from SoD conflicts early in the SAP project, is that the SAP
project should explicitly recognize this as an objective. Also accountability and responsibility for achieving
this objective should be assigned to a senior member of the SAP project (e.g. Security Team Lead).

Control 3.4: Leverage SAP GRC AC to confirm that roles are SoD-conflict – free before assigning them to end
users
Case study object situation: This control was not applied. Authorization roles have been assigned to SBU ‘A’
SAP users prior to having the assurance that these roles are SoD conflict free. In fact, authorization roles have
been assigned whilst there was a common understanding that roles were not clean (see also comments to
control 3.3).
Conclusion: control assessed to be valid, additional guidance in control description/explanation is required
(see conclusion with regard to control 3.3).

Control 3.5: Configured workflow for user access change requests should include required approvals from user's
manager, role owner, security team, and should also include review and approval of SoD
Case study object situation: Control is completely applicable to the case study object situation. Relevant SAP
GRC AC workflows have been configured based on the RACI-model which has been used to clarify roles and
responsibilities in the relevant access control processes (see below).

106
 Functional Teamlead (Not applicable for SBU
'A' and 'B', for SBU 'C' still to be determined)

Functional User (Not applicable for SBU 'A'

Local (Delegated) Business Process Owner

and 'B', for SBU 'C' still to be determined)

(Delegated) Business Process Owner
R = Responsible
A = Accountable
C = Consulted

Mitigating control executor

I = Informed

ERM-GRC Process Owner

Non-disclosure approver
Manager (Site-manager)

Power user (key user) /

IT Security Team Lead

IT Security - Security

IT Security - Quality

GRC System (IDM)

ERM-GRC Officer

IT Security - GRC
System
Activity
I. Access Risk Policy and Ruleset
Own & Maintain the SAP Access Risk Guidelines. None A/R C
Maintain Access Risk definitions (Functions). GRC AC - WF A C C C R
Approve Access Risk definitions (Functions). GRC AC - WF A/R
Maintain Access Risk definitions (Risks). GRC AC - WF A C R
Approve Access Risk definitions (Risks). GRC AC - WF A/R
Inform on additions of new functionality in SAP+ SAP+ C C A R I
Perform impact assessment on new functionality. SAP+ C C C A/R C
II. Access Risk Management
Create / maintain mitigating controls. GRC AC / PC A R
Approve created / updated mitigating controls. GRC AC / PC A/R
Execute mitigating controls. Manual A R
Monitor effectiveness of mitigating controls. GRC PC R A
Monitor (mitigated) SAP Access Risks on a periodic basis. GRC AC A R
III. User Management
Create access request for role assignment. IDM A/R
Preventatively check Access Risks. GRC AC - WF A/R
Approve (or reject) access request (Level 1 approval) for role assignment GRC AC - WF A/R A/R
Approve access request (Level 2 approval) for role assignment GRC AC - WF A/R
Approve access request (Level 3 approval) for role assignment - HIGH & CRITICAL SOD'S ONLY GRC AC - WF A R I I C
Assign mitigating controls to users - HIGH & CRITICAL SOD'S ONLY GRC AC C A/R
Provision authorization roles to user. IDM A R
IV. Role Management
Create change request for role changes. SOL MAN A/R
Create "role definition" in BRM - maintain role name & attributes. GRC AC - WF A/R
Sanity check authorization concept on role definition in BRM (Level 1 approval) GRC AC - WF I I A/R
Approve MASTER, DERIVED, COMPOSITE and JOB role changes / creation (Level 2 approval). GRC AC - WF I I A/R
Approve change request for those role changes that - pre-remediation and/or pre-mitigation -
GRC AC A R
will trigger a HIGH or CRITICAL SOD Conflict (Level 3 approval)
Apply changes to authorization roles. GRC AC - WF A/R
Perform risk analysis. GRC AC - WF A/R
Assign mitigating controls to roles (COMPOSITE AND JOB ROLES ONLY) GRC AC - WF A/R
Approve based on quality check (Level 4 approval). GRC AC A/R
SBU 'C': Approval MASTER, COMPOSITE AND JOB role changes / creation (Level 5 approval). GRC AC - WF A/R
SBU 'A' and 'B': Approval MASTER role changes / creation (Level 5 approval). GRC AC - WF A/R
SBU 'A' and 'B': Approval (COMPOSITE AND JOB) role changes / creation (Level 5 approval). GRC AC - WF A/R
Periodically review role changes and assigned mitigation controls GRC AC A R
V. Management of the SAP GRC Access Control Application
User Management: Approve access to the SAP AC system. TBD A/R A/R
User Management: User Maintenance. TBD I A/R
Change Management: Approving changes. TBD A/R I A/R C C
Change Management: Implementing changes. GRC AC I I A/R
Functional Support. GRC AC A/R

Conclusion: control assessed to be valid, additional guidance in control description/explanation is required.

Recommended that - explanation/guidance to - the control (description) also notes that the RACI-model could
be used as a starting point for clarifying roles and responsibilities with regard to the user access change
request process (and other access control processes). Once RACI matrices have been agreed upon, workflows
can be configured reflecting these matrices.

Control 3.6: Risk-based SoD process requires a company to discover all the potential methods for executing a
transaction in order to understand the full potential for fraud
Case study object situation: Control is completely applicable to the case study object situation.
Conclusion: control assessed to be valid, no need to revise control

Control 3.7: Regardless of the treatment of any exclusions in the SoD analysis, it is vital to document all
omissions, their rationale and to communicate this information to regulators and compliance stakeholders.
Case study object situation: Until now only business roles and business users have been included in the SoD

107
risk analysis using SAP GRC AC’s ARA module. System or process accounts, IT administrators, IT operations and
support personnel have been excluded from the SoD risk analyses.
Going forward, in addition to ARA being used for SoD risk analysis, ARA will be also be used to monitor sensitive
access related access risks (in line with the sensitive access risks as defined in the case study object ruleset).
Hence, unlike noted in the guidance notes to control 3.7, read-only or inquiry functionality in the application
cannot be excluded in the access risk analysis using ARA.
Conclusion: control assessed to be valid, additional guidance in control description/explanation is required.
Recommended that - explanation/guidance to - the control (description) also notes that in case a company’s
ruleset also includes sensitive access risks, read-only or inquiry functionality in the application cannot be
excluded in the access risk analysis. Authorization roles should be assessed both against SoD rule sets as well
as Sensitive Access rule sets.

4.2.5 Step 4: Role and User Access Risk Analysis

Control 4.1: SAP GRC AC (or similar application) should be leveraged to perform periodic role and user analysis
to determine if the newly designed SAP roles are in compliance with SoD policies
Case study object situation: The case study object recognizes that there needs to be continuous monitoring of
access risks (SoD risks and sensitive access risks) in the ‘steady state’ or ‘run & maintain’ phase. However, prior
to SBU ‘A’ SAP+ Post Go-live Support (PGLS) phase, access risk analysis was performed more on an ad-hoc basis.
ERM has decided that periodic/continuous role and user analysis (using SAP GRC AC ARA) will be deployed after
the SBU ‘A’ SAP+ PGLS has been completed. In my view, distinguishing between the project phase and the
steady state is a sensible approach.
During PGLS - which takes about 1-2 months - any optimization that is required, is responded to immediately by
the PGLS team so that end business users are not being limited in their daily work and the business process
doesn’t experience any hiccups. Since such optimization most likely will also impact the newly designed
authorization roles, ERM did not consider it sensible to run the access risk analysis (let alone go through the
defined SAP GRC AC approval workflows for any role changes).
Clearly, what has also contributed to this decision is the fact that SBU ‘A’ BPOs have indicated that they
preferred to have the wider roll out of SAP GRC AC (i.e., the roll out of ARM and BRM modules and related
approval workflows ) to be delayed until after PGLS.
For SBU ‘B’ SAP+ the objective is again to ensure that the SAP+ environment is “clean” or “conflict-free” upon
or post go-live.
Conclusion: control assessed to be valid, additional guidance in control description/explanation is required.
Recommended that - explanation/guidance to - the control (description) also notes that risk and compliance
functions should not be the only functions who require periodic role and user analysis to be performed. Also
executive management as well as the BPOs themselves should be mobilized to ensure both push and pull
factors are in place (see also control 0.1) requiring (a) the SAP environment to be “clean” or “conflict-free” post
go-live and (b) periodic access risk analyses to be performed and followed-up upon.

Control 4.2: Management should define and document a formal process to govern the changes to the SAP GRC
rule set.
Case study object situation: A formal process has been defined to govern the changes to the SAP GRC rule set.
Also a ruleset change log template has been created to record any changes to the ruleset.
Conclusion: control assessed to be valid, additional guidance in control description/explanation is required.
Recommended that - explanation/guidance to - the control (description) also notes that in addition to
documenting the formal process to govern the ruleset changes, also a ruleset change log template is
maintained listing items as Change Request, Reasoning, Change Type (technical versus functional), Change
Object (i.e. functions to be changed), Old Value, New Value, Change date, Changed by, Approved by.

Control 4.3: To ensure SAP environment is “clean” or “conflict-free” post go-live, a sound SAP security
provisioning process must be designed and implemented
Case study object situation: See comments to control 4.1
Conclusion: control assessed to be valid, additional guidance in control description/explanation is required.
See conclusion on control 4.1

Control 4.4: Risk Remediation: eliminate the identified risks by making changes to granted authorizations or by
making changes in the authorization concept

108
Case study object situation: For SBU ‘A’ SAP+ risk remediation activities into the SBU ‘A’ authorization roles
commenced timely and prior to UAT. Unfortunately, as a result of a variety of factors, ERM’s objective to
ensure SBU ‘A’ SAP+ authorization roles are ‘clean’ or SoD conflict-free has not been achieved. The remediation
process has taken/is taking much time to complete. Also it has been recognized that a redesign of the SAP
authorization roles is required (SBU ‘A’ SAP+) or will be required (SBU ‘B’ SAP+) to ensure a more sustainable
set of authorization roles is being deployed.
Although there is agreement over an improved authorization concept (i.e. master – derived – composite – job
roles concept) and authorization roles have been (SBU ‘A’ SAP+) or are being built (SBU ‘B’ SAP+) in line with
this concept, the basis for building these roles are still the old SBU ‘C’ SAP master roles. These old SBU ‘C’ SAP
master roles are too wide and contain transaction codes related to multiple SAP modules within one and the
same master role. Therefore the only difference between the old SBU ‘C’ SAP master roles and the newly built
SBU ‘C’ SAP+ master roles is the revised naming convention that has been applied. Only exception to this rule
are the newly built GPS (Global Procurement Services) SAP+ master roles, where the global BPO has been
involved in defining the roles for the global harmonized sourcing and contracting process within the case study
object. Since it has been decided that the basis for building the SBU ‘A’ SAP+ and SBU ‘B’ SAP+ is represented
by the newly build SBU ‘C’ SAP+ master roles, now already it can be concluded that reorganizing of the
authorization roles will be required (starting again with the SBU ‘C’ SAP+ master roles). Also because SBU ‘C’
SAP+ master roles are too wide, the process to remediate the multitude of SoD conflicts is very time
consuming.
Conclusion: control assessed to be valid, no need to revise control

Control 4.5: User appropriateness reviews provide an easy and effective way to reduce the number of SoD
conflicts (revealed in the testing process)
Case study object situation: Examination of the current user population for terminated employees from the
human resources (HR) list has been completed. In doing so, it is ensured that terminated employees will not be
assigned a role. However, no review has been performed into the user population to verify that authorization
roles - that are to be – assigned to active users are indeed in line with the nature of their job.
Conclusion: control assessed to be valid, no need to revise control

Control 4.6: Once remediation is completed, relevant people, process and technology governance activities
must remain in place to help ensure the situation does not arise again
Case study object situation: Accountability for the tasks of role maintenance, user administration and SoD rule
definitions has been clearly defined and assigned. Furthermore, periodic testing and conflict checks after PGLS
are being incorporated into the provisioning processes.
Conclusion: control assessed to be valid, no need to revise control

Control 4.7: Working closely with BPOs, role owners and the SAP security team to remediate unauthorized
conflicts
Case study object situation: ERM works closely with BPOs/role owners and the SAP+ security teams (IT
security and SAP+ Program Security Team) to remediate unauthorized conflicts. Regardless of this cooperation,
the effects of SoD analysis are (will be) leading to costly remediation and/or mitigation efforts since conflict
resolution may require altering role definitions or alternatively the deployment of mitigating controls (meaning
the risk is accepted but managed through manual controls at regular intervals to verify that permissions in
breach of corporate policies are not abused).
I conclude that the challenges experienced are not specific to the case study object situation, but are
representative of the Role Based Access Control (RBAC) authorization model (i.e. granting access to roles) that
is being deployed by vast majority of large, multinational organizations using ERP systems. To address the
issues referred to above, case study object is considering to look into hybrid solutions that – in addition to the
RBAC model - are also built around the Attribute Based Access Control (ABAC) authorization model (granting
access via attribute-based rules).
Conclusion: control assessed to be valid, additional guidance in control description/explanation is required.
Before recommending what kind of explanation/guidance to be added to the control (description), I first
elaborate more on the key differences between RBAC versus ABAC.
The RBAC model is not well suited to handle contextual conditions. It assumes predefined decisions can be
made based on preconfigured roles regardless of the specific context in which a user later chooses to use this
role. With Attribute Based Access Control (ABAC), by contrast, the objective is to express business rules rather
than to label a set of static user permissions with a role name. In ABAC, attributes describing the subject, the

109
action, the resource and the context of an access request are used to define hierarchies of rules. The following
attributes would be of interest in a rule definition:
 Describing the subject (e.g., the user approving a payment) a list of identifiers pointing to vendor records
manipulated by the user should be attached, an attribute that can be called a user.vendorlist.
 The action would be approve.
 The resource would be a payment – a record or transaction in the system – with a recipient attribute
identifying the vendor to whom money will be sent.
A business rule can state something like “if action=approve, resource=payment and resource.recipient not in
user.vendorlist, then permit else deny”. The above is clarified in below overview.

ABAC assists in the implementation and enforcement of access controls derived from actual business rules,
including rules mandating segregation of duties or sensitive access restrictions. Segregation of duties to
minimize risk exposure remains important regardless of what type of authorization technique is used (RBAC,
ABAC, or any other access model). Enforcing SoD is therefore equally important with ABAC as with RBAC.
However, below example illustrates some of the disadvantages of the RBAC model:

Figure 55. Segregation of Duties under the RBAC model

With RBAC the violation occurs when permissions contained in two different roles are in conflict. Users having
both Role 1 and 2 in the above figure are affected whereas those who have either Role 1 or Role 2 in
combination with other roles are not. Altering Role 1 and/or 2 therefore often leads to cascading role
redefinitions and/or role explosions. Unaffected users in group 1 and 3 may be impacted by measures taken to
handle a conflict within group 2. The role concept may thus expand the effects of SoD resolution into
“innocent” parts of the user population. The role concept also expands the problem across unaffected
permissions. Although only individual permissions within Role 1 and Role 2 are in conflict they “contaminate”

110
their respective roles. With SoD enforced on these roles, none of the permissions they bundle can be combined
even if most combinations do not represent a business risk. By expanding the SoD conflict in either or both
dimensions – affecting “innocent” users and/or “innocent” permissions – RBAC generates considerable
administrative costs.
With ABAC, the failure to capture a business requirement for SoD would instead be the result of imprecise or
erroneous rule definitions. Provided there are efficient means to detect and avoid rule errors as well as
efficient means to verify that all of a company’s actual business rules have been properly captured in the
policies of their authorization system, problem resolution could be relatively simple and isolated to any
inadequate or missing rules.
Reflecting the above, I do recommend that the following guidance is added to the control description: As an
alternative to the RBAC (Role Based Access Control) model – which can lead to costly remediation and/or
mitigation efforts since conflict resolution may require altering role definitions or alternatively the
deployment of mitigating controls – the ABAC (Attribute Based Access Control) model or a combination of
both the RBAC and the ABAC model could be considered. In RBAC, SoD conflicts expand across a larger set of
users and permission than those initially affected. Problem resolution may require changes beyond the
immediate scope of the identified problem. Hence, problem resolution may be time consuming, laborious
and expensive.
SoD requirements on authorization require the ability to provide conditional decisions based on contextual
data. The RBAC model as opposed to the ABAC model is not context-aware and thus not well suited to
handle SoD requirements. In ABAC an unmanaged business requirement for SoD is the effect of rule design
failures: altering failing rules fixes the problem.
Concerns with regard to the ABAC model are that it can become very complex to set up and maintain the
business ruleset. To clarify: a potentially large number of attributes must be understood and managed.
Attributes have no meaning until they’re associated with a user, object, or relation. Other concerns are that
it is not practical to audit which users have access to a given permission and what permissions have been
granted to a given user.

Control 4.8: Default access should be assigned sparingly and careful consideration given to any menu or
security level to which it has been assigned.
Case study object situation: default access (also known as star access) to sensitive menus, transactions or
security levels is not being provided to business end users.
Conclusion: control assessed to be valid, no need to revise control

Control 4.9: Non-standard user IDs and accounts should be investigated for inappropriate access and potentially
changed to meet company policy naming conventions
Case study object situation: This control was not part of the scope of the activities performed by ERM in the
context of ensuring SAP+ authorization roles do become clean and stay clean by deploying SAP GRC AC globally.
Activities performed do not comprise audit-like activities to detect security vulnerabilities around non-standard
user IDs and accounts. Main focus with regards to cleansing of roles has been on authorization roles that are to
be assigned to business end users. Nevertheless, based on my discussions with the IT Security team I do
understand that absolutely no use is being made of powerful accounts – containing the SAP*, SAP-NEW,
SAP_ALL or equivalent profile – that provide unrestricted SAP access.
Conclusion: control assessed to be valid, additional guidance in control description/explanation is required.
Recommended that - explanation/guidance to - the control (description) also notes that segregation of duties
also applies to IT functions themselves. There should be segregation between (1) systems development and
operations, (2) operations and data control, and (3) data base administration and system development.

Control 4.10: Users with direct access (system access) to the lowest level of security (i.e., menus, screens,
transaction codes) should be carefully analyzed
Case study object situation: See comments to control 4.9
Conclusion: control assessed to be valid, additional guidance in control description/explanation is required.
See conclusion on control 4.9

Control 4.11: Risk Mitigation: objective at this stage is to mitigate the remaining risks, whereby compensating
control measures should be established and documented in the application
Case study object situation: Objective was to ensure that SoD conflicts in SAP+ authorization roles are reduced
to their absolute minimum via the remediation process and that any remaining SoD conflicts would be

111
mitigated through risk mitigation. However in practice both processes are performed more or less
concurrently.
Although the remediation process is still on-going, ERM has organized workshops with the SBU ‘A’ BPOs and IT
Subject Matter Experts (IT SMEs) to discuss mitigations for all relevant SoD risks in the ruleset. With regard to
such mitigations, ERM has made a clear distinction between preventive versus detective mitigating controls:
 Preventive mitigating controls (SAP configurable controls): SAP provides the ability to require dual
authorization for changes made to sensitive fields. Sensitive fields include items such as bank account
changes in a vendor record. If a field in the vendor master record is defined as “sensitive”, the
corresponding vendor account is blocked for payment if the entry is changed. The block is removed when a
second person with authorization checks the change and confirms or rejects it. The advantage of this
control is that SAP will not allow the same person who made the change to the vendor record to approve
the change.
To mitigate the segregation of duties risk, ERM - via workshops with SBU ‘A’ BPOs and IT SMEs - is currently
identifying SoD risks for which dual authorization is in place. For these kind of SoD risks a detective
mitigating control - that is more time consuming, laborious and expensive - is not required. I would
recommend case study object that once assessment of the dual authorization or other preventive
configurable SAP controls in the ‘As-Is’ SBU ‘A’ SAP+ situation has been completed, feasibility of
implementing dual authorizations and other preventive configurable SAP controls is also considered for
any remaining SoD risks.
 Detective mitigating controls: Controls designed to ensure any exploitation of a segregation of duties
(SoD) risk is caught in a timely manner and can be addressed before significant loss (as a result of fraud or
errors) or financial misstatement occurs. Detective mitigating controls are additional procedures designed
to reduce the risk of errors or irregularities. For instance, if the record keeper also performs a
reconciliation process a detailed review of the reconciliation could be performed and documented by a
supervisor to provide additional control over the assignment of incompatible functions. Detective
mitigating controls need to be assigned and executed, tested, signed off and reviewed by the business.
Additionally, external audit firms are required under various auditing standards to consider and assess the
risks related to fraud at their clients. Within SBU ‘A’- legacy situation, detective mitigating controls in place
were
Conclusion: control assessed to be valid, additional guidance in control description/explanation is required.
Recommended that - explanation/guidance to - the control (description) also notes that it is important to
make a distinction between preventive mitigating control (i.e., SAP configurable controls like dual
authorizations) and detective mitigating controls. Detective mitigating controls are additional procedures
designed to reduce the risk of errors or irregularities and would include audit trails, reconciliations,
exception reporting, transaction logs, supervisory reviews and independent review.
Business Process Owners (BPOs) and IT Subject Matter Experts (IT SMEs) can be consulted to understand if
any of the SoD conflicts in the ruleset are mitigated by a preventive mitigating control. For all preventive
mitigating controls, BPOs and/or IT SMEs should provide documentation (design documents, screenshots)
evidencing the design and existence of the control. Once risk and compliance function has assessed the
preventive mitigation control documentation to be satisfactory, than there is no need to also have a - more
time consuming, laborious and expensive - detective mitigating control in place. Moreover, for the remaining
SoD conflicts - in liaison with BPOs and IT SMEs - it could be useful to consider feasibility of implementing
SAP configurable controls like dual authorizations. In doing so, a company could reduce the number of
detective mitigating controls that are required. Also from a Continuous Controls Monitoring (CCM)
perspective it is a sensible approach to see if more configuration controls (versus manual controls) can be
used.

Control 4.12: Mitigating controls should address a precise risk

Case study object situation: Control is completely applicable to the case study object situation. For each critical
and high risk in the SoD ruleset, ERM has drafted a detective mitigating control. Subsequently, in workshops
with the BPOs and IT SME, relevant SoD risks are being discussed to determine the presence of any detective
mitigating controls in SBU ‘A’ SAP+ or otherwise agree on a detective mitigating control. In this workshop, any
detective mitigating controls that used to be in place in the SBU ‘A’-legacy situation are also being addressed.
In liaison with the business, it is being ensured that there is sufficient granularity of the detective mitigating
controls (descriptions).
Conclusion: control assessed to be valid, no need to revise control

112
Control 4.13: Mitigating controls should list who (name and job title) performs each of the mitigating controls in
the company.
Case study object situation: Mitigating controls have been uploaded into SAP GRC AC for each SoD risk in the
ruleset. Mitigating controls on role level will only be allowed in composite roles and job roles, in master and
derived roles it is not allowed to have any critical or high SoD conflicts (hence no mitigating controls are
required in these latter roles). The (site) manager is made accountable for executing detective mitigating
controls related to SoD risks in authorization roles that have been assigned to users that (in)directly report to
this manager. The (site) manager can choose to delegate the responsibility for executing the detective
mitigation controls. The /SBU BPO is accountable for the effectiveness of the detective mitigating control.
At the moment there is no clarity yet over who is/will be performing each of the detective mitigating controls
(i.e. mitigation control executors have not been assigned yet for the different business processes). As the
mitigating controls process has not always been adequately embedded for all business processes/SBUs, I do
expect some challenges in assigning and listing who (name and job title) will perform each of the mitigating
controls. Organizational change management would probably be required to ensure that this control is actually
complied with.
Conclusion: control assessed to be valid, additional guidance in control description/explanation is required.
Recommended that - explanation/guidance to - the control (description) also notes that organizational change
management may be required to ensure that for each (detective) mitigating control assigned, the mitigating
control executor is identified/defined timely.

Control 4.14: Continuous monitoring procedures must be established and followed (as the project go-live date
approaches)
Case study object situation: In the RACI (see control 3.5) reference is being made to following continuous
monitoring procedures:
 Monitoring (mitigated) SAP Access Risks on a periodic basis: accountability and responsibility lies with
ERM.
 Monitoring effectiveness of mitigating controls: accountability lies with the (local) BPO and responsibility
lies with the (site) manager.
However, these activities have not been laid down yet in written procedures. Therefore, recommendation to
case study object is that such procedures are being established. Furthermore, in the context of ensuring SAP+
authorization roles are cleansed, SoD violation reports are being reviewed by BPOs and role owners to validate
any required security changes.
Conclusion: control assessed to be valid, no need to revise control

4.2.6 Step 5: Security Testing and Go-Live Preparation

Control 5.1: SAP Security Unit Testing (UT) and User Acceptance Testing (UAT) are critical steps to ensure users
experience minimal access issues prior to go-live.
Case study object situation: Neither SBU ‘A’ SAP+ Integration, System & Regression Testing (ISRT131) nor User
Acceptance Testing (UAT) has included formal SoD and sensitive access reviews to confirm the newly created or
updated SAP+ roles are as SoD conflict-free as possible, and that access to key functions is properly restricted.
Although SBU ‘A’ SAP+ UAT has included testing on authorizations, main focus of SBU ‘A’ SAP+ UAT has been to
ensure that end users are able to perform their designated job functions with the new SAP+ system. Due to
limited emphasis on security implications, SBU ‘A’ SAP+ post implementation problem identification and
remediation may become very costly.
My recommendation for the SBU ‘B’ SAP+ project, would be that ERM is involved in early stages of the
functional testing which allows the discovery of potential security issues before it is too late – or costly – to
modify roles.
Conclusion: control assessed to be valid, additional guidance in control description/explanation is required.
Recommended that - explanation/guidance to - the control (description) also notes that since ERP
implementation teams are usually being tasked with finishing the implementation project on time and

131
The purpose of SBU ‘A’-SAP+ ISRT is for the SBU ‘A’-SAP+ project team to test the solution with full functionality and
integration against the agreed blueprints prior to moving to the User Acceptance Test where business representatives will
verify that the solution fully meets their requirements. Three key objectives for SBU ‘A’-SAP+ ISRT are: (i) to test the
solution with converted master and transactional data before UAT, (ii) to identify and resolve solution defects before the
start of UAT, and (iii) to refine Test Scenarios/Test Scripts where the expected results are not clearly defined

113
within budget there is a tendency these implementation teams do not pay adequate attention to security
implications since it increases implementation time and budget. It is therefore all the more important that
ERP security teams and/or Risk and Compliance functions ensure that they are involved in early stages of the
functional testing which allows the discovery of potential security issues before it is too late – or costly – to
modify roles.

Control 5.2: Company shall not only perform intra-application (i.e., within one application) testing, but also
cross-application (i.e., between two or more applications) testing to reveal the underlying risk of a SoD conflict.
Case study object situation: Prior to SBU ‘A’ SAP+ go-live cross-application SoD and/or SoD testing in non-ECC
SAP applications testing has not been performed. It is recommended that such cross-application SoD testing is
being performed prior to SBU ‘B’ SAP+ go-live. To facilitate cross application SoD risk analysis (and testing),
ERM is expanding the ruleset to other non-ECC applications.
Conclusion: control assessed to be valid, no need to revise control

Control 5.3: The tone at the top drives the level of commitment from all personnel.
Case study object situation: The Company’s CFO is a member of the SAP+ Steering Committee. This committee
provides the tone at the top with regard to the business goals of the project. During the SBU ‘A’ SAP+ project,
the case study’s object executive leadership team has seriously changed. As a general remark, changes in
executive leadership may cause issues with the consistent presence of the tone at the top.
Increasingly, the tone at the top is seen as a key enabler for the success of the SAP GRC AC project and effort is
being directed in establishing there is adequate executive management support – manifesting itself through
the tone at the top - to ensure both SAP+ PMO, Finance, Business and IT personnel are committed to the SAP
GRC AC project.
Conclusion: control assessed to be valid, no need to revise control

Control 5.4: IT, Finance and other management stakeholders must take co-ownership of the SoD process.
Case study object situation: Although the relevancy of this control is completely recognized, in practice there
have been some obstacles that - across the board - caused this co-ownership to be insufficiently realized. In
particular, SBU ‘A’ business management co-ownership has been hard to achieve, as business management –
barring exceptions - were mainly concerned with ensuring that end users are able to perform their designated
job functions with the new SAP+ system. See also comments on control 5.1.
Conclusion: control assessed to be valid, no need to revise control

Control 5.5: Testing timeline should be developed with the input of key business and IT stakeholders and the
audit team(s).
Case study object situation: Relevancy of this control is completely recognized, however there have been
obstacles preventing testing activities for SAP GRC AC to be embedded in the overall testing timeline for the
SBU ‘A’ SAP+ project. See also comments on control 5.1.
Clearly, ERM will develop the testing timeline for the SAP GRC AC project with the input of key business (e.g.,
BPOs) and IT stakeholders (e.g., IT Security)
Conclusion: control assessed to be valid, no need to revise control

4.2.7 Step 6: Move to Production and Support

Control 6.1: Once testing is completed, the newly designed SAP roles can be migrated to the production
environment according to the organization’s change management policy and users can be assigned
Case study object situation: Control is completely applicable to the case study object situation.
Conclusion: control assessed to be valid, no need to revise control

Control 6.2: Establish a support team specifically assigned to address any SAP access issues during go-live and
stabilization activities.
Case study object situation: Control is completely applicable to the case study object situation. For SBU ‘A’
SAP+, a Post Go-Live Support (PGLS) team has been deployed to ensure that users will be able to use the
system effectively. This also includes help resolve access issues on a timely basis. Different from the control,
this PGLS team has not run access risk reports – using SAP GRC AC - to determine if security changes will result
in SoD or other access risks. Recommended that for SBU ‘B’ SAP+ also the latter part is being considered by
the PGLS team.

114
Conclusion: control assessed to be valid, no need to revise control

Control 6.3: During SAP implementation and upgrade projects allow for temporary broader access for “power
users” during the go-live and stabilization period.
Case study object situation: Strictly speaking, broader access during the SBU ‘A’ SAP+ go-live and stabilization
period (“Post Go-Live Support phase” or “PGLS phase”) has been assigned to both “power users” and “business
end users”. Since authorization roles were not sufficiently cleansed prior to go-live, both kind of users had
broader access during go-live and stabilization period. Furthermore, since the PGLS team was established to
assess, prioritize and resolve any issues experienced by the business end users, there was no need to have
temporary broader access for “power users” to be assigned.
Conclusion: control assessed to be valid, additional guidance in control description/explanation is required.
Recommended that - explanation/guidance to - the control (description) also notes that if a Post Go-Live
Support (PGLS) team has been established to assess, prioritize and resolve any issues experienced by the
business end users, there is no urgent need for temporary broader access for “power users” during the go-
live and stabilization period.

4.2.8 Step 7: SAP GRC AC Post Go-Live and Ongoing Management & Monitoring of the Security
Environment

Control 7.1: It is primarily a business responsibility to ensure that management of user access activities does not
result in inappropriate conflicts or access to sensitive information.
Case study object situation: See comments to control 5.1 and 5.4
Conclusion: control assessed to be valid, no need to revise control

Control 7.2: Deploy a standard access management solution, such as SAP GRC AC, which can be complemented
with an identity management tool, like SAP NetWeaver Identity Management.
Case study object situation: Control is completely applicable to the case study object situation. Additional
comments with regard to SAP GRC AC – SAP IdM integration are addressed in my comments to control 8.1 and
control 8.2
Conclusion: control assessed to be valid, no need to revise control

Control 7.3: Develop a strategic vision for access management that aligns with business requirements and risk
tolerance.
Case study object situation: Case study object/ERM has developed a risk and remediation guideline. This
guideline describes the rules and processes to identify, assess, mitigate and monitor access rights related risks
caused by SoD conflicts, critical actions or sensitive access in the SAP+ system of case study object. This
document cannot be regarded as a strategic vision (document) for access management.
With regard to developing a strategic vision for access management, it should be mentioned here that ERM has
developed a strategic vision for Internal Controls. This vision not only includes access controls but also process
controls. Important enablers for achieving this strategic vision are the deployment of SAP GRC AC and SAP GRC
Process Control (SAP GRC PC). ERM plans to deploy SAP GRC AC and SAP GRC PC across all case study object
SBUs (including affiliate companies in case study object’s home country). Quick – access controls related - wins
from setting up SAP GRC PC do include: (1) using PC to execute mitigating controls and confirming whether
they are effective and (2) running periodic SoD reports in SAP GRC PC and sending exceptions automatically to
BPOs/role owners. In addition to ERM’s vision on internal controls, the IT security team also has its own vision
on authorizations and identity management.
Although I fully agree with the importance of having vision on internal controls (comprising both access
controls and process controls), I am also of the opinion that case study object currently lacks a jointly
developed, comprehensive and integrated strategic vision on Identity & Access Management (IAM).
Conclusion: control assessed to be valid, additional guidance in control description/explanation is required.
Recommended that - explanation/guidance to - the control (description) also notes that since access control is
only one subset of identity management, it is recommended that a comprehensive strategic vision or
strategic roadmap with regard to Identity & Access Management (IAM) is jointly developed by respectively
risk and compliance function, IT security and the business. IAM is the security discipline that enables the
right individuals to access the right resources at the right times for the right reasons. Access control is only
one subset of identity management.

115
Implementing an IAM solution / strategy can be complex. The impact on the business often depends upon the
current state of the organization i.e. its maturity and its appetite for change. Different organizations will have
varying levels of maturity with regards to IAM and its implementation. Depending on this maturity, the
capability and strategic requirements of an enterprise will also vary. These will quite often be in constant
evolution as the business keeps up with demands placed upon it. To illustrate this, in below overview IAM
adoption has been categorized into 5 broad categories. How mature the enterprise is may be a combination of
these.
IAM Maturity Key characteristics
Level
1. basic or low  No directory services
maturity  no server-based identities
 most users have unrestricted admin access to systems and services
 inconsistent password management
 manual management of user credentials
 little or no adoption of standards / compliance
2. standard  Minimal Directory services used for authentication only
maturity  Uncontrolled use of administration modes for the majority of users
 no or limited provisioning of resource assignment to users
 minimal adoption of industry standards / compliance / policies / security protocol best practices
3. consolidated or  Directory services are available and have central administration
medium  server-based identity and / or access management in place and utilized
maturity  full usage and adoption of policies / security templates
 strong compliance to industry standards / compliance / policies /security protocol best practices
 role-based access to resources
4. dynamic or  Centrally-managed user provisioning and de-provisioning across one or more heterogeneous
high maturity systems
 use of federated IAM across the organization, including external partners and suppliers
 full automation across business and technical processes
 strong compliance to industry standards / compliance / policies / security protocol best practices
 all IAM activities can be (and are) measured and trackable
5. identity as a  Enabled ‘Identity and Access Management as a service’ to itself, and external organizations
service or  providing full federation as a service across a trusted network, and across many organizations,
advanced but managed centrally
maturity  ability to act as an Identity Provider both to internal and external services

Example below provides a high level view of a potential strategic vision of an organization on IAM. The
overview is not exhaustive but shows the different capabilities that may be addressed in a strategic vision:
 The right people have access to the right information at the right time, with the right level of access / trust
 Individuals have one identity across the enterprise. Store it once, and manage it centrally.
 A security pass that works across the organization, and could work across many organizations
 Open standards and protocols enables system to system interoperability.
 Improved and (potentially) automated processes. For example joiner / leaver processes, user provisioning /
de-provisioning.
 Enabling an adaptable organization with reduction in calls to Help Desk
 Reduction in administration-based cost, such as password resets, self-service, etc.
 Enterprise utilizes single sign-on, federation, shared / common services, etc. as standard
 You know and can measure your organization’s security footprint. Audits are more efficient and
compliance is easier to achieve and track
 Organization makes use of an enterprise-wide ‘Identity as a Service’

Control 7.4: Identify/define policies that make access management standards clear, as well as procedures to
enforce those standards.
Case study object situation: Control is completely applicable to the case study object situation.
Conclusion: control assessed to be valid, no need to revise control

Control 7.5: Establish Key performance indicators (KPIs) and metrics that enables management of the access
management governance process (by the governance committee or equivalent thereof).

116
Case study object situation: Case study object/ERM completely agrees with the importance of this control. KPIs
do not only enable management of the access management governance process: positive trends in KPIs (e.g., a
decrease in the number of users having high/critical SoD violations) can also be used to communicate quick
wins that have been realized as a result of deploying SAP GRC AC and related processes.
Since KPIs have not been established yet, I do recommend that relevant KPIs are determined and
implemented. Recommended that KPIs are defined for each of the following three categories: managing
users, managing roles, managing emergency access. Examples of KPIs per categories are shown in the
explanatory note to this control
Conclusion: control assessed to be valid, no need to revise control

Control 7.6: Work with Business Process Owners (BPOs) and secure their buy-in throughout the development of
the access management governance processes.
Case study object situation: Case study object/ERM completely agrees with the importance of this control. In
all SBUs where SAP GRC AC will be deployed, workshop sessions have taken place or are taking place. In these
sessions BPOs are informed about the objectives of the SAP GRC AC project and are requested to reflect on
access management processes that have been drafted by ERM in liaison with IT Security.
Conclusion: control assessed to be valid, no need to revise control

Control 7.7: Perform periodic self-reviews of the access management governance process.
Case study object situation: Since SAP GRC AC Access Request Management (ARM), Business Role
Management (BRM) and SAP GRC AC Emergence Access Management (EAM) have not been deployed yet, self-
reviews by ERM have not been performed yet. Going forward, performing self-reviews could be a useful
instrument to determine if access management governance processes are still effective and efficient.
Conclusion: control assessed to be valid, no need to revise control

Control 7.8: Deploy organizational structure that is optimal for the long-term success of access management
controls.
Case study object situation: Different from – the guidance to – control 7.8, , the company has not yet
established a governance committee – that is dedicated to overseeing the case study object access
management processes - consisting of stakeholders from the various organizations, such as ERM, IT security,
Finance, Internal audit, and the BPOs. The need for such a governance committee is not being recognized yet.
Reasoning for this is that SAP GRC AC is still in project phase. However, the company has established a Risk
Committee (members of this Committee are in the company’s Executive Committee) to which ERM reports.
This Risk Committee could be used to report/escalate any high level issues around access management.
Conclusion: validity of control cannot be assessed yet, no need to revise control (yet)

Control 7.9: Key areas to consider for a governance team should be around Ownership, Risk Level, New
functionality and Ongoing Processes.
Case study object situation: Although the need for having an access controls management governance team is
not being recognized (yet), vast majority of the areas covered in – the guidance to – control 7.9 have actually
been covered in the case study object Access Controls RACI and related policies and procedures.
Conclusion: control assessed to be valid, however rephrasing of control is recommended. Recommended that
the wording of the control is changed into: Key areas to consider for a governance team the governance of
access controls management should be around Ownership, Risk Level, New functionality and Ongoing
Processes.

Control 7.10: A security governance policy should be in place that contains standards for the SAP ECC
production environments.
Case study object situation: The Company’s IT Security department has issued an Access Management Policy.
The purpose of this policy is to establish the framework and regulations for controlling logical access of users
(employees and third-parties) to the information systems of case study object. According to this policy
information and access to it using the information systems must be controlled according to the business needs
and the security requirements set by case study object. This policy document includes the following items:
 General Principles
 User Identification and Authentication
 Server’s Authentication Requirements
 User Account / Name Management

117
 Password Management
 Privilege Account Management
 Other Access Control Measures
 Review of Access Rights
 Remote Access
 Database Accounts and Password Requirements
I conclude that within case study object there is no specific security governance policy for the SAP ECC
production environments. My recommendation would be that case study object assesses necessity of
developing a separate security governance policy that contains standards not only for the SAP ECC
production environments, but actually for all relevant SAP production environments. This would implicate
that besides the ECC production environments, the policy would also be applicable to SAP SRM, SAP APO, SAP
BI/BW, SAP PLM applications that have been rolled out as part of the SAP+ project.
Conclusion: control assessed to be valid, however rephrasing of control is recommended. Recommended that
the wording of the control is changed into: A security governance policy should be in place that contains
standards for the SAP ECC as well as other relevant SAP application production environments.

Control 7.11: Independent reviews of user access rights should be performed periodically.
Case study object situation: In the Access Management Policy document issued by IT Security, a separate
section is devoted to Access Rights Review. According to the policy, the user accounts and the privileges on
critical or sensitive information systems must be reviewed on a regular basis (e.g. at least annually).
Conclusion: control assessed to be valid, no need to revise control

Control 7.12: Integrate Access Control-application with Continuous Control Monitoring (CCM) application.
Case study object situation: Control is completely applicable to the case study object situation. After SAP GRC
AC has been rolled out, next step will be to set up CCM (most likely by integration of SAP GRC AC with SAP
Process Control application).
Conclusion: control assessed to be valid, no need to revise control

Control 7.13: Decide on using Fire Fighter ID concept versus Role-Based Fire Fighter concept for Emergency
Access or Fire Fighter functionality.
Case study object situation: Control is completely applicable to the case study object situation. Case study
object is currently completing the design for the SAP+ emergency access process – for both business and IT
users - which will be enabled by the SAP GRC AC Emergency Access Management (EAM) submodule. Based on
the following decisive arguments, case study object in the design of the Emergency Access process has opted
for the Fire Fighter ID concept:
 Clear visibility of usage of Fire-Fighter user;
 Logging only of Fire-Fighter-ID’s and not for all activities that the user is performing during the assignment
period;
 ‘Soft’ barrier as the registration onto the dashboard reminds the user that his activities are logged.
Conclusion: control assessed to be valid, no need to revise control

Control 7.14: Define/Identify activities for which Emergency Access Management (EAM) or Fire Fighter (FF)
functionality is to be used.
Case study object situation: Control is completely applicable to the case study object situation. In case study
object EAM design document, it is described for which activities EAM or FF functionality is to be used. In
addition to this, in the same document also reference is being made to activities that should not be performed
using the EAM or FF functionality.
Furthermore in the design document also the design with regard to requesting access to EAM or FF
functionality is being described. In this context, decisions with regard to the following design principles have
been made:
a) Who approves EAM or FF request: IT versus Business (case study object: Business Process Owner)
b) When to request EAM or FF access (case study object: pre-approved and hybrid)
 Pre-approved (access assigned for unlimited period of time)
 During incidents (access requested and assigned for specific period)
 Hybrid (core team with continuous access, access to other users only assigned in case of incidents)
c) What is the default validity period for Fire-Fighter access (case study object: 1 day)

118
d) What kind of tooling will support the request process: e.g., dedicated IT service management solution
versus SAP GRC AC (case study object: SAP GRC AC – SAP IdM)
Conclusion: control assessed to be valid, additional guidance in control description/explanation is required.
Recommended that - explanation/guidance to - the control (description) notes that typical activities for which
this functionality is not to be used are also defined. Furthermore, I recommend that guidance to this control
also states that with regard to requesting access to EAM or FF functionality, items a, b and c shown above
are also defined.

Control 7.15: Emergency Access Management Review is to be deployed and should consist of the following
elements: (i) Review of Fire Fighter Users, (ii) Review of Fire Fighter Access, (iii) Review of Fire Fighter
Assignments and (iv) Review of Fire Fighter Logs.
Case study object situation: In the design document with regard EAM review, only the review of the Fire
Fighter logs is being addressed. In addition to the – explanatory note to – control, case study object has also
identified which function will become responsible for reviewing the Fire Fighter Logs (so-called Fire Fighter
controllers).
Review of Fire Fighter users, review of Fire Fighter access and review of Fire Fighter assignments is not being
addressed. Therefore I recommend that these items are considered in the design document.
Conclusion: control assessed to be valid, additional guidance in control description/explanation is required.
Recommended that - explanation/guidance to - the control (description) notes that it should be clear which
function(s) will become responsible for reviewing respectively (i) Fire Fighter Users, (ii) Fire Fighter Access,
(iii) Fire Fighter Assignments and (iii) Fire Fighter Logs.

Control 7.16: Deploy Exception-Based SoD Monitoring and focus on actual access violations.
Case study object situation: Although not yet implemented, the importance of this control is recognized by
ERM. Once SAP GRC AC has been rolled-out, the implementation of SAP Greenlight Access Violation
Management (AVM) should be considered. Moreover, following functionality - as provided by SAP AVM – is
seen as a key enabler for ensuring there is adequate business involvement to investigate access violations (and
preserving business value):
 Automating the identification and review of actual SoD violations
 Alerting business owners only when exceptions occur, reducing manual control efforts and eliminating
false positives
 Being able to assess the financial exposure of SoD violations
I would recommend ERM drafting a roadmap explaining her strategic vision on internal controls (comprising
both access and process controls) and how to improve the effectiveness and efficiency of these controls in
the coming 3 years. This roadmap also needs to contain any required resources and pre-conditions that
would need to be in place in order to achieve this vision. Clearly, resources should also include reference to
any (IT) tools that are required, among others SAP AVM.
Conclusion: control assessed to be valid, no need to revise control

Control 7.17: Reduce governance costs of enterprise-wide access by extending the capabilities of the Access
Control application across all relevant enterprise systems (SAP and non-SAP).
Case study object situation: See comment to control 1.1
Conclusion: control assessed to be valid, no need to revise control

4.2.9 Step 8: Compliant Identity Management

Control 8.1: Facilitated through SAP GRC AC and SAP IdM integration, provide automated, position based role
management while also ensuring business rules (SoD) compliance.
Case study object situation: Although both ERM and IT Security do recognize the advantages of providing
automated, position based role management while also ensuring business rules (SoD) compliance, in practice it
means a significant challenge to ensure this is actually implemented. Hence provisioning (for starters), de-
provisoning (for leavers) and re-provisioning (for movers) is still done manually within case study object. The
challenge is not in defining the appropriate SAP GRC AC-SAP IdM integration scenario (Scenario 1: IdM-Driven
User Provisioning with Access Control Integration versus Scenario 2: Access Control-Driven User Provisioning
with IdM Integration). Far more, the challenge is in ensuring proper business or job roles are defined: without
such business roles, automated, position based role management (i.e. role provisioning) cannot be
implemented. Another challenge is to ensure that required changes in HR master data (in SAP HCM) caused by

119
starters, leavers and movers are processed adequately and timely. This also only includes management of
information about people who are not employees, such as contractors and consultants, and who also require
access to company resources.
For structural and position based authorizations an organizational structure set up in SAP is required. Nodes in
the org structure represent positions or jobs. For position based security, roles are assigned to the org units
and positions on the org structure. When a user is assigned to a position/job then they inherit the access that
is assigned to that position and org unit that they sit under (if set up that way). This requires that job roles have
been clearly defined.
In order to achieve this, case study object is currently performing a role definition project. In practice this
means that a business or job role hierarchy is defined and subsequently technical - derived and composite -
roles are assigned to these newly defined business roles. Overview below shows the differences between
technical and business roles.

Figure 56. Relationship between Business Roles and Technical Roles

Without business roles being in place, assigning or removing roles to/from people cannot be done
automatically (i.e. cannot be HR driven). Alternatively provisioning would have to be performed manually (via
an administrator) and/or through request/approval workflow.
Main obstacles why automated position-based role management/(de-)provisioning cannot be implemented
yet at case study object are formed by the lack of business roles/job roles as well the fact that there is no
assurance over required changes in HR master data (in SAP HCM) caused by starters, leavers and movers
being processed adequately and timely by the HR department in SAP HCM.
Conclusion: control assessed to be valid, additional guidance in control description/explanation is required.
Recommended that - explanation/guidance to - the control (description) also notes that prior to implementing
(business rule) compliant, automated, position based role management through deploying integrated SAP
GRC AC-SAP IdM solution, the following preconditions need to be in place:
 Definition of job or business roles through defining a business role hierarchy and assigning technical –
derived and composite – roles to business roles. Permissions are best assigned to job roles rather than to
individuals. Making those roles correspond to real-life job tasks and job titles is a powerful way to
manage identities and access over the long term.
 Large dependency on the HR systems requires that there are adequate processes and procedures that
ensure required changes in HR master data (in SAP HCM) caused by starters, leavers and movers being
processed adequately and timely by the HR department in SAP HCM. An organization’s workforce is
managed by the personnel or human resources department. They also have to manage information

120
 about people who are not employees, such as contractors and consultants. Most of these people require
access to company resources. It is recommended to use the HR systems as much as possible as an
authoritative source of data for a company’s identity and access management system. This will help
avoid repetitive work, errors, inconsistencies and other problems as the IAM system grows.

Control 8.2: When exploring potential SAP GRC AC – SAP IdM integration scenarios, do consider items like:
Request submission source, Provisioning roles, Approval workflow, SoD Risk analysis, Request status and audit
trails, existing functionality and change control.
Case study object situation: Whilst exploring potential SAP GRC AC – SAP IdM integration scenarios, the vast
majority of the items referred to in the control descriptions (shown above) are actually being considered.
Conclusion: control assessed to be valid, no need to revise control

4.3 Conclusions
This section covers some conclusions that can be drawn from assessing the applicability of the so-called ‘Good
Practice (SAP) Access Security Design Framework’ at the case study object. Apart from a conclusion with regard
to the overall applicability of the framework, also a revised or updated good practice framework is shown. Any
adjustments to the framework are the result of the assessment or “applicability check” which was covered in
section 4.2.
Furthermore, section 4.3.2 covers some key factors and/or obstacles that cause some elements of the good
practice framework not to be deployed by the case study object. Finally, section 4.3.3 highlights some key
recommendations and/or lessons learned with regard to the case study object itself which have been
concluded as an outcome of the assessment in section 4.2.

4.3.1 Conclusions with regard to Framework Applicability (including Recommended Changes to the
Framework)
In general, applicability of the Good Practice SAP (Access) Security Design Framework to the case study object
is very good. Vast majority of the controls/good practices have been or are being deployed by case study object
in the context of the SAP GRC AC-SAP IdM project. Nevertheless, it also appeared that a few ‘good practices’ or
‘requirements’ from the framework were not or could not (be) applied by the case study object. My
evaluations with regard to the reasons why some requirements are not being applied (completely) are covered
in section 4.3.2
Outcome of the “applicability check” is that none of the 75 controls or good practices can be considered
irrelevant. Hence no single control or good practice has been removed from the framework. Based on the
applicability check, there is no need to add any new controls. Applicability check has triggered changes in 30
out of the total 75 controls: vast majority of these changes to controls involve additional guidance notes as the
initial control description or guidance was either insufficiently clear or not sufficiently reflecting actual practices
and challenges encountered 'in the real world’. For example, in the good practices no distinction is made
between preventive (application controls) and detective (SoD) mitigating controls, whereas in practice it is very
important to identify any SoD risks from the ruleset that are ‘mitigated’ by an application control.
Appendix 2 shows the updated framework taking into consideration all relevant changes (e.g. additions,
rewording of control descriptions) and which do reflect the outcome of the applicability check. Any changes to
the initial framework are shown in red in appendix 2.

4.3.2 Key Reasons causing not all Requirements from the Framework being applied
Below I share my reflections with regard to the decisive factors that have caused some requirements from the
good practice SAP (Access) Security Design Framework not to be applied by the case study object.

Reason 1: Case Study Object is a Multinational Company but not a truly Globally Integrated Enterprise
While the case study object operates in multiple countries, in practice the company is a traditional
multinational. Despite the fact that the shared services concept for quite some years already has gained a
foothold within the organization, every country operation still has its own sales force, its own procurement, its
own HR and payroll processes, and so forth. Core processes and functions – barring exceptions – are still very
much managed regionally instead of managed globally.
In my view, in its management and operations, the case study object is therefore a “multinational” or
“international” but not truly global. In other words, the case study object is not a “globally integrated
enterprise”. In this latter model, processes are organized in fundamentally different ways and it calls for

121
different behaviours, more collaboration, greater focus on a multiplicity of cultural differences, and less
hierarchy.
Deployment of a redesign of the authorization roles within the case study object was complicated because it
lacks global standardization of core processes and functions. The fact that the case study object is not a globally
integrated enterprise and the fact that there is still too much ‘compartmentalised thinking’ (versus end-to-end
process thinking) in my view has led to some resistance to the changing – and to be globally standardized -
access control processes. Another complicating factor involves compliance requirements (e.g., tax compliance)
that can be different per country. Local compliance requirements created a need for localizations and
increased the complexity of deployment of the authorization concept.
Since case study object is not a truly global company, collaboration between people who are in different
functional departments and/or regions is not always optimal. Again this is exacerbated by a high degree of
compartmentalised thinking. To illustrate this via an example, whereas IT Security has the objective to ensure
that the right users have the right access to the right systems and applications at the right time, ERM is
especially focussed on ensuring authorization roles do become and stay clean. Although it may seem evident
that both teams would work closely to ensure both objectives are achieved, in practice – and despite weekly
alignment sessions between both departments - there have been several situations where ERM was surprised
by the steps taken by IT Security. Moreover, ensuring good cooperation between IT Security, ERM and the
business is hampered because all 3 groups have their own mind-set and make use of terminology/jargon that
isn’t necessarily understood by the other groups.

Reason 2: Lack of business process ownership (both locally as well as in case study object’s headquarters
Similar to the majority of the other reasons which are given in section 4.3.2, this reason is not technical in
nature. In my view, business process ownership is one of the most critical success factors for the access control
initiative that the case study object has on-going. The concept of business process ownership means allocating
end-to end responsibility for a process to a single individual, across functional or departmental lines.
Ultimately, it is the business process owner who is responsible for managing the access risks with regard to ‘his
or her’ business process. In the case study object’s country of origin/headquarters (HQ) the concept of business
process ownership is relatively new and for some core end-to-end processes it is actually not clear where
business process ownership lies, let alone that the BPOs in SBU ‘C’ and HQ also fulfil a role as global BPOs.
Within SBU ‘A’, although for the majority of the process it is clear where business process ownership is
assigned, there also it appeared that at least some BPOs were either not familiar with the responsibilities that
come with this ownership or were able to get away with not fulfilling these responsibilities.

Reason 3: Lack of Attention for Internal Controls within SBU ‘A’ SAP+ project
It lacked a (strong) focus on appropriate internal controls into the approach and deliverables of the SBU ‘A’
SAP+ project implementation and as a consequence it has not been made certain those controls are “designed
in” to the system from the start, and that the deliverables and documentation produced can be used for future
compliance needs. Control design, testing and control framework documentation were not defined as
(important) work streams within the project. ERM and Internal audit have not been proactively involved in the
SBU ‘A’ SAP+ project activities. Furthermore time pressure that characterized the overall SBU ‘A’ SAP+ project
also translated into time pressure for the role building and role cleansing process.
As a consequence of the above – and despite the presence of a Security team (headed by a System Integrator
representative) in the SBU ‘A’ SAP+ project – deployment of an appropriate SAP Access Security Design
Framework could/has not been ensured. For the SBU ‘B’ SAP+ project, a core internal controls team has been
established.

Reason 4: Good Practice Framework doesn’t consider varying SAP Access Security Maturity Levels
Although the good practice framework in my view is quite comprehensive in describing the requirements/
good practices for each component of SAP Access Security Design, the extent to which each control is
applicable for the case study object varies. Some requirements in the framework, although undeniably good
practices, should only be deployed - by the case study object - once the vast majority of the other requirements
have been implemented and SAP Access Security Maturity within the company has reached a higher level.
Similar to other maturity frameworks, an increase in maturity can only be achieved by first meeting the
requirements from the next higher level: it is not possible to just skip a maturity level.
I therefore emphasize that the framework can best be regarded as a controls norm method that allows
companies to identify SAP Access Security Design requirements and map them with the current state in their
own SAP system. This approach is to identify and remediate the existing gap between the desired state

122
(business requirements) and the actual state. In my recommendations for further research in Chapter 5, I will
come back on this.
Somewhat related to reason 3 is the fact that the framework doesn’t consider the organizational context nor
does it consider any interdependencies. (Re-)design, building and cleansing of authorization roles – and the
extent to which requirements from the good practice framework are applicable to the case study object –
cannot be separated from the organizational context. Organizational context includes elements like:
 Current SAP Access Security Maturity/Capability Level
 Level of global business process standardization
 Single-Instance132 versus Multiple-Instance ERP/SAP implementation
 Legacy situation: SAP versus multitude of (non-SAP) legacy systems
To clarify this: SBU ‘A’ is moving from - an already relatively homogeneous situation in which there were - 3
different SAP instances to the ‘global’ SAP+ instance. SBU ‘A’ already had its own set of SAP authorization roles,
which now need to be replaced by a global set of roles (despite majority of business processes not being
standardized yet). It shall be clear that at least some SBU ‘A’ BPOs have been reluctant to adopt the global
roles, knowing the lacking of global process standardization. For SBU ‘B’ the situation is different as this SBU is
moving from multiple non-SAP legacy systems to SAP globally. For SBU ‘B’, SAP authorization roles were not
defined in the legacy situation.

Reason 5: Lack of a Jointly Developed Strategic Vision on Identity & Access Management
It currently lacks a jointly developed vision by IT Security, ERM as well as the business with regard to the end
state of Identity & Access Management (IAM) within the case study object. Business requirements with regard
to IAM have not been defined. There is no governing document that dictates how IAM technology will support
the business strategy and help drive businesses priorities over the next 3-5 years. Nowhere an IAM strategy
statement is recorded with the list of the strategic priorities for the business (not IT-specific). It also lacks an
agreed prioritization setting - and derived from that a timeline - of the initiatives and projects that will occur
over the next several years.
Since a jointly developed strategic road map has not been defined, securing buy-in from business leadership is
a more ad hoc process (versus structured) which, in turn, makes it more difficult to earn and retain buy-in from
business users. Without such buy-in it is very difficult to deploy those requirements from the good practice
framework where business involvement is a prerequisite for a successful implementation of the requirement.

Reason 6: Lack of Internal Control Awareness across the Organization

Internal control is a crucial aspect of an organization’s governance system and ability to manage risk, and is
fundamental to supporting the achievement of an organization’s objectives and creating, enhancing, and
protecting stakeholder value. Within the case study object internal control is often perceived and treated as a
compliance requirement, rather than as an enabler of improved organizational performance. In general there
is insufficient understanding across the board that effective internal control can help the case study object
organization improve their performance by enabling it to take on additional opportunities and challenges in a
more controlled way. There is insufficient understanding of how organizational performance relates to
effective risk management and the role and effectiveness of internal control.
In conclusion, the internal control environment has created an extra barrier that prevented some requirements
from the good practice framework to be applied.

Reason 7: Lack of Business or Job roles defined

Main reason why (semi-) automated position-based role management/ (de-)provisioning cannot be
implemented (yet) is that business roles/job roles have not been defined yet. The objective is that based on the
position in SAP HCM a specific business role is being assigned automatically, and the assignment is approved
via a workflow. Since it was decided - partly due to time constraints – that for the SBU ‘A’ SAP+ project,
authorization roles from the legacy system were to be lifted & shifted to the new SAP+ system, business roles
were not defined. Now that the SBU ‘A’ SAP+ Project Go-Live Support phase has been completed, a start has
been made with defining business roles.

Reason 8: Lack of timely processing of required changes – on starters, leavers and movers - in HR systems
A key element of efficient access controls processes is the ability to link the system user to the entry in the
Human Resources system such that access privileges timely cease when an employee is terminated and access

132
One of the main advantages of a single ERP instance is to have one single data source.

123
is timely updated when the employee job function changes. However another important reason why
automated position-based role management/(de-)provisioning cannot be implemented yet at case study
object results from the fact that there is no assurance over required changes in HR master data (in SAP HCM) -
caused by starters, leavers and movers - being processed adequately and timely by the HR department in SAP
HCM. This also includes management of information about people who are not employees, such as contractors
and consultants. Most of these people also require access to company resources.

4.3.3 Recommendations and/or Lessons Learned with regard to the Case Study Object
In this section, I provide my recommendations for the case study object. These recommendations are derived
from the “applicability check” I have addressed in section 4.2 as well as my conclusions with regard to the
reasons why some requirements from the Good Practice SAP (Access) Security Design Framework have not
been applied by the case study object (addressed in section 4.3.2).
Reflecting the outcome of section 4.3.2, multiple recommendations can be regarded as important prerequisites
for earning and keeping appropriate executive and business involvement.

Recommendation/Lesson Learned 1 – Define and Deploy Organizational Change Management Approach:

The impact the user community has on the overall success of an SAP GRC AC system implementation should
not be underestimated. Change management – a planned approach to change in an organization – is vital to
providing structure for the acceptance of the SAP GRC AC system and the related access control processes. A
formal change management plan should be developed and a change management team assembled to work
throughout the SAP GRC AC project life cycle to support change management issues associated with the
system’s implementation.
The change management process should begin early in order to create awareness across the organization of
the SAP GRC AC project, its expected benefits, and the impact it will have on people, processes and technology.
At later stages of the project, in addition to driving user training, the change management process plays a key
role in communications and business readiness leading up to SAP GRC AC go-live.

Recommendation/Lesson Learned 2 – Develop a joint strategic vision/strategic roadmap on Identity & Access
Management (IAM) in particular and Internal Controls in general
I would recommend the case study object to draft a roadmap on IAM. Developing the roadmap should be a
joint effort between ERM, IT security and the business: the roadmap should be based on the business
requirements that are to be laid down by the business. Specific steps required to develop a well thought out
road map on Identity & Access Management are as follows:
 Develop a clear and unambiguous understanding of the current state
 Define the desired end state
 Conduct a Gap Analysis exercise
 Prioritize the findings from the Gap Analysis exercise into a series of gap closure strategies
 Discover the optimum sequence of actions (recognizing predecessor – successor relationships)
 Set high level project timelines and determine required resources
 Develop the Road Map and Socialize with relevant stakeholders
As stated this roadmap also would have to contain a section on required resources and pre-conditions that
would need to be in place in order to achieve this vision. Resources should also include reference to any IT
tools that are required, for example SAP Process Controls, SAP Access Violations Management (SAP AVM) or
SAP Dynamic Authorization Management. Once this vision has been approved by key stakeholders, then
business cases would need to be drafted for the IT tools that are required.
The roadmap helps structure the communication between ERM, IT security and the business when it comes to
balancing priorities on IAM initiatives. However it also helps structure the communication towards executive
and business management in a manner that allows ERM and IT Security to act strategically when making
investment decisions and managing projects and make securing buy-in from executive management and
business leadership a more structured processes which, in turn, makes it easier to earn buy-in from business
users.
In addition to developing a joint strategic vision on IAM, I recommend the case study object’s ERM department
also to evaluate whether there is a need for developing a strategic roadmap on Internal Controls in general and
how to improve the effectiveness and efficiency of these controls in the coming 3-5 years. I would recommend
that an internal controls roadmap would also contain the objective to achieve a shift from a situation where
vast majority of the SoD mitigating controls are presented by manual compensating controls (i.e., detective

124
mitigating controls) towards a situation where the ratio preventive controls versus detective controls is at least
more balanced.

Recommendation/Lesson Learned 3 - Alleviate business process ownership issues.

Process ownership is a framework for managing end-to-end business processes in an efficient and effective
way. Its primary characteristic is that process owners are appointed with responsibility for strategic
development and health of core business processes. When successfully implemented process ownership can
deliver improvements in process quality, efficiency, service delivery and the overall control environment. In my
view the lack of business process ownership can seriously jeopardize a successful deployment of SAP GRC AC –
SAP IdM within the case study object. I therefore recommend that for those business processes where there
are ownership issues, these are being addressed. I would like to refer to specific techniques that are well-
known for alleviating business process ownership issues. In order to prevent issues related to process
ownership, as a starting point it is essential to map the functions of the application under consideration to a
classification framework. The MIT Process Handbook is a good source for such process classification
frameworks.

Recommendation/Lesson Learned 4 – Identify a “controls team” that is formally part of the Case Study
Object’s SAP+ project organization structure
Security controls, such as SoD and critical actions and sensitive access, are an integral concept for internal
controls (both access and process controls) and ERP. Controls should be considered in the design of business
processes. ERP systems are highly configurable, and the project team will make decisions about the setup of
processes that have a large impact on internal controls. These automated controls within each business
process, such a tolerance levels, approvals and validation checks, will decrease the number of manual control
activities that need to take place.
I recommend to identify a “controls team” that is formally part of the case study object’s SBU B SAP+ project
organization structure. This team works across the project, engaging with the process teams, security team and
training team to help ensure internal control and compliance requirements are understood, designed into the
system, documented and tested. The controls team also could/should act as a liaison to external and internal
audit to help provide confidence and evidence that internal controls are being addressed in the
implementation.
Somewhat related to the above, is that I also recommend the case study object to improve internal control
awareness across the organization and in doing so also strengthening the overall internal control environment.
Internal control awareness could be enhanced by providing internal controls trainings to executive and
business management.

Recommendation/Lesson Learned 5 – SoD testing to be integrated into ISRT and UAT

UAT is a critical time for user access security testing and validation of fully functioning user roles with the
required authorization and organizational restrictions. Organizational restrictions do include SoD, critical
actions as well as sensitive access. For the SBU ‘B’ SAP+ project I recommend that SoD testing is integrated into
ISRT and UAT (For the SBU ‘A’ SAP+ project this was not or hardly the case). Important precondition for this is
to ensure that SBU ‘B’ SAP+ authorization roles are finalized and cleansed prior to UAT so that the likelihood
that roles used during UAT will actually reflect the (planned) go-live roles is significantly increased. Cleansing of
SBU ‘B’ SAP+ authorization roles – since these are built on the basis of the SBU ‘C’ SAP+ master roles - may
require approval from SBU ‘C’ IT functional team leads for SBU ‘C’ master roles to be adjusted. Timely cleansing
of SBU ‘B’ SAP+ authorization roles therefore requires an effective and efficient alignment process.

Recommendation/Lesson Learned 6 – Expand ruleset to other non-ECC applications

Access risks related to non-ECC SAP applications like Supplier Relationship Management (SRM), Advanced
Planning & Optimization (APO), Business Intelligence (BI) / Business Warehouse (BW) business functions have
not been entered into SAP GRC AC, despite these applications already being live in SBU ‘A’ and SBU ‘C’. This
may result in the potential under reporting of segregation of duties and other access risks. Hence it is
important that relevant access risks linked to these non-ECC applications (both intra and cross applications),
are also comprised in the case study object Global SAP+ ruleset. From a technical perspective it is important
that SAP GRC AC is also connected to these non-ECC SAP applications.

Recommendation/Lesson Learned 7 – Define relevant Key Performance Indicators (KPIs)

125
I do recommend the case study object to establish Key performance indicators (KPIs) and metrics that enables
management of the access management governance process. Recommended that KPIs are defined for each of
the following three categories: managing users (e.g., statistics on user SoD violations, managing roles (e.g.,
statistics on role SoD violations), and managing emergency access. Examples of KPIs per categories are shown
in the explanatory note to control 7.5

Recommendation/Lesson Learned 8 – Define job or business roles

By complementing SAP IdM identity management functionality with the SAP GRC AC solution which manages
access control, compliant identity management would be enabled for the case study object. In other words, by
implementing an integrated SAP GRC AC – SAP IdM solution, it can be ensured that roles and authorizations
assigned to a user do not contain conflicting rights. To achieve compliant (semi-) automated position-based
(de-)provisioning, I first of all do recommend that business roles are defined.
Business roles, which are defined as part of a business process, can be assigned to users. These business roles
consist of one or more technical roles (i.e. derived and composite roles), which are system specific and
represent access information or technical authorizations. When – through SAP IdM - a business role is assigned
to a user, all technical roles for that business role and any role below that it in the hierarchy are assigned to the
user. In addition, workflow and provisioning is automatically triggered.
Permissions require periodic recertification, meaning the organization needs to review who has access to what
and determine whether or not they should still have those permissions. This activity is also called recertification
of job roles, and should be considered for example on a yearly basis once job roles have been defined and
deployed. I would therefore recommend defining roles and responsibilities within the organization that can
recertify permissions, such as system owners, managers, information security officers and so forth. The
objective is to regularly make sure that the roles and people who have permissions to resources should
continue to have those permissions. This process should also include recertification of job role membership to
ensure that the users assigned a given job role are still performing that role within the organization.

Recommendation/Lesson Learned 9 – Explore possibilities to enhance effectiveness and efficiency of SoD risk
analysis and mitigation.
A certain level of access risk is unavoidable – to eradicate it all would limit business productivity. It is virtually
unheard for a company to be able to remediate all of its SoD issues across all of its roles and users. In many
cases, the controls that are put into place to mitigate the risk are manually driven and time consuming.
Typical SoD reporting only goes as far as identifying the conflicts that the users could perform and doesn’t
provide any insight into what users actually did perform within the affected processes. Whilst it is important to
know about the hundreds or thousands of users who may have SoD issues, in my view it is even more critical to
identify the small group of users who have actually performed a violation.
Once the case study object has rolled out integrated SAP GRC AC – SAP IdM solution, the organisation will be
able to report on who has access, whilst trying to ensure that any SoD risk will be mitigated by their controls.
Despite the detailed and comprehensive insight into the access that users have, an integrated SAP GRC AC –
SAP IdM solution will not provide any understanding of what users have actually done.
Once the case study object has completed the roll out of SAP GRC AC-SAP IdM solution, I therefore recommend
a business case for the implementation of SAP Access Violation Management (SAP AVM) is developed. Without
SAP AVM being implemented, the SAP GRC AC-SAP IdM solution would require relying on mitigating controls to
manage the actions of users despite knowing that these controls are largely manual and therefore produce
many false positives.
SAP AVM solution enables the organization to identify the monetary value of actual access violations and
clearly highlight the level of risk an individual user can have on an organisation. The software provides
comprehensive reporting of the actions performed by users within SoD. It does this by automating the
monitoring and correlation of business transactions to pinpoint where actual SoD violations occur. AVM then
also summarises the financial impact by process, risk or user. It therefore means the organization can stop
relying on people to perform intensive manual controls and move to a model where issues will be
automatically routed to the correct person. The impact this can have on the case study object’s business is very
significant. Business Process Owners (BPOs) - engaged with SoD reporting - no longer have to perform reviews
that offer little value but instead can achieve complete clarity over what their team really did do and the
related commercial impact.
In conclusion, I strongly believe the adoption of the SAP AVM solution is inevitable because it addresses a
significant gap currently being left exposed. Furthermore, it is my view that SAP AVM can become an important

126
enabler for BPOs to really take ownership of addressing SoD risks in their area of responsibility. Deployment of
the SAP AVM within the case study object is therefore really a case of when, not if.

Recommendation/Lesson Learned 10 – Ensure existence of processes to manage access upon go-live and
during early stages of live operation.
SBU ‘A’ SAP+ roll out – despite large number of lifted & shifted authorization roles – has made clear that it is
very likely that access issues will be encountered during go-live, stabilization and the post-go-live periods.
These access issues are due to the overall complexity of changing to another instance of SAP and because
processes are different. Although for SBU ‘A’ SAP+ project a support team has been established to address any
access issues during the post go-live support (PGLS) phase, the team has not been instructed to run access risk
reports to determine of security changes result in access risks (e.g., SoD risks, sensitive access).
For SBU ‘B’ SAP+ roll out I therefore recommend that such instructions are provided and that it is ensured that
there are processes to manage – compliant – access upon go-live and during early stages of live operation. In
particular towards the system integrator expectations should be identified about the access management
processes that need to be in place upon go-live and during the post go-live support phase. As it is probably not
possible anymore to identify such expectations in the contract with the system integrator, the case study
object should find other ways to ensure that, upon go-live and during PGLS, SoD and sensitive access risks are
adequately dealt with. I recommend that - unlike in the SBU ‘A’ SAP+ roll out – for the SBU ‘B’ SAP+ roll out,
SAP GRC AC is used to ensure the integrity of the user access environment is maintained once the SAP+ system
goes live.
With hindsight I conclude that preferred approach would have been to include the SAP GRC AC tool - that
supports the development of user access and provisioning – in the scope of the SAP+ implementation for both
SBUs. In my view this would have contributed to a more pro-active approach on addressing access risks.

Recommendation/Lesson Learned 11 - Ensure review of Fire Fighter logs as well as periodic review of Fire
Fighter users, Fire Fighter access and Fire Fighter assignments is being performed.
Current Fire Fighter process with regard to SBU ‘C’ SAP(+) doesn’t include review of Fire Fighter logs by the Fire
Fighter controller, let alone that periodic review of Fire Fighter users, Fire Fighter access and Fire Fighter
assignments is being performed. As a starting point, I therefore recommend that in the design documentation
for the new Emergency Access Management or Fire Fighter process – which will be enabled by the SAG GRC AC
EAM module – these review elements are explicitly addressed. In the EAM operational procedures that are to
be drafted/updated to reflect the new EAM process, roles and responsibilities with regard to each review
element (i.e. FF logs, FF users, FF access and FF assignments) should be clearly addressed. The objective is to
have a standardized EAM process that will be rolled out within all SBUs (SBU ‘A’, SBU ‘B’ and SBU ‘C’). More
detailed information on the individual review elements can be found in control 7.15.

Recommendation/Lesson Learned 12 – Explore possibilities of Attribute Based Access Controls (ABAC)

solutions
The case study object works closely with partners and an extended supplier network to design and
manufacture products. Enabling employees and partners to access and share enterprise data without
compromising security is becoming more and more important, as a successful collaboration depends on the
ability to share information quickly and easily with third-party companies, working across organizational and
geographical boundaries. For the case study object it is vital to balance the need to provide business partners
(including its Joint Venture affiliates133) with ready access to enterprise data while safeguarding valuable
intellectual property and sensitive corporate information. In addition, because of the global character of the
case study object (as well as the nature of its businesses), a number of industry- and country-specific
compliance requirements must be met.
In the scenario above where data elements contribute to the access criteria, Attribute-based Access Control
(ABAC) is a solution that would best support the business authorization requirements in a scalable way.
However, the SAP authorization concept is designed for Role-based security or Role-based Access Control
(RBAC). To this extent, employing a hybrid model of implementing SAP Authorization (RBAC) complemented by
an ABAC system seems to provide the control necessary to ensure business requirements are met along with
optimizing the maintenance of the authorization systems.

133
A corporation may be referred to as an affiliate of another when it is related to it but not strictly controlled by it, or
when it is desired to avoid the appearance of control.

127
The hybrid RBAC-ABAC model leverages SAP GRC AC and SAP authorization for Governance and Functional
Authorization and leverages ABAC for Data Authorization. This hybrid design combines the features and
integrated capabilities of SAP GRC AC and SAP authorization, such as ease of user assignment and role
management, to efficiently supporting data attributes and avoiding the “role explosion” and custom
development that would be necessary and costly by only using the RBAC model.
SAP Dynamic Authorization Management uses Attribute-based Access Control (ABAC) functionality to provide
secure access to enterprise data in SAP applications. This means that the software uses contextual information
in real time from a number of different sources to determine the entitlements of each user. When calculating
whether to grant access, SAP Dynamic Authorization Management draws on account profile information about
the user, including status, history of previous access requests, and the device the individual is using. It also
looks at the status of the specific enterprise-data object that the user wishes to access and the activity the
individual wants to perform – whether viewing, writing, printing, or sharing documents. In addition, the
software takes into account other factors, including the user’s nationality and geographical location.
I recommend the case study object to investigate if there is a positive business case for employing a hybrid
model of implementing SAP Authorization (RBAC) complemented by an ABAC system. As SAP Dynamic
Authorization Management solution is already on the market and can be used across SAP applications
enterprise-wide, I suggest that the business case is focussed on this solution.

128
5 Conclusion, Evaluation and Summary

5.1 Introduction
Chapter 5 is the final chapter of this thesis. In § 5.2 a high level summary is provided. This section also contains
some reflections on the key reasons that cause some requirements from the good practice SAP (Access)
Security Framework not to be deployed by the case study object. I will evaluate whether these reasons are
typical for the case study object only, or are applicable to all organizations with similar characteristics. Since
recommendations towards the case study object itself have already been addressed in section 4.3, this is not in
scope in this chapter. In the final section (§ 5.3) recommendations for future research are discussed.

5.2 Conclusion, Evaluation and Summary

The results of poorly executed SAP (access) security design process are many: unauthorized access, increased
potential for fraud, inefficient access provisioning for end users, and numerous audit issues. All too frequently,
companies that have not proactively identified and addressed potential security issues face expensive and
challenging redesign projects within one or two years of the SAP roll out project. The pitfalls of bad security
design not only include significant efforts to mitigate security exposures, but also loss of productivity due to
delays in granting access.

Based on a thorough analysis of the available literature around SAP (Access) Security in general as well as the
implementation of SAP GRC AC in particular, I have created a good practice Framework for SAP (Access)
Security Design. I find it remarkable that scientific literature around this topic seems to be entirely lacking:
literature available seems to be restricted to professional literature only.

According to the professional literature, there are two main approaches when building access security in SAP.
The first approach is the “top-down” or “proactive” approach described in detail in this thesis and representing
the basis for the good practice SAP (Access) Security Design Framework. It starts by defining access security
requirements up front during the blueprint phase. The second approach, the “bottom-up” or “reactive”
approach, starts with developing SAP roles based on available transactions and job functions and considering
access security requirements and restrictions as a subsequent step, after roles have been set up in the system.

After completing my assessment of the applicability of the good practice Framework for SAP (Access) Security
Design, I come to the conclusion that the method ‘used’ by the case study object - at least in the situation of
the SBU ‘A’ SAP+ project – has large similarities with the second method, the bottom-up approach. As a result,
access security risks and compliance requirements have not been addressed sufficiently during the SBU ‘A’
SAP+ project. Instead, for SBU ‘A’, access security requirements are being addressed after roles have been built
and access has been granted to users, or after go-live. It is my view that, while this method appears time-
efficient in the shorter term, ultimately it will prove more time-consuming because SAP access security design
most likely has to be rebuilt due to excessive access and a large number of SoD conflicts.

Despite the above, in general, applicability of the good practice SAP (Access) Security Design Framework to the
case study object is very good. Vast majority of the good practices or requirements from the framework have
been or are being deployed in the context of the SAP GRC AC-SAP IdM project. Although this may seem
paradoxical, in fact it is not. While the majority of the requirements from the framework are being deployed,
the sequence in which they are being deployed at the case study object is different from the order in the
framework. It is precisely the order in which the requirements are being implemented that determines
whether the SAP GRC AC project will be effective and efficient.

From the ‘applicability check’ it also appeared that some requirements from the good practice SAP (Access)
Security Design Framework were/could not applied by the case study object. In section 4.3.2. I have recognized
8 key reasons causing not all requirements from the Framework being applied. In my view majority of these
reasons are not typical for the case study object only, instead these reasons do apply in a wider context. I am
convinced that the case study object is not the only large multinational organization that - despite its plans and
ambitions - is not a truly global company134 and that – perhaps even exacerbated by these ambitions - is being
confronted with business process ownership issues. I would expect that all large multinational organizations

134
In § 4.3.2 under reason 1, the concept of a ‘truly globally integrated enterprise’ or a ‘truly global company’ is explained.

129
that not are (yet) truly global integrated enterprises and that do face issues with process ownership, will not be
able to deploy all requirements from the good practice SAP (Access) Security Design Framework.

Besides the reasons referred to above, there also some reasons that I would qualify as ‘hygiene factors’ that
simply need to be in place for the requirements from the SAP (Access) Security Framework to de deployed
successfully. These hygiene factors do comprise the following activities:
 Ensuring there is sufficient internal control awareness across the organization and - related to this -
sufficient attention for internal controls – and access controls in particular - within the SAP roll out project.
 Establishing a clear and jointly developed strategic vision on Identity & Access Management that has the
buy-in from both executive and business management.

Another challenge that the case study organization faces when deploying SAP (Access) Security is the
cooperation between representatives from respectively ERM, IT security and the business. For SAP (Access)
Security to be deployed successfully, in my opinion it is important that there is good cooperation and
transparent communication between these three groups. Achieving this is complicated by the fact that these
three different groups often have their own culture and do not necessarily understand each other's
professional language or jargon.

In conclusion, majority of the reasons why the case study object has not deployed all requirements from the
good practice SAP (Access) Security Framework are related to issues that are not technical in nature but are
more related to organizational change and governance.

The ‘applicability check’ that has been performed in this thesis, has provided input for enhancements to be
made to the framework (see appendix 2). In addition to these improvements to the framework, from the
‘applicability check’ also conclusions can be drawn with regard to topics and/or attention points that remain
underexposed – or even completely overlooked – in the professional literature that has been consulted in the
context of this thesis. I conclude that reasons that are referred to in above three paragraphs are largely
overlooked in the professional literature. Furthermore, in the professional literature little or no mention is
made of the importance of organizational change management (in my view, this represents ‘the’ most
important enabler for a successful SAP GRC AC project).

5.3 Recommendations for Future Research

Based on my evaluation of the professional literature and in combination with the ‘applicability check’ I have
performed, I have concluded in section 5.1 that there are some items where the professional literature falls
short. Clearly, obvious recommendation is that these ‘overlooked items’ are getting the attention they deserve
in the professional literature. Interesting research question could be to validate my conclusion/assumption
that the status on these ‘overlooked items’ (which can be different for each organization) largely determines
the probability of success of deployment of a good practice SAP (Access) Security Design Framework in
general and of a SAP GRC AC project in particular. I do understand that it will be a challenge to measure the
status of these ‘overlooked items’ in an objective way. The success of deployment though can be measured
through the KPIs that are referred to in control 7.5

Other recommendations for future research are as follows:

Recommendation 1: Develop a SAP (Access) Security (Design) Maturity Model or Capability Model. In section
4.3.2 I stated that the sequence in which the requirements from the good practice framework could/should be
deployed is very much dependent on the SAP Access Security Maturity Level of the specific organization. My
assumption is that some requirements do belong to the base and/or lower maturity level(s) – and therefore
should be deployed in all circumstances – whereas other requirements are related to the highest/higher
maturity levels – and therefore will not have to be deployed in all circumstances (as the maturity level is not
high enough yet). I would recommend that a SAP (Access) Security (Design) Maturity Model is developed which
sets out for each maturity level the requirements from the good practice SAP (Access) Security Design
Framework that need to be in place. Once this Maturity Model has been defined, it will become possible to
establish a link between good practice framework and the maturity model that can be used by organizations
that are planning to enhance their SAP (Access) Security and/or implement SAP GRC AC (with or without SAP
IdM integration).

130
I would expect that a prerequisite for achieving the higher levels of SAP Access Security Maturity will comprise
some of the elements referred to in the section 5.2 (business process ownership, defining a strategic vision of
Identity & Access Management, internal control awareness, etc.). I recommend that before one dives into
defining the technical and functional details with regard to the SAP (Access) Security, it is important to take a
step back and look at the prerequisites from an organizational change and governance point of view. In the
maturity model these kind of challenges need to be properly reflected.

Recommendation 2: Assess if the hybrid Role Based Access Control (RBAC) - Attribute Based Access Control
(ABAC) model for authorization management in practice really retains the benefits of each model
individually, without also retaining the weaknesses of each model. Research should provide an answer to the
question if the hybrid model - from an effectiveness and efficiency point - is preferred over each model
individually. A long standing debate in the IT community has been whether Role-Based Access Control (RBAC) -
granting access to roles - or Attribute-Based Access Control (ABAC) - granting access via attribute-based rules-
is a better model for authorization management. RBAC versus ABAC models for authorization both have their
own major benefits and weaknesses. It is interesting to determine whether a hybrid model can retain the
benefits of each while avoiding their major weaknesses. Some immediate questions that emerge are:
- How complex will it be to set up and maintain the business ruleset that is required for granting access via
attribute-based rules (ABAC)?
- Can the hybrid-model actually replace the RBAC model that is used so widely that almost all large
enterprises use RBAC to secure their systems?

Recommendation 3: Define measurable quality criteria for (re-)design of the authorization concept. In
control 2.1 I stated that a good authorization concept should have the following characteristics: reliability,
security, testability, flexibility and comprehensibility. In addition to these quality criteria, in the guidance note
to this control I also provided definitions for each criterion. Despite these criteria and corresponding
definitions, I conclude that these offer too little guidance to design a good authorization concept or to assess
the concept. Definitions provided are qualitative in nature and do not provide any measurable quality criteria. I
therefore recommend that measurable quality criteria are developed – preferably categorized by each of the
five quality criteria shown above. I suggest that a benchmark study is being used to come up with target scores
on these measurable quality criteria. Target scores would than represent the scores for organizations that have
better than average scores on majority of the KPIs that is being referred to in control 7.5
A simple example of such a measurable quality criterion would be the maximum number of transactions codes
that can/should be included in a master/derived role. Having too large master/derived roles most certainly will
trigger more SoD conflicts when these broad master/derived roles are merged into composite and eventually
job roles. By ensuring that master roles will not become too broad, merging of these smaller master roles will
trigger less SoD conflicts.

131
Appendix 1: List of literature

 ISACA (2009): Security, Audit and Control Features SAP ERP, 3rd Edition.
 Sergiy Mysyk (2013): Securing GRC - designing effective security within GRC Access Control.
 SAP AG (2013): Minimize Access Risk and Prevent Fraud With SAP GRC AC.
 PwC (2011): SAP GRC AC overview.
 EY (2014): Turning risk into results, enabling access management with SAP GRC.
 VU Postgraduate IT Audit Opleiding (2014): Scriptiewijzer Derde jaar slotexamen 2014 / 2015.
 ISACA, COBIT 5
 Deloitte (2013): Governance, Risk and Compliance, ISACA Monterrey.
 IBM Software Group (2009): Deliver effective governance for identity and access management.
 CSC (2013): Identity and Access Governance: Integrating Compliance Management and Identity Lifecycle
Management.
 Deloitte: Achieving effective risk management and continuous compliance with Deloitte and SAP.
 EY (2014): Turning risk into results: Enabling compliance and process optimization with SAP GRC.
 Drs. Dennis Hallemeesch en drs. Arjan Vreeke RE (2008): De schijnzekerheid van SAP-autoratisatietools,
KPMG, Compact, 2008-2.
 The Institute of Internal Auditors (2007): Identity and Access Management, Global Technology Audit Guide
(GTAG).
 SAP AG (2013): Minimize Access Risk and Prevent Fraud – With SAP GRC AC,
 Ing. J.A.M. Hermans RE, drs. D.B. van Ham CISA en drs. J. ter Hart (2007): In control ten aanzien van uw
autorisatiemanagement, KPMG, Compact 2007/2.
 ISACA (2012): Auditing SAP GRC (The Coca-Cola Company), ISACA-August 17, 2012.
 Kyleen Wissell (2012): Case Study: How The Coca-Cola Company Reduced Time and Effort Spent on User
Access Reviews with an Automated Role and Security Clean-Up Process, The Coca-Cola Company.
 Protiviti (2014): Optimizing User Administration in SAP, ISACA Geek Week – Atlanta, August 13, 2014,
 Protiviti (2013): SAP Access Management Governance: Getting-It-Right, Making It Sustainable.
 Protiviti (2014): Designing SAP Application Security: Leveraging SAP Access Monitoring Solutions During
SAP Implementations, Upgrades or Redesign Projects.
 Fahri Batur (2013): Access Control Product: High Level Design, InteGRC, 4th November 2013.
 Alessandro Banzer (2014): Remediating Access Control SoD Risks, SAP Community Network, created by
Alessandro Banzer on Aug 21, 2014 10:04 AM, last modified by Alessandro Banzer on Aug 25, 2014 6:14
PM.
 Protiviti (2011): SAP Security Remediation: Three Steps for Success Using SAP GRC.
 Brigitte Beugelaar RE RA en drs. Willem van Loon RA CIA (2010): Geslaagd GRC binnen handbereik, KPMG,
Compact 2010/1, p.8-17.
 Protiviti (2014b): Unlocking the Value of Continuous Monitoring and Control Automation Capabilities in SAP
Process Control,
 Los Angeles Unified School District - Office of the Inspector General Internal Audit (2012): Audit Report -
GRC Implementation Review.
 Australian National Audit Office (2009): SAP ECC 6.0 Security and Control – Best Practice Guide.
 Case Study Object (2011): Case Study Object Global User Administration Process and Procedure.
 SAP (2014): SAP Solution Brief: SAP Access Violation Management by Greenlight.
 Ernst & Young (2010): A risk-based approach to segregation of duties - Insights on governance, risk and
compliance.
 KPMG IT Advisory (2014): SAP GRC AC & Access Violation Management.
 PwC (2012): SAP Security Solutions: Is your business protected?
 Jonathan Levitt (2015): IIA Los Angeles SAP Security Presentation, PwC, March 2015.
 Mantran Consulting (2011): SAP Security: Clearing the Confusion and Taking a Holistic Approach, ISACA
Singapore, 2 March 2011.
 Layer Seven Security (2014): Protecting SAP systems from cyber-attack a security framework for advanced
threats – Whitepaper.
 Henk Peter Wind (2015): SAP NetWeaver Identity Management & SAP GRC AC, InteGRC, February 12, 2015.
 Alexander Polyakov (2014a): SAP Security Landscape: How to protect (Hack) your (Their) big business,
ERPScan, 21-October-2014.
 Protiviti (2006): Guide to the Sarbanes-Oxley Act: Managing Application Risks and Controls,

132
 Alexander Polyakov (2014b): SAP Security made easy: How to keep your SAP systems secure, ERPScan, 20-
November-2014.
 Yin R. (2014): Case Study Research: Design and Methods, 5th edition (first edition, 1984), Sage, Los
Angeles.
 Eric Milliot (2014): Case Study as a Research Method, University of Poitiers, France.
 Swetta Singh, Chris Radkowski, Keith Grayson (2012): How to leverage SAP NetWeaver Identity
Management and SAP GRC AC combined solutions, SAP Solution Management, December 6, 2012.
 Marie-Luise Wagner (2008): Practical Guide for SAP Security, SAP.
 Drs. Ivan Spruit, Jasper Schutte MSc en Sander van der Zon MSc (2013): Access Control applicaties voor
SAP, KPMG, Compact, 2013-3.
 Fijneman, Roos Lindgreen en Veltman (2005): Grondslagen IT Auditing.
 Drs. J. ter Hart, (2011): Access Governance: een einde aan de worsteling rondom autorisatiemanagement?,
KPMG, Compact, 2011-2.
 PwC Research and Insights (2014): Security Roles: Technical Insights from PwC.
 Ron Veldhuizen (2015): Case Study: How FrieslandCampina Embedded a Sound Change Management
Strategy into Its SAP GRC AC Implementation Project to Ensure Success, FrieslandCampina.
 Dean Platt (2015): Designing and Building Compliant Roles within SAP GRC 10.x: How to Take the First Step,
Turnkey Consulting.
 Erwin Albers (2015): Rethinking Segregation of Duties: Where Is Your Business Most Exposed?, SAP
Netherlands.
 Susan Stapleton (2015): Apply Existing Risk and Compliance Processes across Both SAP and Non-SAP
Systems with SAP Access Violation Management, Greenlight Technologies.
 Protiviti (2006): Guide to Sarbanes-Oxley Act: Managing Application Risks and Controls.
 Dina Shahin (2015): Leading Strategies to Enforce Your Organisation’s Access Policies Using Emergency
Access Management in SAP GRC AC, Customer Advisory Group.
 Chris Radkowski and Fedya Toslev (2015): Access Governance for the Enterprise: Integrating SAP Identity
Management with SAP GRC AC, SAP.
 Asokkumar Christian, D. Rajen Iyer and Atul Sudhalkar (2014): Implementing SAP Governance, Risk and
Compliance, SAP Press – Galileo Press.
 Case Study Object IT Security Department (2014): Access Management Policy.
 SAP (2014): SAP Identity Management: Overview, October 2014.

133
 Appendix 2: Revised good practice SAP (Access) Security Design Framework (post check)

SAP Access Reference to Top- Good Practice (I) Detailed description of good practice standard and/or (II) Objective of applying good practice Source
Security Domain Down 8 step standard
approach to
building SAP
(Access) Security
III.SAP Security Step 0: Define 0.1 Define and Deploy  Establish a sense of urgency Friesland-
Organizational and Deploy Organizational Change - Push: Executive Board emphasizes importance on internal controls Campina
Structure & Organizational Management Approach - Pull: SoD requirements in place before SAP GRC AC deployment (2015)
Governance Change  Create a guiding coalition
Management - Assemble a powerful coalition
Approach  Develop a vision and strategy
- Technical implementation – “Big Bang”
- Organizational implementation – Phased rollout
 Communicate the change vision
- Communication plan and dedicated Change Manager
- SBU FD/Controllers and management within business units communicate the (importance of)
change in their organization
- Corporate Communication involvement
 Empower employees for broad-based action
- Define clear responsibilities (RACI)
- Dedicated roles in the project (e.g., project management, change management, technical,
functional, trainers, quality assurance)
- Remove barriers to change
 Generate short-term wins
- Plan quick visible performance improvement (e.g., reduction of fire fighters, simplified
reporting, OpCo pilot success) and communicate and quick wins
- Project perspective: start with Analyse Risks module to clean your data, reduce SoD conflicts
and show quick wins
 Consolidate gains and produce more change
- Keep looking for improvements: Keep end-state in mind and keep communicating
- Evaluation: have periodic evaluations (what went right and what can be improved), learn from
the past and show you apply learnings in future rollouts
 Anchor new approaches in the culture
- Embed SAP GRC AC in the core of the organization: define and distribute deliverables, Quick
Reference Guides, Newsflashes, SharePoint/LiveLink
- Keep involving the end users: schedule periodic evaluation sessions with the end users to
monitor the project

134
SAP Access Reference to Top- Good Practice (I) Detailed description of good practice standard and/or (II) Objective of applying good practice Source
Security Domain Down 8 step standard
approach to
building SAP
(Access) Security
III.SAP Security Step 0: Define 0.2 Identify the right internal  Active executive participation SAP
Organizational and Deploy resources  Need a good project manager Netherlands
Structure & Organizational  Need decision makers , Erwin
Governance Change  Need collaboration between all parties Albers, 2015
Management  Need to know the business processes
Approach  Employee and company knowledge are essential
 Awareness about cultural differences (in case of multinational organizations) is also required to
ensure the right internal resources are identified and that there is good collaboration between all
parties. Because of these cultural differences, there is no one-size fits all approach that can
ensure the right internal resources are identified and that there is good collaboration between all
parties
II.SAP Security & Step 1: Define 1.1 Define in scope SAP  Work with BPOs, SAP functional leads, and compliance organizations to identify business Protiviti
Provisioning SoD Policies and applications processes and applications in-scope of the SAP+ project. (2014a)
processes Rule Design  Determine how the different SAP modules (e.g., FICO, MM) and SAP Applications (e.g., (SAP SRM,
III. SAP Security SAP MDM, SAP CRM) would be utilized for each business process.
Organizational  To ensure that the Access Control project applies a risk-based approach it is not sufficient that
Structure & risk management and compliance functions work with Business Process Owners (BPOs) and SAP
Governance functional leads to define the SAP modules and applications in scope for the Access Control
project, also the order in which these modules and applications are dealt with within the
Access Control project, need to be agreed upon. To clarify, it is very likely that any SoD conflicts
with regard to some SAP ECC modules do have a lower risk profile than vast majority of the SoD
conflicts with regard to non-ECC modules like SRM and/or CRM.
II.SAP Security & Step 1: Define 1.2 Establish an agreed-upon  SoD management framework shall contain: Protiviti
Provisioning SoD Policies and and signed-off SoD - Business risk: definition of overall risk that drive the SoD rule and security controls (2014a), EY
processes Rule Design management framework - Risk description: definition of what a user could do if allowed certain access in the SAP system (2010), SAP
III. SAP Security (‘ruleset’) - SoD and Sensitive Access Policies: job functions that represent or increase risk if provided to a NL (2015)
Organizational user without proper monitoring
Structure & - Job function: tasks assigned to a specific user
Governance - SoD rule: SAP transactions and respective authorization objects related to the conflicting job
functions
 Documenting Access Risks should be done in business language
 Element of the SoD management framework is a matrix of potential conflicts (Conflict matrix),
which is independent of the supporting (SAP) application (e.g., ECC, SRM, APO) driving each
transaction

135
SAP Access Reference to Top- Good Practice (I) Detailed description of good practice standard and/or (II) Objective of applying good practice Source
Security Domain Down 8 step standard
approach to
building SAP
(Access) Security
II.SAP Security & Step 1: Define 1.3 Classify SoD risks into risk  Define the different risks levels that will be deployed. This will help management prioritize areas Protiviti
Provisioning SoD Policies and levels (e.g., critical, high, of focus during role build or security remediation phases: (2014a), EY
processes Rule Design medium and low risk) (2010), SAP
III. SAP Security NL (2015)
Organizational
Structure &
Governance
II.SAP Security & Step 1: Define 1.4 Evaluate SAP standard  SAP standard and custom transactions (i.e., transaction codes) should be evaluated to identify Protiviti
Provisioning SoD Policies and and custom transactions those that provide the ability to create, modify, post or delete data related to any of the (2014a),
processes Rule Design identified risks. SAP NL
III. SAP Security  Subsequently, these SAP transactions are grouped into job functions (e.g. Create a GL Account, (2015)
Organizational Post Payments).
Structure &  Enlist the help of IT to assist with technical risk definitions.
Governance  Further to evaluating SAP standard and custom transactions to identify those that provide the
ability to create, modify, post or delete data related to any of the identified risks, it is
recommended that also ‘display only’ custom transactions are being considered. Those display
only custom transactions that are related to sensitive access – in consultation with IT SMEs (and
BPOs) - should be added to the business ruleset as well.
II.SAP Security & Step 1: Define 1.5 SoD ruleset needs to  Any standard/predefined set of SoD rules (which are included in most SAP Access Management Protiviti
Provisioning SoD Policies and reflect the company’s risk solutions) needs to be adjusted, along with the risk ranking, to reflect the company’s risk profile. (2014a), EY
processes Rule Design profile.  In those cases where standard/predefined ruleset is used as a starting point, ensure security (2010),
III. SAP Security parameters (i.e., authorization objects) in ruleset are adjusted to reflect the company’s security InteGRC
Organizational design. (2013)
Structure &  Each BU must perform a customized analysis of its conflicting transactions in order to capture the
Governance real risk for that particular business model
 For multinational organizations that don’t have all their business processes completely
harmonized (yet), it may be considered to have different rulesets per region or per SBU. This is
to be considered when - for one and the same business processes - the access risks identified
and/or the risk scorings assigned by the different regional/SBU BPOs, do (significantly) vary
between the different regions and/or SBUs.
II.SAP Security & Step 1: Define 1.6 Define Sensitive Access  In addition to SoD policies and SoD risk definitions, also define, group and classify sensitive and Protiviti
Provisioning SoD Policies and and Critical Actions Policies critical SAP transactions to enable monitoring and reporting on SAP roles and users who have (2014a)
processes Rule Design add, modify or even display access to the company’s sensitive information
III. SAP Security
Organizational

136
SAP Access Reference to Top- Good Practice (I) Detailed description of good practice standard and/or (II) Objective of applying good practice Source
Security Domain Down 8 step standard
approach to
building SAP
(Access) Security
Structure &
Governance
II.SAP Security & Step 1: Define 1.7 A formal (SAP) AC  Requirements document includes to-be workflows, business owners / approvers, user access Protiviti
Provisioning SoD Policies and application requirements request form fields, custom fields, field mapping between source systems and SAP GRC AC, user (2012)
processes Rule Design document should be master data source, email notification wording and settings, etc.
III. SAP Security completed (including sign-off)  Formal sign-off should be obtained to validate that the document accurately reflects the
Organizational based on discussions with company’s business requirements for the SAP GRC AC tool
Structure & business process
Governance management
II.SAP Security & Step 1: Define 1.8 Identify Risk Owners  Risks belong to the business; risk owners should be business personnel (not IT!) SAP NL
Provisioning SoD Policies and  Assign risk owners to each risk (2015)
processes Rule Design  For multinational organizations that aim to achieve business processes harmonization facilitated
III. SAP Security through a SAP consolidation project (i.e., a project that is aimed at reducing the number of SAP
Organizational instances) or SAP migration project (i.e. a project aimed at moving from different legacy systems
Structure & to SAP), it is important that risk ownership for access risks both at global level as well as at
Governance regional/SBU level is clearly assigned. Especially, when the consolidation or migration project
leads to a shift of access risk ownership from regional/SBU BPOs to global BPOs it is important
that this is made explicit and formalized. Furthermore, it is important that the organizational
change management approach – as referred to in control 0.1 – also captures necessary steps to
ensure the effect these changes will have on both the regional/SBU BPOs as well as the global
BPOs are effectively managed. Not only is there a risk of regional/SBU BPOs resisting the change
since they will lose some responsibilities, there is also a risk that global BPOs will be wary of
having to make decisions about access risks and access controls that involve users in other
regions/SBUs and in other cultures.
II.SAP Security & Step 1: Define 1.9 Policy on how to deal  Potential immediate remedial actions involve shutting down user access to the SAP KPMG
Provisioning SoD Policies and with a breach of the application(s), sending e-mail notifications to the security team and can be referred to in the (2013)
processes Rule Design segregation of duties is policy.
III. SAP Security determined  Any SoD breaches are investigated as soon as possible.
Organizational
Structure &
Governance
II.SAP Security & Step 1: Define 1.10 Policy on how to deal  Going-live with Emergency user functionality in SAP GRC AC (or similar access control application) KPMG
Provisioning SoD Policies and with the use of emergency - along with being able to monitor the segregation of duties rules - can provide a quick win in the (2013)
processes Rule Design users is determined (see Get Clean-phase.

137
SAP Access Reference to Top- Good Practice (I) Detailed description of good practice standard and/or (II) Objective of applying good practice Source
Security Domain Down 8 step standard
approach to
building SAP
(Access) Security
III. SAP Security  The following items should be considered in the emergency access policy (see also control 7.13,
Organizational 7.14 and 7.15 which address controls and considerations related to Emergency Access
Structure & Management in SAP GRC AC):
Governance - Scope of the emergency access policy: (i) include reference to the SAP applications in scope
and (ii) provide clarity over whether the policy comprises both functional IT users as well as
business end users.
- Define Fire Fighter (FF) or Emergency Access use: listing the different activities for which FF or
Emergency Access is to be used. See also control 7.14
- FF ID concept versus Role-Based FF concept: make clear which FF concept is being applied as
well as the underlying rationale and what the implications are. Some of these matters not
necessarily have to be included in a policy, however arguments for choosing one of both
concepts at least should be set out in a decision paper. See also control 7.13
- Define process for requesting FF or Emergency Access: preferably this includes a flow chart
along with roles and responsibilities.
- Define process for reviewing FF or Emergency Access: See also control 7.15
- Define process for administration of FF or Emergency Access users: policy should list who is
responsible for the administration of FF or Emergency Access users. Furthermore, it should
describe how is being dealt with escalations that become relevant when there are errors in
workflows and/or workflow items are not responded to.
I.SAP Security Step 2: Initial Role 2.1 A good authorization  Reliability: the range of authorization has to correspond with the operational responsibility of the SAP (2008),
Authorization and User Design concept should have the end user Protiviti
concept following characteristics:  Security: it has to be guaranteed that no unauthorized users have access to sensitive data or (2013)
Reliability, Security, programs
Testability, Flexibility, and  Testability: the concept has to be comprehensive and transparent both for internal as well as for
Comprehensibility. external auditors.
 Flexibility: it should be easy adaptable, if for example organizational changes occur or new
modules have to be integrated
 Comprehensibility: it should be easily comprehensible for all those involved, as for example
according to name conventions for users, authorizations and profiles.
Authorization concept quality criteria being referred to above can be seen as a useful reference for
designing a (new) authorization concept. However, this control in itself is not sufficient: it also
needs to be secured and monitored that meeting these criteria is ensured in the actual
deployment (i.e., build and roll out) of the authorization concept.
I.SAP Security Step 2: Initial Role 2.2 Involve business process  When defining an authorization concept, it is important to balance business priorities, such as Protiviti
Authorization and User Design owners in the design and the need for flexibility and control, and keep in mind the importance of minimizing the number of (2013)
concept ownership of roles to ensure security roles to keep maintenance efforts to a minimum.

138
SAP Access Reference to Top- Good Practice (I) Detailed description of good practice standard and/or (II) Objective of applying good practice Source
Security Domain Down 8 step standard
approach to
building SAP
(Access) Security
the roles truly reflect business
functions and will be
sustainable in the longer term
I.SAP Security Step 2: Initial Role 2.3 Define the set of SAP  Transaction logs are analysed to determine the set of monthly, quarterly and year-end Protiviti
Authorization and User Design transactions to be included in transactions that should be included in the newly designed SAP roles (2014a)
concept the updated SAP roles by
reviewing the SAP
transaction history135.
I.SAP Security Step 2: Initial Role 2.4 Conduct workshops with  Role templates, consisting of the role's technical name and the underlining transaction codes, will Protiviti
Authorization and User Design BPOs to validate that the be documented. (2014a)
concept respective SAP transaction  Role templates may also include key information related to security restrictions, such as company
groups are aligned with the codes, cost centers or document types.
“to-be” business processes in
case of new SAP
implementations or existing
business processes in case of
security redesign projects
I.SAP Security Step 2: Initial Role 2.5 Define “role owners” for  Role owners are typically part of the functional implementation, or business teams, and usually Protiviti
Authorization and User Design each role template “own” or are responsible for managing and reporting on the data being updated by the SAP (2014a)
concept transactions and roles they own (e.g., a corporate controller would own finance-related roles).
 Responsibilities for role owners include review and approval of SAP transactions to be included in
the role and ongoing maintenance of the role (e.g., transaction additions, deletions, and approval
of mitigating controls if conflicts occur).
I.SAP Security Step 2: Initial Role 2.6 Role naming conventions  An appropriate design for the naming convention should facilitate identification of: Protiviti
Authorization and User Design and role groupings need to - User-defined role versus SAP-delivered roles (2014a)
concept be intuitive not only to IT - Role type
security experts, but also to - Organizational unit (continent, country, city, site/location)
business approvers and - SAP application (e.g. ECC, SRM, CRM, BW) and/or SAP ECC module (e.g., MM, FI, SD)
reviewers - Activity type

135
Good practice # 2.1 is applicable to SAP upgrade or security redesign projects only. The case study object in 2 of the 3 SBUs (i.e., SBU ‘A’ and SBU ‘C’) has the
characteristics of a SAP upgrade project. For new SAP implementations, since no transactional history will be available, alternative good practice would be to review “to-be”
business processes and conducting a preliminary analysis of individual tasks and SAP transactions that will be performed once the new system goes live.

139
SAP Access Reference to Top- Good Practice (I) Detailed description of good practice standard and/or (II) Objective of applying good practice Source
Security Domain Down 8 step standard
approach to
building SAP
(Access) Security
 Have a role naming convention that is future proof and can handle multiple SAP applications (i.e.
not only SAP ECC, but also other SAP applications like SRM, CRM, Product Lifecycle Management
(PLM), etc.) as well as multiple organizational areas across the world.
I.SAP Security Step 2: Initial Role 2.7 Deploy an access  Access management solutions such as SAP GRC AC, can automate the periodic review of users, Protiviti
Authorization and User Design management solution (such identify risks within roles before granting access to productive systems, and streamline (2013)
concept as SAP GRC AC) to help associated audits and reporting the security risks.
design and keep roles free of
SoD conflicts over time
I.SAP Security Step 2: Initial Role 2.8 Make adequate and clear  Some key SAP security considerations are related to: Provititi
Authorization and User Design choices with regard to key - Job Based versus Task Based roles (2014a),
concept SAP security considerations - Single versus Composite roles (PwC,
to ensure appropriate role - Derived versus Enabler roles 2015),
architecture is in place. - Custom or Pre-delivered SAP Roles Turnkey
- HR or position-based design versus functional design Consulting
(2015)
I.SAP Security Step 2: Initial Role 2.9 First key decision to make  Intention of job-based roles is to give each user one role (e.g., Accounts Payables Manager) that Provititi
Authorization and User Design during the actual design of encompasses all of that person’s activities. This approach utilizes fewer roles, but also gives users (2014a),
concept SAP Security is whether to access to transaction codes they might not need. Also, the roles themselves might have SoD (PwC,
use "Job-based" versus conflicts due to the large number of transactions assigned. 2015),
"Task-based" roles  Intention of task-based roles is to give each user multiple roles, each representing one job task Turnkey
(e.g., Release Purchase Requisition). This approach utilizes more roles, but will limit user access Consulting
to the respective tasks performed. (2015)
 Decision around using a job based or task-based approach will depend on the overall job
consistency of job positions, and the maturity of HR departments in relation to the integration
between SAP access requests and employee hiring, transfer and termination processes.
I.SAP Security Step 2: Initial Role 2.10 Decide on whether to  Composite roles are a grouping of roles held within another role Provititi
Authorization and User Design use Composite roles or Single  Main advantage in composite roles is that they provide a simpler user provisioning process since (2014a),
concept roles the user will receive one role. PwC,
 Main disadvantage of composite roles is that users may be granted more access than required (2015),
due to additional tasks or backup responsibilities being included in the composite role. Turnkey
Consulting
(2015)
I.SAP Security Step 2: Initial Role 2.11 Chose appropriate  Based on the two key SAP security considerations that were referred to in 2.8 and 2.9 above (Job Turnkey
Authorization and User Design design variant for the Role Based versus Task Based roles and Single versus Composite roles), three different design variants Consulting
concept Architecture (2015)

140
SAP Access Reference to Top- Good Practice (I) Detailed description of good practice standard and/or (II) Objective of applying good practice Source
Security Domain Down 8 step standard
approach to
building SAP
(Access) Security
for the Role Architecture can be identified: (i) Job-based Single roles, (ii) Job-based Composite
roles and (iii) Task-based Single roles.
 Organization’s choice with regard to the appropriate design variant should consider the pros and
cons for each variant (see overview provided by Turnkey Consulting) and the best fit to the
organization’s requirements.
 It needs to be secured and monitored that the design variant chosen is actually deployed (i.e.,
build and roll out). In doing so, it can be prevented that soon after go-live a major restructuring
of the authorization roles is required.
I.SAP Security Step 2: Initial Role 2.12 Decide on whether to  While task-based roles determine what users can do, enablers determine where they can do it. PwC (2014)
Authorization and User Design use Derived versus Enabler  From a technical perspective, an enabler is an authorization only role that grants access to the
concept roles “where.” They are similar to derived roles except they have a one-to-many relationship with
task roles (whereas derived roles have an one-to-one relationship with task roles).
 In its purest form, one enabler role grants the “where” access for all the “what” roles that a user
has assigned to them. The enabler concept is simple to maintain and very transparent about
what controlled information a user has access to.
 Enabler model works well when going through upgrades — from an enabler perspective, the key
activity when upgrading is to compare the objects in the enabler to the new objects the upgrade
or support pack introduced to ensure the crucial ones are there.
 Both approaches have strengths and weaknesses that must be weighed for an organization’s
specific SAP environment and business and security objectives. The enabler concept yields the
greatest value in environments with very deep and fluid/changing organizational security
requirements. In these situations the enabler concept allows organizations manage more
efficiently the authorization roles when the pure economies of managing derived roles across the
security landscape become burdensome (enabler roles significantly reduce the number of roles
the organization has to maintain).
I.SAP Security Step 2: Initial Role 2.13 Decide on whether to  Not recommended that out-of-the-box are used as a long-term strategy to maintain SAP security. Provititi
Authorization and User Design use Custom or Pre-delivered  Pre-delivered SAP Roles are designed to as one size fits roles, meaning that they have such a wide (2014a)
concept SAP Roles range of job activities combined in a single role that it will be nearly impossible to provision these
roles to a user without granting excessive access.
 Also, out-of-the-box roles may not meet all business access requirements and control
restrictions.
I.SAP Security Step 2: Initial Role 2.14 Decide on whether to  Another consideration when designing SAP security is the level of integration with HR processes Provititi
Authorization and User Design use HR or position-based (e.g., hiring, termination) and overall consistency with job descriptions and positions. (2014a)
concept design versus functional
design

141
SAP Access Reference to Top- Good Practice (I) Detailed description of good practice standard and/or (II) Objective of applying good practice Source
Security Domain Down 8 step standard
approach to
building SAP
(Access) Security
 In ideal scenario, SAP roles should reflect job responsibilities, but if HR departments and
positions are not mature or consistent, an independent security design based purely on job
functions may be the best option.
 Prerequisites for organizations to apply a position-based design are:
- Business processes are globally harmonized across the company.
- HR job descriptions are well-defined and consistent across the company
- Derived from the above job or business roles have been defined
- "Hire-to-Retire" processes is in a mature stage to enable integrated provisioning.
I.SAP Security Step 2: Initial Role 2.15 Apply recognized  Follow a risk-based approach Turnkey
Authorization and User Design enablers for a successful - Least privileged principal with sensitive processes Consulting
concept SAP authorization concept - Split display and change access (2015)
 Plan for the future
- Be aware of ‘Easy to set up, harder to maintain’
- Make sure naming convention allows for future expansions and complexities
 Have a clear authorization concept (role architecture) strategy and stick to it
 Automate provisioning of generic access where possible
 Keep it simple (or as simple as allowed …)
 Ensure that Business Process Owners are involved timely
 Ensure business process are harmonized/standardized across the company
I.SAP Security Step 3: Role Build 3.1 First step in the technical  Building master roles requires close coordination with the systems integrator and BPOs so that all Provititi
Authorization and User role design phase is to build standard and custom SAP transactions and objects being used as part of the role design are (2014a)
concept / II.SAP Assignment “master roles” or “template understood in terms of functionality (e.g., create master data, update financial statements) and
Security & roles”. are also properly incorporated in the template roles
Provisioning
processes
(ARA/user
provisioning)
I.SAP Security Step 3: Role Build 3.2 Second step in designing  “Derived” or “child” roles is where security restrictions are applied (e.g., company code and cost Provititi
Authorization and User SAP roles is to create center limitations) (2014a)
concept / II.SAP Assignment “derived” or “child” roles
Security &
Provisioning
processes

142
SAP Access Reference to Top- Good Practice (I) Detailed description of good practice standard and/or (II) Objective of applying good practice Source
Security Domain Down 8 step standard
approach to
building SAP
(Access) Security
I.SAP Security Step 3: Role Build 3.3 Designing roles that are  Doing so can lead to increased granularity and more restrictive access. Also it can reduce ongoing Provititi
Authorization and User free from SoD conflicts early security maintenance because it makes it easier to respond to changes in user responsibilities (2014a)
concept / II.SAP Assignment in the SAP+ project resulting from the implementation of new SAP functionality and/or organizational alignment
Security &  Prerequisite for ensuring that roles that are designed are free from SoD conflicts early in the
Provisioning SAP+ project, is that the SAP+ project should explicitly recognize this as an objective. Also
processes accountability and responsibility for achieving this objective should be assigned to a senior
member of the SAP+ project (e.g. Security Team Lead).
I.SAP Security Step 3: Role Build 3.4 Leverage SAP GRC AC to  If master roles have inherent SoD conflicts, all derived roles and subsequently assigned users also Provititi
Authorization and User confirm that roles are SoD- will have conflicts (2014a)
concept / II.SAP Assignment conflict –free before
Security & assigning them to end users
Provisioning
processes
I.SAP Security Step 3: Role Build 3.5 Configured workflow for  Required workflow approval steps do comprise: Provititi
Authorization and User user access change requests - approval by the user’s manager. This requires that the user’s manager is also tracked in Active (2014a)
concept / II.SAP Assignment should include required Directory (alternatively allow for the user’s manager to be specified on the user request form).
Security & approvals from user's - approval of access by a role owner
Provisioning manager, role owner, - approval of access by the security team
processes security team, and should - A review and approval of segregation of duties, including the assignment of mitigating controls
also include review and  RACI-model could be used as a starting point for clarifying roles and responsibilities with regard
approval of SoD to the user access change request process (and other access control processes). Once RACI
matrices have been agreed upon, workflows can be configured reflecting these matrices.
I.SAP Security Step 3: Role Build 3.6 Risk-based SoD process  Mapping all of the ways a user could potentially execute a transaction is critical to accurately EY (2010)
Authorization and User requires a company to depicting SoD
concept / II.SAP Assignment discover all the potential  For example, vendor-update rights may be executed through a series of menus within a given
Security & methods for executing a application. The presence of these menus assigned to specific users should be mapped, walked-
Provisioning transaction in order to through and documented in order for the company to accurately test for a particular conflict
processes understand the full potential  One of the key fallacies in menu (or access) mapping is that one only needs to map the
for fraud transactions that are actually used in the application. While this method will usually capture
many of the executed transactions, it will fail to identify the menus business users do not use but
could use to execute a particular transaction.
I.SAP Security Step 3: Role Build 3.7 Regardless of the  Exclusions refer to the user IDs and menus or access rights intentionally omitted in the SoD EY (2010)
Authorization and User treatment of any exclusions analysis.
concept / II.SAP Assignment in the SoD analysis, it is vital  Often system or process accounts, IT administrators, IT operations and support personnel may
Security & to document all omissions, have access to multiple conflicting menus. This may not actually represent a conflict if the goal is

143
SAP Access Reference to Top- Good Practice (I) Detailed description of good practice standard and/or (II) Objective of applying good practice Source
Security Domain Down 8 step standard
approach to
building SAP
(Access) Security
Provisioning their rationale and to to only capture the business users with SoD conflicts. Alternatively, to facilitate continuous
processes communicate this controls monitoring, companies often include IT users in reports on standard sensitive
information to regulators and transaction usage and SoD conflicts.
compliance stakeholders.  Typically, read-only or inquiry functionality in the application should be excluded from the SoD
analysis as it does not permit execution of sensitive transactions.
 Clearly, in case a company’s ruleset also includes sensitive access risks, read-only or inquiry
functionality in the application cannot be excluded in the access risk analysis. Authorization
roles should be assessed both against SoD rule sets as well as Sensitive Access rule sets.
II.SAP Security & Step 4: Role and 4.1 SAP GRC AC (or similar  This is done by simulating and monitoring changes affecting SAP security design, and providing Provititi
Provisioning User Access Risk application) should be timely feedback to BPOs in case potential conflicts arise. (2014a),
processes Analysis leveraged to perform  Based on the defined ruleset it is determined to which extent the desired segregation of duties is KPMG
III.SAP Security periodic role and user actually present. Breaches of the segregation of duties are reported (2013),
Organizational analysis to determine if the  Risk analysis should be run on a periodic basis, especially after unit and integration testing, which InteGRC
Structure & newly designed SAP roles are is when the SAP system design will be updated to accommodate process improvements. (2013)
Governance in compliance with SoD  Specific details on the parameter configuration of the Access Risk Analysis (ARA) submodule are
policies included in a (detail level) design document.
 Risk and compliance functions should not be the only functions who require periodic role and
user analysis to be performed. Also executive management as well as the BPOs themselves
should be mobilized to ensure both push and pull factors are in place (see also control 0.1)
requiring (a) the SAP environment to be “clean” or “conflict-free” post go-live and (b) periodic
access risk analyses to be performed and followed-up upon.
II.SAP Security & Step 4: Role and 4.2 Management should  Defined SAP rule set in SAP GRC AC may change during the course of the SAP+ project, given that Provititi
Provisioning User Access Risk define and document a new SAP transactions may be added to “to-be” processes or new custom transactions may be (2014a),
processes Analysis formal process to govern the developed. It is critical that an organization's rule change process is formally documented to Provititi
III.SAP Security changes to the SAP GRC rule provide proof to management and auditors that the rules are appropriately controlled. (2012), SAP
Organizational set.  The formal change management process for modifications to the rule set should include the NL (2015)
Structure & approval of changes by relevant business owners as well as an overall business owner for certain
Governance types of changes (e.g. deactivation of risks, changes that cross business functions, etc.)
 In addition to establishing a formal change management process, a process should be defined to
periodically review the rule set to confirm that the risks defined are still relevant and to adjust
the rule set as required based upon changes within the case study object organization.
 Considerations that do apply when organizations do update their ruleset can be both functional
(e.g., new business units, new business processes) as well as technical (e.g., new systems in the
landscape, new authorizations or t-codes in use) in nature.

144
SAP Access Reference to Top- Good Practice (I) Detailed description of good practice standard and/or (II) Objective of applying good practice Source
Security Domain Down 8 step standard
approach to
building SAP
(Access) Security
 In addition to documenting the formal process to govern the ruleset changes, also a ruleset
change log template is maintained listing items as Change Request, Reasoning, Change Type
(technical versus functional), Change Object (i.e. functions to be changed), Old Value, New Value,
Change date, Changed by, Approved by.
II.SAP Security & Step 4: Role and 4.3 To ensure SAP  SAP security provisioning process includes procedures that require SAP security teams to perform Provititi
Provisioning User Access Risk environment is “clean” or a risk simulation in SAP GRC AC prior to granting user access or modifying a role. This simulation (2014a), EY
processes Analysis “conflict-free” post go-live, a will determine if role or user changes are posing SoD or excessive access security risks. (2010)
III.SAP Security sound SAP security  It is important for the company to prioritize the conflicts so that remediation and management
Organizational provisioning process must be of the user population can be focused on those conflicts with the greatest potential for risk
Structure & designed and implemented reduction. The correct assessment and definitions of how to manage each of the risk ratings is a
Governance key factor in delivering benefits from a risk-based approach.

II.SAP Security & Step 4: Role and 4.4 Risk Remediation:  Remediation techniques include role redesign, role clean-up, user appropriateness review and KPMG
Provisioning User Access Risk eliminate the identified risks SoD tool implementation. (2013), EY
processes Analysis by making changes to  Quick wins can be achieved through the deployment of advanced data analysis techniques. These (2010)
III.SAP Security granted authorizations or by analyses go beyond determining whether a transaction code is started, and determine whether
Organizational making changes in the and, if so, what changes or bookings a user actually executed.
Structure & authorization concept  Remediation initiatives generally fall into two categories: tactical clean-up of the user population
Governance and strategic role redesign:
- Tactical role clean up: Tactical user population clean up refers to the process of reviewing the
role or security model to evaluate whether both sides of the conflicting transactions are
required for a particular user to do his or her job. Roles alone cannot be used to test for SoD
conflicts; rather, a company must look to the lowest level of security (i.e., menu item, screen,
executable, transaction code) that make up a particular role to understand what transactions a
user can execute.
- Strategic role redesign: Strategic role redesign seeks to define what constitutes SoD conflict
free access across the company. It maps job function and responsibility in the business to the
required access rights in the system. This approach is typically used when the existing role
model is heavily conflicted and cannot be salvaged through clean-up initiatives. Strategic role
design builds sustainable capabilities and processes that serve to maintain the “cleaned” role
structure.
II.SAP Security & Step 4: Role and 4.5 User appropriateness  Examining the current user population for terminated employees from the human resources (HR) EY (2010)
Provisioning User Access Risk reviews provide an easy and list is vital. This step not only reduces the number of users to be analysed, but establishes the
processes Analysis effective way to reduce the population on which to base the SoD testing
number of SoD conflicts

145
SAP Access Reference to Top- Good Practice (I) Detailed description of good practice standard and/or (II) Objective of applying good practice Source
Security Domain Down 8 step standard
approach to
building SAP
(Access) Security
III.SAP Security (revealed in the testing  Furthermore, a careful review of the user population can be applied to determine whether users
Organizational process) should have access to a particular role or group. A simple check of the user population, in the
Structure & context of job title or function, can be used to identify SoD conflicts. Once identified, such SoD
Governance conflicts can be eliminated.
II.SAP Security & Step 4: Role and 4.6 Once remediation is  It is critical to assign accountability for the tasks of role maintenance, user administration and EY (2010)
Provisioning User Access Risk completed, relevant people, SoD rule definitions.
processes Analysis process and technology  Periodic testing and conflict checks should be incorporated into provisioning processes.
III.SAP Security governance activities must  A critical success factor is to support the redesigned processes with the appropriate technology.
Organizational remain in place to help
Structure & ensure the situation does not
Governance arise again
II.SAP Security & Step 5: Security 4.7 Working closely with  Working closely to remediate unauthorized conflicts by regrouping the transaction codes within Protiviti,
Provisioning Testing and Go- BPOs, role owners and the the conflicting role(s) or reassigning the roles for the conflicting user. (2014a)
processes Live Preparation SAP security team to  For SoD conflicts that cannot be resolved for a business-approved reason, such as limited
III.SAP Security remediate unauthorized headcount, mitigating controls should be identified and documented.
Organizational conflicts  As an alternative to the RBAC (Role Based Access Control) model – which can lead to costly
Structure & remediation and/or mitigation efforts since conflict resolution may require altering role
Governance definitions or alternatively the deployment of mitigating controls – the ABAC (Attribute Based
Access Control) model or a combination of both the RBAC and the ABAC model could be
considered. In RBAC, SoD conflicts expand across a larger set of users and permission than those
initially affected. Problem resolution may require changes beyond the immediate scope of the
identified problem. Hence, problem resolution may be time consuming, laborious and expensive.
 SoD requirements on authorization require the ability to provide conditional decisions based on
contextual data. The RBAC model as opposed to the ABAC model is not context-aware and thus
not well suited to handle SoD requirements. In ABAC an unmanaged business requirement for
SoD is the effect of rule design failures: altering failing rules fixes the problem.
 Concerns with regard to the ABAC model are that it can become very complex to set up and
maintain the business ruleset. To clarify: a potentially large number of attributes must be
understood and managed. Attributes have no meaning until they are associated with a user,
object, or relation. Other concerns are that it is not practical to audit which users have access to a
given permission and what permissions have been granted to a given user.
II.SAP Security & Step 4: Role and 4.8 Default access should be  Risk arises when companies assign default access (also known as star access) to sensitive menus, EY (2010)
Provisioning User Access Risk assigned sparingly and transactions or security levels.
processes Analysis careful consideration given to

146
SAP Access Reference to Top- Good Practice (I) Detailed description of good practice standard and/or (II) Objective of applying good practice Source
Security Domain Down 8 step standard
approach to
building SAP
(Access) Security
III.SAP Security any menu or security level to
Organizational which it has been assigned.
Structure &
Governance
II.SAP Security & Step 4: Role and 4.9 Non-standard user IDs  Non-standard user IDs and accounts indicate deviations from the standard naming conventions EY (2010)
Provisioning User Access Risk and accounts should be of the company. Risk is that a single user may have multiple accounts that, when used in
processes Analysis investigated for combination, constitute inappropriate access per the defined SoD business definition.
III.SAP Security inappropriate access and  Segregation of duties also applies to IT functions themselves. There should be segregation
Organizational potentially changed to meet between (1) systems development and operations, (2) operations and data control, and (3) data
Structure & company policy naming base administration and system development.
Governance conventions
II.SAP Security & Step 4: Role and 4.10 Users with direct access  Shared and powerful system accounts (that users can log into) present a challenge as it is EY (2010)
Provisioning User Access Risk (system access) to the lowest impossible to tell with certainty who has used that specific account. Powerful system accounts
processes Analysis level of security (i.e., menus, only present a problem when these accounts are not locked-down and can be logged into by
III.SAP Security screens, transaction codes) users of the system.
Organizational should be carefully analysed  To prevent unauthorized activity, the company should ensure that it is not possible for a user to
Structure & log into the system or process accounts.
Governance
II.SAP Security & Step 4: Role and 4.11 Risk Mitigation:  Risk mitigation phase can be completed concurrently with remediation; or depending on the KPMG
Provisioning User Access Risk objective at this stage is to objectives and compliance time frame, mitigation can be performed last, when conflicts have (2013), EY
processes Analysis mitigate the remaining risks, been reduced to their absolute minimum. (2010),
III.SAP Security whereby compensating  Many companies will choose to mitigate every potential conflict in order to have a safety net of InteGRC
Organizational control measures should be control in place should a conflict arise. This is a sound and practical strategy for companies (2013)
Structure & established and documented looking to control unforeseen or unpredictable risk.
Governance in the application  When a company chooses to mitigate a SoD conflict, it accepts the risk associated with that
conflict and attempts to compensate through the use of application, IT-dependent or manual
controls (or some combination thereof).
 Workshops are held within the organization to identify mitigating controls and where
appropriate, leverage existing controls based on business processes.
 When leveraging mitigating controls, management should develop a conflict-by-conflict analysis
to document the existence of specific key controls that mitigate the risk related to the particular
conflict.
 Important to make a distinction between preventive mitigating control (i.e., configurable SAP
controls like dual authorizations) and detective mitigating controls. Detective mitigating
controls are additional procedures designed to reduce the risk of errors or irregularities and

147
SAP Access Reference to Top- Good Practice (I) Detailed description of good practice standard and/or (II) Objective of applying good practice Source
Security Domain Down 8 step standard
approach to
building SAP
(Access) Security
would include audit trails, reconciliations, exception reporting, transaction logs, supervisory
reviews and independent review.
 Business Process Owners (BPOs) and IT Subject Matter Experts (IT SMEs) can be consulted to
understand if any of the SoD conflicts in the ruleset are mitigated by a preventive mitigating
control. For all preventive mitigating controls, BPOs and/or IT SMEs should provide
documentation (design documents, screenshots) evidencing the design and existence of the
control. Once risk and compliance function has assessed the preventive mitigation control
documentation to be satisfactory, than there is no need to also have a - more time consuming,
laborious and expensive - detective mitigating control in place. Moreover, for the remaining SoD
conflicts - in liaison with BPOs and IT SMEs - it could be useful to consider feasibility of
implementing SAP configurable controls like dual authorizations. In doing so, a company could
reduce the number of detective mitigating controls that are required. Also from a Continuous
Controls Monitoring (CCM) perspective it is a sensible approach to see if more configuration
controls (versus manual controls) can be used.
II.SAP Security & Step 4: Role and 4.12 Mitigating controls  Generally, it is insufficient to deploy “budget to actual reviews” as the mitigating control for all EY (2010)
Provisioning User Access Risk should address a precise risk SoD conflicts as this control is too general; granularity of controls is important when attempting
processes Analysis to detect and prevent fraud or material misstatement.
III.SAP Security  More than one mitigating control can address a conflict. Implementing a balance of preventative
Organizational and detective controls helps manage the risk should one control fail and supports the use of a
Structure & risk-based approach.
Governance  The conflict matrix should document precisely why each control mitigates the specific conflict
risk. This will serve as a justification to auditors and regulators as to why the control was
selected.
II.SAP Security & Step 4: Role and 4.13 Mitigating controls  Knowing who is performing each mitigating control is relevant since it is important to know if the EY (2010)
Provisioning User Access Risk should list who (name and person performing the mitigating control is also one of the conflicted users.
processes Analysis job title) performs each of  Organizational change management may be required to ensure that for each (detective)
III.SAP Security the mitigating controls in the mitigating control assigned, the mitigating control executor is identified/defined timely.
Organizational company.
Structure &
Governance
II.SAP Security & Step 4: Role and 4.14 Continuous monitoring  Detective SAP security monitoring processes should be designed (and established), including Provititi
Provisioning User Access Risk procedures must be generating periodic SoD violation reports reviewed by BPOs and role owners to validate security (2014a)
processes Analysis established and followed (as changes.
III.SAP Security the project go-live date
Organizational approaches)

148
SAP Access Reference to Top- Good Practice (I) Detailed description of good practice standard and/or (II) Objective of applying good practice Source
Security Domain Down 8 step standard
approach to
building SAP
(Access) Security
Structure &
Governance
II.SAP Security & Step 5: Security 5.1 SAP security Unit Testing  SAP security testing includes executing all SAP transactions within a role to confirm that the role Provititi
Provisioning Testing and Go- (UT) and User Acceptance has required transactions and authorization objects to complete the process (e.g., display, (2014a)
processes Live Preparation Testing (UAT) are critical update and post a financial transaction).
steps to ensure users  Security testing also should include formal SoD and sensitive access reviews to confirm the newly
experience minimal access created or updated SAP roles are as SoD conflict-free as possible, and that access to key functions
issues prior to go-live. (e.g. update vendor master data, update chart of accounts) is properly restricted.
 Involving SAP security teams in early stages of the functional testing phase allows the discovery
of potential security issues before it is too late – or costly – to modify roles.
 Since ERP implementation teams are usually being tasked with finishing the implementation
project on time and within budget there is a tendency these implementation teams do not pay
adequate attention to security implications since it increases implementation time and budget. It
is therefore all the more important that ERP security teams and/or Risk and Compliance functions
ensure that they are involved in early stages of the functional testing which allows the discovery
of potential security issues before it is too late – or costly – to modify roles.
II.SAP Security & Step 5: Security 5.2 Company shall not only  EY (2010)
Provisioning Testing and Go- perform intra-application
processes Live Preparation (i.e., within one application)
testing, but also cross-
application (i.e., between
two or more applications)
testing to reveal the
underlying risk of a SoD
conflict.
II.SAP Security & Step 5: Security 5.3 The tone at the top drives  Many companies fail by placing little emphasis on SoD, resulting in significant concerns or worse, EY (2010)
Provisioning Testing and Go- the level of commitment pervasive fraud and control breakdown
processes Live Preparation from all personnel.
II.SAP Security & Step 5: Security 5.4 IT, Finance and other  Finance understands the financial impact associated with the business processes, risks and EY (2010)
Provisioning Testing and Go- management stakeholders mitigating controls better than any other function. Business management will have the clearest
processes Live Preparation must take co-ownership of view on the operational impact. IT understands how to translate that into system data, reporting
the SoD process. and technical remediation. Either way, one organization cannot simply point to the other or
transfer responsibility to the other party.

149
SAP Access Reference to Top- Good Practice (I) Detailed description of good practice standard and/or (II) Objective of applying good practice Source
Security Domain Down 8 step standard
approach to
building SAP
(Access) Security
II.SAP Security & Step 5: Security 5.5 Testing timeline should  Proactive involvement of the auditors helps prevent unnecessary audit fees and allows for EY (2010)
Provisioning Testing and Go- be developed with the input streamlined, efficient testing and reporting.
processes Live Preparation of key business and IT
stakeholders and the audit
team(s).
II. SAP Security & Step 6: Move to 6.1 Once testing is Provititi
Provisioning Production and completed, the newly (2014a)
processes Support designed SAP roles can be
III. SAP Security migrated to the production
Organizational environment according to
Structure & the organization’s change
Governance management policy and
users can be assigned
II. SAP Security & Step 6: Move to 6.2 Establish a support team  This team not only can help resolve access issues on a timely basis, but also run access risk Provititi
Provisioning Production and specifically assigned to reports to determine if security changes will result in SoD or other access risks. (2014a)
processes Support address any SAP access issues  Also, a communication plan should be established to ensure affected users are aware of any
III. SAP Security during go-live and changes and support protocols related to go-live of the SAP system
Organizational stabilization activities.
Structure &
Governance
II. SAP Security & Step 6: Move to 6.3 During SAP  This is done to help with stabilization of the new system, to ensure users are capable of Protiviti,
Provisioning Production and implementation and upgrade performing job functions during and after go-live, and often is performed using SAP GRC AC to (2014a)
processes Support projects allow for temporary review transaction and super-user action logs.
III. SAP Security broader access for “power  Review and remove this temporary broader access after the new implementation is stable.
Organizational users” during the go-live and  If a Post Go-Live Support (PGLS) team has been established to assess, prioritize and resolve any
Structure & stabilization period. issues experienced by the business end users, there is no urgent need for temporary broader
Governance access for “power users” during the go-live and stabilization period.

IV. Ongoing Step 7: SAP GRC 7.1 It is primarily a business  User access activities comprises authorizing and initiating additions, modifications and Protiviti,
Management & AC Post Go-Live responsibility to ensure that terminations to user access tables (2013)
Monitoring of the and Ongoing management of user access  While IT departments should ensure employees in the IT group have adequate access consistent
Security Management & activities does not result in with sound segregation of duties principles and appropriate limitations on access to sensitive
Environment Monitoring of the inappropriate conflicts or functions, these employees should not be responsible for interpreting business user access
requests for propriety.

150
SAP Access Reference to Top- Good Practice (I) Detailed description of good practice standard and/or (II) Objective of applying good practice Source
Security Domain Down 8 step standard
approach to
building SAP
(Access) Security
Security access to sensitive  In complex ERP systems, IT personnel can provide critical expertise on how best to establish and
Environment information. build user access profiles according to the organization’s business requirements.
IV. Ongoing Step 7: SAP GRC 7.2 Deploy a standard access  Deployment of Access Control application functionality enables optimization of the user Protiviti,
Management & AC Post Go-Live management solution, such management and role management process. It enables automating user access management (2013),
Monitoring of the and Ongoing as SAP GRC AC, which can be tasks and delivers visibility across the enterprise. Also, centralizing and automating the KPMG
Security Management & complemented with an provisioning process leads to greater efficiency and control. (2013)
Environment Monitoring of the identity management tool,  Furthermore deployment helps ensure:
Security like SAP NetWeaver Identity - required approvals are consistently and efficiently obtained during the provisioning process
Environment Management. - security changes for potential SoD violations are being tested prior to granting access, and
- mitigating controls are applied prior to moving the change into the production environment.

IV. Ongoing Step 7: SAP GRC 7.3 Develop a strategic vision  Having a strategic vision will enable security to be addressed in an organized, efficient and Protiviti,
Management & AC Post Go-Live for access management that proactive way, while minimizing exposure to major access management risks. (2013)
Monitoring of the and Ongoing aligns with business  Since access control is only one subset of identity management, it is recommended that a
Security Management & requirements and risk comprehensive strategic vision or strategic roadmap with regard to Identity and Access
Environment Monitoring of the tolerance. Management (IAM) is jointly developed by respectively risk and compliance function, IT security
Security and the business. IAM is the security discipline that enables the right individuals to access the
Environment right resources at the right times for the right reasons. Access control is only one subset of
identity management.
 Implementing an IAM solution / strategy can be complex. The impact on the business often
depends upon the current state of the organization i.e. its maturity and its appetite for change.
Different organizations will have varying levels of maturity with regards to IAM and its
implementation. Depending on this maturity, the capability and strategic requirements of an
enterprise will also vary. These will quite often be in constant evolution as the business keeps up
with demands placed upon it.

IV. Ongoing Step 7: SAP GRC 7.4 Identify/define policies  Procedures should be defined for: (1) handling authorization requests which compromise the Protiviti,
Management & AC Post Go-Live that make access defined rules, (2) obtaining appropriate approval of specific exceptions and (3) modifying the (2006),
Monitoring of the and Ongoing management standards clear, requested access in such a way that the defined rules are not compromised. Protiviti,
Security Management & as well as procedures to (2013)
Environment Monitoring of the enforce those standards
Security
Environment
IV. Ongoing Step 7: SAP GRC 7.5 Establish Key  Examples (see below) include statistics on user SoD violations, role SoD violations, provisioning of Protiviti,
Management & AC Post Go-Live performance indicators service-level agreements (SLAs), and remediating tracking. (2013)

151
SAP Access Reference to Top- Good Practice (I) Detailed description of good practice standard and/or (II) Objective of applying good practice Source
Security Domain Down 8 step standard
approach to
building SAP
(Access) Security
Monitoring of the and Ongoing (KPIs) and metrics that  Managing users:
Security Management & enables management of the - # users having high/critical violations,
Environment Monitoring of the access management - Total # of high/critical violations at user level,
Security governance process (by the - Average lead time for processing 'create', 'change' and/or 'remove' access requests,
Environment governance committee or - Average transactions per user
equivalent thereof).  Managing roles:
- # (single/master, composite or job) roles having High or Critical SoD violations built into them,
- # roles not been assigned to users,
- # of transactions per single/master role,
- # duplicate transaction codes between roles
 Managing emergency access:
- How many firefighter and user accounts exist by functional area?
- How often are firefighter accounts being used?
- Are firefighter logs being reviewed in a timely manner, and are issues addressed appropriately?
IV. Ongoing Step 7: SAP GRC 7.6 Work with Business  This helps ensure the governance initiative will add value to the business. Protiviti,
Management & AC Post Go-Live Process Owners (BPOs) and (2013)
Monitoring of the and Ongoing secure their buy-in
Security Management & throughout the development
Environment Monitoring of the of the access management
Security governance processes.
Environment
IV. Ongoing Step 7: SAP GRC 7.7 Perform periodic self-  This will ensure it continues to accomplish the core objectives Protiviti,
Management & AC Post Go-Live reviews of the access (2013)
Monitoring of the and Ongoing management governance
Security Management & process
Environment Monitoring of the
Security
Environment
IV. Ongoing Step 7: SAP GRC 7.8 Deploy organizational  At the center is a governance lead: a subject matter expert who reports to executive Protiviti,
Management & AC Post Go-Live structure that is optimal for management. This person drives the day-to-day access tasks for access management, (2013)
Monitoring of the and Ongoing the long-term success of coordinates policy changes, and is the primary contact for the business.
Security Management & access management controls.  The governance lead also coordinates the governance committee, which consists of stakeholders
Environment Monitoring of the from the various organizations, such as information systems (IS), finance, internal audit, and the
Security BPOs.
Environment

152
SAP Access Reference to Top- Good Practice (I) Detailed description of good practice standard and/or (II) Objective of applying good practice Source
Security Domain Down 8 step standard
approach to
building SAP
(Access) Security
 The governance team designs, implements and executes controls. It also owns the description of
roles and responsibilities. Information from the governance team is communicated to the user
community and supported though access management single point of contact within the
business and associated BPOs.
IV. Ongoing Step 7: SAP GRC 7.9 Key areas to consider for  Ownership: ISACA
Management & AC Post Go-Live a governance team the - Who approves access? (2012)
Monitoring of the and Ongoing governance of access - Who approves assigning a mitigating control?
Security Management & controls management should - Who defines the risk/function and approves changes?
Environment Monitoring of the be around Ownership, Risk  Risk level:
Security Level, New functionality and - What does each risk level mean (low/medium/high/critical)?
Environment Ongoing Processes - What are the expectations for each risk level?
 New functionality:
- What is the process to identify new functionality added to the system?
- How are these analysed and included (if needed) into a ruleset?
 Ongoing processes:
- Access Provisioning (Preventative SoD/sensitive access analysis)
- Appropriate approvals (role owner, manager)
- Periodic Access Reviews (detective SoD/sensitive access analysis)
- Mitigating Control Reviews (review of users with sensitive access based on business need)
IV. Ongoing Step 7: SAP GRC 7.10 A security governance  Such a policy is to ensure consistency and minimize significant risk to the environment Protiviti,
Management & AC Post Go-Live policy should be in place that  Policy should be designed to create standards around the following key areas: User Access (2013)
Monitoring of the and Ongoing contains standards for the Management, Custom Program and Table Security Requirements, Backend System
Security Management & SAP ECC - as well as other Configurations, Role Creation and Maintenance Standards, Password Management, Security
Environment Monitoring of the relevant SAP application - Parameters.
Security production environments
Environment
IV. Ongoing Step 7: SAP GRC 7.11 Independent reviews of  Review should consider multiple elements which include, among other things: Protiviti,
Management & AC Post Go-Live user access rights should be - Evidence of the application and data owners' approval and monitoring of the propriety of the (2006),
Monitoring of the and Ongoing performed periodically access “touch points” identified. KPMG
Security Management & - Appropriate consideration of system administration access for the transactions being (2013)
Environment Monitoring of the reviewed.
Security - Evidence that critical segregation of duties rules are not being violated due to personnel access
Environment modifications since the prior review.
- Organizational policies regarding access provisioning are being followed.

153
SAP Access Reference to Top- Good Practice (I) Detailed description of good practice standard and/or (II) Objective of applying good practice Source
Security Domain Down 8 step standard
approach to
building SAP
(Access) Security
- Evidence that specific critical transactions were not inappropriately accessed since the previous
review.
 If changes are needed based on these reviews, a standard process should be in place to ensure
these changes are handled in an expedient manner.
 If there are findings in the access security area that evidence a breakdown in the security
administration process, a root-cause analysis should be undertaken and the matters resolved on
a timely basis.

IV. Ongoing Step 7: SAP GRC 7.12 Integrate Access  SAP GRC AC can be integrated with SAP Process Control, whereby, for example, the effectiveness KPMG
Management & AC Post Go-Live Control-application with of the mitigating controls that were assigned in SAP GRC AC can be determined. By making use of (2013)
Monitoring of the and Ongoing Continuous Control the 'test of effectiveness' functionality in SAP Process Control, it is possible to determine if the
Security Management & Monitoring (CCM) mitigation controls have actually been executed and it can also be determined whether the
Environment Monitoring of the application control is effective.
Security  As part of the stay clean – continuous monitoring phase, important prerequisite is also to assign
Environment responsibilities and define procedures for periodic monitoring of assigned authorizations and
breaches with regard to segregation of duties.

IV. Ongoing Step 7: SAP GRC 7.13 Decide on using Fire Typical risks with the Role-Based Fire Fighter Concept are: Customer
Management & AC Post Go-Live Fighter ID concept versus  While using the Fire Fighters role-based concept no reason code can be entered and no comment Advisory
Monitoring of the and Ongoing Role-Based Fire Fighter be made. In contrast to the Fire Fighter ID concept, the user does NOT enter the information. The Group
Security Management & concept for Emergency controller who has to check and verify the logs does not know why a change is being made. (2015)
Environment Monitoring of the Access or Fire Fighter  Under the Fire Fighters role-based concept, the end users do not know they are using Fire Fighter
Security functionality roles. Due to the missing log on, the end users do not see any difference between using a Fire
Environment Fighter role and the other regular roles assigned to them. This can lead to extensive use/ misuse
of the Fire Fighter roles.
 The role-based access does not provide logs for systems where the access is given based on
authorization objects and not on transaction code level.
IV. Ongoing Step 7: SAP GRC 7.14 Define/Identify activities It is recommended that Fire Fighter or Emergency Access is to be used for: Customer
Management & AC Post Go-Live for which Emergency Access  Emergency Access: Advisory
Monitoring of the and Ongoing Management (EAM)136 or - System Issues (Administration usually does not have global access rights with their regular user Group
Security Management & Fire Fighter (FF) functionality ID) (2015)
Environment Monitoring of the is to be used. - Ability to replace colleagues who are out of office (unplanned)
 Critical Access/Access Rarely Required:

136
EAM is a submodule within the SAP GRC AC application that can be used to manage – temporary- emergency or firefighter access.

154
SAP Access Reference to Top- Good Practice (I) Detailed description of good practice standard and/or (II) Objective of applying good practice Source
Security Domain Down 8 step standard
approach to
building SAP
(Access) Security
Security - Open/Close system for Customizing/Development
Environment - Year-End Closing activities
- Upload of data into PROD systems
- Import of transports into PROD systems
- Depreciation run
 Helpdesk and Support:
- Helpdesk and Support usually have display access with their regular user ID but must have
change access from time to time to test issues the end users are having
 Instead of Mitigations:
- If a user has a SoD issue with the regular user ID, part of the access can be given using the Fire
Fighter concept instead of assigning a mitigating control. This option should be considered only
if the activity is rarely carried out (e.g., 6 times per year review of Fire Fighter logs versus 12
monthly mitigation control activities).
 Performance Critical Activities, which should be carried out only by one person at a time:
- E.g., MRP run
Note: Typical activities for which EAM or FF functionality is not to be used are also defined.

With regard to defining the process of requesting access to EAM or FF functionality, also the
following items are to be defined:
 Who approves EAM or FF request: IT versus Business
 When to request EAM or FF access:
- Pre-approved (access assigned for unlimited period of time)
- During incidents (access requested and assigned for specific period)
- Hybrid (core team with continuous access, access to other users only assigned in case of
incidents)
 What is the default validity period for Fire-Fighter access.
IV. Ongoing Step 7: SAP GRC 7.15 Emergency Access  Review of Fire Fighter Users: Customer
Management & AC Post Go-Live Management Review is to be - Sometimes assigning a Fire Fighter ID may be the quicker solution to a missing access problem. Advisory
Monitoring of the and Ongoing deployed and should consist The users accumulate access to Fire Fighter IDs. Once a year a review should be done on if the Group
Security Management & of the following elements: (1) roles required by a user using a Fire Fighter ID can be assigned directly to him/her. (2015)
Environment Monitoring of the Review of Fire Fighter Users,  Review of Fire Fighter Access:
Security (2) Review of Fire Fighter - Once per year a review should be carried out and the executed transactions – using Fire Fighter
Environment Access, (3) Review of Fire Access - should be checked on whether they are included in roles that can be requested by end
Fighter Assignments and (4) users. Many users may use Fire Fighters because requesting a role change is too complicated or
Review of Fire Fighter Logs takes too much time.

155
SAP Access Reference to Top- Good Practice (I) Detailed description of good practice standard and/or (II) Objective of applying good practice Source
Security Domain Down 8 step standard
approach to
building SAP
(Access) Security
- Organizations may find a group of Fire Fighter Users using the same transactions and another
group of Fire Fighter Users using another group of transactions. This can/should result in a split
of Fire Fighter IDs that are more appropriate to those 2 groups. This review can be carried out
using the FF-logs and Pivot tables showing the clusters of users and transactions
 Review of Fire Fighter Assignments:
- Once per year a review should be carried out to find out which users have access to which Fire
Fighters, but also to ensure that (i) obsolete access is removed (e.g., user is not responsible for
the task any longer) and (ii) unnecessary assignments are removed (e.g., Fire fighter access was
granted in case the user has to replace a colleague, but the department has grown since that
time and a replacement is in place)
 Review of Fire Fighter Logs:
- After a Fire Fighter was used, logs are created that contain the changes done using the Fire
Fighter. It is recommended that it is defined how the logs are generated, to avoid Controllers
waiting for logs or not knowing that a Fire Fighter was used and not reviewing the logs.
Recommended to define a standard Notification Type for the organization.
- Usage of the EAM workflow in SAP GRC AC is recommended, so the Fire Fighter Controllers
receive a Workflow notification and the reviews done are recorded centrally.
- After the implementation of new Fire Fighters (IDs), and once per year, a review should be
carried out. Logs should be reviewed for (i) length (number of entries) and (ii) for the length of
time a Fire Fighter was used by a person
- A policy should be in place that forbids users to use Fire Fighters extensively. Users should
either use their own regular user ID or request missing roles. Fire Fighters should only be used
in emergency cases or exceptional cases, not for hours.
 It should be clear which function(s) will become responsible for reviewing respectively (i) Fire
Fighter Users, (ii) Fire Fighter Access, (iii) Fire Fighter Assignments and (iii) Fire Fighter Logs.
IV. Ongoing Step 7: SAP GRC 7.16 Deploy Exception-  Enable exception-based monitoring of SoD violations: Greenlight
Management & AC Post Go-Live Based SoD Monitoring and - Automate identification and review of actual SoD violations Technolo-
Monitoring of the and Ongoing focus on actual access - Alert business owners only when exceptions occur, reducing manual control efforts and gies (2015)
Security Management & violations eliminating false positives
Environment Monitoring of the - Use a comprehensive library of automated SoD controls across business processes
Security - Have centralized tracking, investigation, and resolution of SoD violations
Environment  Assess the financial exposure of SoD violations:
- Summarize the monetary value of actual SoD violations
- Clearly articulate the financial exposure that broad user access has on the business
- Drive change where the impact exceeds the materiality threshold

156
SAP Access Reference to Top- Good Practice (I) Detailed description of good practice standard and/or (II) Objective of applying good practice Source
Security Domain Down 8 step standard
approach to
building SAP
(Access) Security
 SAP Access Violation Management (AVM) offers the functionality that is required to deploy
Exception-Based SoD Monitoring and focus on actual access violations (also taking into
consideration the financial exposure of such actual SoD violations
IV. Ongoing Step 7: SAP GRC 7.17 Reduce governance  Extend the capabilities of the Access Control application across all relevant enterprise systems Greenlight
Management & AC Post Go-Live costs of enterprise-wide (i.e. also focus on risk in applications outside ERP), e.g.,: Technolo-
Monitoring of the and Ongoing access by extending the - Non-ABAP applications like SAP Business Planning and Consolidation (BPC), SAP Master Data gies (2015)
Security Management & capabilities of the Access Management (MDM), SAP Master Data Governance (SAP MDG)
Environment Monitoring of the Control application across all - Cloud-based applications like Ariba, SuccessFactors, Salesforce.com
Security relevant enterprise systems - Non-SAP applications like Oracle, JD Edwards, Hyperion
Environment (SAP and non-SAP)  SAP Access Violation Management (AVM) analyses transactions and user activities across
business applications (SAP and non-SAP) to detect and prevent risks that can materialize in SoD
violations
IV. Ongoing Step 8 8.1 Facilitated through SAP  Two good practice scenarios for possible SAP NW IDM and SAP GRC AC integration are as follows: InteGRC
Management & Compliant GRC AC and SAP IdM - Scenario 1: IdM-Driven User Provisioning with Access Control Integration; (2015), SAP
Monitoring of the Identity integration, provide - Scenario 2: Access Control-Driven User Provisioning with IdM Integration. (2015)
Security Management automated, position based  Prior to implementing (business rule) compliant, automated, position based role management
Environment role management while also through deploying integrated SAP GRC AC-SAP IdM solution, the following preconditions need to
ensuring business rules (SoD) be in place:
compliance. - Definition of job or business roles through defining a business role hierarchy and assigning
technical – derived and composite – roles to business roles. Permissions are best assigned to
job roles rather than to individuals. Making those roles correspond to real-life job tasks and job
titles is a powerful way to manage identities and access over the long term.
- Large dependency on the HR systems requires that there are adequate processes and
procedures that ensure required changes in HR master data (in SAP HCM) caused by starters,
leavers and movers being processed adequately and timely by the HR department in SAP
HCM. An organization’s workforce is managed by the personnel or human resources
department. They also have to manage information about people who are not employees, such
as contractors and consultants. Most of these people require access to company resources. It is
recommended to use the HR systems as much as possible as an authoritative source of data for
a company’s identity and access management system. This will help avoid repetitive work,
errors, inconsistencies and other problems as the IAM system grows.
IV. Ongoing Step 8 8.2 When exploring potential  Request submission source SAP (2015)
Management & Compliant SAP GRC AC – SAP IdM - From where will the provisioning request be initiated (HR System and/or SAP GRC AC and/or
Monitoring of the Identity integration scenarios, do SAP IdM)?
Management considered items like:  Provisioning roles

157
SAP Access Reference to Top- Good Practice (I) Detailed description of good practice standard and/or (II) Objective of applying good practice Source
Security Domain Down 8 step standard
approach to
building SAP
(Access) Security
Security Request submission source, - Role source: Where will the roles for provisioning be maintained (AC and/or IdM)?
Environment Provisioning roles, Approval - Preferred approach is to have one role source for SAP roles
workflow, SoD Risk analysis, - Going forward it is expected that SAP will build-in business role synchronization between SAP
Request status and audit GRC AC and SAP IdM, making this issue not/less relevant
trails, Existing functionality  Approval workflow
and change control - Do you want to use approval workflow within AC and/or IdM?
- Need to consider user notifications from AC and/or IdM
 SoD Risk analysis
- When provisioning new users, the request does not have to be submitted to AC for risk
analysis, and no polling is required. IdM can retrieve the result by also polling the risk analysis
web service with Request ID.
- When provisioning existing users, risk analysis can be called by IdM
 Request status and audit trails
- Consider requirements for request status and audit trails while defining the integration
solution (web services can only pass certain fields, while more details may be viewed natively
in AC or IdM)
 Existing functionality and change control
- IdM’s change control policy and its impact on solution and implementation: Are changes to the
current IdM process realistic?

158
Appendix 3: COBIT 5 on Access Rights
In below table, any relevant management practices and/or risk controls with regard to SAP Security are shown. Those management practices which are related to building
and maintaining an appropriate SAP (Access) Security are marked in yellow.
COBIT 5 Process description
process
DSS05 Protect enterprise information
Manage to maintain the level of
Security information security risk
Services acceptable to the enterprise in
accordance with the security
policy. Establish and maintain
information security roles and
access privileges and perform
security monitoring.
Process COBIT 5 Control Objective
Purpose
Statement
Minimise the DSS05.02 Manage network
business and connectivity security.
impact of
operational Use security measures and
information related management
security procedures to protect
vulnerabilities information over all methods of  Encrypt information in transit according to its classification.
and incidents. connectivity.
DSS05.04 Manage user identity  Maintain user access rights in accordance with business function and process
and logical access.
Ensure that all users have
information access rights in
accordance with their business
requirements and co-ordinate
with business units that
manage their own access rights  Authenticate all access to information assets based on their security classification,
within business processes.
Management practice / Risk controls
 Based on risk assessments and business requirements, establish and maintain a
policy for security of connectivity.
 Allow only authorised devices to have access to corporate information and the
enterprise network. Configure these devices to force password entry.
 Implement network filtering mechanisms, such as firewalls and intrusion detection
software, with appropriate policies to control inbound and outbound traffic.
 Apply approved security protocols to network connectivity.
 Configure network equipment in a secure manner.
 Establish trusted mechanisms to support the secure transmission and receipt of
information.
 Carry out periodic penetration testing to determine adequacy of network protection.
 Carry out periodic testing of system security to determine adequacy of system
protection.
requirements. Align the management of identities and access rights to the defined
roles and responsibilities, based on least-privilege, need-to-have and need-to-know
principles.
 Uniquely identify all information processing activities by functional roles, co-
ordinating with business units to ensure that all roles are consistently defined,
including roles that are defined by the business itself within business process
applications.
co-ordinating with business units that manage authentication within applications
used in business processes to ensure that authentication controls have been
properly administered.
 Administer all changes to access rights (creation, modifications and deletions) to
take effect at the appropriate time based only on approved and documented
transactions authorised by designated management individuals.
 Segregate and manage privileged user accounts.
 Perform regular management review of all accounts and related privileges.
159
COBIT 5 Process description
process
DSS06 Define and maintain appropriate
Manage business process controls to
Business ensure that information related
Process to and processed by in-house or
Controls outsourced business processes
satisfies all relevant information
control requirements. Identify
the relevant information control
requirements and manage and
operate adequate controls to
ensure that information and
information processing satisfy
these requirements.
Process COBIT 5 Control Objective
Purpose
Statement
DSS05.06 Manage sensitive
documents and output
devices.
Establish appropriate physical  Establish an inventory of sensitive documents and output devices, and conduct
safeguards, accounting
practices and inventory
management over sensitive IT  Destroy sensitive information and protect output devices (e.g., degaussing of
assets, such as special forms,
negotiable instruments, special
purpose printers or security
tokens.
Maintain DSS06.03 Manage roles,
information responsibilities, access
integrity and privileges and levels of
the security of authority.
information
assets Manage the business roles,
handled responsibilities, levels of
within authority and segregation of
business duties needed to support the
processes in business process objectives.
the enterprise Authorise access to any
or information assets related to
outsourced. business information
processes, including those
under the custody of the
business, IT and third parties.
This ensures that the business
knows where the data are and
who is handling data on its
behalf.
Management practice / Risk controls
 Ensure that all users (internal, external and temporary) and their activity on IT
systems (business application, IT infrastructure, system operations, development
and maintenance) are uniquely identifiable. Uniquely identify all information
processing activities by user.
 Maintain an audit trail of access to information classified as highly sensitive.
 Establish procedures to govern the receipt, use, removal and disposal of special
forms and output devices into, within and out of the organisation.
 Assign access privileges to sensitive documents and output devices based on the
least privilege principle, balancing risk and business requirements.
regular reconciliations.
 Establish appropriate physical safeguards over special forms and sensitive devices.
electronic media, physical destruction of memory devices, making shredders or
locked paper baskets available to destroy special forms and other confidential
papers).
 Allocate roles and responsibilities based on approved job descriptions and allocated
business process activities.
 Allocate levels of authority for approval of transactions, limits and any other
decisions relating to the business process, based on approved job roles.
 Allocate access rights and privileges based on only what is required to perform job
activities, based on pre-defined job roles. Remove or revise access rights
immediately if the job role changes or a staff member leaves the business process
area. Periodically review to ensure that the access is appropriate for the current
threats, risk, technology and business need.
 Allocate roles for sensitive activities so that there is a clear segregation of duties.
 Provide awareness and training regarding roles and responsibilities on a regular basis
so that everyone understands their responsibilities; the importance of controls; and
the integrity, confidentiality and privacy of company information in all its forms.
 Periodically review access control definitions, logs and exception reports to ensure
that all access privileges are valid and aligned with current staff members and their
allocated roles.
160
COBIT 5 Process description
process
APO07 Provide a structured approach to
Manage ensure optimal structuring,
Human placement, decision rights and
Resources skills of human resources. This
includes communicating the
defined roles and
responsibilities, learning and
growth plans, and performance
expectations, supported with
competent and motivated
people.
Process COBIT 5 Control Objective
Purpose
Statement
DSS06.06 Secure information
assets.
Secure information assets
accessible by the business
through approved methods
including, information in
electronic form (such as create
new assets in any form,
portable media devices, user
applications and storage
devices), information in
physical form (such as source
documents or output reports)
and information during transit.
This benefits the business by
providing end-to-end
safeguarding of information.
Optimise APO07.03 Maintain the skills
human and competencies of
resources personnel.
capabilities to
meet Define and manage the skills
enterprise and competencies required of  Provide access to knowledge repositories to support the development of skills and
objectives. personnel. Regularly verify that
personnel have the
competencies to fulfil their
roles on the basis of their
education, training and/or
experience, and verify that
these competencies are being
maintained, using qualification  Conduct regular reviews to assess the evolution of the skills and competencies of the
and certification programmes
where appropriate. Provide
employees with ongoing
learning and opportunities to
maintain their knowledge, skills
and competencies at a level
Management practice / Risk controls
 Apply data classification and acceptable use and security policies and procedures to
protect information assets under the control of the business.
 Provide acceptable use awareness and training .
 Restrict use, distribution and physical access of information according to its
classification.
 Identify and implement processes, tools and techniques to reasonably verify
compliance.
 Report to business and other stakeholders on violations and deviations.
 Define the required and currently available skills and competencies of internal and
external resources to achieve enterprise, IT and process goals.
 Provide formal career planning and professional development to encourage
competency development, opportunities for personal advancement and reduced
dependence on key individuals.
competencies.
 Identify gaps between required and available skills and develop action plans to
address them on an individual and collective basis, such as training (technical and
behavioural skills), recruitment, redeployment, and changed sourcing strategies.
 Develop and deliver training programmes based on organisational and process
requirements, including requirements for enterprise knowledge, internal control,
ethical conduct and security.
internal and external resources, including succession planning.
 Review training materials and programmes on a regular basis to ensure adequacy
with respect to changing enterprise requirements and their impact on necessary
knowledge, skills and abilities.
161
COBIT 5 Process description
process
APO10 Manage IT-related services
Manage provided by all types of suppliers
Suppliers to meet enterprise
requirements, including the
selection of suppliers,
management of relationships,
management of contracts, and
reviewing and monitoring of
supplier performance for
effectiveness and compliance.
BAI06 Manage all changes in a
Manage controlled manner, including
Changes standard changes and
emergency maintenance relating
to business processes,
applications and infrastructure.
This includes change standards
and procedures, impact
assessment, prioritisation and
authorisation, emergency
changes, tracking, reporting,
closure and documentation.
BAI08 Maintain the availability of
Manage relevant, current, validated and
Process COBIT 5 Control Objective Management practice / Risk controls
Purpose
Statement
required to achieve enterprise
goals.
APO07.06 Manage contract  Obtain formal agreement from contractors at the commencement of the contract
staff that they are required to comply with the enterprise's IT control framework, such as
policies for security clearance, physical and logical access control, use of facilities,
Ensure that consultants and information confidentiality requirements, and nondisclosure agreements.
contract personnel who  Conduct periodic reviews to ensure that contractors' roles and access rights are
support the enterprise with IT appropriate and in line with agreements.
skills know and comply with the
organisation’s policies and
meet agreed-upon contractual
requirements.
Minimise the APO10.02 Select suppliers  In the specific case of acquisition of infrastructure, facilities and related services,
risk include and enforce the rights and obligations of all parties in the contractual terms.
associated Select suppliers according to a These rights and obligations may include service levels, maintenance procedures,
with non- fair and formal practice to access controls, security, performance review, basis for payment and arbitration
performing ensure a viable best fit based procedures.
suppliers and on specified requirements.
ensure Requirements should be
competitive optimised with input from
pricing. potential suppliers.
Enable fast BAI06.02 Manage emergency  Ensure that a documented procedure exists to declare, assess, give preliminary
and reliable changes. approval, authorise after the change and record an emergency change.
delivery of  Verify that all emergency access arrangements for changes are appropriately
change to the Carefully manage emergency authorised, documented and revoked after the change has been applied.
business and changes to minimise further  Monitor all emergency changes, and conduct post-implementation reviews involving
mitigation of incidents and make sure the all concerned parties. The review should consider and initiate corrective actions
the risk of change is controlled and takes based on root causes such as problems with business process, application system
negatively place securely. Verify that development and maintenance, development and test environments,
impacting the emergency changes are documentation and manuals, and data integrity.
stability or appropriately assessed and  Define what constitutes an emergency change.
integrity of authorised after the change.
the changed
environment.
Provide the BAI08.03 Organise and  Identify shared attributes and match sources of information, creating relationships
knowledge contextualise information into between information sets (information tagging).
162
COBIT 5 Process description
process
Knowledge reliable knowledge to support all
process activities and to
facilitate decision making. Plan
for the identification, gathering,
organising, maintaining, use and
retirement of knowledge.
DSS04 Establish and maintain a plan to
Manage enable the business and IT to
Continuity respond to incidents and
disruptions in order to continue
operation of critical business
processes and required IT
services and maintain availability
of information at a level
acceptable to the enterprise.
Process COBIT 5 Control Objective Management practice / Risk controls
Purpose
Statement
required to knowledge.  Create views to related data sets, considering stakeholder and organisational
support all requirements.
staff in their Organise information based  Devise and implement a scheme to manage unstructured knowledge not available
work activities upon classification criteria. through formal sources (e.g., expert knowledge).
and for Identify and create meaningful  Publish and make knowledge accessible to relevant stakeholders based on roles and
informed relationships between access mechanisms.
decision information elements
making and and enable use of information.
enhanced Define owners and define and
productivity. implement levels of access to
knowledge resources.
Continue DSS04.07 Manage backup  Backup systems, applications, data and documentation according to a defined
critical arrangements. schedule, considering: •Frequency (monthly, weekly, daily etc.) • Mode of backup
business (e.g., disk mirroring for real-time backups vs. DVD-ROM for long-term retention) •
operations Maintain availability of Type of backup (e.g., full vs. incremental) • Type of media • Automated online
and maintain business critical information. backups • Data types (e.g., voice, optical) • Creation of logs • Critical end-user
availability of computing data (e.g., spreadsheets) • Physical and logical location of data sources •
information at Security and access rights • Encryption.
a level  Ensure that systems, applications, data and documentation maintained or processed
acceptable to by third parties are adequately backed up or otherwise secured. Consider requiring
the enterprise return of backups from third parties. Consider escrow or deposit arrangements.
in the event  Define requirements for onsite and offsite storage of backup data that meet the
of a business requirements. Consider the accessibility required to back up data.
significant  Rollout BCP awareness and training.
disruption.  Periodically test and refresh archived and back up data.
163
Appendix 4: Definition of terms applied

 Critical Actions: Certain transactions or activities in the organization are regarded as “critical” in itself due
to the following:
- the transaction should only be executed by select user(s) who are highly experienced and
knowledgeable around the use of the transaction
- the transaction, if executed inappropriately, would cause a significant (negative) impact to operations.
 Principle of Least Privilege: the concept that system users should have access to only the resources
absolutely necessary to perform their job responsibilities
 (Re)certification – Periodic certification of authorizations by conducting periodic user-access reviews and
ensuring SoD mitigations are effective on a regular basis
 Segregation of Duties (SoD): An internal control that attempts to ensure that no single individual should
have control over two or more conflicting sensitive transactions
 SoD Conflict: the pairing of two conflicting sensitive transactions or business activities
 Sensitive Access: Certain transactions or activities in the organization are regarded as “sensitive” due to
the transaction allowing access to confidential information
 Sensitive Transaction: a business transaction with the potential to impact a company’s financial
statements

164
Appendix 5: SAP GRC AC Business Processes

The content in this section will provide context of the activities that will be executed by various organizational
users in SAP GRC AC on a day-to-day basis. Maintenance and support activities are also covered.

AC Description of Activity Description of activity

module module
Access This section Run Risk  Running analyses of roles and users is the fundamental functionality of ARA and is
Risk describes the Analyses a requirement for various kinds of users. It will be required for security
Analysis authorisation administrators, auditors, business managers, risk owners and process owners to
(ARA) requirements be able to run reports.
for the roles  The purpose of doing so is to monitor on-going compliance to risk policy where
that will on a monthly basis a measurement is taken of compliance. Risk analysis will also
support the be used to pro-actively on an ad-hoc basis so that the most efficient measures are
business taken to avoid risks from being introduced on a day-to-day basis. To this end, the
processes to risk analysis simulation functionality will be used to model outcomes of
be run in ARA. provisioning requests and role development requests ahead of them being
submitted, therefore being able to identify risks before submission and therefore
avoid making such requests that would otherwise have been rejected.
Assign  When a combination of access must be provisioned to a user based on a business
Mitigating requirement that will cause a risk, it will be necessary to mitigate that risk so as
Controls to provide visibility of any negative event that may arise due to the access having
been provided.
 There are several streams to the end-to-end process of mitigation. This particular
process is concerned with the online activity within ARA whereby a risk owner is
accepting that the access can be provided to a user based on the fact that a
control is run that would identify any negative event.
 When conflicting access has to be given, it will only be given where there is a
relevant control in place to mitigate the risk. When conflicting access has been
given, SAP GRC AC needs to know whether a valid mitigation is in place or not.
The risk owner will therefore assign a relevant mitigation to the user when the
access is provisioned.
 The reason for this is that when risk analysis reports are run, SAP GRC AC will
report whether a risk is mitigated or unmitigated. As a principle, there should be
no unmitigated risks because these risks (for which there is no identified control
for that user) are potentially ‘under the radar’ as a negative event is likely to go
undetected.
Mitigating  ARA will utilise a stock of mitigating controls to mitigate all the company’s SoD
Control risks but these may need to change over time, for instance a control may need to
Maintenance be updated or even replaced over time when a brand new control would be
required. Another element of this is the mapping in GRC of the relationship
between risks and controls, i.e. mapping which risks are mitigated by a particular
control.
 More common maintenance will involve amending control owners and monitors
as the business users that fulfil these roles change over time.
Approve After a new mitigating control is created, it will be routed via workflow to a relevant
Mitigating control approver to approve the creation of the new control.
Control
Ruleset  The project will deliver a SoD and critical transaction ruleset that contains a
Maintenance company’s definition of SoD and critical risks. The ruleset will evolve over time as
the organisation changes and indeed as control requirements change.
 The designated administrator will need to be able to create new rulesets and
amend the delivered ruleset. They will also need to be able to create new risks
and amend existing risks (change risk criticality, descriptions, amend the
conflicting functions and also generate rules). They shall also need to create new
functions and amend existing functions. This may involve adding (e.g. a new
custom transaction) or removing transactions from functions as well as adjusting
the permission settings in functions so that they reflect the authorisations users
need to execute transactions.
 Changes to rulesets, risks and functions are protected by approval workflows
(SAP_GRAC_FUNC_APPR and SAP_GRAC_RISK_APPR). Therefore, what the

165
AC Description of Activity Description of activity
module module
administrator is actually doing when they undertake maintenance is making a
proposal for a change. The change is not actually committed until approved.
 As SAP best practice to maintaining the version integrity of the ruleset; the
rulesets should be maintained within the GRC Development system alone and
then transport the approved changes through to the rest of the GRC landscape.
Therefore the ruleset maintenance access privileges should only be granted for
active use within the GRC Development system.
Approve All changes made to the constituent parts of the ruleset will need to be approved
Ruleset, Risk before they are productive. Workflow will route the change to the appropriate
and Function approver.
Changes
Emer- This section Log-on to EAM Users that are authorised to log-on to ECC with enhanced access for emergency
gency describes the as a FireFighter situations will log-on to the GRC production system and go to the EAM cockpit
Access authorisation where they select the FireFighter ID that they need to log-on with. EAM then logs
Manage requirements the user onto the target system with the enhanced access and the application logs
-ment for the roles all their transaction starts and data updates.
(EAM) that will Assign This process maps ECC users to FireFighter ID’s which essentially authorises an
support the FireFighter ID’s individual to use a particular FireFighter ID (although the individual does also need
business to Users to have access to the EAM role above in order to be able to use the functionality).
processes to This process will be automated via the ARM module whereby the request to assign
be run in a FireFighter ID to a user is initiated in a provisioning request.
EAM. In the advent of the workflow not being available, the GRC Administrator can
manually assign users to FF ID via the role.
Provision FF The FF ID’s are to be provisioned via the ARM module as a “New User” request
ID’s type. As the user type would be selected as “Service”, the workflow will send the
request to the GRC Security Administrator/s to approve. The roles requested to be
assigned to the FF ID shall be approved by their respective Owner/s. It should be
noted that the administrator will still require changing the ‘Initial password’ of the
FFID prior to mapping the owners and controllers.
Mapping owner There are two elements to providing authorisation for EAM owners and controllers.
and controller The first is their ABAP role authorisation, which is provided via a standard
privileges provisioning request. The second is that the user who will fulfil the role of an owner
or controller also needs to be mapped in a table in GRC to the relevant FireFighter
ID’s for which they will assume the role of owner or controller. The EAM
administrator will be responsible for doing the latter element of this.
Log review and Again, this process is driven by workflow in SAP GRC AC. Each time a user logs on
approval with a FireFighter ID, EAM logs the activity of the user whilst logged on with
process enhanced access. Logs are then generated that detail this usage. Workflow will
route the logs automatically to the relevant owner or controller for review. The
owner or controller must then review the log and determine if usage was
appropriate and challenge any usage they feel was unjustified or outside of the
scope of what the user should have been doing at that time. Once they are happy
with the content of the log, they must approve it within EAM thus completing the
audit trail which proves that appropriate control has been exerted over the
enhanced access process.
Maintenance of This will be a process that is seldom run but should be noted. Each time a user logs
Reason Codes on with a FireFighter ID, they are mandated to select a ‘reason code’ that describes
why they are logging on with a FireFighter ID. The reason selected is then used by
the owner/controller as part of their log review to ascertain whether usage was
appropriate.
The SAP GRC AC implementation project will deliver a set of reason codes which are
expected to stay static. If a new reason code is required in future, the EAM
administrator would be responsible for creating it.
Access This section Raise a Request Business users that have authorisation to create provisioning requests in the ARM
Request describes the application are known as requestors. They create online requests for access for
Manage authorisation themselves or other users by selecting the access (roles) that the user needs in
ment requirements order to fulfil their requirements. The requestor submits the request online and
(ARM) for the roles workflow then routes it to the appropriate approver(s) based on the contents of the
that will request.
support the

166
 AC Description of Activity Description of activity
module module
business Amend a Requestors may also be required to amend requests that they have already
processes to Request submitted. This may be due to additional or changed requirements or due to a
be run in ARM compliance issue with the request when the combination of roles was SoD checked.
Approve,  A provisioning request submitted by a requestor is routed to the relevant
Reject, Hold or approver(s) by workflow. The approver logs onto the ARM application to review
Forward a the request and approve the parts of the request that relate to themselves. There
Request are multiple approval steps in the approval workflow. Each approver is notified by
e-mail at the particular time that their approval is required. The approver may be
required to approve the whole request or just subsets of it, depending on the
content of the request.
 The approver can also reject the constituent parts of a request that relate to
themselves if it is not correct or deemed appropriate. ARM also allows the
approver to hold a request so that it can be seen in reporting that the request has
not been forgotten about. The approver can also forward the request to another
person for approval if deemed appropriate.
Perform Risk In a SoD compliant environment, it is important that SoD analysis is performed for
Analysis each provisioning request so as to determine if a request will introduce risks into
the production environment, The project will be delivering an enhanced
provisioning process so that an enforced SoD check is built into the provisioning
process. It will also be possible for requestors and approvers to run a risk analysis at
any time on a request thus being able to validate if a request will be compliant.
Maintenance of These settings determine the behaviour of the system according to business
Access Control requirements. Changes may be needed in future but not frequently. Changes would
Configuration be made in the development system and transported through the landscape. Such
Settings changes would be made by the GRC administrator.

Maintain Provisioning workflows may need to be changed in future to account for new
MSMP137 business or control requirements. Such changes would be made by the SAP GRC AC
Workflow administrator. Examples of changes that may be required would include updates to
the routing of requests, additional approval steps or brand new workflows for new
types of provisioning request.
Maintain BRF+ Various custom rules to determine the approval agents will be created and aligned
rules to the GRC workflows using BRF+138. The GRC administrator will require the ability
to maintain the ‘Decision tables’ that hold the specific rules. Examples of changes
that may be required would include replacing the approver for a certain user group
or location, adding additional rules to cater for new user groups etc. It should be
noted that changes to rules will take place in the GRC Development system and
then be transported through the GRC landscape.
Define Request This activity covers the creation of new provisioning request types. When a
Types requestor creates a provisioning request, they are required to specify what type of
request they wish to create (e.g. joiner, mover or FireFighter ID) so that ARM can
build and route the request appropriately to the request type. This will not be done
that often but may be required in future, especially if an organization extends its
use of ARM to other systems. It should be noted that changes to rules will take
place in the GRC Development system and then be transported through the GRC
landscape.
Maintain Priority types can be set against a request enabling the GRC administrator to track
Priority the progress of requests which require to be dealt with within a day (for example).
Configuration It is unlikely new priority types will be required in the future, but should an
organization need to define further priority values, the GRC Administrator can set
them in SPRO139 on the GRC system. It should be noted that the changes to the

137
SAP GRC 10.0 introduced concept of Multi Step Multi Process (MSMP) workflow engine as a configurable layer that sits
on top of SAP Standard Workflow for Access Controls. This provides flexibility to enable a single request to be split and
routed to different approvers in parallel as well as multiple approval steps depending on business requirements.
138
Business Rule Frame work Plus (BRF+) provides Application Programming Interface (API) and User Interface (UI) for
defining and processing business rules.
139
SPRO is a standard SAP transaction and stands for SAP PROJECT REFERENCE OBJECT. It is used to configure the system
settings based on client requirements. It is primarily used to set values and settings before implementation. It has range of
functional areas and many settings that can be changed.

167
AC Description of Activity Description of activity
module module
rules needs to take place within the GRC Development system and then be
transported through the GRC landscape.
Define Within an access request, a list of available employment types such as full time, part
Employee time, will appear in a dropdown list.
Types It is unlikely that additional Employee types are required in the near future, but the
GRC administrator can amend the entries in SPRO.
It should be noted that such a change would take place within the GRC
Development system and then be transported through the GRC landscape.
Maintain End The GRC Administrator can set the parameters that define the behaviour of the
User fields and the pushbuttons on the Request Access screen. By default, the standard
Personalisation SAP End User Personalisation (EUP) form shall be called within each access request
(EUP) Forms screen, but it is possible to assign a specific EUP form to a specific request type
stage within a workflow. If a specific form is created by the administrator, they also
need to amend the specific workflow stage configuration within MSMP to align with
the new specific EUP form ID. It should be noted that the changes to the rules
would take place within the GRC Development system and then be transported
through the landscape.
Maintain User Managing user defaults allows data fields to be linked that are automatically set for
Defaults newly created users. After user defaults are configured, the data is transferred to
the SAP backend system (SU01) as defaults. In the scenario of adding additional
systems for user provisioning from the GRC system, new user defaults can be
configured by the GRC Administrator within SPRO. Existing setting values can also
be amended by the administrator i.e. Change of Time Zone, additional Parameters
etc. In the scenario of adding new User Defaults for additional systems; the GRC
Administrator will also need to update the Decision table within the BRF+ rule for
the User Default mappings.
Business This section Maintain The Business Process/Sub Processes are shared with the ARA rule set. These will be
Role describes the Business maintained within the SPRO configuration menu of the GRC system. A Business
Manage authorisation Process/Sub Process and Sub Process need to be defined for a role for use within GRC. This task
-ment requirements Process is to be performed by the GRC administrator.
(BRM) for the roles
that will Maintenance of These settings determine the behaviour of the system according to business
support the Access Control requirements. Changes may be needed in future but not frequently. Changes would
business Configuration be made in the development system and transported through the landscape. Such
processes to Settings changes would be made by the GRC administrator.
be run in Maintain The Role Approval workflow may need to be changed in future to account for new
BRM. MSMP business or control requirements. Such changes would be made by the GRC
Workflow administrator. Examples of changes that may be required would include updates to
the routing of role approval requests (if the role owner is not to approve the
requests) or additional approval steps. As Best Practice, it is advised to maintain the
workflows within the GRC Development system and transport the changes across
the rest of the GRC landscape.
Maintain BRF+ A Custom rule to determine the Role Build Methodology to apply will be created.
rules The GRC administrator will require the ability to maintain the ‘Decision tables’ that
hold the specific rules and Condition group values, should any new methodology be
introduced for role build. It should be noted that changes to the rules will take
place within the GRC Development system and then be transported through the
GRC landscape.
Maintain Role The Role types, along with role name lengths need to be maintained within BRM.
Type The GRC Administrator will only require to amend Role Type entries in the example
of a new application type (i.e. non SAP systems) being introduced to the GRC
landscape for Role Build and Provisioning purposes
Role Naming The role naming convention needs to be defined and maintained for each role type
Convention being built per system landscape (SAP, Others, etc).
Should the naming convention for new roles being built be modified in the future,
the GRC Administrator will define the new naming convention from SPRO.
Define Different roles can be attributed to specific companies, making it easier to search
Companies for roles and drive the request through the workflow.
Maintain Functional Areas form an integral part of the BRM and ARM solutions. Functional
Functional Areas are assigned to the role definitions in BRM to support the routing of requests
Areas and identification of the correct approvers for certain custom approval agents in

168
AC Description of Activity Description of activity
module module
ARM. It is anticipated that these values will require on-going maintenance due to
the ever-changing nature of the business. The GRC Administrator will need to
maintain the entries on a regular basis via SPRO, with the additional requirement of
maintaining the Custom Agent rules in BRF+ in relation to Approval Agents being
determined by the Functional Areas.
Define This configuration will need to be updated should new prerequisite types be
Prerequisite needed for use in defining specific role prerequisites. By default, the values
Type “Certification”, “NDA” and “Training” should be sufficient enough, but the GRC
Administrator will be able to add/amend the entries available for assignment.
Define Role Roles can be assigned certain prerequisites which are validated against the user
Prerequisite prior to the role being provisioned, ensuring they are qualified to get access to the
role. The GRC Administrator can maintain the list of courses or certifications to
assign against role definitions in BRM. With new qualifications, courses or NDA’s
being introduced within an industry or organisation, it is likely that the available
prerequisites will require additions over time. Such a task is to be performed by the
GRC Administrator within SPRO.
Role Build The following steps represent the various parts of the Role Methodology:
Methodology • Create a Role /Change Role attributes (Define step)
• Add/amend Authorisations (Actions and Permissions i.e. PFCG)
• Perform Risk Analysis on a Role
• Derive a Single Role
• Approve a Role
• Generate a role
It should be noted that the role builder wishing to add/amend the actions and
permissions within the role requires an active SAP account in the target build
system with valid access to use transaction PFCG. The Role Approver, whilst being
defined by the role builder within the “Define” step of the methodology, needs to
be a valid entry within the “AC Owner” table within the GRC front end.

169