Data Classification Policy Template: Levels, Labelling and Handling Rules

Every control that protects data, from encryption and DLP to AI tool restrictions and retention, depends on knowing how sensitive the data is, and most organisations have a classification scheme that staff ignore because it is vague, has too many levels, or never says what to actually do. This template gives you a data classification policy with four levels, clear labelling rules, a handling matrix that turns each level into concrete actions, and rules for what may and may not be entered into AI tools. It also covers data handled by service accounts, pipelines and AI agents, which inherit the classification of the data they touch. It is written for CISOs, DPOs, data owners and security architects; have legal and privacy teams review it before adoption. For the concepts and programme design behind it, see the Data Classification Guide.

How to use this template

• Replace text in square brackets, such as [Organisation], [Data Protection Officer] and [3 years], with your own terms and values.
• "Must" indicates a mandatory requirement. "Should" indicates a recommended practice where a documented exception may be justified.
• The four levels (Public, Internal, Confidential, Restricted) suit most organisations. If you must align to another scheme, such as the UK Government Security Classifications, map your levels to it in section 4.1 rather than adding levels. Fewer levels are applied more consistently.
• Keep the handling matrix (section 4.4) aligned with your encryption, DLP and retention controls. The encryption requirements per level are set out in the Encryption Policy Template.
• Place this policy beneath your top-level policy. See the Information Security Policy Template.

1. Purpose

This policy establishes how [Organisation] classifies, labels and handles information according to its sensitivity and the impact of its compromise. Its aim is that everyone who creates or uses [Organisation] information, and every system and automated process that handles it, applies protection proportionate to the risk: no less than the data needs, and no more than is useful.

2. Scope

This policy applies to all information created, received, stored or processed by or on behalf of [Organisation], in any format, including:

• Electronic documents, email, chat messages, meeting recordings and transcripts.
• Structured data in databases, data warehouses, data lakes, logs and backups.
• Source code, configuration files, infrastructure templates and the secrets they reference.
• Data used to train, fine-tune, prompt or ground AI models, and the outputs those models produce.
• Paper records and removable media.

It applies to all employees, contractors, and third parties with access to [Organisation] information, and to non-human identities (service accounts, API clients, pipelines, integrations and AI agents) that read, move or transform it. Each non-human identity must have a human owner accountable for the classification of the data it handles.

3. Roles and responsibilities

4. Policy statements

4.1 Classification levels

1. Information that has not been classified must be treated as Internal until its owner classifies it.
2. Classification must reflect the impact of compromise on confidentiality. Where integrity or availability matters more than confidentiality (for example safety data that is public but must not be altered), data owners must record that requirement separately.
3. Information must be classified at the lowest level that adequately protects it. Over-classification is a policy breach where it prevents legitimate sharing.
4. Optional descriptors such as [PERSONAL DATA], [LEGAL PRIVILEGE] or [COMMERCIAL] may be added to show why data is sensitive. Descriptors are not additional levels.
5. [Where you must align to UK Government classifications: Internal and Confidential map to OFFICIAL; Restricted maps to OFFICIAL-SENSITIVE.]

4.2 Assigning and changing classification

1. The creator of information must classify it at creation. The data owner is accountable for the classification of each data set.
2. A collection or aggregation of data must be classified at the level of the most sensitive item it contains, and at a higher level if combining items increases the impact (for example a full customer extract).
3. Derived data, including reports, extracts, model training sets, embeddings and AI outputs, inherits the highest classification of its inputs unless the data owner approves a lower level after review.
4. Only the data owner, or a delegate they name, may lower a classification. Anyone may raise a concern about classification with the owner.
5. Classification must be reviewed when data is published, when its sensitivity decays (for example results after release), and at least [annually] for data sets.

4.3 Labelling

1. Confidential and Restricted documents and email must carry a visible label (header, footer or banner) and an embedded metadata label applied with [labelling tool]. Internal labels should be applied; Public labels are optional.
2. Labelling tools must be configured with a default label of [Internal] for new documents and email, mandatory labelling before saving or sending, and a justification required to remove or downgrade a label.
3. Default labels must not apply encryption, so that legitimate external recipients are not locked out.
4. Automatic labelling or label recommendations must be configured for [payment card numbers, national identity numbers, health data, credentials and private keys].
5. Repositories (sites, teams, buckets, databases and data catalogue entries) holding Confidential or Restricted data must be labelled at the container level and recorded in [the data inventory or catalogue].
6. Structured data must be classified at column or field level in [the data catalogue] where data sets mix levels.

4.4 Handling matrix

For retention schedules and deletion methods, see the Data Retention and Secure Deletion Guide. For masking options, see the Tokenisation and Data Masking Guide.

4.5 AI tools and AI agents

