Article 39 — Tasks of the data protection officer

Article 39 GDPR, Detailed Commentary on the Tasks of the Data Protection Officer

1. Introduction: Understanding the DPO's role under Article 39

Article 39 is the operational provision governing what a Data Protection Officer (“DPO”) actually does once appointed. Articles 37 and 38 establish, respectively, when a DPO must be designated and what position, independence and resources the DPO must have. Article 39 answers a different question: what are the functions that the DPO must perform?

This distinction is important because the DPO is sometimes misunderstood as the person who is personally responsible for making the organisation GDPR-compliant. That is not the structure of the GDPR.

The DPO is primarily an independent adviser, monitor, facilitator and institutional point of contact. The controller or processor remains responsible for deciding how processing is conducted and for implementing the measures necessary to comply with the GDPR.

Article 39 therefore creates a deliberate separation between:

1. decision-making responsibility, which generally remains with the controller or processor;

2. compliance advice and monitoring, which is part of the DPO's role;

3. operational implementation, which normally belongs to management and the relevant business, legal, IT, security, HR or other functions; and

4. regulatory interface, which the DPO facilitates but does not exclusively control.

This separation is essential to understanding almost every difficult issue under Article 39.

Example

suppose a company wants to deploy an AI system that analyses employee communications to identify possible insider threats. The DPO may advise that the proposed processing raises serious issues concerning transparency, proportionality, purpose limitation, employee monitoring, retention and potentially a DPIA. The DPO may recommend safeguards and may monitor whether the organisation follows the applicable requirements.

But the DPO ordinarily does not become the person who “owns” the AI system, decides the business purpose, determines the technical architecture, approves the processing on behalf of the controller, or assumes the controller's legal responsibility.

That distinction becomes particularly important when enforcement action occurs. A failure to comply with the GDPR does not automatically become a personal failure of the DPO merely because the DPO identified the problem or was responsible for monitoring it.

The central philosophy of Article 39 can therefore be expressed as follows:

The DPO helps the organisation understand, implement, monitor and communicate data-protection compliance, but does not replace the controller's responsibility for compliance.

2. Article 39(1): “At least”, the statutory minimum, not the maximum

The first major interpretative point is the phrase “at least”.

The tasks listed in Article 39(1) are therefore a statutory minimum. They are not an exhaustive catalogue of everything that a DPO may ever do.

This has two consequences.

First, an organisation may legitimately give its DPO additional data-protection-related responsibilities.

Example

a DPO might also:

• maintain or coordinate the privacy compliance programme;

• oversee privacy training;

• coordinate responses to data-subject requests;

• assist with records of processing activities;

• coordinate breach-response procedures;

• maintain a privacy risk register;

• advise procurement teams on processor agreements;

• review privacy notices;

• coordinate regulatory correspondence;

• participate in privacy-by-design reviews;

• provide privacy input into product development;

• maintain relationships with external privacy counsel; or

• prepare periodic reports for the board or senior management.

There is nothing inherently problematic with additional tasks.

However, the second consequence is much more important: additional tasks cannot undermine the DPO's independence or create a conflict of interest.

Article 39 must therefore be read together with Article 38.

Suppose a company appoints its Chief Information Officer as DPO but simultaneously makes that person responsible for deciding the company's security architecture, determining which personal data should be collected, approving processing purposes and serving as the ultimate executive decision-maker for the relevant systems.

The problem is not merely that the person has “too much work”.

The deeper problem is that the DPO may eventually be required to monitor or advise on decisions that the same person personally made.

The DPO could effectively become both:

• the person making the decision, and

• the person independently reviewing whether that decision complies with the GDPR.

That creates a structural conflict.

The same concern applies to giving the DPO direct operational responsibility for activities that the DPO is supposed to monitor.

Example

HR Director as DPO Imagine that the HR Director is also designated as DPO. The HR Director decides that employee attendance data should be retained indefinitely because it might be useful for future disciplinary proceedings. The DPO function then requires the same individual to assess whether the retention period complies with storage limitation and proportionality requirements. There is an obvious independence problem. The person would effectively be reviewing their own decision. This does not mean that every dual role is automatically unlawful. The assessment is functional and depends on whether the additional role involves determining the purposes and means of processing or otherwise creates a conflict. But organisations must be particularly careful where the additional role involves decision-making authority over processing operations.

3. Article 39 and the fundamental distinction between advising and deciding

One of the most important concepts running through Article 39 is the difference between advice anddecision-making.

A DPO may say:

“In my assessment, this processing presents a high risk and should not proceed in its current form.”

The controller may ultimately decide:

“We disagree with that assessment and believe the processing can proceed with additional safeguards.”

The controller's ability to disagree does not make the DPO's advice meaningless.

On the contrary, the DPO's independence means that the organisation must be able to receive an honest compliance assessment, including advice that management may find inconvenient.

The DPO is not merely a person who confirms decisions already made by management.

The role would be severely weakened if the DPO were expected to say:

“Management has decided to launch the system, therefore I will find a GDPR-compliant justification for it.”

That reverses the intended relationship.

The proper sequence is generally:

processing proposal → privacy analysis → DPO advice → management decision → implementation → monitoring

rather than:

management decision → DPO approval → implementation

The DPO normally does not possess a general statutory “veto” over processing. But absence of a veto does not mean that the DPO's advice can simply be ignored without consequence.

Where the organisation rejects significant DPO advice, especially in relation to high-risk processing or DPIAs, there should be a clear documentary record explaining the decision.

That documentation serves several purposes:

• it demonstrates that the DPO was actually consulted;

• it preserves the reasoning behind the controller's decision;

• it facilitates accountability;

• it allows later internal review;

• it may become important during regulatory scrutiny; and

• it prevents the organisation from retrospectively claiming that the DPO had approved something when the DPO had actually objected to it.

4. Article 39(1)(a): Informing and advising

The first substantive task is to inform and advise the controller, processor and employees involved in processing.

At first glance this appears simple. In reality, it contains two distinct functions:

1. informing, and

2. advising.

They should not be treated as synonyms.

4.1 “Informing” is a proactive function

Informing is fundamentally about ensuring that relevant people know what their legal and compliance obligations are.

Example

suppose the European Data Protection Board issues new guidance affecting children's data. The DPO may need to assess whether the guidance is relevant to the organisation and communicate the implications to the product, legal, marketing and engineering teams.

Similarly, if a significant judgment changes the interpretation of legitimate interests, the DPO may need to alert management.

The DPO should not necessarily wait until management asks:

“Has anything changed in privacy law?”

The nature of the function is proactive.

A useful way of understanding this is:

