Article 45: Transfers on the basis of an adequacy decision

Article 45 permits cross-border transfers of personal data to a third country or international organisation when the European Commission has issued an adequacy decision for that destination, without requiring additional transfer authorisation. To operationalize it, you must (1) identify transfers, (2) confirm adequacy scope matches the destination and context, and (3) document the decision and monitor for changes. (Regulation (EU) 2016/679, Article 45)

Key takeaways:

• You can transfer without SCCs or other GDPR transfer tools only if an adequacy decision applies to your specific destination and scope. (Regulation (EU) 2016/679, Article 45)
• Operational control hinges on accurate transfer mapping plus a documented “adequacy eligibility” check at onboarding and change events. (Regulation (EU) 2016/679, Article 45)
• Keep an auditable evidence packet: adequacy verification, scope rationale, approvals, and periodic re-checks. (Regulation (EU) 2016/679, Article 45)

The operational question behind the article 45: transfers on the basis of an adequacy decision requirement is simple: “Are we sending EU personal data to a place that the Commission has recognized as adequate, and can we prove it?” Article 45 is the cleanest transfer path because, where it applies, the GDPR does not require “specific authorisation” for the transfer. (Regulation (EU) 2016/679, Article 45)

In practice, teams fail this requirement in boring ways: they don’t know where data is going, they confuse a third party’s corporate HQ with the actual processing location, they assume “cloud in region” equals “no transfer,” or they lack a repeatable check when engineering adds a new subprocessor. The fix is an intake-and-change workflow that forces an adequacy determination before data moves, plus evidence retention that a regulator or customer auditor can follow without tribal knowledge.

This page gives requirement-level implementation guidance you can deploy quickly: applicability, step-by-step controls, decision records, audit questions, common mistakes, and an execution plan that turns Article 45 into an operating procedure you can run across procurement, security, legal, and engineering. (Regulation (EU) 2016/679, Article 45)

Regulatory text

Regulatory excerpt (operative rule): A transfer of personal data to a third country or an international organisation may take place where the Commission has decided that the destination ensures an adequate level of protection, and the transfer “shall not require any specific authorisation.” (Regulation (EU) 2016/679, Article 45)

What the operator must do:

1. Treat adequacy as a defined eligibility criterion for international transfers (destination + scope must match the Commission decision). (Regulation (EU) 2016/679, Article 45)
2. If adequacy applies, you may proceed without adding a separate transfer mechanism solely for Chapter V purposes; if it does not apply, route the transfer to a different transfer mechanism decision path. (Regulation (EU) 2016/679, Article 45)
3. Maintain documentation that shows you checked adequacy before the transfer and that you re-check when something material changes (destination, third party, processing location, service architecture). (Regulation (EU) 2016/679, Article 45)

Plain-English interpretation (what Article 45 expects)

If EU personal data leaves the EEA, you need a lawful transfer basis under GDPR Chapter V. Article 45 says one option is an adequacy decision: the European Commission has already decided that a specific third country (or a territory/sector within it) or an international organisation provides an “adequate” level of protection. When your transfer fits that decision, you do not need extra transfer authorisation steps for that transfer. (Regulation (EU) 2016/679, Article 45)

Operationally, “fits the decision” is the work. Your program needs to answer, with evidence:

• Where is data accessed from and processed (not where the contract is signed)?
• What is the destination legal entity and processing footprint?
• Does the adequacy decision cover that destination and the relevant scope (country vs sector/territory vs international organisation)? (Regulation (EU) 2016/679, Article 45)

Who it applies to

Entities: Any organization acting as a controller or processor that transfers personal data to a third country or an international organisation. Your obligations differ by role, but both controllers and processors must ensure transfers are covered by an appropriate Chapter V mechanism. (Regulation (EU) 2016/679)

Operational contexts where this shows up:

• Third-party onboarding and subprocessor approvals: SaaS tools, support platforms, payroll, analytics, CRM, incident response retainers.
• Internal group transfers: EU entity sending data to a non-EEA affiliate, shared service center, or global SOC access.
• Remote access administration: engineers, support agents, and managed service providers accessing EU personal data from outside the EEA.
• Cloud architecture: backups, DR, logging, and telemetry routed cross-border by default.

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

Step 1: Build and maintain a “transfer inventory” you can defend

