When GDPR Requires You to Appoint a DPO

GDPR makes a data protection officer mandatory in exactly three situations, listed in Article 37(1): you are a public authority or body; your core activities involve regular and systematic monitoring of data subjects on a large scale; or your core activities involve large-scale processing of special categories of data or criminal conviction data. Everyone else may appoint voluntarily, and member states can add their own triggers, which Germany has done with a headcount rule that catches many ordinary companies. The tests turn on three phrases, core activities, large scale, and regular and systematic monitoring, none of which the regulation defines, so the working definitions come from EDPB guidance. Here is how each trigger reads in practice, plus the two traps around voluntary appointments and conflicts of interest.

Trigger one: public authorities and bodies

The clean one. Every public authority needs a DPO regardless of size or what it processes, with courts acting in their judicial capacity carved out. A charter school, a public hospital, and a municipal utility all need one. The edge cases are private companies performing public tasks, in areas like transport, water, energy, and housing, where several member states extend the requirement and the EDPB recommends appointment as good practice anyway. A private company whose only government connection is selling software to governments is not caught by this trigger.

Trigger two: regular and systematic monitoring at large scale

This is the trigger that catches technology companies. The EDPB reads monitoring broadly: behavioral advertising and retargeting, profiling and scoring for credit or insurance pricing, location tracking through apps, loyalty programs, connected devices reporting usage, telematics, wearables, and security monitoring delivered as a service. Regular and systematic means recurring by design rather than incidental, which describes essentially every analytics-driven product.

Concrete cases. An ad tech platform profiling users across sites needs a DPO without argument. A fleet telematics provider tracking driver behavior for insurers does too. A B2B SaaS product whose telemetry continuously monitors its customers' employees at scale is in scope, and this one surprises boards regularly, because the data subjects are users inside client companies rather than consumers. A small agency running one client's retargeting campaigns is doing monitoring, but likely fails the large-scale test on volume alone.

Trigger three: special categories at large scale

Special categories under Article 9: health data, biometrics used for identification, genetics, sexual orientation, religious and political beliefs, trade union membership. Article 10 adds criminal conviction and offense data. Core-activity processing of these at scale means a DPO. Telehealth platforms, digital therapeutics companies, insurers underwriting health risk, biometric access control vendors, background-screening providers, and benefits platforms handling occupational health data across many client organizations are all caught. A hospital is the EDPB's own example of large scale; an individual physician's practice is its example of not large scale. Most B2B companies touch some special-category data incidentally, an employee's sick note, a dietary requirement at an offsite, and incidental is the point: that is not your core activity.

What large scale actually means

The EDPB declines to set numbers and instead names four factors: the number of data subjects affected, as a count or as a share of a population; the volume and range of data items; the duration or permanence of the processing; and its geographic extent. The guidance's own illustrations run the same direction: a hospital's patient data, a city transit system's travel cards, an insurer's or bank's customer base, and a search engine's behavioral advertising are large scale; one lawyer's client files and one doctor's patients are not. In the space between the poles you make a judgment, and critically, you write it down. A documented conclusion that you assessed Article 37 and no DPO is required is itself something supervisory authorities expect to see, and companies that never ran the analysis start any regulatory conversation from a worse position.

Core activities, not everything you do

Core activities are the processing operations your business model actually depends on, not the unavoidable administration that comes with employing people. The EDPB's example: a hospital's core activity is healthcare, which cannot be delivered without processing patient records, so that processing is core. Payroll and standard IT support are ancillary for nearly everyone. This is why holding employee data does not by itself trigger a DPO, and also why processing only your customers' data as a processor does not exempt you: Article 37 applies to processors on the same tests. A managed security vendor monitoring client networks is doing core-activity monitoring even though every monitored person belongs to someone else.

Member states can add triggers, and Germany did

Article 37(4) lets national law require DPOs in additional cases. Germany's BDSG Section 38 is the one that matters at scale: a DPO is required whenever at least 20 people are regularly involved in the automated processing of personal data. In a software company that means roughly everyone with production, support, or CRM access, so a 30-person German subsidiary can trigger the duty with no monitoring and no special categories anywhere in sight. German law also requires a DPO where processing is subject to a data protection impact assessment, regardless of headcount. Spain lists specific sectors in its national law, and several other member states have narrower additions. If you operate through EU subsidiaries, run the DPO analysis per establishment and per national law, not just once against the regulation.

The voluntary appointment trap

Appointing a DPO you were not required to appoint is lawful and sometimes wise. The trap is that the moment you designate someone as a DPO, all of Articles 37 to 39 attach in full: independence, direct reporting to the highest level of management, protection from dismissal or penalty for performing the tasks, adequate resources, mandatory involvement in all data protection questions, and contact details published and communicated to the supervisory authority. The EDPB is explicit that a voluntary DPO carries the same obligations as a mandatory one. If what you want is a privacy lead without the statutory regime, use a different title, privacy manager or privacy counsel, and reserve the DPO designation for a deliberate decision rather than a nice-sounding line on an org chart.

Who can actually hold the job

Article 38(6) allows the DPO to hold other tasks, provided none create a conflict of interest, and Article 38(3) forbids the DPO from receiving instructions on how to perform the role. The consistent regulatory reading: anyone who determines the purposes and means of processing cannot be the DPO. That rules out the CEO and COO, and in practice the CTO, the CISO, and the heads of marketing, HR, and IT, because each decides how personal data gets processed and would be marking their own homework. The general counsel is a recurring bad fit for a different reason: the GC's duty is to defend the company's position, while the DPO's duty runs to compliance and to data subjects, and a breach or a dispute makes those visibly diverge. None of this is theoretical. The Belgian supervisory authority fined a company 50,000 euros in 2020 because its head of compliance, risk, and internal audit also served as DPO, and the combination was held to be a conflict on its face. The workable options are an internal appointee with real independence, standing, and resources, or an external DPO engaged for the role, which Article 37(6) expressly permits.

One DPO can cover a group

Article 37(2) lets a group of undertakings appoint a single DPO, provided that person is easily accessible from each establishment, and Article 37(3) does the same for clusters of public bodies. Accessible means reachable in practice: data subjects and regulators in each country can contact the DPO, in a language they can use, and the DPO can actually see the processing that happens locally. For a multi-entity company this is usually the sensible structure, one appointment communicated to each relevant supervisory authority rather than a DPO per subsidiary. It also concentrates the independence problem in one place, which is easier to protect than five. The same logic is what makes the external model work: one qualified officer, formally designated, covering the group under a contract that guarantees the independence Article 38 requires.

Where BD Emerson fits

An external appointment solves the conflict problem and staffs the role with someone who has handled supervisory authority correspondence before. We provide that through DPO as a service and a virtual data protection officer offering, both covering the Article 39 duties: monitoring compliance, advising on impact assessments, training, and serving as the contact point for regulators and data subjects. If the analysis above leaves you unsure whether you are caught at all, that documented Article 37 assessment is part of our GDPR compliance consulting. The two outcomes worth avoiding are appointing a conflicted executive because the org chart made it convenient, and discovering the German headcount rule after the subsidiary passes 20 people. Both cost more to unwind than to prevent.