SoD Documentation
Responsibility for Contents:
SoD Coreteam (C. Twehues)
Classification:
Internal
Version:
Version 1.93
Subject and Purposes
This document describes the operational concept of the implementation of
Segregation of Duties (SoD) at Henkel.
Distributed by:
20130923 SoD Documentation v1.93.doc
Project SIGMA
Pages : 111
Enclosures : 5
SoD Documentation
Content
1
Management Summary ........................................................................................... 6
1.1 Scope and Target Group of Current Document ............................................... 6
1.2 Definition Segregation of Duties (SoD) ............................................................ 6
1.3 Scope of SoD .................................................................................................. 6
1.4 Definition Identity & Access Management (IAM) ............................................. 6
1.5 Scope of IAM ................................................................................................... 6
1.6 Definition Authorization Concept ..................................................................... 7
2
General Terms ......................................................................................................... 8
2.1 User ................................................................................................................. 8
2.2 User-ID ............................................................................................................ 8
2.3 Access Rights .................................................................................................. 8
2.4 Authorizations .................................................................................................. 8
2.5 Enterprise Roles .............................................................................................. 8
2.6 Business Roles ................................................................................................ 8
2.7 Transaction ...................................................................................................... 8
2.8 Technical Authorization Objects ...................................................................... 9
2.9 SoD Risk ......................................................................................................... 9
2.10 SoD Risk Levels (Colour Coding) .................................................................. 10
2.11 SoD Conflict .................................................................................................. 10
2.12 Dangerous Combinations of Roles ................................................................ 10
2.13 Critical Transactions ...................................................................................... 11
2.14 Critical Roles ................................................................................................. 11
2.15 Need-to-Know Principle ................................................................................. 11
2.16 Preventive Controls ....................................................................................... 11
2.16.1 Segregation of Duties Controls ........................................................................................ 11
2.16.2 Built-In Controls ............................................................................................................... 11
2.17 Detective Controls ......................................................................................... 12
2.17.1 Compensating Controls ................................................................................................... 12
2.18 Privileged Authorizations ............................................................................... 12
2.19 Explanation of Process Flows (Swim Lane Charts) ....................................... 12
3
Roles & Responsibilities ...................................................................................... 14
3.1 HR ................................................................................................................. 14
3.2 Employee ...................................................................................................... 14
3.3 Supervisor of Employee ................................................................................ 14
3.4 Contractor...................................................................................................... 14
3.5 External Company ......................................................................................... 14
3.6 Person In Charge .......................................................................................... 14
3.7 Supervisor of Person In Charge .................................................................... 14
3.8 IT Coordinator................................................................................................ 15
Page 2 of 111
Version 1.93
Classification: internal
SoD Documentation
3.9
3.10
3.11
3.12
3.13
3.14
User Administrator ......................................................................................... 15
Help Desk ...................................................................................................... 15
SoD Council .................................................................................................. 15
SoD Compliance Manager ............................................................................ 15
Business Process Owner .............................................................................. 15
Role Owner ................................................................................................... 16
3.14.1 Tasks of the Global Role Owner ...................................................................................... 16
3.14.2 Tasks of the Local Role Owner ........................................................................................ 16
3.15 Role Administrator (Role Admin) ................................................................... 16
3.15.1 Tasks of the Role Admin (SPOC) .................................................................................... 16
3.15.2 Tasks of the Role Admin (Assignment Approver) ............................................................ 16
4
Identity & Access Management Processes ......................................................... 17
4.1 User ID Administration ................................................................................... 17
4.1.1
4.1.2
4.1.3
4.2
User Authorization Administration ................................................................. 26
4.2.1
4.2.2
4.2.3
4.2.4
4.3
Define Role Owner (IAM-400) ......................................................................................... 38
Define Role Administrator (IAM-401) ............................................................................... 39
Review Role Ownership (IAM-410) ................................................................................. 39
Review Role Administrators (IAM-411)............................................................................ 40
Compliance Controls User Authorization Ownership ...................................................... 40
SoD Compliance Control ............................................................................... 41
4.5.1
4.5.2
4.5.3
4.5.4
4.6
Create Role (IAM-300) ..................................................................................................... 32
Change Role (IAM-301) ................................................................................................... 33
Delete Role (IAM-302) ..................................................................................................... 33
Pre-Authorized Role Change (IAM-303) .......................................................................... 34
Review Obsolete Roles (IAM-310) .................................................................................. 35
Compliance Controls User Authorization Configuration .................................................. 35
User Authorization Ownership ....................................................................... 38
4.4.1
4.4.2
4.4.3
4.4.4
4.4.5
4.5
Assign Roles (IAM-200) ................................................................................................... 26
Remove Roles (IAM-201): Overview ............................................................................... 28
Reapply Role Assignment (IAM-210) .............................................................................. 29
Compliance Controls User Authorization Administration ................................................. 30
User Authorization Configuration ................................................................... 32
4.3.1
4.3.2
4.3.3
4.3.4
4.3.5
4.3.6
4.4
HR Processes Joiner - Mover – Leaver .......................................................................... 17
User ID processes ........................................................................................................... 20
Compliance Controls........................................................................................................ 24
Check Compensating Control (IAM-500) ......................................................................... 41
Approve SoD Exception (IAM-501) .................................................................................. 42
Review SoD Exceptions (IAM-510) ................................................................................. 42
Compliance Controls........................................................................................................ 42
SoD Framework Governance ........................................................................ 43
4.6.1
4.6.2
4.6.3
4.6.4
4.6.5
Review Corporate Standard SoD (IAM-600) ................................................................... 43
Review SoD-relevant Transaction Directory (IAM-601)................................................... 44
Review SoD Permission Directory (IAM-602) .................................................................. 44
Reconciliation of SAP GRC Rule Sets (IAM-603) ........................................................... 45
Define Compensating Controls (IAM-604) ....................................................................... 45
Classification: internal
Version 1.93
Page 3 of 111
SoD Documentation
4.6.6
5
SoD Governance ................................................................................................... 47
5.1 Elements and Structure of the SoD Framework at Henkel ............................ 47
5.1.1
5.1.2
5.1.3
5.2
5.3
SoD Framework ............................................................................................................... 47
SoD Tools ........................................................................................................................ 48
SoD KPI and Reporting.................................................................................................... 48
Naming Conventions of the SoD Framework at Henkel ................................ 48
5.2.1
5.2.2
5.2.3
5.2.4
Rule Sets ......................................................................................................................... 48
Access Risks .................................................................................................................... 49
Functions ......................................................................................................................... 49
Risk Descriptions ............................................................................................................. 50
Governance of the SoD Framework .............................................................. 51
5.3.1
5.3.2
5.3.3
5.3.4
5.3.5
6
Compliance Controls SoD Framework Governance ........................................................ 46
Governance Bodies ......................................................................................................... 51
Corporate Standard Segregation of Duties (CS SoD) ..................................................... 51
SoD Relevant Transaction Directory ............................................................................... 52
SoD Permission Directory ................................................................................................ 52
SAP GRC AC Rule sets ................................................................................................... 53
Authorization Concept (TO BE REVIEWED) ....................................................... 57
6.1 Requirements of Authorization Concept ........................................................ 57
6.1.1
6.1.2
6.2
6.3
General Requirements ..................................................................................................... 57
Technical Requirements .................................................................................................. 58
Dependencies to other Processes ................................................................. 58
Technical Authorization Concept ................................................................... 58
6.3.1 Definition of Terms ........................................................................................................... 58
6.3.2 Background Information ................................................................................................... 59
6.3.3 General Structure of Authorization Concept .................................................................... 60
6.3.4 Domains and their usage ................................................................................................. 63
6.3.5 Naming Convention ......................................................................................................... 68
6.3.6 Future mode of operation and maintenance .................................................................... 71
6.3.7 SU24 ................................................................................................................................ 76
6.3.8 Customer specific authorization objects .......................................................................... 77
6.3.9 Authorization Groups ....................................................................................................... 77
6.3.10 Further Restrictions .......................................................................................................... 78
6.3.11 Current Business Roles ................................................................................................... 78
6.3.12 Emergency procedure : Quickfixes .................................................................................. 80
7
Software (TO BE UPDATED) ................................................................................ 83
7.1 Overview of SoD Tool Landscape ................................................................. 83
7.2 Tools.............................................................................................................. 84
7.2.1
7.2.2
7.2.3
7.2.4
7.3
SAP GR AC – Access Control ......................................................................................... 84
COCOS – Compensating Control System ....................................................................... 85
BIC – SAP ERP Built-in Controls ..................................................................................... 87
RAP – Reapply Roles ...................................................................................................... 87
Operational Model ......................................................................................... 89
7.3.1
Page 4 of 111
Tool Ownership ................................................................................................................ 89
Version 1.93
Classification: internal
SoD Documentation
7.3.2
7.3.3
8
Reporting & KPI ..................................................................................................... 90
8.1 Global SoD Anaylsis (GSODA) ..................................................................... 90
8.1.1
8.1.2
8.2
KPI definition .................................................................................................................... 90
Scope ............................................................................................................................... 90
System SoD Analysis (SSODA) .................................................................... 91
8.2.1
8.2.2
9
Incident Management Regulations .................................................................................. 89
Change Management Regulations .................................................................................. 89
KPI definition .................................................................................................................... 91
Scope ............................................................................................................................... 91
Training & e-Learning ........................................................................................... 93
9.1 SoD Portal Page ............................................................................................ 93
9.2 SoD Forum .................................................................................................... 93
9.3 Training ......................................................................................................... 94
9.3.1
9.3.2
9.3.3
CUP tool ........................................................................................................................... 94
RAR tool ........................................................................................................................... 94
COCOS tool ..................................................................................................................... 95
10 Appendix ................................................................................................................ 96
10.1 FAQ ............................................................................................................... 96
10.2 Glossary ........................................................................................................ 96
10.3 Acronyms .................................................................................................... 101
10.4 Enclosures ................................................................................................... 105
10.4.1 SoD Governance ........................................................................................................... 105
10.4.2 Authorization Management ............................................................................................ 107
10.5 Revision History and Document Reviews .................................................... 108
Classification: internal
Version 1.93
Page 5 of 111
SoD Documentation
1
Management Summary
1.1 Scope and Target Group of Current Document
This document describes the operational model of the processes, tools, and the governance of the
Segregation of Duties concept at Henkel.
Target Group of this document is
-
The maintenance and enhancement team in IT
-
Future projects like Horizon and others that implement changes in the SoD relevant business
processes
1.2 Definition Segregation of Duties (SoD)
Segregation of duties (SoD) is the concept of having more than one person required to complete a task.
Besides organizational measures this includes the segregation of access rights to and authorizations
within the corresponding IT systems.
The SoD Framework is a set of rules that defines which combinations of functions have to be segregated
in a business process in order to mitigate the risk of fraud and erroneous transactions.
1.3 Scope of SoD
The present SoD framework focuses on the business processes Order-to-Cash (OTC) and Purchase-toPay (PTP). The SoD framework was defined independent of the underlying IT systems and has a global
scope.
1.4 Definition Identity & Access Management (IAM)
IAM is an administrative area that deals with identifying individuals in a system (such as a country, a
network or an organization) and controlling the access to resources in that system by placing restrictions
on the established identities.
1.5 Scope of IAM
IAM in the context of this document is limited to controlling the access to and authorization within IT
Systems.
The Scope of IAM is global.
IAM at Henkel consists of three main areas:

Identity Management (IdM):
Definition: Process and tool landscape for managing the lifecycle of user-IDs and their relationship
to persons.
Services: User administration, IAM Request Mgmt, IAM-Reports

Authorization Management:
Definition: Management of compliant authorizations of users within IT systems, e.g. SAP.
Services: SAP Authorizations, Emergency Procedures, IT-based non-SAP Authorizations
Page 6 of 111
Version 1.93
Classification: internal
SoD Documentation

