Who Is Responsible for a DPIA? UK GDPR Guide

Article 35(1) of the UK GDPR leaves no ambiguity here. The controller carries out the DPIA. Other parties can help, and external support can be brought in, but the controller answers for the result.

In most organisations, the controller is the legal entity itself: the company, the public authority, the charity. Day-to-day, that accountability sits with whoever holds decision-making authority over the processing in question, often a senior leader, a project sponsor, or a business unit head.

What "Responsible" Actually Means

Being responsible for a DPIA doesn't mean writing all the paperwork personally. It means:

1. Commissioning the DPIA at the right time, before processing begins
2. Making sure the right people are involved, including the DPO where one's appointed
3. Making the final call on whether processing can proceed, based on the findings
4. Signing off the outcome and documenting it
5. Consulting the ICO under Article 36 if a high risk can't be mitigated, before going ahead

Outsourcing the work of completing a DPIA doesn't outsource the responsibility for it. If you ask a processor to carry it out on your behalf, the ICO is clear that you remain accountable.

When Joint Controllers Are Involved

Where two or more organisations jointly decide the purposes and means of processing, responsibility for the DPIA is shared between them. Article 26 requires joint controllers to agree who takes the lead on completing and maintaining the assessment, and to document that arrangement as part of the wider accountability record.

A common misconception in privacy practice puts DPIA ownership with the DPO, when responsibility sits with the controller. Getting that wrong creates two problems. DPOs end up writing assessments for processing they don't fully understand, and business units stop expecting to own the work themselves.

Under Article 35(2), the controller has to seek the DPO's advice when carrying out a DPIA wherever a DPO's appointed, and that consultation is mandatory. Article 39(1)(c) makes it one of the DPO's core duties: advising on DPIAs and monitoring how they perform over time.

What the DPO Must Do

The ICO sets out six specific areas where DPO advice is required:

1. Whether a DPIA is needed in the first place
2. How the DPIA should be carried out
3. Whether to complete it in-house or bring in external support
4. What measures and safeguards can mitigate the risks identified
5. Whether the DPIA has been completed correctly
6. Whether the processing can go ahead based on the outcome
7. The DPO also has to monitor how the DPIA performs once it's in use, including whether the agreed mitigations got implemented.

What the DPO Must Not Do

UK GDPR protects the DPO's independence, and that limits what DPIA work they can be handed: nothing that would compromise their ability to do the job independently. In practice, the DPO advises and scrutinises the assessment. Authoring it and signing it off are different jobs, and one person can't hold both without compromising the review.

A DPIA isn't a two-person job between the controller and the DPO. The ICO names several other roles that should contribute, depending on what's being assessed:

Article 35(9) requires the controller to seek data subjects' views, or their representatives' views, where appropriate. Choosing not to consult them still needs a documented reason.

Processors don't carry legal responsibility for a DPIA. Where a processor handles the relevant processing, the controller can ask them to complete it on the controller's behalf, though responsibility stays with the controller either way. Article 28(3)(f) makes this contractual: processor agreements have to require them to assist with compliance under Articles 32 to 36, DPIAs included.

Knowing who's responsible only matters if the DPIA gets triggered at the right moment, and the full criteria are covered in our guide to DPIA timing. The short version: Article 35(3) and the ICO's own guidance set the threshold, and the obligation falls due at the point processing is due to begin. Whoever owns the DPIA needs that check built into project scoping from day one.

Most DPIA failures come down to organisational gaps that let the process slip through project governance.

The DPO Becomes the De Facto Owner

When business units treat a DPIA as a privacy-team task, the DPO ends up assessing processing they weren't close enough to scope properly, filling gaps in operational detail nobody's handed over. The DPO turns into a bottleneck, DPIAs slow down, and some get skipped.

The fix is structural: make DPIA ownership explicit in project governance, with the project or business lead initiating, the DPO advising, and the controller signing off.

A DPIA on File Doesn't Guarantee It Holds Up

Article 35(1) requires the assessment before processing starts. A DPIA finished after a system's already live just documents a decision that's already been made.

Having an assessment on file doesn't prevent enforcement, either. In February 2024, the ICO issued enforcement notices against Serco Leisure and several partner leisure trusts over facial recognition and fingerprint scanning used to monitor employees, ordering the biometric data deleted within three months. The ICO's findings centred on a missing valid basis for processing special-category biometric data under Article 9, and a failed necessity and proportionality test, given less intrusive options like ID cards existed. Before signing off, the controller needs to test whether the assessment holds up on its own merits.

Ownership Is Unclear in Complex Processing Chains

Where several business units, vendors, or processors are all touching the same processing, it's common for each one to assume somebody else has done the DPIA. Usually nobody has. Processor contracts should require them to assist with DPIA completion under Article 28(3)(f), and internal project governance should settle who holds the pen before the project starts.

DPIAs Get Completed Once and Forgotten

A DPIA is a living document. The ICO expects organisations to keep it under review and revisit it whenever the nature, scope, or purpose of the processing changes materially. An assessment written for a system that's since expanded, been integrated with new vendors, or been repurposed can drift a long way from the actual risk profile without anyone noticing.

For organisations running several projects at once, managing DPIA obligations by hand tends to recreate the exact gaps regulators find: unclear ownership, missed triggers, and assessments nobody's revisited. The volume of processing activity and the pace of new deployments make a spreadsheet-based approach hard to sustain.

Effective DPIA governance at scale needs three things:

1. Defined triggers, built into project initiation and procurement sign-off, so a project's DPIA need gets settled during approval
2. Tracked workflows, with clear ownership, documented DPO advice, and sign-off records that can be audited on demand
3. Ongoing monitoring that flags when an existing DPIA needs review, triggered by new sub-processors, scope changes, or material incidents

SureCloud's Data Privacy Management, powered by Gracie AI Agents with Personas and Skills, handles DPIA workflows alongside subject access request management, data mapping, and continuous control monitoring in one platform. Organisations using it get DSAR completion done 50% faster and spend 80% less time finding evidence during audits.