Data classification examples: 12 worked cases

Item or context	Likely illustrative level	Main reason	What could change the answer
Approved public annual report	Public	Approved for public release	If it contains unreleased forward-looking guidance, that section may be Internal
Blank internal process template	Internal	Routine non-public; limited harm if disclosed	If it contains client-specific fields, a completed copy may be Confidential
Completed client brief with project details	Confidential	Contract-controlled; material harm if disclosed	If the client grants written permission for wider sharing, the sharing rule changes but the level may not
CV submitted for a role	Confidential	Contains personal data; data-protection duties apply	If organisational policy permits access by a defined panel and applicable data-protection requirements are met, the permitted recipients may change while the level remains the same
Executed service contract	Confidential	Contract-controlled; commercial harm if disclosed	If the contract is published as a case study with redactions, the published version is Public
Research source pack with citations	Internal	Working material; limited harm if disclosed	If it contains unpublished findings or client data, it may be Confidential
Board paper with strategy	Restricted	Severe competitive harm; board-level sensitivity	After the strategy is publicly announced, the paper may be downgraded to Internal
System administrator credentials	Restricted	Severe operational and security harm if disclosed	If the credentials are rotated and the old ones are invalidated, the old record may be Internal
Unpatched vulnerability detail	Restricted	Severe security harm if disclosed before patching	After the patch is widely deployed, the detail may be downgraded to Internal
Aggregated customer export (12 months)	Confidential	Aggregation reveals business patterns; commercial harm	If the export is anonymised and aggregated to a level where re-identification is not feasible, it may be Internal
Anonymised dataset (effective)	Internal or Public	Depends on whether re-identification is feasible and the purpose	If the anonymisation is later shown to be ineffective, reassess both its data-protection status and organisational level
Superseded document (replaced by v2)	Internal	No longer current; limited harm	If it contains information that is still sensitive (for example, a past vulnerability), it may remain Confidential until disposal

Data classification examples at a glance

The table is the quick reference. Below, the same 12 cases are grouped by level, with five worked through step by step.

Examples by classification level

Public

• Approved public annual report: The organisation has approved this for public release. It is on the website. Integrity and version control still matter: an altered copy could mislead readers.
• Anonymised dataset (effective): If the anonymisation is genuinely effective and the dataset is approved for sharing, it may be Public. The key test is whether re-identification is feasible.

Internal

• Blank internal process template: A template with no client-specific data is routine non-public information. Limited harm if disclosed.
• Research source pack with citations: Working material that supports a project. Limited harm if disclosed, assuming it contains no unpublished findings or client data.
• Superseded document (replaced by v2): No longer current. Limited harm, unless it contains information that is still sensitive.

Confidential

• Completed client brief with project details: Contract-controlled. Material harm if disclosed to an unauthorised party.
• CV submitted for a role: Contains personal data. Privacy duty applies.
• Executed service contract: Contract-controlled. Commercial harm if disclosed.
• Aggregated customer export (12 months): Aggregation reveals patterns. Commercial harm.

Restricted

• Board paper with strategy: Severe competitive harm. Board-level sensitivity.
• System administrator credentials: Severe operational and security harm.
• Unpatched vulnerability detail: Severe security harm before patching.

First, understand the illustrative level model and its boundary tests.

Five ambiguous cases, worked step by step

For each worked case, check the information and context, applicable duties, confidentiality, integrity and availability impact, aggregation and purpose. Then record a provisional tier, owner, escalation route and review trigger.

Case 1: Completed client brief with project details

• Information and context: A project brief prepared for a client engagement. Contains the client's name, project scope, timeline, budget range and key personnel.
• Duty: Confidentiality clause in the service contract. UK GDPR applies to any personal data of named individuals.
• CIA impact: Confidentiality: material commercial harm if a competitor sees the budget and scope. Integrity: an altered brief could cause project misalignment. Availability: limited; the client has a copy.
• Aggregation and purpose: Combined with other client briefs, the aggregate could reveal the organisation's client portfolio and pricing patterns. Purpose: internal project delivery.
• Provisional tier: Confidential.
• Owner and escalation: The account owner classifies. Disputes escalate to the policy owner.
• Change trigger: If the client grants written permission for a case study, the published (redacted) version is Public. The original remains Confidential.

