5.1 DPO & DPIA

Why DPO and DPIA Matter on the Exam

The Data Protection Officer (DPO) and the Data Protection Impact Assessment (DPIA) are two of the most heavily tested accountability tools in the General Data Protection Regulation (GDPR). Questions are almost always scenario-based: you are given facts about an organisation and asked whether a DPO is mandatory, or whether a DPIA is required. Memorising the three triggers for each is the single highest-yield task in the compliance domain.

Both tools sit under the accountability principle in Article 5(2): the controller must not only comply but be able to demonstrate compliance. The exam exploits the fact that a DPO and a DPIA are independent obligations — you can need one without the other. A small clinic with no DPO obligation may still owe a DPIA; a public authority always needs a DPO but may run no high-risk processing at all. Treat the two analyses as separate decision trees and never let the answer to one collapse into the other.

When a DPO Is Mandatory (Article 37)

Under Article 37(1), a controller or processor must designate a DPO in three cases:

Key distinctions the exam exploits:

• Core activities means the primary business operations needed to achieve the organisation's goals, not ancillary support like IT, HR, or payroll. A hospital's core activity is patient care (so a DPO is mandatory); an employer running ordinary payroll is not processing health data as a core activity.
• Large scale is judged on the number of data subjects, the volume and range of data, the duration of processing, and the geographical extent. A single physician's patient files are not large scale; a hospital's are.
• Regular and systematic monitoring explicitly includes all forms of online tracking and behavioural advertising — the WP29/EDPB guidance lists this expressly.
• A group of undertakings may appoint a single DPO (Article 37(2)) provided the DPO is easily accessible from each establishment.
• The DPO may be a staff member or an external contractor (Article 37(6)), and the contact details must be published and communicated to the supervisory authority (Article 37(7)).

DPO Position and Tasks (Articles 38-39)

Article 38 protects DPO independence. The controller must:

• Involve the DPO properly and in a timely manner in all data-protection matters
• Provide resources, access to personal data and processing operations, and support to maintain expertise
• Ensure the DPO does not receive instructions regarding the exercise of tasks
• Ensure the DPO is not dismissed or penalised for performing the role
• Have the DPO report to the highest management level

The DPO must also avoid conflicts of interest: they cannot hold a position that determines the purposes and means of processing, so a CEO, COO, head of marketing, head of HR, or head of IT generally cannot also be DPO.

Article 39 lists the DPO's tasks: informing and advising on obligations; monitoring compliance and awareness-raising/training; advising on and monitoring the performance of DPIAs; cooperating with the supervisory authority; and acting as the contact point for the supervisory authority and for data subjects on processing matters. A critical exam trap: the DPO advises and monitors but is not personally liable for the organisation's compliance — that liability stays with the controller. The DPO is also not responsible for deciding whether to proceed with high-risk processing; that decision belongs to management.

When a DPIA Is Required (Article 35)

A DPIA is required when a type of processing is likely to result in a high risk to the rights and freedoms of natural persons, in particular when using new technologies. Article 35(3) lists three cases that always require a DPIA:

1. Systematic and extensive evaluation based on automated processing, including profiling, on which decisions producing legal or similarly significant effects are based
2. Large-scale processing of special-category data (Article 9) or criminal-offence data (Article 10)
3. Systematic monitoring of a publicly accessible area on a large scale (e.g., large-scale CCTV or smart-city sensors)

Supervisory authorities also publish mandatory "blacklist" and optional "whitelist" lists of operations under Article 35(4)-(5), and these go through the EDPB consistency mechanism. The WP29 (now European Data Protection Board, EDPB) endorsed nine criteria — evaluation/scoring, automated decision-making with legal effect, systematic monitoring, sensitive/highly personal data, large scale, matching/combining datasets, vulnerable data subjects, innovative technology, and processing that prevents data subjects exercising a right. Meeting two or more criteria usually signals high risk and a DPIA.

A DPIA can cover a set of similar operations (Article 35(1)), so you do not need one per identical system.

DPIA Content and Prior Consultation (Articles 35-36)

Under Article 35(7), a DPIA must contain at minimum:

• A systematic description of the processing operations and the purposes, including the controller's legitimate interest where relevant
• An assessment of the necessity and proportionality of the processing relative to its purposes
• An assessment of the risks to data subjects' rights and freedoms
• The measures envisaged to address those risks — safeguards, security measures, and mechanisms to ensure protection and demonstrate compliance

The controller must seek the advice of the DPO where one is designated (Article 35(2)) and should seek the views of data subjects or their representatives where appropriate (Article 35(9)). A DPIA is a living document: under Article 35(11) the controller must review it when the risk changes.

Prior consultation (Article 36) is the step many candidates get wrong. The controller must consult the supervisory authority only when the DPIA indicates the processing would result in a high residual risk in the absence of measures taken by the controller to mitigate it. If the controller can mitigate the high risk to an acceptable level, no prior consultation is needed — you simply proceed and document. When consulted, the DPA must respond within 8 weeks of the request, extendable by 6 weeks for complex processing (Article 36(2)).