Article 31: Cooperation with the supervisory authority

Article 31 is short, but it becomes operationally expensive if you wait until a regulator contacts you. The requirement is simple: controllers and processors (and representatives, where applicable) must cooperate with a supervisory authority “on request” as the authority performs its tasks. ¹ In practice, “cooperate” means you can reliably (1) recognize a supervisory authority request, (2) route it to the right accountable owners, (3) gather accurate information from systems and third parties, (4) respond through controlled communications, and (5) preserve a clear record of what happened.

For a CCO, Compliance Officer, or GRC lead, the fastest path is to treat supervisory authority engagement like a regulated intake process, similar to incident response or litigation holds. Your procedure should be role-aware (controller vs. processor), because the content you can provide, and the approvals you need, will differ depending on whether you are answering for your own purposes or on behalf of a customer. The most common failure mode is “policy-only compliance”: a statement that you will cooperate, without a tested workflow, evidence, and clear internal ownership.

Regulatory text

GDPR Article 31 text: “The controller and the processor and, where applicable, their representatives, shall cooperate, on request, with the supervisory authority in the performance of its tasks.” ¹

Operator interpretation (what you must do):

• Be ready to respond when asked. Article 31 is triggered by a supervisory authority request. Your controls need to work under time pressure and scrutiny. ¹
• Cooperate across roles. The obligation applies to both controllers and processors. If you act as both across different processing activities, you need role-based response paths. ¹
• Cooperate in support of the authority’s tasks. Your responses must be complete enough to enable the authority’s work, not just minimal disclosures. ¹

Plain-English requirement

You must have an operational capability to engage with a data protection supervisory authority when it contacts you: receive the request, verify it, assign it, collect accurate facts and documents, respond through approved channels, and keep records that show you cooperated. ¹

Who it applies to (entity and operational context)

In scope entities

• Controllers processing personal data under GDPR. ¹
• Processors processing personal data on behalf of controllers. ¹
• Representatives (where applicable) acting for controllers/processors in certain cross-border/non-EU establishment scenarios. Article 31 names them explicitly, so your operating model should include them if you have one. ¹

In scope operational contexts (typical triggers)

• Investigation correspondence (complaints, inquiries, preliminary questions)
• Follow-up questions after breach notifications or data subject complaints
• Requests for specific records, explanations of processing, or evidence of measures taken

Article 31 does not specify the request format. Treat email, letter, portal messages, and calls as potential triggers until verified.

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

1) Set role-and-scope for cooperation (controller vs. processor)

Create and maintain a role-and-scope register for supervisory authority cooperation:

• Processing activity name
• Your role (controller, processor, joint controller if relevant to your org’s map)
• Systems and data stores involved
• Data categories and affected products/services
• Key internal owners (Privacy, Legal, Security, Product, Customer Success) This prevents delays caused by internal debate about “who owns the answer” when a request arrives.

Practical tip: tie each processing activity to the team that can produce evidence fast (logs, configurations, DPIAs, records of processing, contract terms, subprocessors list).

2) Stand up a supervisory authority request intake channel

Implement a single entry point that your organization can monitor and control:

• Dedicated email alias (e.g., privacy-regulatory@)
• Ticketing/case system queue (integrated with Legal/Privacy)
• Backup intake path (front desk, support) with a mandatory escalation script

Minimum routing rules:

• Any suspected supervisory authority inquiry is escalated to Privacy + Legal immediately.
• Security is included if the subject touches breaches, access logs, monitoring, or technical controls.
• If you are a processor, include the customer account owner so you can coordinate with the controller.

3) Verify the request and control communications

Your procedure should include a verification and comms control checklist:

• Confirm the requestor is a legitimate supervisory authority contact (domain checks, callback through published numbers, portal verification).
• Assign a single authorized responder (usually Legal/Privacy) to avoid inconsistent statements.
• Establish communications boundaries: what can be shared directly, what requires controller approval (processor context), and what requires redaction.

4) Triage and classify the request

Use a simple decision matrix:

Question	If “yes”	Action
Are we acting as a processor for this processing?	Processor	Notify/coordinate with controller per contract, align on response content before disclosure.
Does the request seek technical evidence (logs, configs, access history)?	Technical	Pull Security/IT, preserve records, document collection method.
Does the request involve multiple EU jurisdictions or cross-border processing?	Complex	Centralize case management, coordinate through DPO/lead privacy counsel, maintain one narrative.
Does it indicate potential noncompliance or complaint?	Elevated	Open an internal compliance incident, start remediation tracking alongside the response.

5) Collect facts from systems and third parties

Build a repeatable “evidence pull” playbook. Common sources:

• Records of processing activities (if maintained in your program)
• Data flow diagrams and system inventories
• Security logs (access, admin actions, exports)
• Contracts and DPA terms (processor obligations, subprocessor disclosures)
• Prior DPIAs, risk assessments, and change tickets
• Any internal decisions that explain why the processing occurs (business purpose, legal basis narratives where already documented)

If key evidence sits with third parties (subprocessors, cloud providers), your workflow should include:

• A standard request template
• An internal owner for third-party escalation
• Documentation of what was requested and received

6) Respond, with approvals and a defensible record

Before sending:

• Legal/Privacy reviews the response for scope, consistency, and confidentiality.
• Security approves technical claims and confirms integrity of evidence.
• If you are a processor, document controller coordination and approvals.

During and after sending:

• Keep a copy of the final response and all attachments.
• Log dates, participants, and decision points.
• Track follow-ups as part of the same case, not scattered email threads.

