Article 31 — Cooperation with the supervisory authority

Article 31 is short, but it is one of those GDPR provisions whose practical importance is much greater than its wording suggests. It is the bridge between the supervisory authority's investigative powers and the regulated entity's duty to facilitate regulatory oversight. The real difficulty lies in determining what counts as a valid request, how far cooperation extends, whether the authority can demand more than Article 58 expressly says, what happens when cooperation may expose an undertaking to sanctions, and how Article 31 interacts with fundamental procedural rights.

Below is a detailed commentary focused on those issues, without reproducing the bare Act.

1. The basic function of Article 31

Article 31 establishes a general duty of cooperation between regulated entities and the supervisory authority.

At first sight, the provision appears almost self-evident. A supervisory authority cannot effectively enforce the GDPR if controllers and processors simply refuse to answer its questions, provide documents, permit inspections, identify relevant processing operations, or otherwise assist an investigation.

But Article 31 performs a more sophisticated function.

The GDPR creates a regulatory system based on supervisory oversight rather than prior governmental approval of every processing activity. Controllers generally do not have to obtain permission from a supervisory authority before processing personal data. They are instead expected to comply with the Regulation themselves and to be able to demonstrate compliance.

That model only works if supervisory authorities can subsequently investigate whether compliance actually exists.

Article 31 therefore forms part of the GDPR's broader accountability architecture.

The relationship can be understood as:

Controller/processor → conducts processing → maintains compliance evidence → supervisory authority investigates → entity must cooperate.

Article 30 is particularly relevant here. A controller's records of processing activities, for example, allow the supervisory authority to understand what processing is taking place. Article 31 then ensures that the authority is not merely given a theoretical right to investigate but can obtain the cooperation necessary to perform its functions.

This is why Article 31 should not be read in isolation. Its practical meaning emerges primarily from its interaction with:

• Article 30, concerning records of processing activities;

• Article 33, concerning breach notification;

• Article 35, concerning DPIAs;

• Article 36, concerning prior consultation;

• Articles 51-54, concerning supervisory authorities;

• Article 57, concerning supervisory-authority tasks;

• Article 58, concerning supervisory-authority powers;

• Article 83, concerning administrative fines;

• Article 84, concerning other penalties;

• Article 47 of the Charter, concerning effective judicial protection;

• Article 6 ECHR and corresponding fundamental-rights principles concerning procedural fairness and protection against self-incrimination.

The most important conceptual point is this:

Article 31 is not itself the principal source of the supervisory authority's investigative powers. It creates a corresponding duty of cooperation around the supervisory authority's lawful regulatory functions.

That distinction becomes extremely important when a company receives a regulatory request.

2. Article 31 is largely a supporting or declaratory provision

Article 31 is often described as a largely declaratory provision.

That does not mean that it has no legal effect.

Rather, much of what Article 31 says is developed elsewhere in the GDPR.

Article 57 tells us what supervisory authorities are required to do.

Article 58 tells us what supervisory authorities are empowered to do.

Article 31 then establishes that controllers, processors and applicable representatives must cooperate when the supervisory authority requires their cooperation in performing those functions.

Example

Article 58 gives supervisory authorities investigative powers, including the ability to obtain information and access information necessary for their investigation.

Article 31 reinforces the recipient's obligation to cooperate.

This creates an important distinction between:

The authority's power

The supervisory authority must possess a legal power to demand or investigate something.

The entity's obligation

The controller or processor must cooperate with the lawful exercise of that regulatory function.

The sanction

Failure to comply may itself constitute a GDPR infringement and can potentially lead to an administrative fine.

These three concepts should not automatically be collapsed into one another.

A supervisory authority cannot simply say:

"Article 31 requires cooperation, therefore we can demand absolutely anything."

That would make Article 31 limitless.

At the same time, a controller cannot simply respond:

"Article 31 is only a general provision, therefore we can ignore the request."

That is equally wrong.

The correct approach requires examining the nature of the request, the authority's statutory task, the authority's investigative power, proportionality, procedural safeguards and any applicable fundamental rights.

3. Who is bound?

The provision applies to three principal categories:

1. controllers;

2. processors;

3. their representatives, where applicable.

This is important because Article 31 does not impose the duty exclusively on controllers.

A processor can therefore be approached directly by a supervisory authority.

Example

suppose:

• Company A operates an online marketplace;

• Company B provides cloud infrastructure;

• Company A is the controller;

• Company B is the processor.

A supervisory authority investigating Company A's security arrangements may require information from Company B.

Company B cannot necessarily respond:

"We are merely a processor. You must ask our customer."

The processor itself has obligations under the GDPR and may be directly subject to regulatory oversight.

This becomes particularly important in modern technology arrangements involving:

• cloud providers;

• SaaS platforms;

• hosting companies;

• payment processors;

• customer-support providers;

• data analytics providers;

