| Category | What defines it | Why the distinction matters |
|---|---|---|
| Organisationally sensitive information | Organisation-defined; context, duties and likely harm | May extend beyond named legal categories; the organisation decides what warrants tighter handling |
| Personal data | Relates to an identified or identifiable living person (UK GDPR) | Triggers data-protection duties; not all personal data is special-category |
| Special-category data | Defined subset of personal data under UK GDPR | Higher protection; specific conditions for processing; not the same as "sensitive" in everyday use |
| Criminal-offence data | Data concerning offences and related proceedings | Separate regime; can include allegations and investigations, not only convictions |
| Confidential or contract-controlled business information | Contract, duty of confidence, professional duty or organisational policy | Not a UK GDPR personal-data category; obligations may arise from the relationship, context or policy as well as the content |
What is sensitive data classification?
Sensitive data classification is the process of identifying information that warrants tighter handling and recording that decision as part of the organisation's classification system. It answers: what makes this information sensitive, and what handling follows?
The word "sensitive" is used in at least three different ways in practice:
- Everyday security language: "This is sensitive, so do not share it." This is the broadest use and covers anything the organisation has decided needs tighter handling.
- UK GDPR special-category data: A defined legal subset of personal data with specific processing conditions. This is narrower than everyday "sensitive."
- NCSC "sensitive personal information": A term used in security guidance that is not formally defined and is not synonymous with UK GDPR special-category data.
Keeping these uses separate prevents confusion. A document containing a customer's bank account number may be sensitive in everyday language and may contain personal data, but that information is not special-category data solely because it is financial. A document containing health information may contain special-category personal data and may also be sensitive in everyday language. The legal category and the organisational tier answer different questions.
Sensitive data, personal data and special category data are not the same
The ICO's guide to personal information explains that personal data relates to an identified or identifiable living person. Identification may depend on combining information, and pseudonymised data remains personal data where re-identification remains possible.
The ICO's special-category data guidance lists the defined UK GDPR categories: racial or ethnic origin, political opinions, religious or philosophical beliefs, trade-union membership, genetic data, biometric data used for identification, health, sex life and sexual orientation. Financial information may be sensitive in everyday language without being special-category data.
Criminal-offence data is protected separately and can include allegations, investigations and proceedings, not only convictions. A separate regime and context can apply.
All three ICO pages are under review following the Data (Use and Access) Act and should be rechecked before publication.
The practical implication is that your classification policy should record the legal or contractual trigger separately from the organisation's handling tier. A document may contain special-category personal data while carrying a Confidential organisational classification. The legal assessment and organisational classification are separate decisions made for different reasons.
Record the legal assessment and organisational classification separately, including the basis, responsible role and review point for each. You can then revisit the organisational tier without accidentally rewriting the underlying legal status, or update the legal assessment without treating the handling level as automatic.
Illustrative organisation-defined categories of sensitive business information
Organisations can also identify sensitive business information under their own policies or contracts. The three groups below are illustrative, not exhaustive, and do not map automatically to one tier:
- Access credentials or security material: Passwords, API keys, encryption keys, vulnerability details, security architecture documentation.
- Contract-controlled client material: Information shared under a confidentiality agreement, client project data, client personal data processed on behalf of a client.
- Unpublished internal financial or operational plans: Draft budgets, pricing strategy, merger or acquisition details, board papers before distribution.
The applicable organisational, legal or contractual reason should be recorded instead of being blurred into a generic tier name. The same type of information may be Internal in one context and Restricted in another, depending on the contract, the timing and the likely harm.
How to decide whether information is sensitive
A practical decision process:
- Identify the content. What does the information contain? Personal data, financial data, security material, client information?
- Identify the context. Who created it, for what purpose, in what relationship? A blank template is different from a completed copy.
- Identify the duties. Are there legal, contractual or professional obligations that apply?
- Consider aggregation. Does combining this information with other information increase the risk?
- Assess likely harm. If this information were disclosed, altered or lost, what would the worst realistic outcome be?
- Record the decision. Note the level, the reason, the owner and the review date.
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.
When sensitive data may be Confidential or Restricted
Sensitivity is an input to the classification decision, not the decision itself. The same type of sensitive information may land at different levels depending on context:
- A staff directory with names and roles may be Internal, even though it contains personal data.
- Employee health records may contain special-category personal data and may be Confidential or Restricted under an organisation's locally defined scheme.
- A client contract might be Confidential under the illustrative scheme, depending on its terms and context.
- An unpatched vulnerability detail might be Restricted where disclosure could create severe security harm.
- A published annual report is Public, even though it contains some financial data.
Apply your organisation's boundary tests to the likely harm, applicable duties and context. The full guide explains how to apply your organisation's classification levels.
How context, aggregation and derived data change the decision
The NCSC's principles for protecting sensitive personal information in datasets stress that risk can arise through inference, aggregation and the concentration of data. NCSC explicitly notes that "sensitive personal information" is not formally defined and is not synonymous with UK GDPR special-category data.
Practical examples:
- Aggregation: Individual customer orders may be Internal. A combined export of all customer orders for a year may be Confidential because the aggregate reveals business patterns.
- Inference: A dataset that does not contain a health condition may allow inference of one when combined with other data. The derived dataset may warrant tighter handling than the source.
- Purpose change: Data collected for one purpose may become more sensitive if used for a different purpose. Employee performance data collected for development may become more sensitive if used for a redundancy decision.
- Recipients: Changing the recipient does not automatically change the classification. It should trigger a review of the proposed sharing, applicable duties and controls; the level changes only where the context, duties or likely harm justify it.
These examples are fictional illustrations. The actual decision depends on your organisation's context, duties and risk appetite.
Handling sensitive data through its lifecycle
Once information is identified as sensitive, handling rules should apply across its lifecycle:
- Create or receive: Assign the classification level and record the reason.
- Label: Apply a visible and, where possible, machine-readable label.
- Store: Place in the repository appropriate to the level, with required protections.
- Access: Restrict to those with a need, following the principle of least privilege.
- Share or transmit: Use approved channels; obtain required approvals.
- Use in AI workflows: Confirm permission, minimise data, assess the provider.
- Retain: Keep for the defined period.
- Dispose: Destroy or archive using the approved method.
Use the matrix to map sensitive classifications to controls.
For step-by-step reasoning, see ambiguous classification examples.
Sensitive documents in AI-assisted workflows
When a sensitive document is proposed for use in an AI workflow, the order of decisions matters:
- Classify: Confirm the document's level under the organisation's policy.
- Authorise: Confirm that the proposed AI use is permitted for that level.
- Minimise: Redact or remove data that is not needed for the task.
- Assess the provider: Check the provider's security posture, data-processing terms and jurisdiction.
- Document check: Consider a separate pre-ingestion check for reported signals in the exact document version.
A supported sensitive-information match from a document check is a prompt for review. It reports that a pattern was detected, not the document's classification, legal status or permission for AI use.
The review client documents before AI use workflow shows this sequence in a client-confidentiality context.
Check the supported sensitive-information checks for current scope and limitations.
Frequently asked questions
What is sensitive data?
In everyday security practice, sensitive data is information that warrants tighter handling because misuse, disclosure, alteration or loss could cause harm or breach a duty. It is broader than UK GDPR special-category data and is not a fixed legal category. The organisation defines what is sensitive under its policy.
Is all personal data sensitive?
"Sensitive" can mean different things. All personal data remains within the relevant data-protection regime, but not all personal data is UK GDPR special-category data. An organisation's handling tier is a separate decision based on context, duties and likely harm.
Is financial data special-category data?
No. Financial data is not in the UK GDPR special-category list. It may be sensitive in everyday language and may be personal data, but it is not special-category data. The special-category list is specific: 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.
How should aggregated data be classified?
Aggregation can increase risk. A combined dataset may warrant a higher level than its individual components. The decision should consider the aggregate's content, the inference risk, the purpose and the likely harm. There is no universal rule; the organisation's boundary tests apply.
Can software decide whether data is sensitive?
Software can detect content patterns and flag them for review, but the classification decision requires context, duties and risk appetite, which are governed organisational decisions. Automation is decision support, not a replacement for the authority to classify.
A note on document security before AI use
Once your organisation has classified a document and authorised the proposed AI use, you may want to check the exact version that will be shared. .mdSiren is a document security workspace for AI. Coming soon, Standard Scan will route that exact version to Approved, Needs review or Quarantine and keep eligible Approved versions in a private Library. A supported sensitive-information match is a prompt for review, not an authoritative classification or legal conclusion. The workspace does not assign a level, authorise AI use or replace handling controls, and every result is limited to the reported checks and coverage.