Create a list of all processing activities and systems that export, replicate, store, or provide access to EU personal data outside the EEA. Make it practical:

• System / process name
• Data categories (customer data, employee data, sensitive data flags)
• Data subjects (customers, end users, employees)
• Destination (country or international organisation), including remote access locations
• Third parties involved (processors, subprocessors, affiliates)
• Trigger paths (API, support portal, data warehouse, backups)

Control tip: Tie this to procurement + security architecture review so new tools cannot go live without a transfer entry.

Step 2: Run an “adequacy eligibility check” for each transfer

For each destination in the inventory:

• Confirm the destination is a third country or international organisation for Chapter V purposes. (Regulation (EU) 2016/679, Article 45)
• Confirm there is a Commission adequacy decision that covers the destination and any stated scope limitations (country vs sector/territory vs international organisation). (Regulation (EU) 2016/679, Article 45)
• Record the rationale: what you checked, when you checked it, and who approved.

Decision record template (minimum fields):

• Transfer ID (map to your RoPA / system register)
• Destination (country/organisation) and processing locations
• Adequacy status (Yes/No)
• Scope fit statement (why the decision applies to this transfer)
• Owner (business) + approver (privacy/legal)
• Date of verification + next review trigger
• Exceptions / compensating controls (if any)

Step 3: Gate the transfer in your operating workflows

Article 45 succeeds or fails at intake. Put a hard gate in:

• Procurement / third-party intake: “Will any EU personal data be processed or accessed outside the EEA? If yes, list countries.” If adequacy is asserted, require the evidence packet before contracting.
• Engineering / architecture change: require review when data residency, support model, logging, or backup regions change.
• Subprocessor changes: require notice and review before activation.

Practical gating rule: No “adequacy-based transfer” goes to production until the adequacy check is documented and approved. (Regulation (EU) 2016/679, Article 45)

Step 4: Contract and transparency alignment (don’t create a paper gap)

Article 45 removes the need for a separate transfer tool, but you still need contracts and disclosures to match reality:

• Ensure your third-party agreements accurately state processing locations and the right to be notified of changes.
• Align privacy notices and customer DPAs to reflect cross-border processing where applicable (avoid “EEA-only” claims if remote access occurs).

Step 5: Monitor for drift (adequacy is not “set and forget”)

Build monitoring around trigger events, not calendar reminders:

• New country added for support or engineering access
• New subprocessor
• Cloud region change
• M&A or corporate restructuring that changes processing entities
• Product feature launches that move data to new systems

For each trigger, re-run the adequacy eligibility check and update the evidence packet. (Regulation (EU) 2016/679, Article 45)

Step 6: Operationalize ownership and escalation

Define owners in a short SOP:

• Process owner: Privacy/GRC
• Data transfer owners: System owners and procurement
• Approvers: Legal/Privacy (and Security for architecture)
• Escalation: If adequacy does not apply, route to your non-adequacy transfer mechanism workflow.

Where Daydream fits: Daydream is a natural home for the transfer inventory, third-party records, approval workflow, and recurring evidence packets, so adequacy checks don’t live in spreadsheets that break during audits.

Required evidence and artifacts to retain

Keep a single “Article 45 evidence packet” per transfer (or per third party, if that’s how you manage).

• Transfer inventory entry with destinations and processing/access locations
• Adequacy verification record (decision log with approver, date, scope fit)
• Data flow diagram or narrative sufficient to show how data reaches the destination
• Third-party documents that confirm processing locations and change notification terms (contracts, order forms, security addenda)
• Change management records showing re-assessment after trigger events
• Exceptions register if any transfer was incorrectly assumed to be adequate and required remediation

Common exam/audit questions and hangups

Auditors and regulators tend to probe the same weak spots:

• “Show me all third countries where EU personal data is accessed, including remote support.”
• “Which transfers rely on adequacy, and how do you confirm the adequacy decision applies?”
• “How do you prevent a team from adding a non-adequate destination without review?”
• “How do you know your subprocessors’ subprocessors didn’t move processing?”
• “Where is the evidence that the check happened before production data flowed?” (Regulation (EU) 2016/679, Article 45)

