← All insights

Where SAP access risk actually hides, and how to find it

Most access risk doesn't sit where people look for it. It accumulates quietly in the gaps between roles, systems and exceptions. Finding it takes a different starting point than a standard ruleset run.

Ask a team where their SAP access risk lives and most will point at a list of high-risk transactions. Run a segregation-of-duties (SoD) ruleset, get a report of conflicts, work through the list. It feels thorough. In practice, it catches the obvious and misses the dangerous.

The reason is simple: real access risk is rarely a single permission. It's a combination, the ability to do two things that should never sit with one person, spread across roles that each looked reasonable in isolation. Those combinations are where fraud and error actually happen, and they're exactly what a transaction-by-transaction review struggles to see.

The three places it hides

After enough access reviews, the same hiding places recur regardless of industry or system size.

1. In the layering of roles

A user is rarely assigned one neat role. They accumulate several over time, a base role, a project role, a temporary grant that never got removed, a "just copy what their colleague has" assignment. Each role passed review on its own. The risk only appears when you flatten everything a user can actually do and look at the union. A person who can create a vendor in one role and release a payment in another holds a classic conflict that neither role owner ever saw.

2. In the exceptions

Every SAP estate runs on exceptions: emergency access, break-glass IDs, service accounts, "temporary" elevated rights granted during a go-live. These sit outside the normal role model, which is exactly why they escape normal analysis. They're also the most powerful access in the system. Risk analysis that stops at standard roles ignores the accounts most capable of doing harm.

3. Across systems

Risk doesn't respect system boundaries. A duty split cleanly across two systems can still be a conflict if one person holds access to both. Cross-system and cross-client analysis is harder, so it often gets skipped, and the gap becomes a blind spot precisely where integrated processes create the most exposure.

How to actually find it

Three shifts turn a checkbox exercise into a real risk picture.

Start from usage, not theory. A ruleset tells you what access could be misused. Usage data tells you what's actually being touched. Beginning from real transaction behaviour, who genuinely uses what, lets you separate live risk from theoretical noise, and stops teams from drowning in thousands of conflicts that no one will ever act on.

Analyse combinations, not transactions. The unit of risk is the conflicting pair (or chain), evaluated against everything a user can do across all their roles. The question is never "can this user post a journal?" but "can this user both create and approve the same thing, anywhere in their access?"

Rank by business impact. Not every conflict matters equally. A conflict touching payments, master data or financial postings deserves attention long before one buried in a rarely used reporting transaction. Without prioritisation, remediation stalls under its own weight. With it, you fix the few things that actually move the risk needle first.

A clean SoD report with 4,000 conflicts and no priorities isn't a result. It's a way to look busy while the real exposure stays untouched.

Make it continuous, not annual

The final shift is the hardest culturally. Access risk analysis is usually a project, run before an audit, parked afterwards. But access changes every day: new joiners, role tweaks, urgent grants. A picture that was accurate in March is wrong by June. The estates that stay genuinely low-risk are the ones that monitor continuously, catch new conflicts as they're introduced, and treat the ruleset as a living control rather than an annual deliverable.

Finding access risk well isn't about a bigger report. It's about looking in the right places, the layers, the exceptions, the cross-system gaps, starting from how the system is really used, and keeping the picture current. Do that, and the risk that used to surface only in audit findings becomes something you see and fix first.