Compliance Control:
Definition: Monitoring of compliance to external and internal regulations in the use of IT systems
Services: Compliance Checks & Reports, Support of VIA and external Audit, Compliance
awareness, Compensating Control Setup
1.6 Definition Authorization Concept
The Authorization Concept describes the structure and design of authorizations to users. An authorization
concept is defined in Enterprise Roles and Business Roles in business terms, as well as a translation into
technical terms, i.e. transactions and authorization objects within an IT system (Technical Authorization
Concept).
Classification: internal
Version 1.93
Page 7 of 111
SoD Documentation
2
General Terms
2.1 User
A user is a person in a company that uses an IT system.
2.2 User-ID
A user-ID (also called user account) identifies a user (employee or Contractor) within the company by the
username. It allows one to authenticate to IT systems. It also generally provides one with the opportunity
to be authorized to access them.
2.3 Access Rights
A user needs a user-ID and a password, and access rights assigned to the user-ID to be able to enter IT
systems or applications. This authentication does not automatically imply authorization within the IT
system. It’s like the “key to the main entrance of a building”.
2.4 Authorizations
Authorizations (also privileges, entitlements, permissions) determine what a user can do on the system,
once authenticated with user-ID and password. Authorizations enable users to use certain functionality or
to display information of the IT system. Authorizations are like “keys to doors within a building”.
2.5 Enterprise Roles
Enterprise Roles define access rights and authorizations within the entire enterprise, i.e. across IT
systems and applications.
2.6 Business Roles
Business Roles (or Roles in this context) define groups of authorizations within an IT system in business
terms. Roles contain the authorizations that a user needs to work. Role Administrators grant
authorizations to employees or external staff (users) by assigning specific Roles to their user-IDs.
2.7 Transaction
A transaction in SAP is like a program in normal computer languages, and is identified by a four-character
transaction code. A transaction can be initiated directly from the command field on the presentation
interface or from the corresponding menu option. There are two kinds of transactions: report and dialog
transactions.
-
Report transactions are SAP programs that collect selection parameters from the selection screen
followed by the output called the lists.
-
Dialog programs consist of more than one interactive screen called a dynpro. These transactions
sometimes also need pre-selected information for triggering them, not unlike the explicit selection
screens in report programs; these are called parameter transactions.
Page 8 of 111
Version 1.93
Classification: internal
SoD Documentation
2.8 Technical Authorization Objects
Technical Authorization Objects define authorizations to technical objects within an IT system. These
objects can be e.g. SAP tables, plants, sales organization, etc. With the help of Technical Authorizations
Objects user access can be restricted to a limited organizational area of responsibility.
The functional area
of responsibility
described in four layers:
Role
BuildingisPrinciple
Σ Business Roles
Profile
e.g. Customer Service
Business Roles
e.g. Order Management
Function
e.g. Display Master Data,
Sales Doc Processing,
Delivery Processing
Transactions
e.g. BU01, BU05, BU06, etc.
Henkel / Project SIGMA
15-Apr-2010
2
The four layers are:
1. Transactions: SAP standard and Z-transactions
2. Function: Transactions grouped together with restrictions (org. limitations…)
3. Business Roles: Functions grouped together
4. Profile: Business roles grouped together
SAP Profile: not shown in the above picture, i.e. the technical implementation of a Function.
2.9 SoD Risk
The SoD Framework (see chapter 10.4: “Enclosures”) defines combinations of duties as “High” or “Very
High” risk. These potential combinations are called SoD Risks. The combinations are marked in the SoD
matrix as “High” or “Very High” and are described in the SoD Risk Register with examples.
Classification: internal
Version 1.93
Page 9 of 111
SoD Documentation
2.10 SoD Risk Levels (Colour Coding)
The SoD Framework classifies the risks due to missing SoD in four categories: Red, Orange, Yellow, and
Green.:
Color Code
Risk rating
Green
No risk in the defined sense of SoD,
i.e. no damage/loss possible
Control requirements
for mitigation of SoD risks
Control requirement for
mitigation of risks due to
Critical Functions
No controls required
No controls required
Yellow
Low risk,
i.e. damage/loss is unlikely to happen
and would only be immaterial
No controls required
No controls required
Orange
High risk,
i.e. damage/loss is reasonably possible
to happen and would result in a
material impact
Either SoD or Compensating
Controls required
Compensating Control
mandatory
Red
Very High risk,
i.e. damage/loss would be probable to
happen and could result in a material or
even severe impact
SoD mandatory
The Critical Function must
only be executed by
dedicated and named
personnel; Compensating
Control mandatory
2.11 SoD Conflict
A SoD conflict occurs, when a user actually has the authorization to conduct a combination of duties in a
business process that is defined as a high or very high SoD Risk in the SoD Framework.
Depending on the risk rating, SoD Conflicts can be neglected (low risk), or require approval (high risk,
controlled with a Compensating Control). In case of very high risk, SoD conflicts are not allowed; the
duties have to be segregated.
2.12 Dangerous Combinations of Roles
The Authorization Concept uses Roles which group authorizations a user needs to execute business
functions in an IT system. Objective is to ease the assignment of authorizations to users, but also to
ensure that every user has exactly the authorizations he/she needs to perform business functions in a
compliant way.
Roles are designed not to have a SoD conflict within the role itself. I.e. every user with one role assigned
shall be free of SoD conflicts. Only with the assignment of two or more roles to a user, a SoD conflict
might occur.
There exist pairs of Roles that contain duties that are marked as a SoD risk in the SoD framework. With
the assignment of both Roles to a user, a SoD conflict occurs. The combination of these Roles is called a
Dangerous Combination.
Page 10 of 111
Version 1.93
Classification: internal
SoD Documentation
Example: Role “Procurement” and Role “Warehouse” are in itself free of SoD risks. The role
“Procurement” contains among others the function “create purchase order” and the role “Warehouse”
contains among others the function “book goods receipt”. The combination of these functions (“create
purchase order” and “book goods receipt”) is a SoD risk identified in the SoD matrix. Thus assigning the
two roles “Procurement” and “Warehouse” to a single user within the same organizational unit would lead
to a SoD conflict. I.e. “Procurement” and “Warehouse” are a Dangerous Combination of Roles.
2.13 Critical Transactions
Some single transactions have an inherent risk and are defined as critical transactions. Examples:
-
Technical transaction: Debugging with replace (prohibited by IT Security Policy in all cases)
-
Business transaction: Release of vendor payment block (only assigned to a limited number of well
instructed users)
2.14 Critical Roles
Some Roles might be critical in itself. Reasons might be:
-
Role that bear a SoD conflict in itself (defined exceptions)
-
Privileged authorizations for e.g. process owner, key user, etc
-
Collection of critical transactions in a critical role to control their assignment to users
2.15 Need-to-Know Principle
The Need-to-Know Principle (also known as least user access, least-privilege, or least authority)
describes a security concept, in which all users at all times should run with as few authorizations as
possible, and also launch applications with as few access rights as possible.
The principle is widely recognized as an important design consideration in enhancing the protection of
data and functionality from faults (fault tolerance) and malicious behavior (computer security).
2.16 Preventive Controls
2.16.1 Segregation of Duties Controls
The segregation of areas of responsibility in business processes and of corresponding authorizations,
access rights, and built-in system behavior within the IT systems is called SoD Control. This is a
preventive control against SoD-risks.
2.16.2 Built-In Controls
A Built-in Control is a system behavior that prevents a user to conduct two functions that are defined as a
SoD risk. This control is a Segregation of Duties, when certified as “proven security”.
Example: A user has the authorization to create a purchase order and to book a goods receipt against
purchase orders. A built-in control could be a user exit in SAP that blocks a user from booking a goods
receipt against purchase orders, the user created him/herself. If it is proven that no user can by-pass the
Built-In Control, this control is a valid Segregation of Duties.
Classification: internal
Version 1.93
Page 11 of 111
SoD Documentation
2.17 Detective Controls
2.17.1 Compensating Controls
Compensating Controls are controls which compensate for missing segregations of duties (i.e. for
approved SoD conflicts).
These can be:
-
Ex-ante controls that prevent fraud e.g. “2-pairs-of-eyes”-principle at credit note processing.
-
Ex-post controls that allow detecting if unwanted events of SoD risks have occurred. Where
automated systems provide basis information for detective controls, manual monitoring processes
are required for review of this information.
Example: An exception report is regularly provided by IT-application and lists the actual bookings
by users with SoD-conflicts; the manager in charge is required to review this report timely and to
sign-off the listed transactions retrospectively.
2.18 Privileged Authorizations
Some users need access rights and authorizations beyond the usual scope or beyond the profile of the
employee, in order to support others or other topics. Examples can be a Key User, a Business Process
Owner, a temporary project member, etc.
The Privileged Authorizations assigned in these cases require a special handling and controls beyond the
usual control.
3
Remark: out of scope of project SIGMA. That means, until exceptional processes and/or controls are
listed, privileged users are treated like regular users.
Select Role (IAM-201)
Information
Technology
2.19 Explanation of Process Flows (Swim Lane Charts)
Requester has to be supported to find the right Role.
Example: Process “Select Roles” (IAM-201)
Supervisor
of Employee
/
Internal
Responsible
Person
START
Select
Role Administrator
from Directory
Request Form
plus free text
Info
Employee
/
External
Person
(User)
Yes, from same
Role Administrator
Role Administrator
selects Role
Role
Administrator
Further
Role
necessary ?
No
ROLE SELECTED
Yes, from different
Role Administrator
Select Role
(IAM-201)
Henkel / Project SIGMA / IAM Process Design
Page 12 of 111
Version 1.93
16-Aug-2010
17
Classification: internal
SoD Documentation
Legend
Process starter and terminator
START
Process flow
Select
Role Administrator
from Directory
Further
Role
necessary ?
Process step
Decision
Info
Document (e.g. mail)
Select Role
(2.1.3)
Pre-defined process
OUT
IN
Except
ion
Handli
OR
ng
Connector for process flows across more than one document page
Manual process
Logical OR
Split into parallel processes
Join of parallel processes
Role
Administrator
Responsible person for the process step (swim lane)
Classification: internal
Version 1.93
Page 13 of 111
SoD Documentation
3
Roles & Responsibilities
3.1 HR
The HR department is responsible for all processes concerning the joining, moving or leaving of an
employee within the Henkel organization. All employee master data is stored in the central GHR system.
However, not in all cases HR is the starting point of IAM processes. In a lot of cases request for changes
in access rights and authorizations are triggered from within the business organization.
The lifecycle of Contractors at Henkel is out of scope of HR and covered by special IAM processes.
3.2 Employee
A person who is hired to provide services to a company on a regular basis in exchange for compensation
(contract of service employer/employee) and who does not provide these services as part of an
independent business (contract for services employer/independent External Company).
3.3 Supervisor of Employee
A Supervisor is the line manager of an employee (solid line) and responsible for the delegation of tasks to
an employee. In this context the Supervisor is responsible to grant compliant access rights and
authorizations to an employee (user). The Supervisor usually delegates this task to a Role Administrator.
The Supervisor approves exceptions in case of SoD conflicts. If a Compensating Control is defined (e.g.
an exceptions report that lists the actual transactions of a user with SoD-conflicts) the Supervisor has the
responsibility to review and to sign off the listed transactions retrospectively. He/she might delegate this
task.
3.4 Contractor
A Contractor is a person who provides services to Henkel as part of an independent business
(independent External Company).
3.5 External Company
The company, the Contractor is working for.
3.6 Person In Charge
By definition a Contractor does not have a line manager within Henkel. This role is taken over by a so
called Person In Charge. Main tasks are the request of a user-ID and according authorizations for the
Contractor.
3.7 Supervisor of Person In Charge
The line manager of the Henkel-internal person who is responsible for a Contractor. Usually the Person In
Charge approves assignments of access rights and authorizations to the Contractor, but in some cases
Page 14 of 111
Version 1.93
Classification: internal
SoD Documentation
his/her Supervisor is required for a second approval.
3.8 IT Coordinator
The IT Coordinator is a member of the business organization who supports employees in coordinating
service requests (hardware, software procurement and installation). Often the request for user-IDs and
access to systems goes along with these service requests and is managed by the IT Coordinator as well.
3.9 User Administrator
The User Administrator is a member of the IT service unit User Admin. The User Administrator is
responsible for managing the lifecycle of user-IDs. The User Administrator configures the Identity
Management tools, processes requests for user-ID and role assignments, and runs periodic reviews of
User ID validities.
3.10 Help Desk
A help desk is an information and assistance resource that troubleshoots problems with computers or
similar products.
In the context of IAM the Help Desk is enabled to reset passwords within the password handling process.
3.11 SoD Council
The SoD Council is the owner of the SoD Framework. Members are the global Business Process Owner.
Chairman is the SoD Compliance Manager. The SoD Council approves changes to the SoD Framework,
steers the implementation of SoD within the business processes, and serves as the escalation body when
it comes to conflicts between business process efficiency and compliance objectives. The SoD Council
meets on a quarterly basis. Periodic releases of the Corporate Standard SoD require approval of the
Compliance & Risk Committee.
3.12 SoD Compliance Manager
The SoD Compliance Manager is a member of the IT Governance organization. He/she is responsible for
managing the SoD Lifecycle (driving the design and governance of the SoD Framework as chairman of
the SoD Council, monitoring SoD compliance in the business processes at Henkel and coordinating
follow-up activities). The SoD Compliance Manager is the process owner of IAM processes and tool
landscape.
3.13 Business Process Owner
The Business Process Owner (BPO) is responsible for the design of a specific business process. BPO are
defined by Business Unit and Function at Henkel. Changes in end-to-end processes are coordinated
between different process owners.
The set-up of the Business Process Owner organization varies between the businesses/functions and
processes. In some cases a global BPO but usually regional BPO are installed.
The BPO define standard processes, steer the implementation of standard processes in IT systems in the
regions, and steer the changes within processes and systems.
The BPO usually work with local Key Users in the countries to design local process variants.
In the context of IAM the Business Process Owner defines Role Owners, and triggers changes to Roles
Classification: internal
Version 1.93
Page 15 of 111
SoD Documentation
with changing of the process design.
The Business Process Owner defines, designs, and reviews Compensating Controls for Dangerous
Combinations of Roles as well as for Critical Roles. The BPO might delegate this task to Role Owner(s).
3.14 Role Owner
(to be moved to the ACC or ACC to link to this chapter?)
The Role Owner is defined by the Business Process Owner. He/she defines the content of Business
Roles, defines, designs, and reviews Compensating Controls for Critical Roles, clarifies SoD conflicts
detected by automatic reviews on role design, and triggers the change management process for Roles.
The Role Owner coordinates the nomination of Role Administrators and defines which roles a Role
Administrator is enabled to assign to users. The Role Owner is typically a member of the Business
Process Owner organization.
3.14.1 Tasks of the Global Role Owner
-
- definition and change management of global template authorization roles (master roles)
-
- nomination of Local Role Owners
-
- approval & delegation of local roles for specialties
3.14.2 Tasks of the Local Role Owner
-
derivation of global template roles to local domains
-
definition of local and derived roles
-
nomination of local Role Admins (key user concept)
3.15 Role Administrator (Role Admin)
ACC to link to this chapter?)
(to be moved to the ACC or
The Role Administrator is defined by local Line Management. He/she assigns Roles to and removes Roles
from users. The Role Administrator selects Compensating Controls for approved exceptions. The Role
Administrator initiates changes to roles by requesting missing objects from the Role Owner.
3.15.1 Tasks of the Role Admin (SPOC)
-
contact for end user requests for authorizations
-
select roles according to the request
-
SoD cleaning of users
-
request changes to roles from Local Role Owners
3.15.2 Tasks of the Role Admin (Assignment Approver)
-
approval of role assignments
Page 16 of 111
Version 1.93
Classification: internal
SoD Documentation
4
Identity & Access Management Processes
4.1 User ID Administration
(to be moved to the IDM document)
This chapter describes the processes and compliance controls that support the life cycle of user IDs at
Henkel, including the access to IT systems.
This chapter is currently under review. The documented process flows reflect current practice.
Prerequisite for User ID Administration is
-
HR Master Data entry in case of employees
-
Master data entry in the identity repository (HMD) for contractors
-
Tools to support the Identity Management processes (see chapter 7: “Software”).
Some IAM processes start in HR, when a new employee joins the company, or an employee leaves the
company. In other cases the IAM processes are triggered by supervisors or administrators within the
organization.
The Global HR system (GHR) stores all relevant master data of employees. The process of joining or
leaving a company usually starts in HR, subsequent Identity and Access Management processes are
triggered by HR.
Contractors working at Henkel are not stored in the GHR system. Master Data for Contractors and
External Companies are stored directly in the Henkel Meta Directory (HMD).
4.1.1 HR Processes Joiner - Mover – Leaver
4.1.1.1
Joiner (IAM-001)
Supervisor
of Employee
/
Person in
charge
START
Employee/
Contractor
(User)
START
Create User
(IAM-100)
Assign Roles
(IAM-200)
JOINED
HR
START
Classification: internal
Version 1.93
Page 17 of 111
SoD Documentation
4.1.1.2
Mover (IAM-002)
A typical challenge for a company is the situation of employees frequently changing their duties. A higher
risk exists, when these employees gather access rights and authorizations during their life cycle without
removal of obsolete rights. It is especially the case for assignments in apprenticeship or internships or job
rotations in different business functions.
The trigger for removing authorizations shall come from the former and/or new Supervisor
Supervisor
of Employee
Org A
START
Indicate
“Employee
Leaving”
Supervisor
of Employee
Org B
START
Indicate
“Employee
Joining”
RoleAdministrator
Org A
RoleAdministrator
Org B
Employee/
Contractor
(User)
Remove
Roles
(IAM-201)
Set validity period
for remaining
“old” roles
(overlap period)
END
Assign Roles
(IAM-200)
Info
The Mover process is controlled by the following controls:
1. SoD risks of level very high (red)
The CUP workflow ensures that no Mover has a red SoD conflict at any time.
2. SoD risks of level high (orange)
Compensating controls approved by Supervisors ensure a second pair of eyes for all SoD risks
(risk level red and orange).
3. Remaining risks (need-to-have principle, non-SoD relevant)
Validity periods for authorizations: 24 month expiration of authorizations ensure a review on
average within 1 year, latest after 2 years.
The control of the remaining risk is to be ensured by Supervisors organisationally. No automatic trigger is
required
Page 18 of 111
Version 1.93
Classification: internal
SoD Documentation
4.1.1.3
Leaver (IAM-003)
HR
System
START
Exit-Action
within GHR
Remove
Roles
(IAM-201)
Supervisor
of Employee
Classification: internal
Delete User
(IAM-101)
END
Info
Version 1.93
Page 19 of 111
SoD Documentation
4.1.2 User ID processes
4.1.2.1
Create User (IAM-100)
Create User – After Entry Action (IAM-100A)
HR
START
Entry-Action
within GHR
Only for countries where
Master Data registration can be done
before first working day !
1. PERSON
2. USER
User ID &
Password
Generation
System
Supervisor
Supervisor can directly
request additional authorizations
for the Employee
Info
IT
Coordinator
Activate User
Employee
User/PasswordForm
ENTRY
END
Create User – Before Entry Action (IAM-100B)
User
Administrator
Employee
START
User ID &
Password
Generation
1. USER
2. PERSON
ENTRY
User/PasswordForm
END
Activate User
IT
Coordinator
Use User for the Entry-Action !
No Dummies left in the system !
HR
Page 20 of 111
For some countries it’s a legal restriction:
HR Master Data registration not before
first working day !
Entry-Action
within GHR
END
Version 1.93
Classification: internal
SoD Documentation
Create User – External (IAM-100C)
Requestor
(anybody)
Attach identifying
attributes to a
User + External
Company
START
No
Person in
charge
END
Supervisor
of Person in
charge
Approve
?
Yes
No
END
Approve
?
External Company has to be informed
because he signed the “Data Security
Agreement” and is therefore responsible
for his employee.
External
Company
Info
Create User
System
4.1.2.2
Yes
Approval ?
END
Delete User (IAM-101)
Delete User – Internal (IAM-101A)
HR
START
Exit-Action
within GHR
System
(GHR)
Leave-Date
stored
System
(HAD/HMD)
User-Blocking
User
Administrator
Manual
User-Blocking
Supervisor
START
Classification: internal
Delimit User
User-Erasing
DELIMITED
DELETED
In some cases the Exit-Action in HR is at
the end of the contract (e.g. inactive
period), but the user-ID needs to be
blocked before-hand.
Version 1.93
Page 21 of 111
SoD Documentation
Delete User – External (IAM-101B)
Requestor
(anybody)
START
REJECTED
Request for
Deletion
Person in
charge
No
Approve
?
START
Yes
Supervisor
of Person
in Charge
External
Company
Info
Delete User
System
4.1.2.3
DELETED
Block Inactive User (IAM-102)
START
System
Employee/
Contractor
(User)
Supervisor
of
Employee
/
Person in
charge
Page 22 of 111
Periodical
Check of User
User
Block
Delete
Never used
1 year
1 ½ years
Used once
1 ½ year
2 years
Delete
Action ?
Delete User
USER
REVIEWED
Block
Block User
Info
Info
Version 1.93
Classification: internal
SoD Documentation
4.1.2.4
Password Reset (IAM-103)
Password Reset (IAM-103A)
2 Security
Questions
Help
Desk
Employee
identified
?
PasswordReset & Handover
Yes
No
Password forgotten or
entered wrong password
Employee
START
Employee
contacts Help
Desk
IT
Coordinator
Instructed to
contact IT
Coordinator
personally
Receives Initial
Password
Identifies
Employee via
Badge
PasswordReset & Handover
Creates
personal
Password
END
Password Reset – Self Service (IAM-103B)
LOGIN
ApplicationSelection
LOGIN
HELP
START
Login via
- Corp. UID
- Corp.
Password
HelpDocumentation
CHANGE
PASSWORD
Employee
LOST
PASSWORD
Change via
- Corp. UID
- Old Corp. Password
- New Corp. Password
- Confirm Password
CHANGE
PASSWORD
Lost Password
- Corp. UID
RESET PASSWORD
Yes
Classification: internal
Version 1.93
eMail
successfully sent
?
No
Please inform
Heldpdesk !
Page 23 of 111
SoD Documentation
4.1.2.5
External Company Handling (IAM-104)
Person in
charge
Create/
Modify/Delete
External
Company
START
Supervisor
of Person in
charge
No
REJECTED
Approve
?
External
Company
4.1.2.6
Yes
CREATED
Info
User Access Review (IAM-110)
START
Daily
System
(HAD)
Update of user
access rights
table in UAR
System
(UAR)
END
START
Daily
Select users
with last review
> 12 months +
send mail
Logging of
review in HAD
END
Remove
Access
Rights
END
Yes
Info
Supervisor
Review of User
Access Rights
Approve
?
IT
Coordinator
No
4.1.3 Compliance Controls
This list is not complete. Further and more specific controls are implemented in the processes.
4.1.3.1
Approval of User Requests (C14)
Control C14: User administrators and Help Desk only act on valid and approved requests.
Page 24 of 111
Version 1.93
Classification: internal
SoD Documentation
4.1.3.2
Logging of User Requests (C13)
Control C13a: Every user access request must be logged electronically.
4.1.3.3
User Access Review (C20)
“Review of Obsolete User-IDs“
Control C20: Supervisors are to periodically review an overview of the users under their responsibility and
identify obsolete users (leavers, retired staff etc.)
Classification: internal
Version 1.93
Page 25 of 111
SoD Documentation
4.2 User Authorization Administration
(to be moved to the chapter 4.2. of ACC document)
This chapter describes the processes and compliance controls that support the life cycle of user
authorizations within the SAP systems that are in scope of SoD Compliance.
Prerequisite is
-
User ID existing (see chapter 4.1: “User ID Administration”)
-
Business Roles configured in the process and tool landscape (see chapter 4.3: “User
Authorization Configuration”).
-
Role Administrators defined (see chapter 4.4.2: “Define Role Administrator (IAM-401)”).
4.2.1 Assign Roles (IAM-200)
The Role Assignment workflow requires a 1-step approval by the Role Administrator. The workflow blocks
the assignment of SoD risks of level very high (red). All other SoD risks of level “orange” or lower are
passed. Prerequisite: These conflicts are covered by Compensating Controls activated system-wide.
Supervisor
/ Person in
charge
End
User
Info
START
On demand
Role
Admin
(SPOC)
Authorization
Request
IAM 200-1
Role
Selection
IAM 200-2
Info
Reject/
Submit
?
Request rejected
Request submitted
Role
Admin
(Assignment
Approver)
Role approval process
per selected role
(line items)
Role
Approval
IAM 200-3
Role approval is finished when all
roles are approved or rejected
System
(CUP)
Page 26 of 111
Reject/
Approve
?
Request
rejected
Request
approved
Provisioning
In SAP
Version 1.93
Yes
Success?
No
Exception
Handling
Classification: internal
END
SoD Documentation
4.2.1.1
Assign Roles (IAM-200-1): Authorization Request
Supervisor
/ Person in
charge
End
User
Input by End User:
- Free text: required authorizations
- Free text: reason
- Select system
- Select Role Admin (SPOC) = addressee
Create
Authorization
Request
START
On demand
Info
Role
Admin
(SPOC)
Role
Admin
(Assignment
Approver)
Next Workflow
Stage (0  1)
System
(CUP)
4.2.1.2
END
Assign Roles (IAM-200-2): Role Selection
Supervisor
/ Person in
charge
End
User
Remediate Conflict
Approve SoD
Exception
IAM-510
Exception
Reject Request
OR
No
Role
Admin
(SPOC)
Check
Request
Info
Request
OK?
Yes
Select
Roles
Optional actions:
- select/add different roles
- assign/retain/remove role
- set validity periods of role
SoD
Compliance
Check
Yes
Red
SoD
Risk?
Reject
Request
No
Submit
Request
Role
Admin
(Assignment
Approver)
System
(CUP)
START
Classification: internal
Event: Authorization
request created by
End User
Version 1.93
New
Workflow
Stage (1  2)
END
Page 27 of 111
SoD Documentation
4.2.1.3
Assign Roles (IAM-200-3): Role Approval
Supervisor
/ Person in
charge
End
User
Role
Admin
(SPOC)
Remediate Conflict
Approve SoD
Exception
IAM-510
Exception
Reject Request
OR
No
Role
Admin
(Approver)
Check
Role
Optional:
OR
Change Role
Yes Assignment
Optional changes:
- assign/retain/remove role
- set validity period of role
Role
OK?
Info
System
(CUP)
START
Yes
Red
SoD
Risk?
SoD
Compliance
Check
Reject
Role
No
Approve
Role
Event: Authorization
request submitted by
Role Admin (SPOC)
after role selection
END
4.2.2 Remove Roles (IAM-201): Overview
The main difference between a request for removal and a request for assignment of roles is the approval
step. “Removal without approval”. Request for removal don’t require a SoD check and don’t require a
approval by Role Admins (Assignment Approvers).
Supervisor
/ Person in
charge
End
User
Info
START
On demand
Role
Admin
(SPOC)
Authorization
Request
IAM 200-1
Role
Removal
IAM 201-2
Info
Reject/
Submit
?
Request rejected
Request
submitted
Role
Admin
(Assignment
Approver)
Yes
System
(CUP)
Page 28 of 111
Provisioning
In SAP
Version 1.93
Success?
No
Exception
Handling
END
Classification: internal
SoD Documentation
4.2.2.1
Remove Roles (IAM-201-2): Role Removal
Supervisor
/ Person in
charge
End
User
No
Role
Admin
(SPOC)
Check
Request
Request
OK?
Yes
Select
Existing
Assignments
Select
roles to be
removed
Submit
Request
Reject
Request
Info
Role
Admin
(Assignment
Approver)
System
(CUP)
START
Event: Request for
removal of authorizations
created by end user
END
4.2.3 Reapply Role Assignment (IAM-210)
Each role assigned to SAP users is limited to a certain validity period. A mail daemon recognizes role
assignments that are going to expire in some weeks and ask the user to request a prolongation. This
request for prolongation process is identical to the regular process for assignment of roles.
Supervisor
/ Person in
charge
Info
End
User
Info
Assign Role
IAM 200
Role
Admin
(SPOC)
Role
Admin
(Assignment
Approver)
System
(CUP)
START
Classification: internal
Event: expiration
of existing role
assignments
Version 1.93
END
Page 29 of 111
SoD Documentation
4.2.4 Compliance Controls User Authorization Administration
4.2.4.1
Segregation of Request and Approval of Role Assignments (C15)
Control C15: Every user authorization request must be formally approved by the Role Administrator, i.e.
“2-pairs-of-eyes”-principle (1-step approval). The Role Administrator cannot request and assign roles to
himself. One of both activities requires a second person.
4.2.4.2
Segregation of Role Assignment from Role Design (C35)
Control C35: Role Administrators cannot change roles or approve changes on roles. Role Owners can
assign roles and approve role assignments.
Remark: In general it should be avoided that the one responsible for assigning roles is enabled to
change roles. But exceptions, especially in smaller countries, must be possible, i.e. the Role Owner
also assigning Roles to users.
Sufficient control is provided if:
- “2-pairs-of-eyes”-principle is implemented in the change of roles, i.e. segregation of change request
and development/implementation of change (Role Owner vs. IT Development)
- Role is checked on SoD compliance before implementation
4.2.4.3
Segregation of Role Assignment from Role Implementation (C37)
Control C37: The responsibility to execute changes in user assignments (Role Administrator & User
Administrator) cannot be combined with any execution responsibility in the role development (IT Service
Delivery).
4.2.4.4
Limitation of Role Administrators (C43)
Control C43: Every Role Administrator can only assign a defined and limited set of Roles to users.
4.2.4.5
Approval of SoD Conflicts (C09 and C22)
Control C09: Segregation of Duties conflicts may only be approved if policies on this matter justify or
approve a compensating activity other than segregation.
Control C22: When Role Assignment activities introduce additional SoD conflicts of level "High" (Orange),
the Supervisor needs to be informed. Compensating Controls must be active to mitigate these SoD risks.
4.2.4.6
Logging of User Requests (C13)
Control C13b: Every user authorization request must be logged electronically.
4.2.4.7
Need-To-Know Principle (C17)
Control C17: The Role Administrator is required to inspect appropriateness of assignment and whether
the chosen alternative is considered as the best.
4.2.4.8
Documentation of Roles (C18)
Control C18: Documentation on the available Roles must be available for every requestor and approver
such to identify the appropriate authorizations for a Role Assignment request.
4.2.4.9
Consulting (C19)
Control C19: The adequacy of selected authorizations or Roles can be verified by consulting a subjectmatter expert or GSD.
Page 30 of 111
Version 1.93
Classification: internal
SoD Documentation
4.2.4.10
Validity Period for Role Assignments (C40)
Control C40: When a user is moving from one organizational unit to another unit, the Role Administrator of
the new organizational unit has to set a validity period to the “old” authorizations. These Roles have to be
removed automatically after a validity period (3 months), upon prior information.
4.2.4.11
Review of Role Assignments on Compliance to Need-To-Know (C21)
Control C21: Supervisors are to periodically review an overview of User - Role assignments under their
responsibility and identify obsolete and/or incorrect assignments.
Remark: This task is delegated at Henkel to Role Admins. See process 4.2.3: “Reapply Role
Assignment (IAM-210)”.
4.2.4.12
Review of Role Assignments on Compliance to SoD (C25)
Control C25: All Users must be reviewed periodically to identify any present SoD conflicts to ensure timely
detection of undesired combinations due to recent Role assignments (i.e. detective SoD Control).
Remark: See process 4.2.3: “Reapply Role Assignment (IAM-210)
4.2.4.13
Further Optional Controls from COBIT & ISO27002
These controls are defined in the COBIT and/or ISO 27002 standards, but were decided not to be
implemented within the SIGMA concept. Reason: Controls are redundant to controls above or controls are
defined on low risk areas.
Check Validity of Request
Control C16: The Supervisor is to assess the validity of the request and business case as well as the
business need (place storage) (Verify)
Remark: Control is skipped. The Role Assignment process foresees a 1-step approval for assignment
of roles. Only assignment of an exception requires a 2nd-level approval.
Reason: Effective control is achieved with first approval. The Role Assignment request is documented.
Requestor and Approver are segregated duties. The Role Administrator has only a limited set of Roles
he/she is enabled to assign to users. SoD conflicts are detected preventively by a system before actual
assignment. Detective controls check SoD conflicts ex-post.
Approval for Assignment of SoD Conflicts
Control C23: Segregation of Duties conflicts may only be approved if policies on this matter justify or
approve a mitigation activity other than segregation
Remark: redundant.
Segregation of Role Assignment from Review of Role Assignments
Control C36: The responsibility to assign Roles to users cannot be combined with the responsibility to
periodically review and approve Role Assignments to users (Execution)
Remark: This control was skipped.
Reason: The Role Administrator who is responsible for assigning Roles to Users is at the same time the
most knowledgeable person to review the User assignments.
Classification: internal
Version 1.93
Page 31 of 111
SoD Documentation
4.3 User Authorization Configuration
(to be moved to the chapter 6 of ACC document)
This chapter describes the processes and compliance controls that support the configuration of Business
Roles.
This is prerequisite for the administrative processes described in chapter 4.2: “User Authorization
Administration”.
Prerequisite for the Authorization Configuration is
-
Role Owner defined (see section 4.4.1: “Define Role Owner (IAM-400)”).
-
Role Administrator defined (see section 4.4.2: “Define Role Administrator (IAM-401)”).
4.3.1 Create Role (IAM-300)
Business
Process
Owner
Define Role
Owner
(IAM-400)
START
Process change
triggers the need
for Role creation
No
Role
Owner
START
Role
Owner
defined?
Yes
Change
Role
(IAM-301)
CREATED
Periodic review
triggers the need
for a new Role
Role
Administrator
START
Missing transactions in
Role triggers the need
for Role creation
Page 32 of 111
Version 1.93
Classification: internal
SoD Documentation
4.3.2 Change Role (IAM-301)
Business
Process
Owner
START
Demand to
change Role
Process change
triggers the need
for a Role change
Info
REJECTED
if triggered by
Business Process
Owner
Info
if triggered by
Business Process
Owner No
Role
Owner
START
Check Demand
to change Role
Periodic review
triggers the need
for a Role change
Approval
?
Yes
Pre-authorized
Role Change
(IAM-303)
CHANGED
No
if triggered by Role
Administrator
if triggered by Role
Administrator
Info
Role
Administrator
START
Demand to
change Role
REJECTED
Info
Missing transactions
in existing Roles
triggers the need for
a Role change
4.3.3 Delete Role (IAM-302)
Business
Process
Owner
START
Process change
triggers the need
for Role deletion
Role
Owner
Change Role
(IAM-301)
START
DELETED
Periodic review
triggers the need
for Role deletion
Role
Administrator
Classification: internal
Version 1.93
Page 33 of 111
SoD Documentation
4.3.4 Pre-Authorized Role Change (IAM-303)
The process described here is embedded in the regular CHARM process (Change Management process)
Build
IT
(Service
Delivery)
Maintain
Master Data
(Role Owner/Role
Admin Tables)
Unit &
Functional
Test
Transport
change to
production
Yes
Compliant
solution
possible?
No
No
Is Role
compliant?
System
(GRC)
Yes
Define type of
change and
create CR
No
Info
Role
Owner
Check content
of role
START
Acceptance
Test
Acceptance?
Yes
REJECTED
Info
IMPLEMENTED
The check “Is Role compliant?” needs to check on the following:
-
SoD compliance of role itself, i.e. did the change create a SoD conflict within the objects of the
role?
Further checks can be considered:
-
Impact of the role change on possible Dangerous Combination, i.e. did the change of the role
create a new dangerous combination of this role with any other existing role, although the role
itself is still free of SoD conflicts?
-
Impact of the role change on the existing user authorizations on potential new SoD conflicts, i,.e.
on which users did the change of the role create new SoD conflicts?
These impact analyses are very difficult to conduct. The effort might be higher than a roll-back and/or
clean-up afterwards. Therefore the following steps should be processes after a role change:
-
Regular SoD Analysis (monthly) identifying the users with SoD conflicts
-
Check on solution options: Roll-back roll change, repair role, or clean-up users
A differentiation in simple and complex changes is required.
(A)
simple, pre-authorized changes e.g. for adding a transaction to a role
This change can run at any time.
(B)
complex change with potential impact on user base, e.g. deleting functions out of roles
This change rather runs within the next release upgrade and is tested with the next
integration test.
The Role Owner decides which type of change he triggers.
Page 34 of 111
Version 1.93
Classification: internal
SoD Documentation
4.3.5 Review Obsolete Roles (IAM-310)
IT
Service
Delivery
Periodic
analysis of
obsolete roles
START
Is the Role
still valid?
Role
Owner
Document
Review-Result
REVIEWED
Yes
No
Delete Role
(IAM-302)
4.3.6 Compliance Controls User Authorization Configuration
4.3.6.1
SoD Conflict-Free Role design (C24)
Control C24: Segregation of Duties conflicts in Role design have to be avoided wherever possible.
Exceptions must be formally documented along with the approvals and reference to the documented
opted compensating controls.
4.3.6.2
Approval of Role design changes (C03)
Control C03: Changes to Roles must be approved by the Role Owner.
4.3.6.3
Logging (C05)
Control C05: The process to change Roles must ensure logging.
4.3.6.4
Segregation of Role Design from Role Assignment (C35)
Control C35: Role Administrators cannot change roles or approve changes on roles. Role Owners can
assign roles and approve role assignments.
Remark: In general it should be avoided that the one responsible for assigning roles is enabled to
change roles. But exceptions, especially in smaller countries, must be possible, i.e. the Role Owner
also assigning Roles to users.
Sufficient control is provided if:
- “2-pairs-of-eyes”-principle is implemented in the change of roles, i.e. segregation of change request
and development/implementation of change (Role Owner vs. IT Development)
- Role is checked on SoD compliance before implementation
4.3.6.5
Segregation of Role Implementation from Role Assignment (C37)
Control C37: The responsibility to execute changes in user assignments (Role Administrator & User
Classification: internal
Version 1.93
Page 35 of 111
SoD Documentation
Administrator) cannot be combined with any execution responsibility in the role development (IT Service
Delivery).
4.3.6.6
Segregation of Role Owner from Role Implementation (C42)
Control C42: The responsibility to approve changes of roles (Role Owner) cannot be combined with any
execution responsibility in the role development (IT Service Delivery).
4.3.6.7
Approval of Business Process Owner on Cross-Business Roles (C04)
Control C04: A Role Owner can only add transactions and technical authorization objects out of his/her
area of responsibility to Roles. To add transactions or technical authorization objects out of other areas
requires the approval of the respective Business Process Owner.
Remark: A Role Owner in the Supply Chain wants to add a Finance Transaction in his Role design.
This requires prior permission by the Business Process Owner of Finance.
4.3.6.8
Review of Change Management process for Roles (C06)
Control C06: A periodic review must be performed on the effectuated role changes to ensure adequate
execution of the role change management process
Remark: Covered by the CHARM process, no additional controls for SIGMA defined.
4.3.6.9
Review of Role design (C07)
Control C07: Role content must be reviewed periodically by the appropriate Role Owners to ensure that
the content is still SoD-compliant and required.
Remark: This control is achieved by a periodic review and subsequent deletion of obsolete roles, and
by the content and compliance check with every change of a role. An additional periodic review of role
content is not required.
See process 4.3.2: “Change Role (IAM-301)” and process 4.3.5: “Review Obsolete Roles (IAM-310)”.
4.3.6.10
Approval of Role design creating new Dangerous Combinations (C08)
Control C08: When role changes introduce additional SoD conflicts of level "High" (Beta), additional
approvals must follow by the Business Process Owner. SoD conflicts of level “Very High” (Alpha) must not
be introduced by role changes.
Remark: Tbc if this control can be supported by a GRC tool. Fall-back is a detective SoD Compliance
monitoring that latest detects new SoD conflicts.
4.3.6.11
Further Optional Controls from COBIT & ISO27002
These controls are defined in the COBIT and/or ISO 27002 standards, but were decided not to be
implemented within the SIGMA concept. Reason: Controls are redundant to controls above or controls are
defined on low risk areas.
Review of Roles design on SoD compliance
Control C10: Single roles or tasks used in roles and user provisioning, must be periodically reviewed on
the presence of SoD conflicts and approved by appropriate owners.
Remark: Covered by controls above
Approval of SoD conflicts in Roles design
Control C11: Segregation of Duties conflicts in roles must be formally documented along with the
approvals and reference to the documented opted mitigating controls.
Remark: Covered by controls above
Page 36 of 111
Version 1.93
Classification: internal
SoD Documentation
Handling of Privileged Authorizations
Remark: The handling of Privileged Authorizations is out of scope of SIGMA.
Control C26: A process must be defined controlling the request, use and timely decommissioning of
privileged authorizations. This process must ensure approvals, documentation and periodic review.
Control C27: A list of pre-approved users of privileged authorizations must be defined and maintained to
ensure only authorized staff has access
Control C28: The list of pre-approved users is reviewed at least quarterly for accuracy and updated to
ensure validity and timely adjustments following organizational changes
Control C29: The list of pre-approved users is formally approved after periodic review to ensure
management accountability and awareness.
Control C30: Changes to the pre-approval list are formally approved by the accountable manager
Control C31: The process defined to control the use of privileged authorizations requires a logged incident
/ ticket before privileged authorizations may be obtained. This ticket must be used to justify the use and
must include documentation on the proposed/intended solution (using privileged authorizations) as well as
a closing comment on what was done using these authorizations to solve/close the ticket. This
documentation will be matched with audit trails from the super-user authorizations
Control 32: Every privilege use-case is reviewed by a different individual to inspect its use, match with the
documentation and formally signs off that the use was legitimate and that only activities for the
incident/ticket were performed.
Control 33: Documentary evidence of each ticket, review/approval and sign-off as well as logging remains
available for at least 12 months to allow for inspection and auditability
Control 34: An independent staff member must review (after privileged authorizations were granted) that
privileged authorizations are effective only for the required period and in any case not used for longer than
24 hours
Control 38: The responsibility to use privileged authorizations cannot be combined with the responsibility
to review and approve its legitimate use
Control 39: The responsibility to maintain the "pre-approved" list cannot be combined with the authority to
use the privileged authorizations
Classification: internal
Version 1.93
Page 37 of 111
SoD Documentation
4.4 User Authorization Ownership
Decide if stay here or moved to ACC document
This chapter describes the processes and compliance controls that support the definition and the review
of role ownership.
This is prerequisite for the administrative processes described in chapter 4.2: “User Authorization
Administration”.
4.4.1 Define Role Owner (IAM-400)
Business
Process
Owner
START
Nominate
Role Owner
per process
Role
Owner
Info
IT
(Service
Delivery)
Maintain
Master File
(Global Role
Owner.xls)
System
Maintain
GRC role master
data
DEFINED
This process is covered organizationally.
Page 38 of 111
Version 1.93
Classification: internal
SoD Documentation
4.4.2 Define Role Administrator (IAM-401)
Role
Owner
Define Role Admin
(Assignment Approver
per role)
Define Role Admin
(SPOC)
START
Role
Administrator
Info
IT
(Service
Delivery)
Maintain
Master Data
(SPOC table / GRC
role master data)
System
DEFINED
This process is covered organizationally.
4.4.3 Review Role Ownership (IAM-410)
Business
Process
Owner
IT
(Service
Delivery
Define Role
Owner
(IAM-400)
No
Confirmation
of Role
Owner?
Periodically
check list
of Role Owners
START
Yes
Document
review result
in Global Role
Owner master file
REVIEWED
System
This process is covered organizationally.
Classification: internal
Version 1.93
Page 39 of 111
SoD Documentation
4.4.4 Review Role Administrators (IAM-411)
Define Role
Administrator
(IAM-401)
Role
Owner
IT
(Service
Delivery
No
START
Confirmation
of Role
Admin?
Yes
Periodically
check list
of Role
Administrators
Document
review result
REVIEWED
System
This process is covered organizationally.
4.4.5 Compliance Controls User Authorization Ownership
4.4.5.1
Definition of Role Owner (C01)
Control C01: Role Owner must be defined.
4.4.5.2
Review of Role Owner definition (C02)
Control C02: Role Owner assignments must be periodically reviewed.
Remark: see process 4.4.3: „Review Role Ownership (IAM-410)“.
4.4.5.3
Review of Role Administrator definition (C41)
Control C41: Role Administrator assignments must be periodically reviewed.
Remark: see process 4.4.4: „Review Role Administrators (IAM-411)“.
Page 40 of 111
Version 1.93
Classification: internal
SoD Documentation
4.5 SoD Compliance Control
To stay here.
This chapter describes the compliance controls and review processes that ensure SoD Compliance.
4.5.1 Check Compensating Control (IAM-500)
The supervisor of an employee is responsible for the risks associated to the authorization given to his/her
employees. The Supervisor is also the one checking Compensating Controls.
System
(COCOS)
START
Event:
Periodic trigger
Periodic collection
of potential SoD
violations in SAP
(COCOS Reports)
Periodic
notification mails
to Supervisors
Logging of
approval
status
CHECKED
Info
Yes
Check
Compensating
Control in COCOS
(WEB tool)
Supervisor
Chief
Compliance
Officer
Classification: internal
Approve
?
No
Violation
Handling
Version 1.93
Page 41 of 111
SoD Documentation
4.5.2 Approve SoD Exception (IAM-501)
Business
Management
START
Event: Red SoD conflict
cannot be solved.
Request for exception
raised by Role Admin
President /
MC0
Document request
for exception to
Corporate Standard
SoD
Check request for
exception
No
Approve
?
Yes
Compliance
& Risk
Committee
Check request for
exception
Approve
?
No
Yes
Create a mitigation
control for the
approved exception
limited to N months
IT
Service
Delivery
END
4.5.3 Review SoD Exceptions (IAM-510)
SAP
GRC
START
Reaffirm Role
Assignment
IAM-210
END
4.5.4 Compliance Controls
Not defined
Page 42 of 111
Version 1.93
Classification: internal
SoD Documentation
4.6 SoD Framework Governance
To stay here.
This chapter describes the processes and compliance controls that support the Governance of the SoD
Framework itself. This is important to achieve a consistency between the rules defined in the Corporate
Standard SoD and the rules applied in the organization, processes, and tool landscape.
4.6.1 Review Corporate Standard SoD (IAM-600)
No
Compliance
& Risk
Committee
Approve
changes
?
Yes
Event: Annual Review
START
SoD
Coreteam
Publish new
version of CS
SoD in HIMDOC
Define new CS
SoD release
Collect change
requests to
CS SoD
Approve
changes
?
Yes
Major
change
?
END
Reconciliation
SAP GRC
rule sets
IAM-603
No
Define
Compensat.
Controls
IAM-604
Configure SAP
GRC rule set
IT
Service
Delivery
Classification: internal
Review SoD
Permission
Directory
IAM-602
Yes
No
Review SoD
Rel. Transact.
Directory
IAM-601
Version 1.93
Page 43 of 111
SoD Documentation
4.6.2 Review SoD-relevant Transaction Directory (IAM-601)
Compliance
& Risk
Committee
on demand
END
START
SoD
Coreteam
No
Collect change
requests
IT
Service
Delivery
Approve
changes
?
Yes
Run SoD impact
analysis
Reconciliation
SAP GRC
rule sets
IAM-603
Review SoD
Permission
Directory
IAM-602
Configure SAP
GRC rule set
4.6.3 Review SoD Permission Directory (IAM-602)
Compliance
& Risk
Committee
No
SoD
Coreteam
Approve
?
Yes
on demand
START
IT
Service
Delivery
END
Yes
Collect change
requests
Page 44 of 111
New
transaction
with
permission
?
No
Document SoD
Permission
Directory
Configure SAP
GRC rule set
Version 1.93
Reconciliation
SAP GRC
rule sets
IAM-603
Classification: internal
SoD Documentation
4.6.4 Reconciliation of SAP GRC Rule Sets (IAM-603)
END
Document
reconciliation
results
SoD
Coreteam
Yes
Reconcile
access risks
vs CS SoD
Reconcile
functions vs
SoD-relevant
T-code Directory
Reconcile
permissions vs
SoD-relevant
T-code Directory
Reconcile
permissions
vs SoD Perm.
Directory
Recon
Successful
?
No
IT
Service
Delivery
START
Download SAP
GRC rule sets
Correct SAP
GRC rule set
Event:
Change of SAP
GRC rule set
4.6.5 Define Compensating Controls (IAM-604)
This process describes how Compensating Controls are defined and designed. The actual control itself is
conducted by the Supervisor, see 4.5.1: “Check Compensating Control (IAM-500)”.
The Business Process Owner might delegate the definition of Compensating Controls for single Critical
Roles to the Role Owner. Compensating Controls on Dangerous Combinations of Roles usually require
the definition by the Business Process Owner.
START
Check changes
of new version
of Corporate
Standard SoD
Event:
Change of Corporate
Standard SoD
New
Risks?
No
Update
configuration
of controls
Review
configuration
of COCOS tool
Yes
New
control
required?
SoD
Coreteam
No
Update
Compensating
Control Direct.
Yes
Define change
request
Build, test, and
deploy new
control
IT
Service
Delivery
Classification: internal
END
Version 1.93
Page 45 of 111
SoD Documentation
4.6.6 Compliance Controls SoD Framework Governance
4.6.6.1
Review of Compensating Control measures (C12)
Control C12: Business Process Owner must periodically test, demonstrate and sign-off on the on-going
effectiveness of the employed Compensating Control measures.
Remark: Business Process Owners have to check measures like Compensating Control reports or builtin controls periodically. The Compensating Control itself is conducted by the Supervisor of the User.
This control is achieved by
-
Periodic review of the SoD matrix and subsequent check and change of Compensating Controls
-
Detection of missing Compensating Controls within the assignment process and subsequent
creation (no SoD conflict approval without compensating control)
Page 46 of 111
Version 1.93
Classification: internal
SoD Documentation
5
SoD Governance
To stay here.
This document describes the elements of the SoD Framework at Henkel, ownership and regulations for
change management, and the master files per element.
5.1 Elements and Structure of the SoD Framework at Henkel
5.1.1 SoD Framework
Corporate Standard SoD CS SoD
The Corporate Standard defines
-
the processes (e.g. PTP)
-
functions per process
-
SoD risks as combination of two functions (e.g. function 1 combined with function 2)
-
the classification of SoD risks (risk level, e.g. red = very high)
SoD Relevant Transaction Directory
The SoD Relevant Transaction Directory lists all relevant SAP transactions per process function to enable
the SoD tools to check on combinations of transactions assigned to users. The directory defines
-
the SoD relevant transactions per process
-
the classification of each transaction to a process function
-
the criticality of the transaction (e.g. display transactions not critical)
-
whether the SoD risks is defined more precisely on permission level or if the whole transaction is
classified as SoD-critical
SoD Permission Directory
The SoD Permission Directory defines
-
the authorization objects, fields per SAP transaction
Classification: internal
Version 1.93
Page 47 of 111
SoD Documentation
-
the critical values (e.g. activity type 01/02 = create/change are critical,
but activity type 03 = display is not critical)
5.1.2 SoD Tools
SAP GRC AC
SAP GRC AC (Access Control) is implemented at Henkel for the following purposes
-
Analysis of the SoD compliance of authorization roles (RAR)
-
Analysis of the SoD compliance of SAP users (RAR)
-
Compliant provisioning of authorizations to SAP users, preventing from assigning red SoD
conflicts (CUP)
Compensating Control System (COCOS)
COCOS is a web-based tool that allows Supervisors to check and approve transactions posted by
employees of their team. COCOS displays all cases, where one and the same user ran two steps of a
process in SAP which should have been segregated following the Corporate Standard SoD.
COCOS collects data from Compensating Control Reports running per SoD risk in each SAP System.
Some Compensating Control Reports even check on cross-system SoD Conflicts (e.g. creation of master
data in P03 (central master data system) and posting of credit notes in Pxx (Finance or Logistics
System)).
Built-in Controls
Built-in control prevent users from posting in one document flow two steps of a process that should be
segregated following the Corporate Standard SoD. The user might be authorized to run both process
steps, but is blocked from posting both process steps in one and the same document flow.
5.1.3 SoD KPI and Reporting
Global SoD Cockpit
The Global SoD Cockpit analyzes the SoD compliance of all SAP users worldwide. The cockpit reports
the SoD Compliance by location of the users (regions, countries, and organizational units) independent of
the SAP system the users are working with. This KPI is considering cross-system risks. The cockpit is
updated on a monthly level. Owner of the Global SoD Cockpit is the SoD Compliance Manager.
System SoD Cockpit
The System SoD Cockpit analyzes the SoD compliance of all SAP users worldwide. The cockpit reports
the SoD Compliance per system, independent where the users are located. This KPI is not considering
cross-system risks. The cockpit is updated on a monthly level. Owner of the Global SoD Cockpit is the
SoD Compliance Manager.
5.2 Naming Conventions of the SoD Framework at Henkel
5.2.1 Rule Sets
The Rule Set ID has no naming convention.
Page 48 of 111
Version 1.93
Classification: internal
SoD Documentation
The Rule Set description names the version (i.e. version of the SoD relevant transaction directory and the
release date of the SoD relevant transactions directory
5.2.2 Access Risks
General naming conventions (framework)
Access Risks have the following naming convention
XXXX_Y
XXXX is the 4-digit Risk ID as stated in the Corporate Standard
(SoD Risk Register, high level)
_Y
stands for the type of risk (_S = single system risk / _C = cross system risk)
Within this general frame, the processes define the risks as follows.
Order-to-Cash (OTC)
OTC SoD risks are codified as follows:
XXZZ_Y
XX
is the acronym of the first function
(e.g. B5 for function BU05 – Sales Order Processing)
ZZ
is the acronym of the second function
(e.g. F3 for function FO03 – Credit Management)
Purchase-to-Pay (PTP)
PTP SoD risks are codified as follows:
PXNN_Y
P
is fix for PTP
X
identifies the sub process type (I=Risk only for Intercomany,
E=risk only for external procurement; G = general risk for all types of sub-processes
NN
2-digit number
Human Resources (HR)
HR SoD risks are codified as follows:
HNNN_Y
H
is fix for HR
NNN
3-digit number
_Y
stands for the type of risk (_S = single system risk / _C = cross system risk)
For HR only single system risks apply
5.2.3 Functions
General naming conventions (framework)
Functions have the following naming convention
XXNN(Z)_Y
XX
is the 2-digit header of the process (e.g. PR = procurement)
Classification: internal
Version 1.93
Page 49 of 111
SoD Documentation
NN
Z
2-digit number
is an optional letter, identifying a variant of the function.
This is technically required in some cases, where the the same risk and function
is defined differently per connector.
_Y
stands for the type of risk (_S = single system risk / _C = cross system risk)
Order-to-Cash (OTC)
OTC functions are codified as follows:
XX
PR = Procurement;
AP = Accounts Payable;
MM = Materials Management
Purchase-to-Pay (PTP)
XX
BU = Business Unit OTC
FO = Finance OTC;
Human Resources (HR)
HR functions are codified as follows:
HNNN_Y
H
is fix for HR
NNN
3-digit number
_Y
stands for the type of risk (_S = single system risk / _C = cross system risk)
For HR only single system risks apply
5.2.4 Risk Descriptions
The risk descriptions are listed in the SoD Risk Register of the SoD Matrix of the Corporate Standard
SoD.
Short Description
The short description of the Access Risk is naming the two sub processes combined in this SoD Risk.
E.g. “Processing of Purchase Order and Processing of Vendor Invoice”
SoD Risk Register: “SoD Short Description”
Long Description
The long description describes the risk.
SoD Risk Register: “SoD Long Description”
Control Objective
The Control Objective provides examples.
SoD Risk Register: “Example”
Page 50 of 111
Version 1.93
Classification: internal
SoD Documentation
5.3 Governance of the SoD Framework
5.3.1 Governance Bodies
Corporate Compliance & Risk Committee (CRC)
The CRC is chaired by the Chief Compliance Officer at Henkel.
The CRC approves
-
major changes of the CS SoD
-
exceptions to the CS SoD as regulated in the CS SoD
SoD Coreteam
The SoD Coreteam is chaired by the SoD Compliance Manager. It takes place on a monthly basis.
The SoD Coreteam members are representatives of the Process Ownership per business unit and
function for the SoD relevant processes at Henkel, plus Internal Audit (VIA).
The SoD Coreteam approves
-
minor changes to the CS SoD
-
all changes to the SoD Relevant Transaction Directory
-
all changes to the SoD concept implemented at Henkel (i.e. Provisioning Process (CUP workflow),
Compensating Control System (COCOS), Compensating Control reports, Built-in Controls, SAP
GRC rule sets incl. Permission Level)
-
all changes to the KPIs and SoD Reporting
5.3.2 Corporate Standard Segregation of Duties (CS SoD)
Owner
Owner of the Corporate Standard is the Corporate Compliance & Risk Committee (CRC)
Master Files
The documentation consists of the following documents:
-
Main document:
CS SoD vX.X
(.pdf)
-
Enclosure #1:
SoD Matrix for Purchase-to-Pay (PTP)
(.xls)
-
Enclosure #2:
SoD Matrix for Order-to-Cash (OTC)
(.xls)
-
Enclosure #3:
SoD Matrix for Order-to-Cash (HR)
(.xls)
The Corporate Standard is documented in the HIMDOC database (Henkel’s Corporate Governance
documentation).
Location:
http://sf-apps-i201.de.henkelgroup.net/corporate/sustainability/himdochg.nsf
Responsible for master file
SoD Compliance Manager.
Review Cycle
The Corporate Standard is reviewed annually (end of year).
Classification: internal
Version 1.93
Page 51 of 111
SoD Documentation
Change Management Regulations
All change requests to the Corporate Standard have to be presented to the SoD Coreteam. The SoD
Coreteam decides on all changes to the Corporate Standard, minutes of the decisions are documented in
the Lotus Notes database “SoD Compliance Managements”.
Major changes require additionally the approval of the Corporate Compliance & Risk Committee before
implementation of the change.
Some complex changes might require the trigger of implementation projects, especially when the change
impacts many users (e.g. additional processes).
5.3.3 SoD Relevant Transaction Directory
Owner
Owner of the SoD Relevant Transaction Directory is the SoD Coreteam.
Master File
The SoD Relevant Transaction Directory is an Excel file, stored in the SoD Compliance Management
database in Lotus Notes. This documentation is leading. The configuration of functions and transactions in
the SAP GRC rule sets have to follow this master documentation.
Responsible for master file
SoD Compliance Manager.
Review Cycle
The SoD Relevant Transaction Directory is reviewed on a monthly basis with each change request.
Change Management Regulations
Changes to the SoD Relevant Transaction Directory have to be presented to the SoD Coreteam for
approval.
An impact analysis on different levels might be required before taking a decision on the actual
implementation of the change.
5.3.4 SoD Permission Directory
Owner
Owner of the SoD Permission Directory is the SoD Coreteam.
Master File
The Permission configuration is defined in the PRC system (master).
The SoD Permission Directory is an up-to-date copy of this configuration. This copy is stored in the SoD
Compliance Management database.
Responsible for master file
Responsible for the configuration in SAP GRC AC and responsible for the correct and up-to date
documentation of permissions in the SoD Permission Directory documentation is VT-GSD-SO Authorization Management.
Page 52 of 111
Version 1.93
Classification: internal
SoD Documentation
Review Cycle
The SoD Permission Directory is reviewed on a permanently basis with each change request.
Change Management Regulations
Changes of the documentation follow changes of the permission configuration in PRC (see SAP GRC rule
sets / Change Management / Permission Level).
5.3.5 SAP GRC AC Rule sets
SAP GRC AC architecture
SAP GRC AC is configured with a 3-tier architecture. Development system is DRC, consolidation system
is CRC, and productive system is PRC. SAP GRC AC is implemented as one instance for Henkel
worldwide and connected to the distributed SAP landscape of Henkel.
CRC is connected to SAP ERP development systems (Dxx/Nxx) and to SAP ERP consolidation systems
(Qxx/Kxx/Cxx). CRC is used to run productive SoD analyses on roles changes against consolidation SAP
systems before deployment of these roles to productive SAP systems. Therefore CRC is part of the SoD
framework. Changes of the CRC rule sets have to follow the SoD Governance rules in the same way as
changes on the productive PRC rule set.
PRC is connected to the productive SAP ERP systems at Henkel (Pxx, LA1). PRC is used to run SoD
analyses on user level and to run the provisioning workflow to end users in productive SAP ERP systems.
SAP GRC AC rule sets
The SoD rule sets in DRC which are also active in PRC must have an identical configuration in DRC as in
PRC. Reason: DRC is used productively in the change management process of authorization role
changes.
There are presently 2 SAP GRC AC rule sets defined at Henkel:
CUP rule set
The CUP rule set is a subset of the Corporate Standard SoD. It only defines the SoD risks of level red /
very high, where segregation is mandatory, and Compensating Controls are not allowed. This rule set is
used in the CUP workflow to prohibit the assignment of authorizations to end users that create such a red
SoD conflict.
All other conflicts, where a Compensating Control is allowed by the Corporate Standard SoD (SoD risks of
level orange / high) or where general exceptions are approved by the SoD Coreteam (i.e. red SoD risks in
OTC that are already controlled by a 2-pairs of eyes principle in the SAP system itself, so called built-in
control) are not checked by the CUP workflow. These SoD risks are controlled by the Compensating
Control System.
The CUP rule set presently covers the SoD matrices of the business processes OTC and PTP.
The CUP rule set is used for the Global SoD Cockpit as well as for the System SoD Cockpit.
RAR rule set
The RAR rule set defines all risks of the SoD matrices for OTC and PTP of risk level red / very high, and
orange / high. The RAR rule set is not used in the CUP workflow, but used to analyze SoD risks of roles
and users.
Owner
The content of the SAP GRC rule sets is owned by the SoD Coreteam.
The configuration of the rule sets is owned by the VT-GSD-SO -Authorization Management team.
Classification: internal
Version 1.93
Page 53 of 111
SoD Documentation
Master File
Even if rule sets do not share common objects like SoD risks or SoD functions, the upload functionality
and the transportation functionality of GRC do share common tables.
This requires a joint change management approach with one master file for all changes to the SoD rule
sets in GRC.
SoD Coreteam
IT Service Delivery
CR on
Risks
Approval
Compliance
& Risk Com
CR on
Functions
Approval
SoD
Coreteam
CR on
Permissions
Pre-approved;
check by GSD
CS
SoD
SoD Rel
Trans
Dir
MASTER
FILE RULE
SETS
Upload of
Master File
SoD
Perm
Dir
Test and
Reconciliation
of Rule Sets
Transport of
Rule Sets to
CRC
Recon
Log File
Reconciliation
of Rule Set
DRC
PRC
Transport of
Rule Sets to
PRC
Test and
Reconciliation
of Rule Sets
CRC
PRIMARY SOD DOCUMENTATION
SoD risks and rule sets
The leading master file for SoD risks, soD functions and SoD risk descriptions is the Corporate Standard
SoD. The risk and rule set definitions in SAP GRC have to follow the currently released version of the
Corporate Standard SoD.
SoD transactions
The leading master file for SoD transactions per SoD function is the SoD Relevant Transaction Directory.
The function and transaction configuration in the SAP GRC rule sets have to follow the currently released
version of the SoD Relevant Transaction Directory.
SoD permissions
The leading master file for the permission level of the GRC rule sets is the SoD Permission Directory. The
permissions’ configuration in the SAP GRC rule sets have to follow the currently released version of the
SoD Permission Directory.
MASTER FILE RULE SETS
Any change to the rule set starts with a change of the underlying primary documentation.
All documents are joined in one master file for upload. This master file is common for all processes of the
Corporate Standard SoD.
Page 54 of 111
Version 1.93
Classification: internal
SoD Documentation
Owner of the Master File Rule Sets
SoD Compliance Manager is owning the master file.
Change Management Regulations
The rule sets in CRC and PRC are locked for changes. Only Fire Fighters are allowed in emergency
cases to directly change the rule sets in CRC and PRC.
Any change of the rule set has to follow the following procedure:
1. Definition of change request by businesses, functions, or projects
2. Approval of change request by SoD Coreteam
3. Update of primary documentation by SoD Compliance Manager
4. Update of the Master File Rule Sets by SoD Compliance Manager
5. Upload of rule sets to DRC by VT-GSD-SO -Authorization Management
6. Reconciliation of DRC rule set by SoD Compliance Manager
7. Transportation of rule set from DRC to CRC by VT-GSD-SO -Authorization Management
8. Reconciliation of CRC rule set by SoD Compliance Manager
9. Transportation of rule set to PRC by VT-GSD-SO -Authorization Management
10. Reconciliation of PRC rule set by SoD Compliance Manager
Pre-approved changes for SoD permission level
The decision which transactions are defined on permission level is taken by the SoD Coreteam and
documented in the SoD Relevant Transaction Directory. Any request on adding permission level to further
transactions or removing the permission level from approved transactions requires prior approval of the
SoD Coreteam.
As the configuration of the permission level per transaction requires detailed technical know-how, the SoD
Coreteam decided to delegate the configuration to the VT-GSD-SO -Authorization Management team.
That means: all changes to the permission level in the SAP GRC rule sets are pre-approved by the SoD
Coreteam, as long as
-
the permission level is only changed for transactions where the SoD Coreteam apoproved the
definition of a permission level
-
the definition of the permission level follows general risk considerations, e.g. display activity type
03 = no critical, create/change activity type 01/02 = crtitical.
Each change of the permissions in the SAP GRC rule set has to be documented in the SoD Permission
Directory.
Reconciliation of SAP GRC rule sets
After each change of the SAP GRC rule set a reconciliation to the SoD documentation is required. This
reconciliation needs to be documented in the SoD Compliance Management database for later audit
purposes.
Purpose of the reconciliation is
-
consistency between configured version of the rule sets in SAP GRC and the currently approved
and released version of the SoD Framework
-
consistency between the configuration of the SAP GRC rule set and the documentation of the rule
set
-
consistency between DRC and PRC rule sets
Classification: internal
Version 1.93
Page 55 of 111
SoD Documentation
SoD risks and rule sets
Each change of the SAP GRC risks or rule sets in DRC, CRC, and PRC requires reconciliation against the
Corporate Standard SoD.
SoD functions
Each change of the SAP GRC functions and assigned transactions in DRC, CRC, and PRC requires a
reconciliation against the Corporate Standard SoD and the SoD Relevant Transaction Directory.
SoD permissions
Each change of the permissions defined in DRC, CRC, and PRC requires reconciliation against the SoD
Transaction Directory (which transaction do have a permission level defined) and a reconciliation against
the SoD Permission Directory (to ensure a up-to-date documentation).
Page 56 of 111
Version 1.93
Classification: internal
SoD Documentation
6
Authorization Concept (TO BE REVIEWED)
To move to chapter 3 of ACC
This chapter describes the structure of the authorization concept in SAP (GSP Western Europe).
The Authorization Concept describes the realization of Business Roles in technical SAP settings together
with
-
a concept for coexistence of old and new concept
-
a migration plan for cleaning up user authorization
-
a future mode of operation incl. detailed Change Management process and controls
6.1 Requirements of Authorization Concept
This chapter describes the requirements in the scope of SIGMA project. The requirements have been
categorized in general, technical and business requirements. In addition, the business requirements are
analyzed separately by business. For further details on the requirements please refer to the Requirements
Matrix.
6.1.1 General Requirements
The following general requirements have been identified:
GR-001
All atomic functions must be SoD conflict-free
The atomic components of the to-be business roles must be free of SoD conflicts.
GR-002
No shared ownership of functions between BUs
In the current model, the equivalents to functions are shared between businesses. It is
required that the functions have a unique owner.
GR-003
No shared ownership of Business Roles between BUs
Also business roles won’t be shared between businesses in order to simplify and centralize
their maintenance.
GR-004
Reduce maintenance costs
The authorization concept should help to reduce the maintenance costs of authorizations.
GR-005
Naming for Functions and business roles: easy to identify on the provisioning tool
A new naming convention has to be defined in order to help to identify the functions and
business roles and their description must be in business langauge since they’ll be shown in the
provisioning tool.
GR-006
Prevent 312 SAP Profiles limitation
The actual function and business roles structure leads to problems in the assignment of
business roles to users because of the limit of 312 SAP profiles per user.
GR-007
Apply need-to-know principle
Any user has to be granted the access they strictly need.
GR-008
Naming for Functions and business roles: differentiate between concepts (current and new)
The new naming convention should be descriptive and it has to be possible to differentiate
Classification: internal
Version 1.93
Page 57 of 111
SoD Documentation
between the current and new concept.
GR-009
All business roles must be SoD conflict-free
Each and every business role must be free of SoD conflicts. Their combination can cause
conflicts which will be detected by and their compesating controls documented in the
Compliance control tool.
6.1.2 Technical Requirements
The following technical requirements have been identified:
TR-001
SAP Profiles name should be unique and not system-related
A new naming convention for SAP profiles has to be defined to avoid colliding names when
merging systems (HORIZON Project).
6.2 Dependencies to other Processes
The definitions for the WEU authorizations will have a direct impact on the following R/3 systems:
Region
System
Comments
WEU
P01
WEU
P03
WEU
P08
WEU
P11
WEU
P12
NA
P60
Contains roles from P08
and P01
NA
P62
P12 Mirror
NA
P68
P08 Mirror
MEA
P50
Contains roles from P08
and P01
6.3 Technical Authorization Concept
The technical authorization concept focuses on the detailed technical explanation of the new authorization
concept taking into account the different technical requirements and steps to be accomplished for the
successful implementation.
6.3.1 Definition of Terms
In this section we include the terms we use for the description of the technical authorization concept and
its processes.
Page 58 of 111
Version 1.93
Classification: internal
SoD Documentation
Term
Acronym
Description
Henkel Security Policy
HSP
The Henkel Security Policy is a document which contains the
established security policies within the world-wide Henkel
network.
z-Transactions
Custom Transactions
6.3.2 Background Information
This chapter details background information regarding the current authorization model and the standard
SAP master-derived mechanism.
6.3.2.1
Current model
The current model is based on master functions. Transaction codes are grouped together into master
functions taking into account functional requirements and similar authorization objects. Afterwards those
master functions are derived as required for the diverse businesses with the defined organizational levels
(codification document) and common restrictions. Once derived those (derived) functions are grouped into
business roles (e.g. A/R accounting clerk) to be finally assigned to the users.
6.3.2.2
Master-Derived Mechanism and Organizational Levels
SAP authorization provides the functionality of derived functions.
The idea is to create master functions with authorization data which is shared (transactions,
organizational levels, non-organizational levels) by a certain criteria (e.g. country...). Authorization data
which isn’t shared within the defined criteria won’t be taken into account in the master functions.
Classification: internal
Version 1.93
Page 59 of 111
SoD Documentation
Afterwards derived functions are generated which are linked to the master functions. The derived
functions are generated as copies of the master functions. These derived functions can be adapted with
authorization data which isn’t shared within the defined criteria but it is only allowed for organizational
levels:
Finally the functions can be maintained as following:


Master functions: Mass maintenance for shared authorization data
Modifications of shared authorization data (transactions, organizational levels, nonorganizational levels) needs only to be done in the master function and can be automatically
adapted for the derived functions.
Manually maintenance for authorization data which isn’t shared
Modifications of authorization data (organizational level) which isn’t shared (e.g. company
code, plant…) has to be done manually for the corresponding derived function.
6.3.3 General Structure of Authorization Concept
The new authorization concept is based on composite and single roles. Composite roles correspond to
business roles and single roles correspond to functions.
Composite roles (business roles) are assigned directly to the end users:
Page 60 of 111
Version 1.93
Classification: internal
SoD Documentation
E.g. such a composite role (business role) could be:
Business
UA-OtC
UK-OtC
UW-OtC
UA-PtP
UK-PtP
UW-PtP
Composite Role (Business Role)
OtC Local Administration Foreign Trade
MD Customer
Order Management
Production PtP 01
SC Planner CMM 01
Process GR for components
Composite roles (business roles) don’t contain directly acess rights like transactions and authorization
objects but they are composed of single roles (functions):
E.g. such a single role (function) could be:
Business
UA-OtC
UK-OtC
UW-OtC
UA-PtP
UK-PtP
UW-PtP
Classification: internal
Single Role (Function)
OtC Invoice Creation
Order Entry
Maintain Sales Order
Display Purchase Order
Cancel Goods Receipt
Display Invoices
Version 1.93
Page 61 of 111
SoD Documentation
Finally single roles (functions) contain all authorizations like transactions and technical authorization
objects with values:
The transactions assigned to a single role (function) can be standard and custom transactions. The only
restriction is that the custom transactions have to be available in the development system where the
authorizations are being developed in order to be able to create the corresponding access rights.
6.3.3.1
Single Roles (Functions)
Single roles contain groups of transactions which can be shared with other countries/regions or be local.
Transactions shared by other countries/regions correspond to common processes and local transactions
correspond to local processes:
A. Common processes (global and regional)
B. Local processes (local)
Common processes
For common processes single roles (functions) are used and the standard SAP mechanism of master and
derived functions will be applied. The corresponding functions are called master functions and derived
functions.
Master functions are collections of transaction codes and access rights of a particular business process
which correspond to a common process in order to be shared.
As master functions are template versions they shouldn’t be assigned to business roles because they
don’t contain organizational levels values (company code, plant …).
Derived functions will be created for all master functions of the security concept in order to implement
organizational splits. Derived functions are based on master functions and contain the same access rights
as the master functions. In addition derived functions contain access rights which can be exclusively
controlled by organizational levels (company code, plants, sales organizations…) defined for the domains.
The master and derived functions will be divided into global and regional depending on the business
requirements. Global business roles must be composed by global functions and regional business roles
Page 62 of 111
Version 1.93
Classification: internal
SoD Documentation
must be composed by regional functions:
Local processes
For local processes also single roles (functions) are used but without the mechanism of master and
derived functions. They are called local functions.
Local functions are collections of transaction codes and access rights of a local business process. Local
functions are never master functions and can’t be derived.
6.3.4 Domains and their usage
The following statements define a domain and its usage:
1. Domain is a way of identifying a given set of authorizations objects, fields, org. levels, and their
values usually related to a company or country
2. Domains are documented in the codification document
3. Domains are used as an input for derivation.
The domain code usually contains the country and further specifications (splittings) such as company
code, plant, shipping point, etc. However, some business roles and functions do have special
codifications.
Classification: internal
Version 1.93
Page 63 of 111
SoD Documentation
A domain consists always of 5 characters and is structured as follows:
DDDDD (5)
o
DDddd (2) the first 2 characters determines the country or region code, e.g. BE, DE, etc. (see
appendix)
o
ddDDD (3) determines further splits (company, plant, shipping point), e.g. HKA (BX - Cosmetics
ACC), CDB (DE – Centr. Log UA/UT).
Exceptions:
-
Template functions must have all organizational values set as blank. They are coded by 5 Ts
TTTTT.
-
Functions with organizational values set to * are coded by using an X, e.g. XXXXX (no org.level
restrictions), DEXXX (restricted by country = germany only) , etc.
-
Functions which don’t contain any organizational values are coded using Z. e.g ZZZZZ (typically
used for custom transactions)
Domains usually follow a tree structure for each country, in the picture below the domain tree for UK is
shown:
6.3.4.1
Codification document
The codification document is an Excel spreadsheet which is used to document the domains, their values
and their owners. Changes of existing or creation of new domains must be updated manually.
The codification document is used to determine domain owners and domain values, to find new available
domains and to analyze domain structures.
In order to reduce complexity it has been defined one codification document by region (AP, CEE, LA,
MENA, NA, WEU).
Page 64 of 111
Version 1.93
Classification: internal
SoD Documentation
The Excel Spreadsheet is structured as follows (e.g. WEU):
The tabs are structured in three sections:

First tab: Domains
In the first tab all domains are listed by country (exceptions are regions NORDEN, BENELUX and X for
corporate…) and additional description (e.g. DE, DE-UA, BX, BE-Purchasing). The domains must be
unique and are linked to the corresponding tab and field which contains the domains’ details.
The grouping by additional description can be used as applies. If it isn’t desired to use an additional
description the domain should be always listed by region or country (or exceptions).
Classification: internal
Version 1.93
Page 65 of 111
SoD Documentation

Second and third tab: Domain hierarchy queries and data
If a new organizational values needs to be updated in a certain domain it has to be also done in the
corresponding parent domains.
The second tab called ‘Data Entry’ provides a tool to determine automatically the parent domains:
The yellow field, right to ‘Input Domain’ is used to enter the domain in order to determine the
corresponding parent domains. Once entered the tab displays automatically the parent domains, e.g.
DECAX:
In our example the domain DECAX has 4 parent domains.
Page 66 of 111
Version 1.93
Classification: internal
SoD Documentation
The third tab called ‘Domain table’ contains the relation between domain and parent domain in order to be
determined in the previous tab:

Domains details
The rest of the tabs contain the domain detail: Modules, fields, descriptions, objects, owners…and the
domain values. The domain detail is linked directly to the domains listed in the first tab.
Classification: internal
Version 1.93
Page 67 of 111
SoD Documentation
Maintenance of the codification document
Depending on the type of change to be done one or more steps have to be followed in order to update the
codification document:
A. New value added/removed to/from an existing domain
The domain detail tab has to be accessed and the corresponding values has to be
added/removed to/from the corresponding value.
B. New domain is created
First the new domain has to be added to the corresponding list in the first tab. Here it has to
be analyzed if a new column has to be created or the domain can be added to an existing
one. A new column will require a new tab.
Then the column detail has to be added to the corresponding detail tab (or a new tab has to
be added) and the inserted domain in the first tab has to be linked with the detail tab (and the
domain position).
Finally the relation of the domain and their parent domains have to be updated in the third tab.
6.3.5 Naming Convention
In order to provide a simple concept for an easy maintenance and understanding, a shared naming
convention has been defined for the business roles, functions and SAP profiles.
In addition, the naming convention helps to identify the role/function owners.
6.3.5.1
Business Roles
The naming convention for business roles is:
ABC_DDDDD_EEEEEEEEEEEEEEEEEEEE (30)
Where
 A (1) defines the role scope (region): A (AP), C (CEE), G (Global), L (LA), M (MENA), N (NA), P
(Local), W (WEU)
 B (1) defines the business (A, K…)
 C (1) defines the process (OtC, PtP…)
 D (5) is the domain code (see previous chapter “Domains and their Usage”)
 E (20) is the description (or part of it)
Example:
GWO_DEDXX_ORDER_MANAGEMENT - Global composite role for Germany and company Dorus
Bopfingen for UW and OtC process with description “Order Management”.
Page 68 of 111
Version 1.93
Classification: internal
SoD Documentation
6.3.5.2
Functions
There are three different types of functions which have to be considered for the naming convention.

Master (template)

Derived

Local
Master functions
Master functions are used as templates for derivation. They contain the complete transaction set but all
organizational values are set to ‘ ‘ (blank).
The naming convention for master functions is as follows:
ABCDDDDDNNF_EEEEEEEEEEEEEEEEEE (30)
Where
 A (1) defines the function scope (region): A (AP), C (CEE), G (Global), L (LA), M (MENA), N (NA), W
(WEU)
 B (1) defines the business (A, K…)
 C (1) defines the process (OtC, PtP…)
 D (5) is the domain, for master functions must be always “TTTTT”
 NN (2) is a consecutive alphanumeric numbering used to get unique names within the first 10
characters of the role name.
 F (1) is the type of activity: A (Administration = edit), D (Display), X (mixed)
 E (18) contains the description (or part of it)
Example:
WKPTTTTT01D_DISPLAY_PO – Western Europe master function #1 for UK and PtP process with activity
display and description “Display Purchase Order”.
Derived functions
Derived functions are obtained by deriving the master functions. They contain the same transactions
contents as the master with the addition of values to the organizational levels.
The naming convention for derived functions is as follows:
ABCDDDDDNNF_EEEEEEEEEEEEEEEEEE (30)
Where
 A (1) same as master function
 B (1) same as master function
 C (1) same as master function
Classification: internal
Version 1.93
Page 69 of 111
SoD Documentation
 D (5) is the domain for derived functions (see previous chapter “Domains and their Usage”)
 NN (2) same as master function
 F (1) same as master function
 E (18) same as master function
Example:
WKPDED1X01D_DISPLAY_PO – Western Europe derived function #1 for Germany and company Dorus
Bopfingen with split between plants for UK and PtP process with description “Display Purchase Order”.
Local functions
Local functions should contain only transactions that are being used within the scope of a country or
department. As no further splits or instances of this kind of functions is expected, they are not intended to
be derived.
Local functions will be used only for local business roles. In the case of the need of using a local function
between different departments or countries, a regional (hence template/derived) function must be
considered.
The naming convention for local functions is as follows:
ABCDDDDDNNF_EEEEEEEEEEEEEEEEEE (30)
Where
 A (1) defines the function range (region): P (Local)
 B (1) defines the business (A, K…)
 C (1) defines the process (OtC, PtP…)
 D (5) is the domain, for local functions the domain code XXXXX should not be used (see previous
chapter “Domains and their Usage”)
 NN (2) is a consecutive alphanumeric numbering
 F (1) is the type of activity: A (Administration = edit), D (Display), X (mixed)
 E (18) contains the description (or part of it)
Important: Attention with the consecutive numbering. All local functions must be unique within the first 10
characters. Otherwise duplicated profiles can be generated.
Example:
PFOBELXX23X_TAX_REPORT_BELGIUM – Local function #23 for Belgium and company Henkel Loctite
for Finance and process OtC with description “Tax report Belgium”.
Page 70 of 111
Version 1.93
Classification: internal
SoD Documentation
6.3.5.3
SAP Profiles
A technical requirement of SAP is to define a naming convention for the SAP profiles in order to prevent
the overwriting and/or errors due to duplicated profiles.
The naming convention for SAP profiles can be directly derived of the function name, it corresponds to the
first ten characters:
ABCDDDDDNN (10)
 A (1) same as function
 B (1) same as function
 C (1) same as function
 D (5) same as function
 NN (2) same as function
E.g. the profiles of the examples above should be as following:

WKPTTTTT01D_DISPLAY_PO -> WKPTTTTT01

WKPDED1X01D_DISPLAY_PO -> WKPDED1X01

PFOBELXX23X_TAX_REPORT_BELGIUM -> PFOBELXX23
Important: The consecutive numbering must be reviewed before assigning the profile name in order to
prevent duplicate profile names.
6.3.6 Future mode of operation and maintenance
6.3.6.1
Prerequisites
-
All relevant Process Owners and Role Owners are named and take charge
-
All new Business Roles have to be developed for the new authorization concept following the
policies and procedures described in chapter 4.3: “User Authorization Configuration” involving
Process Owners and Role Owners
-
All new Business Roles to be developed for the new authorization concept pass SoD check to
ensure SoD conflict-free Roles.
6.3.6.2
Ownership
Ownership is a key concept for the authorizations model described in this document. All components of
the authorizations concept must be owned by a Role Owner (as described in section “3.14 Role Owner”
above).
For this reason, the first three characters of the business role or function name define their ownership.
ABC_DDDDD_EEEEEEEEEEEEEEEEEEEE (30)
 A (1) defines the role scope (region): A (AP), C (CEE), G (Global), L (LA), M (MENA), N (NA), P
(Local), W (WEU)
 B (1) defines the business (A, K…)
Classification: internal
Version 1.93
Page 71 of 111
SoD Documentation
 C (1) defines the process (OtC, PtP…)
Hence the ABC part of the name describes the owneship of the role as described in the following table:
Global
Regional
Local
G (Global)
A (AP), C (CEE), L (LA), M
(MENA), N (NA), W (WEU)
P (Local)
Global business roles, global
derived functions, global master
(template functions), global
domains
Regional business roles, regional
derived functions, regional
master (template functions),
regional domains
Local business roles, local
functions, local domains
In addition depending on the type of change the corresponding owner has to be determined:
Transactions
When a transaction is requested the ticket should be deal by SPOC of ACN. He will check if both area of
the requester and of the transaction are the same. In case that both are equal, transaction will be added.
In case that both are not equal, Authorizations team will request the approval of the Process Owner of
requested transaction area. Look the matrix for the approval:
When Authorizations team will have doubts about a transaction, they will first contact with their counter
part in Henkel, second with the boss of their counter part, third their IT Global business consultant in order
to get the accurate information of the transaction and be able than to identify the correct process owner
for the approval.
The Accenture team will save in the share point an excel sheet with all ticket information and approvals
attached in the tickets, as is described in the Matrix_approval_history spreadsheet.
Page 72 of 111
Version 1.93
Classification: internal
SoD Documentation
Authorization Objects
When a change of a value of an authorization object is requested it has to be checked if the requester and
the owner are the same person (see codification document). In case to be the same person the change
will be processed. In case they aren’t a approval of the domain owner will be requested.
In addition there are for some authorization objects specific authorization object owners (see codification
document). In case that a change affects an authorization object of an authorization object owner then the
approval has to be requested to authorization object owner instead of the domain owner.
6.3.6.3
Business Role Creation
Business roles will be always created in the development system N08. Once tested the business roles are
transported to the corresponding production system.
Business roles must be classified into common process business roles and local process business roles.
Common process business roles correspond to global or regional (AP, CEE, LA, MENA, NA, WEU)
shared processes and local business roles to local processes which aren’t shared.
Once determined if a business role is common or local the corresponding functions have to be assigned.
For global business roles it must be assigned only global derived functions:
For regional business roles it must be assigned only regional derived functions:
Classification: internal
Version 1.93
Page 73 of 111
SoD Documentation
For local process business roles it must be assigned only local functions:
6.3.6.4
Function Creation
There are three types of functions which have to be considered. For common processes master functions
and the corresponding derived functions must be used. For specific processes local functions must be
used.
Master functions
Master functions contain directly all transactions and access rights of a certain business process but the
organizational values (company code, plant, sales organization…) are blank.
Derived functions
Technically it is first needed to create the derived function, link it to the corresponding master function and
then derive the master function. Then the authorizations of the master function will be mapped to the
derived function so that the derived function contains the same transactions and access rights as the
master function. Finally the organizational values are adapted.
Transactions and access rights must never be changed, deleted or extended in the derived function. This
will be always done through the master function.
Local functions
Local functions contain directly all transaction and access rights including organizational values of a local
business process.
6.3.6.5
Business Roles Update
Business roles will be always updated in the development system N08. Once tested the business roles
are transported to the corresponding production system.
There can be different reasons for a business role update:
A. Update of transactions
Transactions can’t be added or deleted directly from business roles. It has to be analyzed which
functions are affected and depending on the type of function the following has to be considered:

Master function
First it has to be taken into account that a master function will be derived and therefore
the update will affect all derived functions assigned to a master function.
Page 74 of 111
Version 1.93
Classification: internal
SoD Documentation
Then the transactions have to be added and/or removed and the corresponding
authorization objects have to adapted. Finally the master function has to be saved,
generated and derived.

Derived function
Transactions must never be updated in derived functions.

Local function
Transactions have to be directly added and/or removed and the corresponding
authorization objects have to be adapted. Finally the local function has to be saved and
generated.
B. Update of non-organizational authorization data
Non-organizational authorization data (e.g. document type…) can’t be added, changed or deleted
directly from business roles. It has to be analyzed which functions are and depending on the type
of function the following has to be considered:

Master function
First it has to be taken into account that a master function will be derived and therefore
the update will affect all derived functions assigned to this master function.
Then the non-organizational data has to be updated. Finally the master function has to be
saved, generated and derived.

Derived function
Non-organizational authorization data must never be updated in derived functions.

Local function
Non-organizational authorization data has to be directly updated. Finally the local function
has to be saved and generated.
C. Update of organizational authorization data
Organizational authorization data (e.g. company code…) can’t be added, changed or deleted
directly from business roles. It has to be analyzed which functions are affected and depending on
the type of function the following has to be considered:

Master function
Non-organizational authorization data must never be updated in master functions. This is
done in the corresponding derived functions.

Derived function
Organizational data has to be directly updated in derived functions. Finally the derived
function has to be saved and generated.

Local function
Organizational authorization data has to be directly updated. Finally the local function has
to be saved and generated.
Classification: internal
Version 1.93
Page 75 of 111
SoD Documentation
6.3.7 SU24
The standard SAP transaction SU24 is used to control different properties of transactions and their
authorization objects.
Once executed for a certain transaction code SU24 contains the relationship between transaction code,
authorization object, check indicator and proposal, e.g. for FBL5N:
The possible configurations are per transaction code and authorization object are:
1. CHECK INDICATOR
a. C = Check (if checked in the ABAP code)
b. N = Do not check (even if checked in the ABAP code)
2. PROPOSAL
a. YES (CM) = Pulls all maintained objects, their fields and values into the role when the
transaction, function module or service is added to the menu tab in transaction PFCG
b. NO (N) = Objects are not proposed in PFCG but will generally be checked even if not
required for the transaction
c.
`` (U) = Unmaintained or unknown
The configuration of SU24 is directly linked to the profile generator (PFCG). The different configurations of
SU24 do have the following impacts:

Authorization objects which never need to be checked can be disabled so that they don’t appear
automatically in PFCG and won’t be checked in SAP

Authorization objects which should be always checked but shouldn’t be proposed in PFCG can be
defined so that they don’t appear automatically in PFCG

Authorization objects which should be always checked and proposed in PFCG but without a
proposed value can be defined so that they appear automatically in PFCG but the values have to
be entered (yellow light)
Page 76 of 111
Version 1.93
Classification: internal
SoD Documentation

Authorization objects which should be always checked, proposed in PFCG with their values can
be defined so that they appear automatically in PFCG and don’t need further processing (green
light)

Changes of settings in SU24 can be updated directly to roles (read old, merge new" option in
PFCG)
The following restrictions have to be taken into account during the maintenance of SU24:

SAP best practices recommend avoiding manually entered authorization objects and changes of
proposed authorization values in PFCG.

Some authorization objects proposed by SAP in the SU24 aren’t coded in the corresponding
programs and therefore aren’t checked.

Parameter transactions are linked to core transactions (see SE93, e.g. F-04 -> FB05) and
therefore core authorization objects can be pulled from core transactions
Custom transactions and authorization objects have to be added manually to SU24.
Release upgrades require additional control of SU24 in order to avoid inconsistencies


6.3.7.1
SU24 - Future mode of operation and maintenance
The following processes have been defined for the maintenance of the SU24:
A. Elimination of proposed Security Policy Conflicts
The actual SU24 entries have been analyzed and it has been determined that actually in the
development system N08 there are approx. 4000 entries of SU24 proposing authorization objects
with values generating SoD conflicts. These entries will be adapted in order to propose values
which don’t cause conflicts.
B. CustomTransactions Authorization Objects
All custom transactions must be maintained in SU24. Additionally all authorization objects of
transactions called by the transaction have to be also maintained.
Important: The future mode of operation depends directly on the requirements of the new compliance
control tool and will be reviewed once the selection of the compliance control tool is made.
6.3.8 Customer specific authorization objects
It will be always recommended to use SAP standard authorization objects in order to fulfill all
requirements. However, if there aren’t alternative standard authorization objects available it has to be
analyzed at transaction level if customer specific authorization objects can be implemented. In case of
implementation it has to be taken into account that customer specific authorization objects require ABAP
development. Customer specific authorization objects have always to start with Y or Z.
6.3.9 Authorization Groups
Authorization groups aren’t used.
Classification: internal
Version 1.93
Page 77 of 111
SoD Documentation
6.3.10 Further Restrictions
The direct access to SAP applications, programs and tables won’t be permitted to end users. Examples
for restricted transactions are:
o
Tables: SE16, SM30/SM31
o
Programs: SE38
o
Queries: SQ00
The process to follow is to create a Z-transaction with the corresponding technical authorization objects.
6.3.11 Current Business Roles
In this section we describe the managament of special functions and Business Roles that are out of the
scope of SIGMA but need to be considered as a part of the concept because they deal with special or
critical access.
6.3.11.1
IT Business Roles
IT Business Roles aren’t in the scope of project SIGMA therefore they will be managed according to the
current authorization concept.
IT Business Roles are based on CC with the following levels:
Level 1:
Level 2:
Level 3:
Level 4:
Display
Maintenance tasks on daily basis. Approval from the
business is required
Basic critical tasks
Maintenance tasks for a project. It has a validity date.
Currently there are IT Business Roles defined for the following divisions:















Page 78 of 111
ALE
BI
CAS
EDI
FI:
o COPA
o COPC
ITG
LOG
o INV
o MP
o QM
o SCP
o WM
o PTP
PM/PS
ARCHIVING
BASIS
CRM
MD
HELPDESK
Application Responsible
SD
Version 1.93
Classification: internal
SoD Documentation


o GTS
User Admin
XAS- Authorizations
Rule for the development of IT Business Roles:
The following rules are used since July 2009.

Level 1:
DAAXXXXXBITXD
AA = system where the role is developed/maintained
XXXXX = is fixed, to denote it’s a master Function
B = is the module following the standard SAP R/3 abbreviation for modules.
ITX = is fixed, to denote it’s IT function
D = Display

Level 2:
DAAXXXXXBITXA_CCC
AA = system where the role is developed/maintained
XXXXX = is fixed, to denote it’s a master function
B = is the module following the standard SAP R/3 abbreviation for modules.
ITX = is fixed, to denote it’s IT function
A = Maintain
CCC = Competence Center

Level 3 and Level 4:
The functions are the same as used in the normal business roles
These Business Roles are maintained in template. This means that only a CC manager can raise a CR to
modify the authorizations on the function. It is no valid to create a remedy ticket.
6.3.11.2
Intercompany Business Roles
Users with intercompany Busines roles have to manage processes not only in one country/company but
all companies within an area (WE, NA…). To ensure the access rights to the desired processes and
countries a local business role will be created.
6.3.11.3
Corporate Business Roles
Users with corporate Business Roles have to access processes within different countries in order to give
support to local users. To warranty the access rights to the desired processes and countries a local
business role will be created.
6.3.11.4
SSC Shared Service Center Business Roles
Users with shared service center Business Roles have to access particular processes within certain
countries. To ensure the access rights to the desired processes and countries a local business role will be
created.
Classification: internal
Version 1.93
Page 79 of 111
SoD Documentation
6.3.11.5
RFC/CPIC and Batch Userid Business Roles
Roles for RFC and batch users aren’t in scope and will be managed according to the actual authorization
model:
RFC and Batch userids might have the need for special authorizations to perform their tasks. These type
of userids can’t be called in dialog mode; so if an authorization error is presumed, it will be necessary to
set up a security trace in order to find out the correct authorizations needed. Be aware that not all
checked objects are required for this userid, because SAP is checking all statements in the program and
the values found in the trace need to be interpreted.
The naming convention of the business roles for these userids doesn’t differ from the standard naming
convention. However since most of these userids will be used for several countries, companies or any
other type of organizational element no restriction indicator will be required (unless if the need is
specifically defined).
Example: D01XXX_RFC_OTCRFC Function for RFC userid OTCRFC.
This Business Role can contain any normal type of function, but sometimes, it is necessary to define a
special Function for one of these userids, due to the results obtained in the tracing. In this case a specific
function should be created which contains the specific objects for the RFC activity. The function usually
doesn’t contain transactions in the menu, in contradiction to normal functions.
Regarding the naming of these special functions, the current naming convention should be respected
which is valid for all functions. It should be unique within the Henkel server landscape with respect to the
specific naming conventions corresponding to the respective development system where it is developed.
As a module indicator the letter ‘R’ must be used.
Example: D08XXXXXRZ01A Henkel Custom: OTCRFC authorizations.
In this case the task is valid for the P08/P68 only. General functions must include a Y after the module
indicator.
The same rules are applicable for batch userids, but here the naming convention of the batch userids will
contain BTC instead of RFC.
Example: D12XXX_BTC_ARCHIVING
Batch userids will contain normally more regular functions for reasons of background processing of batch
inputs etc.
6.3.12 Emergency procedure : Quickfixes
The Quickfix procedure allows for fast authorization error support without business interruption while
preserving the regular change management procedures.
The regular change management procedure on security changes is that if a role / function needs to be
adjusted due to an identified authorization error, the change is to take place in the development
environment. Subsequent transports will make the change available in the Test- or Production
environment.
This is still the most recommended approach towards security problems, however, depending on the
project phase or situation, timeliness may be more important and a faster way of dealing with
authorization errors is desirable. That approach may have to overcome the transport latency, but should
not undo or neglect proper change management practices.
The Quick Fix Procedure is simple, provides with the ability to quickly fix security problems and to keep
track of an “error history”.
In brief, the Quick Fix Procedure works as follows:
Page 80 of 111
Version 1.93
Classification: internal
SoD Documentation
1. Authorization Error. An authorization error is reported by a user. This error is to be addressed in a
timely manner;
2. Recording of the Issue. The security administrator requests the authorization error information
electronically. The user should provide with transaction code, SU53 information and his/her own
user-ID and contact information;
3. Quick Fix. If an authorization object or field value is missing in the existing role(s), a manual profile is
created using transaction SU02. This manual profile has naming convention ZFIX#### where each
the “####” is a sequential number. Also note that if the user needs a particular transaction code or
access that was not allocated according to the FU-TA, the solution is NOT quickfixing, but informing
the user that he/she was not authorized by the responsible manager to have that functionality!
Note that each ZFIX#### profile must have a decent description indicating the problem or a reference
to the issue recording (step 2). The sequential number starts from 0001 and for each problem the
number is incremented with 1;
4. Allocation to user. The quick fix manual profile is allocated to the end user that had the problem and
depending on the situation to other users that share the problem or responsibility of that particular
user. Note that this is a direct user assignment of a manual profile;
5. Informing the User. Steps 2,3 and 4 have a walk-through time of maximum 5 minutes. Once the
authorizations of the user were changed, inform the user (preferrably by phone) that the problem was
fixed and he/she needs to logoff/logon to test whether it now works.
6. Fixing the backlog. On a daily basis and preferrably as soon as time is available, the actual master
tasks and derived tasks are to be updated with the information contained in the quickfix. This means
that analysis has to take place to see what value/object was missing from which role and whether it
was the proper solution to give these access rights to the user. The failing authorization role(s) are
updated with the appropriate objects and values in the Development Environment and are set ready
for transport to the appropriate environments.
In this step, the validity and completeness of the information in the issue recording (step 2) is critical. If
no proper list is maintained and the SU53 information etc. is not kept, it is impossible to effectively
clean-up and update the authorization concept;
7. Cleaning Up. After the corrected roles were transported correctly, the Quickfix profiles and
authorizations are to be removed from the users and deleted. Note that in the end, ALL quickfixes are
to be deleted. Fixes should be fixed at a daily basis and no fix should survive for more than 5 working
days.
8. Documentation. Even if the quickfix is deleted in the next working day, the quickfix has to be
documented in the AS database. In the documentation database you can find the template file and the
instructions to document quickfixes.
9. Role instead of profile. If needed, or if the analyst considers it is a better way of solving the
incidence, the quickfix can be created as a role instead of a profile. The naming convention should
remain the same. The role can be created when the fix should remain for some time ( because a
permanent solution cannot be applied for any reason or the exception has been approved).
The advantages of the QuickFix procedure are:

The change management procedure on roles is still in place. No deviation from this
procedure is made;
Classification: internal
Version 1.93
Page 81 of 111
SoD Documentation

User problems can be addressed in the fastest possible way. No transport latencies are
stopping the business processes;

A clear trail of manual profiles with a uniform naming convention is made available that
shows the errors that occurred and what work has to be done subsequently;

If proper change management and discipline is within the security department, all
authorization errors are ressolved using the change management procedure and fixes are
only temporary.
The risks in this procedure are:

Exposure. Administrators may allocate quickfixes to users without considering the functiontask matrix where responsibilities are shown. This means that users may receive
unauthorized access. The positive thing within this procedure is that the exposure to this risk
is limited as quickfixes should be solved on the same day;

Deviation. The risk exists that administrators are not following the steps as described in this
procedure to the very end – that is – fixes are created and allocated, but not really solved in
the security roles. Alternatively, the administrators could “forget” to remove the fixprofiles
after they have transported the corrected roles. This would eventually result in a unclear
concept and it would become unclear whether or not problems were already solved;
Page 82 of 111
Version 1.93
Classification: internal
SoD Documentation
7
Software (TO BE UPDATED)
This chapter describes the tool landscape for the processes listed in chapter 4: “Identity & Access
Management Processes”.
7.1 Overview of SoD Tool Landscape
Can stay here.
SCT
SoD Framework Gov.
IAM 600-604
SoD Framework
SCT
RO
SAP GRC AC
SAP ERP
RAR
BIC
SoD Compliance Ctrl
IAM 501-510
RA
RA
CUP
SV
User
Authorizations
User Auth. Admin
IAM 200-210
User
RO
PTP
OTC
process
User Auth. Config.
IAM 300-310
COCOS
SoD Compliance Ctrl
IAM 500
Compensating
Control Reports
RAP
IdM
HAD
User Auth. Admin
IAM 210
User ID Administration
IAM 001-003 / IAM 100-110
User Auth. Ownership
IAM 400-411
Roles:
-
SCT – SoD Coreteam (in persona: SoD Compliance Manager)
-
RO – Role Owner
-
RA – Role Admin
-
User – End user of SAP ERP system
-
SV – Supervisor of end user
Tools:
-
RAR
-
CUP
-
COCOS
-
RAP
-
BIC
Classification: internal
Version 1.93
Page 83 of 111
SoD Documentation
-
HAD
7.2 Tools
7.2.1 SAP GR AC – Access Control
Can stay here as focus is only on SoD.
7.2.1.1
Overview
7.2.1.2
CUP - Compliant User Provisioning
Overview CUP workflow
Supervisor:
- notified via mail on
authorization change
Role Admin (SPOC):
- Check request
- Select auth. roles
- SoD Risk Analysis
- Remediation in case of SoD conflicts
- Reject or approve
Stage 0
Stage 1
Request
Role
Selection
End User:
- Free Text: “I need …”
- Reasoning
- Selection of system
- Selection of Role Admin
Stage 2
Stage 2
Role
Stage 2
Approval
Role
approval
Role
Approval
SAP
System:
Automatic
provisioning/
removal of roles
in SAP system
Role Admin (Approver):
- Risk Analysis
- Reject or approve
A Compliant User Provisioning workflow needs to be activated at the very end of the
SoD implementation in order to ensure that users are kept SoD-compliant. The CUP
tool prevents from assigning new red SoD-conflicts in the future w/o mitigation control.
7.2.1.3
RAR – Risk Assessment & Remediation
Overview
RAR is a component of the SAP GRC AC tool suite. RAR analyzes user authorizations and role design on
potential SoD conflicts. RAR uses a rule set defined in the master data of the RAR tool.
RAR SoD Role Analysis
RAR offers functionality to analyze SoD conflicts within authorization roles. Please refer to the training
documentation provided in the Portal (http://CUP/).
The Role analysis is conducted in each role change (see process 4.3.2: “Change Role (IAM-301)”).
Typically the SoD analysis is done on Consolidation system before the roles are transported to productive
SAP. In this case RAR is running in CRC, which is connected to all SAP ERP consolidation systems.
Page 84 of 111
Version 1.93
Classification: internal
SoD Documentation
The output of the RAR analysis can be downloaded into a SoD Template Excel for role analysis which
helps to identify the root causes of SoD conflicts.
RAR SoD User Analysis
RAR offers functionality to analyze SoD conflicts on user level. Please refer to the training documentation
provided in the Portal (http://CUP/).
The SoD user analysis is mandatory in each CUP request (i.e. risk violation analysis), but can also be run
manually for one user or a user group via the RAR tool.
The SoD user analysis is done on Productive system PRC which is connected to all productive SAP ERP
systems.
The output of the RAR analysis can be downloaded into a SoD Template Excel for user analysis which
helps to identify the root causes of SoD conflicts.
7.2.2 COCOS – Compensating Control System
Stay here as focus is only on SoD.
7.2.2.1
Overview
The Compensating Control System at Henkel is not looking at the authorization level (i.e. what a user is
allowed to do), but on the actual transactions in the system (i.e. what a user actually posted).
In each SAP ERP system various Compensating Control reports are activated which screen all postings
made during a past period, and detect if one and the same user posted two steps in a document which
should be posted by two different persons following the Corporate Standard SoD. These “potential SoD
violations” are stored in a central table per SAP system and transferred to a globally centralized SAP table
in the SAP GRC database. Supervisor information is added from the central user administration tool HAD,
which is synchronized with the Global HR system.
Classification: internal
Version 1.93
Page 85 of 111
SoD Documentation
Compensating Control System (COCOS)
Technical Overview
Compensating
Control
Reports
HR
Supervisor
Information
Weekly trigger mail to
Supervisors to check
Compensating Control
with link to Web
application
P01
…
SAP
GRC
P93
“Watch Dogs” for SoD violations
16 Compensating Control reports
per SAP system detect actual SoD
violations on document level
(e.g. same user created purchase
order and posted the goods receipt)
Web application for
supervisors to check
and approve
Compensating Control
reports
Central Data Storage
of all SoD violations
and logging of
approval / disapproval
by Supervisors
in SAP GRC
Approve
Logging of approvals
in Central Data
Storage on SAP GRC
GRC – SAP tool “Governance, Risk & Compliance“
Page 5
28-Nov-2012
SoD @ Henkel / COCOS
If one or more employees of a supervisor’s team are listed in the central table, the Supervisor is informed
via mail to check these cases and to approve. In SAP the transactions are executed and are not waiting
for this approval. So the Compensating Control approval is an ex-post approval.
The approval of the Supervisor is logged in the central table in the SAP GRC for later audit purposes.
Please visit the SoD Forum to learn more about the COCOS tool and to find a eLearning document for
training purposes (http://sodforum/)
7.2.2.2
COCOS Web Tool
7.2.2.3
COCOS Data Collection + Mail Notifying
7.2.2.4
Compensating Control Reports OTC
Page 86 of 111
Version 1.93
Classification: internal
SoD Documentation
7.2.2.5
Compensating Control Reports PTP
7.2.3 BIC – SAP ERP Built-in Controls
Stay here as focus is only on SoD.
7.2.3.1
Overview
7.2.3.2
Built-in Controls OTC
7.2.3.3
Built-in Controls PTP
7.2.4 RAP – Reapply Roles
To be moved to ACC chapter 5.
7.2.4.1
Overview
Program 1 : RAP Mass change of
end validity date
Program 2 : RAP Data collector
Program 3 : RAP Email sending
HR
User IDs
Supervisor
Information
P01
…
PRC
P93
Report that collects auth/user and
checks if roles will not expire
8 wks prior to first role
would be expired with
info on what to do to
user
First reminder : 4 wks
prior to first role would
be expired with info
on what to do to user
+ cc supervisor
Second reminder : 3
days prior to first role
would be expired with
info on what to do to
user + cc supervisor
The RAP tool is actually a collection of individual programs rather than a tool suite. Basic idea of the
review process is not to do a review of user authorizations. Instead all user authorizations of dialogue
users are limited to 4 months and users have to request a prolongation (i.e. “re-apply”).
For this purpose the same CUP tool is used:
Classification: internal
Version 1.93
Page 87 of 111
SoD Documentation
CUP request workflow
1) User creates a CUP request to prolong his
authorisations and assigns this to his Role Admin (SPOC)
2) Role admin (SPOC) selects "Existing Assignments" + Action
"Retain“ where needed + runs optional SoD Check
Role admin can overwrite the validity period
The validity period should be automatically set to
today+XX month
Role owner
3) Role assignment approver(s) will receive the request and
will judge on the retention of the roles or not and runs
an SOD check.
4) Enduser + supervisor receives a notification
User
SPOC
Profile updated
7.2.4.2
RAP Program “Mass Change Validity Periods”
7.2.4.3
RAP Program “RAP Data collector”
7.2.4.4
RAP Program “RAP e-mail sending”
Page 88 of 111
Version 1.93
Classification: internal
SoD Documentation
7.3 Operational Model
????
7.3.1 Tool Ownership
7.3.2 Incident Management Regulations
-link to Incident Management document???
7.3.3 Change Management Regulations
Link to Change Management document???
Classification: internal
Version 1.93
Page 89 of 111
SoD Documentation
8
Reporting & KPI
Stay here.
8.1 Global SoD Anaylsis (GSODA)
On a monthly basis all SAP users worldwide are analyzed on red SoD conflicts. The users are reported
per country / business unit where the users are located, independent of the country and SAP system the
users are working for. E.g. a user in the SSC Philippines working for NA is reported in APAC / Philippines.
GSODA is analyzing SoD conflicts within a system (e.g. Purchase order and payment in P01) as well as
cross-system SoD risks (e.g. Master data on corporate SAP master data system P03 (IDH) X payment
on Finance SAP system P08).
8.1.1 KPI definition
The KPI “SoD Compliance (GSODA)” is defined as
#users having no red SoD conflict (single system or cross-system SoD conflicts)
----------------------------------------------------------------------------------------------------------- x 100
#users having access to SAP ERP systems in scope
[in %]
8.1.2 Scope
All SAP ERP users w/w of the systems in scope are analyzed.
SAP systems in scope are
WEU: P01, P03, P08, P11, P12
NA:
P03, P60, P62, P68
MEA:
P03, P50, P92
APAC: P03, P93
LA:
P03, LA1
CEE:
none
SAP ERP system not in scope:
APAC: HK2
being substituted by P93 by program Horizon (included in scope above)
CEE:
being substituted by P92 by program Horizon (included in scope above)
HP1
and all non-ERP SAP systems covering APO, HR, CRM etc.
Page 90 of 111
Version 1.93
Classification: internal
SoD Documentation
as of Jan 9, 2013
Global SoD Analysis
Henkel
Total number of users: 17.319
SoD compliant: 11.901 (69%)
Henkel by Regions
Henkel by Regions
9.000
100%
8.000
90%
7.000
80%
70%
#Users
#Users
6.000
5.000
4.000
3.000
60%
50%
40%
30%
2.000
20%
1.000
10%
0
0%
AP
LA
MEA
NA
WEU
AE (P72)
Others
AP
LA
MEA
Henkel by BU/Function
WEU
AE (P72)
Others
Total
Henkel by BU/Function
9.000
100%
8.000
90%
7.000
80%
70%
#Users
6.000
#Users
NA
5.000
4.000
3.000
60%
50%
40%
30%
2.000
20%
1.000
10%
0
0%
W
K
A
FO
FP
FC
FS
Red SoD conflicts
SoD compliant
Page 4
9-Jan-2013
HR
VS
VT
Others
W
K
A
FO
FP
FC
FS
HR
VS
VT
Others
Total
AP: P93 (Horizon) only; CEE: not included, will be connected via Horizon
Region “Others”: Users working for different region only
Segregation of Duties @ Henkel - KPIs
8.2 System SoD Analysis (SSODA)
On a monthly basis all SAP users worldwide are analyzed on red SoD conflicts. The users are reported
per system they have access to. E.g. a user in the SSC Philippines working for NA (P68) is reported on
P68 (NA).
SSODA is analyzing SoD conflicts within a system only. Cross-system SoD risks are neglected.
8.2.1 KPI definition
KPI “SoD Compliance (SSODA)” is defined as
#users having no red SoD conflict (single system SoD risks only)
-------------------------------------------------------------------------------------#users having access to SAP ERP systems in scope
x 100
[in %]
8.2.2 Scope
All SAP ERP users w/w of the systems in scope are analyzed.
SAP systems in scope are
WEU: P01, P03, P08, P11, P12
NA:
P03, P60, P62, P68
MEA:
P03, P50, P92
Classification: internal
Version 1.93
Page 91 of 111
SoD Documentation
APAC: P03, P93
LA:
P03, LA1
CEE:
none
SAP ERP system not in scope:
APAC: HK2
being substituted by P93 by program Horizon (included in scope above)
CEE:
being substituted by P92 by program Horizon (included in scope above)
HP1
and all non-ERP SAP systems covering APO, HR, CRM etc.
as of Jan 14, 2013
System SoD Analysis
Henkel1)
Total No of SAP accounts2): 30.103
SoD compliant: 21.463 (71%)
Henkel by SAP Systems
Henkel by SAP Systems
6.000
100%
90%
5.000
80%
70%
#Users
#Users
4.000
3.000
2.000
60%
50%
40%
30%
20%
1.000
10%
0
0%
P01
P03
P08
P11
P12
P50
P60
P62
P68
LA1
P72
P92
P93
P01
P03
P08
P11
Henkel by SAP Platforms
P50
P60
P62
P68
LA1
P72
P92
P93
Total
Henkel by SAP Platforms
16.000
100%
14.000
90%
80%
12.000
70%
#Users
10.000
#Users
P12
8.000
6.000
60%
50%
40%
30%
4.000
20%
2.000
10%
0
0%
CORP
GSP WEU
GSP NA
Red SoD conflicts
SoD compliant
Page 2
Page 92 of 111
9-Jan-2013
GSP MEA
LA1
HORIZON
1)
2)
Global AE
CORP
GSP WEU
GSP NA
GSP MEA
LA1
HORIZON
Global AE
Total
HK2 (APAC) and HP1 (CEE) not included, will be connected via Horizon
Total No. of SAP users: 17.319
Segregation of Duties @ Henkel - KPIs
Version 1.93
Classification: internal
SoD Documentation
9
Training & e-Learning
Stay here???
9.1 SoD Portal Page
A Henkel portal page serves as first contact for end users and Role Admins. The portal page explains to
the end user how to request authorizations with the CUP tool.
A special section for Role Admins explains how to run RAR analyses and how to proceed CUP requests.
The Portal page is available in some country versions, translated in local language.
The Portal page is open for every user at Henkel.
Link: http://portal.de.henkelgroup.net/irj/portal/global/8VQKMQ898JREN
Portal Short Cuts: CUP, RAR, SOD, SIGMA, PRC, GRC
9.2 SoD Forum
The SoD Forum is a discussion forum including a Q&A section for all topics around SoD.
The SoD Forum is available in English only.
The SoD Forum is open for every user at Henkel.
Link: http://connections.henkelgroup.net/communities/community/sod
Portal Shortcut: sodforum
Classification: internal
Version 1.93
Page 93 of 111
SoD Documentation
9.3 Training
Can stay here.
9.3.1 CUP tool
9.3.1.1
CUP tool training for end users
Target group:
End users working with SAP ERP systems
Available training types:
end user manual (PPT)
e-Learning Video
no classroom training available
Access to training:
via SoD Portal Page
Contact:
Britta Winkelmeyer@henkel.com
9.3.1.2
CUP tool training for Role Admins
Target group:
Role Admins (SPOC)
Role Admins (Assignment Approvers)
Available training types:
Classroom + Remote Training Sessions
Training document (PPT)
e-Learning Video
Access to training:
via SoD Portal Page
Contact:
Britta Winkelmeyer@henkel.com
9.3.2 RAR tool
Target group:
Page 94 of 111
Role Admins (SPOC)
Version 1.93
Classification: internal
SoD Documentation
Role Admins (Assignment Approvers)
Role Owners
Available training types:
Classroom + Remote Training Sessions
Training documents on RAR analyses (PPT)
e-Learning Video
Access to training:
via SoD Portal Page / Instructions for Role Administrators
Contact:
Britta Winkelmeyer@henkel.com
9.3.3 COCOS tool
Target group:
Supervisors
Available training types:
Help function in COCOS tool
COCOS manual for Supervisors
no classroom training available
Access to training:
via SoD Forum: “Compensating Control System COCOS:
How does this work?”
Link:
SOD FORUM_COCOS
Contact:
Frank.Junglas@henkel.com
Classification: internal
Version 1.93
Page 95 of 111
SoD Documentation
10 Appendix
10.1 FAQ
10.2 Glossary
Stay here.
Term
Acronym
Description
Access Rights
A user needs a user-ID and a password, and access rights
assigned to the user-ID to be able to enter IT systems or
applications. This authentication does not automatically imply
authorization within the IT system. It’s like the “key to the main
entrance of a building”.
Authorization Concept
The Authorization Concept describes the structure and design of
authorizations to users. An authorization concept is defined in
Enterprise Roles and Business Roles in business terms, as well
as a translation into technical authorization objects within an IT
system (Technical Authorization Concept).
Authorization
Configuration
processes and compliance controls
configuration of Business Roles
Authorizations
Authorizations (also privileges, entitlements, permissions)
determine what a user can do on the system, once
authenticated with user-ID and password. Authorizations enable
users to use certain functionality or to display information of the
IT system. Authorizations are like “keys to doors within a
building”.
Built-in Controls
Built-in system behavior that prevents a user to conduct two
functions that are defined as a SoD risk. This control is a
Segregation of Duties, when certified as “proven security”.
that
support
the
Example: A user has the authorization to create a purchase
order and to book a goods receipt against purchase orders. A
built-in control could be a user exit in SAP that blocks a user
from booking a goods receipt against purchase orders, the user
created him/herself. If it is proven that no user can by-pass the
Built-In Control, this control is a valid Segregation of Duties.
Business Roles
Compliance Control Tool
Page 96 of 111
Business Roles (or Roles in this context) define groups of
authorizations within an IT system in business terms. Roles
contain the authorizations that a user needs to work. Role
Administrators grant authorizations to employees or external
staff (users) by assigning specific Roles to their user-IDs.
CCT
The Compliance Control Tool is used in the provisioning process
of user authorizations. It contains the SoD rule set as master
Version 1.93
Classification: internal
SoD Documentation
data. Main tasks are
-
Detective reports on SoD conflicts
-
Preventive SoD
authorizations
-
SoD checks of authorization role changes
-
Exception handling
checks
on
requests
for
new
COBIT
The Control Objectives for Information and related Technology
(COBIT) is a set of best practices (framework) for information
technology (IT) management created by the Information
Systems Audit and Control Association (ISACA), and the IT
Governance Institute (ITGI) in 1996. COBIT provides managers,
auditors, and IT users with a set of generally accepted
measures, indicators, processes and best practices to assist
them in maximizing the benefits derived through the use of
information technology and developing appropriate IT
governance and control in a company.
Compensating Controls
Compensating Controls are controls which compensate for
missing segregations of duties (i.e. for approved SoD conflicts).
These can be:
-
Preventive Controls: Ex-ante controls that prevent fraud
e.g. “2-pairs-of-eyes”-principle at credit note processing
Detective Controls: Ex-post controls that allow detecting
if unwanted events of SoD risks have occurred. Where
automated systems provide basis information for
detective controls, manual monitoring processes are
required for review of this information.
Example: An exception report is regularly provided by
IT-application and lists the actual bookings by users with
SoD-conflicts; the manager in charge is required to
review this report timely and to sign-off the listed
transactions retrospectively.
Critical Roles
Critical Transactions
Some Roles might be critical in itself. Reasons might be:
-
Role that bear a SoD conflict in itself (defined
exceptions)
-
Privileged authorizations for e.g. process owner, key
user, etc
-
Collection of critical transactions in a critical role to
control their assignment to users
Some single transactions have an inherent risk and are defined
as critical transactions.
Examples:
Classification: internal
Version 1.93
-
Technical transaction: Debugging with
(prohibited by IT Security Policy in all cases)
replace
-
Business transaction: Release of vendor payment block
(only assigned to a limited number of well instructed
Page 97 of 111
SoD Documentation
users)
Detective Controls
Detective controls detect the occurrence of SoD risks ex-post.
Controls can be
Enterprise Roles
-
Periodic monitoring of user accounts with approved SoD
conflicts
-
Compensating Controls like manual ex-post review of
actual user bookings
Enterprise Roles define access rights and authorizations within
the entire enterprise, i.e. across IT systems and applications.
Global SAP Platform
GSP
Globally standardized business processes and standard SAP
systems
Henkel Meta Directory
HMD
…
Identity and Access
Management
IAM
IAM is an administrative area that deals with identifying
individuals in a system (such as a country, a network or an
organization) and controlling the access to resources in that
system by placing restrictions on the established identities.
Identity Management
IdM
Process and tool landscape for managing the lifecycle of userIDs. Services: User administration, IAM Request Mgmt, IAMReports.
ISO 27002
ISO 27002 is an information security standard published by the
International Organization for Standardization (ISO). ISO 27002
provides best practice recommendations on information security
management for use by those responsible for initiating,
implementing or maintaining Information Security Management
Systems (ISMS).
Least Authority
See Need-to-Know principle
Least User Access
See Need-to-Know principle
Least-Privilege
See Need-to-Know principle
Need-to-Know Principle
The Need-to-Know Principle (also known as least user access,
least privilege, or least authority) describes a security concept,
in which all users at all times should run with as few
authorizations as possible, and also launch applications with as
few access rights as possible.
The principle is widely recognized as an important design
consideration in enhancing the protection of data and
functionality from faults (fault tolerance) and malicious behavior
(computer security).
Preventive Controls
Privileged Authorizations
Page 98 of 111
Controls that prevent the occurrence of SoD risks. Controls can
be
-
Segregation of Duties in role design
-
Segregation of Duties in user authorizations
-
Built-In Controls in business transactions
-
Compensating Controls like additional “2-pairs-of-eyes”principle.
Some users need access rights and authorizations beyond the
Version 1.93
Classification: internal
SoD Documentation
usual scope or beyond the profile of the employee, in order to
support others or other topics. Examples can be a Key User, a
Business Process Owner, a temporary project member, etc.
The Privileged Authorizations assigned in these cases require a
special handling and controls beyond the usual control.
Request & Workflow
Tool
R&WT
Roles
Segregation of Duties
The Request and Workflow tool is used by end-users to place
requests on assignment or removal of authorization roles and to
direct the request to a named Role Admin
See Business Roles
SoD
Segregation of duties (SoD) is the concept of having more than
one person required to complete a task. Besides organizational
measures this includes the segregation of access rights to and
authorizations within the corresponding IT systems.
SoD Compliance
Governance
processes and compliance controls that support the Governance
of SoD Compliance
SoD Conflict
A SoD conflict occurs, when a user actually has the
authorization to conduct a combination of duties in a business
process that is defined as a high or very high SoD Risk in the
SoD Framework.
Depending on the risk rating, SoD Conflicts can be neglected
(low risk), or require approval (high risk, controlled with a
Compensating Control). In case of very high risk, SoD conflicts
are not allowed; the duties have to be segregated.
SoD Controls
The segregation of areas of responsibility in business processes
and of corresponding authorizations, access rights, and built-in
system behavior within the IT systems is called SoD Control.
This is a preventive control against SoD-risks.
SoD Framework
The SoD Framework is a set of rules that defines which
combinations of functions have to be segregated in a business
process in order to mitigate the risk of fraud and erroneous
transactions.
SoD Risks
The SoD Framework (see chapter 10.4: “Enclosures”) defines
combinations of duties as “High” or “Very High” risk. These
potential combinations are called SoD Risks. The combinations
are marked in the SoD matrix as “High” or “Very High” and are
described in the SoD Risk Register with examples.
Technical Authorizations
Technical Authorizations define the technical objects with an IT
system (e.g. SAP tables, transactions, plant, sales organization,
etc.
Dangerous Combination
of Roles
The Authorization Concept uses Roles that group authorizations
which a user needs to execute business functions in an IT
system. Objective is to ease the assignment of authorizations to
users, but also to ensure that every user has exactly the
authorizations he/she needs to perform business functions in a
compliant way.
Roles are designed not to have a SoD conflict within the role
itself. I.e. every user with one role assigned shall be free of SoD
conflicts. Only with the assignment of two or more roles to a
Classification: internal
Version 1.93
Page 99 of 111
SoD Documentation
user, a SoD conflict might occur.
There exist pairs of Roles that contain duties that are marked as
a SoD risk in the SoD framework. With the assignment of both
Roles to a user, a SoD conflict occurs. The combination of these
Roles is called a Dangerous Combination.
Example: Role “Procurement” and Role “Warehouse” are in
itself free of SoD risks. The role “Procurement” contains among
others the function “create purchase order” and the role
“Warehouse” contains among others the function “book goods
receipt”. The combination of these functions (“create purchase
order” and “book goods receipt”) is a SoD risk identified in the
SoD matrix. Thus assigning the two roles “Procurement” and
“Warehouse” to a single user would lead to a SoD conflict. I.e.
“Procurement” and “Warehouse” are a.
User
A user is a person in a company that uses an IT system.
User Authorization
Administration
processes and compliance controls that support the life cycle of
user authorizations within an IT system
User ID Administration
processes and compliance controls that support the life cycle of
user IDs
User-ID
A user-ID (also called user account) identifies a user (employee
or Contractor) within the company by the username. It allows
one to authenticate to IT systems. It also generally provides one
with the opportunity to be authorized to access them.
Page 100 of 111
Version 1.93
Classification: internal
SoD Documentation
10.3 Acronyms
Acronym
Acceptation
AC
Access Control
ACL
Access Control List
ADS
Active Directory Service
BI
Business Intelligence
BPO
Business Process Owner
CCT
Compliance Control Tool
COBIT
Control Objectives for Information and related Technology
CUP
Compliant user provisioning component
GHR
Global HR System
GRC
Governance, Risk, and Compliance.
Here: Synonym for software to check and monitor SoD compliance
GSD
Global Service Delivery (IT)
GSP
Global System Program (Global SAP Platform)
HAD
Henkel Active Directory
HMD
Henkel Meta Directory (IT tool)
HR
Human Resources
IAM
Identity & Access Management
IdM
Identity Management
ISO
International Organization for Standardization
IT
Information Technology
JCo
Java Connector
LDAP
Lightweight Directory Access Protocol
OTC
Order-to-Cash
PTP
Purchase-to-Pay
RAR
Risk analysis and removal
RFC
Remote Function Call
RTA
Real time agent
R&WT
Request and Workflow Tool
SAP BO AC
SAP Business Objects Access Control (GRC)
SMTP
Simple Mail Transfer Protocol
SoD
Segregation of Duties
SPML
Service Provisioning Markup Language
VIA
Internal Audit at Henkel
Classification: internal
Version 1.93
Page 101 of 111
SoD Documentation
10.3.1.1
Country codes
Stay here or to place in ACC.
The country codes are fixed and only the below indicated country codes may be used.




ID
Country
AT
Austria
BE
Belgium
BX
Benelux
CH
Switzerland
CN
China
DA
Denmark
DE
Germany
ES
Spain
FI
Finland
FR
France
GR
Greece
HK
Hong Kong
IB
Iberia
IR
Ireland
IT
Italy
LU
Luxembourg
NL
Netherlands
NA
North-Americas
NO
Norway
PT
Portugal
SW
Sweden
TU
Turkey
UK
United Kingdom
US
United States
Note 1: BX is the combined codification of NL, LU and BE;
Note 2: NA is currently used for North-America, in the future this will be changed to the
appropriate ISO country codes;
Note 3: Not all countries where Henkel has representation are listed. Countries are added when
addressed in the current projects.
Note 4: IB is the combined codification of ES and PT
Page 102 of 111
Version 1.93
Classification: internal
SoD Documentation
10.3.1.2
Company Indicator
Stay here or to place in ACC.
The company code indicator is a 1-character identifier for a particular enterprise within the GSP systems.
Initially, a logical abbreviation is seeked (H for Henkel, L for Loctite, S for Schwarzkopf). This is done
because these businesses re-occur in many countries. If no logical character can be found, a sequential
alphabetical character will be set to use.
Note that deciding the appropriate character is a technical security team decision that has no impact on
the project(s) or the business. Below the currently allocated combinations are shown:
Classification: internal
Country
AT
Company
S
Description
Schwarzkopf Austria
BE
H
Henkel Belgium
BE
L
Henkel Loctite
BX
H
Henkel Benelux
BX
S
Schwarzkopf Benelux
BX
X
Benelux General
CA
T
Canada Service Technologies
DE
A
HENKEL KGaA /TM/SE (Sichel)
DE
B
HENKELTeroson Heidelberg
DE
D
Dorus Bopfingen
DE
K
Cognis
DE
DE
O
S
SHCP Schwartzkopf Henkel C. Production
Schwarzkopf Hamburg
DE
T
Service Technologies – Germany
DE
Z
Concept Task for non-migrated KgaA
FR
L
Loctite Luxembourg
FR
T
Luxembourg Service Technologies
FR
Z
France old concept
IR
L
Loctite Ireland
IT
T
Italy Technologies
IT
H
Italy Henkel SPA
IT
S
Italy Schwarzkopf & Henkel
LU
C
Chemolux Luxembourg
NA
A
North-America (U.S.)
NA
C
Henkel Canada
NA
X
North-America General
NL
H
Henkel Netherlands
UK
L
Loctite UK
UK
S
Schwarzkopf UK
US
D
U.S. Dial
XX
S
Schwarzkopf International
Version 1.93
Page 103 of 111
SoD Documentation
10.3.1.3
Business and Process Indicator
The business and process code indicator is a 1-character identifier for a particular business and process
within the GSP systems. Initially, a logical abbreviation is seeked (I for IT, F for finance, O for OtC...). If no
logical character can be found, a sequential alphabetical character will be set to use.
Note that deciding the appropriate character is a technical security team decision that has no other
impact. Below the currently allocated combinations are shown:
Page 104 of 111
ID
Business
A
Adhesive
I
IT
F
Finance
K
Cosmetics
W
Detergent
ID
Process
O
OtC
P
PtP
Version 1.93
Classification: internal
SoD Documentation
10.4 Enclosures
Stay here.
10.4.1 SoD Governance
10.4.1.1
Corporate Standard SoD
Location:
 HimDOC: http://sf-apps-i201.de.henkelgroup.net/corporate/sustainability/himdochg.nsf
Contact: Christian.twehues@henkel.com
10.4.1.2
SoD Relevant Transaction Directory
Location:
 Lotus Notes Database “SoD Compliance Management”
 Folder “SoD Documentation”
 Document: “3. SoD Relevant Transaction Directory”
Contact: Christian.twehues@henkel.com
10.4.1.3
SoD Relevant Permission Directory
Location:
 Lotus Notes Database “SoD Compliance Management”
 Folder “SoD Documentation”
 Document: “ 4. SoD Permission Directory”
Contact: Christian.twehues@henkel.com
10.4.1.4
GRC SoD Rule Set Documentation
Location:
 Lotus Notes Database “SoD Compliance Management”
 Folder “SoD Documentation”
 Document: “ 5. GRC SoD Rule Set Documentation”
Contact: Christian.twehues@henkel.com
10.4.1.5
SoD Compensating Control Directory
Location:
 Lotus Notes Database “SoD Compliance Management”
 Folder “SoD Documentation”
 Document: “ 6. SoD Compensating Control Directory”
Contact: Christian.twehues@henkel.com
10.4.1.6
SoD Built In Controls
Location:
 Lotus Notes Database “SoD Compliance Management”
Classification: internal
Version 1.93
Page 105 of 111
SoD Documentation
 Folder “SoD Documentation”
 Document: “7. SoD Built-in Controls”
Contact: Christian.twehues@henkel.com
10.4.1.7
SoD Compensating Control Reports
Location:
 Lotus Notes Database “SoD Compliance Management”
 Folder “SoD Documentation”
 Document: “8. Compensating Control Reports”
Contact: Christian.twehues@henkel.com
Page 106 of 111
Version 1.93
Classification: internal
SoD Documentation
10.4.2 Authorization Management
10.4.2.1
Global Role Ownership files
 Lotus Notes Database “Project SIGMA-2”
 Folder “SoD Green Roles”
 Document: “1. Global Role Ownership”
Contact: Javier.Alvarez@henkel.com
10.4.2.2
Regional Role Ownership files
 Lotus Notes Database “Project SIGMA-2”
 Folder “SoD Green Roles”
 Document: “2. Regional Role Ownership”
Contact: Javier.Alvarez@henkel.com
10.4.2.3
Local Role Ownership files
 Lotus Notes Database “Project SIGMA-2”
 Folder “SoD Green Roles”
 Document: “3. Local Role Ownership”
Contact: Javier.Alvarez@henkel.com
10.4.2.4
Role Admin (SPOC) Table
 Lotus Notes Database “Project SIGMA-2”
 Folder “SoD Green Roles”
 Document: “4. Role Admin (SPOC) table for Role Selection Stage 1 in CUP”
Contact: Javier.Alvarez@henkel.com
10.4.2.5
Role Admin (Assignment Approver) Table
 Lotus Notes Database “Project SIGMA-2”
 Folder “SoD Green Roles”
 Document: “4. Role Admins for Role Approval Stage 2 in CUP”
Contact: Javier.Alvarez@henkel.com
Classification: internal
Version 1.93
Page 107 of 111
SoD Documentation
10.5 Revision History and Document Reviews
Revision history
Version
Author
Date
Revision
v 0.10
V 0.11
Christian Twehues
Christian Twehues
16 August 2010
18 August 2010
V 0.12
V 0.13
Christian Twehues
Christian Twehues
18. August 2010
19. August 2010
V 0.14
Christian Twehues
19. August 2010
V 0.15
Christian Twehues
23.08.2010
V 0.16
V 0.17
Christian Twehues
Christian Twehues
27.08.2010
3.09.2010
V 0.18
V 0.19
Christian Twehues
Christian Twehues
7.09.2010
10.09.2010
V 0.20
V 0.21
V 0.22
V 1.00
Christian Twehues
Christian Twehues
Christian Twehues
Christian Twehues
21.09.2010
22.09.2010
23.09.2010
24.09.2010
V 1.01
Christian Twehues
27.09.2010
V 1.02
V 1.03
Christian Twehues
Christian Twehues
5.10.2010
27.10.2010
V1.04
Koen Menten
15.11.2010
V1.05
Javier Romera
22.11.2010
V 1.06
Diego Alvarado
23.11.2010
V 1.07
Christian Twehues
30.11.2010
V 1.08
V 1.90
Christian Twehues
Christian Twehues
13.12.2010
24.01.2013
V1.91
V1.92
Christian Twehues
Christian Twehues
22.02.2013
23.04.2013
V1.93
Christian Twehues
23.09.2013
Initial version
Check on consistency of Organizational Concept,
Compliance Controls, IAM Process design, and
Tool analysis.
Process Numbering changed
Process “Define Compensating Controls” and
“Review Compensating Controls” changed from
Role Owner responsibility to BPO responsibility
Confirmation of 1-step approval for request and 2step approval for exception approval by S. Braun;
Review of concept with Layla El Kastite on
consistent Controls
Feedback of First Integration Test (Role of
Compensating Control Receiver skipped, tasks
assigned to Supervisor, et al)
Feedback of Stefan Braun, VIA
Feedback of Coreteam on Organizational
Concept: Changes to Role Owner and Role Admin
Roles
Feedback of Second Integration Test of Sept 6
Review of Chapter 9 and specified detailed
requirements
Several smaller corrections after review with HR
Detailed requirements (chapter 9.7 – 9.9) added.
Update of chapter 9.7.3, 9.8.1, and 9.8.2
Approval of Chapter 1-7 by Sounding Board
Approval of chapter 9 by IT (SIGMA Tool Analysis)
Results of Business Roles Requirements Analysis
added to Chapter 8
Feedback of Barbara Schmitz
Correction of smaller errors; description of Control
C43
Documentation Built-In and Compensating
Controls for PTP added
Documentation Built-In and Compensating
Controls for PTP added
Documentation of Henkel Authorization Concept,
Coexistence Plan, Migration Plan
Feedback of KPMG on Technical Authorization
Concept
Documentation of functional specification of tools
Documentation of the finally implemented
processes and tools; first DRAFT
General editing
Update of chapter 5: SoD Governance. After
installation of CRC system (consolidation system),
and after HR joining the SAP GRC, the SoD
governance framework required final stage
Change of IAM-200: SoD Risk Analysis mandatory
at stage 1-Role Selection and optional at stage 2Role Approval (before vice versa)
Page 108 of 111
Version 1.93
Classification: internal
SoD Documentation
This document has been reviewed by
Reviewer (Name, Organizational Unit)
Date reviewed
1
First integration test (Felix Sobotka, Ilka Erkens, Andy Fischer, Nils Jung,
Barbara Schmitz, Joachim Dahl, Layla El Kastite, Gereon Koks, Christoph
Gramp, jochen.wiedemann@accenture.com): Processes IAM-200-203 and
IAM-300-303 only
Aug. 23, 2010
2
Stefan Braun, VIA
Aug. 26, 2010
3
Coreteam, Feedback received from Barbara Schmitz, Gereon Koks, Felix
Sobotka (and Martin Andersen for chapter 4 processes and tools)
Sept 3, 2010
4
Second integration test (Felix Sobotka, Andy Fischer, Barbara Schmitz, Layla
El Kastite, Gereon Koks): All Processes
Sep 6, 2010
5
Ina Schreckenberger
Sep 20, 2010
6
b
Sep 23, 2010
7
SIGMA Sounding Board
Sep 24, 2010
8
KPMG (chapter 8 & 12)
Nov 26, 2010
9
This document was approved by
Chapter
Reviewer (Name, Organizational Unit)
Date
reviewed
1
1 to 4.4
SIGMA Coreteam
Sep 20, 2010
2
1 to 7
SIGMA Sounding Board
Sep 24, 2010
3
9
IT (SIGMA Tool Analysis)
Sep 24, 2010
4
9
IT (GSD, PCA-ARC, SIGMA Tool Analysis)
Nov 5, 2010
5
9
ARC Fit Meeting
Nov 5, 2010
6
8
SIGMA Coreteam
Nov 15, 2010
7
1-12
SIGMA Sounding Board
Nov 19, 2010
8
9
SIGMA Coreteam (Request Tool within Compliance Control Tool)
Nov 22, 2010
9
V1.93
SoD Coreteam
June 27, 2013
Classification: internal
Version 1.93
Page 109 of 111
SoD Documentation
Page 110 of 111
Version 1.93
Classification: internal
SoD Documentation
Classification: internal
Version 1.93
Page 111 of 111