Ownership should be shared, but not blurred. Data leaders and security leaders need a joint operating model, with CDO and CISO functions aligning on categories, rules, and response logic. The article’s core point is that effective zero trust for data depends on business context and security enforcement working together, rather than operating as separate programmes.
How should ownership work when zero trust spans both security and data teams?
Zero trust for data works best when ownership is explicit, because the control depends on both data meaning and enforcement. The data function is usually the authority on classification, business context, and acceptable use, while security owns the control plane, policy enforcement, monitoring, and exception handling. Treat the arrangement as shared accountability with clear decision rights, not a committee with no owner.
That distinction matters because data categorisation is not just labeling. It determines who can access what, which protections apply, and how quickly an issue can be contained. If the business context is wrong, the security controls will be precise but misapplied; if the enforcement is weak, the right classification still will not reduce exposure.
For teams building the operating model, the practical question is who can make the categorisation decision, who can challenge it, and who can override it when the risk changes. The cleanest pattern is a jointly governed taxonomy with one accountable business owner per data domain and one accountable security owner for control design and enforcement.
What does shared ownership need to cover in practice?
Shared ownership has to cover three things: the category itself, the rules attached to that category, and the response logic when the data moves, changes sensitivity, or is accessed in an unusual way. The category is a business statement, but the rules are a security commitment, and the response logic is where the two teams meet during real incidents.
A useful operating model separates policy intent from implementation detail. Data leaders define what the data is, what it means to the business, and what level of sensitivity or handling it requires. Security leaders translate that into access controls, segmentation, logging, and enforcement patterns that can work across platforms and workloads.
At scale, the hardest issue is consistency. If each domain invents its own labels, data teams lose comparability and security loses enforceability. The better pattern is a shared taxonomy, documented decision criteria, and a review cycle that rechecks categories when data sources, regulators, or usage patterns change.
Guide to SPIFFE and SPIRE is useful here because it shows how trust can be anchored in workload identity and policy, which is often the enforcement layer underneath data-centric zero trust.
Where do the boundaries usually fail?
Boundaries fail when classification is treated as a one-time governance exercise or when security assumes the data team will infer control requirements automatically. In practice, zero trust fails when context, policy, and enforcement drift apart. A dataset can be correctly named but still overexposed, underlogged, or allowed into too many downstream systems.
Another common failure is unclear exception handling. If a business owner can relabel sensitive data without security review, the model becomes easy to bypass. If security can hard-block categorisation changes without understanding business impact, teams create shadow processes that weaken the whole programme.
Ultimate Guide to NHIs, Standards is relevant because zero trust depends on how identity and access controls are applied to the systems that store, move, and process the data, not just to the data label itself.
Risk and Threat Considerations
Misowned data categorisation creates both governance risk and security exposure. If the business meaning is set without enforcement, sensitive data can be over-shared; if enforcement is set without business context, controls can be misaligned, inconsistent, or bypassed through exception paths.
Failure mechanism: The failure usually comes from split accountability, where data teams define sensitivity but security teams own the control plane without a shared decision model for category changes, exceptions, and downstream propagation.
Impact: That split can lead to over-permissioned access, weak containment during incidents, inconsistent handling across platforms, and slower response when a dataset changes sensitivity or enters a new use case.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST Zero Trust (SP 800-207) and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Shared ownership of data categorisation sits inside zero trust policy, access, and enforcement decisions. |
| Recommendation — Apply zero trust principles to tie data categories to explicit access and verification rules. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Data categories determine entitlement scope, so least privilege is central to enforcement. |
| AU-6 — Audit Review, Analysis, and Reporting | Shared ownership needs monitoring and review of access and category-change events. | |
| AC-3 — Access Enforcement | Categorisation only matters when policy enforcement reliably follows it. | |
| Recommendation — Constrain access to each data class to the minimum permissions required. Review category changes and access events to detect misclassification or drift. Enforce access decisions consistently from the approved data category. | ||
Practitioner Guidance
What to verify: Confirm that every major data domain has one accountable business owner and one accountable security owner, with a documented rule for who can change the category and who must approve exceptions. If that cannot be stated plainly, the operating model is already too blurred to trust.
Decision rule: If the question is “what is this data and how should it be used,” data leadership should lead; if the question is “how is access enforced and monitored,” security should lead. Where the two collide, require a joint sign-off so business meaning and control impact stay aligned.
Practitioner takeaway: Zero trust for data succeeds when ownership is shared at the policy level but unambiguous at the decision level, because clear accountability is what keeps categorisation, control design, and incident response moving together.
Related resources from NHI Mgmt Group
- How should security teams implement data categorization as part of a zero trust programme?
- How should security teams apply zero trust to data estates that span cloud, SaaS, and on-prem systems?
- Who should own Zero Trust justification across security and IAM teams?
- How should security teams implement Zero Trust when access data is fragmented?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
