Data Classification Policy Template: A Practical Guide

Before you copy the template, confirm the following:

Scope: Which information systems, repositories and workflows does the policy cover?
Owner: Who is accountable for the policy and who approves changes?
Applicable duties: What legal, contractual or regulatory obligations shape your handling rules?
Level model: How many classification levels will you use, and what are their boundary tests?
Lifecycle controls: What handling decisions apply at each stage from creation to disposal?
Exception path: How do users request and receive approval for deviations?

What is a data classification policy?

A data classification policy sits between your information-security strategy and the day-to-day decisions your people make about documents, databases and shared files. It answers three questions: what levels exist, who decides which level applies, and what handling rules follow from that decision.

The UK Government Security Classifications Policy links tiers to the likely impact of compromise and the capability of potential threat actors. It applies to government and partners, so do not copy it as a business standard. The useful principle is proportionality: define tiers and controls for your own context.

The ICO's guide to data security describes security as risk-based. Appropriate measures depend on the nature, scope, context and purpose of processing, along with the likelihood and severity of harm. A formal policy can help evidence what your organisation has decided, but there is no one-size-fits-all form prescribed by the ICO.

A classification policy is not the same as a data-protection policy, a records-management schedule or a technical access-control configuration. It is the governance document that connects those artefacts: it defines the levels, assigns ownership, and states the handling expectations that other documents and systems then implement.

Decisions to make before using the template

The template below uses bracketed placeholders where your organisation must make a specific choice. Before you begin, gather input from the people who will live with the policy:

Information owners. Each business function or data domain should have a named owner who can classify information within their area and approve exceptions.
Legal and compliance. Confirm which duties apply to your data: UK GDPR, sector-specific regulation, contractual confidentiality, export controls or professional obligations.
IT and security. Understand what technical controls are available or planned, so the policy's handling rules are achievable.
Operations and knowledge workers. The people who create, share and use documents daily need to recognise the levels in their own work.

The MoJ Information Classification and Handling Policy shows one public-sector implementation: identify information assets, name owners, record locations and assess the likely effect on confidentiality, integrity and availability. Adapt that structure; its departmental rules are not universal obligations.

Copy-and-adapt data classification policy template

Use this template as a starting point and adapt every bracketed section to your organisation's context. It is practical guidance, not a statutory requirement or universal standard.

Purpose

This policy defines how [Organisation Name] classifies information and the handling rules that apply to each classification level. It supports [list applicable duties, for example UK GDPR obligations, contractual confidentiality, sector-specific regulation]. It does not replace technical security controls, legal advice or individual risk assessments.

Scope

This policy applies to [define scope: all information created, received, stored or processed by the organisation; specific systems; specific business units]. It covers information in all formats, including electronic documents, databases, emails, instant messages, physical records and verbal communications that are subsequently recorded.

Information that is [list exclusions, for example already publicly available under a licence, covered by a separate sector-specific policy] is outside this policy's scope but remains subject to [relevant duty or policy].

When defining scope, you will need to identify sensitive data that warrants tighter handling beyond what the law specifically requires. The criteria for sensitivity are organisation-defined and should be recorded in the policy or a linked procedure.

Definitions

Classification level: An organisation-defined category that communicates the sensitivity or impact of information and connects it to handling rules.
Personal data: Information relating to an identified or identifiable living person, as defined under UK GDPR.
Special-category data: A defined subset of personal data under UK GDPR covering racial or ethnic origin, political opinions, religious or philosophical beliefs, trade-union membership, genetic data, biometric data for identification, health, sex life and sexual orientation.
Criminal-offence data: Data concerning criminal offences and related proceedings, protected under a separate regime.
Sensitive information (organisational): Information that your organisation has defined as warranting tighter handling because of organisational, contractual, security or other contextual risk, whether or not a named legal category applies.
Label or marking: A human-readable or machine-readable attribute that records a classification decision.

These definitions keep legal categories and organisational tiers separate. A legal category does not automatically map to one organisational level; the mapping is a local decision.

Principles

Classification is a governed decision, not an automatic consequence of content.
The level reflects the likely impact of unauthorised disclosure, alteration or loss, considering context, aggregation and purpose.
Controls are proportionate to the level and the organisation's risk appetite.
A label records a decision; it does not by itself apply a technical control.
Classification can change when context, purpose, duties or impact change.

Classification levels

[Organisation Name] uses the following illustrative levels. The number and names are a local choice; the boundary tests must be specific enough that two reasonable people would reach the same decision.