==Information = “You need to know that this legal or compliance development exists and affects you.”==

==Advice = “Given your particular situation, this is what I recommend you do about it.”==

The difference is subtle but important.

5. Who must be informed and advised?

Article 39 does not restrict the function to the legal department.

The provision expressly extends to:

• the controller;

• the processor; and

• employees carrying out processing.

The DPO therefore has an organisation-wide advisory function.

This is particularly significant in large organisations where privacy compliance is distributed across numerous departments.

Consider an online retailer.

The relevant processing may involve:

• marketing;

• sales;

• customer service;

• HR;

• information security;

• fraud prevention;

• analytics;

• procurement;

• IT;

• product development;

• finance; and

• third-party vendors.

A DPO who communicates only with the legal department is not necessarily fulfilling the practical purpose of Article 39.

The employee designing an analytics system may need privacy guidance just as much as the lawyer drafting the privacy notice.

The employee responding to a data-subject request needs to know how the request should be escalated.

The procurement officer needs to know when a vendor may qualify as a processor and what contractual safeguards are required.

The marketing team needs to understand the implications of direct marketing, consent, objection rights and profiling.

The security team needs to understand the interaction between security measures, breach notification and data protection.

Thus, Article 39 creates a horizontal compliance function rather than a purely legal one.

6. Informing senior management

The DPO's relationship with senior management is particularly important.

A common organisational mistake is to treat the DPO as a technical privacy officer somewhere below the legal or compliance hierarchy.

That can undermine the function.

If a DPO discovers that the organisation is systematically retaining sensitive personal data far beyond what is necessary, the DPO must be able to communicate the problem to people capable of correcting it.

Imagine the DPO identifies the following:

• a high-risk AI profiling system;

• inadequate transparency;

• no appropriate retention schedule;

• weak access controls;

• incomplete DPIA documentation; and

• significant regulatory exposure.

If the DPO is required to communicate only through a middle-level manager who can suppress or alter the advice before senior management receives it, the independence and effectiveness of the DPO become questionable.

The DPO should therefore have a practical ability to communicate significant issues to the highest management level.

This is one reason Article 39 cannot be understood independently of Article 38.

The DPO's effectiveness depends not merely on formal appointment but on organisational access.

7. What does “advise” actually mean?

Advice under Article 39 should be understood as reasoned, context-specific compliance guidance.

It is not simply:

“This may violate GDPR.”

Good DPO advice should explain:

1. what processing is being contemplated;

2. which legal requirements are relevant;

3. what risks arise;

4. what the legal uncertainty is, if any;

5. what safeguards could reduce the risk;

6. what alternatives are available;

7. what decision needs to be made; and

8. what consequences may follow from each option.

Example

Employee monitoring Suppose an employer proposes software that continuously records employee keyboard activity. A weak DPO response would be: “Employee monitoring is risky.” A more useful advisory response would explain:

• the precise purpose of monitoring;

• whether less intrusive methods could achieve that purpose;

• whether the proposed monitoring is necessary and proportionate;

• what categories of personal data will be generated;

• who can access the data;

• how long it will be retained;

• whether employees will be adequately informed;

• whether profiling is involved;

• whether special-category data could inadvertently be inferred;

• whether a DPIA is required;

• whether national employment law imposes additional requirements; and

• what technical and organisational safeguards should be implemented.

That is what meaningful advice looks like.

8. “Other Union or Member State data protection provisions”

The DPO's advisory responsibility is not limited to the literal provisions of the GDPR.

Article 39 expressly refers to other applicable Union or Member State data-protection provisions.

This is important because GDPR compliance does not exist in isolation.

Depending on the processing activity, the DPO may need to consider:

• national data-protection legislation;

• employment-related privacy provisions;

• sector-specific privacy rules;

• electronic communications rules;

• rules governing health information;

• rules governing public-sector processing;

• national rules concerning criminal data;

• professional secrecy requirements; and

• relevant European legal developments.

The precise scope depends on the organisation and jurisdiction.

The DPO therefore needs sufficient legal knowledge to identify when the GDPR is only one component of the regulatory framework.

9. Article 39(1)(b): Monitoring compliance

The second major task is monitoring compliance.

This is perhaps the most misunderstood part of Article 39.

The DPO is not the person who guarantees compliance.

The DPO is the person who monitors and advises on compliance.

That difference is fundamental.

9.1 What does “monitor” mean?

Monitoring involves systematically examining whether the organisation's processing practices correspond to its legal and internal requirements.

A DPO may therefore:

• review records of processing activities;

• assess privacy notices;

• examine procedures for data-subject rights;

• review retention practices;

• assess data-sharing arrangements;

• examine processor relationships;

• review DPIAs;

• conduct or coordinate audits;

• examine training programmes;

• assess implementation of privacy policies;

• review breach-management processes;

• identify compliance gaps; and

• report deficiencies to management.

Monitoring is therefore an ongoing function rather than a one-time compliance exercise.

10. Monitoring is different from auditing

The concepts overlap but are not identical.

An audit is generally a structured examination of a particular area against defined criteria.

Monitoring is broader.

Example

a DPO may continuously monitor whether departments maintain appropriate records and comply with data-subject rights procedures.

Once a year, the DPO might conduct a formal audit of the customer-data environment.

Thus:

Monitoring = continuous oversight

Audit = structured periodic or targeted examination

The DPO may use both.

11. Assignment of responsibilities

Article 39 expressly refers to the assignment of responsibilities.

This means the DPO should not merely examine whether a privacy policy exists.

The DPO should consider whether the organisation has actually allocated responsibility for compliance.

Example

a company might have a beautifully drafted data-retention policy stating:

“Personal data must be deleted when no longer necessary.”

But who determines when data is no longer necessary?

Is it:

• IT?

• legal?

• business operations?

• records management?

• the individual business owner?

• the security team?

If nobody has responsibility, the policy is largely theoretical.

A mature privacy programme therefore requires a clear allocation of ownership.

The DPO can identify the absence of such allocation and advise management to correct it.

But again, the DPO does not necessarily become the operational owner.

12. Awareness and training

Article 39 specifically identifies awareness-raising and training.

This reflects an important reality: privacy failures are often caused not by defective laws or policies but by employee behaviour.

Examples

include:

• sending personal data to the wrong recipient;
• storing customer information on unauthorised systems;
• failing to recognise a data-subject request;
• downloading personal data unnecessarily;
• using personal devices without appropriate safeguards;
• retaining information indefinitely;
• sharing credentials;
• exposing personal data through email;
• uploading confidential information into unauthorised AI tools. Training therefore forms part of the DPO's compliance-monitoring ecosystem. The DPO might design training or coordinate it with HR and compliance teams. However, the organisation should not assume that conducting one annual privacy training session automatically satisfies Article 39. Training should be proportionate to the risks and roles involved. A developer handling production databases may require substantially different training from a receptionist. A marketing employee may need detailed guidance concerning consent and direct marketing. A security employee may need specialised guidance on breach identification and escalation. Thus, Article 39 supports a risk-based training model.

13. Monitoring through audits

Audits can be used to determine whether policies operate in reality.

Suppose an organisation's policy states that customer data must be deleted after five years.

The DPO might examine:

• whether the deletion period has actually been configured;

• whether backups retain the information;

• whether archived systems contain the data;

• whether third-party processors have corresponding deletion mechanisms;

• whether exceptions are documented;

• whether departments continue to export old datasets; and

• whether technical deletion is actually occurring.

This illustrates an important principle:

A DPO should not treat documentation as proof of compliance.

A policy saying that something happens is not the same as evidence that it actually happens.

Effective monitoring therefore requires some level of operational verification.

14. The crucial limitation: the DPO is not personally responsible for organisational compliance

This is one of the most important principles under Article 39.

The controller remains responsible for compliance.

Suppose the DPO identifies that an organisation's retention system violates the GDPR and advises management to correct it.

Management refuses.

The organisation subsequently faces regulatory enforcement.

It would be incorrect simply to say:

“The DPO failed to ensure compliance.”

The DPO's function is not to replace management.

If the DPO:

1. identified the problem;

2. properly advised management;

3. documented the issue;

4. escalated it where appropriate; and

5. continued to monitor the matter,

the fact that management refused to implement the recommendation does not automatically transform the DPO into the person legally responsible for the underlying processing.

This is closely connected to the accountability principle.

The controller must be able to demonstrate compliance.

The DPO supports that process but does not become the controller.

15. A difficult scenario: management ignores the DPO

Suppose the DPO informs the CEO:

“The proposed facial-recognition system presents substantial risks and should not be deployed without further safeguards and DPIA analysis.”

The CEO responds:

“We have decided to deploy it anyway.”

What should the DPO do?

The DPO should not simply resign themselves to the decision.

A responsible response could include:

• documenting the advice;

• identifying the legal and risk concerns;

• explaining the consequences;

• ensuring that the DPIA process is properly undertaken;

• escalating significant concerns to appropriate senior management;

• monitoring implementation;

• recommending safeguards; and

• considering whether engagement with the supervisory authority becomes appropriate in the circumstances.

The DPO does not necessarily have a veto.

But neither is the DPO expected to silently endorse a decision with which they disagree.

16. Article 39(1)(c): Advice concerning DPIAs

The third task concerns Data Protection Impact Assessments.

This provision must be read together with Article 35.

A DPIA is fundamentally the controller's responsibility.

The DPO's role is advisory and monitoring-oriented.

This distinction is critical.

16.1 The DPO does not automatically “own” the DPIA

An organisation may sometimes make the mistake of assigning the entire DPIA to the DPO:

“We have a DPO, so the DPO will conduct the DPIA.”

That is problematic.

The controller is responsible for determining whether a DPIA is required, carrying it out and ensuring that the resulting risks are appropriately addressed.

The DPO should advise and monitor.

The reason is partly structural.

If the DPO personally performs the entire DPIA and subsequently monitors whether the DPIA was properly conducted, the DPO may effectively be reviewing their own work.

That undermines the monitoring function.

17. What advice should the DPO give concerning a DPIA?

The DPO's role can begin even before the DPIA is formally drafted.

The DPO may advise on:

Whether a DPIA is required

The DPO can assess the proposed processing against the criteria for high-risk processing.

For example:

• systematic monitoring;

• large-scale processing;

• sensitive personal data;

• innovative technologies;

• profiling;

• vulnerable individuals;

• combining datasets;

• significant effects on individuals.

The DPO can recommend that a DPIA be undertaken where appropriate.

But management should retain responsibility for the decision.

18. Advising on DPIA methodology

A DPIA is not merely a form to be completed.

The DPO may advise on:

• the methodology;

• risk identification;

• likelihood and severity;

• affected data subjects;

• potential harms;

• existing controls;

• residual risks;

• mitigation measures;

• consultation;

• documentation; and

• review mechanisms.

Example

suppose a hospital plans to deploy an AI system that predicts patient readmission.

A meaningful DPIA should not simply state:

“Risk: inaccurate predictions.”

It should explore:

• what happens when the prediction is wrong;

• whether healthcare professionals rely on the prediction;

• whether certain groups are disproportionately affected;

• whether the model uses sensitive information;

• whether the system creates unfair outcomes;

• whether patients understand its use;

• who can challenge a decision;

• how long prediction data is retained; and

• what happens if the vendor changes the model.

The DPO can help ensure that the DPIA addresses those issues.

19. Advising on safeguards

The DPO can recommend safeguards such as:

• data minimisation;

• pseudonymisation;

• encryption;

• access restrictions;

• retention limits;

• human review;

• transparency mechanisms;

• audit logging;

• testing;

• bias monitoring;

• contractual controls;

• deletion mechanisms;

• incident-response procedures; and

• restrictions on secondary use.

The key point is that the DPO should not merely identify risks.

A sophisticated DPO translates risk into practical mitigation measures.

20. Monitoring the performance of the DPIA

Article 39 does not stop at advice.

The DPO must also monitor the DPIA's performance.

This means examining whether:

• the DPIA was actually carried out;

• the assessment covers the relevant processing;

• risks were properly identified;

• safeguards were implemented;

• residual risks remain;

• assumptions have changed;

• the actual processing differs from what was assessed; and

• the DPIA needs to be reviewed.

This is particularly important because a DPIA is not necessarily a one-time document.

Suppose a company conducts a DPIA for an AI recruitment system.

The initial DPIA assumes:

• data comes only from applications;

• no behavioural data is collected;

• the model is used only for ranking;

• humans make the final decision.

Two years later, the company:

• adds social-media data;

• introduces behavioural scoring;

• begins automatically rejecting candidates; and

• expands the model to employee performance assessment.

The original DPIA may no longer accurately describe the processing.

The DPO should therefore monitor whether material changes trigger reassessment.

21. What if the controller disagrees with the DPO?

The GDPR does not generally require the controller to follow every piece of DPO advice.

That is important.

The DPO is not an executive decision-maker.

However, disagreement should not be concealed.

Suppose the DPO recommends:

“The proposed processing should not proceed because the residual risk remains excessive.”

Management concludes:

“We disagree.”

The organisation should document:

• what the DPO advised;

• why the DPO advised it;

• what management decided;

• why management rejected the recommendation; and

• what safeguards or alternative measures were adopted.

This creates an accountability trail.

It also prevents a later dispute about whether the DPO had approved the processing.

22. A particularly important grey area: Can the DPO decide whether a DPIA is required?

The answer requires nuance.

The DPO should certainly be involved in the assessment and should provide advice.

But the DPO should not be transformed into the sole decision-maker responsible for the controller's compliance obligations.

A sensible governance model is:

Business identifies proposed processing → privacy function/DPO assesses risk → DPO advises → controller records determination → DPIA performed where required → DPO advises and monitors.

This maintains the distinction between advice and accountability.

23. Article 39(1)(d): Cooperation with the supervisory authority

The DPO's fourth task is cooperation with the supervisory authority.

The supervisory authority is the regulator responsible for enforcing data-protection law within its jurisdiction.

The DPO therefore performs an important bridge function between the organisation and regulator.

This may include:

• facilitating regulatory communication;

• assisting with investigations;

• coordinating requests for information;

• facilitating prior consultation;

• helping locate relevant records;

• explaining internal processing structures;

• assisting the organisation in responding accurately; and

• maintaining an appropriate regulatory relationship.

The DPO should not be understood as merely a messenger.

The DPO may help ensure that communications with the regulator are accurate, coherent and legally informed.

24. Cooperation does not mean becoming the regulator's employee

The DPO remains part of the controller's or processor's organisational structure.

The DPO therefore does not become an extension of the supervisory authority.

This creates an interesting balance.

The DPO must cooperate with the regulator while maintaining independence from organisational pressure.

Example

if the supervisory authority asks questions about a processing operation, management cannot instruct the DPO:

“Do not tell the regulator about the problem.”

Such interference would undermine the DPO's statutory role.

At the same time, the DPO is not generally required to act as a permanent internal whistleblower reporting every minor compliance deficiency directly to the authority.

The function is one of cooperation and facilitation, not automatic external reporting of every internal disagreement.

25. Article 39(1)(e): Acting as the contact point

The fifth task concerns the DPO's role as contact point for the supervisory authority.

This means the DPO should be accessible to the regulator regarding processing issues.

The function becomes especially important during:

• investigations;

• prior consultations;

• compliance inquiries;

• requests for information;

• regulatory meetings; and

• significant processing-related questions.

The DPO may facilitate access to:

• processing records;

• DPIAs;

• policies;

• risk assessments;

• contracts;

• technical information;

• retention schedules;

• breach records; and

• other relevant documentation.

26. Contact point does not mean exclusive point of contact

This is another important nuance.

The DPO is a contact point, but that does not mean the supervisory authority is legally confined to communicating only with the DPO.

A regulator may need to speak directly with:

• the CEO;

• legal counsel;

• IT personnel;

• security personnel;

• product managers;

• HR;

• business owners; or

• other employees.

Likewise, the DPO should not prevent management or other appropriate personnel from communicating with the regulator.

The DPO's role is to facilitate and coordinate, not monopolise regulatory communication.

27. Prior consultation under Article 36

The reference to prior consultation is particularly important.

Article 36 becomes relevant where, following a DPIA, the controller concludes that processing would result in a high risk in circumstances where the controller has not taken measures to mitigate the risk sufficiently.

The DPO can play a critical role here.

The DPO may:

• identify that prior consultation is required;

• advise the controller on the consultation process;

• coordinate preparation of relevant information;

• facilitate communication with the supervisory authority;

• explain the processing and risk assessment; and

• monitor the outcome.

Again, the controller remains responsible for the underlying processing decision.

28. Does the DPO have a duty to report every GDPR violation?

No general rule in Article 39 says that the DPO must automatically report every internal GDPR violation to the supervisory authority.

This is a crucial distinction.

Suppose the DPO discovers that a department failed to update a privacy notice.

The normal response would generally be:

1. identify the issue;

2. inform the relevant management;

3. recommend corrective measures;

4. monitor remediation.

It would be disproportionate to treat every minor compliance deficiency as requiring immediate external regulatory reporting.

However, the situation changes where:

• the violation is serious;

• management refuses to act;

• there is continuing significant risk;

• the issue concerns major unlawful processing;

• regulatory consultation is required; or

• circumstances otherwise make direct regulatory engagement appropriate.

The DPO's independence must mean something in such circumstances.

29. Confidentiality and the ability to contact the regulator

The DPO is subject to duties of secrecy and confidentiality under Article 38(5), subject to applicable law.

But confidentiality cannot be interpreted so broadly that it prevents the DPO from carrying out Article 39.

Example

a DPO should be able to consult the supervisory authority where appropriate.

Otherwise, Article 39's contact-point function would become practically meaningless.

The balance is therefore:

protect confidential information while enabling legitimate regulatory cooperation.

The DPO must exercise professional judgment regarding what information is necessary and appropriate to disclose.

30. Article 39(2): The risk-based approach

Article 39(2) is short but conceptually very important.

It requires the DPO to have due regard to the risk associated with processing operations, considering:

• nature;

• scope;

• context; and

• purposes.

This is essentially a risk-prioritisation obligation.

The DPO does not have unlimited time.

An organisation may have hundreds or thousands of processing activities.

The DPO therefore cannot reasonably treat every processing operation as equally important.

31. Nature of processing

“Nature” concerns what kind of processing is occurring.

Examples

of potentially significant factors include:

• sensitive personal data;
• children's data;
• biometric information;
• location information;
• behavioural data;
• financial information;
• health data;
• criminal-offence data;
• profiling;
• automated decision-making;
• continuous monitoring. The nature of the data and technology can materially affect the risk.

Example

processing a person's name to send an ordinary invoice is generally very different from processing biometric identifiers for continuous surveillance.

32. Scope of processing

Scope concerns the scale and breadth of the processing.

Relevant questions include:

• How many individuals are affected?

• How much data is processed?

• How frequently is it processed?

• How widely is it shared?

• How many systems are involved?

• Is the processing local or international?

• How long does processing continue?

Consider two hypothetical facial-recognition systems.

System A is used experimentally on 50 consenting employees for one week.

System B is deployed across millions of individuals and operates continuously.

The technology may be similar, but the scope is dramatically different.

That should influence DPO prioritisation.

33. Context of processing

Context is often overlooked.

The same information can carry very different risks depending on the circumstances.

Example

an individual's location data may be relatively low-risk when used for providing navigation services.

The same location data may be highly sensitive in a workplace monitoring system.

Similarly, processing medical information in a hospital for direct care is contextually different from processing similar information for targeted advertising.

