Privacy by Design in Data Management and Governance

The Parallel Programme Problem

A familiar organisational shape: Legal owns privacy. They maintain a record of processing activities, run privacy impact assessments and answer regulators. Elsewhere, a data governance team maintains a catalog, a glossary and a set of classification tags.

The two rarely reconcile. The RoPA describes processing activities; the catalog describes assets. Neither maps cleanly to the other. When a subject access request arrives, or a regulator asks which systems hold a particular category of personal data, somebody conducts a manual reconciliation that takes weeks and produces an answer nobody is fully confident in.

This is not a failure of either team. It is a structural consequence of treating privacy as a compliance discipline rather than a data management one. Purpose, lawful basis, consent state, retention period and minimisation are all attributes of data. They belong on the same assets, in the same catalog, under the same ownership model as quality and lineage.

The Seven Principles, and What They Cost

Ann Cavoukian’s seven principles of privacy by design are now embedded in regulation — Article 25 of the GDPR requires data protection by design and by default, and India’s DPDP framework carries the same logic through its consent, purpose and minimisation obligations.

The principles are sound. What is usually missing is an honest account of what each one demands operationally.

Principle	What it actually requires
Proactive, not reactive	Privacy review at design, before a schema exists. Requires engineering teams to know a review is expected — which means it has to be in their workflow, not on an intranet page
Privacy as the default	Fields default to restricted; access is granted, not assumed. Expensive to retrofit, nearly free if designed in
Embedded in design	Classification and purpose declared at the point a data element is created, not catalogued afterwards from memory
Full functionality	Rejecting the false trade-off between privacy and utility — usually achieved through techniques rather than exemptions
End-to-end security	Protection through the whole lifecycle including backups, derived data sets and vector indexes — the places organisations most often forget
Visibility and transparency	Being able to answer, quickly, what you hold about a person and why. This is a lineage problem
Respect for the user	Rights requests fulfilled within statutory windows without a manual scramble

Read down the right-hand column and a pattern emerges: five of the seven are governance capabilities, not legal ones.

Where the Controls Attach

The value of laying it out this way is that it makes the gaps visible. Most organisations have something at Collect and something at Delete, and very little in between — which is precisely where the enforcement has to happen.

Purpose Limitation Is the Hard One

Of all the privacy obligations, purpose limitation is the one most often declared and least often enforced.

The pattern is consistent. A purpose is stated in a privacy notice at collection — service delivery, say. The data lands in a warehouse. Eighteen months later an analyst joins it to a marketing data set for a propensity model. Nothing in the technical stack objected, because purpose was recorded in a document and the warehouse only knows about tables.

Making purpose enforceable

Three things have to be true:

1. Purpose is a tag on the data, not a sentence in a notice. Every personal data element carries the purposes it was collected for, as structured metadata in the catalog.
2. Access requests declare a purpose. The workflow asks what the data will be used for, and that declaration is recorded against the grant. This alone catches a surprising share of drift, because people are reluctant to write down a purpose they know is questionable.
3. The policy engine compares the two. A request whose declared purpose is not among the data’s permitted purposes is refused or escalated. Not flagged in a report — refused.

Atlan’s purposes model, Collibra’s policy and protect capabilities and Purview’s classification-driven policies all support some version of this. The technical capability is not the constraint. The constraint is having purpose metadata accurate enough that you are willing to let it block a request.

Consent Lineage

Consent is not a checkbox. It is a state that changes over time and has to propagate to every place the data travelled.

The operational question that exposes maturity: a person withdraws consent this morning. Which systems stop processing their data, and when?

For most organisations the honest answer involves a manual process, a spreadsheet of downstream systems compiled at some point in the past, and a delay measured in weeks. The DPDP framework’s consent manager mechanism — with interoperable platforms through which people can review and withdraw consent across services — makes this considerably harder to fudge, because withdrawal arrives as a signal rather than an email.

What consent lineage requires:

• A consent record with a stable identifier, linked to the data subject and the specific purposes consented to.
• Every downstream copy, aggregate and derived asset traceable back to that identifier — which is ordinary lineage, applied to a privacy attribute.
• An event mechanism so withdrawal propagates rather than requiring a sweep.
• Evidence of action, because being able to show a regulator what you did and when is the actual obligation.

Minimisation, and Why Retention Is Its Enforcement

