Does Your SaaS Actually Need a Data Protection Officer? Running the Article 37 Test

By Andrew

“Do we need a DPO?” is probably the single most common GDPR question asked inside growing SaaS companies, and it almost always gets answered badly — usually with a headcount threshold someone half-remembers, or a confident “that’s only for big companies.”

Neither is in the regulation. GDPR Article 37 contains no employee count, no revenue threshold, and no user number. What it contains instead is a three-part test built on two deliberately undefined phrases, which means the answer for any given company is a judgment call rather than a lookup. And the part most teams miss entirely: if you decide the answer is no, you need to be able to demonstrate *how* you reached that conclusion, because a regulator asking the question later will not accept “we didn’t think we had to.”

The Three Triggers

Article 37 makes appointing a Data Protection Officer mandatory in exactly three situations.

The first is being a public authority or body — straightforward, and irrelevant to most commercial SaaS.

The second is where your **core activities** consist of processing operations that require **regular and systematic monitoring of data subjects on a large scale**. This is the trigger that catches adtech platforms, location-tracking applications, workplace-monitoring tools, behavioural analytics products, and anything whose value proposition involves observing user behaviour continuously.

The third is where your **core activities** consist of **large-scale processing of special category data** — health, biometrics, genetics, race or ethnicity, political opinions, religious beliefs, trade union membership, sex life or sexual orientation — or data relating to criminal convictions and offences. Health-tech, HR platforms handling medical records, and identity-verification services routinely land here.

Two phrases carry the entire weight of the test: *core activities* and *large scale*. Get either reading wrong and the conclusion flips.

“Core Activities” Is Narrower Than It Sounds

The first filter is the one companies most often over-apply to themselves, then dismiss.

Core activities means the processing that is inseparable from what you actually do — the key operations needed to achieve your objectives, not everything you happen to process along the way. Every company processes employee HR data. Every company runs payroll. Nobody appoints a DPO because of payroll, because payroll is ancillary support, not the business.

The distinction matters most in edge cases. A cybersecurity provider monitoring client network traffic for threats is monitoring as a core activity — that *is* the product. A logistics company using GPS to track its own delivery fleet is monitoring, but arguably as a support function to the actual business of moving goods. A SaaS analytics platform whose entire value is tracking end-user behaviour across customer websites is monitoring as a core activity, unambiguously, even if the company has twelve employees.

Which brings up the point that upends the “we’re too small” instinct: **there is no size exemption in Article 37.** A twenty-person adtech startup processing behavioural data on millions of end users meets the test. A four-hundred-person B2B software company selling project management tools, processing nothing more sensitive than names and work email addresses, very likely does not. Headcount is not the variable. What you do with data is.

“Large Scale” Has No Number — On Purpose

The second phrase is where most self-assessments quietly collapse, because people go looking for a threshold that was never written.

GDPR does not define “large scale” numerically. The European Data Protection Board’s guidance (WP243) instead sets out factors to weigh together: the number of data subjects affected, either as an absolute figure or as a proportion of the relevant population; the volume of data and the range of data items processed; the duration or permanence of the processing; and the geographical extent of the activity.

Notice that these factors interact rather than each standing alone. Continuous processing of a modest dataset across many EU member states can weigh heavier than a one-off bulk import in a single country. Processing a small number of records that are extraordinarily sensitive and permanently retained can weigh heavier than a large volume of transient, low-risk data.

The practical consequence is that reasonable people can reach different conclusions on the same facts — which is exactly why the reasoning has to be written down.

Your National Law May Have a Number Even Though GDPR Doesn’t

Here is the detail that invalidates a great many carefully reasoned Article 37 assessments: GDPR Article 37(4) explicitly permits member states to impose stricter DPO requirements than the Regulation itself, and at least one major market has done exactly that with a hard numeric threshold.

Under Section 38 of Germany’s Federal Data Protection Act (BDSG), a company must appoint a DPO once **at least 20 employees are regularly engaged in automated processing of personal data** — irrespective of whether the processing is large-scale, systematic, or high-risk in any GDPR sense. There’s no core-activities test and no balancing of factors. It’s a headcount trigger, and “employees regularly engaged in automated processing” in a modern software company means roughly everyone who uses a CRM, a support desk, or an HR system. The threshold was actually relaxed in 2019 — it previously sat at ten — which tells you how low the bar has historically been.

