Article 37 — Designation of the data protection officer

ARTICLE 37 GDPR: DESIGNATION OF THE DATA PROTECTION OFFICER

Detailed Commentary, Explanations, Examples, Illustrations and Practical Nuances

1. The basic architecture of Article 37

Article 37 is the starting point for understanding the Data Protection Officer under the GDPR.

At first sight, the provision appears relatively straightforward. It identifies circumstances in which a controller or processor must designate a DPO, explains when one DPO can serve multiple organisations, establishes the professional requirements for the position, permits both internal and external DPOs, and requires the DPO's contact details to be made available.

In practice, however, Article 37 is much more sophisticated.

The provision performs two different legal functions.

First, it establishes when the appointment of a DPO is mandatory.

Second, it establishes the institutional conditions necessary for that DPO to function effectively.

This distinction is important.

The question under paragraph 1 is:

"Must this organisation have a DPO?"

The questions under paragraphs 2 to 7 are largely:

"If there is a DPO, how can that DPO be organised, qualified, positioned and made accessible?"

That means Article 37 should not be read as merely a hiring provision. It is really an organisational accountability provision.

The DPO is intended to provide an internal mechanism through which data protection compliance is continuously monitored, questioned and improved.

This is particularly important because the GDPR does not treat compliance as a one-time exercise. A controller cannot simply conduct one GDPR audit, adopt a privacy policy and declare itself compliant. Processing activities change, technologies change, purposes change, vendors change, risks change and regulatory expectations change.

The DPO therefore operates as a continuing institutional privacy function.

This explains why Article 37 must be read together with Articles 38 and 39:

• Article 37 asks when a DPO must or may be designated and what qualifications the DPO must possess.

• Article 38 determines the DPO's position, independence, resources and protection.

• Article 39 defines the DPO's actual tasks.

A useful conceptual formula is:

Article 37 = designation Article 38 = position and independence Article 39 = functions and responsibilities

The three provisions therefore form a single legal architecture.

2. Who is responsible for designating the DPO?

Article 37 applies to both controllers and processors.

This is an important point because the DPO obligation is not limited to organisations that determine the purposes and means of processing.

A processor may independently be required to appoint a DPO.

Illustration

Suppose:Company A is a hospital. It determines why patient information is processed and therefore acts as a controller. It engages: Company B, a specialist cloud company, to host and process patient records. Company B is a processor.

If Company B's own processing activities satisfy Article 37(1), Company B may have its own mandatory DPO.

The fact that Company A has a DPO does not automatically satisfy Company B's obligation.

This is an important distinction.

Controller's DPO and processor's DPO are not interchangeable

The GDPR does not create a rule saying:

"If the controller has a DPO, the processor does not need one."

Instead, the Article 37 test must be applied separately to the relevant organisation.

Example

a small retailer may have only a few hundred customers and therefore not satisfy the large-scale criteria.

But suppose that retailer uses a processor whose business consists of providing behavioural advertising technology to thousands of businesses across Europe.

The retailer might not need a DPO.

The processor might.

Practical lesson

The DPO assessment should therefore be performed at the level of the individual controller or processor, rather than simply at the level of the overall data ecosystem.

This becomes particularly important when conducting vendor due diligence.

A privacy team should not ask only:

"Does our vendor comply with GDPR?"

It should also ask:

"Does the vendor's own processing profile trigger Article 37?"

That can reveal an important distinction between a processor that merely performs limited processing for one client and a processor whose entire business model involves large-scale monitoring or sensitive-data processing.

3. The expression "shall designate"

The words "shall designate" are mandatory.

Where Article 37(1) applies, the organisation does not have discretion to say:

"We understand that a DPO would be useful, but we prefer not to appoint one."

The obligation is triggered by law.

The organisation may have flexibility regarding:

• who performs the function;

• whether the DPO is internal or external;

• whether the DPO is full-time or part-time;

• whether the DPO is supported by a team;

• how the DPO is operationally integrated into the organisation.

But it does not have flexibility regarding whether the statutory obligation exists.

A crucial distinction

There is an important difference between:

"The organisation has appointed someone who performs privacy work."

and:

"The organisation has formally designated that person as its GDPR DPO."

These are not necessarily the same.

An organisation might have:

• a privacy manager;

• chief privacy officer;

• compliance officer;

• legal counsel;

• information security officer;

• data governance manager.

One of these individuals may perform many DPO-type functions.

But if the organisation is legally required to designate a DPO, it must ensure that the person is actually designated as the DPO and that the requirements of Articles 37, 38 and 39 are satisfied.

This matters because the statutory DPO enjoys a particular legal position, including independence and protection against interference under Article 38.

4. Must the designation be in writing?

The GDPR does not prescribe a particular formal instrument through which the designation must occur.

In other words, Article 37 does not say:

"The controller shall execute a written DPO appointment letter."

Nevertheless, from an accountability perspective, a documented designation is extremely important.

Imagine an organisation is investigated by a supervisory authority.

The organisation says:

"We have a DPO."

The authority asks:

"Who?"

The organisation identifies an employee.

The authority asks:

"When was this person appointed?"

No document exists.

The authority asks:

"What were the person's responsibilities?"

The organisation produces an outdated job description that never refers to the GDPR DPO function.

The authority asks:

"How was the organisation's decision that Article 37 applied documented?"

Nothing exists.

Even if the absence of a written appointment does not automatically invalidate the designation, the organisation has created a serious accountability problem.

The principle is therefore:

Legal validity and demonstrability are different questions.

A robust organisation should maintain documentation showing:

1. why Article 37 applies;

2. who was designated;

3. when the designation occurred;

4. whether the DPO is internal or external;

5. the DPO's reporting line;

6. the resources provided;

7. the DPO's contact details;

8. the DPO's qualifications;

9. conflicts-of-interest analysis;

10. arrangements for covering the DPO's absence.

This documentation becomes particularly important when the organisation has concluded that no DPO is required.

A negative conclusion should also be capable of being demonstrated.

5. Article 37(1): The three mandatory situations

Article 37(1) establishes three principal situations.

A DPO must be designated where:

1. processing is carried out by a public authority or body, subject to the judicial exception;

2. the core activities involve regular and systematic monitoring of data subjects on a large scale;

3. the core activities involve large-scale processing of special-category data or criminal-conviction/offence data.

These should be treated as separate legal tests.

An organisation does not need to satisfy all three.

Satisfying any one of the applicable conditions is sufficient.

Illustration

Company X:

• is privately owned;
• does not operate as a public authority;
• does not engage in large-scale monitoring;
• processes health data concerning millions of individuals. The first two conditions may not apply.

But Article 37(1)(c) may independently trigger the DPO obligation.

Conversely:

Company Y:

• does not process special-category data on a large scale;

• but operates a massive online advertising platform;

• continuously tracks users across websites and applications.

Article 37(1)(b) may trigger the obligation.

The three limbs should therefore be analysed independently.

6. Article 37(1)(a): Public authorities and bodies

The first category is comparatively broad.

Where processing is carried out by a public authority or body, the DPO requirement generally applies, except for courts acting in their judicial capacity.

The rationale is institutional rather than simply quantitative.