The review client documents before AI use workflow applies this sequence to client material.

Case 2: CV submitted for a role

• Information and context: A candidate's CV submitted through a recruitment process. Contains name, contact details, work history, education and possibly health-related information (for example, a disability disclosure).
• Duty: UK GDPR. The ICO's guide to personal information explains how identifiability and context affect whether information is personal data. If health information is present, it falls within the ICO's definition of special-category data.
• CIA impact: Confidentiality: material harm to the candidate if their application is seen by unauthorised people. Integrity: an altered CV could affect the hiring decision. Availability: limited.
• Aggregation and purpose: Combined with other CVs, the aggregate could reveal the candidate pool. Purpose: recruitment.
• Provisional tier: Confidential. If special-category data is present, the handling is stricter but the level is still determined by the organisation's boundary tests.
• Owner and escalation: The recruitment lead classifies. Follow the organisation's data-protection review route where special-category data is present.
• Change trigger: After the recruitment process ends, the CV is retained or disposed of per the retention schedule. If the candidate is hired, the CV moves to the HR file under the HR data-handling rules.

See how to scan CVs before AI screening after classification and authorisation.

Case 3: Aggregated customer export (12 months)

• Information and context: A 12-month export of customer orders, including customer names, order values, product categories and delivery addresses.
• Duty: UK GDPR (personal data). Contractual confidentiality if the export is shared with a third party.
• CIA impact: Confidentiality: commercial harm if a competitor sees the customer base and revenue patterns. Integrity: an altered export could mislead business decisions. Availability: limited.
• Aggregation and purpose: The NCSC principles for protecting sensitive datasets explain why aggregation and concentration can change risk. Here, the export reveals business patterns not visible in individual orders. Purpose: internal business analysis.
• Provisional tier: Confidential. The aggregation raises the level above what individual orders would warrant.
• Owner and escalation: The data owner for the customer database classifies. The policy owner is consulted if the export is to be shared externally.
• Change trigger: If the export is anonymised to a level where re-identification is not feasible, it may be downgraded to Internal. If a specific customer's data is removed, the remaining export may still be Confidential.

Case 4: Unpatched vulnerability detail

• Information and context: A detailed description of a vulnerability in a system the organisation operates, including the affected component, the attack vector and the potential impact. The vulnerability is not yet patched.
• Duty: Assume the organisation has contractual security obligations to the system's users and recognises a professional duty to manage the vulnerability responsibly. Sector-specific security or notification duties may also apply, depending on the system and data involved.
• CIA impact: Confidentiality: severe security harm if an attacker sees the detail before the patch. Integrity: the system's security posture is compromised. Availability: potential for service disruption if exploited.
• Aggregation and purpose: Combined with other vulnerability details, the aggregate could reveal the organisation's security posture. Purpose: internal remediation.
• Provisional tier: Restricted.
• Owner and escalation: The security team classifies. The CISO or equivalent is the escalation point.
• Change trigger: After the patch is widely deployed and the vulnerability is no longer exploitable, the detail may be downgraded to Internal. The change should be recorded with the patch deployment date.

Case 5: Anonymised dataset (effective)

• Information and context: A dataset derived from customer transaction data, with direct identifiers removed and quasi-identifiers generalised. The organisation has assessed that re-identification is not feasible with currently available methods.
• Duty: UK GDPR still applies if re-identification is feasible. If the anonymisation is effective, the data is no longer personal data.
• CIA impact: Confidentiality: limited if the data is genuinely anonymised. Integrity: an altered dataset could mislead analysis. Availability: limited.
• Aggregation and purpose: The dataset is intended for research or benchmarking. Purpose: analysis.
• Provisional tier: Internal, or Public if approved for external sharing.
• Owner and escalation: The data owner classifies. An appropriately qualified privacy or data-protection role reviews the anonymisation assessment under the organisation's governance model.
• Change trigger: Reassess on the organisation's defined schedule and when data, access, linkage sources or re-identification techniques materially change. If re-identification becomes feasible, review both the data-protection status and the organisational level rather than assuming an automatic tier.

