Article 60: Cooperation between the lead supervisory authority and the other supervisory authorities concerned

Article 60 sits in the GDPR’s cross-border enforcement mechanics. If your organization operates in more than one EU/EEA member state, or your processing “substantially affects” people in multiple member states, your regulator interactions may not be limited to a single supervisory authority. In that model, the Lead Supervisory Authority coordinates, and other supervisory authorities are “concerned” and participate.

For a Compliance Officer, CCO, or GRC lead, the practical requirement is not to manage the regulators’ process. It is to make your organization cooperation-ready: you can exchange relevant information through the LSA process without internal confusion, missed deadlines, contradictory positions, or ad hoc disclosures. Article 60’s language is short, but execution is not. You need defined internal roles (Legal, DPO, Security, Product, HR, Customer Support), a controlled method to collect facts, and a defensible record of what you shared and why. (Regulation (EU) 2016/679, Article 60)

If you use a system like Daydream to manage compliance workflows and evidence, Article 60 becomes easier to demonstrate because each regulator matter can be run as a case with assigned owners, approvals, and a complete audit trail.

Regulatory text

Excerpt (operative requirement): “The lead supervisory authority shall cooperate with the other supervisory authorities concerned… in an endeavour to reach consensus… [and] shall exchange all relevant information with each other.” (Regulation (EU) 2016/679, Article 60)

What the operator must do with this text

You are not the party that “cooperates” in Article 60; supervisory authorities cooperate with each other. Your operational obligation is indirect but real: you must be able to support that cooperation by providing complete, accurate, and consistent information to your LSA (and, in practice, responding appropriately when communications involve multiple authorities). If you cannot quickly assemble facts, decisions, and evidence, you increase the risk of delayed responses, incomplete disclosures, or shifting narratives across countries. Article 60 explicitly expects “all relevant information” to be exchanged between authorities, so you should assume the information you provide can be shared across concerned regulators. (Regulation (EU) 2016/679, Article 60)

Plain-English interpretation (what this requirement means)

If a GDPR matter is cross-border, you need to behave like a single, well-coordinated organization in regulator communications:

• One story, backed by evidence. Your positions, timelines, and technical facts need to match across all correspondence.
• Fast internal fact-finding. You need a way to identify what is “relevant information” and gather it without delay.
• Controlled disclosures. Everything you send must be approved, traceable, and consistent with your legal strategy and your security/engineering facts.

This is mostly an operating model problem, not a policy problem.

Who it applies to (entity and operational context)

Article 60 becomes operationally relevant when you have cross-border GDPR exposure, especially if:

• You have establishments in multiple EU/EEA member states, or
• A processing activity affects individuals in multiple member states (common for online services, SaaS, adtech, HR platforms, and consumer apps with EU users).

It applies whether you act as a controller or processor, but your “relevant information” and internal owners differ:

• Controllers will own decisions about purposes, legal bases, transparency, and rights handling.
• Processors will often support the controller’s response with system logs, incident details, sub-processor facts, and contractual positions.

Even if you rarely hear from regulators, you still need the workflow ready. Cross-border complaints and investigations arrive without warning.

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

1) Establish scope and triggers (so you know when Article 60 matters)

Create and maintain a GDPR role-and-scope register that answers, per major processing activity:

• Are you controller, joint controller, or processor?
• Which EU/EEA countries are impacted (user base, employees, customers)?
• Which systems and data categories are in scope?
• Who is the internal accountable owner (business owner + Legal/DPO point)?

This directly supports determining whether the matter is likely cross-border and therefore likely to involve an LSA and concerned authorities. (Regulation (EU) 2016/679, Article 60)

Practical trigger events to define:

• Complaint received from an EU data subject that references a specific country regulator
• Inquiry from any supervisory authority that references coordination, cross-border processing, or an LSA
• Major incident or breach that affects data subjects in more than one member state
• Large-scale change to processing that alters geography (new EU markets, new EU establishment)

2) Implement a regulator-communications operating procedure (make it repeatable)

Write a short, requirement-specific SOP that includes:

• Named owners: DPO/Privacy, Legal, Security, Engineering, Customer Support, and a single accountable “regulatory response lead”
• Intake channel: dedicated email alias and ticketing/case tool
• Triage questions: what happened, where, when, which systems, which member states, which categories of data
• Approval gates: who signs off before anything is sent externally (typically Legal + DPO, with Security/Engineering attesting to technical accuracy)
• Single source of truth: one case file where facts and drafts live

This SOP is what auditors and regulators expect you to have beyond “we cooperate.” (Regulation (EU) 2016/679, Article 60)

3) Build the “relevant information” checklist (so teams don’t debate relevance mid-crisis)

Create a standard checklist you can tailor per matter:

• Processing description (purpose, systems, data categories, data flows)
• Establishment and geography facts (entities involved, where decisions are made)
• Timeline of events (complaint, discovery, containment, remediation steps)
• Policies/procedures applicable to the issue (rights handling, security controls, retention)
• Evidence extracts (logs, screenshots, configuration exports) with chain-of-custody notes
• Prior communications (what you already told customers, users, or other authorities)

Your checklist should force the team to decide what is relevant and document why.

4) Run each matter as a case with an evidence packet

For each cross-border regulator matter, create an “evidence packet” with:

• Case summary and scope determination
• Stakeholder list and roles
• Communications log (date/time, sender, recipient, subject, decision)
• Versions of responses and approvals
• Attachments provided (exact files, hashes if your practice supports it)
• Exceptions and remediation actions

