What is a data classification policy and why does it matter?
A data classification policy defines how your company categorises information based on its sensitivity, regulatory status, and the potential harm from unauthorised disclosure. It answers: what data do we have, how sensitive is it, and what protections does it require?
It's foundational — because without knowing what data is sensitive, you can't consistently encrypt the right things, restrict the right access, apply the right retention rules, or respond appropriately to a breach. Most compliance frameworks require it explicitly:
- ISO 27001:2022 Annex A.5.12 (Classification of information), A.5.13 (Labelling), A.8.2 (Classification)
- SOC 2 CC9.1 (data classification in vendor contracts), C1.1–C1.2 (confidentiality commitments and disposal)
- GDPR/UK GDPR Art. 5(1)(f) integrity and confidentiality principle, Art. 25 data protection by design, Art. 32 TOMs
- HIPAA §164.310(d) media controls, §164.312(a) access control (classification drives access decisions)
- PCI DSS Req 3 (stored cardholder data = highest classification), Req 9.8 (media disposal)
For enterprise sales, data classification is also a procurement requirement. Enterprise buyers ask: "How do you classify our data?" and "What protections apply to our most sensitive data?" Having no answer — or a vague one — stalls deals.
Choosing your classification tier structure
Most SaaS companies use 3 or 4 classification tiers. More tiers add precision but increase complexity and training burden. The right choice depends on your business:
| Tiers | Structure | Best For |
|---|---|---|
| 3 | Public / Internal / Confidential | Simple B2B SaaS, early-stage, no PHI or PCI data |
| 4 | Public / Internal / Confidential / Restricted | Most B2B SaaS — separates customer PII from regulated data (PHI, PCI) |
| 4 | Public / Internal / Sensitive / Highly Confidential | Enterprise SaaS with government or financial clients |
| 4 (ISO-aligned) | Public / Internal / Confidential / Secret | ISO 27001 certification path; aligns with A.5.12 terminology |
The 4-tier Public / Internal / Confidential / Restricted model is the most commonly used in B2B SaaS because it cleanly separates: freely shareable data, internal-only operational data, customer and employee personal data, and regulated or highest-sensitivity data (credentials, PHI, CHD, M&A).
What goes in each tier
Public
Information that can be shared with anyone without restriction or approval. Examples:
- Marketing materials, website content, product documentation
- Press releases, published blog posts, open-source code
- Job postings, public API documentation
Public data requires no special protection controls — but it should still be intentionally classified as Public, not just assumed to be. Employees sometimes share Internal data publicly because they didn't know it required protection.
Internal
Information for internal use only. Disclosure to unauthorised parties could cause minor reputational or operational harm. Examples:
- Internal memos, meeting notes, general HR policies
- Non-sensitive project documentation, operational procedures
- Internal Slack messages and non-sensitive email
Confidential
Sensitive business information. Unauthorised disclosure could cause significant harm — financial loss, regulatory risk, loss of customer trust. Examples:
- Customer personal data (names, emails, usage data) — GDPR-regulated
- Employee personal data, HR records, payroll
- Financial reports, forecasts, investor information
- Product roadmap, unreleased source code, competitive strategy
- Customer contracts, pricing, SLAs
- Security assessment reports (findings and remediation status)
Restricted (or Highly Confidential)
Highest-sensitivity data. Unauthorised disclosure could cause severe harm — regulatory fines, legal liability, safety risk, or competitive catastrophe. Examples:
- Authentication credentials: passwords, API keys, private keys, tokens
- Special category personal data (GDPR Art. 9): health, biometric, race, religion, trade union membership, sexual orientation
- Payment card data (CHD) — PCI DSS-regulated
- HIPAA PHI / ePHI — health records
- M&A information, board strategy, undisclosed financials
- Security vulnerability details for unpatched systems
- Children's personal data (COPPA / GDPR Art. 8)
GDPR special category data always = Restricted
This is non-negotiable. GDPR Art. 9 special category data — health, biometric, genetic, racial/ethnic origin, political opinions, religious beliefs, trade union membership, sex life/orientation — requires elevated protection:
- Explicit consent or another Art. 9(2) condition required (not just any lawful basis)
- DPIA mandatory for large-scale processing
- Enhanced encryption, access controls, and pseudonymisation
- Separate handling from standard personal data
Many SaaS companies process special category data without realising it: HR analytics platforms may infer health conditions; DEI tools process racial/ethnic data; wellbeing apps explicitly collect mental health data. If you process it, it's Restricted class — minimum.
Data handling standards by classification tier
| Scenario | Public | Internal | Confidential | Restricted |
|---|---|---|---|---|
| Email (internal) | ✅ No restrictions | ✅ Standard email | ⚠️ Encrypt sensitive attachments | ❌ Encrypted channel or secure file transfer only |
| Email (external) | ✅ No restrictions | ⚠️ Confirm recipient | ⚠️ Confirm recipient, encrypt attachments | ❌ Approval required + encryption mandatory |
| Cloud file storage | ✅ Any approved tool | ✅ Company tools only | ⚠️ Company tools only, no public sharing | ❌ Restricted platforms, access-controlled, no sync to personal devices |
| Code repositories | ✅ Public OK | ✅ Private repo | ⚠️ Private repo, no hardcoded data | ❌ No committed secrets; secrets manager only |
| Screen sharing / video calls | ✅ No restrictions | ✅ Standard caution | ⚠️ Confirm no unauthorised attendees | ❌ Only in secured, dedicated meetings |
| Printing | ✅ No restrictions | ⚠️ Standard disposal | ⚠️ Secure disposal, clean desk | ❌ Avoid printing; if necessary, cross-cut shred immediately after use |
Storage controls that matter
The most common data handling failures in SaaS companies:
- Production data in dev/test environments: Confidential and Restricted data must be masked or anonymised before use in non-production systems. Engineers running queries against live customer data "just to debug" is a GDPR violation.
- Credentials in source code: API keys, database passwords, private keys committed to GitHub (especially public repos) — this is the most common form of accidental Restricted data exposure. Use a secrets manager (HashiCorp Vault, AWS Secrets Manager, Doppler) and add secret scanning to your CI/CD pipeline.
- Personal cloud storage: Employees uploading company files to personal Google Drive or Dropbox. Your classification policy should explicitly prohibit Confidential and Restricted data on non-approved platforms.
- Customer data outside agreed geographic regions: GDPR requires that customer personal data (Confidential class) stays within contractually agreed regions. AWS us-east-1 for an EU customer without their knowledge is a breach.
Labelling approaches: pragmatic for SaaS
ISO 27001 A.5.13 requires labelling of information assets. The pragmatic approaches for a small SaaS team:
- Document headers/footers: "CONFIDENTIAL — [Company] Internal Use Only" in headers of sensitive documents. Works with Google Docs, Word, PDF.
- File naming convention: Prefix files with classification tag: [CONFIDENTIAL] Q1 Board Pack.pdf, [RESTRICTED] AWS Root Credentials.txt (ideally the latter doesn't exist as a file at all).
- Tooling (if budget allows): Microsoft Purview, Varonis, or similar DLP tools can automatically classify and label documents. High upfront cost but pays off at 50+ employees.
- Training + culture: For sub-25-person teams, the most practical approach is training people to apply labels consistently, spot-checked by security reviews.
Don't let perfect be the enemy of good. Some labelling with training is better than an elaborate scheme no one follows.
Secure disposal: the forgotten half of the policy
ISO 27001 A.8.3 and PCI DSS Req 9.8 both require secure disposal of media containing sensitive data. Common requirements:
- Digital files: secure deletion (DoD 5220.22-M or NIST 800-88 equivalent) — not just moving to Trash
- Cloud storage: deletion API call + confirmation; understand the provider's soft-delete and backup retention periods
- Physical documents: cross-cut shredding (not strip-cut) for Confidential and above
- Hardware: certified secure wiping or physical destruction before disposal; certificate of destruction from vendor
- GDPR Art. 17 right to erasure: your classification scheme should inform your erasure process — Restricted personal data requires the most thorough deletion approach (including backups)
Compliance framework mapping
| Framework | Reference | Data Classification Requirement |
|---|---|---|
| ISO 27001:2022 | A.5.12 | Information classified according to legal requirements, value, criticality, sensitivity to disclosure or modification |
| ISO 27001:2022 | A.5.13 | Appropriate set of procedures for information labelling developed and implemented |
| ISO 27001:2022 | A.8.2 | Classification aligned with access control policy; classification maintained for information lifecycle |
| SOC 2 | C1.1 | Commitments related to confidential information disclosed to user entities |
| SOC 2 | C1.2 | Confidential information disposed of when no longer needed to meet commitments |
| GDPR/UK GDPR | Art. 5(1)(f) | Personal data processed in manner ensuring appropriate security (integrity and confidentiality) |
| GDPR/UK GDPR | Art. 25 | Data protection by design — classification scheme as mechanism to implement data minimisation and appropriate safeguards |
| GDPR/UK GDPR | Art. 32 | Access control and encryption as TOMs — classification determines which controls apply |
| GDPR/UK GDPR | Art. 9 | Special category data = Restricted class minimum; explicit condition required; enhanced TOMs |
| HIPAA | §164.310(d) | Media controls: disposal, re-use, accountability for hardware |
| PCI DSS | Req 3 | Cardholder data (CHD) = highest classification; minimise storage, encrypt, restrict access |
| PCI DSS | Req 9.8 | Media containing cardholder data rendered unrecoverable when no longer needed |
Related guides and generators
- Data Classification Policy Generator
- Information Security Policy Generator
- Access Control Policy Generator
- Data Retention Policy Generator
- GDPR Article 30 RoPA Generator
- SOC 2 Gap Assessment Generator
- ISO 27001 Gap Assessment Generator
- GDPR Art. 32 TOMs for SaaS
- SOC 2 Gap Analysis Before Audit
⚠️ This guide is for informational purposes only and does not constitute legal advice. Classification scheme design and compliance requirements vary by framework and industry. Engage qualified security and legal counsel for your programme.