Data Classification Template

Overview

Not all data is equal. A public marketing blog post and a customer credit card number don’t deserve the same protection, but teams often apply uniform encryption and access controls because nobody defined the difference. Data classification creates a shared vocabulary for risk: public data can be open, internal data needs access control, confidential data needs encryption, and restricted data needs encryption plus strict need-to-know access. Without it, engineers default to either over-protecting everything (expensive and slow) or under-protecting everything (breach risk).

This template gives you a four-level scheme, a dataset inventory, per-level handling rules, and an exception log. Copy it into your wiki or security handbook, fill in the placeholders, and you’ve got a classification policy your team can actually enforce.

When to Use

Use this template when:

• You’re designing a data storage or access control policy and need consistent labels across teams
• Compliance frameworks (SOC 2, GDPR, HIPAA, PCI DSS) require documented data handling
• A breach or leak happened and you realize nobody agreed on what “sensitive” meant
• You’re onboarding a new security engineer or DPO who needs to understand the existing scheme
• You’re scoping a DLP tool rollout and need the labels the tool will enforce

Don’t use this template when your organization already follows a mandated scheme — government contractors bound by a clearance model (Unclassified/CUI/Secret) or PCI merchants inside an existing CDE scope should adapt the mandated taxonomy instead. If your immediate need is consent and subject rights rather than labeling, see the Data Privacy and GDPR Compliance recipe.

The Template

Copy the markdown below and replace the placeholders. The classification document itself should live wherever your team keeps security policies — a wiki page or a versioned repo works; what matters is that engineers find it during design reviews.

# Data Classification: <System / Dataset>

## 1. Classification Definitions

| Level | Description | Examples | Handling Requirements |
|-------|-------------|----------|----------------------|
| **Public** | Approved for public disclosure | Marketing site, OSS repos, job posts | No access control; standard backups |
| **Internal** | Employees and contractors only | Wikis, roadmaps, non-sensitive metrics | Role-based access; encrypted at rest; MFA remote |
| **Confidential** | Disclosure harms the company | Customer PII, financials, source code | Encrypt rest+transit; least privilege; audit log |
| **Restricted** | Disclosure causes severe harm | Cards, SSNs, health records, keys | Encrypt rest+transit; need-to-know; strict audit |

## 2. Dataset Inventory

| Dataset | Classification | Storage | Encryption | Access Control | Retention | Owner |
|---------|---------------|---------|------------|----------------|-----------|-------|
| `user_profiles` | Confidential | PostgreSQL RDS | AES-256 | RBAC: eng, support | 7y post-deletion | @data-owner |
| `payment_tokens` | Restricted | Vault / HSM | AES-256-GCM | Payments team only | 90 days | @security-owner |
| `public_docs` | Public | S3 (public) | None | None | Indefinite | @content-owner |

## 3. Handling Rules by Level

### Access

| Level | Authentication | Authorization | MFA | Remote Access |
|-------|---------------|---------------|-----|---------------|
| Public | None | None | N/A | Open |
| Internal | SSO | Role-based | Required | VPN + MFA |
| Confidential | SSO | Role + approval | Required | VPN + MFA + justification |
| Restricted | SSO + hardware key | Need-to-know + multi-party | Required | Dedicated VPN + justification |

### Transmission

| Level | Internal Network | External Network | Email / Chat |
|-------|-----------------|------------------|--------------|
| Public | Plain | Plain | Allowed |
| Internal | TLS 1.2+ | TLS 1.2+ | Allowed with care |
| Confidential | TLS 1.2+ | TLS 1.2+ + DLP scan | Approved channels only |
| Restricted | TLS 1.2+ + mTLS | Prohibited — secure transfer | Prohibited — approved exchange |

### Storage

| Level | Encryption at Rest | Key Management | Backup | Geolocation |
|-------|-------------------|----------------|--------|-------------|
| Public | Optional | Standard | Standard | Any region |
| Internal | AES-256 | Standard | AES-256 | Approved regions |
| Confidential | AES-256 | HSM or KMS | AES-256 | Approved regions + residency |
| Restricted | AES-256-GCM | HSM | AES-256 + air-gapped | Approved regions, no cross-border |

