What breaks when organisations rely on documentation instead of real identity activity data?

Why This Matters for Security Teams

Documentation is useful for governance, but it is not evidence of what identities actually did. When organisations rely on policies, spreadsheets, and approval records instead of live identity activity, they miss the difference between intended control and enforced control. That gap is especially dangerous for service accounts, API keys, and other NHIs that operate outside normal user workflows. NHIMG’s Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts, which means most teams are certifying risk they cannot actually see.

The failure is not just poor recordkeeping. It means orphaned credentials can persist, excessive privileges can go unnoticed, and unapproved access paths can survive long after a review cycle closes. That creates a false sense of control during audits and slows incident response because investigators must reconstruct reality from incomplete records. The control expectation in NIST SP 800-53 Rev 5 Security and Privacy Controls depends on observable implementation, not just written procedure. In practice, many security teams discover the gap only after an access review, outage, or breach has already exposed it.

How It Works in Practice

The practical issue is that documentation captures design intent, while identity activity data captures execution. If a service account is documented as disabled but still authenticates through a CI/CD pipeline, the document is wrong in security terms. The same applies when an application owner signs off on a role matrix that no longer reflects actual permissions, token usage, or key rotation behaviour. Security teams need evidence from identity providers, vaults, logs, and workloads, not just attestations from owners.

Current best practice is to correlate several sources: authentication events, token issuance, privilege changes, secret rotation records, and application telemetry. That makes it possible to answer three questions at the same time: who or what authenticated, what it was allowed to do, and whether that access still makes sense. For NHI programs, this is especially important because machine identities often outnumber human identities by 25x to 50x, and they are frequently spread across code, CI/CD, cloud services, and unmanaged applications. The result is that a spreadsheet can say “review completed” while the actual account remains active and overprivileged.

Teams that want stronger assurance should map documented controls to observed events and exceptions. Use identity activity data to validate whether rotation really happened, whether a key was used after decommissioning, and whether access drift is accumulating. NHIMG’s 52 NHI Breaches Analysis shows how often identity weakness becomes an entry point when visibility is poor. In operational terms, documentation tells you what should exist; activity data tells you what is actually alive, active, and reachable. These controls tend to break down when identities are embedded in unmanaged apps and shadow pipelines because those environments rarely emit complete, reviewable telemetry.

Common Variations and Edge Cases

Tighter validation often increases operational overhead, requiring organisations to balance assurance against the cost of collecting and normalising event data. That tradeoff matters most when teams inherit legacy platforms, third-party SaaS, or development tooling that does not produce consistent logs. In those environments, current guidance suggests treating documentation as a starting point and using compensating controls where telemetry is incomplete, rather than assuming the review itself proves enforcement.

There is also no universal standard for how much activity data is enough. Some organisations can verify controls with direct API logs and identity provider events; others must infer from proxy logs, vault audit trails, or cloud control plane records. The key is to avoid overclaiming. If a control cannot be observed, it should be reported as partially evidenced, not fully effective. That distinction matters under frameworks such as NIST and in incident response, where responders need proof of actual access paths. NHIMG’s Top 10 NHI Issues and Ultimate Guide to NHIs — Key Research and Survey Results reinforce the same point: visibility and rotation fail first where accountability is weakest.

Related resources from NHI Mgmt Group

• What breaks when organisations rely on monitoring alone instead of real-time enforcement for Salesforce data security?
• What breaks when organisations rely on point solutions instead of continuous controls monitoring?
• What breaks when organisations rely only on entity detection for data protection?
• What breaks when organisations rely on fraud tools instead of identity observability?