← All insights

Sensitive access: the risk that isn't a conflict

Segregation of duties gets almost all the attention in SAP risk. But some of the most dangerous access needs no second person and no conflict at all, just one powerful action, performed once.

Most SAP risk conversations are really conversations about segregation of duties. Can one person both create a vendor and pay it? Both raise a purchase order and approve it? SoD is about combinations, two duties that are fine apart and dangerous together. It deserves the attention it gets.

But it quietly crowds out a second category of risk that is just as serious and far less governed: sensitive access. These are single actions powerful enough to cause real damage on their own. No conflicting pair. No second step. One transaction, one capable user, and the harm is done.

What counts as sensitive

Sensitive access is the set of things you'd never want someone to be able to do casually or unwatched, regardless of what else they can do. The specifics vary by organisation, but the shape is consistent:

• Changing where money goes, maintaining a vendor's or employee's bank details, altering payment settings, opening or releasing a payment run.
• Posting directly to the books, manual journal entries straight to the general ledger that bypass the normal subledger controls.
• Editing data underneath the application, direct table maintenance that changes records without the checks the transactions would enforce.
• Changing values at runtime, debug-and-replace access that lets someone alter what the system is doing as it runs.
• Reconfiguring the system or its users, changing configuration, or creating and granting access to user accounts.

None of these require a partner in crime. Each is a complete risk by itself.

Segregation of duties asks, "can one person do two conflicting things?" Sensitive access asks the simpler, scarier question: "can one person do one catastrophic thing?"

Why it slips through

Sensitive access is under-governed for predictable reasons.

The ruleset is built around conflicts. SoD analysis is pair-based by nature; sensitive access is single-action by nature. It often ends up as a secondary list in the tooling that nobody curates with the same care as the conflict matrix, present, but neglected.

"It's only one transaction." A single permission looks harmless next to a flagged conflict. The mental model says risk comes from combinations, so a lone powerful transaction doesn't trip the alarm, even though it should.

It hides in technical roles. A lot of sensitive access lives in basis, support and technical roles that business reviewers never really scrutinise. The capability is there; the attention isn't.

How to bring it under control

Managing sensitive access well looks a lot like managing privileged access, because that's effectively what it is.

Build a catalogue that fits your processes

Generic "critical transaction" lists are a starting point, not an answer. The sensitive actions that matter depend on how your organisation actually runs, your payment process, your configuration model, your support arrangements. The catalogue has to reflect that, or it will flag noise and miss the things that matter.

Restrict first, then watch

Sensitive access should be held by as few people as the business genuinely needs, and ideally not as standing access at all where it can be granted on demand instead. What can't be tightly restricted should be closely watched, logged, and its use reviewed by someone independent, exactly as you would for emergency access.

Treat usage as the signal

The fact that someone can perform a sensitive action matters less than whether they do, and whether that use was expected. Monitoring actual usage of sensitive transactions turns a static list of scary permissions into a live picture of what's really happening, and surfaces the unexpected before it becomes an incident.

You need both lenses

A controls programme that only looks for conflicts is solving half the problem with great precision. Segregation of duties and sensitive access are complementary lenses on the same estate: one finds the dangerous combinations, the other finds the dangerous singles. Leave either out and you have a blind spot exactly where it costs the most.

So when you next review your access risk, ask both questions. Not just "where are the conflicts?" but "what can one person do, alone and unwatched, that we could never undo?" The answers to the second question are often the ones that should have been controlled first.