What is a data classification matrix?
A classification matrix has two parts:
- Decision matrix: A compact table that helps you choose the right level based on likely harm, duties, aggregation and purpose.
- Handling matrix: A table with lifecycle actions as rows and classification levels as columns, specifying the controls that apply at each intersection.
The decision matrix helps people choose a level; the handling matrix turns that choice into repeatable actions.
The Cabinet Office security-adviser guidance covers governance and controls across personnel, storage, remote working, movement, data at rest and in transit, collaboration and removable media. It also notes that aggregated information can be more valuable than individual items. The guidance is for government security advisers and requires local tailoring; it is not a ready-made business matrix.
Decision matrix versus handling matrix
The decision matrix helps you answer: "What level should this information be?" It considers:
- Likely harm if disclosed, altered or lost.
- Applicable legal, contractual or professional duties.
- Aggregation risk: does combining this with other information increase the risk?
- Purpose and recipients: who needs it, and who must not see it?
The handling matrix helps you answer: "What do we do with information at this level?" It specifies:
- Access rules.
- Storage requirements.
- Sharing and transmission rules.
- Third-party and AI-use controls.
- Retention and disposal.
- Incident and escalation.
- Reclassification triggers.
The decision matrix supports each classification or reclassification decision. The handling matrix is a maintained reference for the people and systems that apply the resulting controls.
Copy-ready data classification matrix
Use this matrix as a starting point and replace or adapt every entry to your organisation's context, tooling, duties and risk appetite. It is practical guidance, not an official NIST template or universal standard.
Decision matrix
| Factor | Public | Internal | Confidential | Restricted |
|---|---|---|---|---|
| Likely harm if disclosed | None or negligible | Limited | Material | Severe |
| Applicable duties | No identified duty prevents approved publication | Record relevant internal, contractual, legal or professional duties | Record duties that constrain access or sharing | Record duties and consequences that justify the strictest local controls |
| Aggregation risk | No material increase identified | Reassess when combined with related information | Aggregation may increase impact or reveal patterns | Define concentration or inference as a review trigger where the organisation's policy requires it |
| Purpose and recipients | Public; any recipient | Organisation; defined internal group | Named individuals or small group | Named individuals with demonstrated need |
Handling matrix
| Lifecycle action | Public | Internal | Confidential | Restricted |
|---|---|---|---|---|
| Create and label | Label as Public; record approval for release | Label as Internal; record creator | Label as Confidential; record owner and reason | Label as Restricted; record owner, reason and named recipients |
| Access | No confidentiality restriction after release approval; preserve the approved version | [Define internal access rule] | [Define roles and approval route] | [Define named access, need and approver] |
| Storage | [Approved public repository and integrity controls] | [Approved internal repository and access control] | [Required repository, encryption and logging] | [Strictest local storage and monitoring controls] |
| Sharing and transmission | Approved public channels; preserve provenance and version | [Approved internal channels and external-sharing rule] | [Approved channels, protection and recipient checks] | [Strictest channels, named recipients and onward-sharing rule] |
| Third parties and AI use | Use only an approved service and permitted content; assess terms and minimise where relevant | [Authorisation rule], [provider criteria], [minimum-data rule], [document-check decision] | [Approver], [provider criteria], [minimum-data rule], [document-check decision] | [Strictest approver, provider, minimisation and checkpoint decisions] |
| Retention and disposal | [Publication and archive schedule] | [Business, legal and contractual schedule; disposal method] | [Applicable schedule, disposal method and record] | [Applicable schedule, authorised disposal method and record] |
| Incident and escalation | Follow [public-content incident route] | Follow [internal incident route] | Follow [security route]; consult privacy or legal advisers where duties may apply | Follow [urgent containment and escalation route]; assess applicable notification duties |
| Reclassification | Review on [content-change or republication triggers] | Review at [defined interval] and on [events] | Review at [defined interval] and on [duty, contract or context changes] | Review on [defined high-impact triggers]; require [approver] for downgrade |
Before using the matrix, define the levels before filling the matrix.
Then place the matrix inside your policy so people can find the rules and their owners.
For worked examples, see how the controls apply to real documents.
How to set access, storage and sharing controls
The access, storage and sharing rows convert level definitions into day-to-day behaviour. A few principles:
- Least privilege: Users receive access only to the levels and specific assets their role requires. A marketing team does not need access to Restricted security documentation.
- Proportionality: The controls should be proportionate to the level and the organisation's risk appetite. Encryption may add little confidentiality value to an approved public brochure; higher-risk information needs controls selected for its threat model.
- Achievability: If a control is too hard to implement, it is more likely to be bypassed. Choose controls that your people can follow without excessive friction.
- Implementation: A policy statement alone does not demonstrate that a technical or procedural control has been implemented. Define how each control operates and how its effectiveness will be checked.
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. The guide does not prescribe a tier scheme or provide legal advice, and it is under review.
Retention, disposal and reclassification
Retention and disposal need explicit decisions in a classification matrix. A few points:
- Retention periods are not universal. They depend on legal obligation, contract, business need and risk. The matrix should reference the source of the period, not invent one.
- Disposal must be secure. A Confidential document that is "deleted" from a shared drive while recoverable copies remain may not meet the organisation's secure-disposal requirement. The disposal method should match the level and the applicable policy.
- Applicable holds can pause disposal. Where an applicable legal or regulatory hold exists, pause scheduled disposal and follow the organisation's legal- or counsel-approved process.
- Reclassification is a decision, not an automatic event. A document does not automatically become Internal after a project ends. Someone must review it and record the change.
The NCSC's principles for protecting sensitive personal information in datasets stress that access and monitoring matter, and that inference, aggregation and concentration can change risk. The NCSC notes that "sensitive personal information" is not formally defined.
Adding third-party and AI-use controls
The third-party and AI-use row should answer five questions:
- Authorisation: Who approves the use of a specific AI service or third-party processor for a given 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?
- Monitoring: How will the organisation detect and respond to a provider-side incident?
The order matters: classification and permission precede any scan. The organisation first decides whether the document may enter the AI workflow at all. Only then is a document-security checkpoint relevant.
After authorisation and minimisation, see the document review workflow for the later document-security checkpoint.
To understand security and scope, check the document-security limitations before relying on a result.
Ownership, exceptions and escalation
Every row in the matrix needs an owner. One workable model is:
- Policy owner: Owns the matrix, approves changes and resolves disputes.
- Information owners: Own the classification decisions within their domain and approve access requests.
- Security or IT function: Implements technical controls and supports incident response.
- Users: Follow the handling rules and report incidents.
One practical exception record can include:
- A written request stating the rule being varied and the reason.
- Approval from the policy owner or a designated delegate.
- A compensating control that addresses the risk created by the exception.
- An expiry date.
- An audit record.
Set a local review trigger or interval and an expiry or renewal rule for approved exceptions.
Testing and maintaining the matrix
Test the matrix periodically to confirm it still works in practice. Include:
- Access review: Are the right people accessing the right levels?
- Control verification: Are the technical controls actually in place and functioning?
- Exception review: Should an exception be renewed for a defined period, closed, or incorporated into a revised policy or control?
- Incident review: Did any incident expose a gap in the matrix?
- Change review: Have there been changes in law, technology, structure or threat that require matrix updates?
Use these references as completeness and implementation checks:
- 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; it is not a ready-made classification matrix.
- The NIST Cybersecurity Framework 2.0 includes outcomes for inventories and metadata, least privilege, and protection at rest, in transit, in use and in backups. These are outcomes, not implementation instructions or a security certification.
- CISA's Zero Trust Maturity Model Version 2.0 is a US-federal maturity model. Its Data pillar can help describe current and target implementation states, but it is not a classification matrix and does not prove that a control is enforced.
- Microsoft Purview sensitivity-label documentation shows one product-specific implementation in which file or email metadata can trigger encryption, marking, permission or sharing controls. It also explains that a label need not apply protection. The mechanics depend on the product, licence and feature set.
Frequently asked questions
What should a data classification matrix include?
A decision matrix (to help choose the right level) and a handling matrix (to specify controls at each level and lifecycle stage). The handling matrix should cover: create and label, access, storage, sharing and transmission, third parties and AI use, retention and disposal, incident and escalation, and reclassification. Each cell should name the action, the owner and the exception path.
Is a matrix the same as a policy?
No. A policy defines the levels, principles and governance. A matrix maps those levels to controls and can sit within the policy or as a linked document.
Who owns each matrix row?
Assign an accountable owner for the matrix and, where useful, functional owners for individual rows. For example, IT may own storage controls, security may own incident controls, and a data-protection role may advise on retention where personal data is involved. Record the allocation in the matrix or a linked register rather than assuming these example roles fit every organisation.
Can controls be automated from labels?
In some product implementations, a label can trigger technical controls such as encryption or access restriction. A label need not apply protection, so configure the control separately and verify that it works.
How often should a matrix be reviewed?
Choose a risk-based review interval and define trigger events such as a material change in applicable law, technology, organisational structure, threat or control capability. Version the matrix, and record changes with a reason and an approver.
A note on document security before AI use
After classification and authorisation for the proposed AI use, you may want to check the exact file before sharing it with AI. .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. The result does not enforce the matrix, classify data, authorise AI use or replace data-loss-prevention controls, and it remains limited to the reported checks and coverage.