The DPO must therefore avoid simplistic assessments based solely on the category of data.

34. Purpose of processing

Purpose is central to risk assessment.

Why is the organisation processing the data?

Consider two systems using employee location data.

System A uses location data solely to determine whether a field technician is currently assigned to a service call.

System B uses the same data to calculate employee productivity scores, predict future behaviour and determine promotion eligibility.

The second purpose may create substantially greater risks because the processing may affect employees in significant ways.

Thus, the risk analysis cannot be reduced to:

“Location data = medium risk.”

The DPO must ask:

“Location data, used for what purpose, in what circumstances, with what consequences?”

35. Risk-based prioritisation does not mean ignoring low-risk processing

This is a crucial nuance.

A risk-based approach does not mean:

“If something is low risk, GDPR does not apply.”

That is incorrect.

Even relatively low-risk processing remains subject to applicable GDPR requirements.

The risk-based approach primarily determines how much attention and resources should be devoted to a particular issue.

Example

the DPO may spend:

• 30 hours reviewing an AI recruitment system;

• 10 hours auditing employee monitoring;

• 5 hours reviewing a marketing process;

• 1 hour reviewing a routine low-risk administrative process.

That does not mean the last activity is outside GDPR.

It means the DPO is allocating limited resources rationally.

36. Risk-based prioritisation and proportionality

Article 39 therefore encourages proportionality in the DPO's work.

Suppose an organisation has:

• a low-risk internal contact directory; and

• a high-risk predictive policing algorithm.

The DPO should not spend equal amounts of time on both merely because both involve personal data.

The high-risk processing deserves deeper examination.

This affects:

• audit frequency;

• depth of DPIA review;

• training intensity;

• management reporting;

• monitoring frequency;

• technical review;

• legal research; and

• escalation.

37. Article 39 and the principle of accountability

Article 39 is closely connected to the broader accountability architecture of the GDPR.

The DPO helps the controller move from:

“We believe we comply.”

to:

“We have processes, evidence, monitoring and documentation demonstrating how we comply.”

Example

if a company claims that it has appropriate data-retention practices, the DPO might ask:

• Where is the retention schedule?

• Who owns it?

• How are retention periods determined?

• How are exceptions documented?

• How is deletion technically enforced?

• How often is compliance tested?

• What happens with backups?

• What happens when a processor holds the data?

• Is there evidence that deletion actually occurred?

This demonstrates the difference between formal compliance andoperational compliance.

38. Article 39 and privacy by design

Although privacy by design is primarily addressed by Article 25, the DPO's Article 39 role supports it.

A mature DPO should become involved early in projects rather than being invited after the product has already been built.

Consider a company developing a new mobile application.

If the DPO is consulted six months after development, the architecture may already require substantial redesign.

If the DPO participates at the design stage, the organisation can potentially:

• minimise data collection;

• avoid unnecessary identifiers;

• configure privacy-friendly defaults;

• reduce retention;

• build consent mechanisms correctly;

• design deletion functionality;

• implement access controls; and

• create appropriate transparency mechanisms.

Article 39 therefore operates as part of a preventive compliance model.

39. Article 39 and data breaches

Article 39 does not make the DPO the person legally responsible for notifying a supervisory authority under Article 33.

The controller generally bears that responsibility.

But the DPO may be heavily involved in the breach process.

Example

following a cyberattack, the DPO may:

• advise on whether personal data was involved;

• assist with risk assessment;

• advise on whether notification is required;

• review communications to affected individuals;

• coordinate with security teams;

• assist with regulatory communication;

• ensure relevant documentation exists; and

• monitor corrective measures.

Again, the DPO's role is advisory and supervisory rather than automatically becoming the legal owner of the breach.

40. Article 39 and data-subject rights

The same distinction applies to data-subject rights.

The DPO may monitor whether the organisation properly handles:

• access requests;

• rectification;

• erasure;

• restriction;

• objection;

• portability;

• rights concerning automated decision-making.

But the DPO does not necessarily have to personally process every request.

A large company might have a dedicated privacy operations team handling requests, while the DPO monitors whether that system is functioning correctly.

Example

the DPO might audit:

• response times;

• identity verification;

• search methodology;

• exemptions;

• communication quality;

• escalation procedures; and

• recurring failures.

This is an excellent illustration of the difference between operational execution andindependent monitoring.

41. Article 39 and processors

Article 39 applies to DPOs of both controllers and processors.

For a processor, the DPO's role may involve monitoring:

• processor-side security;

• contractual compliance;

• instructions from controllers;

• subprocessors;

• international transfers;

• incident management;

• records of processing;

• data deletion and return procedures.

Consider a cloud service provider acting as processor for hundreds of controllers.

Its DPO may need to ensure that the organisation can demonstrate compliance with processor-specific obligations.

The DPO may also advise management on whether a proposed service architecture is compatible with contractual and GDPR obligations.

42. A difficult issue: Can the DPO perform operational privacy tasks?

Yes, potentially, but the answer depends on the nature of the task.

Not every operational activity creates a conflict.

Example

helping prepare a privacy training session is generally compatible with the DPO role.

Maintaining a register of regulatory developments is also compatible.

Coordinating privacy audits can be compatible.

But a problem arises where the DPO is given authority to make the organisation's core processing decisions.

For example:

“The DPO decides which customer data the company collects and determines the purposes for which it will be used.”

That is problematic because determining purposes is fundamentally a controller function.

Likewise:

“The DPO decides whether the organisation's processing is lawful and then personally approves it as business owner.”

This creates a conflict.

The correct approach is therefore functional rather than based merely on job titles.

43. The DPO should not become a “rubber stamp”

An ineffective DPO may simply approve everything presented by management.

This defeats the purpose of the role.

A DPO should be capable of saying:

“I do not recommend proceeding.”

or:

“The proposed safeguards are insufficient.”

or:

“This processing requires further assessment.”

or:

“The DPIA does not adequately address the relevant risks.”

Independence means the DPO must be able to provide uncomfortable advice.

A DPO who never disagrees with management may indicate either unusually mature compliance or a structurally ineffective role. The organisation should therefore focus on the substance of the DPO's work rather than merely the absence of conflict.

44. Documentation is a critical component of Article 39

Although Article 39 does not prescribe a single universal DPO documentation system, documentation is extremely important.

A DPO should generally maintain evidence of significant:

• advice;

• recommendations;

• audits;

• training;

• DPIA consultations;

• regulatory interactions;

• identified compliance issues;

• escalations; and

• follow-up activities.

Why?

Because without documentation, it may later become impossible to determine:

• what the DPO knew;

• what the DPO advised;

• when the DPO advised it;

• whether management rejected the recommendation;

• whether the issue was escalated;

• whether remediation occurred.

Documentation therefore protects both the organisation and the DPO.

45. What Article 39 does not require

It is useful to identify several things Article 39 does not automatically require.

It does not mean that:

• the DPO must personally perform every privacy task;

• the DPO must approve every processing activity;

• the DPO is personally liable for every GDPR violation;

• the DPO must report every internal violation to the regulator;

• the DPO must personally conduct every DPIA;

• the DPO must personally respond to every data-subject request;

• the DPO has an automatic veto over business decisions;

• the DPO becomes the controller; or

• the DPO must treat every processing activity as equally risky.

Understanding these limitations prevents the role from becoming distorted.

46. The DPO as an institutional “challenge function”

One of the most useful ways to conceptualise the DPO is as an internal challenge function.

The DPO asks questions such as:

Why are you collecting this information?

Why do you need it for this long?

Why are you sharing it with this vendor?

Why is this level of monitoring necessary?

What happens if the information is inaccurate?

Why is this processing proportionate?

What safeguards have been implemented?

What happens if an individual objects?

Has the DPIA been updated?

What evidence demonstrates compliance?

These questions may slow down projects.

That is not necessarily a defect.

Privacy governance sometimes requires friction precisely because the purpose of the DPO is to prevent the organisation from treating personal data merely as a commercial resource.

47. Risk-based DPO work in practice: an illustrative model

Imagine a technology company has the following processing operations:

Project A, Internal employee directory

Data:

• name;

• job title;

• work email.

Purpose:

• internal communication.

Risk: relatively low.

Project B, Marketing analytics

Data:

• browsing history;

• device information;

• behavioural data.

Purpose:

• targeted advertising.

Risk: moderate.

Project C, AI recruitment system

Data:

• CVs;

• employment history;

• potentially inferred characteristics;

• assessment results.

Purpose:

• candidate ranking.

Risk: high.

Project D, Biometric authentication

Data:

• biometric identifiers.

Purpose:

• identity verification.

Risk: potentially high.

A sensible DPO would not devote identical resources to all four.

Project A might be subject to routine monitoring.

Projects B, C and D may require deeper assessment.

Projects C and D may warrant detailed DPIA involvement, senior-management reporting and more frequent monitoring.

This is Article 39(2) in practical operation.

48. Another difficult issue: What if management refuses to cooperate?

Suppose the DPO repeatedly asks a business unit for access to records necessary for monitoring.

The business unit refuses.

The DPO's role then cannot be fulfilled effectively.

The issue should be escalated through appropriate organisational channels, potentially to senior management.

This demonstrates why Article 38 and Article 39 must be read together.

Article 39 gives the DPO tasks.

Article 38 supplies the conditions necessary for performing those tasks effectively.

A DPO who technically has the title but lacks:

• access;

• information;

• personnel;

• budget;

• senior-management access; or

• sufficient time

may be unable to perform Article 39.

Formal appointment alone is therefore insufficient.

49. The DPO and expertise

Although the requirement concerning expertise arises primarily under Article 37 and Recital 97, it has direct relevance to Article 39.

The DPO cannot meaningfully advise management without sufficient knowledge.

Expertise may need to cover:

• GDPR requirements;

• national privacy law;

• regulatory guidance;

• organisational processing;

• technology;

• cybersecurity;

• risk assessment;

• DPIAs;

• data governance; and

• relevant sectoral requirements.

The necessary depth depends on the organisation.

A DPO advising a multinational AI company may need a very different knowledge profile from a DPO advising a small organisation performing relatively routine processing.

The GDPR therefore does not prescribe a single academic qualification as the universal measure of DPO competence.

What matters is whether the DPO possesses sufficient knowledge and practical ability for the processing environment.

50. Article 39 and AI governance

Article 39 has become especially significant in environments involving AI.

Consider an organisation deploying a generative AI system that processes employee and customer information.

The DPO may need to advise on:

• what personal data is entered into the system;

• whether prompts contain personal information;

• whether data is used for model training;

• retention;

• vendor access;

• international transfers;

• transparency;

• automated decision-making;

• data-subject rights;

• security;

• accuracy;

• profiling;

• purpose limitation; and

• DPIA requirements.

The DPO's role is not necessarily to become the AI system's product manager.

Instead, the DPO should act as an independent privacy governance function capable of identifying risks and challenging assumptions.

51. Article 39 and emerging technology

The reference to risk also means that the DPO's responsibilities evolve with technology.

A DPO cannot simply rely on a static compliance checklist.

New technologies can alter risk assessments.

For example:

• facial recognition;

• location analytics;

• behavioural advertising;

• connected devices;

• large language models;

• predictive analytics;

• biometric authentication;

• employee surveillance;

• synthetic data;

• data enrichment;

• automated decision-making.

Each may change the nature, scope, context or purposes of processing.

Therefore, Article 39 encourages a dynamic compliance function.

52. The relationship between Article 39 and Article 35

The distinction can be summarised as follows:

Article 35: controller's DPIA responsibility.

Article 39: DPO's advice and monitoring role.

This distinction should never be lost.

Suppose a company conducts a defective DPIA.

It does not automatically follow that:

“The DPO is responsible because the DPO was consulted.”

The DPO's responsibility is to provide appropriate advice and monitor performance.

The controller remains responsible for ensuring that the DPIA is properly carried out.

53. The relationship between Article 39 and Article 36

The same logic applies to prior consultation.

The DPO may facilitate and advise on prior consultation.

But the DPO does not become the controller merely because the DPO communicates with the regulator.

The regulatory interface is therefore an extension of the DPO's facilitative role.

54. The relationship between Article 39 and Article 38

Article 39 gives the DPO responsibilities.

Article 38 protects the conditions necessary to perform them.

This creates an important practical equation:

==Tasks without resources = ineffective DPO.==

If a DPO is expected to:

• audit 40 departments;

• monitor international transfers;

• review DPIAs;

• conduct training;

• manage regulatory communication;

• advise on AI;

• monitor breaches; and

• maintain compliance reporting,

but is given no staff, budget or access, the organisation may have complied with the formal appointment requirement while undermining the substantive purpose of the role.

The DPO therefore requires sufficient resources proportionate to the complexity and risk of the processing environment.

55. The DPO's role in internal investigations

Suppose an organisation discovers that an employee has systematically downloaded customer records.

The DPO may advise on:

• whether personal data has been compromised;

• containment;

• legal assessment;

• notification obligations;

• affected individuals;

• evidence preservation;

