Data Classification Guide

Most organisations have a data classification policy, but few can say what share of their data actually carries a label or whether any control acts on it. Classification only earns its cost when a label changes what happens to the data: who can open it, whether it can leave, whether it is encrypted and how long it is kept. This guide covers how to choose a scheme, write handling rules per level, apply labels manually and automatically, classify structured and unstructured data, judge the accuracy of machine and AI-assisted classifiers, and measure coverage. It uses the UK Government Security Classifications Policy, FIPS 199 and Microsoft Purview sensitivity labels as worked examples, and is written for security, data protection and records teams designing or repairing a classification programme.

Key takeaways

• Classify to drive controls, not to describe data. Every level needs handling rules that a person or a system enforces; a label nothing reads is decoration.
• Keep the scheme small. Three or four confidentiality levels, with optional descriptors for personal, financial or legal data, beat a long taxonomy that users guess at. Microsoft notes effectiveness drops beyond about five main labels.
• Combine labelling methods. Use a default label for the bulk, recommended labels to coach users, automatic labelling for well-defined data types and manual labels for judgement calls such as trade secrets.
• Measure classifier accuracy before enforcing. Pattern matching and trainable or AI classifiers produce false positives and false negatives; run in simulation, sample results and tune before a label triggers encryption or blocking.
• Coverage is the headline metric. Report labelled share by store and level, accuracy from sampled reviews, and the volume of sensitive data found unlabelled or in the wrong place.

What classification is for, and the two models in use

• Impact categorisation (US federal model): FIPS 199 rates each information type for confidentiality, integrity and availability as LOW ("limited adverse effect"), MODERATE ("serious adverse effect") or HIGH ("severe or catastrophic adverse effect"), written as SC information type = {(confidentiality, impact), (integrity, impact), (availability, impact)}. A system takes the high water mark of the information it holds. NIST SP 800-60 Vol. 1 Rev. 1 maps information types to provisional categories. This model selects control baselines for systems.
• Confidentiality classification (labelling model): government tiers and commercial levels such as Public, Internal, Confidential and Restricted travel with the item as a marking and drive day-to-day handling.
• Use both: categorise systems by impact to choose baselines, and label data so DLP, encryption, sharing and retention controls can act on individual items. See the Data Security Guide.

Choosing a classification scheme

Two UK principles translate well to commercial schemes: a duty of confidentiality applies whether or not information is marked, and access follows need to know balanced with the need to share. Local policy may also waive marking of routine OFFICIAL material, the government equivalent of a default label.

A workable commercial four-level scheme

• Descriptors, not extra levels: add descriptors such as Personal Data, Financial or Legal Privilege when a handling rule depends on the data type rather than the sensitivity level, as the UK policy does.
• Personal data: NIST SP 800-122 sets a PII confidentiality impact level from six factors (identifiability, quantity, data field sensitivity, context of use, obligation to protect confidentiality, and access to and location), "to supplement the provisional confidentiality impact level". Quantity matters: bulk customer records usually sit a level above a single record.
• Payment data: place cardholder data and sensitive authentication data at the top level so PCI DSS scope is visible in labels. See the PCI DSS 4.0 Guide.

Roles and ownership

• Data owner: the accountable business leader who sets a data set's level, approves access and exceptions, and signs off retention. Under the UK policy only the originator can reclassify and users may challenge with a reason; the same rule works commercially.
• Data steward and custodian: the steward maintains definitions, catalogue entries and classifier rules for a domain and reviews results; the custodian operates the store and implements the controls the label demands.
• Inventory link: the catalogue or record of processing should hold owner, level and location for each data set. See the Data Mapping and ROPA Guide.

Handling rules per level

Write handling rules as a matrix where each cell is something a control can check.

DLP policies, sharing settings and conditional access rules should reference the label directly. See the Data Loss Prevention (DLP) Guide and the Encryption Guide.

Labelling methods: manual, default, recommended and automatic

A common pattern: default Internal, recommended Confidential when personal data is detected, automatic Restricted for card numbers and secrets at high confidence, and mandatory manual choice for legal, finance and M&A.

Worked example: Microsoft Purview sensitivity labels

