Article 31: Cooperation with the supervisory authority

GDPR Article 31 requires your organization, as a controller or processor (and your EU representative if applicable), to cooperate with the supervisory authority whenever requested. Operationally, that means you need a defined regulator-request intake and response process, clear ownership, fast retrieval of accurate GDPR evidence, and a defensible record of what you provided and when. (Regulation (EU) 2016/679, Article 31)

Key takeaways:

• Build a single “supervisory authority request” workflow with named owners, legal review gates, and response tracking.
• Maintain a role-and-scope register so you can answer as controller vs. processor without improvising under pressure.
• Keep regulator-ready evidence packets (records, decisions, and actions) so you can respond completely and consistently.

Article 31 is short, but it becomes operationally heavy the first time a supervisory authority sends an inquiry, opens an investigation, or asks for documentation tied to a complaint, breach, or audit theme. The requirement is simple: cooperate “on request.” The execution is not. You need to route regulator communications correctly, respond within the authority’s expectations, and avoid self-inflicted errors like inconsistent statements, incomplete production, or a failure to engage because nobody “owns” the request.

For a CCO, Compliance Officer, or GRC lead, the goal is to turn Article 31 into a repeatable capability: (1) you recognize a supervisory authority request immediately, (2) you know who coordinates, (3) you can collect facts and evidence quickly across functions and third parties, and (4) you can provide clear, consistent responses with an auditable trail. This page gives requirement-level guidance you can implement without waiting for a full GDPR program redesign. It also explains how to prevent the most common failure mode: a policy that says “we cooperate,” with no operational mechanism to prove it.

Regulatory text

Text (verbatim): “The controller and the processor and, where applicable, their representatives, shall cooperate, on request, with the supervisory authority in the performance of its tasks.” (Regulation (EU) 2016/679, Article 31)

Operator interpretation: You must be able to receive, triage, and respond to supervisory authority requests in a timely, accurate, and complete way. “Cooperate” is practical, not symbolic: produce information, make knowledgeable staff available, explain decisions, and support the authority’s lawful tasks. The trigger is a request from the supervisory authority, not your own internal timeline. (Regulation (EU) 2016/679, Article 31)

Plain-English interpretation (what the requirement means in practice)

Article 31 creates a standing obligation: if a supervisory authority asks for information or assistance related to its tasks, you respond constructively. This is not limited to controllers. Processors also have direct obligations to cooperate, which matters when the authority contacts a service provider directly, or when you need the processor to support your response. (Regulation (EU) 2016/679, Article 31)

From an operating perspective, cooperation usually means:

• A controlled intake channel for regulatory communications.
• A consistent method to identify which processing activity, system, dataset, and legal entity is in scope.
• A coordinated response that is fact-checked, privilege-aware, and approved.
• Traceable production: what was requested, what you provided, and what you did next.

Who it applies to (entity and operational context)

Applies to:

• Controllers subject to GDPR for the relevant processing.
• Processors subject to GDPR for the relevant processing.
• EU/Member State representatives, where required, when acting on behalf of controllers/processors. (Regulation (EU) 2016/679, Article 31)

Operational contexts where Article 31 shows up:

• A complaint investigation tied to a data subject issue.
• Follow-up questions after a personal data breach notification (your own or a third party’s).
• A thematic inquiry (for example, around a type of processing, marketing practice, or cross-border transfer) where the authority asks multiple organizations for information.
• Processor-side outreach: the authority asks your processor for logs or incident details, and your processor needs a cooperative process to respond and keep you aligned.

Control objective (what “good” looks like)

You can demonstrate, with evidence, that:

1. Supervisory authority requests are identified and escalated immediately.
2. Roles are clear (controller vs. processor per processing activity) so the response matches your obligations.
3. Responses are accurate, complete, consistent, and approved.
4. You retain an auditable record of the end-to-end exchange. (Regulation (EU) 2016/679, Article 31)

What you actually need to do (step-by-step)

Step 1: Define scope and roles (controller vs. processor) for fast decisions

Create and maintain a GDPR role-and-scope register that maps:

