Identity Data Modeling: Authoritative Sources, Correlation, and Data Quality

Three lists that disagree

A company with no identity data model doesn’t look broken from the outside. HR keeps its own list of employees. Active Directory has another, built up over years of accounts created as needed, some of them stale, a few of them duplicated, like the employee who appears once under her maiden name and once under her married one. The ticketing system has a third list of “requesters” that overlaps with the other two but matches neither. Ask how many people currently work there with active access to company systems, and there is no single place to look. There are three lists, they disagree, and reconciling them by hand becomes a project every time an auditor asks.

The previous article described IGA as a loop between administration, which carries out changes, and governance, which decides and checks. Both halves of that loop depend on answering one question with confidence: who is this? Provisioning can’t assign the right entitlement to the wrong person’s record. A review can’t ask a manager to judge access for someone who appears twice, under two slightly different names, without the manager noticing something is off and losing faith in the whole exercise.

Everything else in this module sits on top of a data model, and if the model is wrong, no amount of good policy or well-run review fixes it. This article is about that layer: where an IGA platform gets its facts, and what breaks when they’re wrong.

Three decisions at the core

An identity data model doesn’t have to be exotic. At its core it’s three decisions. Which system is trusted to say that a person exists and works here: the authoritative source. How records that describe the same person in different systems get linked together: correlation. And how the platform notices when a linked record has drifted away from reality: reconciliation.

Get those three right early and every governance capability built afterwards, reviews, separation-of-duties checks, roles, inherits a foundation it can trust. Get them wrong or skip them, and each of those capabilities inherits the same nagging doubt about whether the record in front of it is still true.

Organizations sometimes put off starting an IGA program because their identity data “isn’t clean enough yet,” as if there were a clean starting line to wait for. In practice the data model is what makes the mess visible and fixable. Waiting for clean data before building the thing that would clean it is a reliable way for a program never to start.

What makes a source authoritative

An authoritative source is the system whose record of a fact is treated as the truth for governance: when another system disagrees, the authoritative source wins, automatically, without someone arbitrating each conflict. That’s a stronger claim than “this system has good data.” A system can have excellent data and still be the wrong choice if it isn’t the first place a fact gets recorded.

For most facts about employees, whether they’re currently employed, their job title, their manager, their cost center, the HR system is the right authoritative source. The reason is structural rather than a matter of data quality. HR has to know someone was hired before payroll can pay them, and has to know they left before payroll stops. That obligation is what makes the fact reliable: it isn’t recorded as an afterthought for IT, it’s part of a different business process that would break if it were wrong.

Active Directory is often mistaken for an authoritative source because it’s central and everyone uses it. But it’s downstream. An account is created there because HR reported a hire, or because a manager asked, or, more often than anyone admits, because someone at the help desk created it by hand to unblock a new employee on their first day. AD is an excellent authority on a narrow fact, whether an account exists and which groups it belongs to, and a poor one for whether the person still works here, because it has no structural reason to know that faster or more reliably than HR.

The pattern to keep in mind is that authority is about where a fact is born, not about which system looks most complete or most recent. A spreadsheet updated an hour ago is still a worse source than an HR system updated yesterday. Nothing guarantees the spreadsheet keeps being updated, nothing records who changed what, and nothing stops two people from maintaining two different copies of “the” spreadsheet by next quarter.

It’s worth writing the decisions down and revisiting them on a schedule. A one-page register that names exactly one authoritative system for each governed attribute (employment status: HR; manager: HR; account existence: AD; group membership: AD; contract end date: vendor system) settles more real disputes than it looks like it should. Without it, every disagreement between two systems gets argued out informally by whoever notices it first, with a different answer each time.

Non-employees need a real source, not an exception

Almost every model that starts with “HR is authoritative” runs into the same wall in its first design meeting: HR only knows about employees. Contractors, consultants, vendor staff, partner users, and service accounts all need governed access and all need to exist somewhere in the model, and none of them were ever hired.

The usual mistake is to patch them onto the employee model as a small exception: a manually maintained list, a special group in AD, a spreadsheet someone promises to keep current. It fails for the same reason a spreadsheet fails anywhere else. Nothing forces it to stay accurate, and non-employees are exactly the population whose end dates nobody remembers to act on.