• remediation;

• future controls.

But the DPO should be cautious if another role they hold requires them to make the operational decision being independently assessed.

This again demonstrates why conflicts must be assessed functionally.

56. The DPO's role when there are competing business interests

Privacy compliance often competes with commercial objectives.

For example:

Marketing may want more data.

Product may want broader analytics.

Security may want longer retention.

HR may want more employee monitoring.

Finance may want extensive customer records.

The DPO's role is not to prevent all of these activities.

Rather, the DPO asks:

Can the legitimate objective be achieved in a manner consistent with data-protection law and fundamental rights?

This makes the DPO a risk-management and rights-protection function, not merely an obstacle to innovation.

57. The DPO should recommend alternatives, not merely identify problems

High-quality DPO advice is solution-oriented.

Suppose management wants to retain customer information indefinitely for future analytics.

Instead of merely stating:

“Indefinite retention is problematic,”

the DPO could recommend:

• defined retention periods;

• anonymisation where appropriate;

• pseudonymisation;

• aggregated datasets;

• restricted access;

• periodic review;

• separate retention for legally necessary records; and

• documented deletion processes.

This allows the organisation to pursue legitimate objectives while reducing privacy risk.

58. Article 39 and proportionality

The DPO's risk-based role is ultimately linked to proportionality.

A compliance measure should be appropriate to the actual risk.

Example

a low-risk internal contact list may not require the same level of governance as a biometric surveillance platform.

At the same time, “proportionate” does not mean:

“We can ignore the GDPR because compliance would be inconvenient.”

The DPO must distinguish genuine proportionality from commercial convenience.

59. A useful distinction: compliance owner versus compliance adviser

Organisations should ideally establish clear responsibility matrices.

For example:

This is not a rigid statutory allocation for every organisation, but it illustrates the conceptual structure.

The DPO should not become the dumping ground for every privacy-related responsibility simply because the organisation has appointed one.

60. Common mistakes under Article 39

Several recurring mistakes deserve particular attention.

Mistake 1: Treating the DPO as the GDPR compliance owner

Incorrect because the controller remains responsible.

Mistake 2: Making the DPO approve every processing activity

The DPO advises and monitors rather than acting as a universal approval authority.

Mistake 3: Giving the DPO conflicting executive responsibilities

This may undermine independence.

Mistake 4: Treating the DPO as responsible for performing every DPIA

The controller remains responsible for the DPIA.

Mistake 5: Ignoring the DPO's advice

The organisation may ultimately disagree, but significant disagreements should be reasoned and documented.

Mistake 6: Restricting the DPO's access to senior management

This can seriously undermine effectiveness.

Mistake 7: Preventing direct communication with the supervisory authority

This is inconsistent with the DPO's independent regulatory-contact function.

Mistake 8: Treating risk-based prioritisation as an exemption from GDPR

Low-risk processing is still processing subject to applicable obligations.

Mistake 9: Focusing only on paperwork

A privacy policy is not evidence that the underlying process actually works.

Mistake 10: Involving the DPO too late

Late-stage consultation can make privacy-by-design much more difficult.

61. A practical model for implementing Article 39

A mature organisation could operationalise Article 39 through a structured DPO programme.

Step 1: Establish the DPO mandate

Clearly define:

• statutory tasks;

• additional responsibilities;

• independence;

• reporting lines;

• access rights;

• resources.

Step 2: Create a processing inventory

Understand:

• what processing occurs;

• where;

• why;

• by whom;

• using which systems;

• with which processors.

Step 3: Develop risk prioritisation

Rank processing based on:

• nature;

• scope;

• context;

• purposes;

• potential impact.

Step 4: Develop monitoring programme

Establish:

• audits;

• reviews;

• compliance testing;

• policy checks;

• DPIA reviews;

• training assessments.

Step 5: Develop advisory mechanisms

The DPO should be embedded early in:

• new products;

• major technology projects;

• AI deployments;

• vendor arrangements;

• international transfers;

• significant changes in processing.

Step 6: Establish escalation procedures

Define how serious issues move from:

business → privacy function → DPO → senior management → regulator where appropriate.

Step 7: Document advice and decisions

Maintain evidence of:

• recommendations;

• disagreements;

• remediation;

• escalations;

• regulatory communication.

This turns Article 39 from a theoretical obligation into an operational governance system.

62. The deeper constitutional function of the DPO

The DPO has a somewhat unusual position within corporate governance.

Most corporate functions ultimately serve management's operational objectives.

The DPO has a statutory independence component because privacy protection concerns fundamental rights.

This gives the DPO a role somewhat analogous to an internal institutional check.

The DPO asks management to confront the consequences of processing for individuals.

This becomes especially important where commercial incentives favour:

• more data;

• longer retention;

• broader profiling;

• increased surveillance;

• more extensive sharing; or

• faster deployment.

The DPO introduces an independent privacy perspective into those decisions.

63. The DPO is neither management nor regulator

The DPO occupies a middle position.

The DPO is:

• inside the organisation, because they understand its operations and advise it;

• independent from operational decision-making, because they must be able to provide objective advice;

• connected to the regulator, because they serve as a contact point and cooperate with the supervisory authority.

This hybrid character explains many of the apparent tensions in Article 39.

The DPO must simultaneously:

• help the organisation comply;

• challenge the organisation where necessary;

• cooperate with regulators; and

• preserve confidentiality.

Those functions are not contradictory if the DPO's role is understood correctly.

64. The ultimate test: Can the DPO actually perform the Article 39 functions?

When evaluating whether an organisation has genuinely implemented Article 39, the question should not merely be:

“Has a DPO been appointed?”

The better questions are:

• Can the DPO obtain relevant information?

• Can the DPO speak to senior management?

• Can the DPO provide independent advice?

• Can the DPO disagree with management?

• Can the DPO monitor processing?

• Can the DPO conduct or coordinate audits?

• Can the DPO access DPIAs?

• Can the DPO communicate with the regulator?

• Does the DPO have sufficient expertise?

• Does the DPO have sufficient resources?

• Are significant recommendations documented?

• Is the DPO protected from conflicts of interest?

If the answer to these questions is no, the organisation may have a nominal DPO rather than an effective DPO.

65. Integrated example: AI recruitment system

Consider a company deploying an AI recruitment platform.

The system:

• collects CVs;

• analyses employment history;

• scores applicants;

• predicts suitability;

• stores applicant information;

• uses a third-party AI provider; and

• potentially generates inferred characteristics.

The Article 39 analysis would unfold as follows.

Inform and advise

The DPO informs HR and management about:

• applicable GDPR requirements;

• transparency;