1. Users must not paste, upload or connect Confidential or Restricted data, credentials, private keys or source code to any AI tool not approved for that level.
2. AI tools and agents that retrieve data (for example through retrieval-augmented generation, connectors or plugins) must enforce the access rights of the requesting user. An agent must not use a service account with broader access than the user it acts for.
3. AI agents and their service accounts must be registered with an owner, the highest classification they may access, and the systems they may write to.
4. AI-generated outputs inherit the classification of the inputs and retrieved content (section 4.2), and must be labelled before being shared.
5. Restricted data must not be used to train or fine-tune models without data owner and [DPO] approval and a completed [DPIA].

See the AI Acceptable Use Policy Template and the Generative AI Data Loss Prevention Guide.

4.6 Non-human access to classified data

1. Service accounts, pipelines and integrations must be granted access only to the data sets and classification levels their documented purpose requires.
2. Credentials that grant access to Restricted data are themselves Restricted and must be held in [approved secrets manager], never in code, tickets or chat.
3. Data movement by automated jobs from a higher to a lower classified system must be approved by the data owner and logged.

5. Exceptions

1. Requests for exceptions to the handling matrix must be submitted to [the exception register] with the data set, business reason, compensating controls and an end date.
2. Exceptions for Restricted data require approval from the data owner and [CISO]; others from the data owner and [Head of information security].
3. Exceptions expire after no more than [12 months] and must be reviewed every [6 months].

6. Compliance and monitoring

1. [Organisation] must use [DLP, labelling analytics and data discovery tools] to detect unlabelled sensitive data, label downgrades, and transfers of Confidential or Restricted data to unapproved destinations, including unapproved AI services.
2. Data discovery scans must run against [file shares, cloud storage, SaaS and databases] at least [quarterly] to find sensitive data in the wrong place.
3. [Security operations] must report quarterly to [the CISO] on:
   • Percentage of documents and email carrying a label, and percentage of repositories with a container label.
   • Label downgrades and removals, with justifications reviewed.
   • Sensitive data found in locations not approved for its level.
   • DLP incidents by level and channel, including AI tool uploads blocked or warned.
   • Percentage of data sets with a current owner and classification review.
   • Service accounts and AI agents with access to Restricted data, and those without an owner.
4. Staff must complete classification and handling training on joining and [annually]. Breaches of this policy may be handled under [disciplinary procedure].

7. Review and approval

Implementation guidance

Where the design choices come from

• Impact-based levels: the definitions in section 4.1 follow the FIPS 199 approach of limited, serious, and severe or catastrophic adverse effect, and its high water mark principle, which section 4.2 applies to aggregated data.
• Proportionality and descriptors: the UK Government Security Classifications Policy (version 2.0, August 2024) bases classification on the impact of compromise and the likely threat, stresses proportionate protection, notes that aggregated data sets may need additional controls, and uses descriptors such as COMMERCIAL and PERSONAL DATA that are not classifications in themselves. It also states that only the originator can reclassify information, which section 4.2 adopts for data owners.
• Labelling tool settings: the defaults in section 4.3 (default label, mandatory labelling, downgrade justification, not defaulting to an encrypting label, container labels) correspond to features of common labelling tools. Microsoft Purview sensitivity labels, for example, support all of these, and Microsoft advises against default labels that apply encryption.

Rollout

1. Agree the levels and handling matrix with data owners and the DPO before configuring tools.
2. Run data discovery against your largest repositories to find where Confidential and Restricted data actually sits.
3. Publish labels in recommend-only mode for [one quarter]: users see suggestions, nothing is blocked, and you measure accuracy and false positives.
4. Turn on default and mandatory labelling, then automatic labelling for the clearest data types (card numbers, identity numbers, private keys).
5. Enable DLP in audit mode, review incidents for [30 days], then move to warn and finally block for Restricted data. Keep the audit-only policy ready to restore if blocking disrupts a critical process.
6. Extend controls to AI: block unapproved AI services for Confidential and Restricted data, and confirm that approved AI tools honour labels and user permissions.

Failure patterns this policy is written to prevent

• Sensitive data pasted into public AI tools: in the Samsung ChatGPT source code leak, staff pasted source code and a meeting transcript into the public ChatGPT service in three separate incidents, after which Samsung restricted generative AI tools. Section 4.5 sets per-level rules before that happens.
• Everything marked Confidential: blanket over-classification makes labels meaningless and drives staff to unapproved sharing tools.
• Labels with no consequences: a label that does not drive DLP, encryption or access controls is decoration. The handling matrix must map to configured controls.
• Derived data left unclassified: extracts, embeddings and AI outputs often escape classification even when their sources are labelled.

Framework mapping

Sources for the design choices

• Cabinet Office: Government Security Classifications Policy
• NIST: FIPS 199, Standards for Security Categorization of Federal Information and Information Systems
• Microsoft Learn: Learn about sensitivity labels

Related NHI Mgmt Group resources: Data Classification Guide · Data Loss Prevention (DLP) Guide · Data Security Guide · Shadow AI Policy Template · Encryption Policy Template