Hi there world!
Today I wanted to share a few tips and trick with you for remediating your SoD Access Risks using GRC 10.x.
Ok, so you’ve finished your GRC Implementation and now you are able to easily query your SoD and Critical Risks. Frankly, you might be panicking… 100,000 conflicts?!!?!! In the words of my people “OY VEY!” Here’s a quick step-by-step for starting to tackle the impossible.
- Start from the bottom up with your roles. It’s impossible to remediate your users’ access without clean roles. For this reason, a task-based role design is the best approach. Roles should be free of inherent SoD conflicts, which you can query via NWBC—>Access Management—> Risk Analysis —> Role Level.
- Create a critical action risk for each function that make up your SoD risks. Run Role Level Risk Analysis as above, but this time for Critical Action Risks. Make sure that your roles are free from unintentional access that could have a financial business impact, this again correlates to a task-based role design.
- Be wary of assigning users access to roles with a lot of transactions and permissions even if they are only display only. This can cause an issue due to the “borrowed authorization concept” in SAP Security. In that many transactions check for the same authorizations and user access cannot be viewed in a silo within a single role. Transactions can borrow permissions within other roles.
- Time to begin remediating access at a user level! NWBC—>Access Management—> Risk Analysis —> User Level. Run User Level Risk Analysis for Critical Actions Risks created previously, first. Because the roles are now clean of inherent conflicts, unnecessary access should be able to be removed via a role removal process, rather than via role mediation.
- We can now run User Level Risk Analysis again at the Permission (SoD Risk) Level. It is now possible to remediate user access by removing roles to remove any avoidable SoD conflicts.
- Lastly is Mitigating Control assignment for any remainaing and ONLY unavoidable SoD conflicts.