Article 48: Transfers or disclosures not authorised by Union law

To comply with the article 48: transfers or disclosures not authorised by union law requirement, you must treat third-country court orders and administrative demands for EU personal data as not automatically enforceable and only disclose if there is a valid international agreement (for example, an MLAT) or another lawful transfer basis under GDPR Chapter V. Build an intake-and-decision procedure that blocks ad hoc disclosures and produces an auditable decision record. (Regulation (EU) 2016/679, Article 48)

Key takeaways:

• Route every third-country data demand through a formal legal intake; no business-led “quick compliance.”
• Disclose only if an applicable international agreement exists, or you can document another GDPR Chapter V transfer mechanism.
• Keep an evidence packet for each demand: request, analysis, approvals, response, and minimization steps.

Article 48 sits at the intersection of privacy compliance, cross-border discovery, and government access requests. Operationally, it answers one question: “What do we do when a non-EU authority tells us to hand over personal data?” The requirement is narrow but high-risk because the trigger event is often urgent, confidential, and handled by teams (Security, Trust & Safety, Finance, HR, Sales Ops) that are not used to GDPR Chapter V analysis.

For a Compliance Officer, CCO, or GRC lead, the fastest path to a defensible posture is to establish a single intake path for any third-country judgment, subpoena, warrant, or administrative demand that seeks personal data. Then you standardize the decision: is the request enforceable based on an international agreement in force between the requesting country and the EU or a Member State, and if not, do you have another lawful transfer basis under Chapter V that fits the situation? (Regulation (EU) 2016/679, Article 48)

This page translates that legal rule into an operator-ready workflow, required artifacts, and audit-proof evidence practices so your teams can respond quickly without creating unlawful transfers or uncontrolled disclosures.

Regulatory text

GDPR Article 48 states that a third-country court judgment or administrative decision requiring a controller or processor to transfer or disclose personal data may be recognized or enforceable only if it is based on an international agreement (such as a mutual legal assistance treaty) in force between the requesting third country and the EU or a Member State, without prejudice to other Chapter V transfer grounds. (Regulation (EU) 2016/679, Article 48)

What the operator must do

• Do not treat third-country legal demands as self-executing. Your default must be “hold and review,” not “comply and disclose.” (Regulation (EU) 2016/679, Article 48)
• Check the legal channel. If the request is not routed through an applicable international agreement, it is not automatically enforceable for GDPR purposes. (Regulation (EU) 2016/679, Article 48)
• If you disclose anyway, you need a defensible Chapter V basis. Article 48 explicitly preserves other lawful transfer grounds, but you must document which one applies and why. (Regulation (EU) 2016/679, Article 48)

Plain-English interpretation

Article 48 is a “foreign order firewall.” If a non-EU authority tells you to hand over personal data that is subject to GDPR, you cannot treat that demand as legally binding for GDPR transfer purposes unless it comes through a recognized international agreement channel (for example, MLAT). If it doesn’t, you pause, escalate, and decide whether you can respond through another lawful transfer mechanism under GDPR’s international transfer rules. (Regulation (EU) 2016/679, Article 48)

This requirement matters most in practice for:

• Cross-border litigation holds and eDiscovery.
• Law enforcement and national security requests received directly by your company.
• Regulator-to-company demands issued outside the EU.
• Parent-subsidiary demands (for example, a non-EU parent compels an EU subsidiary to produce HR data).

Who it applies to

Entity scope

• Any organization acting as a controller or processor handling personal data subject to GDPR that receives a third-country judgment or administrative demand for disclosure or transfer. (Regulation (EU) 2016/679, Article 48)

Operational scope (where you’ll see it)

• Legal: subpoenas, discovery, civil procedure demands.
• Security/Trust: law enforcement portals, emergency disclosure requests.
• HR/People Ops: foreign employment disputes requesting EU employee files.
• Finance: tax authority requests that include customer or employee identifiers.
• IT/Cloud Ops: third parties (cloud providers, SaaS tools) that receive demands and ask you for instructions.

Third-party risk context If you are a controller using processors, Article 48 becomes a contract and oversight issue: your processors may receive third-country demands. Your operating model must ensure they notify you promptly and do not disclose without your instruction, except where strictly required and permitted.

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