The more durable approach treats non-employees as their own governed category with their own authoritative source. A vendor management system, or a dedicated registry, plays the same role for contractors that HR plays for employees. A contract’s existence and end date are recorded there as part of procurement, legal, or finance processes that have their own reasons to care whether the engagement is still active. When that system says a contract has ended, the identity model has a reliable trigger to remove access without waiting for someone to file a ticket.

Ask an IGA program who its authoritative source for contractors is, and a surprising number answer that they don’t really have one; IT creates the account when a manager asks. That answer means every contractor identity in the organization has no enforced end date, no trigger for removal, and no reliable way to know whether the engagement is still running. It’s consistently one of the first things worth fixing, because contractors often carry a lot of access relative to how well they’re governed.

flowchart TD
  accTitle: Several authoritative sources feed one identity model
  accDescr: The HR system is the authoritative source for employees and sends hire, job change, and termination events. A vendor management system or non-employee registry is the authoritative source for contractors and vendor staff and sends engagement start and end events. A service account registry records the owner, purpose, and expiry of non-human identities. All three feed a single correlation and governance layer, which drives provisioning in the target systems.
  HRIS[HR system<br/>employees] -->|hire, job change, termination| CORR[Correlation and<br/>governance layer]
  VMS[Vendor system or registry<br/>contractors, vendors] -->|engagement start and end| CORR
  SVC[Service account registry<br/>non-human identities] -->|owner, purpose, expiry| CORR
  CORR --> PROV[Provisioning in<br/>target systems]

Service accounts and other non-human identities need a third lane in the same picture. They have no job title and no manager in the HR sense, but they still need an owner, a documented purpose, and ideally an expiry or a periodic re-justification. Without those, they pile up the same way forgotten human accounts do. A service account with no registered source and no owner is invisible to governance from the day it’s created, not just eventually forgotten. Later in this domain, the article on identity hygiene covers what happens when that ownership goes missing.

Choosing an identifier that doesn’t change

Matching records reliably depends on the key they’re matched on, and the choice of identifier deserves more thought than it usually gets. A good identifier is assigned once, when a person first appears in an authoritative source, and is never reassigned or reused, not even years later for an unrelated new hire. Reuse turns a reliable key into a silent bug: a new employee inherits an old employee’s identifier, and every system that ever cached it now points a fragment of stale access at the wrong person.

Two convenient-looking choices are worth avoiding. An email address seems natural because it’s everywhere, but email addresses change with marriage, rebranding, or a domain migration, and a key that changes defeats its own purpose the first time it does. A government identifier, like a national ID or a Social Security Number, is worse for a different reason: it’s sensitive personal data that shouldn’t be copied into every downstream system just to serve as a join key, and privacy laws treat that kind of unnecessary spread as exactly what they’re meant to prevent.

Most mature programs end up with a purpose-built, opaque identity ID, generated once in the authoritative source and carried as an attribute into every downstream account. It means nothing outside the identity system, never changes for the life of the identity, and is never recycled, even after the person leaves. Building that habit in before dozens of applications have learned to match on something weaker is far cheaper than retrofitting it later.

Which attributes to model, and which to leave out

It’s tempting to pull every field the HR system offers into the identity model, on the theory that more data can only help. It doesn’t. Every attribute in the model has to be kept accurate, synchronized, and protected, and some of them create risks of their own.

A small core covers most of what governance needs: the identity ID, legal and preferred name, work email, employment type (employee, contractor, intern), status, start and end dates, manager, department or cost center, job code, and location. Those are the attributes that policies, reviews, and the joiner-mover-leaver process actually read. Anything an access rule depends on deserves extra care, because a rule is only as reliable as the field behind it, a point the policies article later in this domain develops in detail.

Some fields are better left out unless a specific use requires them. Dates of birth, national identifiers, home addresses, and salary rarely help decide access, and copying them into an IGA platform, and from there into every connected system, multiplies the places where sensitive personal data lives. Privacy laws in most jurisdictions, from the GDPR to Latin America’s data protection laws, expect organizations to collect only what they need for a stated purpose. An identity model is a good place to practice that.

It also helps to decide, for each attribute, whether it flows only from the authoritative source into other systems or whether other systems may write it too. Preferred name and phone number are often allowed to be edited by the person themselves in a self-service portal. Department and manager almost never should be, since letting anyone but HR change them would let people change their own access.