## 4. Exception Log

| Dataset | Requested Lower Level | Justification | Risk Accepted By | Date | Review Date |
|---------|----------------------|---------------|------------------|------|-------------|
| | | | | | |

End of document. Review and update quarterly.

Explanation

The template replaces vague terms like “sensitive” with four concrete levels. Each level carries explicit handling rules for access, transmission, and storage, so an engineer reading “Confidential” knows exactly which controls apply — there’s no room for interpretation. The dataset inventory forces you to catalog what you have before you can protect it; most teams discover datasets they didn’t know existed during this step. The exception log acknowledges that business needs sometimes require bending the rules, but only with documented risk acceptance and a review date, so exceptions expire instead of becoming silent permanent holes.

Keep the number of levels small. Schemes with six or more levels look thorough on paper but collapse in practice because nobody can tell the difference between “Level 4” and “Level 5” at 2 AM during an incident. Four levels map cleanly to the decisions engineers actually make: can I put this in a public ticket? Can I email it? Does it need an approval workflow?

Data Classification Decision Tree

When a new dataset shows up and the owner isn’t sure which label applies, walk this tree:

The tree intentionally ends every ambiguous path at Confidential rather than at a “TBD” label. A dataset that sits unclassified for weeks is a dataset with no handling rules — which in practice means Public-by-accident.

Handling Requirements by Level

This matrix summarizes the controls each level triggers. It’s the part of the document auditors ask for first, and the part engineers paste into their service READMEs.

Classification	Encryption	Access	Logging	Retention
Public	Not required	Anyone	Optional	No restriction
Internal	At rest	Employees	Required	Per policy
Confidential	At rest + in transit	Need-to-know only	Required + audit trail	Per policy + legal hold
Restricted	At rest + in transit + key vault	Named individuals only	Required + tamper-proof logs	Per policy + legal hold + right to erasure

How to Roll It Out

A classification scheme that lives only in a wiki page changes nothing. The steps below assume a mid-size engineering org; a small team can compress steps 1–3 into a single afternoon workshop. Roll it out in this order:

1. Inventory first, classify second. Export your datastore list (RDS, S3, warehouses, SaaS tools) and get each dataset an owner before debating levels. Datasets without owners get flagged, not classified — an unowned dataset is itself a finding.
2. Classify at creation, not retroactively. Add a “data classification” field to your service onboarding checklist, PR template, or Terraform module variables. Retroactive classification of 200 existing datasets takes quarters; labeling the next dataset takes a minute.
3. Wire enforcement where data flows. Classification labels are only useful if something checks them: DLP rules on email and storage, bucket policies that block public ACLs on non-Public datasets, CI checks that fail when a schema gains a PII column without a label.
4. Handle mixed datasets at the highest level. A spreadsheet with Public marketing copy and Restricted card numbers is Restricted. Where possible, split the dataset so the bulk of it isn’t dragged up a level by a few columns.
5. Review on a schedule, and on triggers. Quarterly for Restricted, biannually for Confidential, annually for Internal and Public. Also review when a dataset’s purpose changes, a regulation starts applying, or two datasets merge.
6. Treat test and staging data as classified. Production clones in staging carry the same sensitivity. Either scrub them to a lower classification or enforce the same controls — “it’s just staging” is how most test-environment leaks start.
7. Feed the labels into the rest of your security documents. Classification is an input, not a product: retention rules in your data retention policy, containment steps in your incident response playbook, and scope lines in your security audit checklist all read from it. When those documents disagree with the scheme, fix the scheme — don’t fork the vocabulary.

Worked Example

A small B2B SaaS (“Acme Analytics”) adopts the template. Their completed inventory looks like this:

Dataset	Level	Reasoning
customers.user_profiles	Confidential	Names, emails, company — PII, but not sensitive categories
billing.payment_tokens	Restricted	Card data via PSP tokens; PCI scope applies
analytics.events	Internal	Product usage metrics, aggregated, no PII after filtering
logs.app_requests	Confidential	Contains user IDs and request paths; often overlooked
db_backups.nightly	Restricted	Full dump includes both profiles and tokens — highest level wins
blog.content	Public	Approved marketing material
sales.pipeline_export	Confidential	Prospect emails and deal values; shared only with sales leadership

Three decisions were non-obvious and worth documenting: the log store got bumped from Internal to Confidential because it carries user IDs; database backups inherited the highest level present (Restricted), which forced them into encrypted, need-to-know storage instead of the shared backup bucket; and the analytics pipeline needed a documented filter proving it strips PII before events land in the Internal warehouse. That filter is now an exception log entry with a quarterly review.

Ninety days later the scheme already paid for the effort: two exceptions expired instead of rotting, and the payments team moved card handling to their PSP’s hosted fields, which let them downgrade billing scope from Restricted to Confidential and cut the audit surface in half.

Variants

Context	Extra Levels	Key Difference
Healthcare (HIPAA)	Add PHI / ePHI labels	Patient data is always Restricted; BAAs required
Finance (PCI DSS)	Add CDE (Cardholder Data Environment)	Card data is Restricted; network segmentation mandatory
Government	Add Unclassified, CUI, Secret, Top Secret	Clearance-based access; air-gapping common
SaaS startup	Merge Internal + Confidential	Simplicity over completeness when the team is small
EU operations	Add “EU Personal Data” flag	GDPR residency and processing agreements required

Pick the base scheme first and only add labels when a regulation forces you to. A five-level scheme where the fifth level covers three datasets is usually better expressed as Restricted + a flag, like the EU row above.

What Works

1. Label data at creation, not at storage; retroactive classification is expensive and error-prone
2. Automate classification where possible; DLP tools can tag data based on patterns (credit cards, SSNs)
3. Review classifications quarterly; a “public” dataset that becomes revenue-critical may need upgrading
4. Train engineers on the difference between Confidential and Restricted; the gap is where breaches happen
5. Log every exception; patterns of exceptions indicate policy misalignment or training gaps

Common Mistakes

1. Classifying everything as Confidential to be “safe”; this dilutes protection and slows engineering
2. Not labeling test/staging data; developers often clone production and forget the data is still sensitive
3. Ignoring metadata; a log file containing user IDs is Confidential even if it contains no names
4. Not including third-party vendors in classification rules; a SaaS tool with SSO is still external
5. Treating classification as a one-time audit; data changes, services evolve, and classifications rot
6. Classifying the source but not the copies; a CSV export of a Restricted table sitting in marketing’s inbox is still Restricted

Troubleshooting

• Teams can’t agree on a level: use the decision tree, and when it still lands ambiguous, classify higher and record the debate in the exception log for the next review.
• DLP tool floods false positives: tune patterns against your actual data samples before enabling blocking mode; a tool that cries wolf gets bypassed.
• Legacy data is unlabeled and nobody owns it: assign a provisional owner (usually the team that reads it most) and classify at the highest level the content might contain until someone proves otherwise.
• A vendor won’t sign the DPA your Restricted tier requires: keep that vendor out of the Restricted data flow entirely — a “temporary” exception without a review date is a permanent one.
• Labels exist but nothing enforces them: pick one enforcement point that hurts (usually the public-bucket check or the email DLP rule) and make it real before adding more paperwork.

Further Reading

• ISO/IEC 27001 — Information security management: Annex A control 5.12 covers classification of information; the basis most auditors expect.
• NIST SP 800-60: US government guide for mapping information types to security categories.
• AWS Macie documentation: managed discovery and classification of sensitive data in S3.
• Google Cloud Sensitive Data Protection: managed DLP scanning for GCP storage and warehouses.
• Microsoft Purview: data classification and governance across Microsoft and multi-cloud estates.
• EU GDPR text (EUR-Lex): Articles 5, 30 and 32 drive the records-of-processing and security requirements behind most classification schemes.

Companion code: data classification template files: the fillable template and the completed B2B SaaS example from this page.