A DPIA That Stays Current: A Living Data-Protection Impact Assessment
A data-protection impact assessment written in Word is accurate the day it's signed and drifting from reality by the next sprint. When the processing it describes is captured by the runtime, the DPIA can be a query against what's actually happening.
- Katya SavenkovaDirector of Operations
In this article
A DPIA is meant to show you understand and have mitigated the privacy risks of processing personal data. For AI, the standard version — a document authored once and filed — has a fatal flaw: the processing keeps changing while the document doesn't. A DPIA that describes last quarter's system is a liability. The fix is to tie it to what the runtime actually does, so it stays current.
What a DPIA is supposed to do
A data-protection impact assessment documents what personal data a process uses, why, what the risks are, and how they're mitigated — and it's expected for higher-risk processing, which AI over personal data often is. Its purpose is genuine: to force you to understand and reduce privacy risk before harm happens. The purpose is good; the usual execution — a static document — is what undermines it.
Why the Word document goes stale
An AI system's data processing is not fixed. A new data source is connected, a retrieval scope changes, a model is swapped, a redaction rule is added. Each change alters the privacy picture the DPIA described — and the DPIA, being a document, doesn't notice. Within weeks it describes a system that no longer exists, which means it's not just useless but actively misleading: it asserts a risk posture that isn't true anymore.
A DPIA's value is that it reflects reality. A document can't — but a query against the runtime can.
A DPIA grounded in the runtime
Much of what a DPIA describes is observable in a governed runtime. What data is processed, under what access scope, with what redaction, retained how long — these aren't things you have to assert from memory; they're things the platform enforces and records. So the factual backbone of the DPIA can be drawn from what's actually happening, and refreshed, rather than reconstructed. The assessment describes the live system because it's connected to it.
What still needs human judgment
To be clear, a living DPIA doesn't remove the assessment part. Whether a residual risk is acceptable, whether a mitigation is sufficient, whether the processing is proportionate to its purpose — these are judgments a human makes, and must. What the runtime grounding provides is an accurate, current picture of the facts those judgments are made against, so the judgments aren't being applied to a system that's changed out from under them.
Staying current as an asset
A DPIA that stays current changes its role from a compliance artifact to a genuine risk tool. When a change to processing is reflected in the assessment, you can see the privacy impact of a decision before you ship it, and a regulator asking 'is your DPIA current' gets a yes backed by the live record. The document stops being a snapshot you dread updating and becomes a view you can trust.
Frequently asked questions
Keep the DPIA true. See how the factual backbone of a data-protection impact assessment can be grounded in what the runtime actually does — and stay current as processing changes. Book a walkthrough.
Part of