Correlation: recognizing the same person everywhere

With sources settled, the next problem is linking records. The same person exists as a row in HR, an account in AD, a mailbox, and logins in a dozen SaaS applications, and none of those systems knows they describe the same human being. Correlation establishes that link.

The clean way to do it is deterministic: match on a stable, unique identifier that every system shares, such as the identity ID from the previous section, carried into each account as an attribute. When the key exists and is consistently filled in, correlation is close to a database join. That’s why good programs invest early in getting the identifier into every connected system’s accounts, even old applications that were never designed for it. It turns correlation from an ongoing analysis problem into a one-time integration task.

Deterministic matching isn’t always possible, especially in legacy systems provisioned long before anyone thought about correlation, or where accounts were created by hand with nothing consistent filled in. Then correlation falls back to probabilistic matching: a combination of attributes that together make a strong case, such as name (allowing for formatting differences), department, manager, start date, and sometimes a phone extension or badge number. No single attribute is reliable on its own, since names collide, departments get renamed, and people share managers, but a scored combination usually produces a confident match or a confident non-match. The smaller set of ambiguous cases goes to a person to decide.

That manual review is the third method, and it’s indispensable for genuine edge cases while being useless as the main approach for a large population. A sensible program uses all three: deterministic where it can, probabilistic for the legacy remainder, and people for what’s left.

The cases that break matching

A handful of real situations break both methods and deserve explicit rules rather than whatever the matching logic happens to do by default.

Name changes are the most common. Marriage, divorce, and gender transition all produce a legal name change during employment. A model that matches partly on name has to treat the stable identifier as more authoritative than the name, and needs a defined process for updating downstream systems without creating a second, orphaned identity under the old name.

Rehires come next. Someone leaves and rejoins eighteen months later. Whether they get a new identity record or reactivate the old one is a policy decision with real consequences. Reactivating risks bringing back stale access from a job that no longer exists; creating a new record risks losing the continuity HR and audit processes expect.

Duplicate identities are records that should be one: often the result of a merger, or of two departments onboarding the same contractor without knowing about each other. Left unmerged, each record accumulates its own access, and no review ever sees the whole picture for that person.

Shared and generic accounts, like a “warehouse-scanner” login or a “training-room-pc” account, deliberately don’t belong to one person. They should be tagged as such instead of showing up as unexplained matching failures that get investigated again every month.

And partner identities, people from another organization signing in to a supplier portal or a shared referral platform, aren’t in this organization’s HR or vendor system at all, because someone else employs them. Matching them usually relies on federation data from the partner’s identity provider, a SAML assertion or OIDC claim carrying the partner’s own stable identifier. The governance question shifts accordingly. The partner organization is the authority on whether the person still works there; the receiving organization’s job is to trust that assertion, remove access quickly when it stops arriving, and resist building a local copy of a population it has no way to keep current.

Reconciliation: catching drift before it piles up

Correlation creates a link once. Reconciliation keeps it honest by regularly comparing what the IGA platform believes each identity’s accounts and access are with what actually exists in the target systems, and surfacing the differences.

Drift usually has mundane causes. A database administrator creates a login by hand at 2 a.m. during an incident, meaning to formalize it later, and doesn’t. Someone makes a change directly in AD because it’s faster than filing a request. A connector fails silently for three weeks and stops passing on removals, so accounts that should be gone are still active. None of it is malicious, and none of it shows up unless something compares the intended state with the real one on a schedule.

flowchart TD
  accTitle: Reconciliation compares governed state with actual state and resolves drift
  accDescr: On a schedule, the reconciliation process reads the actual accounts and access in each target system and compares them with the governed state the identity platform believes is correct. A match needs no action. A mismatch is classified as a change made outside the process, an account with no owning identity, or access that is no longer justified, and each goes to its own resolution path.
  SCHED([Scheduled run]) --> PULL[Read actual state<br/>from target systems]
  PULL --> COMPARE{Matches governed state?}
  COMPARE -->|Yes| OK([No action])
  COMPARE -->|No| CLASSIFY{What kind of drift?}
  CLASSIFY -->|Changed outside the process| FLAG[Review and fix the process]
  CLASSIFY -->|No owning identity| ORPHAN[Orphaned account cleanup]
  CLASSIFY -->|No longer justified| STALE[Send to certification]