• What a label can enforce: encryption with defined users, permissions and expiry; headers, footers and watermarks; and container settings for Teams, Microsoft 365 Groups and SharePoint sites (privacy, external sharing, unmanaged device access). A label can also apply no protection, a sensible first phase.
• Persistence and interoperability: the label "is stored in clear text in the metadata for files and emails", so other services can read it, and it "stays with the content, no matter where you save or store it". Each item carries a single sensitivity label.
• Priority: label order sets priority, with the most restrictive at the bottom. Priority decides which label wins when several auto-labelling conditions match and when a downgrade needs justification. Removing or lowering a label prompts for a justification that administrators can review in activity explorer.
• Policy settings: label policies set the default label, mandatory labelling and downgrade justification. Microsoft advises against encrypting default labels for documents and warns that mandatory labelling without training "can result in inaccurate labeling".
• Client-side versus service-side auto-labelling: client-side labelling runs in Office apps and supports automatic or recommended labels. Service-side auto-labelling policies label files at rest in SharePoint and OneDrive and mail in transit through Exchange Online (not mailboxes at rest), cannot recommend, and do not add visual markings.
• Simulation first: a service-side policy cannot label until it has run at least one simulation, which can take up to 12 hours, and Microsoft notes that a simulation match does not guarantee the file will be labelled. Tenants can have up to 100 auto-labelling policies, and a daily labelling throughput limit applies.
• Manual labels are respected: by default, service-side policies do not overwrite a manually applied label.
• Changing labels later: editing or deleting a label does not change content already labelled; the version applied is what is enforced. Settle the taxonomy before mass labelling. Other platforms and DSPM tools raise the same questions: what is enforced, which label wins, and what happens to labelled content when the scheme changes.

Classifying structured and unstructured data

Unstructured data

