Professional Documents
Culture Documents
1. Authorization concept.
The authorization concept must be set up according to the following guiding principles:
Transparency: the concept must be clear and easy to understand for all people involved
Controllability: the roles are created in such a manner that they allow for user authorization
review and user risk remediation
Maintainability: the roles are created in such a manner that they allow for easy maintenance
Flexibility: the roles are set up to be able to handle any organizational change
The authorization concept is documented in a Concept matrix. The composite roles, single roles
and transaction codes, including descriptions, are contained in this document. With regard to
the Concept definition the following is adhered to:
The roles in this concept are designed according to need to have authorizations.
The composite roles contain derived single roles and are designed to provide all specific
authorization for a specific HR function/ Job in a specific company.
The single roles are designed to provide access to one specific task in the SAP system. The
transaction codes are therefore logically grouped in the various single roles.
The following detailed guidelines provide more detailed guidelines which support the guidelines
as stated above.
Single Role
3. SAP CC is Accountable and Responsible for the design and creation of single roles. The
business provides input as to required transactions and access (contents).
4. Master-derived Relationship
The single roles are created according to the master derived principle.
This means that non-organizational roles changes are done in the master roles and
organizational changes are done in the derived role.
5. Single roles are free from SOD risks according to the CRH GRC Ruleset.
SOD risks as defined in the CRH GRC rule set do not exist in single roles, technical privileged
access is only contained in technical single roles.
6. Technical and functional authorizations are segregated
Technical and functional transactions and authorization objects are not included in the same
single role, as far as this is possible.
7. Custom transactions are only added to roles if proper security measures are in place
This means that at least one OpCo restrictive authorization check is embedded in the related
program and that has been aligned with the business and SAP CC Security.
8. Custom transactions and custom authorization objects are configured in SU24 set up
When a new custom transaction is created, this transaction is configured in transaction SU24 to:
make sure related authorization objects are pulled into a role when the transaction is
entered into a role.
be able to control (in)activity of authorization objects.
Roles for display contain only display transactions and authorization object values.
Transactions are only added to roles in the menu tab not directly in S_Tcode.
The type of role and the contents of the role are clearly described in the description tab of the
role.
The transactions in the menu of the single master roles are entered in a proper folder structure
where the main folder contains the single role description.
13. Single roles comply with the CRH Role naming convention.
Composite role
15. SAP CC is responsible for the creation and maintenance of composite roles. The business
provides input as to required single roles for a specific HR function/ Job (contents).
16. Composite roles are free from SOD risks according to the CRH GRC Rule set
SOD risks as defined in the CRH GRC rule set do not exist in composite roles; single roles
containing technical privileged access are only added to composite roles at business request.
The type of role and the contents of the role is clearly described in the description tab of the
role.
General
21. SAP Standard roles are not assigned and therefore not available on productive systems.
Only when absolutely required for proper functioning of applications are SAP standard roles
assigned and available on productive systems.
Each role has a role owner assigned, which can determine who should be assigned to the role.
This is for change management and for GRC workflow purposes.
Role changes are performed in development and transported across the landscape after test
and approval.
Change to the authorization concept are periodically updated in the Concept Definition
Matrix
24. Roles are not shared between regular end users and special users.