Data Platform & Analytics · Chapter 6 of 8
Governance, privacy and the 82%
Named in more postings than SQL. Treat it as the job rather than as paperwork.
Privacy and compliance language appears in 82% of the data-platform postings behind this site. That is not because these teams love policy — it is because a data platform is where an organisation's regulatory exposure physically lives.
The five things you will actually be asked to implement
| Requirement | What it means in the platform | Where it usually fails |
|---|---|---|
| Classification | Every column tagged by sensitivity, ideally at ingestion | Applied to tables, not columns, so everything inherits the strictest tag |
| Access control | Row and column-level, derived from classification | Granted per-person ad hoc; nobody can answer who can see salary data |
| Retention | Automatic deletion on a schedule per class | Nothing is ever deleted, because deletion is scary and nobody owns it |
| Erasure | Find and remove one person across every copy | Backups, exports, and the analyst's local extract |
| Residency | Data physically stays in a jurisdiction | A replica or a backup quietly crosses a border |
The question that finds the real problem
“If a customer asks us to delete their data tomorrow, what exactly do we do?” The honest answer usually reveals four copies nobody had listed — the warehouse, a materialised mart, a backup, and someone's extract. Erasure is the requirement that exposes whether the lineage and the inventory are real, which is why it is worth asking first.
Make the platform the easy path
Governance imposed as a review gate produces shadow pipelines. Governance implemented as defaults — classification applied at ingestion, access derived from it, retention scheduled automatically — produces compliance without anybody choosing it.
This is the same principle as the paved road in platform engineering, and it is the difference between a governance programme that works and one that generates documents.