Classification Propagation

Access control on a data platform is applied to classified data: this column is personal, that table is restricted, this dataset is confidential. The classification is attached to the source.

Data does not stay at the source. It is joined, aggregated, denormalised, indexed, exported and cached — and each derivative is a new object that the classification did not follow. A restricted column copied into a convenient aggregate table becomes, by default, unrestricted.

Classification propagation is the mechanism that makes the label follow the data, so that a derivative inherits at least the sensitivity of its most sensitive input.

Why it matters

This is the most common way access controls are defeated, and it requires no malice. An analyst builds a useful denormalised table for their team; the source columns were protected; the new table is not. Access is granted to the new table on its own merits, and the protection is gone — with every individual step being reasonable and none of them being a policy violation as written.

The failure is also invisible to the controls themselves. The row filters and column masks on the source continue to work perfectly. Nothing alerts. The exposure is discovered by an audit, a leak, or not at all.

Implementation patterns

• Classify at ingestion, as a required attribute, with unclassified data defaulting to restricted — otherwise classification never happens and the default is open.
• Propagate automatically through lineage: a derived object inherits the maximum sensitivity of its inputs, computed by the platform rather than declared by the author.
• Support explicit declassification as a reviewed, recorded exception — an aggregate genuinely may be less sensitive than its inputs, and that must be a decision with an approver rather than a side effect.
• Apply policy to the classification, not to the object, so a newly-created derivative is governed the moment it exists, without anyone granting or restricting anything.
• Cover every path: views, materialised tables, exports, extracts, search indexes, caches, notebooks and BI tool datasets. A path that does not propagate is where the data leaves.
• Detect re-identification risk, since a masked identifier may be reversible by joining other columns — a genuine and frequently overlooked exposure that per-column classification does not capture.
• Make effective access computable in both directions: what can this person see, and who can see this data.
• Alert on classification drops, where a derivative is less sensitive than its inputs without an approved exception.

Industry example

Catalogue-based governance layers — Unity Catalog and comparable systems — implement exactly this: classification attached to columns, propagated through lineage to derived tables and views, with policy applied to the labels rather than to individual objects. The design exists because per-object grants demonstrably fail at scale, producing permission sets nobody can reason about and access reviews that revoke nothing.

The same reasoning drives the wider requirement for lineage capture. Lineage is frequently justified for impact analysis and debugging, and its governance use is at least as valuable: without it, the derivatives of a sensitive source cannot be enumerated, so neither classification propagation nor erasure can be performed reliably.

Failure scenarios

• Unclassified data defaulting to open, which makes every downstream control decorative.
• Derived tables created outside the governed path — in a notebook, an extract, a BI tool's own storage.
• Classification declared manually by the object's author, who has an incentive to declare it low.
• Aggregates assumed to be safe, when small groups permit re-identification.
• Masked identifiers reversible by join, defeating the mask without touching it.
• Exports and downloads unclassified, which is where data leaves the platform entirely.
• Lineage incomplete, so propagation covers the paths the platform knows about and not the others.
• Declassification without review, turning the exception into the norm.

Trade-offs

Automatic propagation is conservative by construction: a table joining one sensitive column to ten benign ones inherits the sensitivity of the whole, which restricts access to data that mostly does not need it. That over-restriction drives people to build unrestricted copies, which is the exact failure the mechanism exists to prevent — so the declassification path must be genuinely usable, not merely present.

It also requires complete lineage, which is a substantial investment and is never quite complete: notebooks, local extracts and third-party tools create derivatives the platform cannot see.

The trade is over-restriction and lineage investment in exchange for protection that survives the data being copied. For an estate where derivatives are rare it is unnecessary; for a self-service analytics platform, where creating a derived table is a routine daily act, it is the only version of access control that remains true after the first month.

Interview question

"An analyst joins our customer table to an order table and saves the result for their team. Tell me what happens to the protections on the personal columns, what should happen, and what you would build to close the gap without making people stop building derived tables."