What breaks when SoD matrices are only defined in spreadsheets?

Why Spreadsheet-Only SoD Breaks at Enforcement

A spreadsheet can document toxic combinations, but it cannot enforce them where access is actually granted. Once duties are spread across SaaS apps, delegated admins, and exception paths, the control becomes informational instead of preventative. The organisation may look governed on paper while the effective access model keeps drifting in production.

The deeper failure is that SoD is not just a policy artifact, it is an access decision that must survive provisioning, role changes, and emergency access. If the control is not wired into the systems that create, review, and log access, the spreadsheet becomes a reference file rather than a living control.

That is why spreadsheet-only SoD often misses the moment where conflicting entitlements accumulate. The conflict can be visible to reviewers and still remain technically possible in the application, which means the business can satisfy audit questions without reducing real privilege overlap.

Where Spreadsheet SoD Usually Fails in the Control Stack

SoD matrices usually fail at the boundaries between ownership, provisioning, and evidence. One team may maintain the matrix, another team may grant access, and a third may review activity after the fact, which leaves no single control point preventing an incompatible combination from being assigned.

Live control requires linkage to identity lifecycle, access certification, and audit logging. Without that linkage, the matrix cannot see delegated administrators, temporary exceptions, or inherited permissions, and those are the exact paths where conflicting power tends to accumulate.

• Provisioning can create conflicts faster than a spreadsheet review cycle can catch them.
• Exceptions can outlive their justification if they are not tied to expiry and reapproval.
• Logging can show that access was used, but not that the access path should never have existed.

A useful way to think about it is that the spreadsheet describes SoD intent, while the runtime control model enforces SoD state. If those two layers are separated, the organisation must rely on manual discipline to keep a preventive control working, and that rarely scales across multiple applications.

What Practitioners Should Expect Instead of Manual SoD Maintenance

Practitioners should expect SoD to behave like a governed entitlement rule, not a static policy chart. The practical question is whether a conflict can be blocked or at least surfaced before it is granted, not whether it can be explained later in a review meeting.

For teams operating across many applications, the best test is whether SoD rules are evaluated during provisioning and recertification with the same identity source of truth. If the control only exists in a spreadsheet, then every new app, role, or delegated admin path becomes a separate manual reconciliation problem.

Segregation of Duties (SoD) Guide is the right next step when you need to move from conflict definitions to enforceable rules, mitigations, and exception handling across both human and non-human access paths.

Practitioner Guidance

What to verify: Check whether the SoD rule set is connected to provisioning, certification, and logging, and whether exceptions carry expiry and accountable ownership. If those links are missing, the matrix is advisory only.

What to prioritise: Focus first on the high-impact conflicting combinations that can create direct financial, operational, or administrative abuse, then extend coverage to delegated admins and emergency access. Those are usually the fastest routes from policy to real exposure.

Common mistake: Treating clean audit narratives as proof of enforcement. A spreadsheet can help demonstrate governance, but it cannot prove that conflicting entitlements were technically prevented from being assigned or retained.

Practitioner takeaway: SoD only works when the control lives in the entitlement lifecycle, not when it is stored as a reference list that people must remember to follow.

Related resources from NHI Mgmt Group

• What breaks when SAP SoD checks are done with spreadsheets only?
• What breaks when mitigation controls are only tracked in spreadsheets?
• What breaks when SoD is reviewed only at audit time?
• What breaks when Oracle SoD reporting relies on assigned roles instead of effective access?