Privacy Risk Register Template
Privacy Risk Register Template
The fields a defensible data protection risk register should contain — and why each one is what a DPC or ICO review tests under Article 5(2) accountability.
A privacy risk register template is the structured set of fields a data protection risk register should contain so an organisation can show — under the GDPR's Article 5(2) accountability principle — how it identifies, scores, treats and reviews the risks in its processing. Unlike the Article 30 RoPA, the GDPR does not prescribe a fixed list of register fields, so the set below is best practice rather than statute — the practical fields the Data Protection Commission (DPC) and Information Commissioner's Office (ICO) expect to see when they ask how a risk was managed. Getting the fields right is the easy half: a register is only useful if each risk traces back to the assessment that raised it and stays current as controls change.
Key takeaways
- There is no statutory ‘risk register’ in the EU or UK GDPR, but Article 5(2) accountability and Article 35 DPIA follow-up mean you must be able to demonstrate how risks are identified, rated and treated — the register is that evidence.
- The core of every entry is two scores: inherent risk (before controls) and residual risk (after), so the value of the mitigation is visible.
- Each risk should trace to its source — the DPIA, LIA, TIA or activity that raised it — and carry a named owner and review date.
- A spreadsheet captures the fields but not the provenance; keeping the register current between audits is what a DPC or ICO review actually tests.
What fields must a privacy risk register include?
Because no article fixes the columns, a good template starts from what the accountability principle has to be able to show. A defensible data protection risk registerrecords, for each risk:
- Risk reference and source — a unique ID and the assessment, activity or system that raised it (a DPIA, legitimate-interests assessment, transfer impact assessment or vendor review).
- Risk description — the processing and the specific risk to individuals' rights and freedoms.
- Affected individuals — whose data is in scope (employees, customers, vulnerable groups) and which rights are at stake.
- Inherent risk — the likelihood and severity of the risk before any controls.
- Existing controls — the technical and organisational measures already in place.
- Treatment plan — the strategy (mitigate, avoid, transfer or accept), the named owner, the actions and the due date.
- Residual risk — the likelihood and severity that remain after the planned controls.
- Links — to the related Article 30 RoPA entry, system, vendor or international transfer the risk relates to.
- Review — the owner, the last-reviewed and next-review dates, and the status (open, in treatment, mitigated, accepted or closed).
| Register field | What it records | Why a regulator looks for it |
|---|---|---|
| Source / reference | The assessment or activity that raised the risk | Shows the risk was identified through a process, not guessed |
| Inherent risk | Likelihood × severity before controls | Establishes the starting exposure being managed |
| Controls & treatment | Measures in place + the plan, owner and due date | Evidences that identified risks are actually being acted on (Art 35(7)(d)) |
| Residual risk | Likelihood × severity after controls | Shows whether the remaining risk was judged acceptable, or escalated |
| Links | To the RoPA entry, system, vendor or transfer | Connects the risk to the processing it belongs to, not a standalone list |
| Review | Owner, review dates and status | Demonstrates the register is current, not a stale snapshot (Art 35(11)) |
Inherent vs residual risk: the two scores that matter
The heart of a risk register is two ratings, not one. Inherent risk is the likelihood and severity of harm to individuals before any controls are applied; residual riskis what is left after the planned technical and organisational measures. Recording both is what makes the value of the controls visible — a single score hides whether a high-risk activity has been brought under control or simply written down. Under Article 35(7) the residual rating is a reasoned decisionrecorded with its evidence, not a number a tool generates on its own; where a high residual risk remains after mitigation, Article 36 prior consultation with the supervisory authority may be triggered. For the underlying obligation and when a DPIA is required in the first place, see the DPIA guide.
Is a spreadsheet template enough?
A spreadsheet is a reasonable way to capture the fields, and for a very small, stable organisation it can be the whole record. Its limit is not the columns but the provenance: a spreadsheet stores only what someone last typed, and it cannot show where a score came from, who approved the treatment, or what changed since the last review. Those are the first questions a DPC or ICO review asks, and a register that has drifted out of date reads as weak Article 5(2) accountability rather than control.
The practical move is to keep the same fields but manage them as a governed registerrather than a static file — one that keeps each risk's source assessment, approval chain and version history, and surfaces entries for review when the business changes. That is what the Acompli risk management module does, and what to look for in a tool is covered in privacy risk management software: what it is and what to look for.
How do you build and maintain a privacy risk register?
Filling the register once is straightforward; keeping it accurate is the real work. A workable approach runs in four steps:
- Derive risks from assessments: take each risk from the DPIA, legitimate-interests assessment, transfer impact assessment or vendor review that raised it, rather than from a blank page, so each entry can be substantiated.
- Score inherent and residual separately: record likelihood and severity before and after the planned controls, so the mitigation's value is explicit.
- Assign a treatment plan and owner: give each risk a strategy, a named owner and a due date, recorded as a reasoned decision.
- Review on a schedule and on change: re-open the affected entries when the processing, a control, a vendor or a transfer changes — Article 35(11) expects a review at least when the risk changes.
This is where software earns its place over a file. In Acompli, approved assessments feed an AI extraction step that drafts and scores candidate risks with a link back to the source response, and a named reviewer accepts, adjusts or rejects each one before it enters the register — the AI drafts and surfaces; a person approves, and nothing publishes itself.
Common questions about the privacy risk register
What fields must a privacy risk register include?
Unlike the Article 30 RoPA, the GDPR does not prescribe a fixed field list for a risk register, so the fields are best practice rather than statute. A defensible register records, per risk: a reference and its source (the DPIA, LIA, TIA, activity or vendor review that raised it); a description of the risk to individuals' rights and freedoms; the affected individuals; the inherent risk (likelihood and severity before controls); the existing technical and organisational controls; a treatment plan (strategy, named owner, actions and due date); the residual risk after the planned controls; links to the related Article 30 RoPA entry, system, vendor or transfer; and a review record (owner, last-reviewed and next-review dates, and status). The point is not the columns but that each value can be substantiated and kept current.
Is a privacy risk register legally required under the GDPR?
There is no standalone statutory duty to keep a 'risk register' in either the EU or UK GDPR. What the law requires is the ability to demonstrate it: the Article 5(2) accountability principle means a controller must be able to show how data protection risks are identified, rated and treated, and Article 35(7) requires a DPIA to record an assessment of the risks and the measures to address them, with Article 35(11) requiring a review at least when the risk changes. A documented, current risk register is the practical evidence of that accountability — which is why the DPC and ICO expect to see one even though no article names it.
What is the difference between inherent and residual risk?
Inherent risk is the likelihood and severity of the risk to individuals before any controls are applied; residual risk is what remains after the planned technical and organisational measures. Recording both — rather than a single score — is what makes the value of the controls visible and lets a reviewer judge whether the residual level is acceptable or whether further mitigation, or Article 36 prior consultation, is needed. Under Article 35(7) that residual rating is a reasoned decision recorded with its evidence, not a number a tool produces on its own.
Is a spreadsheet risk register enough?
A spreadsheet captures the fields and, for a very small and stable organisation, can be the whole record. Its limit is provenance: it stores only what someone last typed and cannot show where a score came from, who approved the treatment, or what changed since the last review — the first questions a DPC or ICO review asks. A register that has drifted out of date reads as weak Article 5(2) accountability rather than control. The fields are the same; a governed register keeps each risk's source assessment, approval chain and version history, and surfaces entries for review when the business changes.
Primary sources
Related research
Privacy Risk Management Software
What privacy risk software is, how assessment-fed risk extraction works, and what to look for in a tool.
Read article →DPIA Guide
When a DPIA is required under Article 35, and how its risks feed the register.
Read article →Transfer Impact Assessments
The Schrems II method behind transfer risk — mechanism, safeguards and residual exposure.
Read article →