Who is accountable when data definitions differ across departments?

Why This Matters for Security Teams

When departments use different definitions for the same data element, the problem is not just reporting noise. It affects access decisions, control validation, audit evidence, and incident response. The accountable party is usually split between the source-data owner and the governance function that approves shared definitions, but if either side is undefined, accountability evaporates. This is why data governance is a control issue, not a documentation exercise. NHI Mgmt Group research shows that 68% of organisations do not know how to fully address NHI risks, which is a useful warning sign for broader identity and data ownership gaps as well, as seen in the Ultimate Guide to NHIs — Key Research and Survey Results.

The practical failure is that teams often assume a business glossary or BI layer will resolve disagreement automatically, when in reality the disagreement usually reflects missing decision rights. The closest external reference point is the NIST Cybersecurity Framework 2.0, which reinforces that governance, risk, and ownership have to be explicit before controls can work. In practice, many security teams encounter definition drift only after a control exception, audit finding, or data incident has already exposed it.

How It Works in Practice

Accountability works best when it is assigned at two levels. First, the source system owner is responsible for the meaning, quality, and lineage of the data element at its origin. Second, a governance body approves cross-functional definitions so that downstream consumers do not invent their own versions. That governance function should not own the data itself; it should arbitrate disputes, publish the canonical definition, and enforce change control.

Practitioners usually make this concrete through a data dictionary, ownership register, and exception workflow. A useful operating pattern is:

• Assign a named business owner for each critical data definition.
• Assign a steward or governance lead to approve changes and resolve conflicts.
• Record lineage so teams can trace where a definition originated and how it is used.
• Require consumers to map local terminology back to the shared definition before reporting or automation.
• Review mismatches during control testing, not only during architecture reviews.

This matters because definitions directly affect downstream identity and security controls. If one department defines “active account” differently from another, access reviews, offboarding, and exception handling will all produce inconsistent results. The broader NHI risk picture in the Ultimate Guide to NHIs — What are Non-Human Identities shows why ownership and visibility cannot be separated: if you cannot agree on what an identity or record means, you cannot govern it consistently. These controls tend to break down when data definitions are embedded in spreadsheets, local BI tools, or manually maintained reports because no single team can prove which version is authoritative.

Common Variations and Edge Cases

Tighter ownership often increases coordination overhead, requiring organisations to balance speed against consistency. That tradeoff is real, especially in federated enterprises where departments need some freedom to model local needs. Current guidance suggests that local variation is acceptable only when there is a clearly mapped canonical definition and an approved exception process. There is no universal standard for this yet, so organisations should treat it as a governance design decision rather than a compliance checkbox.

Edge cases usually appear in mergers, shared services, and analytics-heavy environments. In a merger, both legacy definitions may need to coexist temporarily, but only one should be authoritative for reporting and control purposes. In analytics teams, the same term may have different operational and analytical meanings, which is acceptable if the distinction is explicit and versioned. For security and risk reporting, ambiguity is usually unacceptable because it weakens traceability. The goal is not to force every department into identical language, but to ensure every material definition has a named owner, a documented approval path, and a single source of truth for control decisions.

Related resources from NHI Mgmt Group

• Who is accountable for email authentication across domains and SaaS senders?
• Who is accountable when third-party cloud access is abused in a data breach?
• Who is accountable when a leaked Git token leads to cloud data exposure?
• Who is accountable when a supplier platform exposes customer data?