Classification Propagation

A column classified as sensitive is protected in the table where it was classified. Copied into an aggregate, a model's training set, an export or a reverse-ETL destination, it has escaped the policy — and the control now exists on the source and nowhere else.

The classification must propagate through lineage, and enforcement must apply to the derived asset too.

Why it matters

Derived data is where most of the real exposure lives. The primary tables are the ones that get reviewed; the aggregates, extracts and copies are created by people solving a different problem and are rarely classified at all.

It is also the mechanism that makes deletion possible: you cannot delete what you cannot find, and an inventory that covers primary tables and misses derivations leaves the obligation silently unmet.

Implementation patterns

• Labels attached at the schema level, in code, reviewed like code — not in a register that drifts.
• Automatic propagation through the transformation framework, so a derived column inherits the strictest label of its inputs unless explicitly downgraded with a recorded justification.
• Three levels at most, with unambiguous examples, so a developer classifies in seconds. Five or six cannot be applied consistently, so the classification becomes arbitrary and so do the derived controls.
• Automated consequences per level: encryption, retention, whether it may appear in logs, whether it may leave a region, who may query it, masking in non-production.
• Enforcement rather than documentation — a sensitive field appearing in a log statement or a non-production dataset rejected by a pipeline check.
• Defaults that fail safe: unclassified treated as most sensitive, making classification the path of least resistance.

Industry example

Insurance platforms such as Digit and payment platforms such as Razorpay both have the compounding problem: a sensitive field flows into aggregates, exports for partners, model training sets and support tooling, and each copy is a place the control must apply.

And field-level classification does not reach inside unstructured documents, which contain everything — making extraction and redaction a separate problem with its own error rate, and treating a document store at the highest sensitivity present in it the usual defensible simplification.

Failure scenarios

• Classification on primary tables only, with derivations unlabelled.
• A manual register, out of date within a quarter.
• Too many levels, producing arbitrary classification.
• Downgrade without justification, which is how a label is lost silently.
• Documents treated as a single unclassified asset.

Trade-offs

Inheriting the strictest label of all inputs is conservative and produces over-classification: an aggregate that reveals nothing about an individual inherits the label of its most sensitive input, and the resulting controls make legitimate analysis harder.

The resolution is a recorded downgrade — a reviewed justification that an aggregate is no longer sensitive — rather than either automatic downgrading, which loses the label silently, or no downgrade path, which makes the whole platform behave as though everything is maximally sensitive and drives analysts to copy data out.

Interview question

"A sensitive column is copied into a monthly report that is emailed to a partner. Which of your controls applied, at which point, and what would you change?"