How should organisations govern access when IAM is spread across spreadsheets and tickets?

Why This Matters for Security Teams

When access governance lives in spreadsheets and ticket queues, the organisation loses the one thing audit, security, and operations all need: a reliable system of record. That creates drift between what was approved, what is actually active, and what should have been revoked. NHI Management Group has highlighted how weak visibility and lifecycle control remain common across enterprise identity programs in the Ultimate Guide to NHIs, and the pattern is especially damaging for non-human identities because their volume and privilege footprint are usually far larger than teams expect.

This matters because spreadsheet governance is not just manual, it is fragile. Ownership changes, tickets close without evidence, and revocation becomes dependent on memory rather than process. That leaves security teams unable to prove who approved access, whether that access still aligns to business need, or whether stale entitlements have quietly accumulated. The NIST Cybersecurity Framework 2.0 treats governance and access control as continuous capabilities, not one-time clerical tasks, which is exactly where ad hoc tracking falls short. In practice, many security teams discover access sprawl only after an incident, an audit request, or a failed offboarding review, rather than through intentional control design.

How It Works in Practice

The practical fix is to collapse scattered approvals into a governed workflow that becomes the authoritative source for entitlement decisions. That means each access grant has a named owner, a business purpose, an approval record, an expiry or review date, and a revocation path. For non-human identities, that workflow should also capture what system or workload the identity supports, because service accounts, API keys, and automation tokens often outlive the project they were created for.

A mature process usually includes:

• a single intake path for new access requests, linked to role or workload purpose
• time-bound approvals, so access is reviewed against current need rather than historical convenience
• automatic ticket-to-revocation closure, so removal is not left to follow-up emails
• recertification for standing access, especially for privileged or shared entitlements
• logging that can be exported for audit, incident response, and ownership review

For NHI governance, the goal is not just centralisation. It is traceability across the identity lifecycle, from issuance to rotation to deprovisioning. The Lifecycle Processes for Managing NHIs guidance is useful here because it frames access as something that should change over time, not remain static after approval. That view aligns with the OWASP Non-Human Identity Top 10, which treats weak lifecycle governance, exposed secrets, and excessive privilege as recurring risk drivers rather than isolated mistakes. Where organisations are ready for deeper control, they should also move toward policy-based approval logic and automated revocation triggers tied to HR, CMDB, or CI/CD events. These controls tend to break down when entitlements are inherited across multiple business units because ownership becomes ambiguous and no single team can confidently revoke access.

Common Variations and Edge Cases

Tighter access control often increases process overhead, requiring organisations to balance stronger governance against operational speed. That tradeoff is real, especially in fast-moving engineering environments where tickets are seen as friction and informal exceptions become the norm. Current guidance suggests that the answer is not to remove governance, but to make it lightweight enough that teams will actually use it.

One common edge case is emergency access. Break-glass permissions should not live in spreadsheets indefinitely; they need explicit expiry, post-incident review, and evidence of removal. Another is delegated administration, where platform teams create access on behalf of product teams. In those cases, best practice is evolving toward clear accountability for the approving owner, not just the person who executed the change. A further complication is service-to-service access, where the “requester” is a workload rather than a person. The right model there is to govern the entitlement like any other asset, but attach it to the application or automation owner and require periodic validation.

NHIMG’s Regulatory and Audit Perspectives section reinforces a practical point: if governance cannot produce an evidence trail quickly, the process is not truly governed. That is also why the “spreadsheet plus ticket” model often survives until an external review forces change. The Top 10 NHI Issues research helps prioritise where to fix first, usually by targeting high-risk, high-privilege, and high-churn access paths before expanding to lower-risk entitlements.

Related resources from NHI Mgmt Group

• How should organisations govern access when identity controls are spread across IGA, AM, and PAM?
• How should organisations govern access when employees, contractors and partners all need systems access?
• How should security teams govern access to sensitive files beyond IAM roles?
• How should security teams govern non-human identities that have persistent access?