7) Close the loop: remediation and program improvements

Article 31 cooperation often reveals gaps (missing logs, unclear ownership, incomplete inventories). Close requests with:

• Remediation items, owners, and due dates
• Updated role-and-scope register entries
• A short “lessons learned” note added to your evidence packet

Where Daydream fits naturally: Daydream is useful when you need a requirement-level procedure, clear ownership mapping, and repeatable evidence packets across controllers/processors without reinventing the workflow each time.

Required evidence and artifacts to retain

Maintain a case file (evidence packet) per supervisory authority request:

• Original request (message, letter, screenshot, portal export)
• Verification steps (how you validated the authority contact)
• Role determination (controller/processor) and scope notes
• Internal routing log (who was notified, when)
• Evidence collected (exports, screenshots, logs) plus collection method and custodian
• Drafts and approvals (Legal/Privacy/Security sign-off)
• Final response and proof of submission/delivery
• Controller coordination record (if processor)
• Remediation tracker entries and closure notes

Retention period is not stated in Article 31; set one consistent with your broader compliance and legal hold practices.

Common exam/audit questions and hangups

Expect examiners, customers, and internal audit to ask:

• “Show your documented procedure for handling supervisory authority requests.” ¹
• “Who is authorized to respond, and how do you prevent inconsistent communications?”
• “How do you determine whether you are controller or processor for the relevant processing?”
• “Provide an example evidence packet from a past request (redacted if necessary).”
• “How do you coordinate with controllers when you are the processor?”
• “How do you ensure completeness of responses across systems and subprocessors?”

Hangups that slow responses:

• No system inventory or data map tied to owners
• Logs exist but are hard to retrieve quickly, or teams disagree on what logs prove
• Procurement/third-party management cannot quickly contact subprocessors
• Email-only handling with no case management or approval trail

Frequent implementation mistakes (and how to avoid them)

1. No role clarity. Teams answer as if they are the controller when they are a processor (or vice versa).
   Fix: maintain a role-and-scope register and require role confirmation at triage.

2. Uncontrolled communications. Multiple stakeholders email the authority separately.
   Fix: designate a single responder; everyone else routes through the case owner.

3. Evidence that cannot be explained. Logs are exported without documenting context, time source, or custodian.
   Fix: standardize an evidence collection cover sheet (who, what, when, how pulled).

4. Controller coordination happens late. Processors begin assembling responses but forget contractual notice/approval steps.
   Fix: embed “controller notification and approval” as a required step in the processor workflow.

5. Policy-only compliance. A policy says “we cooperate,” but nobody can show a test run.
   Fix: run a tabletop using a mock authority request and generate a sample evidence packet.

Enforcement context and risk implications

No public enforcement case sources were provided in your source catalog for this page, so this guidance stays anchored to the text of Article 31 and operational exam expectations. ¹ Practically, failure to cooperate increases regulatory friction: more follow-up requests, less credibility in dispute resolution, and higher risk that a matter escalates into a broader investigation.

Practical 30/60/90-day execution plan

First 30 days (stand up the basics)

• Assign accountable owners: Privacy (process owner), Legal (response authority), Security (technical evidence owner).
• Create the supervisory authority request SOP: intake, verification, triage, response, approvals, recordkeeping. ¹
• Establish intake channels and routing rules; test them with a simulated message.
• Start the role-and-scope register for top processing activities tied to EU personal data.

Days 31–60 (make it repeatable)

• Build evidence pull checklists per system (CRM, HRIS, product analytics, support tooling).
• Add third-party escalation templates and a subprocessor contact path.
• Create standard response artifacts: internal fact-gathering questionnaire, approval checklist, evidence cover sheet.
• Run a tabletop exercise and produce a “gold standard” evidence packet.

Days 61–90 (harden and integrate)

• Integrate the workflow into your GRC or case tooling so every request becomes a tracked case with approvals.
• Train front-line teams (Support, Sales, HR) on identification and escalation.
• Add metrics that matter operationally (e.g., open cases, overdue internal tasks) without inventing external benchmarks.
• Review your register and procedure after any real request; update based on what slowed you down.

Frequently Asked Questions

Does Article 31 apply to processors, or only controllers?

It applies to both controllers and processors, and where applicable their representatives. Your procedure should explicitly cover how you respond as a processor, including coordination with the controller. ¹

What counts as a “request” from a supervisory authority?

Article 31 does not constrain the format, so treat any inbound communication that appears to come from a supervisory authority as a trigger until verified. Build verification steps into your workflow. ¹

Do we need a dedicated “regulator response” policy, or is a generic privacy policy enough?

A generic policy rarely provides the routing, approvals, and evidence standards you need under time pressure. Document a specific operating procedure and tie it to an intake and case workflow. ¹

As a processor, can we respond directly to the supervisory authority without notifying the controller?

Article 31 requires cooperation, but your response path should still honor your contractual and role-based obligations to the controller. Build controller notification and alignment into triage for processor-scoped processing.

What evidence should we keep to prove we cooperated?

Keep a case file with the original request, verification steps, internal routing, collected evidence, approvals, and the final response. Treat it like an audit-ready packet that can be re-reviewed later.

How do we operationalize this if we operate in multiple EU countries?

Centralize case ownership and maintain one controlled narrative and evidence packet, then coordinate inputs across regions. Your role-and-scope register should identify which processing activities and teams are involved by geography.

Footnotes

1. Regulation (EU) 2016/679, Article 31