Article 48: Transfers or disclosures not authorised by Union law

GDPR Article 48 requires you to not treat a third-country court order or regulator demand as automatically valid grounds to disclose EU personal data. You may disclose only if the demand is grounded in an international agreement (for example, MLAT) between that country and the EU or a Member State, or if another GDPR Chapter V transfer mechanism independently applies. (Regulation (EU) 2016/679, Article 48)

Key takeaways:

• Route all third-country legal demands for EU personal data through a documented, legal-reviewed intake and decision workflow.
• Do not disclose solely because a non-EU authority “ordered” it; confirm an international agreement basis or a separate Chapter V transfer ground. (Regulation (EU) 2016/679, Article 48)
• Keep an evidence packet for every demand (request, analysis, approvals, disclosure scope, and logs) to stay defensible in audits and regulator inquiries.

Article 48 sits at the intersection of privacy, litigation, and law enforcement requests. Operationally, it becomes relevant the moment a third-country court, tribunal, or administrative authority asks your company (or one of your processors) to hand over personal data that is subject to the GDPR. The trap is treating that foreign demand as a “legal obligation” that automatically justifies disclosure.

Article 48’s message is narrow but strict: foreign judgments and administrative decisions that require transfer or disclosure of personal data are only “recognised or enforceable” for GDPR purposes when they rest on an international agreement in force between the requesting country and the EU or a Member State (for example, a mutual legal assistance treaty), without prejudice to other Chapter V transfer grounds. (Regulation (EU) 2016/679, Article 48)

For a CCO or GRC lead, the fastest way to operationalize this is to implement a single intake path for all cross-border legal demands, require legal sign-off against a decision checklist, and harden third-party contracts so processors escalate requests immediately rather than responding directly.

Regulatory text

Text (verbatim): “Any judgment of a court or tribunal and any decision of an administrative authority of a third country requiring a controller or processor to transfer or disclose personal data may only be recognised or enforceable in any manner if based on an international agreement, such as a mutual legal assistance treaty, in force between the requesting third country and the Union or a Member State, without prejudice to other grounds for transfer pursuant to this Chapter.” (Regulation (EU) 2016/679, Article 48)

Operator interpretation (what you must do):

• Do not disclose EU personal data solely because a third-country authority demands it. A foreign order is not automatically a valid “legal basis” under the GDPR just because it exists. (Regulation (EU) 2016/679, Article 48)
• Confirm whether the demand is routed through a valid international agreement (for example, an MLAT) between the requesting country and the EU or a Member State. If not, you cannot treat it as automatically enforceable for GDPR disclosure. (Regulation (EU) 2016/679, Article 48)
• If you still plan to transfer, you must rely on another Chapter V transfer ground (for example, an applicable transfer mechanism) independent of the foreign demand. Article 48 explicitly preserves (“without prejudice”) those other grounds, but does not create one by itself. (Regulation (EU) 2016/679, Article 48)

Plain-English requirement

If a non-EU government agency or court asks for GDPR-covered personal data, you must pause and validate the legal pathway. Your teams cannot treat the request as “mandatory” unless it comes through the right international channel (or you have another lawful GDPR transfer basis that stands on its own). You also need to control how much you disclose, document why, and make sure your processors don’t respond behind your back.

Who it applies to (entity and operational context)

Applies to:

• Controllers subject to GDPR that receive third-country demands for personal data. (Regulation (EU) 2016/679, Article 48)
• Processors subject to GDPR that receive such demands while processing on behalf of a controller. (Regulation (EU) 2016/679, Article 48)

Common operational trigger points:

• Law enforcement requests delivered to Trust & Safety, Security, Legal, Support, or Abuse teams.
• Litigation discovery or subpoenas served on a US or other non-EU affiliate for data about EU individuals.
• Direct outreach to a cloud provider, SaaS provider, or other third party processor demanding customer data.
• “Emergency disclosure” requests (often routed informally) that bypass standard legal channels.

Third-party risk angle: even if your own staff is trained, your exposure often comes from a processor that receives a demand and responds quickly. Article 48 explicitly covers processors, so you need contractual and procedural controls that force escalation and prohibit unilateral disclosure. (Regulation (EU) 2016/679, Article 48)

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

1) Establish scope and roles (controller vs. processor)