• Legal entities in your group.
• Processing activities (aligned to your ROPA if you maintain one).
• Role per activity (controller/processor/joint controller where relevant).
• Data categories and systems involved.
• Key third parties involved in the activity (processors/sub-processors).

Why this matters for Article 31: it prevents “role confusion” during regulator engagement, which is where teams lose time and create inconsistent statements.

Step 2: Stand up a “supervisory authority request” operating procedure

Write a short SOP that answers, with names and backups:

• Intake owner: who monitors official inboxes/portals and receives mail.
• Case owner: who runs the request end-to-end (often Privacy Office/DPO, Compliance, or Legal).
• Decision rights: who approves external statements and evidence production (usually Legal + DPO/Privacy + relevant exec).
• Triage path: how you classify request type (inquiry, investigation, follow-up, on-site/remote audit, information demand).
• Response mechanics: how you draft, review, and submit; how you translate if needed; how you handle meetings/interviews.
• Third-party coordination: how you require processors to support information gathering promptly (contract + runbook).
• Recordkeeping: where the regulator case file lives and who can access it. (Regulation (EU) 2016/679, Article 31)

Step 3: Build a regulator-request intake and tracking workflow

In your GRC tool, ticketing system, or a dedicated regulator mailbox plus case tracker:

• Log every request with date/time received, requesting authority, and scope.
• Assign an owner and due date (use the authority’s deadline when provided; if not provided, set an internal target and document your rationale).
• Track tasks for each function: Security, Engineering, Product, Marketing, HR, Customer Support, Vendor Management.
• Track versions of drafts and final submissions.
• Track what evidence was provided.

If you use Daydream, set up a “Regulator Request” playbook that auto-creates an evidence checklist aligned to your GDPR artifacts, then attaches outputs to a single case record for audit-ready retrieval.

Step 4: Pre-stage “evidence packets” so cooperation is not a scramble

Maintain a small set of always-current evidence that commonly supports supervisory authority cooperation:

• Data protection governance: policies, training records, role assignments.
• Processing documentation: ROPA excerpts, system diagrams, data flow maps, retention schedule.
• Risk decisions: DPIAs where applicable, legitimate interest assessments where applicable, transfer assessments where applicable.
• Security and incident materials: incident response plan, breach logs, technical summaries, access control narratives.
• Third-party oversight: DPAs, sub-processor lists, due diligence summaries, incident obligations and escalation paths.

The goal is not to dump documents; it is to be able to answer precisely and consistently, with supporting records.

Step 5: Define response quality controls (accuracy, consistency, privilege)

Before sending anything:

• Validate factual claims against system logs or authoritative sources.
• Reconcile differences across teams (Security vs. Product narratives often conflict without a single fact base).
• Run Legal review for privilege and scope; don’t withhold improperly, but also don’t waive privilege accidentally.
• Maintain a clear “what we know / what we’re still validating” separation in drafts. (Regulation (EU) 2016/679, Article 31)

Step 6: Operationalize third-party cooperation (processor support)

If you are a controller, your ability to cooperate often depends on processors. Put in place:

• A contractual requirement to support supervisory authority inquiries relevant to the processing.
• A joint runbook: who at the processor responds, how fast, and how evidence is transferred securely.
• A single coordination rule: the processor does not freelancing-respond about your environment without notifying you, unless legally required.

If you are a processor, mirror the above internally: you need your own regulator request process, plus a mechanism to coordinate with controller customers without creating inconsistencies.

Required evidence and artifacts to retain

Maintain a Regulator Cooperation Case File per request:

• Original request (email/letter/portal message) and proof of receipt.
• Triage record: scope, roles (controller/processor), systems, and stakeholders.
• Task log showing collection steps and owners.
• Drafts and approvals (who approved, when).
• Final response package submitted and proof of submission.
• Evidence index: list of documents/data produced.
• Communications log (calls/meetings) with attendees and notes.
• Remediation actions and closure memo (what changed as a result). (Regulation (EU) 2016/679, Article 31)

Common exam/audit questions and hangups

Expect requests like:

• “Show your procedure for handling supervisory authority inquiries and who owns it.”
• “Provide a sample case file from a prior supervisory authority request (redacted if needed).”
• “How do you ensure processors support your responses?”
• “How do you prevent inconsistent statements across departments?”
• “Where is the authoritative record of your controller vs. processor role per processing activity?” (Regulation (EU) 2016/679, Article 31)

