A Book of Record is an authoritative inventory that records who owns each identity and account. It is built from metadata, behavioral signals, HR data, and system context, then maintained over time so security teams can make remediation and governance decisions with clear accountability.
Expanded Definition
A Book of Record is the authoritative source that tells an organisation which identity or account exists, who or what owns it, and what contextual facts support that assignment. In NHI practice, it is less a static list than a governed inventory that stays aligned to changing metadata, HR events, system signals, and remediation decisions.
The term is often used to distinguish the trusted ownership record from scattered operational evidence. That boundary matters because the same account may appear in a cloud console, IAM tool, SIEM, or secret vault, but only one record should drive ownership and accountability. Definitions vary across vendors and operating models, but the security meaning is consistent: the Book of Record is the place where an organisation can defend “this is the current owner” and “this is the current state.”
For machine identities, that distinction becomes important when ownership is shared across platform, application, and security teams. The record must be rich enough to support decisions, but not so loose that it becomes a duplicate directory with no governance value.
Examples and Use Cases
In practice, a Book of Record may appear as a governed dataset, a CMDB-adjacent inventory, or a security-owned register that reconciles multiple sources before it is treated as authoritative.
- A service account registry maps each account to an application owner, a business service, and a decommission date.
- A secrets review process uses the record to determine which team must rotate a token after a dependency changes.
- An offboarding workflow uses the record to identify which identities must be revoked when a workload or integration is retired.
- A governance team uses the record to resolve disputes when application, platform, and security teams each believe another group owns an account.
- A remediation queue uses the record to prioritise stale, orphaned, or over-privileged identities that need action.
That workflow often benefits from practitioner context such as the Ultimate Guide to NHIs, which ties inventory accuracy to lifecycle control, visibility, and offboarding discipline.
The main tradeoff is between completeness and trustworthiness. A broad inventory can capture more identities, but if ownership evidence is weak, the record stops being authoritative and becomes only a discovery feed.
Security Implications
When the Book of Record is incomplete, stale, or disputed, organisations lose the ability to answer basic governance questions quickly: who owns this identity, who can approve change, and what should happen when it becomes risky. That failure shows up as delayed revocation, orphaned accounts, unassigned secrets, and prolonged exposure after an employee, application, or vendor relationship changes.
For NHI environments, this is especially consequential because identity sprawl is normal rather than exceptional. NHIMG reports that 5.7% of organisations have full visibility into their service accounts, which means many teams are making decisions from partial records rather than an authoritative source.
Failure mechanism: ownership data drifts when discovery, HR, platform, and application systems are not reconciled, so remediation tickets cannot be assigned confidently and stale identities remain active.
Impact: access stays open longer than intended, investigations take longer to resolve, and security teams cannot prove accountability for rotation, revocation, or exception handling.
Domain and Governance Relevance
In NHI governance, the Book of Record is the control point that connects discovery to action. It turns a large population of service accounts, API keys, certificates, and automation credentials into something a team can actually govern, because each item can be tied back to an owner, system, and business context.
That matters most when identities are created by code, pipelines, SaaS integrations, or platform automation and then forgotten. Without a trusted record, orphaned NHIs are easy to miss, and even well-intentioned remediation efforts can stall because no one can prove who should approve the change.
The term also supports cross-functional accountability. Security may detect the issue, but platform or application owners usually have to validate the record, confirm business relevance, and complete the fix. In that sense, the Book of Record is not just documentation; it is the governance mechanism that keeps lifecycle control usable at enterprise scale.
NHIMG guidance on NHI governance and lifecycle management is especially relevant here because authoritative inventory is the prerequisite for meaningful offboarding, rotation, and exception tracking.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Inventory and Discovery | A Book of Record is the authoritative inventory for NHIs and their ownership. |
| NHI-02 — Secrets and Credential Management | Record accuracy determines which identities require rotation, revocation, or exception handling. | |
| NHI-03 — Ownership and Accountability | The term centers on who owns each identity and account. | |
| Recommendation — Maintain a governed NHI inventory as the source of truth for ownership and lifecycle decisions. Tie every credential to a recorded owner so rotation and revocation do not stall. Assign each NHI a named owner and keep that accountability current. | ||
| CIS Controls v8 | 5.3 — Account Management | Account lifecycle control depends on knowing which accounts exist and who is responsible. |
| 6.3 — Access Control Management | An authoritative record supports governed approval and review of access assignments. | |
| Recommendation — Use account inventories to remove stale or unowned access paths promptly. Validate access ownership against the record before approving or changing privileges. | ||
| NIST CSF 2.0 | ID.AM-1 — Physical devices and systems are inventoried | The concept is an inventory-driven governance record for identities and accounts. |
| Recommendation — Keep the inventory current so governance decisions are based on known assets. | ||