A public authority may process personal data in circumstances where individuals have limited ability to avoid that processing.

Illustration

Consider a government department administering:

• taxation;
• social security;
• immigration;
• licensing;
• public education;

• public healthcare;

• welfare benefits.

Individuals often cannot simply say:

"I do not want this organisation to process my data."

The processing may be necessary for the exercise of public authority or performance of a public task.

The DPO requirement therefore acts as an additional institutional safeguard.

The GDPR does not require the public authority first to prove that its processing is "high risk" before Article 37 applies.

This is a significant difference from the private-sector tests in Article 37(1)(b) and (c).

7. What is a "public authority or body"?

The GDPR does not provide a single exhaustive definition of the phrase.

Consequently, national law becomes relevant.

The concept may encompass:

• central government authorities;

• regional authorities;

• municipalities;

• public agencies;

• public institutions;

• other bodies governed by public law.

The difficult cases arise where a private organisation performs a function that resembles a public function.

Example

private public-service provider Suppose a privately incorporated company operates a public transport network under a statutory concession. It may process:

• passenger identities;
• travel-card information;
• location information;

• payment data;

• journey histories.

The organisation may perform an important public-service function.

However, the fact that an organisation performs a public task does not automatically mean that it is itself a "public authority or body" for Article 37(1)(a).

The classification must be determined under the relevant legal framework.

Nevertheless, even where Article 37(1)(a) does not strictly apply, the organisation may still fall within Article 37(1)(b) because transport systems can involve extensive monitoring.

This illustrates an important practical principle:

Failure to qualify as a public authority does not necessarily mean that Article 37 is irrelevant.

The organisation must still examine the other limbs.

8. Why courts are treated differently

Article 37(1)(a) expressly excludes courts when they act in their judicial capacity.

The distinction is important.

A court performs different institutional functions.

Judicial function

A judge processing information in order to:

• adjudicate a dispute;

• assess evidence;

• issue a judgment;

• conduct judicial proceedings;

is acting within the judicial function.

The GDPR therefore does not require that processing to be subject to the ordinary DPO requirement under Article 37(1)(a).

Administrative function

But courts also have administrative operations.

For example:

• payroll;

• employee management;

• recruitment;

• IT administration;

• building security;

• procurement.

Those activities are different from adjudication.

Therefore, the judicial exception should not be understood as:

"Courts never need a DPO."

That would be too broad.

The critical question is:

In what capacity is the relevant processing being carried out?

This functional distinction is essential.

9. Article 37(1)(b): Regular and systematic monitoring on a large scale

This is one of the most difficult parts of Article 37.

Four concepts must effectively be analysed:

Core activities + monitoring + regular and systematic + large scale.

Each has a separate role.

A common mistake is to see any tracking activity and immediately conclude:

"DPO required."

That is incomplete.

The monitoring must form part of the relevant core activities, and the monitoring must be on a large scale.

10. What does "monitoring" mean?

Monitoring generally refers to observing, tracking or evaluating individuals over time.

It can include:

• tracking;

• profiling;

• behavioural analysis;

• location monitoring;

• online activity monitoring;

• scoring;

• surveillance;

• behavioural advertising.

Importantly, monitoring does not have to mean that a human being is physically watching someone.

Automated monitoring can qualify.

Example

online advertising Suppose an advertising platform records:

• websites visited;
• searches;
• clicks;
• purchases;

• location;

• device information;

• browsing behaviour.

It creates a behavioural profile and uses the profile to predict interests.

No employee may ever personally inspect the individual's entire history.

The monitoring is nevertheless automated.

Therefore:

Human observation is not necessary for monitoring.

11. What does "regular" mean?

"Regular" generally captures persistence, repetition or recurrence.

It may involve processing that is:

• continuous;

• recurring;

• periodic;

• repeated at fixed intervals;

• ongoing over a period.

Example 1

continuous monitoring A mobile application continuously collects location information. This is plainly regular.

Example 2

periodic monitoring A fitness application collects health and location information every five minutes. Even though the collection is not literally continuous, it is repeated according to a predictable pattern. It can therefore be regular.

Example 3

isolated collection A company collects a person's identity information once to issue a single invoice. That is not ordinarily "regular monitoring." The critical idea is persistence or repetition.

12. What does "systematic" mean?

"Systematic" focuses more on the organised nature of the monitoring.

Monitoring is systematic where it is:

• planned;

• structured;

• organised;

• methodical;

• conducted according to a general strategy;

• integrated into a data collection system.

Example

An e-commerce platform records every customer's:

• searches;
• product views;
• abandoned carts;
• purchases;
• time spent on products.

It then uses an algorithm to generate personalised recommendations.

This is systematic because the monitoring is built into the platform's architecture.

It is not an accidental observation.

Contrast

Suppose a small shopkeeper occasionally notices which products customers appear interested in.

That does not automatically become systematic monitoring merely because the shopkeeper observes customers.

The monitoring must be considered in the context of the actual processing operation.

13. Examples of regular and systematic monitoring

The concept can cover a very wide range of technologies.

Examples

include:

Telecommunications

Telecommunications providers necessarily process information concerning communications, traffic and sometimes location.

Behavioural advertising

Advertising networks monitor online behaviour to construct advertising profiles.

Credit scoring

A financial institution may continuously analyse an individual's financial behaviour to assess creditworthiness.

Fraud detection

Banks may monitor transactions to identify suspicious patterns.

Insurance

An insurer may analyse behavioural or telematics data to calculate risk.

Location tracking

Mobile applications may continuously or periodically collect location data.

Loyalty programmes

Retailers may analyse purchasing histories to understand customer behaviour.

CCTV

Large-scale surveillance systems may monitor individuals across physical spaces.

Wearable devices

Fitness or health platforms may monitor activity patterns over time.

Connected devices

Smart meters, smart vehicles and home automation systems may continuously generate behavioural information.

The important point is that the monitoring concept is technologically neutral.

It does not matter whether the monitoring occurs through:

• a website;

• a mobile application;

• CCTV;

• sensors;

• wearables;

• vehicles;

• telecommunications infrastructure;

• algorithms.

The legal question is what the processing actually does.

14. "Large scale" is the second half of the test

Regular and systematic monitoring is not enough.

It must also be conducted on a large scale.

The GDPR does not provide a numerical threshold such as:

"More than 100,000 individuals = large scale."

This is deliberate.

A rigid numerical threshold would become outdated quickly and could produce arbitrary results across different sectors.

Instead, the assessment is contextual.

Four particularly important factors are:

1. number of data subjects;

2. volume and range of personal data;

3. duration or permanence;

4. geographical extent.

15. Factor 1: Number of data subjects

The first question is:

How many people are being monitored or whose data are being processed?

Clearly, millions of individuals strongly indicate large-scale processing.

But the number cannot be considered in isolation.

Example

A national health system may process data relating to millions of residents. That strongly indicates large scale. But consider a specialist cancer clinic processing extremely detailed health information about 15,000 patients. Although the number is smaller, the processing may still be large scale depending on the other factors. Therefore:

Large scale is not simply synonymous with "huge number of people."

16. Factor 2: Volume and range of data

The second question is:

How much data is being processed, and how varied is it?

Processing:

• name;

• email address;

• customer number

is materially different from processing:

• location;

• browsing behaviour;

• purchase history;

• financial information;

• biometric information;

• health information;

• behavioural profiles.

The greater the volume and diversity of information, the stronger the indication of large-scale processing.

Illustration

Company A stores the names and telephone numbers of 500,000 customers. Company B stores detailed behavioural profiles of 100,000 customers, including:

• location;
• purchasing behaviour;
• online activity;
• preferences;

• inferred interests;

• device information.

It would be wrong automatically to conclude that Company A's processing is necessarily more significant simply because it has more individuals.

The nature and range of data matter.

17. Factor 3: Duration and permanence

The third factor concerns time.

Processing that occurs:

• once;

• briefly;

• for a single transaction

is different from processing that continues:

• for years;

• indefinitely;

• continuously;

• throughout a customer relationship.

Example

A company collects passport information once to verify identity for a single transaction. Compare that with an online platform that continuously tracks a user's behaviour for ten years. The second operation has a much stronger large-scale monitoring profile. Duration also matters because prolonged monitoring can create a much more comprehensive picture of an individual.

18. Factor 4: Geographical extent

The fourth factor concerns geographic scope.

Processing may occur at:

• local level;

• regional level;

• national level;

• EU-wide level;

• global level.

Example

A CCTV system covering a small private office is very different from a nationwide surveillance network. Likewise: A small local retailer serving 500 customers is different from a global online platform serving users across Europe and elsewhere. Geographical reach therefore contributes to the overall assessment.

19. Large scale is a contextual assessment, not a mathematical formula

The four factors should not be mechanically added.

There is no formula such as:

number × volume × duration × geography = large scale.

Instead, the factors are considered together.

Example

Imagine a company processes information about 50,000 people. The processing:

• occurs continuously;
• includes location and behavioural data;
• operates nationwide;
• is central to the company's business model.

That may strongly support a finding of large-scale monitoring.

Another company might process information about 500,000 people but only collect a minimal identifier once for a one-off administrative purpose.

The second operation does not necessarily involve the same kind of monitoring.

The legal analysis therefore requires substance rather than arithmetic.

20. Core activities: perhaps the most misunderstood concept

The word "core" is extremely important.

Article 37(1)(b) and (c) do not say:

"If the organisation processes personal data."

Almost every modern organisation processes personal data.

Instead, they refer to processing forming part of the organisation's core activities.

The purpose is to distinguish between:

primary business operations

and

ancillary administrative functions.

21. What are core activities?

The core activity generally refers to the operations that are central to achieving the organisation's objectives.

A useful question is:

Could the organisation realistically carry out its principal business or public function without this processing?

If the answer is no, the processing may be closely connected to its core activities.

Hospital example

A hospital's primary purpose is healthcare.

Patient health records are essential to:

• diagnosis;

• treatment;

• clinical decision-making;

• continuity of care;

• medical administration.

Although "processing health data" is not literally the hospital's commercial product, processing health data is inseparable from providing healthcare.

Therefore, patient-data processing can constitute a core activity.

22. Core activities do not have to be the company's "product"

This is a crucial nuance.

Suppose a hospital says:

"Our core activity is healthcare, not data processing."

That argument is too simplistic.

The relevant question is not whether the organisation sells data.

The question is whether processing personal data is inextricably connected with the principal activity.

Another example: bank

A bank's core business is financial services.

But it cannot conduct banking without processing:

• identity information;

• account information;

• transaction data;

• financial information.

The processing is therefore integral to the business.

23. Ancillary processing

Now consider ordinary employee administration.

Almost every organisation processes:

• employee names;

• payroll data;

• attendance information;

• tax information;

• contact details.

These activities are necessary for running the organisation.

But necessity in the broad sense does not automatically make them a "core activity" for Article 37.

Otherwise, almost every organisation would automatically require a DPO because every organisation processes employee data.

The distinction is therefore between:

processing that enables the organisation's principal activity

and

processing that is the principal activity or an inseparable component of it.

Example

A manufacturing company employs 2,000 people. It processes employee payroll information. That does not ordinarily mean that the company's core activity is processing employee personal data. Its core activity is manufacturing. Payroll is an essential administrative function, but generally ancillary.

24. The "inextricable part" principle

The strongest way to understand core activities is to ask whether the processing is an inextricable part of the organisation's main activity.

Hospital

Healthcare cannot be provided properly without processing patient health information.

Bank

Banking cannot function without processing financial information.

Search engine

A search engine's business model may fundamentally depend upon analysing user activity and behaviour.

Advertising platform

Behavioural monitoring and profiling may be at the centre of the business.

Cloud processor

A cloud service provider may process customer data as part of providing its central service.

The same word "processing" therefore produces very different Article 37 outcomes depending on the organisational context.

25. A useful examination technique for "core activities"

When analysing a problem question, ask four questions:

Question 1

What is the organisation's principal purpose?

Question 2

What processing is necessary to achieve that purpose?

Question 3

Is the processing merely administrative support?

Question 4

Or is the processing integral to delivering the organisation's principal service?

This approach is more reliable than asking simply:

"Does the organisation process personal data?"

26. Article 37(1)(c): Special-category and criminal-offence data

The third mandatory category addresses particularly sensitive processing.

The organisation must appoint a DPO where its core activities consist of large-scale processing of:

• special categories of personal data under Article 9; or

• personal data concerning criminal convictions and offences under Article 10.

This provision reflects the heightened risks associated with such information.

27. Special-category data

Article 9 covers categories such as:

• racial or ethnic origin;

• political opinions;

• religious or philosophical beliefs;

• trade-union membership;

• genetic data;

• biometric data for uniquely identifying a person;

• health data;

• sex life;

• sexual orientation.

The fact that an organisation processes one of these categories does not automatically trigger Article 37(1)(c).

There are three important elements:

1. the processing must concern the relevant type of data;

2. the processing must be on a large scale;

3. the processing must form part of the organisation's core activities.

All three aspects matter.

28. Example: small medical practice

Imagine a small doctor operates a private practice.

The doctor processes health data concerning patients.

Health data are special-category data.

But the practice may not process health data on a sufficiently large scale to trigger Article 37(1)(c).

This does not mean the doctor has no GDPR obligations.

The doctor remains subject to the GDPR.

It simply means that Article 37(1)(c) may not independently make appointment of a DPO mandatory.

This distinction is extremely important.

The DPO obligation is not the same thing as the GDPR's general compliance obligation.

29. Example: national hospital network

Now imagine a healthcare network operating hospitals across several regions and processing medical records for millions of patients.

Here:

• the data are health data;

• health-data processing is integral to healthcare;

• the number of individuals is very large;

• processing is continuous;

• the geographic scope is substantial.

The Article 37(1)(c) conditions are much more clearly satisfied.

A DPO is therefore mandatory.

30. Criminal-conviction and offence data

Article 37(1)(c) also expressly covers data relating to criminal convictions and offences referred to in Article 10.

Example

A large background-screening company provides criminal-record screening services to employers. Its business depends substantially upon processing information concerning criminal convictions. If that processing is large scale and forms part of its core activities, Article 37(1)(c) is strongly implicated. Again, the analysis is not: "Does the company process criminal-record data?" It is:

