DPIA Software

DPIA software is the tool a privacy team uses to run the Article 35 Data Protection Impact Assessment required by the EU and UK GDPR. Useful DPIA software does more than fill in a template — it works the substance of the necessity-and-proportionality assessment, records where each answer came from, and keeps a named human accountable for the sign-off. That distinction — a tickbox form versus a defensible decision record — matters when someone asks why processing went ahead and what evidence supported the decision. This guide covers what DPIA software is, why it is a legal requirement, how it works, and what to check before choosing a tool.

DPIA software turns Article 35 work into defensible decisions

DPIA software runs the Data Protection Impact Assessment — the structured evaluation the GDPR requires before processing that is likely to result in a high risk to individuals. A blank Word template can capture answers, but it stores only what someone last typed. DPIA software treats each assessment as a governed decision record: it carries the systematic description of the processing, the necessity-and-proportionality reasoning, the risks to individuals and their likelihood and severity, the mitigating measures, the recorded DPO advice and a named approver — and it knows where each of those answers came from.

That provenance is the point. When the Data Protection Commission (DPC) in Ireland or the Information Commissioner's Office (ICO) in the UK looks at a project file, the question is not “do you have a DPIA document” but “can you show the assessment was defensible, dated before the processing, and acted on.” Acompli treats the completed DPIA as source evidence rather than a one-off form: the approved assessment becomes a record that can be reused when the activity changes, a regulator asks, or a similar project starts later.

When is a DPIA required?

A DPIA is required before any processing “likely to result in a high risk to the rights and freedoms of natural persons” — Article 35(1) of the EU and UK GDPR. Article 35(3) then names three cases where one is required in particular; the list is illustrative, not exhaustive, so the practical first question a tool should answer is whether a project crosses the high-risk threshold at all.

The three Article 35(3) cases:

1. Systematic and extensive evaluation or profiling by automated processing that produces legal or similarly significant effects for individuals.
2. Large-scale processing of special-category data (Article 9) or of personal data relating to criminal convictions and offences (Article 10).
3. Systematic monitoring of a publicly accessible area on a large scale.

Beyond those cases, the Article 29 Working Party's nine criteria (WP248 rev.01, endorsed by the EDPB) are the working test for “likely high risk”: in most cases a combination of two of the nine indicates a DPIA is needed, and in some cases one is enough. The nine are evaluation or scoring; automated decision-making with legal or similar effect; systematic monitoring; sensitive or highly personal data; large-scale processing; matching or combining datasets; data concerning vulnerable individuals; innovative use of new technology; and processing that prevents individuals exercising a right or using a service.

Each regulator also publishes its own list. Under Article 35(4) the Data Protection Commission (DPC) has adopted a list of ten types of processing operation that require a DPIA in Ireland where a screening assessment indicates likely high risk; the Information Commissioner's Office (ICO) publishes its own screening criteria for the UK. The defensible pattern is the same in both jurisdictions: a recorded threshold screen first— a short check against these triggers — and a full Article 35(7) assessment only where the screen indicates high risk. Acompli runs that screen as the first step, so a borderline project gets a documented decision on whether a DPIA is required rather than a guess, and the triggers are logged for audit-readiness. See the DPIA requirements guide for Ireland and the UK for the underlying detail.

DPIA software compared to a Word template and a generic GRC form

Most teams run a DPIA in one of three ways. The important difference is whether the assessment can show where each answer came from and who approved it when a supervisory authority opens the project file.

Acompli is the right-hand column: the DPIA drafts with per-field citations and a named human approves the outcome, so the assessment is a defensible decision record rather than a document that records only what someone last typed.

The DPIA workflow in practice

The strongest DPIA software runs the assessment as a controlled workflow, so the substance is worked rather than improvised in a blank document. In Acompli the pipeline runs in four governed stages:

• Screen: a structured template asks the Article 35(3)/(4) trigger questions first, so borderline projects get a documented decision on whether a DPIA is required rather than a guess.
• Draft: the assessment starts from an Article 35(7) template and draws context from the organisational knowledge base; evidence-grounded AI drafting maps responses to each field with a per-field citation back to the source it came from.
• Review: drafted answers enter a review queue where a named person can trace every field to its evidence, weigh the necessity-and-proportionality reasoning, and approve, edit or reject it before sign-off.
• Carry through: approved findings flow downstream — into the Article 30 RoPA, the risk register and vendor reviews — and the assessment surfaces for re-review when an upstream fact changes.

This is the honest meaning of “DPIA automation”: automation reduces the typing, the chasing and the re-keying, not the accountability. Acompli's AI drafts, classifies and surfaces; a person approves the outcome, the residual-risk and DPO-advice decisions are recorded rather than assumed, and nothing publishes itself. (See the Acompli DPIA module for how the workflow runs in the platform.)

What to look for in a DPIA platform

Whatever the vendor, assess whether the tool can preserve the reasoning, evidence and approvals behind the assessment. The criteria that matter:

• Full Article 35(7) coverage — the systematic description of processing, the necessity-and-proportionality assessment, the risks to individuals, and the measures that address them, as distinct fields rather than one free-text box.
• Screening against the regulator's high-risk list — the Article 35(4) operations the DPC publishes for Ireland and the ICO's screening checklist for the UK, with the EDPB nine-criteria test applied.
• Evidence traceability — every answer links back to the source response, system or contract that produced it, so a claim can be substantiated, not just asserted.
• Recorded DPO advice — the Article 35(2) consultation captured as a dated decision, not an afterthought.
• Reviewer-attributed version history — what changed, who changed it, who approved it, and when.
• An Article 36 prior-consultation trigger — where a high residual risk remains after mitigation, the tool should flag the prior-consultation workflow rather than let the project proceed silently.
• Downstream connections — approved outputs carried through to the Article 30 RoPA and the risk register, with a Schrems II transfer flag routing affected processing to a Transfer Impact Assessment.
• A self-contained export — a record the DPC or ICO can read without a login to your platform.

For a structured side-by-side of DPIA tools against these criteria, see DPIA tools compared for Irish organisations. Acompli is built to each of these criteria: structured Article 35(7) fields, screening against the DPC and ICO lists, per-field evidence citations, recorded DPO advice, an Article 36 trigger on high residual risk, and approved findings that flow to the Article 30 RoPA and risk register.

Which type of DPIA software fits you?

Teams choosing a DPIA tool meet four broad types. The right one turns less on feature count than on whether the finished assessment is a defensible Article 35 decision record a regulator can follow.

Who needs DPIA software?

Any organisation that runs processing likely to result in a high risk to individuals needs a DPIA. Privacy and DPO functions use DPIA software to make that assessment guided and repeatable; larger groups need entity-scoped assessments so each subsidiary can show its own supervisory authority a defensible record. The same evidence model also supports related LIAs, TIAs and EU AI Act work. In Acompli those assessments share one workflow and knowledge base, so a DPIA, LIA or TIA reuses the same approved evidence and approval trail rather than starting from a blank form.

Common questions about DPIA software

Primary sources

1. GDPR Articles 35 and 36 (EUR-Lex, Regulation (EU) 2016/679)
2. DPC — Guide to Data Protection Impact Assessments
3. ICO — Data Protection Impact Assessments (DPIAs)

Related research

Related Acompli workflows

Pricing scales with your compliance estate — data controllers, legal entities, jurisdictions and integrations — never a per-seat price. See Acompli pricing.