• Pattern-based detectors: Purview sensitive information types combine a primary element (a regular expression with or without checksum validation, a keyword list, dictionary or function), supporting elements within a proximity window (Microsoft's example uses 250 characters) and a confidence level: low 65, medium 75, high 85.
• Exact data match: matches against exact values from a real table of customers or employees, which finds your own records rather than anything shaped like an identifier. In Purview, a label condition using EDM must also include at least one non-EDM type.
• Trainable classifiers: learn a document category (contracts, CVs, source code, board minutes) from examples; Microsoft describes "hundreds of examples". Use them for content that has no reliable pattern.
• Encrypted content: classifiers "only work with items that aren't encrypted", so classify before encrypting and do not expect scanners to see inside password-protected archives.

Structured data

• Classify at column level: databases and warehouses are classified by sampling column values and reading names and schema. Google Cloud Sensitive Data Protection, for example, profiles BigQuery and Cloud SQL at project, table and column level, predicts infoTypes per column, calculates sensitivity and data risk levels, and re-profiles after 30 days by default or on schema change.
• Record it in the catalogue: store level and data type as column tags so masking and access policies can key off them.
• The table inherits the highest column: like the FIPS 199 high water mark, unless sensitive columns are masked or tokenised for that consumer.
• Derived data: extracts and training sets inherit the source level unless an owner approves a lower one after de-identification.

AI-assisted classification: accuracy and review

Machine learning and large language model classifiers extend coverage to content that patterns miss, but they are probabilistic. Google's documentation says plainly that its service "cannot commit to 100% accuracy across all scenarios". Treat every classifier as a component with a measured error rate.

• Know the trade-off: high confidence gives "the fewest false positives but the most false negatives", low the reverse. Microsoft pairs high confidence with low instance counts (five to 10) and low confidence with 20 or more.
• Measure precision and recall: run the classifier on a labelled test set from your own data. Precision matters when the label blocks or encrypts; recall matters when the label decides what gets protected at all.
• Use feedback loops: Purview offers Match and Not a Match feedback. A published custom trainable classifier cannot be retrained; Microsoft advises removing it and starting over with larger samples.
• Route uncertainty to people: automatic labels for high confidence, a recommendation or steward review for medium, nothing for low.
• Protect the pipeline and retest: an external AI classifier receives the content it classifies, and training sets hold the most sensitive examples, so both need Restricted handling. Retest after model or definition changes.

Trade secrets and high-value intellectual property

Under Directive (EU) 2016/943, information is a trade secret only if, among other conditions, it "has been subject to reasonable steps under the circumstances, by the person lawfully in control of the information, to keep it secret". Similar reasonable-measures tests exist in other jurisdictions. Labels and the access records behind them are practical evidence of those steps.

• Label trade secrets manually: no classifier knows which formula or process is the secret. Owners label them Restricted and keep a register of what is protected and where.
• Back the label with access control: a marking without restricted access weakens the reasonable-steps argument.
• Keep evidence: label history, downgrade justifications and access logs support a later claim. See the Insider Threat Programme Guide.

Where identity fits

• Labels with encryption are identity policy: an encrypting label grants usage rights to users and groups, so stale groups silently widen who can open Restricted content.
• Non-human readers: scanners, backup tools, search indexes, service accounts and AI assistants all read labelled data. Give each a scoped identity and record which labels it may process.
• AI assistants honour labels only as far as permissions allow: Microsoft 365 Copilot returns data from an encrypted item only if the user holds the EXTRACT usage right. Oversharing in the underlying permissions remains the bigger risk. See the Enterprise AI Copilot Security Guide and the Permission-Aware RAG Guide.

Implementing classification: a phased approach

1. Agree the scheme and handling matrix: three or four levels, descriptors, owners, and a one-page handling matrix approved by legal, privacy and the business.
2. Baseline: scan priority stores in discovery mode only to see where sensitive types concentrate.
3. Publish labels without protection: release labels and a default label to a pilot group, then everyone, to build coverage without blocking work.
4. Turn on recommendations and simulation: enable recommended labels in clients and run service-side auto-labelling in simulation. Sample matches per detector and tune until precision is acceptable.
5. Enforce in rings: enable automatic labelling and label-based DLP and encryption first for the narrowest, highest-confidence data (card numbers, secrets, Restricted sites), then widen by business unit.
6. Extend: tag warehouse columns and connect SaaS applications that can read labels.
7. Roll back safely: keep each enforcement policy in its own rule so it can be returned to test mode. Before removing an encrypting label from content, confirm who will need access afterwards, because removing the label also removes the encryption.

Decision guidance

• Three levels or four: choose four when a distinct set of data needs controls you cannot afford to apply to all Confidential data.
• Default label choice: Internal, not Confidential; a high default floods DLP with noise.
• Automatic versus recommended: automatic for detectors with measured high precision; recommended where precision is moderate or context matters.
• Encrypting labels: apply them to Restricted, where the cost to workflows (partner access, third-party tools, classifiers that cannot read encrypted items) is justified. For Confidential, prefer access controls and DLP.
• Small versus large: small organisations get most of the value from three levels, a default label, built-in card and national identifier detectors and a few DLP rules. Large ones need domain stewards, catalogue integration, column tagging and formal accuracy testing.

Detection and measurement

• Monitor: label applied, changed and removed events, downgrade justifications, auto-labelling matches, label-based DLP hits and external sharing of Confidential and Restricted items.
• Labelled coverage: percentage of items labelled per store and per level, tracked monthly. Report default-labelled items separately from deliberately labelled ones.
• Unlabelled sensitive data: items where a high-confidence detector matched but the label is missing or lower.
• Classifier precision: share of sampled automatic labels confirmed correct by stewards, per detector or classifier.
• Downgrade rate: downgrades and removals per 1,000 users per month, top justifications reviewed.
• Misplaced data: Restricted items in locations the handling matrix forbids.

Common failure patterns

• Policy without enforcement: a scheme that no DLP, sharing or access control references.
• Sensitive data outside labelled stores: labels on documents do nothing for exports, storage accounts and shared links. The Microsoft SAS token exposure shows how one over-permissive link exposed 38TB of internal data that sat outside any document labelling control.
• No rule for AI tools: handling matrices that predate generative AI leave staff to decide what can be pasted into public tools, as the Samsung ChatGPT source code leak showed.
• Too many labels: eight or more levels and sublabels lead users to pick at random.
• Enforcing untested classifiers: switching on blocking or encryption from unsampled simulation results, then a disruptive rollback that discredits the programme.

Framework mapping

Practitioner checklist

• Adopt a three or four level scheme with descriptors and a named owner for each data domain.
• Publish a one-page handling matrix covering storage, encryption, sharing, email, devices, AI tools and disposal.
• Set a default label of Internal and require justification for downgrades.
• Run automatic labelling in simulation and sample at least a few hundred matches per detector before enforcing.
• Reserve encrypting labels for Restricted data and test access for partners, search and eDiscovery first.
• Tag structured data at column level in the catalogue and apply masking from the tags.
• Keep a register of trade secrets with manual Restricted labels and restricted access.
• Give scanners, service accounts and AI assistants scoped identities and record which labels they may read.
• Report labelled coverage, unlabelled sensitive data, classifier precision and downgrade rate every month.

Standards and references

• NIST: FIPS 199 Standards for Security Categorization of Federal Information and Information Systems
• NIST: SP 800-60 Vol. 1 Rev. 1 Guide for Mapping Types of Information and Information Systems to Security Categories
• NIST: SP 800-122 Guide to Protecting the Confidentiality of Personally Identifiable Information
• Cabinet Office: Government Security Classifications Policy
• NARA: About Controlled Unclassified Information
• EUR-Lex: Directive (EU) 2016/943 on the protection of trade secrets
• Microsoft Learn: Learn about sensitivity labels
• Microsoft Learn: Apply a sensitivity label to content automatically

Related NHI Mgmt Group resources: Data Security Guide · Data Loss Prevention (DLP) Guide · Encryption Guide · CUI Guide · Data Mapping and ROPA Guide