"Does the company's core activity consist of processing such data on a large scale?"

31. The distinction between Article 9 and Article 10

Article 9 deals with special categories of personal data.

Article 10 concerns criminal convictions and offences.

They should not be collapsed into one category.

This distinction matters because Article 10 has its own regulatory architecture and is not technically part of Article 9's list of special categories.

Article 37(1)(c), however, expressly brings both within the mandatory DPO trigger.

32. A major practical trap: "any sensitive data = mandatory DPO"

This is incorrect.

Consider a technology company with 20 employees.

It has:

• employee health information;

• emergency contact information;

• limited sick-leave records.

The company processes special-category data.

But that fact alone does not automatically satisfy Article 37(1)(c).

The processing must also be:

• core;

• large scale.

Therefore:

Sensitive data is a necessary part of this limb, but it is not by itself sufficient.

33. Voluntary appointment under Article 37(4)

Article 37 does something particularly useful.

Even when Article 37(1) does not require a DPO, an organisation may voluntarily appoint one.

This is important because the DPO can be valuable even outside mandatory situations.

Example

a medium-sized technology company may not technically cross the Article 37 threshold but may still decide to appoint a DPO because:

• it operates in multiple countries;

• it processes substantial personal data;

• it conducts AI-related profiling;

• it expects regulatory scrutiny;

• it wants a central privacy governance function;

• its customers demand DPO oversight.

The organisation can voluntarily establish the role.

34. The major consequence of voluntarily calling someone a DPO

This is a subtle but extremely important point.

An organisation should not casually say:

"We have appointed a DPO."

If the person is formally designated as the DPO, the GDPR's DPO framework applies.

That means the organisation cannot simply use the title while denying the corresponding statutory position.

The person should benefit from the safeguards and independence required under Articles 38 and 39.

Therefore, organisations sometimes deliberately distinguish between:

Data Protection Officer

and

Privacy Manager / Privacy Counsel / Data Protection Manager.

This can be sensible where the organisation is not legally required to appoint a DPO and does not intend to create the formal statutory DPO position.

But the terminology must not be used to evade an actual Article 37 obligation.

35. Article 37(2): One DPO for a group of undertakings

Large corporate groups often operate through multiple legal entities.

For example:

GlobalTech Group

may contain:

• GlobalTech Germany GmbH;

• GlobalTech France SAS;

• GlobalTech Spain SL;

• GlobalTech Italy SRL;

• GlobalTech Netherlands BV.

Each entity may have GDPR obligations.

Article 37(2) permits the group to designate a single DPO, provided that the DPO is easily accessible from each establishment.

This is an important efficiency mechanism.

The GDPR does not necessarily require:

one company = one DPO.

Instead:

one appropriately structured DPO function can serve multiple group entities.

36. Why accessibility is the condition

The group-DPO mechanism would be meaningless if a DPO were formally appointed but practically unreachable.

Suppose the group appoints one DPO in Germany.

The French entity has a serious data breach at 2 a.m.

The DPO is:

• difficult to reach;

• unfamiliar with the French operation;

• unable to communicate with French employees;

• unavailable for urgent consultations.

Merely saying:

"We have a Group DPO"

does not solve the problem.

Accessibility is therefore substantive.

It means the DPO must be capable of actually performing the function for each establishment.

37. Accessibility has several dimensions

Accessibility should be understood in at least four ways.

Physical or organisational accessibility

The DPO must be sufficiently connected to the establishments they serve.

Communication accessibility

Employees, data subjects and regulators must have practical channels for contacting the DPO.

Temporal accessibility

The DPO must be sufficiently available when matters require intervention.

Linguistic accessibility

Where relevant, the DPO must be able to communicate effectively with the affected data subjects, staff and supervisory authorities.

Therefore:

Publishing an email address is not the same thing as being genuinely accessible.

38. Group DPO: one person does not necessarily mean one-person operation

Another important nuance is that a "single DPO" does not mean that the DPO must personally perform every task without assistance.

A group DPO may be supported by:

• privacy lawyers;

• compliance professionals;

• privacy analysts;

• security specialists;

• local privacy coordinators;

• administrative staff.

The DPO remains the responsible designated function, but an appropriate support structure can make the function effective.

This is especially important for multinational organisations.

Illustration

A Group DPO serves 30 subsidiaries across Europe. It would be unrealistic to expect the DPO personally to:

• attend every meeting;
• answer every request;
• investigate every incident;
• conduct every DPIA;

• review every contract.

A privacy team can assist.

But the team should operate under a structure that preserves the DPO's independence and authority.

39. Article 37(3): Several public authorities

Article 37(3) creates a similar possibility for public authorities.

Several public authorities or bodies may designate a single DPO, taking into account:

• organisational structure;

• size.

Example

Several small municipalities may share a DPO. This can be efficient where:

• their processing activities are similar;
• they are geographically close;
• they have similar administrative structures;
• their combined workload is manageable.

But the arrangement must still allow the DPO to perform the Article 39 tasks effectively.

40. "Taking account of organisational structure and size"

This qualification is important.

Suppose a DPO is appointed for:

• three small municipalities.

That may be manageable.

Now imagine the same DPO is appointed for:

• 150 large public bodies;

• multiple ministries;

• several thousand employees;

• millions of data subjects.

The formal designation may exist, but the practical capacity of the DPO may be inadequate.

Therefore:

The legal possibility of sharing a DPO does not eliminate the resource requirement.

41. Article 37(5): Professional qualities

Article 37(5) moves from the question:

"Does the organisation need a DPO?"

to:

"Who is capable of being the DPO?"

The GDPR does not prescribe a particular academic degree.

It does not say:

"The DPO must be a lawyer."

Nor does it say:

"The DPO must hold CIPP/E, CIPM or another certification."

Certifications may be evidence of expertise, but they are not the statutory test.

The legal standard is based on:

• professional qualities;

• expert knowledge of data protection law and practices;

• ability to fulfil Article 39 tasks.

42. Expertise is contextual

The level of expertise required depends on the organisation.

Imagine two organisations.

Organisation A

A small business with straightforward processing.

Organisation B

A multinational AI company processing:

• biometric information;

• behavioural data;

• children's data;

• large-scale profiling;

• international transfers;

• automated decision-making.

It would make little sense to demand exactly the same level of expertise from the DPOs of both organisations.

The second organisation presents:

• greater legal complexity;

• greater technological complexity;

• greater risk;

• more extensive processing;

• more complicated international issues.

The DPO therefore needs corresponding expertise and resources.

43. What should a competent DPO understand?

A competent DPO should understand much more than the text of the GDPR.

Depending on the organisation, relevant knowledge may include:

Legal knowledge

• GDPR;

• relevant national data protection law;

• sector-specific privacy rules;

• employment law where relevant;

• electronic communications law;

• rules on international transfers;

• rules governing surveillance or biometrics.

Practical privacy knowledge

• records of processing;

• DPIAs;

• data-subject rights;

• breach management;

• vendor management;

• privacy notices;

• retention;

• lawful bases;