Daydream can fit naturally here as the system of record: you capture tasks, approvals, and evidence in one place so you can show a clean audit trail later.

5) Control consistency across countries and functions

Operational controls to prevent inconsistent narratives:

• One external voice: only the regulatory response lead (or Legal) sends external responses.
• One timeline: maintain a single agreed chronology; don’t let Security and Support maintain competing timelines.
• One facts owner per domain: Security owns incident facts, Engineering owns system behavior, Privacy owns legal basis/rights analysis.

6) Train the front door (so inquiries aren’t missed)

Most failures start with a missed email or a local team responding informally. Train:

• Customer Support and Trust/Safety
• Local country managers
• Security incident responders
• HR (for employee data issues)

Training objective: route anything from a supervisory authority to the intake channel immediately, with no substantive response outside the workflow.

Required evidence and artifacts to retain

Keep artifacts that prove you can support regulator cooperation quickly and consistently:

• GDPR role-and-scope register (current version + change history)
• Regulator communications SOP (versioned) and RACI/ownership map
• Case files for each matter (intake, triage notes, approvals, final responses)
• Communications log (including attachments)
• “Relevant information” checklist completed per case
• Post-mortem or lessons learned, with corrective actions tracked to closure

Retention should match your legal/regulatory retention approach for compliance records; document the rationale in your records schedule. (Regulation (EU) 2016/679)

Common exam/audit questions and hangups

Expect questions like:

• “How do you determine whether an issue is cross-border and who your LSA is for that processing?”
• “Show me your last regulator inquiry. Who approved the response? Where is the evidence you relied on?”
• “How do you ensure teams in different countries don’t respond inconsistently?”
• “Where do you store regulator communications, and can you produce a complete log?”
• “What is your process to identify and provide all relevant information requested?”

Hangups examiners look for:

• No single accountable owner for regulator responses
• Facts trapped in Slack/Teams with no audit trail
• Engineering/security facts not reviewed by Legal/DPO before submission
• Ad hoc local responses from affiliates or customer support

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails	How to avoid it
Treating Article 60 as “regulators’ problem”	You still need to supply consistent, complete information	Build a regulator-response SOP and case workflow mapped to cross-border triggers
No role clarity (controller vs processor) per activity	You can’t determine who answers what	Maintain a role-and-scope register tied to processing inventory
“Relevant information” decided in real time	Delays and internal disputes	Pre-build a checklist and evidence standards
Multiple teams emailing regulators	Inconsistent positions; privileged content risk	Single intake channel + single external sender + approval gates
Evidence not reproducible	You can’t defend what you said	Evidence packet with attachments, versions, and approvals

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not list specific cases.

Risk implications you should plan for anyway:

• Longer investigations if you cannot provide coherent information quickly.
• Expanded scope if different authorities receive inconsistent facts or timelines.
• Operational disruption because cross-functional teams scramble without a playbook.

Practical 30/60/90-day execution plan

First 30 days (stabilize the basics)

• Appoint a regulatory response lead and backups; document who can approve outbound regulator communications.
• Create the intake channel and case workflow in your GRC/ticketing system (Daydream or your existing tooling).
• Draft the regulator communications SOP (short, executable, names included).
• Start the GDPR role-and-scope register for top processing activities and top EU entities.

Days 31–60 (make it operational)

• Build the “relevant information” checklist and standard evidence packet template.
• Run a tabletop exercise: simulate a cross-border complaint and force the team to produce a regulator-ready response package.
• Train Customer Support, Security IR, and local business leads on routing rules and “no off-script responses.”

Days 61–90 (prove repeatability)

• Pilot the workflow on real low-risk inquiries (or internal audit requests) to validate approvals, logging, and evidence capture.
• Add metrics that don’t require external benchmarking: cycle time to first draft, number of late approvals, missing evidence types.
• Complete an internal audit of one case file: can you reconstruct exactly what happened and what you shared?

Frequently Asked Questions

Do we need to contact “concerned” supervisory authorities directly under Article 60?

Article 60 describes cooperation between supervisory authorities and information exchange between them. Your operational focus should be responding through your LSA process and maintaining a defensible, consistent record of what you provided. (Regulation (EU) 2016/679, Article 60)

What counts as “all relevant information” in practice?

Treat it as information needed to understand the processing, the event/complaint, and your decisions and controls. Use a checklist that covers scope, timeline, systems, data categories, and remediation, then document why each provided item was relevant. (Regulation (EU) 2016/679, Article 60)

We are a processor. How does Article 60 affect us?

You may not lead regulatory strategy, but you still need to supply accurate system facts, logs, and security details to the controller (and sometimes to authorities via the controller). Build your evidence packet process so you can respond quickly and consistently.

How do we prevent local affiliates from responding independently to their national authority?

Put a single intake channel in place, train local teams to route immediately, and require Legal/DPO approval for any regulator response. Then audit for “side-channel” communications by reviewing shared mailboxes and ticket tags.

Can we keep regulator correspondence in email only?

Email alone rarely gives you a clean audit trail for approvals, versions, and attachments. Store correspondence in a controlled case file with an evidence packet so you can reproduce exactly what was sent and who approved it.

How can Daydream help with Article 60 execution without turning this into a heavy program?

Run each inquiry as a case with tasks, approvers, and evidence uploads, and keep the role-and-scope register and SOP in the same system. That gives you fast retrieval and a consistent audit trail when the LSA requests additional information.