RAR 5.3 - Remediation Plan

[Former Member]

I've started with remediating each role in DEV system.

Now I want to transport the risk free remediated roles to PRD.

But if I transport user access in PRD will be disturbed.

This means I've to plan and test user remediation in a system other than PRD.

Suppose I want to do the test in TST system which implies I need to have all the PRD users in TST.

I think I'm bit confused here. Can anyone suggest the approach of role and user remediation paln in a 3 system landscape.

[Former Member]

thanks

[Former Member]

There are two concerns with the approach suggested by Amol:-

1) Mitigated Users

As these users are not validly mitigated by a control, you would have to create 'temporary' mitigating control master data. The auditors may not like this idea very much as there is a risk of under reporting.

2) Setup Test IDs in PRD

These Test IDs may be treated as Generic IDs in PRD and are often viewed as backdoor to the ERP systems. For completeness, you will have to do due diligence to make sure that these IDs are cleaned up post remediation. There's also licences costs with creation of that many IDs in PRD.

Recommendation

1) Transport new roles/remediated roles in PRD

2) Assign new roles/remediated users in PRD (assumption: based on a user to role mapping (U2RM) spreadsheet as reference)

- The end results in users having two types of roles; the existing roles and the new/remediated roles

3) Remediate by batches eg. departments, roles or user groups

- Set the old roles to expire by batches, so if there are any problems you can back out and reactivate the old roles minimising impact on PRD.

Note: You will still have to get management sign off on each remediation stage; and have proper communications to end users in terms of date of when they will go live.

[Former Member]

Hi Teck,

> 1) Mitigated Users

> As these users are not validly mitigated by a control, you would have to create 'temporary' mitigating control master data. The auditors may not like this idea very much as there is a risk of under reporting.

>

Can you please clarify what exactly you mean by "users are not validly mitigated by a control"? and creation of "temporary mitigating control master data".

>2) Setup Test IDs in PRD

>These Test IDs may be treated as Generic IDs in PRD and are often viewed as backdoor to the ERP systems. For completeness, you will have to do due diligence to make sure that these IDs are cleaned up post remediation. There's also licences costs with creation of that many IDs in PRD.

>

I meant test IDs to be setup in QA system, one should not test roles in prod. Creating test IDs in prod with update access would be an audit concern as they can be used for real business transaction.

Regards,

Amol...

[Former Member]

Hi,

As Simon said you will definitely need same rule set for your Dev, test and prod system, then engage business to identify and plan mitigation activities ( What, When and how).

I will suggest following approach -

1) Get confirmation from business Managers/risk owners on which productions users need to be mitigated (will retain conflict).

This can be done in two ways -

a) Either manually sending them a list of users with conflicts for review and then mitigating the users in RAR

b) Using CUP SOD review functionality (I would recommend this as it automates review and mitigation process).

2) Clean up access of users for whom risks are marked for removal.

3) Remediate roles with conflict in Development ( you can split the authorizations to create separate roles).

4) Test the new roles; you do not need to replicate all prod users, just setup test IDs specific to new roles being created. The other approach to this is you can replicate access of only Mitigated prod users in test system, and assign new roles for testing.

As long as you make sure that each new role has all the authorization to support the tcodes in it, there will not be issues.

5) Once everything is properly tested move remediated roles to prod and perform assignment. Here you can do stepwise approach (roles in batches) to minimize prod impact if any.

Good luck..:)

Regards,

Amol

[Former Member]

You can also make use of the simulation functionality to try to check what impact changes will have before you implement them in Development?

Again, that can be useful for specific amendments and not for wholesale changes.

Simon

[Former Member]

I would start with a consistent ruleset across all of the systems including production.

That is absolutely key!

Only then will you be able to work with your business stakeholders to identify the true risks and appropriate solutions.

You need to consider the types of risks that are being generated and assess the real requirements for remediation, mitigation or acceptance in light of the business impacts and appitite for risk management.

You may find that in the interim, role splitting maybe an option whereby you remove the SoD from one role by creating two etc. You can then temporarily assign the users both roles. That way, the roles can be cleansed without impacting the user's authorisations. However, that does not remove the conflicts or risks.

There is no quick way to do this but the key thing is engagement with the business to ensure that you are implementing the correct solution for them and the business processes.

You will have to test your changes to either the roles or the conflicts being triggered, in some way, so yes you will need to replicate the users productive access but not necessarily the whole user master records at one time.

Simon