Data Security, Privacy & Compliance
Every data programme meets the same gate: can you show who may see what, prove where it went, and delete it when asked. This track is about passing that gate by design rather than by exception — and about the fact that the controls are cheaper applied to data than reimplemented in every application.
01 The syllabus
What this track covers
Eight topics, in the order they have to be done. Each one is a capability rather than a document, and each depends on the one before it.
Classification
Deciding what kind of data each field holds — personal, sensitive, regulated, commercial — because every control after this one is applied by class rather than by table.
Without it: policy per report, foreverDiscovery of personal data
Finding where personal and special-category data actually sits, including the copies in spreadsheets, test environments and analytics extracts that nobody registered.
The estate is always wider than the registerAccess control
Role-based and attribute-based entitlement enforced at the data rather than in each application, so one policy governs every consumer including an agent.
RBAC for structure, ABAC for contextMasking and tokenisation
Making data usable without exposing it: static masking for lower environments, dynamic masking by role, tokenisation where the original must be recoverable.
Test data is the most common breach pathEncryption and key management
At rest, in transit, and the question that actually matters — who holds the keys, and whether that satisfies the jurisdiction you operate in.
Encryption without key control is theatreResidency and sovereignty
Where data may be stored and processed, which increasingly constrains architecture more than cost does, and applies to backups and support access too.
Support access is processingRetention and deletion
Keeping data no longer than the purpose requires, and being able to delete it across every copy — which is only possible if lineage is complete.
You can only delete what you can traceConsent and purpose limitation
Recording why data may be used and enforcing that at query time, so a dataset collected for service delivery is not quietly used to train a model.
Purpose is an attribute of use, not of storage02 The frameworks
What the frameworks actually require of data
Different regimes, converging demands. Read the right-hand column as the engineering requirement: it is broadly the same list regardless of which regime brought you here.
| Framework | What it is concerned with | The data obligation it creates |
|---|---|---|
| GDPR (EU/UK) | Personal data of individuals, and the lawfulness of processing it | Lawful basis and purpose recorded per use; minimisation; access, correction and erasure on request; records of processing; impact assessments for high-risk processing |
| India DPDP Act | Consent-led processing of personal data by data fiduciaries | Notice and consent captured and revocable; rights of the data principal honoured; additional obligations where you are a significant data fiduciary |
| CCPA / CPRA (California) | Consumer rights over personal information, including sale and sharing | Inventory of categories collected and disclosed; opt-out honoured downstream; deletion propagated to service providers |
| HIPAA (US healthcare) | Protected health information and who may handle it | Minimum necessary access; audit controls on every access; agreements with anyone processing PHI on your behalf |
| PCI DSS | Cardholder data wherever it is stored, processed or transmitted | Storage restrictions on sensitive authentication data; tokenisation or truncation; segmentation and evidence of both |
| BCBS 239 (banking) | Risk data aggregation and reporting capability | Accuracy, completeness, timeliness and adaptability of risk data, with lineage that can be demonstrated rather than asserted |
| ISO 27001 / SOC 2 | The management system and controls around information security | Documented controls, evidence they operated, and access reviews you can produce on request |
Summarised at the level of the obligation each framework creates for data. For the binding text, and for how it applies to you, take advice — the requirements are stable, the detail and the timelines are not.
03 The controls
The controls, and where each one belongs
The recurring mistake is implementing these per application. Each one applied once at the data layer covers every consumer, including the ones that do not exist yet.
| Control | What it does | Where it should live |
|---|---|---|
| Classification | Labels each field by sensitivity and regulatory class | The catalogue, applied automatically and reviewed by a steward |
| Entitlement | Decides who may see which rows and columns | The governed data layer, not each BI tool |
| Masking | Removes or obscures values for those without entitlement | Dynamic at query time; static when data leaves for lower environments |
| Encryption and key custody | Protects data at rest and in transit | Platform and infrastructure, with keys held where the jurisdiction requires |
| Lineage | Shows every place a field has travelled to | Captured automatically from pipelines; it is what makes deletion and DSARs possible |
| Retention | Removes data when the purpose expires | Policy on the dataset, enforced by the platform rather than by a cleanup script |
| Audit logging | Records who accessed what, and when | The access layer, immutable, and retained as long as the obligation lasts |
| Purpose binding | Ties permitted use to the basis the data was collected under | The semantic layer, evaluated at query time |
04 Sequence
Getting there in one quarter rather than one programme
The order matters. Every organisation that starts with policy documents and ends with a spreadsheet of controls had the sequence the wrong way round.
05 What goes wrong
The four failures worth naming
Policy without enforcement
A published standard that no system applies. It survives an audit of documents and fails the first audit of behaviour.
Copies nobody registered
Extracts into spreadsheets, notebooks and test databases are where most real exposure lives, and they are invisible to a control applied only to the warehouse.
Access granted per project, revoked never
Entitlement accumulates. Without periodic review driven by data rather than by memory, the effective access surface only grows.
Deletion that cannot be proved
Removing a row from the source while copies persist downstream satisfies nobody, and lineage is the only way to know where they are.
06 Diagnostics
Six questions to ask your own team
If two of these cannot be answered without a manual investigation, those two are the plan for the next quarter.
- Can you list every place a customer's personal data exists, including copies, without a manual investigation?
- Is entitlement enforced once at the data layer, or reimplemented in every reporting tool?
- Is production data masked in test and development environments today?
- If a subject access or deletion request arrived this morning, how long would it take, and who would do it?
- Can you produce an access review for a regulated dataset from the platform rather than from memory?
- Do you know which datasets an AI system or agent is permitted to read, and is that enforced?
07 Measure it
The metrics behind this track
08 Questions
Frequently asked
Where should access control actually be enforced?
At the data, once. Enforcing it in each BI tool, application and export means the control is as strong as the weakest consumer, and a new consumer — an agent, a notebook, a partner feed — starts with no control at all.
Does compliance slow a data programme down?
Retrofitted, badly. Designed in, it usually accelerates it, because the arguments that normally stall a rollout — who may see this, where may it live, how do we delete it — already have answers.
What is the most commonly missed exposure?
Non-production environments. Full copies of production data with weaker access controls are both the most common breach path and the easiest thing to fix with masking.
How does this relate to data residency for AI?
Directly. Sending data to a model endpoint is processing, and where that endpoint runs is a residency question. It should be answered by policy on the dataset, not by whoever configured the integration.
See these controls running
Classification, entitlement, lineage and policy applied to the data itself rather than to each report.