Segregation of Duties project: how many risks need to be defined?
Are you working on a Segregation of Duties (SoD) project or are you going to in the future? Do you need to define risks but don’t know how many?
Every company has its processes, and not all of them are SoD relevant: there is no reference number. One of the most frequent questions during SoD matrix definition meetings is: how many risks do we need to define?
There is no single correct answer, but we can learn from what 10 italian companies have done!
Keep in mind: this does not mean that what they’ve done has to be the set rule to apply, however it can give us some perspective and useful advice.
The Segregation of Duties contains these management steps:
Let’s delve into the risks definition step.
But first, some quick tips before starting:
A common mistake often takes place, between the professional figures who are in charge of cooperating on this kind of projects. The involved areas are many, but the most frequent are:
It’s often the case – especially in more structured companies – that many different figures work inside the IT department: CIO, CISO, IT Manager, Key User, Business Process Owner etc.
A SoD Management project concerns business departments, same for the identification and organizational resolution of risks; the IT department only has a support role and should be involved directly only when the risks in question are the ones of its own department. In this case, the IT becomes a direct player in the project.
Below you can find a graph that shows the number of risks for 10 italian companies confronted with the standard SAP GRC Access Control matrix.
On the Y axis: the number of risks (blue column), number of Duties (red column), number of relevant SoD transactions in the matrix (continuous line with red triangle)
The average number of risks present in these matrixes is 85. This number is much lower when confronted with the one of risks present in the SAP standard Access Control matrix: 300 risks exist there. The number of SoD relevant considered transactions is also different: the average is however 700.
For Segregation of Duties purposes, only transaction which allow creation and change actions are considered, while those that allow display only are not SoD relevant. The latter exclusion, however, might not be correct when other data protection regulation are considered (i.e. GDPR)
A company that uses SAP’s main modules, will average 2500/3000 transactions usage. Considering the above-mentioned facts, SoD relevant transactions are about 20% of the total, which is not a small percentage.
Here are the 10 Italian company fields:
Keep in mind that even custom transaction must be considered when building a SoD matrix if they have an impact on the financial statement. If these transactions do not contain authorization controls, it will be necessary to edit the ABAP code to add them.
Even the type of risk is important:
In case a process is divided on more systems, it’s important to consider a cross-system analysis.
Aglea can help you define a rules matrix: we have many templates you can start from.
Furthermore, we developed a solution that makes it possible to almost semi-automatically understand if a custom transaction (write but also display) has an impact on a SoD Process.
Finally, if you need to perform a risk analysis on your systems, we can help you with our Security Analyzer tool
Blog post originally translated from: https://www.aglea.com/blog/progetto-segregation-of-duties-quanti-rischi-devono-essere-definiti