A consumer finance platform wants to apply controls proportionate to data sensitivity. How should classification work so it actually drives behaviour?

Why most classification schemes fail

They are documents rather than mechanisms. A policy defining four sensitivity levels, with no automated consequence, produces a spreadsheet that is out of date within a quarter and controls that depend on developers remembering which level applies.

The second failure is too many levels. Five or six categories cannot be applied consistently by the people creating data, so the classification becomes arbitrary and the controls derived from it are arbitrary too.

What makes it work

• Three levels at most, with unambiguous examples. A developer must be able to classify a new field in seconds without consulting anyone.
• Classification attached to the data at the schema level, in code, reviewed like code — not in a separate register that drifts.
• Automated consequences per level: encryption requirement, retention period, whether it may appear in logs, whether it may leave a region, who may query it, whether it needs masking in non-production.
• Enforcement rather than documentation. A field classified as sensitive should be rejected by a pipeline check if it appears in a log statement or a non-production dataset, not merely discouraged by a policy.
• Defaults that fail safe. Unclassified data is treated as the most sensitive level until classified, which makes classification the path of least resistance.

The consequences that matter most in consumer finance

• What may appear in logs, which is where sensitive data most often leaks — and where it is retained, replicated to analytics, and read by many people.
• What may go to non-production, since production data in a test environment is a recurring source of breaches and the fix is automated masking rather than a policy.
• What may cross a jurisdiction, since residency rules apply to categories rather than to systems.
• Retention, which differs by category and conflicts between regulations — a transaction record retained for years alongside personal data subject to erasure.

The design that resolves the conflict

Separate the regulated record from the identity, keeping business facts under a pseudonymous reference and the reference-to-person mapping in a separately governed store. Deleting the mapping satisfies erasure while preserving the retained record.

This must be designed early, because retrofitting it means rewriting every table that embedded a personal identifier — which in most systems is nearly every table.