Identity Data Quality: The Problem Nobody Wants to Own 

Connecting an application moves the data. It does not make the data trustworthy. 

Connecting an application to a governance platform feels like a finish line. The integration is built, the accounts appear in the dashboard, and the application moves from the ungoverned column to the governed one. In practice, the connection is a starting line. What flows across it, the identity data itself, determines whether the governance that follows is real or only apparent. And that data is very often a mess. 

Earlier in this series we argued that “connected” should mean you can act on access, not just see it. There is a corollary that matters just as much: acting on bad data is worse than not acting at all. A connection that faithfully provisions and deprovisions access based on inaccurate, inconsistent, or mismapped identity data will make confident, automated, wrong decisions at scale. Speed and automation do not fix dirty data. They amplify it. 

Transport is not transformation 

Most conversations about connectors are really conversations about transport. Can we reach the application? Can we pull its accounts and push changes back? Those are necessary questions, and they get the attention because they are the visible part of integration. 

The harder question is transformation. Once the data arrives, is it meaningful? Does a user in this application map to the same person in the identity system? Does an entitlement called “Level 3” here correspond to anything the governance platform can reason about? Is the department field populated, consistent, and correct, or is it blank, freeform, or wrong? Transport gets the data from A to B. Transformation makes it usable once it lands. A program that solves transport and ignores transformation has built a fast pipe carrying unreliable information. 

What dirty identity data looks like 

Dirty identity data is rarely dramatic. It is mundane and pervasive. The same person exists as three slightly different accounts across three systems, and nothing links them. Job titles and departments are entered by hand and never reconciled. Entitlements have names that made sense to whoever configured the application and mean nothing outside it. Accounts persist with no clear owner. Attributes that governance decisions depend on are missing or stale. 

None of these are exotic failures. They are the normal state of identity data in a large organization, and they are exactly the conditions under which automated governance quietly goes wrong. 

Why nobody wants to own it 

Data quality is the problem nobody wants to own because ownership is genuinely unclear. The application team treats its data as an internal matter. HR owns the system of record for employees but not for contractors, service accounts, or the many local accounts scattered across departmental systems. The identity team owns the governance platform but inherits whatever data the connected systems hand it. Each group can reasonably say the problem starts somewhere else. 

So it sits in the gap between teams, unowned and unaddressed, until a certification produces a nonsensical result or an audit asks a question the data cannot answer. Unglamorous and cross-functional, identity data quality is easy to defer and easy to blame on someone else. That is precisely why it festers. 

Automation does not clean up dirty data. It executes on it faster and more confidently than a human ever would. 

Dirty data produces dirty decisions 

The cost surfaces in the decisions governance is supposed to get right. A reviewer certifying access cannot approve intelligently when the entitlement names are meaningless and the roles are inconsistent, so they rubber-stamp, and the certification becomes theater. A deprovisioning workflow misses accounts because the identity correlation failed and the system never realized two accounts belonged to the same departing employee. Access decisions get made on attributes that were wrong months ago. The governance program runs smoothly and produces the wrong answers, which is more dangerous than a program that visibly struggles. 

What good identity governance actually requires

Trustworthy governance requires an identity data layer that does three things. It normalizes, bringing attributes, naming, and entitlement structures from every connected source into a consistent model. It correlates, recognizing that accounts across different systems belong to the same identity, so a person can be governed as a person rather than as a scattering of unlinked logins. And it maps meaning, ensuring that an entitlement or role means the same thing to the governance platform regardless of which application it came from. 

This identity layer is often treated as a supporting capability rather than part of governance itself. In practice, it is foundational. At READI, that responsibility sits within the Atlas Unified Identity Directory, which normalizes and correlates identity data from every connected source into a single model while property mapping preserves the meaning of attributes and entitlements across systems 

Own it, or inherit its failures 

Identity data quality will never be the problem a team volunteers for. It has no obvious owner, it produces no visible wins, and it is easy to assume someone upstream already handled it. But every governance decision an organization makes rests on it. The programs that hold up are the ones that stop treating data quality as somebody else’s job and start treating it as the foundation it actually is. Connecting an application moves the data. Making that data trustworthy is the work that turns a connection into governance.