The consequence for a SaaS company is direct. A twenty-five-person B2B product with no special category data, no behavioural monitoring, and a perfectly defensible “Article 37 doesn’t apply to us” memo still needs a DPO the moment it has a German establishment. The GDPR analysis was correct; it just wasn’t the whole analysis.

Germany is the most-cited example, but it isn’t guaranteed to be the only one, and national implementations shift. Any company with establishments in multiple member states needs the assessment done per jurisdiction rather than once at group level — which is precisely the kind of question a structured GDPR compliance review is meant to surface before a regulator does.

Controller or Processor? The Question That Reframes Everything

Most SaaS companies occupy two roles simultaneously and assess only one of them. For customer end-user data flowing through your platform you’re typically a **processor**, acting on the controller’s documented instructions under an Article 28 agreement. For your own employee records, marketing list, analytics and billing data, you’re a **controller** making your own purpose-and-means decisions.

Article 37 applies to both, but the analysis runs differently in each capacity. As a processor, the question is what your operations objectively involve — if your platform performs large-scale behavioural monitoring on behalf of clients, that’s monitoring as a core activity regardless of whose data it is or who decided to collect it. Companies that conclude they’re “just a processor” and treat the question as their customers’ problem have the logic backwards: the obligation attaches to the activity, not to the role label.

There’s a commercial dimension too. Enterprise procurement teams increasingly ask vendors outright whether a DPO has been appointed and request their contact details during security review. Answering that quickly — or producing a documented assessment explaining why one isn’t required — has become a sales-cycle asset independent of whether a regulator ever asks.

The “No” That Still Needs Documentation

Here’s the part that surprises teams who reach a negative answer and consider the matter closed.

If you assess the Article 37 criteria and conclude a DPO isn’t mandatory, that conclusion is itself a compliance artifact. Under the accountability principle, you’re expected to be able to demonstrate the basis for your data protection decisions — and “we determined we don’t fall under Article 37” is a decision. A supervisory authority reviewing your organisation after a complaint or a breach will ask how you reached it. An enterprise customer’s security questionnaire will ask the same thing, usually with less patience.

A defensible negative assessment records what your core activities actually are, which processing operations were evaluated against each trigger, how the large-scale factors were weighed, and when the assessment was made. It should also name a review trigger — because the answer changes. A company that adds behavioural analytics, expands into a new market, or launches a feature touching health data can cross the threshold without anyone noticing that the old assessment no longer describes the business.

This is where a documented compliance audit earns its cost even for companies that turn out not to need a DPO at all: the output isn’t just an answer, it’s the evidence that the answer was reached properly.

What Appointing One Actually Costs

For companies that land on the mandatory side, the two paths diverge sharply on cost.

An in-house DPO in Western Europe typically commands €80,000 to €150,000 in base salary. Reported figures vary a lot by market — some UK surveys put the average nearer £51,000 — so the honest range is wide and turns on whether you’re hiring a seasoned specialist or someone growing into the role. Salary is also only part of it: loaded with benefits, employer taxes, recruitment and training, the real number runs meaningfully higher, plus three to six months of hiring time and the ordinary risk of a mis-hire in a role where mistakes are regulatory rather than operational.

Outsourced or fractional arrangements sit in a different bracket: published pricing clusters between roughly €1,150 and €2,900 per month, or about €21,000 to €35,000 annually. The trade-off is worth stating plainly — an external DPO brings cross-client experience and immediate availability, but knows your product less intimately than someone in your standups, and needs deliberate onboarding to be effective rather than decorative.

There’s also a structural reason the external route fits smaller SaaS companies. Article 38 requires the DPO to operate without instructions on how to perform their tasks, report to the highest management level, and remain free from conflicts of interest — which is why appointing your CTO is usually a bad idea, since they’d be supervising their own processing decisions. In a company where everyone wears several hats, genuine independence is often easier to source from outside the org chart than inside it, which is much of the appeal of a DPO-as-a-Service arrangement: a named, qualified, registered officer with the independence requirement satisfied by construction.

The Voluntary Appointment Trap

A piece of advice that sounds prudent can quietly create obligations a company never intended to take on: “we’re not sure whether we need one, so let’s appoint someone as a precaution.”

