What breaks when role modelling is still managed in spreadsheets?

Why spreadsheet role models fail once access starts changing faster than the workbook

Spreadsheets work only while the role model is small, slow-moving, and locally understood. Once access patterns shift across teams, environments, or business lines, the workbook becomes a snapshot rather than a control surface. The practical failure is not the file itself, but the gap between recorded roles and the actual permissions people are accumulating and using.

A spreadsheet also hides the operational questions that role modelling must answer: who owns each role, what business function it represents, which entitlements it bundles, and whether it still reflects current job reality. Without those relationships, the model drifts into a naming exercise, and reviewers start accepting stale roles because they cannot reconstruct the real access picture quickly enough.

That drift matters because role modelling is supposed to constrain access growth, not merely document it. When the model is disconnected from live usage, teams stop seeing overlap, exception creep, and role sprawl until the cleanup becomes a separate project instead of a routine governance activity.

What actually breaks in the access governance model

The first break is integrity. Roles that once mapped cleanly to job functions start accumulating one-off permissions, temporary exceptions, and inherited access that never gets removed. Over time, the spreadsheet records an approval history, but not a dependable access architecture.

The second break is reviewability. A good role model should let you explain why access exists, whether it is still necessary, and where least privilege is being violated. A spreadsheet rarely gives you that answer at speed, especially when multiple owners edit different versions, definitions shift, or the same role name is reused for slightly different entitlements.

The third break is governance scale. This is where role modelling starts to resemble role mining and role design rather than simple documentation: the model must keep up with entitlement change, business change, and lifecycle change without forcing every decision back into manual reconstruction. When that does not happen, role engineering becomes reactive and brittle instead of governable.

Why stale roles turn least privilege into a paper control

Least privilege depends on an up-to-date picture of what each role should include. If the workbook is stale, the role may still look clean on paper while the live access behind it has already expanded. That is how overpermissioning becomes normalised: the spreadsheet says the role is controlled, but the system state says otherwise.

Spreadsheets also make it difficult to distinguish role design problems from access lifecycle problems. Some excess comes from poor role definitions, some from delayed deprovisioning, and some from role reuse across unrelated functions. If those are mixed together, the organisation cannot tell whether it needs better role architecture, faster review cycles, or stricter entitlement governance.

For that reason, mature role modelling is closer to continuous entitlement calibration than periodic documentation. It should reconcile business change, observed usage, and approval logic often enough that role definitions remain usable as control objects, not historical artifacts.

Risk and Threat Considerations

Spreadsheet-managed role models create a quiet but material exposure: they make privilege creep harder to see and slower to correct. The longer access changes remain unreconciled, the more likely an overbroad role will become the path through which excess permissions, lateral movement, or business process abuse is normalised.

Failure mechanism: Manual reconciliation cannot keep pace with entitlement churn, so role definitions lag behind actual access, exceptions get copied forward, and redundant permissions accumulate until no one can prove that the role still enforces least privilege.

Impact: The organisation inherits more standing privilege, weaker review evidence, higher audit friction, and a larger blast radius when a role is misassigned, abused, or compromised.

Practitioner Guidance

What to prioritise: Treat the spreadsheet as a transitional artifact, not the source of truth. The first priority is to anchor role definitions to owned business functions and observed entitlement use, so you can tell whether a role is structurally wrong or merely overdue for cleanup.

What to verify: Before trusting a role model, verify that each role has an owner, a purpose, a bounded entitlement set, and a current recertification path. If any of those are missing, the issue is not cosmetic, it is a control design failure.

What good looks like: Role changes are traceable, exceptions are time-bound, and the model can be recalibrated from live access evidence without a full manual rebuild. That is the practical difference between access governance and spreadsheet administration.

Practitioner takeaway: If role modelling depends on humans periodically re-deriving reality, it is already behind; the control only becomes trustworthy when role design, usage evidence, and access change move on the same operating cadence.

Related resources from NHI Mgmt Group

• What breaks when PCI access reviews are still managed in spreadsheets?
• What breaks when JML is still managed through manual tickets and spreadsheets?
• What is the difference between role-based access and API key governance for NHI security?
• When does a short-lived API key still create material risk?