Hangup to expect: People confuse “data center region” with “access location.” Article 45 is about the transfer, which includes access and processing from a third country in many real operating models.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails	Fix
Assuming “EU-hosted” means no transfer	Remote access, support, and admin paths can still create a third-country transfer	Include access locations in transfer inventory; gate support model changes
Treating adequacy as a one-time checkbox	Processing changes faster than policies	Tie re-checks to change triggers and subprocessor updates
No documented scope fit	Adequacy decisions can be scoped to territories/sectors	Record the scope rationale in the decision log (Regulation (EU) 2016/679, Article 45)
Inventory exists but isn’t enforced	Teams bypass spreadsheets	Put checks into procurement + architecture review workflows
Evidence scattered across teams	Audits fail on retrieval, not intent	Store an evidence packet per transfer in a system of record

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this page, so this guidance focuses on defensible execution of the text. (Regulation (EU) 2016/679, Article 45)

Risk you should plan for:

• Regulatory exposure: If a transfer is incorrectly treated as adequate, you may be missing an appropriate Chapter V transfer tool for that flow. (Regulation (EU) 2016/679)
• Contractual exposure: Customers often request your transfer mechanism posture during due diligence; unclear inventories and undocumented decisions create deal friction.
• Operational exposure: Shadow IT and support tooling commonly introduce new transfer destinations without legal review.

Practical execution plan (30/60/90)

Calendar durations are guidance for sequencing work, not a claim about required timing.

First 30 days (stabilize and stop new gaps)

• Assign an owner for Article 45 transfer determinations (Privacy/GRC) and define approvers.
• Stand up a transfer inventory template and populate the top systems and third parties that process EU personal data.
• Add an intake question to procurement and third-party onboarding: “Any processing or access outside the EEA? List countries.”
• Create an adequacy decision record template and require it before approving any “adequacy-based” transfer. (Regulation (EU) 2016/679, Article 45)

Days 31–60 (cover the long tail and embed gates)

• Expand the transfer inventory to all in-scope systems, including telemetry, logs, backups, and support tools.
• Implement a change trigger workflow with Engineering/Security: region changes, new access locations, new subprocessors require re-check.
• Centralize evidence packets per third party / transfer in your GRC system (Daydream or equivalent) so retrieval is one click.

Days 61–90 (prove it works and harden operations)

• Run an internal audit sampling: pick transfers marked “adequacy-based” and confirm the evidence packet exists and matches reality.
• Train procurement, IT, and engineering on what counts as a transfer and what evidence is required.
• Add metrics that matter operationally (counts, completion, exceptions), without inventing thresholds: track open adequacy determinations and overdue re-checks.
• Document remediation playbooks for “adequacy assumption was wrong” incidents: containment, mechanism selection, customer comms, and record updates.

Frequently Asked Questions

Does Article 45 mean we don’t need SCCs at all?

Only for transfers that fall under a valid Commission adequacy decision for the specific destination and scope. If adequacy does not apply, you need a different Chapter V transfer mechanism for that transfer. (Regulation (EU) 2016/679, Article 45)

What counts as a “transfer” for Article 45 operational purposes?

Treat any sending, storage, or access of EU personal data from a third country or by an international organisation as a transfer scenario you must map and assess. Build your inventory to include remote admin and support access paths. (Regulation (EU) 2016/679)

We store data in the EU, but our support team is outside the EEA. Can we rely on Article 45?

Possibly, if the access occurs from a destination covered by an adequacy decision and the scope fits. You still need a documented adequacy eligibility check tied to that support model. (Regulation (EU) 2016/679, Article 45)

How do we operationalize adequacy decisions without legal research every time?

Use a standard decision record and require Privacy/Legal approval for the initial determination, then re-check only when defined triggers occur (new country, new subprocessor, architecture change). Store the evidence packet in a system of record so teams reuse prior determinations. (Regulation (EU) 2016/679, Article 45)

What evidence do auditors expect for adequacy-based transfers?

They look for a transfer inventory entry plus a dated adequacy determination showing destination, scope fit, approver, and linkage to the system or third party. They also expect change records showing you re-assess when processing locations or access patterns change. (Regulation (EU) 2016/679, Article 45)

Can a processor make the adequacy call, or must the controller decide?

Both controllers and processors have obligations under GDPR and should be able to show how their transfers are covered. In practice, processors should maintain their own transfer inventory and adequacy decision records and provide them to controllers during due diligence. (Regulation (EU) 2016/679)