The question usually arrives from a board or a customer's security questionnaire, and it is nearly always answered too quickly — in one of two wrong directions.
When GDPR actually requires one
Article 37 lists three triggers. You need a DPO if:
- You are a public authority or body (courts acting judicially excepted).
- Your core activities consist of processing operations that require regular and systematic monitoring of data subjects on a large scale.
- Your core activities consist of large-scale processing of special-category data (health, biometrics, religion, politics, sexual orientation, and so on) or data on criminal convictions.
Two words in there carry the weight.
Core activities. Not everything you do — what you fundamentally do to deliver your product or service. A hospital's core activity involves health data. A company that merely has an HR department processing employee sick notes does not thereby have a core activity of processing health data.
Large scale. Not defined by a number, which is unhelpful, but assessed on the volume of data, the number of individuals, the duration, and the geographical reach. A single clinic is generally not large scale. A national telecoms operator is.
Most SaaS and ecommerce companies meet none of the three, and do not need a DPO.
The trap: appointing one anyway, badly
Plenty of companies appoint a DPO voluntarily — to reassure enterprise customers, or because a questionnaire asked and "no" felt like a bad answer.
Here is the catch: if you appoint a DPO, the Article 38 and 39 obligations apply to that role regardless of whether you were required to have one. You have voluntarily taken on a set of duties. And the most commonly breached of those is independence.
A DPO must:
- be involved properly and in a timely manner in all data protection matters
- report to the highest level of management
- not receive instructions on how to perform the role
- not be dismissed or penalised for performing it
- not have a conflict of interest with other duties they hold
That last point is where it goes wrong. Regulators have found that the DPO cannot be the person who determines the purposes and means of processing — because they would be marking their own homework. In practice this rules out the CEO, the CTO, the Head of Marketing, and usually the Head of IT.
Appointing your CTO as DPO to satisfy a questionnaire is not a neutral act. It is a documented conflict of interest, in writing, that you handed to the regulator yourself.
If you do not need a DPO, you still need an owner
Not needing a DPO does not mean not needing accountability. GDPR's accountability principle applies regardless. Someone has to:
- keep the record of processing current
- handle data subject requests within the deadline
- maintain a risk register and run DPIAs where required
- respond to security reviews and regulator correspondence
Call the role whatever you like — Privacy Lead, Compliance Owner — as long as it is named, resourced, and not the person whose incentives run the other way. What you must not do is call it a DPO if you are not going to give it the independence a DPO is legally owed.
The honest test
Ask two questions:
Is monitoring or special-category data what our product fundamentally does? If yes, you likely need a DPO and should get proper advice on it.
If no — who is accountable today, and can they actually act? If the answer is "nobody, really," that is the gap to close. It is a resourcing decision, not a titling decision, and giving someone a title without authority solves nothing while creating an obligation you have not thought about.