• consent;

• privacy by design.

Technical understanding

The DPO does not necessarily need to be a cybersecurity engineer.

But the DPO should understand enough to engage meaningfully with:

• encryption;

• access controls;

• logging;

• pseudonymisation;

• cloud architecture;

• identity management;

• AI systems;

• data flows.

44. Business knowledge matters too

A technically brilliant privacy lawyer who understands no part of the business may not be an effective DPO.

Consider a bank.

The DPO should understand at least broadly:

• lending;

• payments;

• fraud detection;

• customer onboarding;

• credit scoring;

• financial crime compliance;

• customer service.

Why?

Because data protection advice must operate within the actual processing environment.

The DPO's job is not simply to say:

"GDPR says no."

The DPO should be capable of explaining:

"This processing creates these risks; here is the legal issue; here are the safeguards; here is how the organisation can achieve its objective while reducing the risk."

45. Ability to perform Article 39 tasks

Expert knowledge alone is not enough.

A person might be an outstanding privacy academic but still be a poor DPO if they cannot practically perform the role.

The DPO must be able to:

• advise management;

• monitor compliance;

• allocate responsibilities;

• raise concerns;

• support DPIAs;

• monitor DPIA implementation;

• cooperate with supervisory authorities;

• act as a contact point;

• communicate effectively with data subjects.

This is why Article 37(5) refers expressly to the ability to fulfil Article 39 tasks.

46. Personal qualities

The role requires more than technical knowledge.

A DPO may sometimes have to tell senior management:

"This project should not proceed in its current form."

That requires:

• confidence;

• integrity;

• independence;

• communication ability;

• professional judgment;

• willingness to challenge senior personnel.

A DPO who always agrees with management may be technically qualified but institutionally ineffective.

47. The DPO is not simply the company's "privacy policeman"

Another important nuance is that the DPO should not be conceptualised as an internal enforcement officer who personally controls every privacy decision.

The DPO's role is primarily:

• advisory;

• monitoring;

• supervisory;

• facilitative;

• communicative.

The controller remains responsible for compliance.

This is fundamental.

Example

A company unlawfully processes personal data. It cannot defend itself by saying: "Our DPO made a mistake." The DPO does not replace the controller's accountability. The controller retains responsibility for complying with the GDPR. The DPO helps the organisation achieve and demonstrate compliance.

48. Article 37(6): Internal or external DPO

The GDPR gives organisations flexibility.

A DPO may be:

Internal

An employee of the organisation.

External

A professional engaged under a service contract.

Both models can comply with Article 37.

49. Internal DPO example

A multinational company appoints its senior privacy counsel as DPO.

The person is already an employee.

This is permitted.

However, the organisation must still ensure that the person can perform the DPO function independently.

The person should not be placed in a position where their other responsibilities create an unacceptable conflict of interest.

50. External DPO example

A medium-sized company does not have sufficient internal expertise.

It engages an external privacy consultancy.

The consultancy provides:

• a designated lead DPO;

• privacy lawyers;

• analysts;

• breach-response support;

• DPIA assistance.

This can also satisfy Article 37.

The key issue is not whether the DPO sits inside the organisation.

The key issue is whether the DPO can actually perform the statutory function.

51. Can a DPO be part-time?

Yes, the role does not necessarily have to be full-time.

But part-time does not mean:

"The DPO is available for two hours a month regardless of organisational needs."

The amount of time and resources must correspond to the organisation's circumstances.

Example

A small organisation with relatively straightforward processing may require limited DPO time. A multinational technology company processing millions of users' data probably requires significantly more. The correct question is:Are sufficient time and resources available to perform the Article 39 tasks effectively?

52. External DPO does not mean "outsourcing responsibility"

This distinction is essential.

A company cannot say:

"We hired an external DPO, so GDPR compliance is now the DPO's responsibility."

That is legally and conceptually wrong.

The DPO advises and monitors.

The controller remains responsible.

Illustration

A company asks its DPO: "Can we launch this AI product?" The DPO advises on:

• lawful basis;
• transparency;
• DPIA;

• data minimisation;

• automated decision-making;

• retention;

• international transfers.

Management makes the final business decision.

If management ignores legitimate DPO advice, that does not automatically transfer responsibility to the DPO.

53. Conflict of interest: a major Article 37/38 issue

One of the most important practical questions is:

Can someone hold another role while also serving as DPO?

Potentially yes, but not where the other role creates a conflict with the DPO's duties.

The underlying concern is whether the person determines the purposes and means of processing while simultaneously being expected to monitor those decisions independently.

Classic example

Suppose the company's:

Chief Executive Officer

is also appointed as DPO.

The CEO determines major business strategies and decides how customer data will be processed.

The same person then has to independently monitor whether those decisions comply with GDPR.

That creates an obvious structural conflict.

54. Another conflict example

Consider a:

Head of Marketing

who determines:

• advertising strategy;

• customer profiling;

• targeting methods;

• data use.

The company appoints the same person as DPO.

Now the individual must monitor whether the marketing department's profiling practices comply with GDPR.

The conflict is obvious.

The person is effectively checking their own decisions.

This is inconsistent with the functional independence expected of the DPO.

55. Article 37 and Article 38 must be read together

Article 37 tells us about designation.

Article 38 tells us about the DPO's position.

Therefore, one cannot conclude:

"The person meets Article 37(5), so the appointment is automatically valid."

Not necessarily.

The organisation must also satisfy Article 38.

The DPO needs:

• independence;

• appropriate involvement;

• sufficient resources;

• access to management;

• protection against interference;

• protection against retaliation for performing DPO tasks.

56. The DPO must be able to challenge management

This is one of the most important practical implications.

Imagine the board proposes:

"Let's launch a system that profiles customers using extensive behavioural data."

The DPO identifies serious compliance risks.

The DPO advises:

"The system should not launch until the DPIA is completed and appropriate safeguards are implemented."

Management disagrees.

The DPO must be able to maintain that professional position without being punished simply because the advice is inconvenient.

This is why independence is not merely an abstract principle.

It is a practical requirement.

57. DPO dismissal and the Leistritz judgment

The Court of Justice addressed an important aspect of DPO protection in Leistritz AG v LH, C-534/20.

The case concerned the relationship between national employment law and the GDPR's protection of the DPO.

The Court explained the significance of the DPO's functional independence and the protection against dismissal or penalties connected with performing DPO tasks.

The important conceptual point is that the GDPR's protection is directed at preventing the organisation from effectively saying:

"You advised us against doing this, so we will remove you as DPO."

The protection is therefore closely connected to the independence of the function.

At the same time, DPO protection does not mean that a DPO becomes absolutely immune from all employment consequences.

A DPO can still be disciplined or dismissed for legitimate reasons unrelated to the performance of DPO duties, subject to applicable national law.

The key distinction is:

The employer cannot retaliate against the DPO merely because the DPO properly performs the DPO function.

58. Article 37(7): Publication of contact details

The final paragraph contains two separate obligations.

The organisation must:

1. publish the DPO's contact details; and

2. communicate those details to the supervisory authority.

These requirements have different audiences.

Publication

This primarily ensures accessibility for:

• data subjects;

• employees;

