When Article 35 makes an assessment mandatory, what it has to contain, and how to evaluate the tools that claim to run one.
DPIA software supports the Data Protection Impact Assessment that GDPR Article 35 requires before processing likely to result in a high risk to people's rights and freedoms. A useful tool does three things a template cannot: it screens processing against the Article 35 triggers so assessments open when they should rather than when someone remembers, it grounds the assessment in what the system actually does rather than in a form someone fills from memory, and it tracks the mitigations through to done. Judge candidates on whether the assessment can be reopened when the processing changes, and whether residual high risk visibly routes to the Article 36 consultation step.
Most DPIA failures are omissions. Look for a tool that evaluates new or changed processing against the Article 35 triggers and your authority's published list, and that records the screening decision even when the answer is no — the reasoning is part of your accountability evidence.
A DPIA written from a questionnaire captures what the author remembered. A DPIA that pulls in the actual data categories, recipients, transfers and retention from your data map starts from facts and spends its effort on judgement instead of discovery.
Check the scoring model. If it only offers likelihood against business impact, it will systematically under-rate harms like discrimination, loss of control over personal data or physical safety, which is the entire point of the exercise.
Identified measures that live only inside a document are not measures. The tool should carry each mitigation as tracked work with an owner and a residual-risk rating recorded after it lands, not before.
A DPIA is a living record. Adding profiling, a new data source or a new transfer should reopen the assessment rather than leave a stale one on file. Ask what triggers a re-review and whether the history is preserved.
Four shapes of vendor, described by category rather than by name. Which one fits depends on how fast your systems change and how much judgement you need to buy in.
Large, modular GRC platforms that cover most regimes through separately licensed modules, usually with a long implementation and a dedicated administrator.
Best fit: Large organisations with a compliance team big enough to own configuration, and budget that tolerates a multi-module licence.
Focused products that do one job well — consent, DSAR intake, cookie scanning, vendor questionnaires — and integrate loosely with whatever else you run.
Best fit: Teams with one acute, well-bounded problem, who accept that the register tying everything together lives somewhere else.
People rather than software: an external DPO or advisory retainer that produces the documentation on your behalf, often in documents you then own.
Best fit: Organisations without in-house expertise who need judgement more than tooling, and who can accept that the output is a snapshot.
Systems that connect to what you already run, derive the records from live signals, and keep them current between audits rather than regenerating them before one.
Best fit: Teams whose systems change faster than documents can be maintained by hand, and who need to evidence a current state on demand.
Noru opens the right assessment on its own: because the data map knows what a system processes, changes that cross an Article 35 trigger surface as an assessment to run rather than waiting for someone to notice.
Assessments start from the evidence already in the programme — data categories, recipients, transfers, retention — so the work spent is on necessity, proportionality and risk rather than on rediscovering what the system does.
Mitigations become tracked work with owners, residual risk is recorded after the measure lands, and the whole assessment is versioned so you can show what was known and decided at any point in time.
Whenever processing is likely to result in a high risk to individuals' rights and freedoms. Article 35(3) names three cases explicitly: systematic and extensive automated evaluation producing legal or similarly significant effects, large-scale processing of special-category or criminal-offence data, and systematic monitoring of publicly accessible areas on a large scale. Supervisory authorities also publish their own lists.
A systematic description of the processing and its purposes, an assessment of necessity and proportionality, an assessment of the risks to data subjects, and the measures envisaged to address those risks including safeguards and security measures.
The controller. The DPO must be consulted and their advice recorded, and processors are required to assist, but accountability for the assessment and for the decision to proceed sits with the controller.
Article 36 requires prior consultation with the supervisory authority before the processing begins. The authority can advise and, in the extreme, use corrective powers to prevent the processing.
A DPIA is the specific instrument defined by the GDPR, with mandatory content and a consultation duty attached. Privacy impact assessment is the broader generic term. If you fall under the GDPR, it is the DPIA requirements you have to meet.
A template is fine for a handful of assessments a year. It breaks down when you need to prove that every high-risk change was screened, that mitigations were actually implemented, and that the assessment reflects the system as it is now rather than as it was at launch.
Regulatory references on this page were last checked on .
A 45-minute walkthrough against your frameworks, your integrations and your evidence.
