ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
DPIA review and monitoring is the part of the process that most organizations skip, and it is the part the law expressly asks for. Article 35(11) of the GDPR says the controller shall carry out a review to assess whether processing is performed in accordance with the DPIA, at least when there is a change in the risk represented by processing operations. A DPIA that is signed once and filed is out of date the moment the project changes.
This guide explains what triggers a review, how often to schedule one, who should own it, what to check and how to record the outcome. It is general information, not legal advice.
A DPIA describes processing at a point in time. Real systems move: teams add features, suppliers change, data volumes grow and threats evolve. If the assessment does not move with them, the organization is relying on a picture that no longer matches reality, and any regulator who compares the two will notice.
Regular DPIA review and monitoring also protects the project team. It gives an early warning when a measure has failed or a new use has crept in, and it produces a dated trail showing that the organization kept its assessment alive. That trail is valuable evidence if a complaint or investigation arrives.
Article 35(11) requires a review, at least when the risk changes. It does not fix a calendar interval, so the organization decides what is proportionate. Most set an annual review for high-risk processing, with shorter cycles for fast-changing systems, and event-driven reviews whenever a trigger occurs. You can read the text in Article 35 of the GDPR.
Supervisory authorities generally expect a DPIA to be a living document. Guidance from European authorities describes it as a process that continues throughout the life of the processing, not a form to complete once. Build your own cycle around that idea.
| Review trigger | Example | Typical action |
|---|---|---|
| New purpose | Customer data reused for analytics | Reassess risks and lawful basis |
| New data or scale | Adding health or location data | Rescore and add measures |
| New supplier or transfer | Moving to a new cloud region | Check contracts and safeguards |
| Incident or complaint | A breach or repeated data subject complaints | Review measures and root cause |
| Scheduled review | Annual check | Confirm nothing has drifted |
List the events that force a review and connect them to your change management. Typical triggers are a new purpose, a new category of data, a new processor or transfer destination, a change in technology, a change in the people affected, a security incident and a change in the law or in regulator guidance. Any one of them can alter likelihood or severity.
Make the trigger practical. Add a short question to your project and change forms: does this alter how personal data is collected, used, shared or kept? If yes, the DPIA owner must be notified. Without that link, changes happen quietly and the review never starts. Our guide to when a DPIA is required helps you spot changes large enough to need a new assessment rather than a review.
Give ownership to the person accountable for the processing, usually the business or product owner, with the DPO advising. The DPO should not own the outcome, because Article 39 gives the DPO a monitoring and advisory role, not the job of making decisions for the controller. Record who is responsible for each review and when it is due.
Keep a simple register of live DPIAs with their next review date, owner and status. Report overdue reviews to a governance forum. Overdue reviews are a leading indicator that the programme is drifting, and they are easy to spot once the register exists.
A review does not have to be long. Work through a short set of questions and record the answers.
Every review should produce a dated record, even when nothing has changed. A line such as “reviewed on 12 March, no material change, measures confirmed, next review March next year” is enough for a low-change system. Where risks or measures change, update the DPIA itself, keep the earlier version and note what changed and why.
Where the review shows a higher residual risk, take the decision seriously. Depending on the change, you may need to add measures, pause the change or consult the supervisory authority under Article 36, as covered in DPIA prior consultation. Update the residual risk assessment and record who accepted it.
Free DPIA template and tool
Does this processing need a DPIA, and what would it say?
Screen the processing against Article 35 and the nine WP248 criteria, describe it, test necessity and proportionality, rate the risks to the people concerned and record the DPO's advice and sign-off. Free, with findings and the Article 36 check.
Monitoring is the day-to-day side of the same idea. Some measures produce their own signals: access logs, retention job reports, complaint counts, training completion and supplier audit results. Pick a few indicators that show whether each key measure is working, and check them on a regular rhythm.
If an indicator turns red, do not wait for the next scheduled review. Investigate, fix, and record the finding. A short monthly dashboard for higher-risk processing is usually proportionate and gives early warning.
A DPIA does not sit alone. Feed the outcome of each review into your risk register, your record of processing and your privacy notices, so that all three describe the same reality. For high-risk automated systems, connect it with AI-related DPIAs and with the core DPIA guide that explains the full process. If a review reveals a mismatch between a DPIA and a legitimate interests balancing test, compare them using DPIA vs LIA.
Report review results to whoever governs privacy in your organization: a privacy committee, risk forum or the board. A short summary showing the number of live DPIAs, reviews completed on time, changes made and any residual risks accepted is enough. It keeps DPIA review and monitoring visible and gives leaders the information they need to fund the follow-up work.
Finally, learn from the reviews. If the same trigger keeps appearing, such as supplier changes, improve the upstream process. If the same measure keeps failing, redesign it. Continuous improvement turns the review from a compliance chore into a genuine control.
Frequent errors include treating the DPIA as a launch gate only, having no register of DPIAs, allowing reviews to lapse, updating the document without keeping the old version, and failing to connect incidents to the assessment. Another is reviewing only paperwork and never checking that measures work in practice.
Also avoid over-engineering. A heavy review process for a low-risk system wastes effort and encourages people to skip it. Match the frequency and depth to the risk, and revisit that judgement each year. See our DPIA example for how a completed assessment and its review notes fit together.
A bank runs a DPIA for a fraud-scoring model. At the annual review the owner notes that the model now uses device data as well as transaction data. That is a new category and a change in scale, so the team rescores the risk, adds a measure limiting retention of device identifiers and updates the privacy notice. The DPO records advice, the owner signs off and the next review date is set.
Six months later a supplier change triggers an interim review, which confirms that the contract and transfer safeguards still hold. The process is light, dated and easy to follow, which is precisely what good DPIA review and monitoring looks like.
If you want the assessment, the review log, measures and residual risk in one place, the DPIA Report and Workbook provides a structured report and workbook that supports version control and dated reviews. Whichever format you use, make DPIA review and monitoring a routine part of running the processing, not an afterthought.
The law requires a review at least when the risk changes. Many organizations also review high-risk processing annually and use event-driven reviews for changes and incidents.
The accountable business or product owner, with advice from the DPO. Record the owner and next review date in a register.
Not always. Small changes need a documented review. A significant new purpose, data type or technology may need a new or substantially updated assessment.
Add measures, reconsider the change or consult the supervisory authority if the residual risk remains high. Record the decision and who accepted it.
Yes. Keeping earlier versions with dates lets you show how the assessment evolved and why decisions were made.
September 30, 2026