Level	Boundary question	Example
Public	Is this information approved for public release?	Published annual report, marketing brochure
Internal	Would unauthorised disclosure cause limited harm to the organisation?	Internal process documentation, staff directory
Confidential	Could disclosure, alteration or loss cause material harm or breach a duty?	Client contracts, unpublished financial data
Restricted	Could compromise cause severe harm or trigger stringent legal or contractual consequences?	Security credentials, vulnerability details, board strategy

If you still need to define your tiers, choose your data classification levels before writing the handling rules.

Ownership

Policy owner: [Name or role] is accountable for this policy, its review and its interpretation.
Information owners: [List or reference the register of information owners by function or data domain].
Classification authority: [Define who can assign or change a classification, and the escalation route for disputes].
Users: All staff, contractors and third parties with access to organisational information are responsible for applying the correct level and following the associated handling rules.

Labelling

[Organisation Name] requires [define in-scope assets] to carry a classification label at creation or first receipt.
Labels should be visible (header, footer, metadata) and, where technically feasible, machine-readable.
A label records the classification decision; it does not enforce access controls or apply encryption by itself.
For information at multiple levels, [define the local rule: for example, apply the highest level to the whole document, split the content, or require an information-owner decision].

Access

Access to information should follow the principle of least privilege: users receive access only to the levels and specific assets their role requires.
[Define access approval routes for each level, for example line-manager approval for Confidential, policy-owner approval for Restricted].
Access reviews should occur [define frequency, for example annually or on role change].

Storage

Information should be stored in [define permitted repositories by level].
[Define any required encryption, access logging or physical security controls by level].
Personal data and special-category data should be stored in accordance with UK GDPR and any applicable sector rules.

Sharing information externally requires [define approval route].
Transmission of Confidential or Restricted information should use [define approved channels, for example encrypted email, secure file transfer].
[Define any restrictions on sharing with specific jurisdictions or recipient types].

Third parties and AI services

Before sharing information with a third party or AI service, confirm that the proposed use is permitted under this policy and any applicable contract or law.
Assess the provider's security posture, data-processing terms and jurisdiction.
Minimise the data shared: include only what the task requires.
For documents entering an AI workflow, consider a separate pre-ingestion check. You can see the document review workflow to place that checkpoint after authorisation and minimisation.
[Define any additional provider-specific controls, for example data-processing agreements, residency requirements].

Retention and disposal

Retention periods are determined by [define source: legal obligation, contract, business need, risk assessment].
[Define the disposal method for each level, for example secure deletion, physical destruction].
Legal holds override disposal schedules.
[Define who authorises disposal and how it is recorded].

Exceptions

A user may request an exception to a handling rule by [define route, for example submitting a form to the information owner].
Exceptions require [define approver, for example policy owner or designated delegate].
Every exception must record: the rule being varied, the reason, the compensating control, the expiry date and the approver.
Exceptions are reviewed at [define frequency] and lapse automatically unless renewed.

Incidents

A suspected or confirmed breach of a handling rule is a security incident and must be reported to [define route, for example the security team or data-protection officer].
[Define the response steps, including containment, assessment, notification and review].
Incidents involving personal data may trigger recording or notification duties under applicable data-protection law. Follow [Organisation Name]'s personal-data-breach procedure and consult [relevant legal or compliance contact].

Training

All users receive classification training at onboarding and [define refresh frequency, for example annually].
Information owners receive additional training on classification decisions and exception handling.
Training records are retained for [define period].

Review and reclassification

This policy is reviewed [define frequency, for example annually or when a material change occurs].
Information should be reclassified when its context, purpose, duties or impact change.
[Define the reclassification trigger and route, for example contract expiry, project completion, incident discovery].
Superseded documents should be clearly marked and moved to [define archive or disposal route].

Roles, ownership and escalation

This template assigns four roles. In a small organisation, one person may hold more than one role, but the responsibilities still need to be documented and the escalation path made clear.

Policy owner sets the level model, approves exceptions and reviews the policy.
Information owners classify information within their domain and approve access requests.
Security or IT function implements technical controls and supports incident response.
Users apply labels, follow handling rules and report incidents.

In this template, escalation follows a simple path: user to information owner to policy owner. Adapt that route to your organisation, then record both the final decision and its reasoning.

Applying the policy across the information lifecycle

A classification policy only works if it is applied at each stage of the information lifecycle:

Create or receive: Assign the initial classification level based on content, context and duties.
Label: Record the level in a visible and, where possible, machine-readable way.
Store: Place the information in the repository appropriate to its level.
Access: Grant access according to role and need-to-know.
Share or transmit: Use approved channels and obtain required approvals.
Use in third-party or AI workflows: Confirm permission, minimise data, assess the provider.
Retain: Keep the information for the defined period.
Dispose: Destroy or archive using the approved method.
Review: Reclassify or confirm the level at defined intervals or on trigger events.