• HR platforms;

• AI service providers;

• outsourced call centres;

• managed security providers.

The contractual relationship between controller and processor does not prevent the supervisory authority from engaging directly with the processor.

4. The role of the representative

The reference to representatives is particularly important for organisations outside the EU.

A non-EU controller or processor may, in certain circumstances, be required to designate an EU representative under Article 27.

The representative does not become the controller merely because it represents the controller.

Its function is essentially to provide a regulatory point of contact within the Union.

This has practical importance because an EU supervisory authority should not have to deal with a completely inaccessible organisation located thousands of kilometres away with no established EU contact.

The representative can therefore be approached regarding matters falling within its mandate.

However, one should not confuse representation withtransfer of responsibility.

The designation of a representative does not ordinarily transform the representative into the underlying controller or processor.

The substantive GDPR responsibility remains with the controller or processor.

This distinction is particularly important in enforcement.

Imagine:

A US-based online service processes personal data of EU users and is required to appoint an EU representative.

The representative receives an investigation request.

It cannot simply say:

"I am not responsible for GDPR compliance, so I have no role."

Its representative function exists precisely to facilitate regulatory engagement.

At the same time, the underlying company cannot assume:

"We appointed a representative, so all GDPR responsibility has shifted to them."

That is not the purpose of Article 27 or Article 31.

5. What exactly does "on request" mean?

This is one of the most important phrases in the provision.

Article 31 creates a reactive duty of cooperation.

The duty arises when the supervisory authority makes a request.

This distinguishes Article 31 from provisions imposing proactive obligations.

Example

GDPR obligations can require a controller to act without waiting for the supervisory authority:

• breach notification under Article 33;

• data-subject notification in appropriate circumstances;

• prior consultation under Article 36 where its conditions are satisfied;

• maintaining appropriate records;

• conducting DPIAs where required.

Article 31 operates differently.

The supervisory authority first makes the request.

The recipient then has a duty to cooperate.

This does not, however, mean that an organisation has no compliance responsibilities until an authority contacts it.

Quite the opposite.

A mature compliance programme should ensure that the organisation can respond quickly when a request arrives.

6. "On request" does not mean "only when formally investigated"

Another subtle point is that a supervisory authority does not necessarily need to be investigating a known violation before requesting cooperation.

The authority may perform regulatory tasks that are broader than responding to an established infringement.

Example

a supervisory authority may:

• monitor GDPR compliance;

• investigate complaints;

• conduct inspections;

• assess emerging technologies;

• supervise high-risk processing;

• investigate security practices;

• cooperate with other supervisory authorities;

• conduct general regulatory oversight.

Therefore, the controller should not assume:

"Unless you have already proved that we violated the GDPR, you cannot ask us questions."

That reverses the regulatory structure.

The authority's legitimate supervisory task can itself justify regulatory engagement.

7. Does the authority need reasonable suspicion?

Generally, the existence of a request under Article 31 does not necessarily depend upon the supervisory authority possessing a prior, specific suspicion of unlawful processing.

This is a crucial distinction.

A supervisory authority may be performing a regulatory function rather than prosecuting an already-established violation.

Consider two situations.

Situation A: Complaint-driven investigation

A data subject complains:

"The company refused to delete my personal data."

The authority contacts the company and asks:

• when was the request received?

• what response was provided?

• what data were retained?

• what legal basis justified retention?

The connection with the authority's task is obvious.

Situation B: Sectoral investigation

The authority is examining how large online platforms handle children's data.

It contacts several organisations and asks about:

• age-assurance mechanisms;

• categories of data collected;

• retention periods;

• automated profiling;

• parental controls.

There may be no specific complaint against each company.

Nevertheless, the authority may still be performing a legitimate supervisory function.

Therefore:

No initial suspicion is necessarily required merely because the authority is exercising regulatory oversight.

But this does not mean the authority has unlimited discretion.

8. The crucial limitation: the request must relate to the authority's tasks

The words requiring cooperation "in the performance of its tasks" impose an important legal boundary.

The supervisory authority is not entitled to use Article 31 as a general-purpose information-gathering power unrelated to data protection regulation.

Its request must be connected with its statutory responsibilities.

This is where Article 57 becomes crucial.

Article 57 identifies the functions of supervisory authorities.

Consequently, a company receiving a request should ask:

What regulatory task is this request connected to?

For example:

• investigating a complaint;

• monitoring GDPR application;

• investigating an alleged infringement;

• supervising compliance;

• cooperating with another authority;

• examining a transfer issue;

• investigating security measures.

The closer the connection, the stronger the legal basis for the request.

9. Proportionality is an essential limitation

Even where a supervisory authority has a legitimate task, the request should not be understood as automatically unlimited.

The GDPR operates within broader principles of EU law, including proportionality and fundamental rights.

Suppose a regulator asks a small company:

"Provide every document relating to every customer you've ever had."

That request may be dramatically broader than necessary for investigating a narrow issue.

Compare this with:

"Provide the records relating to the 15 customers whose deletion requests are the subject of this investigation."

The second request is much more closely tailored to the regulatory purpose.

This does not mean a company may simply refuse the first request.

It means that the scope, relevance and proportionality of regulatory demands matter.

A sensible compliance response should therefore distinguish between:

• a request that appears burdensome but is legally justified;

• a request that is unclear and needs clarification;

• a request that appears manifestly excessive;

• a request that potentially conflicts with fundamental rights or another legal obligation.

The safest approach is normally not immediate refusal.

Instead:

1. identify the legal basis;

2. clarify ambiguity;

3. preserve relevant records;

4. provide responsive material;

5. raise legitimate objections in a documented manner where necessary.

10. Article 31 and Article 58 must be read together

This is perhaps the most important structural relationship.

Article 58 gives supervisory authorities specific powers.

These include investigative powers such as obtaining information, conducting investigations, obtaining access to personal data and premises, and exercising other regulatory powers.

Article 31 creates a broader cooperation framework.

Therefore, when an authority asks a company to provide documents, one should determine whether the request is being made:

• under Article 58;

• under Article 31;

• under another GDPR provision;

• or under applicable national procedural law.

This matters because the precise legal consequences can differ.

For example:

"Please provide the following information pursuant to Article 58(1)(a)."

is materially different from:

"We invite you voluntarily to provide the following information."

The first is a regulatory demand.

The second may be voluntary.

The word "voluntary" should therefore never be ignored.

A company should understand whether it is receiving:

• an informal request;

• a formal information demand;

• an inspection notice;

• an enforcement order;

• a request for cooperation;

• or a combination of these.

11. Can Article 31 fill gaps in Article 58?

This is one of the more interesting doctrinal questions.

One possible interpretation is that Article 31 merely reinforces the specific powers already granted under Article 58.

Another interpretation gives Article 31 independent significance as a gap-filling provision.

Under the latter approach, Article 31 could potentially support requests that are necessary for the authority's legitimate tasks but do not fit neatly into one of the express powers in Article 58.

This interpretation must nevertheless be handled cautiously.

Otherwise Article 31 could become a backdoor method of circumventing the carefully structured limitations of Article 58.

Imagine Article 58 deliberately grants an authority certain investigative powers but places procedural boundaries around them.

If the authority could simply invoke Article 31 to bypass those boundaries, Article 58's carefully constructed framework would become meaningless.

Therefore, a strong interpretation is:

Article 31 provides an independent general cooperation obligation, but it cannot be interpreted in a manner that destroys the legal and fundamental-rights limitations governing supervisory powers.

This distinction is extremely important in litigation.

12. Cooperation is broader than merely answering emails

"Cooperate" should not be understood narrowly.

Cooperation may involve positive action.

For example:

• supplying documents;

• providing explanations;

• identifying responsible personnel;

• explaining processing architecture;

• providing relevant records;

• answering factual questions;

• facilitating access to systems where legally appropriate;

• arranging an inspection;

• providing information about processors or subprocessors.

It can also involve tolerating regulatory activity.

Example

if an authority lawfully exercises an inspection power, the organisation may have to permit access to relevant premises.

Therefore:

Cooperation is both an active and passive concept.

A controller cannot satisfy Article 31 merely by avoiding obstruction.

If the authority asks for information, the organisation may need to actively produce it.

13. Cooperation versus voluntary assistance

An important practical distinction exists between a mandatory request and a voluntary request.

If an authority expressly asks:

"We invite you to voluntarily provide information..."

that wording may indicate that the authority is not presently imposing a compulsory obligation.

The legal consequences therefore need to be examined carefully.

This is particularly important because organisations sometimes respond to every communication from a regulator as though it were legally compulsory.

That can create unnecessary disclosure of sensitive information.

Conversely, treating a mandatory regulatory demand as merely voluntary can result in non-compliance.

The recipient should therefore examine:

• the wording of the request;

• the legal provision invoked;

• the deadline;

• the documents requested;

• whether the authority identifies an enforcement or investigative power;

• applicable national procedural rules.

14. The role of the DPO

The Data Protection Officer is not directly one of the principal addressees of Article 31 merely by virtue of being a DPO.

However, Article 39 gives the DPO responsibilities involving cooperation with the supervisory authority.

This creates an important division of responsibility.

The controller or processor remains responsible for compliance.

The DPO acts as an independent compliance and advisory function.

In practice, the DPO may be the principal regulatory contact.

For example:

Regulator → DPO → Legal/Privacy team → business owner → IT/security → response to regulator

This is usually sensible because the DPO can coordinate the response while maintaining the independence required by Article 38.

But an organisation should avoid turning the DPO into the person legally responsible for the company's compliance.

