DPIA Builder
Work through a data protection impact assessment: screen whether one is needed, score each risk before and after controls, track who owns what, and print the assessment as a document. Runs entirely in your browser. Nothing is uploaded.
Version 1.0.0 · Updated Aug 20, 2026
Use DPIA Builder now
Runs in your browser · nothing is uploaded
This in-page version cannot save your work between visits — browser storage is switched off inside the sandbox. The full version saves your work locally after download.
Overview
Frequently asked questions
How does the DPIA Builder licence work?
It is a one-time purchase for a downloadable tool — no subscription. You buy it once and the file is yours to keep and use.
Can I try the DPIA Builder before buying?
Yes. Use the Try online button for a fully interactive demo with sample data already loaded — nothing to install and nothing is saved.
Can I import my data from a spreadsheet?
Yes. Use the Spreadsheet template button to save a CSV with the right headings, fill it in Excel or any spreadsheet, then Import spreadsheet to load it back. The file is read in your browser — nothing is uploaded.
Does my data stay private?
Yes. The tool is a single HTML file that runs entirely on your computer and makes no network requests, so nothing you enter is ever uploaded or shared.
Do I need Excel or any other software?
No. It replaces the spreadsheet template entirely: open the file in your browser (Chrome, Edge, Firefox or Safari) on Windows, Mac, Linux or a tablet, and start working.
How to use DPIA Builder
The complete in-tool guidance, reproduced here so you can read it before you download.
What this tool does
CM8-351 walks you through a data protection impact assessment and produces the document at the end of it. You describe the processing and answer nine screening questions on the Settings tab, then record each risk to people, score it before and after the controls you intend to put in place, and give every control an owner and a date. The tool totals the reduction, flags anything still high, and prints the whole thing as an assessment.
Everything runs inside this single file — no account, no upload, no network request of any kind. An assessment describes your weakest points in handling other people's data, which is not a document to leave on somebody else's server while you are still working on it.
Screening: is one needed?
The nine checkboxes on the Settings tab are the criteria that appear, in one form or another, in most data protection regimes: large scale, sensitive data, vulnerable people, automated decisions, systematic monitoring, new technology, matching data sets, denial of a service, and transfer to another country.
The common rule of thumb is that two or more means a formal assessment is expected, and one means you should record your reasoning either way. That is a rule of thumb and not the law anywhere in particular — some regimes publish their own list of processing that always requires one.
Fill this in even if you already know you are doing the assessment. The screening table prints with the document, and "we did this because four criteria applied" is a better opening than a form that starts in the middle.
Describing the processing
Four fields, and the discipline is in keeping them specific:
- What is being assessed — the processing operation, not the project. "Recording customer service calls", not "Phase 2 of the contact centre programme".
- Why — the purpose in one line, as you would explain it to the people affected. If it takes a paragraph, there is probably more than one purpose and they may need assessing separately.
- Whose data — customers, employees, applicants, members of the public. This is what decides whose interests you are weighing.
- How long it is kept — a period and a trigger. "Twenty-four months from the end of the contract" is a retention rule. "As long as necessary" is not, and writing it down usually reveals that nobody has ever decided.
What one row is
One row is one risk to people, not one control. A single risk may need three controls and they all go in one row; two different harms arising from the same feature are two rows, because they will score differently and may be owned by different people.
Risk to people, not risk to you
This is the distinction that separates a real assessment from a compliance exercise. The question is not "what could go wrong for us" but "what happens to a person if this goes wrong".
"Regulatory fine" is not a harm to a person. "Card fraud", "a conversation filed against a stranger's record", "distress at having been recorded without knowing", "unable to get a copy of their own data" — those are harms to people. The What actually happens to somebody field is deliberately required and deliberately short, because a risk you cannot express as a sentence about a person is usually a risk nobody has thought through.
Organisational consequences follow from harms to people; they are not a substitute for them.
How the scoring works
Risk = likelihood × severity Likelihood 1 remote · 2 possible · 3 likely · 4 almost certain Severity 1 minor annoyance · 2 inconvenience people can overcome 3 significant harm — money, reputation, distress 4 severe or irreversible harm Range: 1 to 16
Severity is judged from the point of view of the person affected, and the scale is written that way on purpose. A leak that would embarrass your organisation but cost an individual nothing is a 1 or a 2 however uncomfortable it would be for you.
The high threshold defaults to 9, which is "likely and significant", or "almost certain and inconvenient". Move it if your organisation bands risk differently — the ranking is what matters more than the number.
Before and after controls
Score the risk twice: as it would be with no controls at all, and as it will be once the controls in the row are actually in place.
Two rules the tool enforces. A control cannot make a risk more likely or more severe, so the after scores cannot exceed the before scores. And a risk still marked "identified" carries its full inherent score into every total, because a control nobody has designed reduces nothing. That is why the tiles can show a large number of identified risks and a small reduction — which is the honest picture of an assessment that has been started and not finished.
Be careful about which axis a control moves. Most controls reduce likelihood. Very few reduce severity, because severity is about what happens to the person once it has gone wrong. Pause-and-resume on a payment step genuinely reduces severity — the card data is not there to leak. An access log does not: it makes misuse easier to detect, not less harmful. Assessments that show severity falling everywhere are usually wrong.
High residual risk
A risk still in the High band after controls is the most important output of the whole exercise, and the tool flags two versions of it separately: still high after controls, and high risk accepted.
In several regimes a high residual risk cannot simply be accepted — the supervisory authority must be consulted before the processing starts. Whether that applies to you, and what the threshold is, depends on where you are. What is true everywhere is that accepting a high risk is a decision a named person should make in writing, and the sample assessment has one in it that has not been signed off, so you can see how it reads.
Status, and when an assessment is finished
- Identified — the risk is written down and nothing has been designed. Carries its full inherent score.
- Planned — a control exists on paper, with an owner and a date. Flagged if the date has passed or nobody owns it.
- Implemented — the control exists in reality. This is the only status that should be set after somebody has checked.
- Accepted — the residual risk stands, and somebody has decided that is acceptable.
- Removed — the processing was changed so the risk no longer exists. The cheapest control there is, and the most under-used: the sample includes a feature switched off rather than controlled.
An assessment is not finished when the document is written. It is finished when the controls it promised exist, which is why the status chart is in the report.
Keeping it alive
Revisit the assessment when the processing changes — a new data field, a new supplier, a new country, a feature switched on — and when a control that was planned becomes real. An assessment that describes what you intended to do two years ago is worse than none, because it will be produced as evidence of something that is not true.
What this is not
- It is not legal advice and it is not a template approved by any authority.
- It does not decide whether an assessment is legally required. The screening is a prompt.
- It does not tell you whether a lawful basis exists, and it does not record one — that belongs in the record of processing, which is a different document.
- It does not consult anybody. Where a regime requires consultation with a supervisory authority, a data protection officer, or the people affected, that is a real step outside this tool. The Settings tab records only whether an adviser has reviewed it.
- It does not sign anything. An assessment nobody accountable has signed is a draft.
Printing the assessment
The Report tab is the document: the description you entered, the screening table, the risk treatment plan and the charts, with a title block you fill in. Print it, get it signed, and keep it with the version of the processing it describes.
Saving your work
The assessment is held in this browser, on this computer, and stays there between visits. Use the backup button to write a JSON file you control — that file is the only copy that survives clearing browsing data or moving to a new machine.
Accuracy & disclaimer
Every score here is a judgement you made, and the tool multiplies and adds them exactly as entered. It has no view about whether your controls work, whether your retention period is defensible, or whether your processing is lawful. Where the law requires a particular form, a particular consultation or a particular sign-off, the law is what applies, not this document.
Where this fits
Part of Privacy & Data Protection in Governance, Risk & Compliance.
Before this tool
Related tools
Build a register of processing activities: purpose, data subjects, data categories, lawful basis, retention, transfers and impact assessments, with a gap list and a printable report. Runs entirely in your browser — nothing is uploaded.
Log personal data breaches against the clock: hours from awareness to containment and to report, a likelihood-and-severity risk rating, deadline tracking and a printable register. Runs entirely in your browser. Nothing is uploaded.
Record every gift and hospitality item given or received, test each one against your own approval and prohibition thresholds, and catch the cumulative annual total from a single counterparty that item-by-item checks always miss. Runs entirely in your browser — nothing is uploaded.
Keep a project and business risk register — strategic, financial, operational and compliance risks scored on a 5×5 grid, inherent and residual, with the four responses and a board-ready report. Not a workplace safety assessment. Nothing is uploaded.
Plan the year's internal audits — one row per planned audit, with risk-based frequency, auditor independence, planned against actual dates, deferral reasons and a coverage check that shows which high-risk processes are under-audited; for conducting the audits themselves use the internal audit checkl
Track internal audit findings from report to closure — owners, due dates, extensions, overdue ageing and closure statistics, with a report ready for an audit committee. Runs entirely in your browser. Nothing is uploaded.