ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
DPIA mitigation measures are the part of a data protection impact assessment that changes what actually happens to people’s data. Article 35(7) of the GDPR requires a DPIA to describe the measures envisaged to address the risks, including safeguards and security measures, and a DPIA that lists risks without credible measures is only half finished.
This guide explains the main types of mitigation, how to choose measures that fit the risk, how to assign owners and evidence, and how to show that the residual risk is acceptable. It is general information, not legal advice.
Good DPIA mitigation measures share four traits. They are specific, so a reader knows exactly what will be done. They are linked to a named risk, so it is clear why the measure exists. They have an owner and a date. And they can be verified, so someone can check that they work. “Improve security” fails all four tests. “Encrypt the customer database at rest by 30 June, owned by the head of infrastructure” passes.
Measures should also be proportionate. A small internal tool does not need the controls of a national health service. Match the effort to the score from your DPIA risk scoring and be ready to explain why the chosen measures are enough.
Technical controls reduce the chance or the impact of harm through the design of the system. Common examples include encryption in transit and at rest, pseudonymisation or anonymisation of data used for analysis, role-based access, multi-factor authentication, logging and monitoring, secure deletion and separation of environments.
Choose them by asking what could go wrong with this data and how a control would stop it. If the risk is exposure through a lost laptop, disk encryption helps. If the risk is misuse by staff, access limits and logging help. If the risk is re-identification, stronger anonymisation helps. Link each measure to the risk it addresses so reviewers can follow the logic.
| Type | Examples | Typical risk reduced |
|---|---|---|
| Technical | Encryption, pseudonymisation, access controls, logging | Unauthorised access, exposure |
| Organizational | Policies, training, approval workflows, retention rules | Misuse, over-retention |
| Legal and contractual | Processor contracts, transfer safeguards, clear notices | Unlawful sharing, lack of transparency |
| Design choices | Data minimisation, on-device processing, opt-outs | Excessive collection, loss of control |
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.
Organizational measures cover people and process: policies, training, approval steps, supplier checks, incident procedures and retention schedules. They matter because technical controls fail when people do not know how to use them or when nobody owns them.
Examples include requiring approval before new data uses, training the staff who handle sensitive records, setting a retention limit with automated review, and defining who decides on data subject requests. For higher-risk processing, add independent review, such as the involvement of the DPO covered in consulting the DPO and data subjects.
Contracts, notices and lawful transfer mechanisms are also mitigation. A processor agreement with security and audit clauses reduces supplier risk. A clear privacy notice and an accessible opt-out reduce the risk of people losing control. Transfer safeguards reduce the risk of access by foreign authorities, as discussed in international data transfers.
For processing involving children, transparency measures carry extra weight. See DPIAs for children’s data for age-appropriate design and how consent can be verified, including verifiable parental consent.
The most effective DPIA mitigation measures often remove the risk rather than manage it. Collect less data. Keep it for a shorter time. Process it on the device rather than in a central store. Aggregate before analysing. Use a less intrusive alternative. Each of these reduces both likelihood and severity because there is simply less to go wrong.
Encourage project teams to ask early whether the purpose can be achieved with less. If the answer is yes, record the change as a measure. That kind of decision is far cheaper before build than after launch, which is one reason DPIAs are best started at the design stage.
For each measure, record who is responsible, when it will be in place and what evidence will show it works. Evidence might be a configuration screenshot, a test report, a signed contract, a training log or a policy approval. Without evidence, a measure is only an intention, and it should not reduce the residual score.
Track measures in a register and review it until everything is closed. If a measure slips, re-score the risk and decide whether the processing can start. A DPIA that lists measures nobody completes is worse than none, because it creates a false record of protection.
Once measures are in place, re-score the risk. The result is the residual risk, and the DPIA should show why it is acceptable. If it remains high, Article 36 requires you to consult the supervisory authority before processing, as described in DPIA prior consultation.
The decision-maker should see both the measures and the remaining risk in plain terms: what we are doing, what could still happen and why we accept it. Record the DPO’s advice and the approval date. If the advice was not followed, record why.
Not every measure can be delivered at once, so rank them. Start with those that address the highest residual risks and those that are cheap and quick, such as changing a default setting or shortening a retention period. Then schedule the larger items, such as a new access-management tool, with clear milestones. Explain the order in the DPIA so a reviewer can see that the sequence was deliberate.
If a high-impact measure cannot be delivered before launch, consider a phased release: start with a smaller group, less data or a limited purpose until the control is ready. That approach often reduces risk faster than waiting for perfection, and it gives you real-world evidence of how the measures perform.
Measures decay. Access lists grow, retention jobs fail and training lapses. Build a light check into your operations: a quarterly confirmation from each owner that the measure is still in place, plus a spot test by the privacy or security team. Record the result. If a measure has failed, treat it as an incident and re-score the risk.
Link the DPIA to your change process so that any significant change to the system triggers a review of the measures. Adding a new data source, a new processor or a new purpose will usually change the risk picture, and the mitigation should change with it.
Typical problems include listing measures that are already in place as if they were new, crediting controls that are not tested, using vague verbs such as “consider” or “review”, and copying a generic list into every DPIA. Another is forgetting that measures can create new risks: extra monitoring of staff to protect data may itself raise privacy concerns.
Also avoid treating mitigation as a one-off. Systems change, suppliers change and threats change. Set a review date for the DPIA and revisit the measures when the processing changes. A worked case appears in our DPIA example.
Suppose a company introduces video interviews with automated scoring. Risks include bias, lack of transparency and long retention of recordings. DPIA mitigation measures could include human review of every automated score, a clear explanation to candidates, testing for disparate outcomes, deleting recordings after a short period, and restricting access to named recruiters.
Each measure is assigned to an owner: HR for the explanation and retention, the vendor for testing, security for access. The residual risk is then re-scored and approved. The same pattern works for any project, from a new CRM to a wearables programme.
If you want a report that carries risks, DPIA mitigation measures, owners, evidence and residual risk in one place, the DPIA Report and Workbook gives you a structured layout aligned with the ICO guidance on DPIAs and the regulation. Whatever you use, the goal is the same: measures that are specific, owned, evidenced and proportionate.
Examples include encryption, pseudonymisation, access controls, shorter retention, staff training, processor contracts, clearer notices and design changes that collect less data.
Measures that the risk depends on should be in place, or firmly scheduled, before processing begins. Do not credit a measure that has no owner or date.
A named person for each measure, typically the business or system owner, with the DPO advising and reviewing rather than delivering them.
Yes. For example, extra monitoring can affect staff privacy. Consider side effects and re-score the risk after adding measures.
Keep evidence such as test results, configurations, signed contracts and training records, and review them on a schedule.
September 30, 2026