That can create a serious governance problem.

The DPO advises, monitors and cooperates.

Management remains responsible for the organisation's substantive compliance decisions.

15. Article 31 does not eliminate the controller's responsibility

A controller cannot respond to a regulatory request:

"Our processor has the relevant data, so please contact them."

The controller's responsibility does not disappear merely because processing has been outsourced.

Similarly, a processor cannot always say:

"The controller owns the data, therefore we have no obligation to cooperate."

Both parties can have direct obligations.

This is particularly important in complex outsourcing arrangements.

For example:

Bank → cloud provider → cybersecurity vendor → subcontracted support provider

A regulatory investigation may require information distributed across the chain.

The controller should therefore maintain sufficient contractual arrangements to ensure that regulatory cooperation is operationally possible.

This is one reason Article 28 contracts should address cooperation with supervisory authorities.

16. Contractual allocation of regulatory cooperation

Article 31 itself operates independently of contract.

A processor does not become subject to Article 31 merely because the controller inserted a clause into the Data Processing Agreement.

The statutory obligation arises from the GDPR.

Nevertheless, contractual provisions are extremely important for implementation.

A DPA might establish:

• who receives regulatory correspondence;

• who informs whom;

• response timelines;

• document preservation;

• allocation of responsibility;

• regulatory inspection procedures;

• communication protocols;

• escalation procedures;

• confidentiality arrangements.

For example:

Regulator contacts processor directly → processor informs controller → both coordinate response → processor provides technical evidence → controller handles substantive legal position.

Without such arrangements, a regulatory request can create chaos.

17. The processor-controller conflict problem

Suppose the supervisory authority investigates the controller and requests information held by the processor.

The processor may face competing interests.

The controller might say:

"Do not provide anything to the regulator without our approval."

But the processor may have its own legal obligations.

A contractual instruction from the controller cannot necessarily override an independent statutory obligation owed to a supervisory authority.

This illustrates a broader principle:

Contractual instructions operate within the boundaries of applicable law.

The controller does not acquire unlimited control over the processor merely because Article 28 establishes a processor relationship.

This becomes particularly important where the controller attempts to suppress disclosure of information that the processor is legally required to provide.

18. Confidentiality and trade secrets

Another difficult issue concerns sensitive commercial information.

Suppose the regulator requests:

• source-code information;

• security architecture;

• proprietary algorithms;

• pricing models;

• customer lists;

• technical diagrams;

• internal risk assessments.

The organisation may argue that disclosure would reveal trade secrets.

That does not automatically extinguish the duty to cooperate.

Regulatory confidentiality and trade-secret protections must be balanced.

Possible mechanisms can include:

• redaction where legally permissible;

• confidentiality arrangements;

• secure data rooms;

• limited disclosure;

• controlled inspection;

• explanations rather than unnecessary production of unrelated material.

The key point is:

"Confidential" does not automatically mean "immune from regulatory disclosure."

A supervisory authority's legitimate investigative function may justify receiving highly sensitive material.

At the same time, the authority's request should remain legally grounded and proportionate.

19. The most difficult issue: self-incrimination

The most sophisticated issue surrounding Article 31 is the relationship between cooperation and the privilege against self-incrimination.

Imagine the supervisory authority asks:

"Did your company knowingly ignore the GDPR requirement despite receiving legal advice that the processing was unlawful?"

An answer could potentially provide evidence of an infringement.

Can the company be forced to make an incriminating admission?

This is where fundamental rights become relevant.

The privilege against self-incrimination forms part of the broader protection of defence rights and fair procedures.

Under European human-rights law, the precise scope of the privilege depends upon the circumstances.

The basic principle is that a person should not necessarily be compelled, under threat of punishment, to provide an admission that establishes their own wrongdoing.

20. Why this matters particularly under GDPR

GDPR violations can result in extremely substantial administrative fines.

Article 83 permits significant fines, potentially reaching:

• €10 million or

• 2% of worldwide annual turnover for certain infringements,

and higher levels for more serious categories of infringements.

Moreover, Member States may provide for additional penalties under Article 84.

Therefore, the distinction between an ordinary regulatory information request and compelled self-incriminating testimony can become constitutionally significant.

The fact that a sanction is labelled "administrative" does not automatically settle the fundamental-rights question.

EU fundamental-rights jurisprudence looks at matters such as the nature and severity of the sanction.

21. The Orkem analogy

The case commonly discussed in this context is Orkem v Commission.

The Court of Justice recognised limits on compelling an undertaking to provide answers that effectively require it to admit an infringement which the authority itself is responsible for proving.

The broader principle is highly relevant:

A regulatory authority may be able to demand factual information and existing documents without necessarily being able to compel an undertaking to construct an admission of its own infringement.

This creates an important distinction.

Existing factual evidence

The authority might ask:

"Provide all internal emails concerning the deletion request."

