If you work in privacy compliance, three acronyms appear in almost every conversation: RoPA, DPIA, and DSAR. They are all GDPR obligations, they all sound similar at a glance, and they are frequently mixed up — even by experienced professionals.

In practice, they serve fundamentally different purposes. A Record of Processing Activities (RoPA) is your operating map of personal data flows. A Data Protection Impact Assessment (DPIA) is your risk analysis for high-risk processing. A Data Subject Access Request (DSAR) is an individual right that your organisation must respond to.

This guide explains the difference, the legal basis for each, and how they work together in a mature compliance programme.

What is a RoPA?

A Record of Processing Activities (RoPA) is a written register documenting every processing activity involving personal data within your organisation. It is required under Article 30 of the UK GDPR and EU GDPR and serves as your central source of truth for understanding how personal data flows through your business.

Each processing entry in a RoPA records the purpose of processing, categories of data subjects and personal data, recipients, international transfer details and safeguards, retention periods, and a description of technical and organisational security measures.

For controllers, Article 30(1) sets out the full list of mandatory fields. For processors, Article 30(2) specifies a narrower set of record-keeping obligations covering the categories of processing carried out for each controller. Organisations often assume the 250-employee threshold exempts them, but that exemption is narrow — it only applies if processing is occasional, involves no special category data, and is unlikely to result in risk.

A RoPA is not a one-off exercise. It is a living register that must be maintained as your operations change. For a complete breakdown of the requirements, see our guide to what a Record of Processing Activities is and how to build one.

What is a DPIA?

A Data Protection Impact Assessment (DPIA) is a risk assessment required under Article 35 of the GDPR for processing activities likely to result in high risk to individuals' rights and freedoms.

Unlike a RoPA — which documents the facts of processing — a DPIA evaluates the necessity and proportionality of the processing, identifies specific risks to data subjects, and defines mitigations to reduce residual risk to an acceptable level.

Processing activities that trigger the DPIA requirement include systematic profiling, large-scale processing of special category data, systematic monitoring of public areas, and the use of innovative technologies. Supervisory authorities maintain lists of processing types that require a DPIA, and some — such as the ICO in the UK — provide additional guidance on what crosses the threshold.

A DPIA must be conducted before the processing begins, not retrospectively, and must be reviewed when the nature, scope, context, or purposes of processing change. For organisations deploying AI systems, the DPIA obligation takes on particular urgency. See our guide to AI and DPIAs for a detailed look at how risk assessments apply to automated decision-making and machine learning models.

What is a DSAR?

A Data Subject Access Request (DSAR) is a right exercised by an individual — not a document your organisation produces proactively. Under Article 15 of the GDPR, individuals have the right to obtain confirmation of whether their personal data is being processed, access to that data, and information about the purposes, categories, recipients, retention periods, and rights they hold.

When a DSAR is received, your organisation must respond without undue delay and within one month, confirming what data you hold, providing a copy, and explaining how and why it is processed. Extensions of up to two months are permitted for complex or numerous requests, but the individual must be informed within the first month.

DSARs are distinct from both RoPAs and DPIAs in a fundamental way: they are externally triggered. A RoPA is something you maintain. A DPIA is something you assess internally. A DSAR is something you respond to because an individual asks. The quality and speed of your response depends heavily on how well your RoPA is maintained — you cannot locate data you have not mapped.

RoPA vs DPIA vs DSAR: Key Differences at a Glance

| | RoPA | DPIA | DSAR | |---|---|---|---| | Legal basis | Article 30 | Article 35 | Article 15 | | What it is | Register of processing activities | Risk assessment for high-risk processing | Individual's right to access their data | | Who initiates it | Organisation (ongoing obligation) | Organisation (before new high-risk processing) | Data subject (external request) | | Trigger | Any processing of personal data | Processing likely to result in high risk | Individual submits a request | | Frequency | Continuous maintenance | Per-processing activity, reviewed as processing changes | On receipt of valid request | | Deadline | Ongoing obligation | Before processing begins | Within one month of request | | Output | Living register | Assessment document and evidence package | Copy of data and processing information |

How They Work Together in Practice

These three obligations are not siloed exercises. In a well-structured compliance programme, they 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 processing landscape. A maintained RoPA tells you what data you already hold, where it flows, and who the recipients are — reducing the discovery phase of each new DPIA from weeks to hours.

A completed DPIA can trigger RoPA updates. When a DPIA identifies a new processing activity, a new data flow, or a revised retention period, the RoPA must be updated to reflect the change. The DPIA is not the final step — it feeds back into the central register that keeps your compliance picture accurate.

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 outdated or incomplete RoPAs spend days manually searching across systems when a DSAR arrives. Those with current, granular registers can locate and compile the relevant data within hours.

DPIAs inform DSAR exemptions. Article 15(4) allows organisations to consider the rights and freedoms of others when responding to a DSAR. A well-documented DPIA may provide the rationale for restricting partial access — for example, where disclosure would reveal trade secrets embedded in automated decision-making logic or compromise the privacy of other data subjects. These exemptions must be justified, and the justification should be documented and auditable.

Common Misconceptions

"We have fewer than 250 employees, so we do not need a RoPA."

The Article 30(5) exemption is narrower than it appears. It applies only where processing is occasional, does not involve special category data, and is unlikely to result in risk. Most organisations that process employee data, customer data, or supplier data do not qualify for the exemption. If personal data is a regular part of your operations, you almost certainly need a RoPA. For a detailed explanation, see our complete guide to GDPR Article 30.

"DPIAs are only required for AI and automated decision-making."

AI and automated decision-making are common DPIA triggers, but the Article 35 obligation extends far further. Large-scale processing of special category data, systematic monitoring of public areas, and processing that involves vulnerable individuals all fall within scope. The ICO publishes a non-exhaustive list of processing types that require a DPIA — and it covers far more than AI.

"A DSAR and a DPIA are the same thing because they both involve data protection."

They serve opposite directions. A DPIA looks inward — assessing risk before processing begins. A DSAR looks outward — responding to an individual's right to know what you hold. Confusing the two leads to DPIAs that read like data inventories and DSAR responses that read like risk assessments. Both outcomes fail their respective regulatory expectations.

"Once written, the RoPA and DPIA are done."

Neither is a one-off exercise. A RoPA must be maintained as operations change. A DPIA must be reviewed when the nature, scope, context, or purposes of processing change — including when a model is retrained, when training data sources shift, or when new regulatory guidance is published. Treating either as a static document creates an accumulating compliance gap.

Building a Programme That Covers All Three

Organisations that manage these obligations well share a few common practices:

Maintain a single source of truth for processing activities. A current RoPA underpins both DPIA scoping and DSAR response. Invest in keeping it accurate rather than treating it as a project deliverable.
Triage new processing systematically. When a new initiative, vendor, or system is proposed, assess whether a DPIA is required before committing resources. This is far cheaper than retrofitting compliance after launch.
Test DSAR response under realistic conditions. The time to discover that your RoPA does not cover a critical system is not when a DSAR lands with a one-month deadline. Run dry-run exercises periodically.
Treat documentation as living artefacts. Version-controlled, regularly reviewed, and supported by evidence — not static documents stored in a shared drive and forgotten.

Clarium helps teams build and maintain visual, structured RoPAs that stay accurate as operations change, and supports deterministic DPIA production for high-risk processing. Get started free or see how it works.

RoPA vs DPIA vs DSAR — What's the Difference?