SAP GRC Implementation Process
SAP GRC Implementation process
Top-down approach, where it starts by defining security requirements up front during the blueprint phase.
The first step is to work with the business process owners (BPO’s), functional leads to identify the business processes and applications in-scope of the SAP project and finalizing the SoD policies and risk ratings (Critical, High, Medium, and low).
Critical Risk represents significant impact to company operations. Risk cannot be mitigated, it requires remediation.
Examples are
Hight Risk represents financial risk and causes loss or theft. Risk may be mitigated with proper management level report or it may require remediation.
Medium Risk represents medium profit and loss impact and disrupts an operational process. The risk can be mitigated with a management level report.
Low risk can be mitigated
The definitions vary from company to company. Once the SoD policies and risks are defined, SAP standard and custom transactions should be evaluated and created for identified risks. Finally, these transactions are grouped into job functions (creating GL accounts, posting payments) and should be configured as rulesets, which are used to analyze SoD conflicts at the role or user level.
Apart from SoD policies and risk definitions, companies has to define the sensitive transactions to enable monitoring and reporting on SAP roles and users who have add, modify, delete or even display access to the company’s sensitive information such as vendor pricing, customer lists, financial data, HR information etc.
If it is a new security implementation, then role matrix needs to be created. The role matrix basically consists of role technical name, transaction code and its description. For this, transaction logs are analyzed to determine the set of monthly, quarterly or year end transactions that should be included in the newly designed SAP roles. The role matrix needs to be updated based on the BPO’s inputs.
The next step is to define the “role owners” for each role. Role owners are typically part of the functional implementation or business teams and usually responsible for managing and reporting on the data being updated by the SAP transactions and roles they own. For example, addition of SAP transactions, deletion, modification, and approval of mitigating controls if conflicts occur.
Once the role matrix is created and approved, then the roles can be created and assigned to users. The technical design phase starts with building the “master roles” or template roles. The next step is designing the SAP roles is to create “derived” or “child roles” which is where security restrictions are applied such as company code or cost center limitations.
End user role assignment is critical step when designing the SAP application security because some user may need one role, multiple or all company code roles. While assigning the roles to users it is important to that roles are SoD free. If the master roles have inherited the SoD conflicts, then all derived roles and subsequently assigned users will have conflicts.
Periodic role and user analysis need to be done for the newly designed roles that are in compliance with SoD policies. Risk analysis should be executed periodically. It is important that initially created ruleset in SAP access control may require changes based on addition or deletion of the new SAP transactions or creation of custom transactions.
Risk simulation needs to be performed before granting user access or modifying a role. This determine weather role or user changes are causing SoD or excessive access security risks.
SAP security unit testing and user acceptance testing are very important steps to make sure users will be having minimal access issues prior to go-live. Testing of security includes executing all the t.codes within a role to confirm that role has required transactions and authorization objects to complete the process. Testing of SAP security also include Segregation of Duties and sensitive access reviews to confirm that the newly created or updated SAP roles are SoD conflict free. It is also important to create test users for final UAT process in the quality system with the SAP roles to be used in the production environment.
Once the testing is complete, the new SAP roles can be migrated to the production system as per the company’s change management policy and users can be assigned. Support team needs to be established to address the SAP access issues during the go-live. The team not only resolves the access issues, but also run access risk reports to determine if security changes will result in SoD or other access risks.
Comments
Post a Comment