• other external persons.

Communication to the supervisory authority

This allows the DPA to know:

"Who is the organisation's DPO?"

The DPO therefore becomes an identifiable institutional contact point.

59. What does "contact details" mean?

A DPO contact mechanism should genuinely enable communication.

Depending on the circumstances, this may include:

• dedicated email address;

• telephone number;

• postal address;

• appropriate online contact mechanism.

For an online organisation, merely publishing:

"DPO: 123 Privacy Street"

may not be sufficiently practical.

A dedicated email address is far more useful.

60. Must the DPO's name be published?

The GDPR requires publication of contact details, not necessarily publication of the DPO's personal name.

An organisation may therefore publish:

dpo@company.com

rather than:

Jane Smith, DPO.

This can also have privacy and security advantages.

However, internally, employees should generally know who the DPO is and how to contact them.

The distinction is therefore:

External publication: contactability is the key requirement.

Internal organisation: identification of the person performing the DPO role is important.

61. A contact form is not necessarily enough

An organisation may provide:

"Contact our DPO" form.

That can be useful.

But the safest approach is to provide actual contact details as well.

For example:

DPO: dpo@example.com

and additionally:

Contact form: [DPO form]

The form can supplement the contact details.

It should not be used to make the DPO artificially difficult to reach.

62. Why accessibility matters for data subjects

Imagine a data subject wants to complain:

"I believe the company is using my health information unlawfully."

If the company's website contains:

• no DPO details;

• only a generic contact form;

• no identifiable privacy contact;

• no clear route for raising concerns,

the person faces unnecessary obstacles.

Article 37(7) is designed to prevent this.

The DPO is intended to be an accessible channel through which privacy concerns can reach the organisation.

63. DPO contact details and Articles 13 and 14

The DPO's contact details are often included in privacy notices.

This is logical because Articles 13 and 14 require information concerning the DPO where applicable.

Therefore, a privacy notice may contain something such as:

"If you have questions regarding the processing of your personal data or wish to contact our Data Protection Officer, please write to dpo@example.com."

This allows Article 37(7) and transparency obligations to operate together.

64. Communication with the supervisory authority

The second obligation is to communicate the DPO's details to the relevant supervisory authority.

This ensures that the authority knows whom to contact.

The requirement becomes particularly important during:

• investigations;

• consultations;

• complaints;

• DPIA-related issues;

• breach situations;

• regulatory correspondence.

The DPO should not become a barrier between the authority and management.

Instead, the DPO should facilitate communication.

65. The DPO as an institutional bridge

A useful way to understand the DPO is to think of the role as a bridge.

Inside the organisation

The DPO communicates:

GDPR → management → business teams

Outside the organisation

The DPO communicates:

organisation ↔ supervisory authority

Toward individuals

The DPO provides a channel:

data subject ↔ organisation

This makes the DPO a central node in the GDPR's accountability structure.

66. The DPO is not the same as the supervisory authority

This distinction is important.

The DPO is an internal or externally contracted organisational function.

The supervisory authority is a public regulatory body.

The DPO does not:

• issue administrative fines;

• exercise regulatory enforcement powers;

• act as a substitute for the DPA.

Instead, the DPO cooperates with the authority.

67. The DPO is not the data controller

Another common misunderstanding is to treat the DPO as the person responsible for deciding the purposes and means of processing.

That would confuse the DPO's role with the controller's role.

Suppose the company decides:

"We will collect customer location data to provide location-based services."

That decision belongs to the controller.

The DPO may advise on:

• necessity;

• proportionality;

• lawful basis;

• transparency;

• retention;

• security;

• DPIA.

But the DPO does not become the controller merely by advising.

68. The DPO is not a "compliance shield"

One of the biggest misconceptions in corporate practice is:

"If we appoint a DPO, we have demonstrated GDPR compliance."

Not necessarily.

The DPO is evidence of an appropriate governance structure.

But appointment alone does not prove substantive compliance.

A company with an excellent DPO can still violate the GDPR.

Conversely, a company without a mandatory DPO may have many other areas of compliance.

The DPO is one component of the broader accountability framework.

69. The DPO and accountability

Article 5(2) establishes the accountability principle.

Article 24 requires controllers to implement appropriate measures to ensure and demonstrate compliance.

Article 37 contributes to this structure by requiring a specialised privacy function in specified circumstances.

The relationship can therefore be represented as:

1. Article 5(2)
2. Accountability Article 24
3. Organisational responsibility Article 37
4. Designation of DPO Article 38
5. Independence and resources Article 39
6. Operational tasks

The DPO is therefore not an isolated GDPR requirement.

The provision forms part of the architecture through which organisations operationalise accountability.

70. A complete Article 37 assessment framework

When advising an organisation, the analysis should proceed systematically.

Step 1: Identify the organisation

Is it:

• controller;

• processor;

• public authority/body;

• private undertaking?

Step 2: Examine Article 37(1)(a)

Is processing carried out by a public authority or body?

If yes, examine the judicial exception.

Step 3: Examine Article 37(1)(b)

Ask:

1. What are the organisation's core activities?

2. Do those activities involve monitoring?

3. Is the monitoring regular?

4. Is it systematic?

5. Is it large scale?

Step 4: Examine Article 37(1)(c)

Ask:

1. Are Article 9 data involved?

2. Are Article 10 data involved?

3. Is processing large scale?

4. Is that processing part of the core activities?

Step 5: Check national law

Member State law may impose additional DPO requirements.

Step 6: Consider voluntary designation

Even if Article 37(1) does not apply, should the organisation voluntarily designate a DPO?

Step 7: Determine the organisational model

Should the DPO be:

• internal;

• external;

• group-wide;

• shared between public authorities?

Step 8: Assess accessibility

Can employees, data subjects and regulators actually reach the DPO?

Step 9: Assess qualifications

Does the person have appropriate:

• legal expertise;

• practical expertise;

• sector knowledge;

• technical understanding;

• organisational knowledge?

Step 10: Assess independence and conflicts

Does the person's other role create a conflict?

Step 11: Provide resources

Does the DPO have sufficient:

• time;

• staff;

• budget;

• information;

• access to management?

Step 12: Publish and communicate contact details

The organisation should complete the Article 37(7) requirements.

71. Worked example: online advertising platform

Consider:

AdTechCo

AdTechCo provides behavioural advertising services across Europe.

It collects:

• browsing behaviour;

• device identifiers;

• location;

• clicks;

• purchase behaviour;

• inferred interests.

It serves millions of individuals.

Step 1: Controller or processor?

Suppose AdTechCo determines its own advertising purposes and means.

It is a controller.

Step 2: Core activity?

Behavioural advertising is central to its business.

Yes.

Step 3: Monitoring?

The company tracks online behaviour.

Yes.

Step 4: Regular?

Tracking occurs continuously.

Yes.

Step 5: Systematic?

The tracking is algorithmically organised.

Yes.

Step 6: Large scale?

Millions of individuals, extensive data, continuous processing and international reach.

Very likely yes.

Conclusion

Article 37(1)(b) is strongly engaged. The organisation should designate a DPO.

72. Worked example: small accounting firm

Consider:

SmallTax Ltd