1) Establish a single intake channel and “stop the line” trigger

• Create a centralized mailbox/ticket type (for example, “Third-country data demand”) owned by Legal + Privacy with GRC visibility.
• Train frontline teams to forward any non-EU demand immediately.
• Add a rule: no production without written approval from the designated owner (usually Legal with Privacy sign-off).

Practical trigger definition Treat these as in-scope until proven otherwise: subpoenas, warrants, court orders, regulator letters, administrative orders, informal requests “with legal threat,” and demands served on third parties asking for your data.

2) Triage: confirm role, data, and jurisdiction

Record, at minimum:

• Are you acting as controller, processor, or sub-processor for the requested data?
• What data categories and which systems are implicated?
• Is the data about EU/EEA individuals, or processed in an EU establishment context (treat as potentially GDPR-scoped until confirmed)?
• Who is the requesting authority and what country is involved?

This is where a role-and-scope register prevents delays and inconsistent decisions.

3) Enforceability screen (Article 48 test)

Perform and document the core Article 48 check:

• Is the request based on an international agreement (for example, MLAT) in force between the requesting third country and the EU or a Member State? (Regulation (EU) 2016/679, Article 48)
• If the request came directly to your company (not via an EU/Member State channel), treat that as a red flag requiring escalation and documented analysis.

Output: a short written conclusion (even if privileged) stating whether Article 48 recognition/enforceability is met. (Regulation (EU) 2016/679, Article 48)

4) If not enforceable under Article 48, assess other Chapter V transfer grounds

Article 48 preserves “other grounds for transfer pursuant to this Chapter.” (Regulation (EU) 2016/679, Article 48) Your procedure should require Legal/Privacy to decide whether an alternative transfer mechanism is available and appropriate for the specific disclosure.

Operationally, you need a decision memo that:

• Identifies the transfer mechanism relied on (if any).
• Explains why it fits the facts of the request.
• Defines scope limits (fields, date ranges, identities) to reduce exposure.

Do not allow “we had to comply” as the sole rationale.

5) Minimize, secure, and control the disclosure

If you disclose:

• Apply data minimization: only the fields strictly required.
• Use a secure transmission method, logged and access-controlled.
• Consider pseudonymization/redaction where feasible.
• Record any restrictions communicated to the requester (for example, confidentiality notices).

6) Manage processors and other third parties

Update third-party contract and oversight expectations:

• Processor must notify promptly of any third-country demand relating to your personal data.
• Processor must not disclose without your documented instruction unless prohibited by law, and must provide the prohibition notice where permitted.
• Processor must preserve a demand log and provide it on request.

In practice, most failures happen when a SaaS provider receives a demand and responds under its own policy, outside your GDPR transfer analysis.

7) Retain an evidence packet per request, plus a demand log

You want two layers of defensibility:

• Case-level packet (for each demand).
• Program-level log (all demands, even denied/withdrawn).

Daydream (or any GRC system you already run) becomes helpful here because it can standardize the intake questionnaire, approvals, and evidence attachments so responses don’t depend on who is on call.

Required evidence and artifacts to retain

Maintain the following artifacts in a controlled repository (case management system or GRC tool):

A. Program artifacts

• Article 48 operating procedure with owners, triggers, escalation paths, and approval matrix.
• Role-and-scope register: controller/processor role by product/system and data categories.
• Third-country demand training record for relevant teams.
• Standard response templates (acknowledgment, denial, request for MLAT channel, partial production with scope limits).

B. Per-request evidence packet

• Copy of the demand (including service details).
• Triage record: data categories, systems, roles, jurisdictions.
• Article 48 enforceability assessment and conclusion. (Regulation (EU) 2016/679, Article 48)
• Chapter V transfer mechanism assessment (if any) referenced by Article 48’s “without prejudice” clause. (Regulation (EU) 2016/679, Article 48)
• Approval record (names/titles, date/time, decision).
• Production record: what was disclosed, to whom, when, and how (secure channel evidence).
• Minimization/redaction notes.
• Post-action review notes and any remediation tasks.

Common exam/audit questions and hangups

Expect auditors, customers, and regulators to probe:

1. “Show me your procedure.” Who can approve disclosure to third-country authorities?
2. “How do you identify in-scope requests?” What is the training and routing mechanism?
3. “How do you apply Article 48?” Provide examples of enforceability decisions. (Regulation (EU) 2016/679, Article 48)
4. “What about processors?” How do you ensure third parties notify you and don’t disclose independently?
5. “Do you keep a log?” Can you evidence completeness, not just the “big” cases?

Hangups that slow teams down:

• Confusion between “lawful disclosure” and “lawful international transfer.”
• No single owner; Security responds to “emergency” requests without Privacy review.
• Lack of system mapping, so no one knows what data exists where.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails	Fix
Treating any subpoena as mandatory	Article 48 restricts recognition/enforceability absent an international agreement. (Regulation (EU) 2016/679, Article 48)	“Hold and review” policy + legal intake gate
No written decision record	You can’t prove the Article 48 analysis later	Require a decision memo before any production
Allowing processors to “handle it”	You lose control of disclosure and transfer rationale	Contract clauses + demand notification workflow
Over-producing data “to be safe”	Increases breach and regulatory exposure	Minimization checklist and scoped production
Ad hoc approach by region/team	Inconsistent decisions create audit findings	Standard templates, log, and periodic review

Enforcement context and risk implications

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

From a risk lens, Article 48 failures typically show up as:

• Unlawful international transfers or disclosures.
• Weak governance over government access requests.
• Processor oversight gaps (a third party discloses without your instruction).

Even if the underlying request is legitimate, regulators and customers will focus on whether you had a controlled, documented process tied to GDPR Chapter V decision-making. (Regulation (EU) 2016/679, Article 48)

Practical 30/60/90-day execution plan

First 30 days (Immediate stabilization)

• Assign ownership: Legal primary, Privacy co-approver, Security intake partner.
• Publish the “stop the line” rule and intake path for third-country demands.
• Create templates: triage form, Article 48 decision record, response letters. (Regulation (EU) 2016/679, Article 48)
• Stand up a demand log (even a controlled spreadsheet if you lack tooling).

Days 31–60 (Operationalize across teams and third parties)

• Train frontline teams: Security, Support, HR, Finance, IT, Sales Ops.
• Build a system/data map for the most commonly requested datasets.
• Update processor playbooks: notification, no-disclosure-without-instruction, evidence retention expectations.
• Run a tabletop exercise using a realistic subpoena scenario and capture gaps.

Days 61–90 (Make it auditable and repeatable)

• Add approval workflows and evidence collection in your GRC platform (Daydream works well if you want a requirement-to-evidence structure).
• Implement periodic review of the demand log to detect patterns and repeat requests.
• Formalize exception handling (who can approve deviations, how they are documented).
• Internal audit-style check: sample requests, confirm evidence packet completeness.

Frequently Asked Questions

Does Article 48 mean we can never respond to a non-EU subpoena?

No. It means the subpoena is not automatically enforceable for GDPR purposes unless based on an international agreement, and you must rely on a lawful GDPR Chapter V basis if you disclose. Document the path you used. (Regulation (EU) 2016/679, Article 48)

What counts as a “decision of an administrative authority”?

Treat any binding order or formal demand from a non-EU government agency as in-scope until Legal/Privacy determines otherwise. Route it through the same intake and decision record. (Regulation (EU) 2016/679, Article 48)

We are a processor. Can we disclose directly to the foreign authority?

Your default should be no. Escalate to the controller and follow your contract instructions, while documenting the Article 48 analysis and any legal constraints on notice. (Regulation (EU) 2016/679, Article 48)

How should we handle “emergency” law enforcement requests?

Treat urgency as a triage factor, not an approval bypass. Use an expedited version of the same workflow: confirm scope, document the Article 48 screen, minimize data, and record approvals. (Regulation (EU) 2016/679, Article 48)

What if the request is served on our US-based cloud provider?

Require the provider to notify you and pause production where legally permitted. Your third-party terms and operating procedure should prevent unilateral disclosure of your controlled personal data. (Regulation (EU) 2016/679, Article 48)

What evidence will satisfy an auditor that our Article 48 control works?

A complete demand log plus a sample of case packets with the original demand, Article 48 enforceability assessment, Chapter V rationale, approvals, and production/minimization records. (Regulation (EU) 2016/679, Article 48)