Hangups that slow teams down:

• No single intake channel; requests sit in an unmonitored inbox.
• Unclear legal entity boundary (which subsidiary is responsible).
• Evidence scattered across drives and point tools with no index.
• Processor dependency without a tested escalation path.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: “We cooperate” exists only in policy.
   Fix: Implement a request workflow, case owner, and evidence packet library. Keep a sample completed case file template ready.

2. Mistake: Treating every request like litigation discovery.
   Fix: Use Legal review, but keep the posture cooperative and responsive. Track scope precisely and ask clarifying questions early if needed. (Regulation (EU) 2016/679, Article 31)

3. Mistake: Inconsistent narratives across Security, Privacy, and Product.
   Fix: Establish a single fact base (logs, architecture docs, ROPA/DPIA excerpts) and require cross-functional sign-off before submission.

4. Mistake: Processor coordination is ad hoc.
   Fix: Contractual commitments plus a runbook, tested with tabletop exercises.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page avoids naming specific cases. Practically, Article 31 failures tend to amplify the risk of any underlying GDPR issue: weak cooperation can extend investigations, reduce credibility, and increase the chance of deeper information requests. Keep your posture disciplined: prompt engagement, accurate facts, and a complete record. (Regulation (EU) 2016/679, Article 31)

Practical execution plan (30/60/90-day)

You asked for speed; use this phased plan as an implementation scaffold.

First 30 days (foundation)

• Assign an executive owner and a day-to-day case owner for supervisory authority requests.
• Create the intake channel(s): dedicated email alias, mail handling instructions, portal access list.
• Publish the SOP v1 with approvals and a simple RACI.
• Start the role-and-scope register with your highest-risk processing activities. (Regulation (EU) 2016/679, Article 31)

Days 31–60 (make it operational)

• Build the case tracker (GRC workflow or ticketing) with required fields and an evidence index.
• Define the regulator-ready evidence packet list and collect the current versions.
• Add processor cooperation steps: named contacts at top processors and an escalation path.
• Run a tabletop exercise: simulate a supervisory authority request and measure where evidence retrieval breaks.

Days 61–90 (harden and prove)

• Produce a “golden” sample case file using the tabletop output (clearly labeled as exercise).
• Add quality controls: fact validation checklist, Legal review gate, version control.
• Operationalize retention: ensure the case file location is access-controlled but discoverable to the response team.
• If you use Daydream, centralize the role-and-scope register and evidence packets so the next request starts from a known, auditable baseline.

Frequently Asked Questions

Do we have to respond to every email that claims to be from a supervisory authority?

You must cooperate “on request,” but verify authenticity through known official channels before sharing sensitive information. Document the verification step in the case file. (Regulation (EU) 2016/679, Article 31)

Does Article 31 apply to processors, or only controllers?

It applies to both controllers and processors, and where applicable their representatives. Processors should maintain their own regulator-request SOP and coordinate with controller customers. (Regulation (EU) 2016/679, Article 31)

What does “cooperate” mean operationally?

It means you respond constructively to supervisory authority requests that support the authority’s tasks, with accurate information and appropriate supporting evidence. Your workflow should show ownership, approvals, and a complete communications log. (Regulation (EU) 2016/679, Article 31)

Can we ask the supervisory authority to narrow or clarify the request?

Yes. A clarifying question is often part of cooperation when scope is ambiguous. Record what you asked, what they clarified, and how it changed your production plan. (Regulation (EU) 2016/679, Article 31)

What evidence should we keep to prove cooperation?

Keep the request, your triage notes, task logs, drafts and approvals, final submission, proof of submission, and an index of produced materials. This should all live in a single case file. (Regulation (EU) 2016/679, Article 31)

How do we handle requests that involve a third party processor’s data or systems?

Trigger your processor cooperation runbook: notify the processor, assign joint owners, and require evidence delivery through a secure channel. Keep the controller’s response consistent with what the processor provides and document any gaps. (Regulation (EU) 2016/679, Article 31)