An SAP SOD Analysis Tool is one of the most widely used application in SAP access governance. It’s helps organizations to meet the SOX compliance requirements and identify Segregation of Duties conflicts by comparing users, roles, transactions, Fiori applications and authorization data against a defined risk framework. For organizations with thousands of users and complex SAP landscapes, identifying SODs manually would simply not be practical. But there is a question that deserves more attention:
Is the SAP SOD Analysis Tool actually reducing risk, or are organizations becoming too dependent on what the tool reports?
This may sound like an uncomfortable question, particularly for organizations that have invested heavily in SAP SOD solutions. But the technology itself is rarely the problem. The problem is how organizations interpret the output.
A conflict identified by an SoD tool is not automatically a material business risk. A conflict that disappears after remediation is not necessarily proof that the underlying risk has disappeared. And a system that comes with thousands of ready-made risks is not necessarily more effective than one with a smaller, carefully designed ruleset.
The traditional approach to SAP SOD has largely been about one question:
Can the user perform conflicting activities?
That question is still important. But it is no longer enough. The more important questions are beginning to be:
- Did the user actually perform those activities?
- Did the combination create meaningful exposure?
- What business context surrounded the activity?
- And what should the organization do about it?
That is where SAP SOD needs to evolve.
SAP SOD Analysis Tool Is Not an Anti-Virus Solution
In my experience, I see a common assumption. Many C level executives tell us that they have implemented SAP GRC Access Risk Analysis, or a third-party Risk Analysis solution. They look at the SoD solution like an antivirus software.
With antivirus, the model is relatively straightforward. You install the software, scan the environment, identify malicious files, remove them and continue operating. You may run another scan later, but the fundamental expectation is that once the threat has been removed, the problem is gone.
SAP access governance doesn’t work that way.
An SAP environment is constantly changing. Employees change jobs. New users join. Existing users leave. Roles are modified. New transactions are introduced. Fiori applications are added. Organizational values change. Business processes are redesigned. Projects introduce temporary access. Emergency access is granted. Custom developments create new ways of performing business activities.
Every one of those changes can alter the SoD risk landscape.
Yet many organizations still approach SAP SOD as a periodic exercise. They run an SAP SOD analysis, generate a report, work through the conflicts, document exceptions and close the exercise until the next quarterly or annual review.
The problem is that the SAP environment continues to change between those reviews.
A user who had no conflict on Monday may receive a new role on Tuesday. A role that was considered acceptable last year may become problematic after a business process changes. A new Fiori application may provide access to an activity that wasn’t considered when the original ruleset was designed.
So an SoD report is a snapshot. It is not the risk environment itself.
This is why organizations should stop thinking about an SAP SOD Analysis Tool as something they implement, configure and then leave running in the background. The tool should support an ongoing governance process in which access changes, role changes, business changes and actual usage continuously feed the risk assessment.
The objective is not to run more scans simply for the sake of running more scans. The objective is to make sure that changes in the SAP environment do not create unmanaged risk between formal review cycles.
In other words, SAP SOD is a continuous governance problem, not a periodic scanning problem.
Not All SAP SOD Analysis Tools Are the Same
It is tempting to treat all SoD products as equivalent because many of them appear to perform the same basic function: identify conflicting access.
At a high level, that is true.
But the depth of analysis can be very different.
A basic SOD tool for SAP may take a ruleset and compare it against user or role assignments. If a user has access to two activities defined as conflicting, the system creates a risk. That is useful, but it leaves several questions unanswered.
- Why does the conflict exist?
- Which organizational values make it relevant?
- Is the user actually responsible for both activities?
- Is the access temporary?
- Is there a compensating control?
- Is the user actually using the access?
- Does the conflict represent a genuine business exposure?
These questions matter because authorization is rarely black and white.
Consider a user who has access to create vendors and process payments. On paper, this may represent a classic SoD conflict. But suppose the user’s vendor creation access is restricted to one company code, while payment processing is restricted to another. Or perhaps the user has the access but has never used one side of the conflict. Or perhaps a documented and effective compensating control exists.
- The technical conflict remains.
- The risk assessment may change.
This is why organizations evaluating SOD software for SAP should look beyond the number of transactions supported or the number of risks contained in the product. They should understand how deeply the solution can interpret authorization data, organizational restrictions, business context, actual activity and controls.
The difference is ultimately between finding a conflict and understanding a risk.
Those are not the same thing.
Don’t Get Trapped by Stock Rulesets That Promise Thousands of Ready-Made Risks
One of the most attractive claims in the SoD market is also one of the easiest to misunderstand:
“Thousands of ready-made risks included.”
At first glance, more sounds better. If one product offers 5,000 risks and another offers 1,000, it is easy to assume that the first product provides broader protection.
But the number of risks in an SOD matrix is not a measure of the quality of the risk model.
Every organization is different. Its business processes, organizational structure, approval mechanisms, internal controls, custom transactions, Fiori applications, regulatory obligations and risk appetite are different. A risk that is highly relevant to a global manufacturing company may have little relevance to a professional services organization. A generic risk may generate thousands of conflicts in one environment and almost none in another.
There is also a practical problem with excessively large stock rulesets.
If an organization starts with thousands of generic risks, it can quickly end up with thousands of findings. Security teams then spend considerable time explaining false positives, maintaining exceptions and deciding which risks can be ignored.
At some point, the conversation changes from:
“Which risks are important to us?”
to:
“How do we get this report down from 5,000 conflicts?”
That is not maturity. It is ruleset administration masquerading as risk management.
A good SoD Analyzer should provide a strong starting point, but it should also allow the organization to adapt the ruleset to its own environment. Risks should be added when the business introduces new processes, modified when controls change and retired when they are no longer relevant.
The important question is therefore not:
How many risks does the tool come with?
It is:
How accurately does the ruleset represent our actual business risk?
A smaller ruleset that produces meaningful findings can be far more valuable than a huge library that generates noise.
The objective of an SAP SOD analysis program should never be to maintain the world’s largest SOD matrix. It should be to maintain the right SOD matrix for the organization.
Can-Do Analysis Is No More Enough. We Need to Ask: Did-Do
This is perhaps the most important evolution taking place in SAP SOD. Traditional SOD in SAP analysis is primarily capability-based. It asks what a user can do based on the access assigned to that user.
That remains an essential question.
If someone has conflicting access, the organization needs to know about it. Preventive access governance depends on understanding what users are capable of doing.
But capability doesn’t tell us what actually happened. Consider two employees.
Both have the ability to create vendors and process payments.
- Employee A has the access but has never created a vendor and has never processed a payment.
- Employee B has the same access and has repeatedly created vendors and subsequently processed payments.
From a traditional authorization perspective, both users have the same SoD conflict. From a risk perspective, the situations are very different.
This is the difference between Can-Do and Did-Do.
Can-Do asks:
What is the user capable of doing?
Did-Do asks:
What did the user actually do?
The second question brings system activity into the conversation. Transaction execution, Fiori usage, audit logs and other activity information can provide evidence that helps determine whether a theoretical conflict has translated into actual exposure.
This does not mean that organizations should abandon traditional SAP SOD analysis.
Quite the opposite.
Can-Do analysis remains fundamental because preventive controls depend on understanding what users are capable of doing. The point is that capability analysis should not necessarily be the end of the investigation.
The more mature model is:
Access → Capability → Usage → Activity → Context → Risk
rather than simply:
Access → Conflict → Report
That shift is important because modern SAP environments are becoming increasingly complex. Users may access business processes through classic transactions, Fiori applications, integrations, APIs and custom developments. Looking only at a static authorization assignment can therefore provide an incomplete picture.
The future of SOD SAP is not about choosing between authorization analysis and activity analysis. It is about bringing the two together.
SoD Analysis Is the Diagnosis. Materialization Is the Treatment
There is a simple analogy that explains the difference between analysis and remediation particularly well.
SoD analysis is like a diagnosis.
A diagnosis can indicate that something may be wrong. It provides evidence that requires interpretation. The doctor then considers the patient’s history, other symptoms, additional tests and the severity of the condition before deciding what treatment is appropriate.
The diagnosis itself doesn’t cure the patient. The same principle applies to SAP SoD.
An SAP SOD Analysis Tool identifies potential conflicts. It tells you that a user has a combination of access that your ruleset considers risky.
But the analysis itself doesn’t remove the risk. The next step is understanding whether the risk is relevant, whether it has materialized and what treatment is appropriate.
That treatment could involve removing access, redesigning a role, restricting organizational values, introducing a compensating control, implementing monitoring or accepting the risk with appropriate ownership.
This is why SoD controls for SAP should be considered part of a broader lifecycle.
Analysis identifies the potential condition.
Materialization provides evidence of actual exposure.
Treatment addresses the risk.
The analogy also highlights an important misconception.
A conflict disappearing from a SoD report does not necessarily mean the underlying risk has disappeared. A user may have received another role that provides the same access. A manual workaround may have been introduced. An emergency access mechanism may have replaced the original access.
The report may look cleaner.
The risk may not be.
Stop Treating Every Conflict as Equal
A common problem in SOD compliance for SAP is treating every conflict as though it carries the same significance.
It doesn’t.
A conflict involving a highly privileged user with access across multiple company codes is not necessarily equivalent to a narrowly restricted conflict in a low-risk process. A conflict that has never been used is not necessarily equivalent to one that is being actively exercised.
Risk needs context.
That context can include the user’s role, organizational scope, business process, frequency of use, transaction values, duration of access and effectiveness of compensating controls.
This is why a mature access SOD risk assessment should go beyond a simple High, Medium or Low classification.
The organization should be able to understand why the risk is considered significant.
A good risk assessment should help answer:
- What can the user do?
- Where can the user do it?
- Why does the combination conflict?
- Has the access been used?
- Has the conflicting activity occurred?
- What business entities were involved?
- What controls exist?
- Who owns the risk?
- What treatment is appropriate?
This transforms SoD from a technical authorization exercise into a business risk discussion.
SoD Controls Should Be About Risk, Not Just Documentation
It is possible to have a SoD policy, an SoD matrix, an SoD tool and periodic review reports and still have a weak control environment.
Why?
Because having a process documented does not mean the process is effective.
For example, an organization may state that all SoD conflicts are reviewed every quarter. If the review consists of generating a report, assigning thousands of findings to business owners and accepting most of them without meaningful investigation, the organization has completed the process but may not have meaningfully reduced risk.
The quality of the decision matters more than the existence of the workflow.
An effective SoD program should therefore connect identification with action.
A potential conflict should be validated. Relevant risks should be assessed. Ownership should be established. Treatment should be documented. Exceptions should have a reason and an expiry where appropriate. Compensating controls should themselves be reviewed.
And the process should be capable of detecting when circumstances change.
That is what turns SOD compliance for SAP from a reporting exercise into a functioning control framework.
Automate Identification of Segregation of Duties (SoD), But Don’t Automate Away Judgment
There is no question that automation is necessary. Large SAP environments simply cannot depend on people manually comparing thousands of users, roles, transactions, authorization objects and organizational values. Organizations should absolutely automate identifying Segregation of Duties (SoD) conflicts.
But automation must be used correctly. A machine is very good at comparing data. It can identify a conflicting combination in seconds. It can analyze large volumes of authorization data. It can detect changes. It can correlate activities and prioritize findings.
What it cannot automatically understand in every situation is the business reason behind the access.
A finance process owner may know why a particular combination is required. An SAP security architect may understand how a custom transaction behaves. An auditor may know which control is genuinely effective. A business owner may understand why an exception is temporary.
The purpose of automation should therefore be to improve human decision-making, not eliminate it.
The best SOD tool for SAP is not necessarily the one that removes humans from the process.
It is the one that gives humans better information and reduces the amount of manual work required to reach a good decision.
What Should Organizations Look for in an SAP SOD Analysis Tool?
When evaluating an SAP SOD Analysis Tool, organizations should look beyond the traditional product checklist.
The first question should be whether the ruleset is relevant and customizable. Can the organization create its own risks? Can it modify existing rules? Can it retire risks that are no longer relevant? Can it account for custom transactions and applications?
The second question should be how deeply the solution understands SAP authorization. Does it analyze authorization objects, fields and organizational values rather than simply looking at transaction assignments?
The third question should be whether the tool can move beyond static access.
Can it analyze actual usage? Can it distinguish between what users can do and what they actually did? Can it provide evidence of activity that helps determine whether a conflict has materialized?
The fourth question should be what happens after the finding is identified.
Can the solution support remediation, mitigation, monitoring, exception management and evidence collection?
And finally, can security, audit and business stakeholders understand the result?
A technically accurate report that nobody can interpret or act upon is not enough.
The real value of an SAP SOD Analysis Tool lies in its ability to help an organization answer three questions:
What is the risk?
Why does it matter?
What should we do about it?
The Future of SAP SOD Is Risk-Based, Not Conflict-Based
The traditional model of SoD has been relatively straightforward:
Access → Conflict → Reporting/Remediation
That model still has value, but it is becoming insufficient for increasingly complex SAP environments.
A more mature model looks like:
Access → Capability → Usage → Activity → Context → Materialization → Risk → and finally Treatment
This does not make traditional SoD obsolete. It makes it more useful.
- Authorization analysis tells us what a person can do.
- Activity analysis tells us what the person actually did.
- Business context tells us why it matters.
- Materialization tells us whether the potential risk became actual exposure.
- Controls and remediation determine what should happen next.
That is a much more complete approach to SAP SOD analysis. It also changes the way success should be measured.
An organization shouldn’t celebrate simply because its SoD report contains fewer conflicts this year than last year. It should ask whether it has better visibility into its real risks.
Perhaps the organization has fewer conflicts because roles were redesigned.
That is good.
Perhaps it has fewer conflicts because the ruleset was narrowed to avoid false positives.
That requires investigation.
Perhaps it has more conflicts because the organization finally added risks that had previously been missing.
That could actually be a sign of improvement.
The number of conflicts is not the KPI.
The quality of risk understanding is.
Conclusion: Stop Counting Conflicts. Start Understanding Risk.
An SAP SOD Analysis Tool is only as valuable as the decisions it enables. If it is treated as a periodic scanner, measured by the number of conflicts it finds, or driven by a generic ruleset, it can easily become another reporting exercise. The real value begins when organizations look beyond what users can do and start understanding what they actually do, the business context around that activity, whether the potential risk has materialized, and what action is appropriate.
The goal of SAP SOD was never to achieve zero conflicts. It is to understand where the real risks are, which ones matter, and how effectively they are being treated. Analysis identifies the potential risk. Materialization establishes the exposure. Treatment addresses the risk. The question, therefore, isn't how many conflicts your SoD tool can find. It is whether your organization is getting better at managing the risks behind those conflicts.
