Data classification policy

Description

Data classification is the foundational schema that the rest of the data-protection program reads off of. Every other operational control (encryption, retention, access management, transfer rules, breach-response thresholds) needs to know what tier of data it is operating on, and the classification policy is the single document that defines the tiers and their handling rules. The policy is upstream of essentially every other privacy and security decision the program makes, which is why misalignment between the documented policy and the actual data-inventory tagging compounds across every downstream control simultaneously. The policy decomposes into three deliverables. The tier definition itself names the categories the program will track; most modern programs settle on four to six tiers with the typical split being public, internal, confidential, and regulated (with regulated subdividing into PII, PHI, PCI, and any sectoral category that applies, plus the GDPR Article 9 special-categories carve-out and the increasingly-common AI-training-data flag for jurisdictions where that distinction matters). The per-tier handling matrix documents what each tier means operationally: encryption requirements at-rest and in-transit (AES-256 floor for confidential, FIPS 140-3 module for regulated in some sectoral contexts), retention boundaries, access-control posture (need-to-know, role-based, attribute-based, with break-glass-with-audit for the regulated tier), geographic restrictions where data-localization rules apply (a separate tier or a sub-tier flag is the common pattern for data that must remain in-jurisdiction), and incident-response thresholds keyed to per-tier severity. The data-inventory tagging layer applies the policy to actual data assets: every column in every production table, every event property in the analytics stack, every field in every third-party vendor schema gets tagged to a tier, and the tagging is what makes the policy operational. The trade-off pressure is between policy precision (which adds tiers and sub-tiers and makes the matrix more accurate) and policy operability (a tier scheme that engineers and product managers cannot apply consistently in practice will produce inconsistent classifications, which propagates into wrong decisions everywhere downstream). Most programs find that the classification policy and the data inventory iterate on each other for the first 12 to 18 months before stabilizing, and the stabilized policy is usually simpler than the initial draft. The statutory anchors do not typically prescribe a specific tier scheme but they drive the categories. GDPR Articles 5(1)(f), 9, and 32 require security measures appropriate to the risk and explicit handling rules for special categories of personal data. CCPA at Cal. Civ. Code §§1798.100 et seq. requires disclosure of categories of personal information collected and an inventory adequate to support DSAR responses. HIPAA at 45 CFR Part 164 mandates classification of PHI for the Security Rule's administrative, physical, and technical safeguards. PCI DSS v4.0 requires the cardholder-data-environment scope to be defined and tagged. NIS2 (Directive (EU) 2022/2555) and DORA (Regulation (EU) 2022/2554) layer cybersecurity obligations that explicitly require classification of information assets by criticality. Sectoral regulators (HHS OCR, FFIEC, FINRA, FCA, MAS) maintain their own classification expectations on top of the general frameworks. Evidence formats that satisfy a regulator inquiry include the classification policy document itself, the data-tier mapping showing how production assets are tagged, and the tier-handling matrix that downstream controls reference.

Required by (7 regulations)

• EU CRA

  Supports the CRA Annex I Part I data-minimization essential requirement by documenting what data the product processes and why.

  Regulation (EU) 2024/2847 (Cyber Resilience Act)

  Source →

• Texas CUBI

  Identifies biometric identifiers as a protected data class subject to CUBI's reasonable-care storage standard.

  Capture or Use of Biometric Identifier Act (CUBI)

  Source →

• China CIIPA

  China CIIPA requires classified protection of network data on critical information infrastructure.

  Regulations on the Security Protection of Critical Information Infrastructure (State Council Order No. 745); implementing Cybersecurity Law Articles 31-39

  Source →

• CIRCIA

  CIRCIA incident-reporting obligations are supported by classifying covered systems and data by criticality.

  6 U.S.C. § 681 et seq. (CIRCIA, enacted as Division Y of the Consolidated Appropriations Act, 2022); CISA NPRM published 89 Fed. Reg. 23644 (April 4, 2024); final rule pending

  Source →

• GDPR

  GDPR Article 32 security-of-processing obligations are supported by classifying personal data by sensitivity.

  Regulation (EU) 2016/679 of the European Parliament and of the Council

• NIS2

  NIS2 risk-management measures require classifying systems and data by criticality.

• UK GDPR

  UK GDPR Article 32 security-of-processing obligations are supported by data classification.

Fulfilled by (1)

• In-house build · medium effort

Magist does not accept payment from vendors. Methodology.

Evidence formats

• classification policy
• data-tier mapping
• tier-handling matrix