What do organizations get wrong when they rely on manual spreadsheets to manage separation of duties?

What spreadsheets miss about separation of duties

Manual spreadsheets make separation of duties look tidy when it is actually dynamic. The real control problem is not just listing conflicts once, it is keeping pace with role changes, entitlement growth, exceptions, and overlapping access across multiple systems. Once that turns into a file, the control becomes dependent on human memory, manual reconciliation, and whoever remembers to update the row.

A spreadsheet also tends to flatten context. It may show that one person holds two permissions, but not whether those permissions are active in production, whether they were inherited through a role change, or whether they create a toxic combination only when paired with access in another application. That is why the failure mode is usually drift, not a single obvious error.

Organizations also underestimate evidence quality. A static worksheet can show that someone reviewed access at a point in time, but it does not prove continuous enforcement, timeliness of remediation, or whether exceptions were approved and tracked to closure. For audit and operational use, the gap is not just completeness, it is traceability.

Why manual SoD tracking fails as access changes

Separation of duties depends on current state, not historical intent. A person can move teams, inherit a new role, gain system-specific privileges, or receive a temporary exception that quietly becomes permanent. If the tracking method is manual, the control usually degrades fastest where the business changes fastest, which is why one-time cleanup efforts rarely stay effective.

The deeper problem is that SoD is cross-system by nature. Conflicts often emerge only when entitlements from HR, IAM, ERP, finance, or custom applications are viewed together. A spreadsheet owned by one team cannot reliably normalize those sources, detect duplicates, or reconcile identity changes at the same speed as the environment.

That is why organizations often end up with the appearance of control rather than the control itself. They can demonstrate that they have a list, but not that the list is continuously aligned to actual privilege, actual business roles, and actual transaction paths.

What a defensible SoD control needs instead

A defensible SoD program needs rule-based detection, ownership, and recurring review of conflicts, not a file that depends on periodic manual updates. The control should identify incompatible combinations, track approved mitigations, and alert when new entitlements create a breach of policy. The important shift is from documentation to enforcement.

That usually means integrating the control into IAM and IGA Basics rather than treating it as a standalone checklist. It also means using a formal ruleset such as the Segregation of Duties (SoD) Guide model for conflicts, mitigations, and ongoing monitoring, especially where exceptions must be justified and revisited.

When SoD is tied to access lifecycle events, it becomes far more reliable. Provisioning, role changes, access certification, and removal should all trigger the same conflict logic so that the control does not depend on someone remembering to refresh a spreadsheet after the fact.

Risk and Threat Considerations

Manual SoD tracking creates a quiet accumulation risk. The longer a spreadsheet remains the source of truth, the more likely it is that hidden privilege combinations, stale exceptions, and cross-system conflicts will persist unnoticed until an audit, fraud review, or incident exposes them.

Failure mechanism: The control fails when access changes outpace manual reconciliation, allowing incompatible permissions to remain active after role moves, temporary access grants, or system changes.

Impact: A single user can retain enough combined access to initiate, approve, and complete a sensitive process end to end, which undermines fraud prevention, auditability, and accountability.

Practitioner Guidance

What to verify: Confirm that SoD conflicts are evaluated against current entitlements across all relevant systems, not just against a one-time spreadsheet extract. If conflict detection depends on a monthly review, treat the control as lagging, not preventive.

Common mistake: Do not confuse a documented review with an enforced control. If the process cannot show when access changed, who approved the exception, and when the conflict was remediated, it is not reliable enough for operational assurance.

What good looks like: The organization can identify toxic combinations automatically, evidence how exceptions are approved and aged, and prove that access changes trigger re-checks without waiting for a periodic cleanup cycle.

Practitioner takeaway: SoD fails in spreadsheets because the risk lives in movement, not in the snapshot, so the control must be continuous, cross-system, and tied to the access lifecycle.

Related resources from NHI Mgmt Group

• What do teams get wrong when they rely on manual DNS recovery?
• What do teams get wrong when they rely on manual review alone?
• What do security teams get wrong when they rely on manual privilege reviews at enterprise scale?
• What do teams get wrong when they rely on manual vulnerability management in DevSecOps?