How often reconciliation runs matters as much as how it works. Run once a year, it finds a year’s worth of drift at once: orphaned accounts, out-of-process changes, and failed connectors, usually discovered just before an audit, which is the worst possible moment. Programs that reconcile high-risk systems daily or weekly keep each finding small enough to be a quick fix rather than a project. The provisioning article later in this domain goes deeper into how reconciliation works and what to do with each kind of drift.

How bad data breaks governance downstream

All of this is invisible when it works. It becomes visible the moment it’s wrong, because every governance capability inherits whatever the data model got wrong, usually in a way that’s hard to trace back to the cause.

Reviews break first, and quietly. Give a manager a review where three rows are really the same contractor, because two onboarding events created duplicate records. The manager doesn’t know that. They see three unfamiliar entries with slightly different names and approve all three, because rejecting any of them might lock out a colleague over what could be a formatting quirk. Multiply that by every duplicate and matching failure in the population, and a review that was meant to be a real check turns into clicking through. The reviewer isn’t careless; the data in front of them doesn’t support careful review.

Provisioning breaks second, and loudly. A request approved for “David in Finance” is fulfilled for the wrong David, because matching relied on name in a department with two Davids and neither had the identifier filled in on the target system. The wrong person suddenly has access they didn’t ask for, the right person still lacks what they need, and everyone notices. The cause is a matching gap nobody had prioritized, because it hadn’t caused a visible failure until that day.

A worked example: 340 accounts nobody could explain

A mid-sized healthcare provider runs its first full access review eighteen months after deploying an IGA platform. The campaign turns up 340 identity records with no match in HR: no identity ID, no link to an active employee, just accounts that had accumulated over years of direct creation in AD.

The team pulls the list into a spreadsheet, adds what each system knows about last sign-in and creation date, and starts asking owners about each account. Investigating them sorts them into three groups. About 60% are legitimate service accounts that were simply never registered anywhere. About 30% are genuinely orphaned accounts belonging to people who left years earlier. The remaining 10% are active contractors whose engagements were tracked in a spreadsheet that the procurement team stopped updating after a staff change nobody flagged.

None of the 340 were malicious, and all of them were invisible to governance until someone went looking for unmatched accounts. That’s exactly the kind of finding reconciliation should produce routinely. Here it surfaced once, during a first review campaign that ran three weeks late because of the cleanup.

A second example: what a merger does to matching

The healthcare example is drift accumulating slowly inside one organization. Mergers produce the same problem all at once, at a much larger scale. When a mid-sized insurer buys a regional competitor, the two companies arrive with two HR systems, two AD forests, and almost always some overlap: people who worked at both companies at different times, contractors shared by both, and colliding conventions. In this case both companies turned out to number their employee IDs starting from 1.

Matching the combined population isn’t a matter of running the acquired company’s data through the acquirer’s existing logic. Most correlation assumes there’s one authoritative source per fact, and for a while after a merger that stops being true: two sources both claim authority over two overlapping populations. Programs that treat this as a deliberate data project, before reviews resume, end up with a genuinely unified picture of who’s who. Programs that run reviews straight against the merged directory inherit years of duplicate-identity noise that nobody budgeted time to fix.

Data quality is a measure, not a cleanup

Data quality isn’t a one-time project with an end date. It’s a standing property of the model, and it needs measuring continuously, with a baseline recorded before anyone claims improvement. Three measures recur in mature programs.

Tracked as trends and reported alongside the operational measures from the previous article, these numbers do two things. They give the program defensible evidence that the data is improving, or an early warning when it’s getting worse, which often happens after a merger, a new connector, or a change in an HR process. And they give reviewers and auditors a reason to trust the reports built on that data instead of treating every review as a new investigation.

If there’s no baseline yet, a one-time sweep is a legitimate place to start: try to match every account in each connected system to a person, even by hand in a spreadsheet before any platform exists, and count what doesn’t match. It won’t scale as an ongoing process, but it gives you the starting number that makes every later improvement measurable, which is the step organizations most often skip.

Who owns the data

A data model has owners just like entitlements and roles do, and most data problems turn out to be ownership problems in disguise.

