Who is accountable when identity data from a connected system becomes unreliable?

Why This Matters for Security Teams

When identity data from a connected system becomes unreliable, the problem is not just data quality. It becomes a governance failure that can distort access reviews, break audit evidence, and misstate who or what is entitled to act. NIST Cybersecurity Framework 2.0 treats identity and access governance as an ongoing control function, not a one-time integration task, which is why bad source data cannot be ignored until the next recertification cycle.

For NHI programmes, that distinction matters because service accounts, API keys, and connected system identities often outlive the systems that created them. NHIMG research shows that 97% of NHIs carry excessive privileges and only 5.7% of organisations have full visibility into their service accounts, which makes a drifting source system especially dangerous. The broader issue is visible in the Ultimate Guide to NHIs and the Top 10 NHI Issues, where poor visibility and stale entitlements repeatedly amplify risk.

In practice, many security teams encounter source-system drift only after an audit finding, access incident, or failed recertification has already exposed the gap, rather than through intentional monitoring.

How It Works in Practice

Accountability sits with the identity programme owner because they own the trust boundary around the identity graph, even when the upstream data is owned by another platform team. That means they must define which connected systems are authoritative for which attributes, how freshness is measured, and what happens when a source becomes inconsistent, unavailable, or demonstrably wrong. NIST guidance on governance and ongoing access control supports this model, while operational execution usually depends on documented ownership, exception handling, and escalation paths.

A practical approach separates data stewardship from business accountability:

• Assign an owner for each source system and each identity attribute, such as account status, role, manager, or entitlement.
• Define trust levels for sources, including which fields are authoritative and which are advisory only.
• Monitor for drift, such as stale records, conflicting attributes, and delayed deprovisioning.
• Quarantine unreliable records so they do not silently feed recertification, provisioning, or audit evidence.
• Require remediation SLAs and escalation when a source cannot be corrected quickly.

This is where the 52 NHI Breaches Analysis is useful: identity failures rarely begin with a single exploit, but with a chain of weak data, weak ownership, and weak review. External guidance from the NIST Cybersecurity Framework 2.0 helps teams map this into govern, identify, protect, detect, and respond activities rather than treating it as a one-off IAM ticket.

These controls tend to break down when connected systems have no named data owner, because no team feels responsible for fixing the source or for stopping bad data from propagating.

Common Variations and Edge Cases

Tighter source controls often increase operational overhead, requiring organisations to balance better identity assurance against slower onboarding, more exception handling, and more coordination across platform teams. There is no universal standard for this yet, but current guidance suggests that the sharper the downstream decision impact, the stricter the source validation should be.

Edge cases usually appear in federated environments, M&A integrations, and third-party managed systems. In those cases, the identity programme owner still remains accountable for the trust model, but the operational owner of the source may be external, which makes contract language, evidence collection, and remediation SLAs essential. If a source cannot meet minimum quality thresholds, it should be downgraded from authoritative to advisory or removed from decisioning altogether.

That principle also applies to non-human identities exposed to shared platforms, where unreliable source data can cause stale secrets, overprovisioning, or orphaned service accounts. The Ultimate Guide to NHIs - Key Research and Survey Results shows why these mistakes persist at scale: identity sprawl and weak visibility make bad records hard to spot before they influence access. In mature programmes, unreliable data is treated as a control failure, not a clerical error.

Related resources from NHI Mgmt Group

• Who is accountable when a vulnerability becomes an identity-driven breach?
• Why is it important to integrate identity and data governance?
• Why do silent data changes create governance risk for identity and security programmes?
• How do data governance and identity governance intersect in AI programmes?