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.

Do you want to know all the details on how to build a SoD Matrix? Download the free checklist here!

Which are the phases of a SoD management project?

The Segregation of Duties contains these management steps:

• Risks definition
• System analysis
• Remediation
• Mitigation
• Continuous compliance

Let’s delve into the risks definition step.

But first, some quick tips before starting:

• At first, it’s suggested to identify few but well-known risks inside the selected business area. These risks must be easily understandable and accepted by all interlocutors and especially the risks’ owners. In many cases, by starting from a pre-configured matrix it’s easier to find risks that have nothing to do with the company.
• For the identified risks, try to work through the whole SoD itinerary. This can help you better understand the various difficulties in the different project steps.
• After the introduction of risks and their complete management, gradually widen the perimeter.

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
• Audit
• Business

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.

How many risks should you define?

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)

So, what does this data show?

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:

• Manufacturing
• Chemical
• Pharmaceutical
• Automotive
• Energy
• Media

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:

• SoD Risk: Couples (or more than 2) of actions that conflict with each other
• Critical Action Risks: parts of the process which have a risk by themselves
• Critical Permission Risks: Technical objects that are critical by definition, often in the IT area

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