Data classification
Data classification sorts the data a system handles into a few classes by the harm its loss, change or misuse would cause, so each class comes with a known set of controls. For a single change, it means naming the classes of data the change touches, where copies go, how long they stay and which rules apply.
Controls follow from the data, so unrecorded data gets the wrong ones. If nobody notes that a new analytics event carries health data, it can reach a third-party tracker, a log and a backup with the controls of internal data, and the team learns about duties such as GDPR's 72-hour breach notice only after an incident. Classification tells threat modeling and requirements how much protection each flow needs.
- Who
- The developer and product owner, with privacy or legal review when regulated data or an unclear obligation appears
- When
- In planning, before design and control choices, whenever a change adds or moves data
- How often
- For every change that adds a field, store, export, log or vendor; the scheme itself yearly
- You end up with
- The data classes, purposes, retention and obligations recorded on the ticket and in a data inventory
Do this
Agree a small set of classes
Three to five classes defined by impact are a common starting point, such as public, internal, confidential and restricted. NIST FIPS 199 rates the impact of losing confidentiality, integrity and availability as low, moderate or high, so rate all three, not only secrecy. Write down what each class requires, as OWASP ASVS 5.0
v5.0.0-14.1.2expects.List the data the change touches
For each new or changed field, event, file and export, record what it holds and its class. Include the copies: logs, analytics events, search indexes, caches, exports and backups. ASVS
v5.0.0-14.1.1reminds you that data which is only encoded, such as a Base64 string or a JWT payload, is still the data it contains.Flag regulated and secret data
Mark personal, health and payment card data, credentials and secrets explicitly. Health data is special category data under GDPR Article 9, and pseudonymized data stays personal data while anyone, including you, can re-identify it. Secrets go in a secret store, never in the data model or the code (Secrets out of code).
Record purpose and retention for each copy
Give each field a purpose and each copy a retention rule with a trigger, a duration and an owner, such as "delete 30 days after account closure". Drop fields the purpose does not need: data you never collect needs no protection and no deletion path.
Note the obligations and the open questions
List the laws and contracts that may apply, such as GDPR, HIPAA, the FTC Health Breach Notification Rule or PCI DSS for card data. Send unclear ones to privacy or legal review with an owner and a due date. "Under review" is an honest state; a blank that reads as "no obligation" is not.
Feed the classes into design and tests
Use the classes in the threat model (Threat modeling) and the security requirements (Security requirements). Restricted data might need field-level authorization, encryption, no values in logs and a deletion test. A CI check that fails when a new column has no inventory entry stops unclassified data from merging.
Done when
The ticket names the data classes, their retention and the obligations in scope.
Mark it in the gap checkCommon mistakes
- Classifying only the main database. Copies in logs, analytics, search indexes, exports and backups carry the same data, often with weaker controls and no deletion path.
- Calling tokenized or pseudonymized data anonymous. While anyone, including you, holds the lookup table, it is still personal data with the same duties.
- Rating only confidentiality. A public price list still needs integrity, because a changed price costs money.
- Writing "not covered by HIPAA" as if it meant "no obligation". A health app outside HIPAA can still owe breach notices under the FTC rule and consent under state laws such as Washington's My Health My Data Act.
- Classifying once and never again. A new field, export or vendor changes what a flow carries; tie the review to the change, not to the calendar.
A starting scheme: classes, examples and controls
Names and controls vary by organization; this is a common shape, not a standard. Check the obligations column with privacy or legal review.
| Class | Examples | Typical controls | Obligations to check |
|---|---|---|---|
| Public | Marketing pages, published docs, a public price list | Integrity and availability controls; review before publishing | Usually none for confidentiality |
| Internal | Internal wikis, non-sensitive metrics, service names | Authentication, least privilege, standard logging | Contracts with customers and vendors |
| Confidential | Customer records, email addresses, order history, tenant data | Object and tenant authorization, encryption in transit and at rest, retention rules, no values in logs | Privacy laws such as GDPR when personal data is involved |
| Restricted | Health data, payment card data, credentials, secrets and keys | Restricted data might need all of the above plus field-level access, access logging, masking and tested deletion; secrets in a secret store | GDPR Article 9 for health data, HIPAA or the FTC Health Breach Notification Rule, PCI DSS for card data |
Tools and guides
- Workflow: Secure a feature
- GDPR, CCPA, HIPAA or the FTC rule: scope privacy and health-data obligations before choosing controls
Map data, actors and processing purposes to the relevant GDPR, California or HIPAA requirements and preserve uncertainty about applicability.
- GDPR privacy by design for engineers: Articles 25, 32 and 35 in code
Turn GDPR data protection by design and by default, security of processing and DPIA triggers into engineering work: a personal-data inventory checked in CI, defaults that collect and share less, a DPIA screen at design time, and access and erasure requests that reach every store.
- Data minimization and retention: collect less and prove that deletion works
Design collection and deletion around a data-flow graph that includes logs, derived tables, exports and restored backups, and use per-person keys so deletion can reach copies you cannot edit.
- Tokenization, pseudonymization and privacy transformations: choose deliberately
Choose between vault tokens, keyed pseudonyms, format-preserving encryption, aggregation and differential privacy by the joins, reversibility and leakage each allows, and test re-identification on the data you release.
Standards
- NIST SSDF 1.1
- PO.1 Define Security Requirements for Software DevelopmentPW.1 Design Software to Meet Security Requirements and Mitigate Security Risks
- OWASP SAMM 2
- Threat AssessmentSecurity Requirements
Sources
- NIST FIPS 199: Standards for Security Categorization of Federal Information and Information Systems. February 2004.
- OWASP ASVS 5.0.0: V14 Data Protection. Version 5.0.0.
- NIST SP 800-218: Secure Software Development Framework (SSDF) Version 1.1. February 2022.
- OWASP SAMM: Threat Assessment, stream A (Application Risk Profile)
- Regulation (EU) 2016/679 (GDPR), EUR-Lex. OJ L 119, 4 May 2016.
- HHS: The HIPAA Security Rule
- 16 CFR Part 318, Health Breach Notification Rule (CFR annual edition, via govinfo)
- Washington State Attorney General: My Health My Data Act
- PCI SSC document library: PCI DSS v4.0.1. v4.0.1 (June 2024).