How should organisations write a data classification policy that people actually follow?

Why This Matters for Security Teams

A data classification policy only works when it turns judgment into routine behaviour. If people cannot tell whether data is public, internal, confidential, or restricted in a few seconds, they will ignore the policy and default to convenience. That is why classification must connect directly to handling rules, not sit as a theoretical governance document. NIST’s NIST Cybersecurity Framework 2.0 and NIST SP 800-53 Rev 5 Security and Privacy Controls both reinforce that protection must be operational, repeatable, and accountable.

For organisations running modern cloud, SaaS, and AI-enabled workflows, the challenge is not just labeling files. It is ensuring the label drives access control, sharing, retention, logging, and disposal across systems and teams. That becomes harder when sensitive content moves through collaboration tools, tickets, chat, and automation. NHIMG research on Top 10 NHI Issues shows why this matters: 97% of NHIs carry excessive privileges, and 79% of organisations have experienced secrets leaks. In practice, many security teams discover classification drift only after data has already been copied into the wrong system, rather than through intentional governance.

How It Works in Practice

The most usable policies start with a small number of sensitivity levels and plain-language criteria. Each level should answer three questions: what kind of data is this, who may access it, and how must it be handled. The policy then maps those answers to specific rules for storage, sharing, encryption, retention, and disposal. That mapping matters more than the label itself, because users remember concrete actions, not abstract definitions.

A workable policy usually includes:

• Clear examples for each level, including edge cases such as customer data, source code, credentials, and AI training inputs.
• Named owners for the policy, data stewards for classification decisions, and approvers for exceptions.
• Simple handling rules embedded in tools, such as DLP prompts, access restrictions, and default sharing settings.
• Review triggers for new systems, new regulations, and new AI use cases that change how data flows.

Operationally, classification should be tied to the systems where people actually work. If a file is marked restricted but can still be emailed externally or pasted into an AI assistant, the policy has failed. NHIMG’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs shows the same principle for machine identities: governance only sticks when lifecycle controls are embedded into day-to-day operations. For classification, that means aligning with NIST Cybersecurity Framework 2.0 and using NIST SP 800-53 Rev 5 Security and Privacy Controls to translate labels into enforceable control objectives.

These controls tend to break down when classification depends on manual judgment at scale, because users cannot apply nuanced rules consistently across high-volume collaboration and AI-assisted workflows.

Common Variations and Edge Cases

Tighter classification often increases user friction, requiring organisations to balance stronger protection against the cost of slower work and more exceptions. The best practice is evolving, but current guidance suggests that policies fail when they try to classify everything with the same level of precision. A short policy with a few well-chosen categories usually outperforms a dense document with many overlapping labels.

One common edge case is AI-generated or AI-processed content. If sensitive source material enters a model, prompt, or downstream summary, the resulting output may inherit the original sensitivity even when it looks harmless. Another is third-party sharing, where a document may be non-sensitive internally but restricted once shared outside the organisation. The Ultimate Guide to NHIs — Regulatory and Audit Perspectives is relevant here because auditors increasingly expect organisations to show not just policy language, but evidence that handling rules are enforced consistently.

Finally, classification should not be static. Update it when new data types appear, when business units adopt new collaboration tools, or when legal requirements shift. If the policy cannot be understood by a new employee in minutes and applied without escalation for routine cases, it is too complex to survive contact with daily operations.

Related resources from NHI Mgmt Group

• How should organisations enforce data classification when employees paste information into AI tools?
• How should organisations write an AI acceptable use policy that employees will follow?
• Should organisations prioritise password policy enforcement or data classification first to reduce identity attack impact?
• How do organisations know whether AISPM is actually working?