The NIST SP 800-53 Rev. 5 control catalogue covers attributes, marking, storage, transport, sanitisation, transit protection, retention and incident handling. It requires selection and tailoring, so use it as a coverage check, not a ready-made classification matrix. Once your rules are clear, turn classifications into handling controls with a matrix that maps each level to a specific action.

Adding third-party and AI-service rules

The third-party and AI-service clause needs five concrete decisions:

Authorisation: Who approves the use of a specific AI service or third-party processor for a given classification level?
Provider assessment: What security, privacy and contractual criteria must the provider meet?
Minimisation: What is the minimum data necessary for the task?
Document check: Is a separate pre-ingestion document-security check required before a document enters the AI workflow?
Monitoring: How will the organisation detect and respond to a provider-side incident?

These decisions should be recorded in the policy or in a linked procedure. They are organisational choices, not universal requirements. The order matters: classify the information, confirm the proposed use is permitted, minimise or redact where required, then consider any separate document-security checkpoint.

Implementing the policy in practice

Publishing the policy is only the start. Put it into practice through:

Communication: Tell people the policy exists, what it means for their daily work and where to find it.
Tooling: Make labelling and access controls easy to use. If correct handling is too cumbersome, people are more likely to work around it.
Enforcement: Define what happens when a handling rule is breached. This should be proportionate and consistent.
Measurement: Track classification coverage, exception rates, incident counts and training completion to identify gaps.
Support: Provide a clear route for people to ask what level a document should be, without fear of blame.

The NIST Cybersecurity Framework 2.0 offers useful language for inventories, metadata, least privilege and protection at rest, in transit, in use and in backups. It is a framework, not an implementation guide or security certification.

Reviewing and updating the policy

Review the policy on [define a risk-based schedule] and when relevant events occur, including:

A material change in law, regulation or contract.
A security incident that exposed a gap in handling rules.
A significant change in the organisation's information assets, technology or structure.
A change in the threat landscape that affects the proportionality of controls.

During each review, check whether:

The level model still matches the organisation's risk profile.
Handling rules work with current tools.
Exceptions remain justified or should be incorporated into the policy.
Training reflects current examples and edge cases.
People can find and understand the policy.

Frequently asked questions

Is a data classification policy required by law?

The ICO guidance cited above is risk-based and does not prescribe a specific classification-policy format or number of levels. A policy can help an organisation document its chosen measures, but applicable requirements depend on its processing, sector and contracts. Treat this template as operational guidance, not legal advice.

How many classification levels should a policy have?

Use the smallest number of levels that your people can apply consistently. A three-level scheme is simpler; adding a fourth or fifth level can express more handling differences but also increases decision and control complexity. The Cabinet Office Government Security Classifications Policy uses three national-security tiers for government; that is a different context and should not be imported as a business standard. What matters is that each level changes handling in a way people can recognise and act on.

Who owns classification decisions?

Under this template, the information owner for the relevant data domain makes the classification decision and the policy owner sets the level model and resolves disputes. The organisation may let the person who creates or first receives information make an initial classification, subject to the information owner's oversight.

How often should the policy be reviewed?

Set a risk-based review schedule and define trigger events such as a material change in applicable law, technology, organisational structure or threat. The ICO guidance cited here does not supply a universal review interval for a classification policy.

Can software classify data automatically?

Software can find content patterns, apply metadata and enforce selected rules. People still need to decide how context, permission, duties and risk appetite affect the classification. Software supports that governed decision; it does not make it for the organisation.

Where a document check fits before AI use

Classification informs the decision about whether a document may enter an AI workflow and what handling rules apply. An authorised person or process must separately confirm whether the proposed AI use is permitted.

A document-security check comes later. It examines the exact file version for reported signals such as hidden content, instruction-like text and supported sensitive-information patterns.

Where instruction-like content is part of the threat model, you can also check a document for prompt-injection signals as one bounded technical step.

.mdSiren is a document security workspace for AI. Coming soon, Standard Scan will check the exact document version, route it to Approved, Needs review or Quarantine, and keep eligible Approved versions in a private Library. This is one later document-security checkpoint: it does not classify information, authorise AI use, establish compliance or replace data-loss-prevention controls. Every result is limited to the reported checks and coverage for that exact version. Read the security and coverage limits.

Data classification policy template: a practical guide

What is a data classification policy?

Decisions to make before using the template