Who should own the source of truth when employee data differs across connected systems?

Why This Matters for Security Teams

When employee data is duplicated across HR, IAM, SaaS, and directory systems, the question is not just where the record lives, but which system is authoritative for each attribute. Without that decision, access reviews, joiner-mover-leaver workflows, and audit evidence all become inconsistent. NIST’s control guidance on account management and information system monitoring in NIST SP 800-53 Rev 5 Security and Privacy Controls supports the need for explicit ownership and traceable updates. NHIMG’s research shows how often identity governance fails when records drift, with only 5.7% of organisations reporting full visibility into service accounts in the broader identity estate, a warning sign for any environment that relies on stale or conflicting identity data; see the Ultimate Guide to NHIs — Key Research and Survey Results. In practice, many security teams discover source-of-truth gaps only after an access recertification, audit finding, or termination delay has already exposed the mismatch.

How It Works in Practice

The right answer is usually not “one system owns everything.” It is more precise to assign source-of-truth ownership by attribute. HRIS often owns legal name, manager, department, and employment status. IAM or directory services may own account status, group membership, and authentication attributes. Collaboration tools may own profile image or display preferences, but only if those values do not drive security decisions. That separation reduces conflicting writes and makes downstream sync rules predictable. Operationally, teams should document three things:

• Authoritative system by attribute, not by application.
• Update path, including which system may write and which systems may only read.
• Conflict resolution rules when two systems disagree.

Current guidance suggests that the authoritative source should also be the workflow trigger for changes that affect access, especially hire, transfer, and termination events. That is where policies such as NIST SP 800-53 Rev 5 Security and Privacy Controls become practical: they support controlled provisioning, revocation, and review. For identity programs that also manage service accounts or machine identities, the same discipline applies to secrets and ownership boundaries; NHIMG’s Ultimate Guide to NHIs reinforces that governance, rotation, and visibility fail when responsibility is unclear. A common implementation pattern is to treat the HR system as authoritative for employment state, then let IAM ingest that state and enforce access changes without permitting downstream systems to overwrite it. These controls tend to break down in decentralized SaaS environments where multiple business systems can edit the same profile fields because the integration layer cannot reliably arbitrate conflicts.

Common Variations and Edge Cases

Tighter source-of-truth control often increases operational overhead, requiring organisations to balance data consistency against local team autonomy. There is no universal standard for every attribute, so the governance model should reflect business impact rather than technical convenience. For example, a marketing platform may legitimately own a display photo, but it should not own department or manager if those fields drive access control. Hybrid and merger environments are especially messy because two HR systems may both claim authority during transition, and legacy directories may still feed access decisions. In those cases, current guidance suggests a temporary hierarchy: name a primary system of record, mark secondary systems as read-only for security-relevant fields, and enforce a reconciliation cadence until consolidation is complete. Profile images are a good example of a non-security attribute that can still create confusion if copied incorrectly. Title and department, by contrast, are often entitlements-adjacent and should be governed more tightly. When disagreement persists, the safer default is to let the authoritative identity source win and require manual review for exceptions rather than allowing downstream systems to self-correct. That approach aligns with the broader identity lessons NHIMG documents in the Gladinet Hard-Coded Keys RCE Exploitation coverage, where hidden trust in stale data and embedded assumptions becomes an attack surface. The practical rule is simple: if an attribute can affect access, audit, or lifecycle decisions, its ownership must be explicit and enforced.

Related resources from NHI Mgmt Group

• What breaks when organisations do not have a single source of truth for transaction data?
• How should organisations handle large-scale deletion requests across multiple data brokers and systems?
• How should security teams govern consent when GenAI systems reuse personal data across multiple workflows?
• How should security teams apply consent controls across data pipelines and AI systems?