SAP Access Risk Management: SoD Risk and FUE Exposure – Two Business Risks from the Same Root Cause
Ask a CFO whether they are aware of any Segregation-of-Duties (SoD) violations in their SAP environment, and most will say yes — with a degree of resignation. SoD findings have featured in audit reports for decades. They are familiar, and for many organisations, treated as an accepted cost of operating a complex SAP landscape.
Ask the same CFO whether they know how much of their SAP Cloud ERP Private subscription is attributable to access their users do not actually need, and you will typically get a very different response. The question lands differently — because it connects directly to a line on the budget, not a finding in a report.
This distinction matters. SoD risk and FUE exposure both stem from the same root cause — over-assigned or poorly designed SAP access — but they carry different implications, generate different levels of urgency, and demand different responses. For SAP access risk management teams, understanding both dimensions is becoming a core responsibility — particularly in organisations on or planning a move to SAP Cloud ERP Private (formerly RISE with SAP).
Segregation-of-Duties (SoD) is a fundamental control principle: users with the ability to perform conflicting functions should be the exception, not the norm. In SAP environments, most SoD conflicts arise from poorly designed roles that grant access beyond what is required for a user’s job function.
The business risk is real. SoD violations create the conditions for fraud — misappropriation of assets, unauthorised payments, manipulation of financial records. In regulated industries, they also attract regulatory scrutiny under frameworks such as SOX and J-SOX.
Yet in many organisations, SoD risk is treated primarily as an audit finding rather than a business risk. Several factors contribute to this:
- SoD findings are expressed in technical SAP language — transaction codes, Fiori services, authorisation objects, role names — that business users find difficult to interpret.
- The connection between a specific SoD conflict and a probable business harm is not always clear or immediate.
- Remediation requires access changes that can disrupt operations, making business owners reluctant to engage.
- Annual audit cycles create a compliance rhythm that treats SoD as a periodic exercise rather than a continuous risk.
- Many organisations have held the same SoD findings for years without incident, reinforcing the perception that they represent theoretical rather than actual risk.
The result is a common pattern: SoD violations are documented, partially remediated, and carried forward — managed as an audit obligation rather than addressed as a genuine business priority.
Full-Use Equivalent (FUE) exposure is a different category of problem. Under SAP Cloud ERP Private, every user’s license tier is determined by the authorisation objects assigned to them — not by what they actually use. The STAR rule set maps those authorisation objects to FUE classifications, and those classifications determine the cost of each user’s license.
Over-assigned access — the same underlying problem that generates SoD violations — directly inflates FUE consumption. A user whose assigned SAP roles gives them access to financial postings, procurement approval, and system configuration, even if they perform only one of those functions, may be classified at a higher FUE tier than their actual job function requires. This overstatement will persist for the duration of the SAP Cloud ERP Private subscription, with the cost impact felt throughout the entire contract term.
FUE exposure manifests in two specific commercial scenarios:
The difference from SoD risk is stark: FUE exposure is quantifiable, continuous, and directly linked to cost. It does not require a fraud event to materialise. It is already happening.
SoD violations and FUE over-consumption both originate from the same source: SAP role designs that assign more access than users genuinely require. The remediation approach — refining SAP single roles, removing unnecessary authorisation objects field values, aligning access to actual job function — is broadly the same for both problems.
What differs is the audience, the urgency, and the language needed to drive action.
SoD risk is a business risk — but one that has historically been communicated in the wrong language. The risk is probabilistic: it represents the conditions for fraud, not fraud itself. Because it is expressed in technical SAP terms – non-descriptive SAP roles names, transaction codes, authorisation objects — the conversation has typically landed with audit committees and SAP security managers rather than with the business managers who should own it. This is a failure of communication, not a reflection of the risk’s importance.
FUE exposure is a business risk with an immediately visible commercial consequence. It is financial and certain — already reflected in the subscription cost, and growing with every access change that has not been evaluated for FUE impact. It requires no SAP technical background to understand: over-assigned access costs money every month. For organisations on SAP Cloud ERP Private, this often makes it the easier of the two risks to escalate — and the more effective door-opener for a broader access governance conversation.
Organisations that frame access risk only as an audit problem are missing half of the argument. The most effective case for investment in SAP access governance combines both dimensions: this is a control risk and a commercial liability. For organisations on or moving to SAP Cloud ERP Private, the commercial dimension is often the more persuasive of the two.
A common pattern emerges: an organisation invests in SoD remediation – refining SAP access and removing conflicting permissions. Access risk improves, audit findings decrease, and the GRC programme is deemed a success.
But if that remediation was conducted without reference to FUE implications, the outcome may be mixed. Consider:
- Roles that were split to resolve SoD conflicts may result in users holding multiple smaller roles — each of which contributes to FUE classification. Net FUE consumption may not reduce, and in some cases may increase.
- New roles created during remediation may not have been designed with the STAR rule set in mind, inadvertently introducing FUE uplift through the choice of authorisation objects.
- Access removed to remediate SoD conflicts may have been replaced with alternative access that carries the same FUE tier classification.
The converse also holds: an organisation that optimises purely for FUE reduction — removing access to lower license costs — without reference to its SoD implications may inadvertently create new control gaps.
The correct approach addresses both dimensions simultaneously. Role design decisions should be evaluated against SoD risk, FUE impact, and operational necessity — not treated as three separate exercises. This is what it means to manage SAP access risk as a business risk rather than a compliance checklist.
One of the most significant obstacles to effective SAP access governance is the gap between technical SAP language and business language. Business users — managers who approve access, executives who own risk decisions, finance leaders who fund GRC programmes — typically have limited familiarity with transaction codes, authorisation objects, and composite role structures / designs.
This gap has consequences. When access risk is communicated in technical terms, business owners are unable to make informed decisions. They either defer to IT — abdicating accountability — or approve access requests without understanding what they are approving.
Bridging this gap requires translating access risk into the language of business outcomes:
- Instead of: ‘User holds conflicting access to FB60 and F110’, say: ‘This user can create a vendor invoice and process the payment — without a second approver in the chain.’
- Instead of: ‘Role assignment generates an FUE uplift for 20 Core FUE Users to become Advanced FUEs’, say: ‘Adding this access will increase this user’s monthly license cost by approximately $60 000.’
- Instead of: ‘SoD conflict count has increased by 12% since the last review’, say: ‘The number of users who could process an unauthorised payment without detection has grown by 12%.’
This is not simplification for its own sake. It is the difference between a governance programme that generates reports and one that drives decisions. When business users understand what they are approving — and at what commercial and control cost — they engage more responsibly and more consistently.
Soterion’s access control solutions are built with this principle at their centre. Business-friendly risk descriptions, FUE impact visibility within provisioning workflows, and plain-language SoD explanations are features that exist specifically because technical language has historically prevented business ownership of access risk.
How Should Organisations Approach SAP Access Risk Management in 2026?
Effective SAP access risk management in 2026 requires organisations to operate on two tracks simultaneously. The first is the control track: identifying and remediating SoD conflicts, tightening role design, and ensuring users hold only the access their job function genuinely requires. The second is the commercial track: understanding the FUE cost of the current role structure, modelling the license impact of proposed access changes before they are applied, and entering or renewing a SAP Cloud ERP Private subscription with a right-sized baseline.
Practically, this means: conducting role design reviews with both SoD conflict pairs and FUE classification in view; embedding FUE impact assessment into every provisioning workflow so that business-as-usual access changes do not silently inflate license consumption; and communicating access risk to business stakeholders in the language of business outcomes rather than technical SAP terminology. Organisations that treat these as separate programmes — one for compliance, one for licensing — will find they duplicate effort and miss the compounding benefit of addressing both at the source.
Final Thoughts
SoD risk and FUE exposure are not competing priorities. They are two expressions of the same underlying problem — SAP access that has not been designed or maintained with sufficient rigour — viewed through different lenses.
The organisations managing SAP access most effectively in 2026 are those that have moved beyond treating access risk as an audit obligation and begun treating it as a business risk with financial consequences. Under SAP Cloud ERP Private, the financial consequences of poor role design are no longer theoretical. They appear on the subscription invoice.
The business case for investment in SAP access governance has never been clearer. The question is whether organisations are framing it in the language that drives the right decisions — and giving the right people the information they need to act.
Ready to see both dimensions of your SAP access risk in one view?
Soterion’s Access Risk Manager surfaces SoD violations in business-friendly language — so your access approvers understand what they’re signing off on. And the SAP License Manager shows the FUE cost of every role assignment, so your finance and IT leaders can see exactly what over-assigned access is costing the business each month. Request a demo to see both in action, or reach out to us directly at [email protected]