It has 10 employees and serves 200 local clients.

It processes:

• names;

• addresses;

• tax information;

• financial records.

It does not systematically monitor individuals.

Its processing is primarily necessary to provide accounting services.

Does it process personal data?

Yes.

Does it process financial information?

Yes.

Does it automatically need a DPO?

No.

The mere fact that personal and financially sensitive information is involved does not automatically trigger Article 37(1)(c).

The organisation must examine:

• whether any Article 9/10 data are processed;

• whether the relevant processing is large scale;

• whether it constitutes a core activity.

The answer may ultimately be that no mandatory DPO is required, while all other GDPR obligations remain fully applicable.

73. Worked example: hospital

Consider:

Regional Health Network

It operates several hospitals.

It processes:

• medical records;

• diagnoses;

• genetic information;

• prescriptions;

• treatment histories.

Millions of patient records are processed over long periods.

Core activity?

Healthcare.

Is health-data processing integral to healthcare?

Yes.

Large scale?

Yes.

Article 9 data?

Yes.

Conclusion

Article 37(1)(c) is strongly engaged. The organisation must designate a DPO.

74. Worked example: hospital's payroll department

Now isolate a different processing activity within the same hospital:

The payroll department processes employee:

• salaries;

• bank details;

• tax information.

This processing is not automatically analysed as the hospital's core activity for Article 37(1)(c).

The fact that the same organisation has one processing operation that triggers Article 37 does not mean that every individual processing activity must independently satisfy the test.

The relevant question is whether the organisation's core activities, viewed institutionally, satisfy the Article 37 test.

This is an important distinction between:

organisation-level assessment

and

individual-processing-level assessment.

75. Worked example: employee monitoring software

Consider a company that sells software allowing employers to monitor employees.

The software records:

• keystrokes;

• screen activity;

• login times;

• productivity scores;

• application use.

The software provider processes information for hundreds of employers.

Core activity?

Yes, monitoring is central to the service.

Regular?

Yes.

Systematic?

Yes.

Large scale?

Potentially yes, considering the number of employees monitored across the provider's customer base.

The provider may therefore fall within Article 37(1)(b).

This example demonstrates why processors must perform their own Article 37 analysis.

76. Worked example: CCTV

Consider two organisations.

Organisation A

A small office has two cameras covering the entrance.

Organisation B

A company operates CCTV infrastructure across hundreds of retail locations and continuously analyses customer movement.

Both process images.

But the second organisation has a much stronger:

• scale;

• duration;

• geographic;

• monitoring;

• systematic-processing profile.

Therefore, "CCTV = DPO" is too simplistic.

The correct analysis is:

What kind of monitoring is taking place, at what scale, for how long, across what geographical area, and as part of what activity?

77. Worked example: mobile application

A mobile app collects location data.

Again, location tracking alone does not automatically answer the DPO question.

Consider:

App A

Collects location once to show a nearby store.

App B

Collects location every few seconds for years and combines it with:

• browsing;

• purchases;

• contacts;

• behavioural profiles.

The second operation has a radically different monitoring profile.

The words "location data" alone do not determine the result.

78. The importance of the processor's perspective

A particularly important nuance is that large scale can arise from the processor's aggregate activity.

Suppose:

LocalRetailer

has only 500 customers.

It hires:

AnalyticsProcessor

which provides behavioural analytics to:

• 2,000 retailers;

• each with thousands of customers.

The local retailer may not conduct large-scale monitoring.

But the processor's business may involve large-scale processing when its activities are viewed in their own context.

Therefore, the processor cannot necessarily avoid Article 37 by pointing to the small size of any one client.

This is one reason Article 37 expressly refers to both controllers and processors.

79. The DPO does not have to be physically located in every establishment

A multinational group does not necessarily need a separate DPO sitting in every country.

Article 37(2) expressly permits a group DPO.

The real requirement is functional accessibility.

Modern communications technology can facilitate this through:

• secure email;

• telephone;

• video conferencing;

• internal privacy portals;

• dedicated escalation channels.

But technology does not automatically solve accessibility.

A DPO who technically has an email address but cannot respond, lacks information about local operations or cannot communicate with relevant stakeholders is not genuinely accessible merely because the email address exists.

80. Language is an often-overlooked accessibility issue

Suppose a group DPO is based in one Member State.

The DPO communicates only in English.

The affected data subjects are predominantly consumers who cannot reasonably communicate in English.

The DPO's accessibility may therefore be impaired.

A multinational group should consider:

• local language requirements;

• translated privacy materials;

• local contact channels;

• support staff;

• regulatory communication.

The purpose is not linguistic perfection.

It is effective communication.

81. Documentation of the Article 37 assessment

A sophisticated privacy programme should maintain an Article 37 DPO assessment memo.

The memo might contain:

Organisation profile

• entity;

• role;

• jurisdictions;

• business activities.

Article 37(1)(a)

• public authority analysis.

Article 37(1)(b)

• core activities;

• monitoring;

• regularity;

• systematic nature;

• scale.

Article 37(1)(c)

• Article 9 processing;

• Article 10 processing;

• core activities;

• scale.

National-law assessment

• relevant Member State requirements.

Conclusion

• mandatory DPO;
• voluntary DPO;
• no DPO.

Review mechanism

The organisation should periodically reassess the conclusion.

This is particularly important because an organisation's processing profile can change.

82. Why the DPO assessment should not be treated as permanent

Imagine an organisation begins as a small business.

It processes 2,000 customers.

No DPO is required.

Five years later:

• it acquires competitors;

• expands into 20 countries;

• launches behavioural advertising;

• processes millions of users;

• begins location tracking.

The original conclusion may no longer be valid.

Therefore, the Article 37 assessment should be revisited when there are significant changes to:

• business model;

• scale;

• technology;

• geographic reach;

• categories of data;

• monitoring practices;

• corporate structure.

83. Article 37 and AI systems

Modern AI makes Article 37 analysis particularly interesting.

Suppose an AI company operates a system that:

• continuously analyses user behaviour;

• creates profiles;

• predicts preferences;

• scores individuals;

• uses behavioural data for personalisation.

The organisation should examine whether its AI processing amounts to regular and systematic monitoring on a large scale.

Similarly, AI systems processing:

• health data;

• biometric data;

• genetic data;

• criminal-record information

may raise Article 37(1)(c) considerations where the processing is large scale and forms part of the core activities.

The technology itself does not trigger Article 37.

Rather:

The underlying processing characteristics determine whether Article 37 applies.

84. Article 37 is not a "number of employees" test

A common corporate misunderstanding is:

"We have fewer than 250 employees, so we do not need a DPO."

This is wrong.

Employee headcount is not the central Article 37 test.

A company with 20 employees could have a mandatory DPO if its core activities involve large-scale monitoring.

A company with 2,000 employees might not automatically trigger Article 37 merely because of its size.

Organisational size may be relevant to practical resources and context, but it is not itself one of the three primary triggers in Article 37(1).

85. Article 37 is also not a turnover test

Similarly:

"Our revenue is below €X, so Article 37 does not apply."

The GDPR does not structure Article 37 around revenue.

The relevant concepts are:

• public authority;