• data minimisation;

• rights;

• processor obligations;

• profiling;

• security;

• retention;

• DPIA requirements.

Monitor compliance

The DPO examines:

• whether the system follows the approved design;

• whether data is collected beyond necessity;

• whether retention is controlled;

• whether vendors are appropriately governed;

• whether rights requests can actually be fulfilled.

DPIA advice

The DPO advises on:

• whether the DPIA is required;

• methodology;

• risks;

• safeguards;

• human oversight;

• candidate transparency;

• residual risk.

Monitor DPIA

After deployment, the DPO checks whether:

• the actual system matches the DPIA;

• new data sources have been introduced;

• model functionality has changed;

• safeguards remain effective.

Regulatory cooperation

If the supervisory authority asks questions, the DPO facilitates communication and access to relevant records.

Risk-based prioritisation

Because recruitment can significantly affect individuals and may involve profiling, the DPO gives the system greater scrutiny than routine administrative processing.

This single example illustrates virtually every component of Article 39.

66. Another integrated example: employee monitoring

Suppose a company introduces software that monitors:

• keystrokes;

• screenshots;

• application use;

• location;

• productivity indicators.

The DPO should not merely ask:

“Is monitoring lawful?”

The analysis should explore:

• purpose;

• necessity;

• proportionality;

• less intrusive alternatives;

• transparency;

• employee expectations;

• access;

• retention;

• security;

• potential profiling;

• automated decision-making;

• national employment/privacy law;

• DPIA requirements.

If the DPO concludes that continuous screenshots are excessive, the DPO might recommend:

• aggregated productivity information;

• limited event logging;

• shorter retention;

• restricted access;

• prohibition on using data for unrelated disciplinary purposes;

• clear employee notices; and

• periodic review.

Again, the DPO advises and monitors. Management makes the ultimate operational decision.

67. Another integrated example: data breach

Suppose an employee accidentally sends a spreadsheet containing 100,000 customer records to an external recipient.

The DPO may:

1. assist in determining what data was involved;

2. assess the likely risk;

3. advise on containment;

4. advise on regulatory notification;

5. advise on communication with affected individuals;

6. coordinate regulatory contact where appropriate;

7. monitor remediation;

8. recommend training or technical safeguards.

But the DPO does not automatically become the person legally responsible for the breach.

The controller's obligations remain the controller's obligations.

68. Article 39 and the concept of “effective” compliance

An organisation can have all of the following:

• privacy policies;

• a DPO;

• DPIA templates;

• training materials;

• data inventories;

• contracts;

• retention schedules.

Yet still have poor GDPR compliance.

Why?

Because compliance depends upon implementation.

Article 39's monitoring function helps bridge this gap.

The DPO asks:

Does the organisation actually do what its policies say?

That is arguably one of the most valuable functions of the DPO.

69. Final synthesis

Article 39 should ultimately be understood as creating a multi-dimensional governance role.

The DPO is:

An adviser

The DPO explains legal obligations and recommends practical solutions.

An educator

The DPO raises awareness and supports appropriate training.

A monitor

The DPO examines whether the organisation's processing complies with applicable requirements.

A risk assessor and challenger

The DPO focuses attention on processing operations presenting greater risks.

A DPIA adviser

The DPO advises on whether and how DPIAs should be performed and monitors their implementation.

A regulatory facilitator

The DPO cooperates with the supervisory authority and acts as an appropriate contact point.

An escalation function

The DPO should be capable of bringing serious concerns to senior management and, where appropriate, engaging with the supervisory authority.

But the DPO is not:

• the controller;

• the ultimate compliance owner;

• an automatic decision-maker;

• an automatic veto-holder;

• personally responsible for every organisational violation;

• automatically responsible for conducting every DPIA; or

• required to report every internal defect to the regulator.

The most important conceptual distinction is therefore:

The DPO is responsible for performing the DPO function; the controller remains responsible for the processing.

That distinction protects both sides.

It protects the organisation because management retains responsibility for making informed decisions and implementing compliance.

It protects the DPO because the DPO is not transformed into a scapegoat for decisions made by management contrary to the DPO's advice.

And it protects data subjects because the DPO provides an independent internal mechanism through which privacy risks can be identified, challenged, escalated and monitored.

70. Examination and practice-oriented conclusions

For legal analysis, Article 39 is best approached through five questions.

First: What is the DPO required to do?

At minimum, inform and advise, monitor compliance, advise and monitor DPIAs, cooperate with the supervisory authority, and act as the regulatory contact point.

Second: Who remains responsible for compliance?

The controller or processor remains responsible for fulfilling its own GDPR obligations. The DPO does not become the controller merely by advising or monitoring.

Third: Can additional tasks be assigned to the DPO?

Yes, because Article 39 establishes a minimum list. But additional tasks must not create conflicts of interest or undermine independence.

Fourth: What controls the DPO's priorities?

Article 39(2): risk associated with processing, taking account of nature, scope, context and purposes.

Fifth: What is the DPO's fundamental institutional role?

To provide an independent, sufficiently resourced and knowledgeable privacy function capable of advising, challenging, monitoring and facilitating regulatory engagement without taking over the controller's decision-making responsibilities.

The deepest point in Article 39 is therefore not any individual subparagraph. It is the architecture of responsibility that the provision creates.

The GDPR does not solve the problem of organisational privacy compliance by appointing one person and transferring all responsibility to that person. Instead, it creates a system in which the controller owns the compliance obligation, while theDPO provides independent expertise, monitoring, challenge, advice and regulatory facilitation.

That distinction is what makes the DPO function meaningful.

A DPO who merely approves management decisions is ineffective.

A DPO who attempts to run the entire organisation's privacy programme and make all processing decisions risks becoming conflicted.

A DPO who identifies risks, provides well-reasoned advice, monitors implementation, documents concerns, escalates serious issues and maintains an appropriate regulatory relationship is performing the role contemplated by Article 39.

In practical terms, therefore, Article 39 should be read not as a checklist of administrative duties, but as the legal framework for an independent internal privacy governance and assurance function.

The provision's repeated emphasis on informing, advising, monitoring, cooperating and acting as a contact point demonstrates that the DPO's power is principally informational, advisory, supervisory and facilitative, rather than executive.

And Article 39(2) adds the final qualification: those functions must be performed intelligently and proportionately, by directing greater attention toward processing operations capable of producing greater risks to individuals.

The resulting model is:

Understand the processing → identify the risks → advise the organisation → challenge inadequate approaches → monitor implementation → document significant issues → escalate where necessary → facilitate regulatory engagement → continuously reassess risk.

That is the practical meaning of Article 39.