Insight article

Identity Source of Truth: Why Authoritative-Source Design Matters

Identity programs often talk about the source of truth as if there is only one.

In practice, identity data is usually assembled from multiple sources: HR, payroll, identity governance, directories, service desks, applications, contractors, vendors and manual exceptions.

The architecture challenge is not simply to name one system as the source of truth. It is to decide which system is authoritative for each identity attribute, at which point in the lifecycle, and under which exception conditions.

HR is usually authoritative, but not for everything

For employees, the HRIS is often the best authoritative source for core employment information such as legal name, worker identifier, employment status, start date, termination date, manager, organisation, location, job title and cost centre.

But that does not mean HR owns every identity attribute.

Directories may own usernames, email addresses or technical account state. Identity governance platforms may own access policies, role assignments and provisioning workflows. Applications may hold local entitlements. Security teams may own privileged access rules.

If the architecture does not make these boundaries explicit, identity integration becomes fragile.

Attribute-level authority matters

A useful identity architecture defines authority at attribute level.

• HRIS may be authoritative for employment status.
• HRIS may initiate a joiner event.
• Identity governance may orchestrate provisioning.
• Directory services may assign the user principal name and mailbox.
• Applications may consume identity data but not own it.
• Support teams may manage exceptions through controlled processes.

This avoids the common problem where every platform appears to have the employee record but no one can explain which value wins when records disagree.

Timing is part of the architecture

Identity lifecycle events are time-sensitive.

A future-dated hire, immediate termination, role change, secondment, leave event or contingent-worker update may need different handling across systems.

The architecture needs to answer when the identity is created, when access is provisioned, when the email address is created, when the worker is visible in downstream systems, when access is removed, and what happens if the HR record changes after provisioning.

These are not implementation details. They are control decisions.

Joiner, mover and leaver flows need exception design

The happy path is not enough.

A practical identity architecture accounts for rehires, secondments, contingent workers, duplicate identities, shared mailboxes or service accounts, late HR data, incorrect manager hierarchy, urgent access needs, termination reversals and extended access exceptions.

Without exception design, support teams invent workarounds. Those workarounds then become hidden control risk.

Data privacy and minimisation still apply

Identity systems often receive sensitive employee data because it is convenient, not because it is necessary.

Good architecture asks what attributes are actually required, which attributes are sensitive, which system needs each field, whether a derived value can be used instead, whether cross-border or cross-entity movements are involved, who can view and support the data, and how long identity-related data is retained.

Identity integration should not become uncontrolled employee-data replication.

What good looks like

A strong identity authoritative-source model includes lifecycle event ownership, attribute-level authority, integration timing, identity matching rules, exception handling, provisioning controls, privacy decisions, operational support, audit and reconciliation.

Final thought

Identity source-of-truth design is not a diagram showing HR feeding IAM.

It is a set of decisions about authority, timing, control, privacy and operational accountability. That is why it belongs in architecture, not as a late-stage configuration debate.