That is fundamentally a request for existing evidence.

Compelled admission

The authority might ask:

"Confirm that your company intentionally violated Article 17."

That moves much closer to compelled self-incrimination.

The distinction is not always simple.

An apparently factual question may itself effectively require an admission.

22. Does self-incrimination mean the company can refuse everything?

Absolutely not.

This is a common overstatement.

The existence of a privilege against self-incrimination does not create a general right to ignore supervisory authorities.

A company generally cannot say:

"Everything you ask might potentially hurt us, so we refuse to cooperate."

That would destroy the regulatory system.

The more defensible distinction is between:

ordinary factual/regulatory cooperation

and

compelled testimonial evidence that effectively forces an admission of an offence or infringement.

The precise boundary depends on the applicable fundamental-rights jurisprudence and procedural context.

This remains an area requiring careful legal analysis.

23. Documents versus compelled statements

This distinction is especially important.

Suppose a regulator asks:

"Produce your internal DPIA."

That is a request for an existing document.

Compare:

"Explain why you deliberately ignored the risks identified in the DPIA."

The second question may require a more evaluative response.

A further question:

"Admit that you knew the DPIA demonstrated that the processing was unlawful."

moves even closer to compelled self-incrimination.

Therefore, regulatory teams should classify requests carefully.

A useful internal classification is:

This does not mean every item in the final category is automatically protected.

It means the legal risk is substantially higher.

24. "Cooperation" does not mean surrendering defence rights

One of the biggest mistakes organisations make is assuming:

==Regulatory cooperation = giving up all procedural rights.==

That is incorrect.

A controller can cooperate while still:

• requesting clarification;

• asserting legal privilege where applicable;

• raising confidentiality concerns;

• challenging disproportionate requests;

• seeking reasonable extensions;

• identifying jurisdictional issues;

• preserving procedural objections;

• asserting fundamental rights where appropriate.

The correct approach is cooperate without abandoning lawful procedural protections.

This is particularly important because an aggressive refusal can itself create an Article 31 issue.

25. The importance of a clear regulatory request

Because failure to comply with Article 31 can be sanctioned, the request should ordinarily be sufficiently clear for the recipient to understand what is expected.

Imagine a regulator sends:

"Provide all relevant information."

That is extraordinarily vague.

What constitutes "relevant"?

Which period?

Which systems?

Which individuals?

Which processing activities?

Which documents?

A recipient should not necessarily guess.

It may legitimately seek clarification.

This is not necessarily non-cooperation.

Indeed, asking:

"Could you please clarify whether the request covers records from January 2024 onwards and whether the scope includes our processor's systems?"

may actually demonstrate responsible cooperation.

26. Deadlines matter

Regulatory cooperation is time-sensitive.

An organisation should not wait until the deadline to discover that:

• the relevant documents are archived;

• the processor holds the information;

• the DPO is unavailable;

• IT needs several days to extract logs;

• legal review is necessary.

A mature organisation should have a regulatory response protocol.

For example:

Day 0

Request received.

Day 1

Legal/DPO triage.

Day 2

Scope identified.

Day 3

Data owners assigned.

Day 4-7

Documents collected.

Day 8

Legal review.

Day 9

Confidentiality/redaction assessment.

Day 10

Submission.

The exact timeline obviously depends on the regulator's deadline.

27. The regulator's request should not be confused with a data-subject request

A regulatory request is fundamentally different from a data-subject access request.

Under Article 15, the individual is exercising a statutory right.

Under Article 31, the supervisory authority is performing a regulatory function.

This distinction matters because the organisation should have separate internal workflows.

For example:

DSAR workflow → verify identity → locate personal data → assess exemptions → respond to individual.

Regulatory request workflow → verify authority → determine legal basis → preserve evidence → identify scope → coordinate response → legal/procedural review → submit to regulator.

Mixing the two can produce significant errors.

28. Article 31 and records of processing activities

Article 30 provides an excellent example of how Article 31 operates in practice.

Suppose a supervisory authority asks:

"Provide your record of processing activities."

The controller should be able to produce it.

If it has not maintained the record properly, Article 31 may become the immediate problem, but the underlying Article 30 non-compliance may also become relevant.

This demonstrates an important enforcement principle:

A regulatory request often exposes multiple compliance deficiencies simultaneously.

Example

a regulator investigating a complaint about employee monitoring may discover:

• no proper ROPA;

• inadequate retention policy;

• no DPIA despite high-risk processing;

• excessive monitoring;

• insufficient transparency;

• inadequate access controls.

A regulatory investigation can therefore expand from one issue into a broader compliance examination, subject to the authority's lawful powers and procedural framework.

29. Article 31 and data breaches

Article 31 becomes especially important during breach investigations.

Imagine:

A company suffers a ransomware incident.

The supervisory authority investigates.

It may ask:

• when did the breach begin?

• when was it discovered?

• what systems were affected?

• what categories of data were involved?

• what security measures existed?

• what logging was enabled?

• when was the incident reported?

• what remediation was performed?

The company cannot simply say:

"We already notified you under Article 33, so we have nothing else to provide."

Article 33 notification and Article 31 cooperation serve different functions.

The breach notification is an initial statutory communication.

The subsequent investigation may require much greater detail.

30. Article 31 and the DPO's independence

The DPO may coordinate regulatory correspondence, but the DPO should not be placed in a position where they are pressured to conceal non-compliance.

Example

management should not tell the DPO:

"Do not disclose the DPIA because it makes us look bad."

The DPO's role includes cooperation with the supervisory authority.

At the same time, the DPO is not the organisation's litigation counsel.

This means the organisation should ideally distinguish:

DPO function

• regulatory liaison;

• monitoring;

• advice;

• compliance coordination.

Legal function

• legal privilege;

• litigation strategy;

• procedural objections;

• defence of enforcement proceedings.

This separation can become extremely important during contentious investigations.

31. Article 31 and legal professional privilege

Another difficult issue is legally privileged material.

Suppose a company receives legal advice from external counsel stating:

"Your current processing probably violates Article 6."

The regulator asks for all internal and external communications concerning that advice.

The company may have grounds to resist disclosure depending on applicable privilege rules.

Article 31 does not automatically erase legal privilege.

This again demonstrates that:

The duty to cooperate exists within the broader legal system.

The correct response is not necessarily blanket refusal.

The company should identify privileged material, explain the basis for withholding it where appropriate, and provide non-privileged material where legally required.

32. Article 31 and processors with massive customer bases

The practical burden can become enormous for large processors.

Consider a cloud provider with 100,000 customers.

A regulator investigates the cloud provider's processing arrangements and asks:

"Identify all controllers for whom you process personal data."

This could involve a massive database.

The processor should nevertheless maintain sufficient information to identify its controller relationships.

This is another reason processors should have a structured ROPA and customer classification system.

For major processors, regulatory readiness should include:

• customer/controller mapping;

• processing-category mapping;

• subprocessor mapping;

• transfer mapping;

• security-control documentation;

• incident records;

• contractual records.

33. The importance of authenticity and regulator verification

In practice, organisations should also verify that a purported regulatory request is genuine.

This sounds obvious, but modern organisations receive phishing emails impersonating authorities.

A request for:

• customer records;

• employee data;

• security documentation;

• credentials;

• confidential information

should not automatically be treated as authentic merely because it appears to come from a regulator.

A sensible verification process may involve:

1. verifying the authority's domain;

2. checking official contact information;

3. confirming the case/reference number;

4. contacting the authority through independently verified channels;

5. confirming the identity of the requesting officer.

Once authenticity is established, however, the organisation should not use verification as a pretext for delay.

34. What happens if the organisation ignores the request?

This is where Article 31 becomes materially important.

Failure to cooperate can itself constitute a GDPR infringement.

Article 83(4)(a) places Article 31 among the obligations whose infringement can attract administrative fines.

The potential fine is significant.

Therefore:

Ignoring a regulator can create a second violation on top of the violation being investigated.

Imagine:

1. Company unlawfully processes data.

2. Regulator investigates.

3. Company refuses to cooperate.

4. Company may now face consequences for both the underlying processing violation and failure to cooperate.

This is why deliberately obstructive behaviour is extremely risky.

35. Silence is not always a neutral strategy

In ordinary commercial disputes, silence may sometimes be tactically useful.

In regulatory investigations, it can be dangerous.

Suppose the regulator asks:

"Please provide the relevant DPIA within 14 days."

The organisation simply does nothing.

Even if the underlying DPIA would ultimately demonstrate compliance, failure to cooperate creates an unnecessary enforcement risk.

A much better strategy is:

"We are compiling the requested DPIA and expect to provide it by [date]. We require an extension of seven days because the document is held in archival systems."

That demonstrates cooperation while preserving practical feasibility.

36. Cooperation should be accurate, not merely extensive

Another subtle point:

More information is not always better.

An organisation sometimes responds to a regulator by dumping thousands of irrelevant documents into a data room.

This may technically look cooperative but can actually:

• obscure important evidence;

• create confidentiality problems;

• reveal unrelated personal data;

• create inconsistencies;

• generate additional regulatory questions;

• increase the risk of accidental disclosure.

Regulatory responses should therefore be:

complete + accurate + relevant + structured.

Not simply:

massive.

37. The danger of inconsistent answers

Regulators often compare information received from different sources.

Suppose:

Controller says: "Only EU data is stored in Europe."

But:

Processor says: "Support personnel in India and the US can access the data."

The discrepancy can immediately raise questions concerning international transfers and remote access.

Similarly:

DPO says: "Data is deleted after 30 days."