When the same information changes classification

A classification is not necessarily permanent. Changes in context should trigger reassessment; the review may confirm the existing level or produce a recorded reclassification:

• Time: A public announcement may trigger review of a previously Restricted board paper.
• Purpose: A changed purpose may alter the duties, context or likely harm.
• Aggregation: Combining individually lower-level items may warrant tighter handling for the aggregate.
• Incident: A security incident may expose information or risk that was not considered in the earlier decision.
• Legal change: A new or amended legal requirement may change the applicable duties.
• Contract change: A new or amended contract may add or remove confidentiality obligations.

The Cabinet Office Working at OFFICIAL guidance emphasises that the creator assesses context and that need-to-know is balanced with need-to-share. The same principle applies: the classification should reflect the current context, not the context at the time of creation.

How to classify mixed documents and collections

A document may contain information at multiple levels. A board paper may contain a Public section (a summary of published results) and a Restricted section (unreleased strategy). A database may contain Internal records and Confidential records.

Follow the organisation's written policy and record the reasoning. One conservative set of options is:

• Single document, multiple levels: Apply the highest level to the whole document, split the content, or escalate the decision, according to local policy.
• Collection or database: Classify at the granularity the system can govern. Where items are not logically separated, a policy may apply controls capable of protecting the highest level present.
• Derived data: Reassess the output itself. A report derived from Confidential data may qualify for a different level if it no longer exposes the same information or risk, but that change must be justified rather than assumed.

To assess whether information is sensitive, check its content, context, duties and likely harm.

How to adapt these examples to your policy

These examples use the illustrative four-level model. Your organisation may use a different number of levels or different names. The reasoning path is the same:

1. Identify the information and its context.
2. Identify applicable duties.
3. Consider CIA impact.
4. Consider aggregation, purpose and recipients.
5. Choose the organisation's tier.
6. Apply the linked handling controls.
7. Record ambiguity, owner approval or reclassification.

Once the level is set, look up the corresponding handling controls.

Classification examples before AI-assisted use

When a document from the examples above is proposed for use in an AI workflow, three distinct decisions or checks are needed:

1. Classification: Determine the document's level under the organisation's policy.
2. Authorisation: An authorised person or process confirms whether the proposed AI use is permitted for that level and context.
3. Document-security check: A separate, later step examines the exact document version for reported signals before it is shared with an AI service. This is a technical check, not a classification or authorisation decision.

Keep the decisions separate. A properly classified and permitted document can still contain a reported signal that needs review. Likewise, no reported signal is not permission to use the document with AI; classification and authorisation still apply.

Frequently asked questions

What is an example of Public data?

An approved public annual report, a marketing brochure, a press release or content on your public website. The key test is that the organisation has approved it for public release.

Are CVs always Confidential?

In the worked example, the CV is Confidential because of its content, context and the organisation's illustrative boundary tests. That is not a universal mapping: another organisation must apply its own policy and duties. Permission to share a CV with a particular panel changes the permitted recipients; it does not by itself decide the organisational tier.

How do you classify a document containing mixed data?

Follow the rule defined in your policy. A conservative option is to apply controls capable of protecting the highest level present; alternatives include splitting the document or escalating the decision. Whichever route you use, record it consistently.

Can anonymised data be Public?

If the anonymisation is genuinely effective (re-identification is not feasible) and the data is approved for public release, yes. If anonymisation is later shown to be ineffective, treat the information as personal data and reassess its organisational level.

Who resolves an ambiguous case?

Under the illustrative governance model, the information owner decides and the policy owner resolves a dispute. Your own route may differ; name it in the policy and record both the decision and its reasoning.

A note on document security before AI use

After classification and authorisation, you may want to check the exact file before sharing it with an AI service. .mdSiren is a document security workspace for AI. Coming soon, Standard Scan will check that exact version, route it to Approved, Needs review or Quarantine, and keep eligible Approved versions in a private Library. The result does not choose the example's tier, authorise the proposed use or replace handling controls, and it remains limited to the reported checks and coverage.