Minimisation is stated as collecting only what is necessary. In practice the collection decision was made years ago by someone who has left, and the live question is retention: why are we still holding this?

Two observations from delivery work.

Usage telemetry is the fastest route to minimisation. Query log analysis routinely shows that a substantial share of catalogued personal data fields have not been read by anything in a year. Fields nobody queries are pure liability — they carry breach exposure, subject access burden and retention obligation while producing nothing. Deleting them is the cheapest privacy improvement available to most organisations, and it requires no new technology.

Retention schedules fail at the copies. An organisation deletes from the system of record and considers the obligation met. The data persists in the warehouse, in three downstream marts, in a BI extract, in backups, and increasingly in a vector index built for a retrieval system. Retention has to be lineage-aware or it is theatre.

A practical test

Pick one personal data field. Trace it forward through every copy and derivation. Count how many places it exists. Then ask what your deletion process actually touches. The gap between those two numbers is your real retention posture.

Techniques That Remove the Trade-Off

The fourth principle — full functionality, not zero-sum — is the one that sounds most like marketing and is in fact the most technically substantive. A set of techniques genuinely lets you keep analytical utility while reducing exposure, and each has a specific right use.

Technique	Use it when	Watch for
Tokenisation	Identifiers must be joinable across systems but need not be readable	Token vault becomes the crown jewel; secure it accordingly
Dynamic masking	Same table serves users with different entitlements	Masking applied at the BI layer only — the warehouse is still exposed
Pseudonymisation	Analytics on individual-level behaviour without identity	Still personal data under GDPR; reduces risk, does not remove obligation
Aggregation with thresholds	Reporting where individual rows are unnecessary	Small cells re-identify; enforce a minimum group size
Synthetic data	Development, testing, demonstration environments	Poorly generated synthetic data leaks the original distribution
Differential privacy	Published statistics or shared aggregate outputs	Genuine utility cost; budget management is an ongoing discipline

A common and avoidable error is using synthetic or masked data in non-production while leaving production access broad. Non-production is usually the easier target and the more commonly breached; the effort is worth spending, but not instead of production controls.

The AI Complication

Generative and agentic AI have created privacy exposure faster than most governance programmes have adapted, in three specific ways.

Vector indexes inherit everything and carry nothing

A retrieval system built over a document repository inherits every privacy defect that repository had, and the embedding process typically strips the classification that would have flagged it. Personal data in a document becomes retrievable by anyone with access to the assistant, regardless of who could open the original file.

The fix is structural: every chunk retains its source pointer, classification and permitted audience, and retrieval filters on the requesting user’s entitlements at query time rather than only recording them.

Models inherit lawful basis

Training a model on personal data is processing. The lawful basis of the training data constrains the model, and where consent was the basis, withdrawal has consequences that deletion of the source row does not resolve. Whether a data set may be used for AI training should be an explicit governance attribute, enforced by the feature store, not a judgement made by whoever built the pipeline.

Agents act on personal data at machine speed

An agent with broad read access and the ability to compose and send communications can create a disclosure incident faster than any human process. Least-privilege identity per agent, purpose-scoped data access and approval gates on anything that leaves the organisation are the controls that matter — and they are access control problems, not prompt engineering problems.

Where to Start

A sequence that produces defensible improvement in a quarter rather than a programme that reports coverage for two years.

1. Unify the inventory. One record of what personal data exists, where, and under what basis — in the catalog, not in a parallel spreadsheet. This is the single highest-value step and it usually requires organisational agreement more than technology.
2. Classify by sensitivity and purpose together. Sensitivity alone tells you how hard to protect it. Purpose tells you who may use it and for what. Most programmes have the first and not the second.
3. Instrument one enforcement path. Pick classification driving masking, or purpose driving access approval. Make it real. This is the moment privacy stops being documentation.
4. Trace one field end to end. Including into derived assets and indexes. The result will be uncomfortable and it will tell you more than any assessment.
5. Delete what nothing reads. Query telemetry identifies it; the risk reduction is immediate and the effort is low.
6. Then automate rights fulfilment, once lineage is good enough that a subject access request can be answered from the catalog rather than by interview.

Privacy that lives in a legal register describes your intentions. Privacy that lives in your catalog governs your data.

Published by KRISID · 10 July 2026. This paper reflects our delivery experience and publicly available sources at the time of writing. It is general guidance, not legal advice — regulatory obligations vary by jurisdiction and by how a system is used.