RoPA vs DPIA vs DSAR: How Three GDPR Obligations Interlock
Three acronyms dominate privacy compliance conversations, and experienced professionals mix them up. RoPA, DPIA, and DSAR all concern personal data protection, but they serve different functions: a register, a risk assessment, and an individual right. Where each begins and ends, and how they feed each other, separates a programme that holds together from one that collapses under scrutiny.
Each has a dedicated framework page: RoPA, DPIA and DSAR. This post focuses on the differences between them.
A RoPA is your operating map of every processing activity
A Record of Processing Activities is a written register documenting every processing activity involving personal data. Article 30 of the UK GDPR and EU GDPR requires it, and it functions as the central source of truth for how personal data moves through your business.
Each entry records the purpose of processing, categories of data subjects and personal data, recipients, international transfer details and safeguards, retention periods, and technical and organisational security measures. Controllers face the full Article 30(1) field list. Processors keep a narrower set under Article 30(2).
The 250-employee exemption is narrower than it looks. It applies only where processing is occasional, involves no special category data, and is unlikely to result in risk. A company processing payroll, customer orders, and supplier contracts on a regular basis does not qualify. For a full breakdown of the requirements, see our complete guide to GDPR Article 30, and for a practical walkthrough, our guide to what a Record of Processing Activities is and how to build one.
A DPIA is your risk assessment for high-risk processing
A Data Protection Impact Assessment is required under Article 35 for processing likely to result in high risk to individuals' rights and freedoms. Where a RoPA documents the facts of processing, a DPIA evaluates necessity and proportionality, identifies risks to data subjects, and defines mitigations to reduce residual risk to an acceptable level.
Several processing types trigger it: systematic profiling with significant effects, large-scale processing of special category data such as health records or biometric identifiers, systematic monitoring of public areas, and innovative technology without established safeguards. The ICO in the UK publishes a non-exhaustive list of processing types that require a DPIA, and the EDPB offers equivalent EU guidance.
A DPIA must be conducted before processing begins, never retrospectively, and reviewed when the nature, scope, context, or purposes change. For teams deploying AI, the obligation takes on particular urgency: a model retrained on new data, or a new automated decision-making pipeline, can trigger a fresh assessment. Our guide to AI DPIAs examines how risk assessments apply to machine learning, and when a DPIA is required and how to do one covers the trigger and the process.
A DSAR is an individual right exercised against your organisation
A Data Subject Access Request is a right exercised by an individual, not a document you produce proactively. Under Article 15, individuals can obtain confirmation of whether their personal data is being processed, access to that data, and information about purposes, categories, recipients, retention periods, and the rights they hold.
When a DSAR arrives, you must respond without undue delay and within one month. Extensions of up to two months are permitted for complex or numerous requests, but the individual must be informed within the first month.
DSARs differ from RoPAs and DPIAs in a structural way. A RoPA is something you maintain. A DPIA is something you assess internally. A DSAR is something you respond to because an individual asks. And your response depends heavily on how well your RoPA is maintained: you cannot locate data you have not mapped. For practical handling, see our guide on how to respond to a Data Subject Access Request.
The concrete differences at a glance
| RoPA | DPIA | DSAR | |
|---|---|---|---|
| Legal basis | Article 30 (UK/EU GDPR) | Article 35 (UK/EU GDPR) | Article 15 (UK/EU GDPR) |
| What it is | Register of processing activities | Risk assessment for high-risk processing | Individual's right to access their data |
| Who initiates | Organisation, ongoing obligation | Organisation, before new high-risk processing | Data subject, external request |
| Concrete trigger | Any processing of personal data (e.g. payroll, CRM, marketing email lists) | Systematic profiling, large-scale special category data, public area monitoring, innovative technology | Individual submits a request by email, letter, or verbal ask |
| Frequency | Continuous maintenance | Per processing activity, reviewed on change | On receipt of each valid request |
| Deadline | Ongoing, kept current at all times | Completed before processing begins | One month from receipt, extendable by two months for complex cases |
| Output | Living register with Article 30 fields | Assessment document with risk ratings and mitigations | Copy of personal data plus processing information |
Jersey mirrors the structure under the DPJL 2018
The Data Protection (Jersey) Law 2018 (DPJL 2018) mirrors the GDPR architecture closely. Under the DPJL 2018, the same three obligations apply through equivalent provisions. The Jersey Office of the Information Commissioner (JOIC) is the supervisory authority, and Jersey holds EU adequacy, reaffirmed on 15 January 2024, so personal data can flow from the EEA to Jersey without additional safeguards.
For Jersey-registered organisations, the practical obligations are nearly identical to UK GDPR, and JOIC has published guidance that closely tracks ICO positions on these obligations. For a detailed look, see our guide to data protection in Jersey under the DPJL 2018.
How the three reinforce each other
A current RoPA enables faster DPIAs. Before you can assess whether new processing is high-risk, you need to understand your existing landscape: what data you already hold, where it flows, who the recipients are. A maintained RoPA gives the DPIA scoping exercise a ready-made inventory instead of a blank page.
A completed DPIA feeds back into the RoPA. When it identifies a new processing activity, a new data flow, or a revised retention period, the register must reflect the change. The assessment is a checkpoint, not a terminal document.
DSARs depend on a well-maintained RoPA. When an individual asks for the data you hold about them, you need to know where to look. Organisations with current registers can scope a DSAR in minutes because they know which systems hold what.
DPIAs also inform DSAR exemptions. Article 15(4) lets organisations consider the rights and freedoms of others when responding, for example where disclosure would reveal trade secrets in automated decision-making logic or compromise other data subjects.
Where the three obligations get confused
Three mistakes recur. The 250-employee RoPA exemption is assumed wider than it is, when it only covers occasional, low-risk processing without special category data. DPIAs are assumed to be AI-only, when the ICO's threshold list covers large-scale special category data and public area monitoring too. And both a RoPA and a DPIA are treated as one-off documents, when each must be maintained and reviewed as operations, models, and guidance change.
Three obligations, one evidence base
These three obligations do not stand alone. They form a system where the register feeds the assessment, the assessment updates the register, and both determine how quickly you can respond when an individual exercises their rights. A programme that treats them as separate deliverables produces three documents that drift from reality at different speeds. One that treats them as interlocking produces a living model where each obligation strengthens the next.
Clarium keeps the register that feeds all three: AI extraction pulls Article 30 fields from free text with confidence scores, visual maps show where data moves, and export gives you the format the regulator asks for. See pricing.