"System of record" is going to get used a lot in identity over the next year. So it is worth pinning down what the phrase should actually mean for your identity security program.
Five properties make up a system of record. Naming them is useful mainly because it tells you which missing property is holding up which project.
1. Complete continuous capture
The record holds every identity in scope, and it holds them as things change. Coverage gaps are never randomly distributed. What goes missing is the systems without a modern API, the homegrown application the payments team wrote in 2011, the mainframe, the appliance with an LDAP interface and a CSV export, the Unix hosts with local accounts and SSH keys nobody has inventoried since the last audit. Those are exactly the places standing privilege collects, because they are the places every tool in the stack finds hardest to reach.
Capturing all of it once is only half the requirement. Ownership decays when people change roles, group membership decays constantly, and an account certified in April can be sitting in a privileged group in May with the certification still reading as clean.
What this costs you: your access review certifies whatever the connector returned, so the accounts that were never in scope roll forward untouched through every cycle. Termination revokes the federated applications and leaves the local account, the key and the token behind. Your privileged program keeps finding accounts in scans and then stalling, because a scan result three months old is not something anyone can act on.
2. Reconciled
Identity data arrives in different formats and has to be normalized and enriched as it comes in. One system exports groups, another exports roles, a third exports a permission string with the entitlement buried inside it. One calls the human a user, the next calls them a principal, a third has three rows for the same identity.
A record resolves all of that on the way in, which is the difference between a record and a pile of exports behind a shared search box. The reason this is hard is that the source systems share almost no common keys. The finance application has an employee number, the cloud role has an ARN, the local admin account on the Unix host has a username somebody picked in 2014, and HR has a person with no accounts attached at all. Nothing in that data says those four things belong to the same human.
What this costs you: reviews get routed to the wrong owner. Actions like deprovisioning cover the accounts the process knows are that person's and miss the ones nobody ever connected to them. And every behavioral tool you have bought on top of this is baselining fiction, because one person arrives as five separate entities and a service account gets modeled as though it were a human being.
3. Change history
The record keeps the change, not just the current state. This is the property most teams assume they have. A weekly export copied into a warehouse gives you fifty-two photographs a year, which looks like history and behaves nothing like it. You can see the state on any given Sunday and still not say what changed on a Tuesday, who changed it, or how long an entitlement existed before the next snapshot happened to catch it. Access granted and revoked between two exports never existed as far as your evidence is concerned.
What this costs you: audit evidence becomes an assembly project every cycle instead of a query, and what you hand over is a reconstruction rather than a record. Investigations start with reconstruction rather than analysis, which is most of why an alert with an account name in it turns into a two day exercise across the identity and SOC teams.
4. Neutrality
The record cannot belong to any one tool's domain. It takes from the IdP, the IGA, the vault, HR and every other enterprise system, and it feeds all of them back.
This is the reason the record cannot simply be a feature your IGA vendor ships next year. A record living inside one tool inherits that tool's reach, that tool's model of what an identity is, and that tool's inability to manage any identity outside its own footprint. Asking your IGA or PAM platform to also be the impartial record of everything that exists is asking it to grade its own work.
What this costs you: a record that lives inside a tool can only hold what that tool reaches, so you cannot use it to find what that tool is missing. If your IGA connects to 40 of your 300 applications, its inventory reports on 40 and says nothing about the other 260. You end up checking the tool's coverage against the tool's own view of coverage. The second cost arrives later. That history belongs to the product rather than to you, so when the platform gets replaced, three years of change data either stays behind or arrives as a flat file with no lineage.
5. A way to act
The record has to be actionable, and the action has to land back in the record. Without this you have a very well-built report that somebody still has to turn into work.
Standing privilege gets revoked, accounts get vaulted, ownership gets assigned, evidence gets filed. Whether that happens through Hydden or through the IGA and PAM tooling you already run matters less than that the loop closes and the record knows it closed.
What this costs you: findings pile up faster than anyone can work them, especially after a discovery exercise. The scan produces a list, the list becomes a backlog, the backlog becomes a spreadsheet, and the spreadsheet is stale before the first item is closed.
Where this leaves you
Assess your maturity against each property. When application onboarding drifts a sprint after it finishes, you have a completeness problem. When you cannot say how many humans you actually have, that is a reconciliation issue. When audit evidence takes two weeks to assemble, change history is missing. When your view of the enterprise stops at the edge of one product, that is neutrality. When discovery produces a backlog nobody works, that is the missing way to act.
Those get treated as five separate problems with five separate owners. But they are the same thing showing up in five places, which is the argument for building the record first and running the programs on top of it.
To see what a system of record will do for your practice, schedule a demo today!
Frequently asked questions
What makes something an identity system of record?
Five properties, and all five at once. It captures every identity in scope and keeps capturing as things change. It reconciles that data on the way in, so the same human arriving from six systems resolves to one entity. It keeps the change rather than only the current value. It stays neutral, meaning it belongs to no single tool's domain. And it offers a way to act, with the action landing back in the record. Miss one and what you have is a report.
What does complete coverage actually mean?
Every identity in scope, including the systems that are hard to reach. The missing portion is never randomly distributed: it is the homegrown application written in 2011, the mainframe, the critical database, the appliance with an LDAP interface and a CSV export, and the Unix hosts with local accounts and SSH keys nobody has inventoried since the last audit. Standing privilege accumulates in exactly those places, because they are the hardest for any tool to collect from reliably.
Why isn't a quarterly export good enough?
Because identity changes faster than a quarter, and an export records a state rather than a change. An account you certified in April can be sitting in a privileged group by May with the certification still reading as clean, and access granted and revoked between two exports never happened as far as your evidence is concerned. Accuracy that has to be rebuilt by a project every quarter costs the same money every quarter and buys a few weeks of confidence each time.
Why does reconciliation matter for identity analytics?
Because unreconciled accounts contaminate everything built on top of them. Elastic Security Labs argues that most UEBA deployments get their entities wrong from the start, and once the entity is wrong the analytics are too: a shared administrative account gets modeled as though it were one person, or a service account gets modeled as though it were interactive. The same failure is working its way into identity products, and they will keep underdelivering until the data underneath them is fixed.
Can my IGA or PAM platform be the system of record?
Not for the whole estate, because a record inside a tool can only hold what that tool reaches. If the platform connects to 40 of your 300 applications, its inventory describes 40 and is silent on the other 260, which means you cannot use it to find what it is missing. The history also belongs to the product rather than to you, so a platform replacement takes years of change data with it. A neutral record sits underneath the IGA and PAM tools you already run and makes them accurate.
Why does the record need a way to act?
Because a finding nobody can work is not an outcome. Discovery without a path to revoke standing privilege, vault a credential, assign an owner or file evidence produces a list, the list becomes a backlog, and the backlog is stale before the first item is closed. The action also has to land back in the record, so the next review starts from what is true rather than from what was true before the last round of fixes.
Which of the five requirements is most dangerous to be missing?
Completeness. The other four operating on partial capture give you current, well-resolved, fully audited answers about part of your estate and say nothing at all about the rest. The systems the record cannot reach are the systems where standing privilege has been collecting for years, so the gap is not just missing data, it is missing the riskiest data.