Data Protection Officer: When a SaaS Company Needs One

A data protection officer is a mandatory appointment for some companies, a useful voluntary one for others, and a costly misunderstanding for the rest. Most SaaS teams asking the question do not need one, but the ones that do usually find out from a regulator rather than from their own analysis.

This guide runs the Article 37 test the way it actually applies to a SaaS business, covers what the role requires, and explains what to do when the answer is no. For the service view, see the DPO advisory page.

The Three Triggers, Read Properly

GDPR Article 37 makes a data protection officer mandatory in exactly three situations. Everything else is voluntary.

1. You are a public authority or body. Rare in SaaS. If you are a private company selling to government, this does not apply to you. It applies to the government.

2. Your core activities require regular and systematic monitoring of data subjects on a large scale.

3. Your core activities consist of processing special category data or criminal conviction data on a large scale.

Triggers 2 and 3 are where the real analysis happens, and three phrases carry all the weight.

"Core activities"

Core activities are the processing that is inseparable from what you sell, not the processing every company does to run itself.

Payroll is not a core activity. Neither is your own HR data, your CRM, or your marketing list. Every business does those, and doing them does not put you in scope.

The question is whether personal data processing is intrinsic to your product. An analytics platform, a customer data platform, an ad tech company, or a health records system processes personal data as the product. A project management tool that happens to store user names does not.

"Large scale"

GDPR does not define a number, and the absence of a threshold is deliberate. Regulatory guidance points to the volume of data, the number of data subjects, the duration of processing, and its geographic reach.

Useful anchors: a hospital's patient records are large scale. A single physician's practice is not. A national telecom's location data is large scale. A regional retailer's loyalty program probably is not.

For SaaS, the honest read is that processing data on hundreds of thousands of individuals across multiple countries, continuously, is large scale. A few thousand B2B users at your direct customers usually is not.

"Regular and systematic monitoring"

This means tracking behavior over time, not storing records. Behavioral advertising, location tracking, fitness and health monitoring, credit scoring, and profiling for automated decisions all qualify. Storing a customer's account details does not, no matter how many customers you have.

Running the Test on a Real SaaS Company

Apply the triggers in order and be honest about the answers.

Do you process special category data as a core activity? Health, biometric, genetic, racial or ethnic origin, political opinions, religious beliefs, trade union membership, sex life, or sexual orientation. If you are a HealthTech company holding patient data as the product, this is a yes and you are almost certainly in scope.

Do you monitor behavior regularly and systematically at scale? Not "do you have analytics." Do you track individuals over time as part of what you sell? Ad tech, behavioral analytics, and engagement-scoring products should look hard at this.

Is that processing your core activity or your back office? If the processing exists to run your company rather than to deliver your product, it is not a core activity.

If all three answers point away from you, no DPO is legally required. That is the common outcome, and it is a legitimate one.

Where SaaS companies get it wrong in both directions

Over-appointing. A 40-person B2B SaaS company with EU customers appoints a DPO because it sounds responsible, then discovers the role carries structural obligations that are awkward to unwind. Voluntary appointment is allowed, but a voluntarily appointed DPO is generally held to the same Article 38 and 39 requirements. You do not get a lighter version by choosing it.

Under-appointing. A HealthTech or ad tech company decides it is too small for a DPO. Size is not a trigger. Nature and scale of processing are. A 25-person company processing health data as its product may well need one.

What the Role Actually Requires

The obligations that surprise people are structural, not technical.

• Independence. The DPO cannot receive instructions on how to perform the role. You cannot tell your DPO what conclusion to reach.
• Protection from dismissal. They cannot be fired or penalized for doing the job. If your DPO tells you a launch is unlawful, that opinion is protected.
• Direct reporting to the highest management level. Not to the CTO, not buried under legal.
• Accessibility. Data subjects must be able to contact them, and the contact details go in your privacy notice and to the supervisory authority.
• Resourcing. They need enough time, budget, and access to do the work.

The conflict of interest problem

A DPO cannot hold a position that determines the purposes and means of processing. That eliminates most of the people companies instinctively nominate:

Appointing the CTO is the most common mistake in this whole area, and supervisory authorities have penalized it. For the adjacent question of how this differs from a US-style privacy officer, see DPO vs privacy officer.

When You Do Not Need One, Do This Instead

No DPO requirement does not mean no privacy accountability. The obligations under Articles 5, 30, and 32 apply regardless.

