Why do organisations struggle to secure data even when classification is mature?

Why This Matters for Security Teams

Mature classification often creates a false sense of control. Labels, tags, and policy tiers can show that data is important, but they do not stop over-permissioned users, stale service accounts, or cloud roles from reaching it. Security teams usually discover the gap when an investigation, audit, or breach reveals that the data governance model was stronger than the access model. That is why data protection has to be treated as an identity and entitlement problem, not only a records management problem.

The practical issue is that data classification is usually static while access pathways are dynamic. A file can be tagged correctly, yet still be exposed through inherited permissions, SaaS sharing, API tokens, or machine identity trust that was never revisited. Control frameworks such as NIST SP 800-53 Rev 5 Security and Privacy Controls recognise this gap by pairing information protection with access control, auditability, and continuous monitoring. In practice, many security teams encounter the exposure only after permissions have already drifted beyond the original classification intent, rather than through intentional review.

How It Works in Practice

Effective protection starts by connecting classification to enforcement points. A mature program should translate a sensitive label into decisions about who can read, copy, export, share, or automate against the data. That means mapping classification to identity context, group membership, privileged roles, application access, and machine identity trust. Without that mapping, the label becomes descriptive rather than preventive.

Operationally, teams usually need several layers working together:

• Classification policy that defines sensitivity levels and handling rules.
• Access governance that reviews users, roles, and entitlements against those rules.
• Privileged access controls for administrators and break-glass paths.
• Secret and token governance for service accounts, integrations, and automation.
• Logging and detection so unusual access to sensitive data can be investigated.

This is where identity security becomes decisive. A classified dataset in a cloud warehouse may still be reachable through a broad IAM role, an over-scoped API key, or a non-human identity created for a workflow and never narrowed. The same issue appears in SaaS platforms where sharing settings, inheritance, and delegated administration override the intended policy. NIST guidance on access control and monitoring is useful here, but the real challenge is operational: classification must be machine-readable enough to drive enforcement, and the enforcement must be reassessed whenever identity, role, or integration changes. For related identity governance principles, NIST SP 800-63 Digital Identity Guidelines help frame assurance, lifecycle, and authentication decisions that influence who can reach sensitive systems.

Teams that do this well also validate policy outcomes, not just policy existence. They test whether a person with the right job title but the wrong need-to-know can access the asset, whether a contractor can inherit access through a shared group, and whether an automation account can traverse from one sensitive repository to another. These controls tend to break down when data is spread across multi-cloud and SaaS environments because entitlement sprawl, inherited permissions, and disconnected logs make it difficult to confirm the true effective access path.

Common Variations and Edge Cases

Tighter data controls often increase operational overhead, requiring organisations to balance stronger protection against business speed and administrative complexity. That tradeoff is especially visible in environments with rapid cloud change, cross-functional analytics, or heavy automation, where access can be legitimate but short-lived.

There is no universal standard for this yet, but current guidance suggests that the hardest edge cases are not the most sensitive records themselves. The hardest cases are the systems around them: shared workspaces, data lakes, service principals, partner integrations, and AI workflows that pull from multiple sources. A dataset may be classified correctly, yet its derivatives, cached copies, and model training inputs may fall outside the original policy scope.

This is where identity beyond traditional IAM becomes relevant. If a non-human identity can read sensitive data, then the classification program must account for that identity’s lifecycle, ownership, rotation, and revocation. Otherwise, the organisation may know what the data is worth while still lacking practical control over who or what can access it. For organisations handling regulated personal or financial data, CISA guidance on Zero Trust Architecture reinforces the need to verify access dynamically rather than trust a label or network location alone.

Classification also struggles when business units interpret sensitivity differently or when shadow IT introduces parallel storage and collaboration tools. In those cases, the gap is not the label itself but the absence of a shared control plane that can enforce the label consistently across identity, infrastructure, and application boundaries.

Related resources from NHI Mgmt Group

• What do organisations get wrong about automated data classification?
• What breaks when organisations rely on manual data classification for AI security?
• Should organisations prioritise data classification or permission cleanup first?
• How should organisations secure mobile identity verification without over-sharing personal data?