But:

IT says: "Backups remain for 12 months."

Such inconsistencies can undermine credibility.

Therefore, before responding to a regulator, organisations should conduct an internal fact reconciliation exercise.

38. Regulatory response should be evidence-based

A strong response should distinguish between:

Known facts

"The request was received on 2 August."

"The relevant log is attached."

Interpretation

"Our legal assessment is that Article 6(1)(f) applies."

Uncertainty

"We are verifying whether historical backups contain the relevant records."

This distinction is extremely valuable.

It prevents the organisation from accidentally presenting assumptions as facts.

39. Can a regulator request personal data?

Yes, where necessary for its lawful supervisory function.

This is unsurprising because supervisory authorities themselves may need access to personal data to investigate compliance.

Example

an investigation into unlawful employee monitoring might require access to:

• employee records;

• monitoring logs;

• communications;

• access records.

The organisation cannot automatically refuse on the ground:

"Those are personal data, so GDPR prevents us from giving them to you."

That misunderstands the GDPR.

The supervisory authority operates within the regulatory framework and may have legal authority to obtain relevant personal data.

40. Article 31 and minimisation

Nevertheless, the organisation should still consider data minimisation.

If a regulator asks for information concerning:

"Employee A's monitoring activity during March 2026"

the organisation should not automatically provide unrelated personal records concerning:

• medical history;

• salary;

• family information;

• private communications.

The organisation should provide what is legally required and relevant to the investigation.

Again, the goal is cooperation without unnecessary disclosure.

41. International groups and multiple supervisory authorities

Large multinational organisations can face multiple supervisory authorities.

For example:

• Irish authority;

• French authority;

• German authority;

• Dutch authority.

The controller may have a lead supervisory authority under the one-stop-shop mechanism, but other concerned authorities may still have roles under the GDPR.

Therefore, organisations need a centralised regulatory-response mechanism.

A multinational should ideally maintain:

• regulator contact register;

• authority correspondence history;

• case management system;

• DPO escalation process;

• legal review procedure;

• evidence-preservation protocol.

This prevents different subsidiaries from giving inconsistent answers to different regulators.

42. The hidden importance of Article 31 in AI governance

Article 31 is increasingly important in AI and emerging-technology investigations.

Imagine an AI company processes:

• prompts;

• user profiles;

• behavioural data;

• biometric information;

• model-training datasets.

A supervisory authority may ask:

"Explain what categories of personal data were used to train the model."

Or:

"Provide documentation demonstrating the source and legal basis for the training data."

Or:

"Identify processors involved in hosting and model operations."

Article 31 means the company cannot simply avoid engagement because its architecture is technically complex.

The company needs regulatory readiness.

For AI companies, this means maintaining documentation concerning:

• datasets;

• purposes;

• legal bases;

• data provenance;

• retention;

• model-development processes;

• processors;

• international transfers;

• security controls;

• data-subject rights mechanisms.

43. A practical regulatory response framework

When an Article 31 request arrives, a sophisticated organisation should follow a structured process.

Step 1: Authenticate the request

Confirm that it genuinely originates from the competent supervisory authority.

Step 2: Identify the legal basis

Determine whether the authority invokes:

• Article 31;

• Article 58;

• another GDPR provision;

• national procedural law.

Step 3: Identify the scope

Determine:

• processing activity;

• time period;

• data categories;

• documents;

• personnel;

• systems.

Step 4: Preserve evidence

Issue appropriate litigation/regulatory holds where necessary.

Step 5: Identify owners

Typical stakeholders include:

• DPO;

• privacy counsel;

• litigation counsel;

• IT;

• security;

• HR;

• business teams;

• processor management.

Step 6: Collect evidence

Gather documents from authoritative systems.

Step 7: Reconcile facts

Check that statements from different teams are consistent.

Step 8: Identify protected material

Assess:

• legal privilege;

• trade secrets;

• confidential third-party information;

• personal data;

• security-sensitive information.

Step 9: Assess self-incrimination concerns

Especially where the regulator requests admissions or explanations that could establish an infringement.

Step 10: Respond accurately

Answer each question directly.

Step 11: Maintain the regulatory record

Preserve:

• request;

• correspondence;

• internal analysis;

• documents produced;

• explanations;

• extensions;

• final submission.

This becomes extremely valuable if enforcement proceedings later arise.

44. What Article 31 does not mean

Several common misconceptions should be rejected.

Myth 1: "The regulator can ask anything."

No. The request must relate to the authority's lawful tasks and operate within applicable legal and fundamental-rights constraints.

Myth 2: "The company can refuse unless there is a complaint."

No. A supervisory authority may have broader supervisory tasks.

Myth 3: "Article 31 applies only to controllers."

No. Processors and applicable representatives are also directly covered.

Myth 4: "The DPO is legally responsible for cooperation."

