ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
A privacy risk register records the ways your processing could harm the people whose data you hold, how likely each harm is, how severe it would be and what you are doing about it. It sounds like a security register with a different label, but the difference matters: the risk it tracks is to individuals, not to the organization. A breach that costs you little may still do serious damage to the people affected, and a register that only counts your own losses will miss it.
This guide covers what belongs in a privacy risk register, the twelve fields that make it useful, how to score harm using the categories in the GDPR, how it connects to data protection impact assessments and treatment plans, and how to keep it current.
The GDPR takes a risk-based approach. Controllers must apply measures that reflect the likelihood and severity of risk to the rights and freedoms of individuals, and processing likely to result in a high risk triggers a data protection impact assessment. Recital 75 describes the harms in scope, and you can read it on the GDPR Recital 75 page on gdpr-info.eu. They include physical, material and non-material damage such as discrimination, identity theft, fraud, financial loss, reputational damage and loss of confidentiality, as well as deprivation of rights and loss of control over personal data.
The register turns that list into a working record. Each entry names a processing activity, the harm that could result, the people affected and the controls in place. It is the natural place to spot which activities need a full assessment, and our guide to privacy risk assessment versus DPIA explains how the two relate.
Free privacy risk assessment
Which privacy risks would hurt the people whose data you hold?
List your personal data and processing, pick from 38 privacy risk scenarios, rate them for the people concerned and for you, and plan treatment with ISO 27701 controls. You get a heat map, a process score and the findings an auditor would raise, free.
Run the free privacy risk assessment → or View premium report sample
| # | Field | What to record |
|---|---|---|
| 1 | Risk ID | A unique reference used across documents |
| 2 | Processing activity | The activity from your record of processing, such as recruitment or customer profiling |
| 3 | Affected individuals | Customers, employees, children, patients and any vulnerable groups |
| 4 | Data involved | Categories, including any special category or criminal data |
| 5 | Risk description | Cause, event and harm to the person in one sentence |
| 6 | Type of harm | Physical, material or non-material |
| 7 | Severity | Rating for the impact on the individual |
| 8 | Likelihood | Rating that reflects scale, sensitivity and context |
| 9 | Existing measures | Controls already reducing severity or likelihood |
| 10 | Treatment and owner | Planned action, a named person and a date |
| 11 | DPIA link | Whether a DPIA exists, is needed or is not required |
| 12 | Residual rating and review date | Expected risk after treatment and when you will revisit it |
Your record of processing activities already lists what you do with personal data, so use it as the source list for the register. For each activity, ask what could go wrong for the people involved. A payroll run could expose salaries, a recruitment tool could screen people out unfairly, a loyalty scheme could reveal sensitive purchases and a shared inbox could disclose a customer’s health details. Write each risk as cause, event and harm to the individual. If you do not have a record yet, our guide to the ROPA exemption explains why most organizations need one.
Severity should reflect what happens to the person, not what happens to the organization. A useful scale ties each level to the consequence for the individual.
| Level | Severity (illustrative) |
|---|---|
| 1 Minimal | Minor inconvenience, easily reversed |
| 2 Limited | Some annoyance or short-term effort to correct |
| 3 Significant | Financial loss, distress or restricted opportunity that takes effort to fix |
| 4 Major | Serious or lasting harm such as identity theft, discrimination or loss of employment |
| 5 Critical | Irreversible harm, safety risk or loss of fundamental rights |
For likelihood, use the factors that Recital 75 highlights as raising risk: sensitive data, profiling and prediction of personal aspects, processing of children’s or other vulnerable people’s data, large scale and the possibility of reversing pseudonymisation. Each factor that applies should push the likelihood or the severity rating upward. Ratings should be reasoned, so add a short note beside each score explaining which factors you considered.
Two harms with the same immediate cost can differ hugely in seriousness if one is reversible and the other is not. A wrongly sent newsletter can be recalled or apologized for. A leaked medical history cannot be taken back. Add a reversibility note to high-severity entries, because it helps decide which risks need stronger controls and which justify a DPIA.
Suppose a retailer introduces a loyalty scheme that infers household composition and health interests from purchases. The register entry names the activity, lists customers as affected individuals, notes that inferred health interests are close to special category data and describes the risk in one sentence: an inferred health profile is shared with a marketing partner, so customers could be targeted with sensitive offers without knowing why. Severity is rated three because the effect is distress and loss of control rather than financial loss, and likelihood is rated four because the sharing is built into the design. The score is above tolerance, so the entry links to a DPIA and lists treatments: stop inferring health interests, restrict sharing to aggregated data and improve the privacy notice. After treatment the residual rating falls to two.
The register is where you decide which activities need a full assessment. Any entry with high severity and meaningful likelihood, or that matches the triggers in Article 35, should point to a DPIA. Use field eleven to track whether one exists. Our guide on when a DPIA is required lists the triggers, and if a completed assessment still leaves high residual risk, read our explanation of DPIA prior consultation.
For every risk above your tolerance, record a treatment: minimize the data, shorten retention, add access controls, pseudonymize, improve transparency, add human review or stop the activity. Give each action an owner and a date, and record the residual rating once it is done. That is the difference between a register and a list of worries.
Keep the two registers connected but separate. A security register tracks threats to the confidentiality, integrity and availability of your systems. A privacy risk register tracks harm to individuals, which includes misuse of data you hold legitimately, unfair decisions, excessive collection and failures to honor rights, none of which need a security incident. A single event can appear in both with different scores. Our comparison of privacy risk and cybersecurity risk shows where they overlap.
Set review triggers that match how your processing changes: a new system or supplier, a new purpose for existing data, a new category of data subject, an incident, a rights request pattern or a regulatory change. Review the whole register on a fixed cycle, annually as a minimum and quarterly for high-rated entries. Assign one owner for the register, usually the data protection officer or privacy lead, and one owner per risk. Present the top risks to management regularly, together with overdue actions.
You can build the register in a spreadsheet, but the scoring scales, heat maps and treatment plan take agreement across legal, IT and the business. The Privacy Risk Assessment Report and Workbook provides a ready structure with a risk register, heat maps, an ISO 27701 treatment plan and a live workbook for your own activities. For the wider management system, see our overview of ISO 27701 implementation.
The GDPR requires a risk-based approach and DPIAs for high-risk processing but does not prescribe a register. A privacy risk register is the practical way to show that you assessed and managed risk to individuals.
A DPIA is a detailed assessment of one high-risk processing operation. The register is the portfolio view across all activities and tells you where a DPIA is needed.
The data protection officer or privacy lead usually owns the register as a whole, while each risk has a named owner who is accountable for treatment and for updating the rating.
There is no correct number. Include the risks that matter for each processing activity and group similar ones so the register stays usable and current.
Review it whenever processing changes materially and on a fixed cycle, annually as a minimum and more often for high-rated entries.
September 30, 2026