Create and maintain a role-and-scope register for Article 48 operations:

• Where you are a controller (your products, your customers, your HR data).
• Where you are a processor (data handled for customers) and who the controller is.
• Data categories and systems likely implicated (identity data, content, logs, support tickets).

Why it matters: the intake route and communications differ when you are a processor (you may need to notify the controller and follow contract instructions before any disclosure).

2) Implement a single intake channel for third-country demands

Make it impossible for ad hoc teams to respond:

• Central mailbox / portal owned by Legal/Privacy with Security support.
• A case ticket template with mandatory fields: requesting authority, jurisdiction, legal instrument type, deadline, data subjects affected, systems involved, and whether the request cites an international agreement.

Operational control: instruct customer support and SOC to redirect all such requests to the central channel and not acknowledge substance.

3) Run an Article 48 decision checklist (legal-reviewed)

Your decision checklist should answer, in order:

1. Is this a third-country judgment/court order/administrative decision requiring disclosure? (Regulation (EU) 2016/679, Article 48)
2. Is it based on an international agreement in force between the requesting country and the EU or a Member State (e.g., MLAT)? If yes, document the basis and proceed to minimization and security steps. (Regulation (EU) 2016/679, Article 48)
3. If no international agreement basis, is there another lawful Chapter V transfer ground that applies independent of the order? Article 48 allows other grounds to be considered, but does not waive the need for them. (Regulation (EU) 2016/679, Article 48)
4. Are you a processor? If yes, notify the controller per contract and require written instruction unless prohibited by law.
5. Can you narrow the scope? Apply data minimization: least data, least time range, least identifiers, and redact where possible.
6. Can you challenge or seek clarification? Decide whether to resist, seek protective orders, or require the authority to use formal channels.

This is where Daydream fits naturally: create a dedicated “Article 48 legal demand” workflow with required fields, approvers, and evidence attachments so each request results in a repeatable, auditable decision record.

4) Build the “disclosure execution” runbook (only after approval)

If disclosure is permitted, define the mechanics:

• Data extraction method and access controls (who can pull, who can approve).
• Integrity controls (hashing exports, chain-of-custody notes).
• Secure transfer method to the authority (avoid email attachments).
• Logging (what was disclosed, to whom, when, by whom).

5) Contractually bind processors and other third parties

Update DPAs and key supplier terms so processors:

• Notify you promptly of any third-country legal demand relating to your data.
• Do not disclose without your documented instruction unless legally prohibited.
• Provide a copy of the request (or meaningful details if restricted).
• Support challenges to overbroad requests where permitted.

This is a third-party due diligence item: confirm the supplier has a legal demand process, escalation contacts, and transparency reporting practices.

6) Train the front line and test the control

Train teams most likely to receive requests (Support, Security Operations, IT, HR Ops). Run a tabletop exercise using a realistic scenario: a third-country administrative authority emails Support demanding account data for an EU user. The test passes only if the request is routed, evaluated, and documented through the Article 48 workflow.

Required evidence and artifacts to retain

Maintain an “Article 48 evidence packet” per request:

• Original request and any attachments.
• Intake ticket with timestamps and request metadata.
• Role determination (controller/processor) and impacted systems.
• Legal analysis and the basis for recognition/enforceability (international agreement reference) or other Chapter V transfer ground considered. (Regulation (EU) 2016/679, Article 48)
• Controller instruction (if you are a processor) and communications log.
• Data minimization rationale and final disclosure scope.
• Export/audit logs: who accessed, who extracted, who approved, and delivery confirmation.
• Any challenge/objection correspondence and outcomes.

Auditors look for two things: consistency (every request follows the same path) and completeness (the file shows why disclosure was allowed or refused).

Common exam/audit questions and hangups

• “Show me your procedure for responding to non-EU government demands for EU personal data.” (Regulation (EU) 2016/679, Article 48)
• “How do you confirm whether a request is based on an international agreement such as an MLAT?” (Regulation (EU) 2016/679, Article 48)
• “How do processors in your supply chain escalate requests, and how do you verify they didn’t disclose directly?”
• “Provide examples of requests you rejected and the documented rationale.”
• “Where are decision records stored, and who can approve disclosures?”

