Data Classification: What It Is, Levels, Frameworks, and How to Implement It
Data classification is the process of categorising data based on its sensitivity, value, and regulatory requirements to determine the appropriate level of protection. It is a foundational information security practice that enables organisations to apply the right security controls to the right data.
For B2B companies, data classification is both a compliance requirement and a trust signal. ISO 27001, SOC 2, GDPR, NIS2, and DORA all require organisations to identify, classify, and appropriately protect their information assets. Enterprise buyers expect vendors to demonstrate a clear classification scheme and consistent data handling practices.
This guide covers what data classification is, standard classification levels, how to implement a classification scheme, regulatory requirements, and how classification supports broader security and compliance objectives.
Classification Levels
Standard Four-Level Scheme
| Level | Description | Examples | Handling Requirements |
|---|
| Public | Information intended for public consumption | Marketing materials, blog posts, press releases | Integrity controls only; no confidentiality requirements |
| Internal | Information for internal use, not for public disclosure | Internal policies, org charts, meeting notes | Authenticated access, basic encryption in transit |
| Confidential | Sensitive information that could cause significant harm if exposed | Customer data, financial records, source code, contracts | Need-to-know access, encryption at rest and in transit, audit logging |
| Restricted | The most sensitive information requiring the highest protection | Encryption keys, credentials, regulated PII, trade secrets | MFA, full audit trails, encrypted storage, strict handling procedures |
Classification Decision Criteria
| Criterion | Question to Ask |
|---|
| Confidentiality impact | What harm would result if this data were disclosed to unauthorised parties? |
| Integrity impact | What harm would result if this data were modified without authorisation? |
| Availability impact | What harm would result if this data were unavailable? |
| Regulatory requirements | Is this data subject to specific regulatory protections (GDPR, DORA, NIS2)? |
| Contractual obligations | Do customer contracts impose specific handling requirements? |
| Business value | How critical is this data to business operations and competitive advantage? |
Data Types and Classification
Common Data Categories
| Data Type | Typical Classification | Regulatory Context |
|---|
| Personal data (standard) | Confidential | GDPR Article 6 |
| Special category personal data | Restricted | GDPR Article 9 |
| Financial records | Confidential | DORA, SOX, local regulations |
| Customer contracts | Confidential | Contractual obligations |
| Source code | Confidential | IP protection |
| Encryption keys and credentials | Restricted | ISO 27001 A.8.24 |
| Audit logs | Confidential | ISO 27001, SOC 2, DORA |
| Marketing materials | Public | N/A |
| Internal policies | Internal | ISO 27001 document control |
| Incident reports | Confidential | NIS2 Art. 23, DORA Art. 19 |
| Risk assessments | Confidential | ISO 27001, NIS2, DORA |
| Employee HR data | Confidential/Restricted | GDPR, local employment law |
Security Controls by Classification Level
Control Matrix
| Control | Public | Internal | Confidential | Restricted |
|---|
| Access control | None | Authenticated users | Need-to-know, role-based | Need-to-know, MFA required |
| Encryption in transit | Optional (HTTPS) | Required (TLS) | Required (TLS 1.2+) | Required (TLS 1.3, mutual TLS) |
| Encryption at rest | Not required | Recommended | Required (AES-256) | Required (AES-256, HSM key management) |
| Audit logging | Not required | Basic access logging | Full access and modification logging | Full logging with tamper protection |
| Data loss prevention | Not required | Monitoring | Active blocking | Active blocking with alerts |
| Backup | Standard | Standard | Encrypted backups | Encrypted backups, separate key management |
| Disposal | Standard deletion | Secure deletion | Certified destruction | Certified destruction with witness |
| Sharing | Unrestricted | Internal only | Approved recipients with NDA | Named individuals with explicit approval |
Implementing Data Classification
Step-by-Step Approach
- Define the classification scheme — Establish clear classification levels with definitions, examples, and handling requirements
- Create a data inventory — Identify all data assets across systems, databases, file stores, and SaaS applications
- Classify existing data — Assign classification levels to all identified data assets based on the defined criteria
- Implement labelling — Apply classification labels through metadata, visual markings, and system configurations
- Define handling procedures — Document how each classification level should be created, stored, transmitted, shared, and disposed of
- Configure controls — Implement technical controls (access control, encryption, DLP) aligned to classification levels
- Train employees — Ensure all staff understand the classification scheme and their responsibilities
- Monitor and review — Regularly review classifications, monitor compliance, and update as needed
Data Labelling Methods
| Method | Application | Automation |
|---|
| Metadata tagging | Document properties, file metadata | Semi-automated (DLP tools, document management systems) |
| Visual marking | Headers, footers, watermarks on documents | Automated (templates, document management) |
| Email headers | Classification labels in email headers or subject lines | Automated (email security tools) |
| Database schemas | Classification columns in database tables | Manual or automated (data catalogues) |
| DLP content analysis | Automatic classification based on content patterns | Automated (DLP, AI-based classification) |
| API response headers | Classification metadata in API responses | Automated (API gateway configuration) |
Compliance Requirements
Regulatory Mapping
| Framework | Requirement | Data Classification Alignment |
|---|
| ISO 27001 | A.5.12 | Classification of information based on security needs |
| ISO 27001 | A.5.13 | Labelling of information according to classification |
| ISO 27001 | A.5.10 | Acceptable use rules based on classification |
| ISO 27001 | A.5.14 | Secure transfer based on classification |
| SOC 2 | CC6.1 | Logical access controls based on data sensitivity |
| SOC 2 | CC6.7 | Restriction of data based on classification |
| GDPR | Art. 5, 9, 32 | Data protection proportional to sensitivity |
| NIS2 | Art. 21(2)(d) | Supply chain security including data classification |
| DORA | Art. 9 | Classification of ICT assets and information |
Audit Evidence
| Evidence | Description |
|---|
| Classification policy | Documented policy defining classification levels, criteria, and handling requirements |
| Data inventory | Register of data assets with assigned classification levels |
| Labelling procedures | Documentation of how data is labelled and marked |
| Handling procedures | Documented procedures for each classification level |
| Training records | Evidence that employees are trained on the classification scheme |
| Access controls | Configuration evidence showing access controls aligned to classification |
| DLP configuration | Data loss prevention rules configured by classification level |
| Review records | Evidence of periodic classification reviews and updates |
Common Mistakes
| Mistake | Consequence | Better Approach |
|---|
| Too many levels | Confusion, inconsistent application | Start with 3-4 levels; add granularity only when needed |
| No data inventory | Cannot classify what you don't know about | Complete data inventory before classifying |
| Classification without controls | Labels exist but protection doesn't follow | Map controls to each classification level |
| One-time exercise | Classification becomes outdated quickly | Integrate into data governance processes |
| Over-classification | Everything marked Confidential; controls lose meaning | Apply classification based on actual risk |
| No training | Employees don't understand the scheme | Include classification in security awareness training |
| Ignoring unstructured data | Files, emails, and documents unclassified | Include all data types in the classification programme |
How Orbiq Supports Data Classification
- Trust Center: Publish your data classification posture — classification scheme, handling procedures, and protection measures for buyer self-service
- Continuous Monitoring: Track data classification compliance across ISO 27001, SOC 2, GDPR, and DORA requirements
- AI-Powered Questionnaires: Auto-respond to data classification and handling questions from enterprise buyers
- Evidence Management: Centralise classification policies, data inventories, and handling procedures for auditors
Further Reading
This guide is maintained by the Orbiq team. Last updated: March 2026.