• core activities;

• monitoring;

• regularity;

• systematic nature;

• large scale;

• special categories;

• criminal-conviction/offence data.

Financial size may provide contextual evidence but does not replace the legal test.

86. Article 37 and DPIAs

There is a close practical relationship between DPO designation and Data Protection Impact Assessments.

A DPO may advise on DPIAs under Article 39.

But this does not mean:

"Every organisation required to conduct a DPIA automatically requires a DPO."

The two provisions use related but distinct legal tests.

A DPIA concerns whether processing is likely to result in a high risk to individuals.

Article 37 concerns whether the organisation falls within one of the statutory DPO triggers.

The concepts overlap in some situations, particularly where processing involves:

• large-scale monitoring;

• sensitive data;

• profiling.

But they should not be treated as identical tests.

87. Article 37 and accountability evidence

A strong organisation should be able to produce evidence of:

• DPO designation;

• DPO qualifications;

• independence arrangements;

• conflict assessment;

• resources;

• reporting structure;

• training;

• communications;

• supervisory authority notification;

• public contact details.

This is important because the DPO itself can become part of the organisation's accountability evidence.

Example

during an audit, the organisation can demonstrate:

"We identified that Article 37 applies. We formally designated a qualified DPO. We gave the DPO direct access to senior management. We established a dedicated contact channel. We provide resources and involve the DPO in relevant DPIAs."

That is much stronger than simply saying:

"We have a privacy officer."

88. A subtle but important distinction: DPO involvement does not mean DPO approval

The DPO should be involved in relevant privacy matters.

But the DPO is not necessarily a mandatory approval authority for every processing decision.

For example:

"The DPO must sign every privacy policy."

Not necessarily.

"Every marketing campaign is invalid unless the DPO approves it."

Not automatically.

The DPO's role is principally to:

• advise;

• monitor;

• assist;

• cooperate;

• communicate.

The exact organisational workflow can vary.

What matters is that the organisation does not undermine the DPO's ability to perform those statutory tasks.

89. DPO independence does not mean DPO isolation

Independence should not be misunderstood.

A DPO is not supposed to operate as a completely detached outsider who never interacts with management.

Quite the opposite.

The DPO needs meaningful access to:

• senior management;

• business units;

• IT;

• security;

• HR;

• legal;

• procurement;

• product teams.

The DPO needs information to perform the role.

Thus:

Independence means freedom from improper instructions and interference, not separation from the organisation.

This distinction becomes crucial in practice.

90. What makes a DPO ineffective?

A DPO may exist on paper but be ineffective in reality.

Warning signs include:

• the DPO is never consulted;

• the DPO is excluded from major projects;

• the DPO has no access to senior management;

• the DPO lacks budget;

• the DPO has insufficient time;

• the DPO cannot communicate with regulators;

• the DPO's advice is systematically ignored without proper consideration;

• the DPO's other role creates a conflict;

• employees do not know how to contact the DPO;

• data subjects cannot easily reach the DPO.

This demonstrates an important principle:

Formal designation is only the beginning. Effective functioning is the real objective.

91. The deeper purpose of Article 37

The deeper objective of Article 37 is institutional.

The GDPR assumes that certain processing environments are sufficiently complex, extensive or sensitive that an organisation needs a dedicated expert who can continuously monitor privacy compliance.

The DPO therefore represents a form of internal regulatory expertise.

The organisation itself is still responsible.

But the DPO provides:

• expertise;

• institutional memory;

• continuity;

• challenge;

• advice;

• regulatory communication;

• privacy governance.

This makes the DPO one of the most important organisational mechanisms under the GDPR.

92. The central distinction to remember

For examination, advisory and compliance purposes, the most important distinction is this:

Article 37(1)

asks:

When is designation mandatory?

Article 37(2) and (3)

ask:

Can one DPO serve multiple entities?

Article 37(4)

asks:

Can a DPO be appointed voluntarily or required by additional national/Union law?

Article 37(5)

asks:

What qualities and expertise must the DPO possess?

Article 37(6)

asks:

Can the DPO be internal or external?

Article 37(7)

asks:

How must the DPO be made accessible?

This structure makes the provision much easier to analyse.

93. Final practical checklist

When confronted with an Article 37 problem, do not immediately ask:

"Does the company need a DPO?"

Instead, work through the following chain:

1. Who is the organisation? Controller or processor?

2. Is it a public authority/body? If yes, Article 37(1)(a) may apply.

3. What are its core activities? Identify the organisation's primary operations.

4. Does the core activity involve monitoring? Identify tracking, profiling, surveillance or behavioural observation.

5. Is the monitoring regular? Is it ongoing, recurring or periodic?

6. Is it systematic? Is it organised, planned or methodical?

7. Is it large scale? Consider:

• number of individuals;

• volume/range;

• duration;

• geographical extent.

8. Does the organisation's core activity involve Article 9 or Article 10 data?

9. Is that processing large scale?

10. Does Member State or Union law impose additional requirements?

11. If no mandatory appointment exists, should the organisation voluntarily appoint a DPO?

12. Who should be appointed? Assess professional qualities and expertise.

13. Internal or external?

14. Is there a conflict of interest?

15. Is the DPO sufficiently independent? This requires Article 38 analysis.

16. Does the DPO have sufficient resources?

17. Is the DPO accessible?

18. Have the contact details been published?

19. Have they been communicated to the supervisory authority?

20. Has the whole assessment been documented?

That is the practical Article 37 methodology.

94. The ultimate lesson of Article 37

Article 37 should not be reduced to the statement:

"Certain companies have to appoint a DPO."

Its real significance is much deeper.

The provision identifies circumstances in which the GDPR considers an organisation's processing environment sufficiently:

• public in character;

• extensive;

• systematic;

• persistent;

• sensitive;

• complex;

to justify a specialised privacy governance function.

The DPO is therefore not merely a job title.

The DPO is an institutional safeguard.

But the safeguard works only when the entire structure is respected.

A company cannot meaningfully comply with Article 37 by:

• appointing an unqualified person;

• giving the person no time;

• placing the person in a conflict of interest;

• excluding the person from relevant projects;

• refusing access to management;

• making the person inaccessible;

• failing to publish contact details;

• or treating the DPO as personally responsible for the organisation's GDPR compliance.

The correct model is:

The controller or processor remains responsible for compliance. The DPO provides independent expert advice, monitoring and regulatory communication within the organisation's accountability structure.

This is why Article 37 must always be read together with Articles 38 and 39.

Article 37 creates the function. Article 38 protects the function. Article 39 gives the function substance.

That three-part relationship is the key to understanding the GDPR's DPO framework.

Absolutely. Article 38 is much richer than a list of six obligations. The central idea is that the DPO must be institutionally capable of being independent. It is not enough to appoint someone and give them the title “DPO”. The organisation must create a governance structure in which the DPO can actually see what is happening, intervene early, advise management honestly, communicate with data subjects, and raise uncomfortable issues without fear of retaliation.

Below is a detailed, explanatory commentary, including practical illustrations, interpretive nuances, compliance traps and the relationship between Article 38, Articles 37 and 39, Recital 97 and the CJEU's jurisprudence.