Not in that sense. The organisation remains responsible, although the DPO has related statutory duties.

Myth 5: "Anything confidential can be withheld."

No. Confidentiality does not automatically defeat regulatory authority.

Myth 6: "Self-incrimination allows refusal of everything."

No. The privilege is not a blanket immunity from regulatory investigation.

Myth 7: "A processor can ignore the regulator because it acts for the controller."

No. Processors have their own GDPR obligations.

Myth 8: "Article 31 replaces Article 58."

No. Article 58 remains central to the authority's investigative and corrective powers.

45. The deeper conceptual significance

Article 31 embodies an important principle of modern data protection regulation:

Accountability requires not merely complying with the law, but being capable of demonstrating and facilitating regulatory verification of that compliance.

This is why Article 31 fits naturally into the GDPR accountability model.

Consider the chain:

Article 5(2) The controller must be able to demonstrate compliance.

Article 24

The controller must implement appropriate measures and demonstrate compliance.

Article 30

The organisation maintains structured records of its processing.

Article 32

It implements appropriate security measures.

Article 35

It conducts DPIAs where required.

Article 31

It cooperates with the supervisory authority.

Article 57

The authority performs its regulatory tasks.

Article 58

The authority exercises investigative and corrective powers.

Article 83

Non-compliance can result in sanctions.

Seen this way, Article 31 is not an isolated procedural provision.

It is one of the mechanisms that makes the entire accountability model enforceable.

46. The most important practical distinction: cooperation versus defence

The sophisticated approach is neither:

"Give the regulator everything."

nor:

"Fight every request."

The correct approach is:

Cooperate where legally required, clarify where necessary, protect legitimate rights, and preserve procedural objections where appropriate.

That requires a disciplined legal strategy.

A company should therefore never confuse:

cooperation withconcession.

Providing documents does not necessarily mean admitting an infringement.

Answering factual questions does not necessarily mean accepting the regulator's legal interpretation.

Seeking clarification does not necessarily constitute refusal.

Raising privilege does not necessarily constitute obstruction.

And asserting a fundamental right does not necessarily mean refusing all cooperation.

These distinctions are extremely important during enforcement proceedings.

47. Final synthesis

Article 31 may consist of only a single sentence, but it creates a significant regulatory obligation.

Its essential architecture can be reduced to five questions:

1. Who must cooperate?

Controllers, processors and applicable representatives.

2. When?

When the supervisory authority makes a request.

3. Why?

To enable the supervisory authority to perform its GDPR tasks.

4. What does cooperation involve?

Potentially providing information, documents, explanations, access and other forms of assistance, depending on the lawful request.

5. Are there limits?

Yes.

The request must be connected to the authority's lawful functions and must operate within the broader framework of EU law, proportionality, procedural fairness, confidentiality, privilege and fundamental rights.

The most important practical lesson is therefore this:

Article 31 should never be treated as a simple "answer the regulator" provision. It is the intersection between GDPR accountability, supervisory powers, regulatory procedure and fundamental rights.

For controllers and processors, the safest compliance posture is to maintain a regulatory-readiness system before an investigation ever begins. That means knowing who owns the response, where the evidence is located, how the DPO and legal team coordinate, how processors will cooperate, how privileged material is handled, how deadlines are managed, and how factual accuracy is verified.

For legal analysis, the key is to read Article 31 together with Articles 30, 39, 51-58 and 83, rather than treating it as a standalone duty. Article 31 supplies the general cooperation obligation; Article 57 defines the regulatory mission; Article 58 supplies much of the concrete investigative machinery; and Article 83 gives non-compliance with Article 31 real enforcement consequences.

The most difficult unresolved territory concerns the precise boundary between mandatory cooperation and fundamental procedural rights, particularly the privilege against self-incrimination. That issue prevents Article 31 from being understood as an unlimited power to compel an undertaking to build the case against itself. At the same time, that limitation cannot be converted into a general licence to obstruct regulatory investigations.

In practical terms, the ideal response to a supervisory-authority request is therefore:

verify → identify legal basis → scope → preserve → collect → reconcile → assess privilege/confidentiality → identify fundamental-rights issues → respond completely and accurately → preserve the response record.

That is the operational meaning of Article 31 within the GDPR's broader accountability and enforcement architecture.

Article 32 is one of the most operationally important provisions in the GDPR because it converts the abstract principle of integrity and confidentiality into a concrete, risk-based security obligation. Its central idea is not that an organisation must make personal data absolutely secure. Rather, it must be able to show that it hasidentified the security risks created by its processing and implemented measures proportionate to those risks, while continuously testing whether those measures remain effective.

Below is a detailed commentary that goes beyond merely restating the provision and examines the difficult interpretive questions, practical implications, examples, grey areas, compliance strategy, and the relationship of Article 32 with Articles 5, 24, 25, 28, 33, 34 and 35.