HR owns the accuracy of employee records, but HR’s priorities are payroll and compliance, not access. A job code entered a week late doesn’t bother payroll and does mean a new hire’s access arrives a week late. The fix is usually a conversation and an agreement, not a technical change: which fields drive access, how quickly changes must be entered, and who in HR to call when something looks wrong. Some programs go further and add a simple data quality report that HR reviews monthly, showing records with blank departments, managers who have left, or job codes that don’t exist.

Procurement, or whoever runs the vendor system, owns contractor records in the same way, and usually needs the same conversation, since end dates are the field that matters most for access and the one most likely to be left empty.

The IAM team owns the correlation logic and the register of authoritative sources, and is responsible for raising problems with the owners of each source. What it shouldn’t do is quietly fix source data inside the IGA platform. An override that corrects a wrong department in the platform but not in HR will be overwritten at the next synchronization, or worse, will hide the problem from the people who could fix it for good.

Where this maps to standards

The model described here echoes the structure of the standards the industry uses to exchange identity data:

• SCIM (RFC 7643 and RFC 7644) defines a standard schema and REST API for representing and provisioning identities and their attributes. It’s the closest thing to a shared answer to what an identity record’s core schema looks like, and worth knowing even if you don’t provision over SCIM, because it shapes how most modern connectors think about attributes.
• The IDPro Body of Knowledge chapter on identity lifecycle management covers authoritative source selection and correlation as foundations of the lifecycle.
• Analyst research on the IGA market regularly names identity data quality and coverage of non-employees among the most common reasons deployments underperform their business case, a useful point when a data quality workstream needs its own budget instead of being treated as a footnote to a platform purchase.

None of this requires adopting SCIM wholesale before you start. Knowing that “get the data model right first” is documented practitioner consensus helps the next time a project timeline pushes a team to skip straight to review campaigns on an unchecked foundation.

The foundation for the rest of the module

How does an IGA platform know, with confidence, who someone is? Through authoritative sources chosen for structural reasons rather than convenience: HR for employees, separate sources for everyone and everything else. Through correlation that links records across systems, deterministically where there’s a shared key and probabilistically, with explicit rules for the hard cases, where there isn’t. And through reconciliation that keeps those links honest, often enough that each finding stays small.

None of it shows up in a demo. A vendor showing a slick review campaign or request catalog is showing the parts of IGA people notice. The data model underneath decides whether any of that can be trusted, and it’s often what separates programs that hold up under audit from programs that discover, mid-audit, that a third of what they were governing was never really theirs to govern.

Recap

• An authoritative source is where a fact is born, not just the system with the most current data: HR for employees, separate sources for non-employees and non-human identities.
• Use a stable, opaque, never-reused identity ID as the matching key; avoid email addresses and government IDs.
• Model a small core of attributes that access decisions actually use, leave out sensitive fields nobody needs, and decide which attributes only the source may write.
• Correlation links records deterministically through that key, probabilistically through scored attributes, and by hand for the rest, with explicit rules for name changes, rehires, duplicates, shared accounts, and partners.
• Reconciliation catches drift on a schedule; the more often it runs on high-risk systems, the smaller each finding stays.
• Bad data breaks reviews quietly and provisioning loudly.
• Measure match, orphan, and duplicate rates as trends, and treat data problems as ownership problems with the owners of each source.

Three questions to test yourself

1. AD shows an employee as active, while HR shows them terminated two weeks ago. Which system wins, and what does that tell you about why AD was never a good authority on employment status?
2. A matching process links accounts by name and department only. Name two situations from this article where it would produce a wrong match, and what extra signal would fix each one.
3. A review campaign shows an unusually high approval rate with almost no revocations. Which data quality explanation from this article would you check before concluding the access is all correct?

Hands-on exercise

Pick an organization you know and two or three systems people there use.

1. Write the register of authoritative sources: for employment status, manager, job, contract end date, and account existence, name the one system that should be authoritative and say why.
2. For each system, find out what identifier accounts carry and whether it could be used for deterministic matching.
3. Describe how you would handle a rehire and a name change in that organization.
4. Estimate the match, orphan, and duplicate rates you would expect to find in a first sweep, and say which source owner you would talk to first about what you find.