Name an internal privacy owner. Not a DPO, no Article 38 protections, but a person accountable for privacy work. Usually a compliance lead, an operations lead, or a technical founder in smaller teams.

Build the record of processing activities anyway. Article 30 applies to nearly everyone. It is also the artifact that tells you whether your DPO answer is still correct as you grow. See the Article 30 guide.

Get outside counsel for the hard calls. DPIAs, lawful basis for a new product line, and international transfer structures need real expertise on an occasional basis, not a permanent appointment.

Re-run the test annually. A DPO obligation arrives with a product change, not a headcount milestone. Launching a behavioral analytics feature or acquiring a health data product can flip your answer overnight.

Consider a fractional DPO. External appointment on a retainer gives you the expertise and independence without a full-time hire. It is also cleaner on conflict of interest than any internal candidate.

Cost and Structure Options

Internal appointment. Cheapest on paper if you have a qualified compliance person with no conflict. Realistic only if that person exists and has capacity.

External or fractional DPO. A retainer for a named external expert who meets the accessibility and independence requirements. The usual answer for mid-sized SaaS companies with a genuine obligation.

Full-time hire. Justified when the processing is large scale and complex enough to need daily attention. For most SaaS companies below several hundred employees, this is premature.

Whichever you choose, register the DPO's contact details with your lead supervisory authority and publish them in your privacy notice. An appointed DPO nobody can reach does not satisfy the requirement.

The Obligations That Travel With the Question

GDPR is not the only regime that raises a designated-person requirement, and a SaaS company selling internationally can trip a second one without noticing.

UK GDPR. Broadly mirrors the EU triggers for a DPO. If you have both EU and UK operations, one appointment can usually cover both, provided the person is accessible to data subjects and authorities in each jurisdiction.

EU representative under Article 27. This is a different obligation that companies routinely confuse with the DPO. If you have no establishment in the EU but offer goods or services to people there, or monitor their behavior, you may need a representative located in the EU. A representative is a contact point, not an independent adviser, and the two roles are separate. Needing one does not mean you need the other.

US state privacy laws. Most do not mandate a DPO-equivalent. Several require documented assessments for higher-risk processing, which is the kind of work a DPO would otherwise own. The DPO vs privacy officer comparison covers how the US role differs in practice.

Sector rules. HIPAA requires a designated Privacy Officer and Security Officer for covered entities and business associates. Those designations do not satisfy a GDPR DPO requirement, and a GDPR DPO does not satisfy them either. A HealthTech company operating on both sides of the Atlantic may need all three, though one qualified person can sometimes hold more than one, subject to the conflict rules.

Document the answer either way

Whatever you conclude, write it down. A short memo recording the triggers you assessed, the evidence behind each answer, and the date is worth having. Regulators are far more receptive to a company that reached a defensible "no" through analysis than to one that never considered the question. It also gives your next annual review a baseline to compare against, which is what turns this from a one-time judgment into a maintained position.

If you are building the privacy program that sits underneath this decision, start with the record of processing activities guide and the GDPR compliance checklist. The contract layer is covered in GDPR data processing agreements, and the certification path is in ISO 27701. Service pages: DPO and GDPR.

Frequently Asked Questions

What does a data protection officer do? Informs and advises on data protection obligations, monitors compliance, advises on DPIAs, cooperates with the supervisory authority, and acts as contact point for regulators and data subjects. The role is advisory, not executive. A DPO assesses decisions rather than making them, and must be able to do so without fear of removal.

What are the duties of a data protection officer? Article 39 sets out advising, monitoring compliance including training, advising on DPIAs, cooperating with the authority, and being its contact point. Article 38 adds the structural requirements: reporting to the highest management level, freedom from instruction, protection from dismissal, and no conflicting role.

What skills do you need to be a data protection officer? Expert knowledge of data protection law proportionate to your processing, the ability to run a DPIA, enough technical fluency to challenge an engineering design, and the communication skill to explain the position to product teams and regulators alike. No specific certification is mandated.

Can anyone be a data protection officer? No. The binding constraint is conflict of interest: anyone who determines the purposes and means of processing is disqualified, which rules out the CTO, engineering and marketing leads, and usually the general counsel. An existing employee without a conflict, or an external appointee, can hold the role.

Not Sure Whether You Need a DPO?

ShieldKey Solutions runs the Article 37 assessment, documents the reasoning either way, and provides fractional DPO coverage when the answer is yes. When the answer is no, we tell you that and help you stand up the privacy ownership you do need.

Schedule a scoping call →