Hangup to expect: teams confuse Article 48 with general “lawful basis” concepts and assume “legal obligation” applies globally. Your control should force the specific Article 48 question: enforceable based on an international agreement, or another Chapter V ground. (Regulation (EU) 2016/679, Article 48)

Frequent implementation mistakes (and how to avoid them)

1. Treating a foreign subpoena as automatically binding.
   Fix: require documented analysis of the international agreement basis or separate Chapter V transfer ground before any disclosure. (Regulation (EU) 2016/679, Article 48)

2. Letting local offices or support agents respond.
   Fix: one intake channel, auto-replies that route to Legal, and training backed by an internal policy with clear “do not respond” language.

3. Processor “silent compliance.”
   Fix: DPA clauses, escalation SLAs, and periodic testing with critical processors (ask them to walk you through their last legal demand).

4. Over-disclosure (too broad exports).
   Fix: minimization checklist and two-person approval for production data exports.

5. No defensible file.
   Fix: evidence packet requirement; if the file is incomplete, treat it as an incident and remediate.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should assume examiners will evaluate control design and operating evidence, not whether your interpretation matches a specific prior fine.

Risk is still concrete:

• Unlawful disclosure can trigger GDPR regulator scrutiny and contractual fallout with enterprise customers.
• The third-party angle increases exposure: processors are explicitly covered, so your program must extend past your boundary. (Regulation (EU) 2016/679, Article 48)

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

You asked for speed; use a phased plan with clear deliverables rather than calendar promises.

First 30 days (Immediate)

• Assign owners: Privacy/Legal process owner, Security execution owner, GRC evidence owner.
• Publish the intake route and “do not respond” guidance to front-line teams.
• Stand up the ticket template and evidence packet structure in your GRC system (Daydream or equivalent).
• Identify top processors likely to receive demands (cloud, comms, CRM, hosting) and confirm escalation contacts.

Days 31–60 (Near-term)

• Update DPAs / third-party contract addenda for escalation and no-unilateral-disclosure language.
• Build the decision checklist into the workflow with required legal approval.
• Implement data export approval controls (two-person review, logging, secure delivery method).
• Run one tabletop and record lessons learned as corrective actions.

Days 61–90 (Operationalize and monitor)

• Conduct a mini-audit: sample recent requests (or run simulated requests) and verify complete evidence packets.
• Add a recurring control test in your compliance monitoring plan (request intake, legal review, minimization, logging).
• Expand training to HR and IT (they receive separate categories of demands).
• Report metrics qualitatively to leadership: volume of requests, % routed correctly, recurring gaps (avoid numeric targets unless you have internal data).

Frequently Asked Questions

If a third-country authority says the order is “legally binding,” can we disclose under GDPR?

Not solely on that basis. Article 48 says recognition/enforceability for GDPR disclosure hinges on an international agreement (such as an MLAT) between the requesting country and the EU or a Member State, without prejudice to other Chapter V transfer grounds. (Regulation (EU) 2016/679, Article 48)

We’re a processor. Can we respond directly to the authority to meet the deadline?

Article 48 applies to processors too, so you need a contract-backed rule that you escalate to the controller and do not disclose without documented instruction unless law prohibits notice. Build this into your legal demand SOP and DPA clauses. (Regulation (EU) 2016/679, Article 48)

Does Article 48 ban all disclosures to non-EU authorities?

No. It limits treating third-country judgments/administrative decisions as automatically enforceable grounds for disclosure; it also preserves the possibility of relying on other Chapter V transfer grounds where applicable. (Regulation (EU) 2016/679, Article 48)

What evidence will an auditor expect for Article 48?

A complete case file: the request, role determination, analysis of the international agreement basis or other Chapter V ground, approvals, minimization decisions, and logs of what was disclosed. The goal is a defensible record per request. (Regulation (EU) 2016/679, Article 48)

How do we handle a request sent to our cloud provider instead of to us?

Contractually require the provider to notify you and prohibit disclosure without your instruction unless legally barred. Operationally, test that escalation path during due diligence and periodic reviews.

Can we solve this with policy language alone?

No. Article 48 becomes real in intake and execution: routing, legal review, approvals, minimization, and logging. Regulators and customers will ask for operating evidence, not a policy PDF. (Regulation (EU) 2016/679, Article 48)