GDPR draws no distinction between a mandatory DPO and a voluntary one. Once you designate someone as your Data Protection Officer — in a privacy notice, a contract, or a filing with a supervisory authority — the full weight of Articles 38 and 39 attaches: independence, the reporting line to senior management, protection from dismissal for performing the role, the resourcing obligation, timely involvement in all personal-data matters. All of it applies exactly as though the appointment had been compulsory, and the EDPB’s guidance is explicit on the point.

That doesn’t make voluntary appointment a bad idea — it makes *casual* voluntary appointment a bad idea. Naming a “Data Protection Officer” on your privacy page because the title looked reassuring, while that person has no independence, no budget and no seat at product decisions, creates precisely the exposure the appointment was meant to reduce: a published claim you cannot substantiate.

The workable alternative below the mandatory threshold is a privacy lead or data protection manager — someone who owns the work without carrying the statutory title. The tasks get done, the accountability evidence gets produced, and the Article 38 machinery doesn’t engage. If you want the title, take the obligations with it deliberately rather than by accident.

Appointing Is the Beginning, Not the Finish Line

Article 39 defines what a DPO is actually for, and the list is narrower than the vague “handles privacy” most job descriptions imply: inform and advise the organisation on its obligations; monitor compliance with GDPR and internal policies, including training and audits; advise on data protection impact assessments and monitor their performance; and act as the contact point for the supervisory authority. All of it with due regard to the risk of the processing involved — effort is meant to scale with risk, not spread evenly.

Two features of that list matter commercially. It’s advisory and supervisory rather than executive, so appointing a DPO monitors compliance without transferring legal responsibility for achieving it — the controller stays on the hook. And the artifacts the role depends on (records of processing, impact assessments, retention schedules, training records) are things the organisation produces and the DPO oversees. A DPO appointed into a company with none of that in place spends the first six months building a foundation rather than monitoring one.

Which leads to the most instructive enforcement pattern in this area — it isn’t about companies that failed to appoint anyone, it’s about companies that appointed someone and then failed to support them. Article 38 requires organisations to involve the DPO properly and in a timely manner in all personal-data matters, to provide the resources to carry out the role, and to maintain their expert knowledge. Regulators have treated failure on these support obligations as a contravention in its own right. A DPO who learns about a new data-processing feature after it ships, or who has no budget and no access to leadership, is a compliance box ticked and a compliance function absent.

The associated penalties sit in GDPR’s lower tier — up to €10 million or 2 percent of global annual turnover, the band for procedural rather than substantive violations. That ceiling is theoretical for most companies; actual enforcement has been more modest but real. Spain’s supervisory authority fined a security company €50,000 for failing to appoint a DPO. Italy’s regulator issued a €75,000 fine to a government ministry in a case combining unlawful disclosure of thousands of individuals’ data with the absence of a DPO. The pattern in both is worth noting: the missing DPO wasn’t discovered by proactive audit — it surfaced alongside some other failure that had already drawn a regulator’s attention.

Running the Test

A workable sequence for answering the question properly:

**Write down your core activities first**, before looking at the criteria at all — specifically, which processing operations are inseparable from delivering your product. Doing this before reading the triggers reduces the temptation to define your way to the answer you want.

**Test each core activity against both substantive triggers.** Does it involve regular and systematic monitoring of individuals? Does it involve special category or criminal-offence data? Ancillary processing — HR, payroll, your own marketing list — sits outside this analysis.

**Weigh the large-scale factors together**, not individually: number of data subjects, volume and variety of data, duration and permanence, geographic reach. Record the weighing, not just the verdict.

**Document whichever conclusion you reach**, with a date and a named review trigger tied to product or market changes rather than a vague annual reminder.

**If the answer is yes, treat appointment as the beginning.** The role needs independence, reporting access to senior leadership, budget, and genuine involvement in product decisions before they ship. The foundational privacy programme work — records of processing activities, impact assessments, internal policies, staff training — is what the DPO oversees, and it doesn’t build itself.

The question “do we need a DPO?” is asked as though it has a binary answer, and technically it does. But the useful output of asking it isn’t the yes or no. It’s the documented reasoning underneath — which is the thing you’ll actually be asked for, by a regulator or by a customer, on a day when producing it quickly matters a great deal.