Risks review - Post GRC AC 10 implementation

[Former Member]

We have finshed with the implementation of AC 10 and got the reports with the user and role risks. Now we have different reports of conflicts and wants to start remediating it. But I am unsure from where to start, whether to remove the tcodes from the roles, or better to redesign the role with the limited transactions.

I tried to come up with this, not sure if this is the right approach.

First review Role analysis report

A) Try to remove the transactions not applicable to the role. OR - Role not applicable to the user.

B)Split the roles if different users involved.

Later, User analysis report

A) If risk cannot be removed, find a solution or create a Firefighter role if its critical or rare used tcode.

B) If there is no option found to remove the risk, mitigate the risk with the approval.

[former_member771067 · Accepted solution]

Hi,

Frank is absolutely right. your risk definition should reflect your customer needs. Cutomize the ruleset if doesn't meet your requiremnet. Just addition to Frank, try to keep the Single Roles clean first, then the Composite Roles and after then only try to keep the user level by either removing the risk else mitigating them.

Thanks,

Guru

[Former Member · Accepted solution]

Thanks Frank and Guru,

I agree that ruleset should be customized according to Business requirement. But if we provide them the option to disable the rules in the standard risk, dont you think that they will more prefer this option more rather than remediating or mitigating the risk.

I am saying this as Business people doesnt give much importance to this and will try to finish the process by suggesting to disable to rules wherever they find conflicts. Also I dont think they will be interested to provide their inputs to add more risk and function to the standard ruleset.

[Former Member · Accepted solution]

I completely agree to what experts have said . You can also review these below points to make your remediation process easy and effective.

1. Is the Risk valid for our business.

2. Should the violating role be assigned to User.

3. Should the violating role , have this Tcode.

4. Is the Tcode appropriately secured.

5. Is there a external control for the User/ role.

Cheers .. Vikas

[koehntopp]

That's always a difficult process after roles get too big. Ideally, roles should represent actions necessary to perform those steps in a business process where segregation of duties is not necessary. No role should have inherent SoD issues, otherwise there's no way to remediate them on user level.

You also need to make sure risk definition has been adapted to what the customer needs - it's no use remediating on the basis of the default rule set if the customers business processes don't support these assumptions. The rule set is a definition of what kind of access is undesirable for a customer. Make sure these assumptions are correct, first.

Frank.