Who is accountable for maintaining an identity system of record, and what should it feed?

Why This Matters for Security Teams

An identity system of record is not just an administration database. It is the reference point for who or what has access, under what authority, and with what review history. When that record is incomplete or disputed, access reviews become subjective, JML workflows break down, and incident response loses the ability to answer basic questions quickly. NHI Management Group research shows the scale of the problem: only 5.7% of organisations have full visibility into service accounts, and 97% of NHIs carry excessive privileges in the Ultimate Guide to NHIs.

Security teams often assume the system of record belongs only to IAM tooling, but the operational reality is broader. It must support governance, audit evidence, privileged access decisions, and containment during an incident. That is why standards such as NIST SP 800-53 Rev. 5 Security and Privacy Controls place emphasis on accountability, access enforcement, and reviewable records rather than on a single product. In practice, many security teams discover the gaps only after an access review, audit request, or breach forces them to reconcile three or four inconsistent sources of truth at once.

How It Works in Practice

Accountability usually sits with identity, IAM, or security operations leadership because that function owns the control plane, the definitions, and the remediation path. But “ownership” should not mean “sole consumer.” The system of record must feed the workflows that depend on trustworthy identity data: access certification, joiner mover leaver automation, privileged inventory, and incident investigation. If a team cannot use the same record to approve access, revoke access, and prove why access existed, then the record is not serving as a system of record.

In mature environments, the record typically includes both human and non-human identities, their sponsors or owners, assigned roles, linked secrets or certificates, last review date, and authoritative source. That data should flow into:

• Access reviews, so managers and control owners can attest against current entitlements rather than stale exports.
• JML workflows, so HR, IT, and platform teams can trigger moves and revocations from one authoritative event.
• Privileged access management and service account inventories, so elevated access is visible before it is abused.
• Incident response, so responders can trace which identities existed, what they could reach, and who approved them.

NHIMG guidance in the Top 10 NHI Issues and the Ultimate Guide to NHIs shows why this matters: if service accounts are not visible and governed centrally, revocation becomes slow and privilege creep goes unnoticed. The practical test is whether the record can drive decisions without manual reconstruction from tickets, spreadsheets, and vault logs. These controls tend to break down in hybrid estates where cloud IAM, legacy directories, CI/CD secrets, and local app accounts all maintain their own partial truth.

Common Variations and Edge Cases

Tighter ownership often increases governance overhead, requiring organisations to balance single-point accountability against the reality of federated platforms and delegated administration. Current guidance suggests the answer is not to centralise every action, but to centralise the canonical record and distribute controlled updates.

There is no universal standard for exactly which upstream system should be authoritative in every environment. Some organisations treat HR as authoritative for people, a CMDB or IAM platform as authoritative for technical access, and a secrets manager or PKI service as authoritative for credentials. That model can work if the feeds are deterministic and reconciled. The risk appears when source systems disagree and nobody is accountable for resolution. NIST control language around access enforcement and auditability supports this separation of duties, but the enterprise still needs one place where conflicts are resolved, not merely recorded.

For NHI-heavy estates, the edge cases are usually service accounts, API keys, certificates, and shared automation identities. NHIMG research shows that only 20% of organisations have formal offboarding and revocation processes for API keys, which means the system of record must also define owner, purpose, expiry, and revocation path. If those fields are optional, the record becomes a directory of unknowns rather than a governance control. In practice, the weakest point is often not identity creation but identity retirement.

Related resources from NHI Mgmt Group

• Who is accountable for non-human identity risk when a service account or API key is over-permissioned?
• Who is accountable when a weak login design allows access to multiple systems through one compromised identity?
• Why do organisations need a neutral identity record instead of relying on IGA or PAM alone?
• Who is accountable when identity verification workflows rely on knowledge-based authentication?