Article 44: General principle for transfers

Article 44 requires that any transfer of EU personal data to a third country or international organisation only happens if you comply with GDPR’s Chapter V transfer conditions, including onward transfers. Operationally, you must (1) identify and map transfers, (2) select a valid transfer mechanism, and (3) prove your controls operate across third parties and sub-processors. ¹

Key takeaways:

• You need an inventory of cross-border data flows, including onward transfers, tied to systems and third parties. ¹
• Every transfer needs an explicit Chapter V “permission path” and a documented decision record; policy statements alone won’t carry an audit. ¹
• Controllers and processors are both on the hook, so your third-party due diligence and contract workflow must enforce transfer conditions end-to-end. ¹

Article 44 is the “gatekeeper” requirement for international data transfers under GDPR: it does not give you a transfer tool by itself, but it blocks transfers unless you can show the Chapter V conditions are met. The practical implication for a Compliance Officer, CCO, or GRC lead is straightforward: you need a repeatable operating process that prevents teams from sending personal data abroad by default, and you need evidence that the process works for your third parties and their sub-processors.

Most organizations fail Article 44 in predictable ways: they cannot describe where personal data goes, they discover transfers late (after procurement or implementation), and they cannot demonstrate how onward transfers are controlled once the data leaves their environment. Article 44 explicitly covers onward transfers from one third country to another, so your controls must reach beyond your direct contract boundary. ¹

This page focuses on requirement-level execution: scoping, control design, intake gates, contract triggers, evidence packets, and audit-ready artifacts you can operationalize quickly.

Regulatory text

GDPR Article 44 (excerpt): “Any transfer of personal data which are undergoing processing or are intended for processing after transfer to a third country or to an international organisation shall take place only if, subject to the other provisions of this Regulation, the conditions laid down in this Chapter are complied with by the controller and processor, including for onward transfers of personal data from the third country or an international organisation to another third country or to another international organisation …” ¹

What the operator must do

• Treat international transfer compliance as a hard precondition for moving personal data outside the relevant jurisdictional boundary, not as a post-signature contract task. ¹
• Ensure both controllers and processors follow the Chapter V conditions, meaning your internal engineering and procurement flows must work even when you act “only” as a processor. ¹
• Control and document onward transfers (a third party in country A sending data onward to country B), not just the first hop. ¹

Plain-English interpretation (requirement meaning)

If your organization sends or makes personal data accessible outside the EU/EEA to a third country or an international organisation, you can only do so when you have satisfied the GDPR’s international transfer conditions in Chapter V. Article 44 is the general principle that applies to every transfer scenario, including third-party hosting, support access, shared service centers, analytics providers, and any sub-processor chain. ¹

For operations: no mechanism, no transfer. Your job is to make that rule real in intake, procurement, architecture reviews, and third-party onboarding.

Who it applies to (entity and operational context)

Applies to:

• Controllers exporting personal data to third parties or group entities outside the EU/EEA. ¹
• Processors handling personal data on behalf of a controller where processing includes international access/hosting/remote support, and where onward transfers may occur through sub-processors. ¹

Common operational contexts that trigger Article 44

• Using a cloud service where data is stored, replicated, backed up, or administered from outside the EU/EEA.
• Allowing third-party support personnel in a third country to access EU personal data (even if storage stays in the EU).
• Sharing datasets with affiliates, partners, or customers where recipients are established outside the EU/EEA.
• Sub-processor chains (your processor uses another processor outside the EU/EEA). ¹

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

Below is a pragmatic operating procedure you can implement without rewriting your entire privacy program.

Step 1: Establish scope and ownership (make it executable)

1. Name an owner for “International Transfers (Article 44)” across Privacy, Security, Procurement, and Engineering.
2. Build a role-and-scope register:
   • Controller vs. processor role per product/service line
   • Data categories involved (customer, employee, end-user, special category where relevant)
   • Systems in scope (apps, data stores, integration points)
   • Third parties involved and sub-processor visibility
3. Define trigger events that force review:
   • New third party onboarding
   • Change in hosting region, support model, or sub-processor list
   • New integration that exports personal data

Daydream note: In practice, teams move fastest when this is a single intake workflow that routes to the right reviewer with required fields and hard stops. Daydream can structure the intake, approvals, and evidence packet so transfer decisions don’t live in inboxes.

Step 2: Map transfers and onward transfers (data-flow inventory you can defend)

Create and maintain an international transfer inventory that answers:

• What data leaves (data elements and categories)?
• Who receives it (legal entity and role)?
• Where it goes (country/region; include remote access locations if applicable)?
• Why it’s transferred (business purpose)?
• What happens next (onward transfers via sub-processors)? ¹

Minimum viable output: a table you can export during an audit and reconcile to vendor lists, system architecture diagrams, and RoPA.

Step 3: For each transfer, document the “Chapter V permission path”

Article 44 points you to “conditions laid down in this Chapter.” Your operating requirement: every transfer record must cite the transfer mechanism used and link to the supporting evidence. ¹

Implementation pattern:

• Add a required field in your intake: “Transfer mechanism (Chapter V)” + “Decision record link.”
• Block procurement or go-live until populated and approved.

Keep this mechanism selection controlled by Privacy/GRC, not left to a project manager to guess.

Step 4: Contract and third-party controls (cover onward transfers)

Because Article 44 covers onward transfers, your third-party due diligence needs to verify:

• The third party’s sub-processor model and how onward transfers are governed
• Whether they can provide a current list of sub-processors and locations
• Whether your contract terms require them to follow the chosen transfer mechanism downstream ¹

Operationalize this as:

• A third-party onboarding checklist that cannot be waived without documented exception approval.
• A sub-processor change notification control: a way to receive, review, and record changes that impact transfer scope.

Step 5: Build monitoring and exception handling (prove it’s not “one and done”)

Auditors will test operation. Put in place:

• Periodic reconciliation between:
  • Vendor master/procurement system
  • Cloud accounts and regions
  • Support tooling access logs and user locations (where available)
  • Your transfer inventory
• An exception register for urgent business needs, with:
  • risk acceptance owner
  • compensating controls
  • target remediation date and closure evidence

Step 6: Train the teams who create transfers (practical, role-based)

Training should be short and tied to actual work:

• Procurement: identify transfers and route intake
• Engineering/IT: region selection, remote access, integrations
• Customer Success/Support: support access from third countries
• Legal/Privacy: mechanism selection, decision records, contracting

Required evidence and artifacts to retain (audit-ready)

Keep an “Article 44 evidence packet” per transfer or per third party (choose a consistent unit). Include:

Core artifacts

• International transfer inventory entry (with system + third party + country + onward transfer notes) ¹
• Controller/processor role decision for the processing context
• Transfer mechanism decision record (the “permission path” and approver)
• Contracts and addenda that implement the selected transfer approach (and cover sub-processors/onward transfers)
• Sub-processor list and location disclosures (current as of last review)
• Approval workflow evidence (tickets, GRC workflow exports, or signed checklists)
• Exceptions and remediation tracking records

Operational artifacts (strong signals in audits)

• Procurement gate evidence (a required questionnaire field, rejection logs, or “cannot proceed” controls)
• Architecture review outputs showing region and access constraints
• Change management records for region/sub-processor changes

Common exam/audit questions and hangups

Expect questions like:

• “Show me all third parties that receive EU personal data outside the EU/EEA, and the mechanism used for each.” ¹
• “How do you detect remote access to EU personal data from third countries?” ¹
• “How do you control onward transfers by your processors/sub-processors?” ¹
• “What is your process when a third party adds a new sub-processor in a new country?” ¹
• “Who signs off, and what evidence proves the sign-off happened before go-live?”

Hangups that slow teams down:

• Confusion between “data stored in EU” and “data accessed from outside EU.” Treat both as transfer risk until you have a documented position and evidence aligned to your mechanism decision. ¹
• Lack of a single source of truth. If procurement, security, and privacy each have different lists, you will fail basic reconciliation.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Policy-only compliance.
   Fix: Put Article 44 checks into intake gates (procurement + architecture). Require a transfer mechanism field and a decision record link before signature or go-live. ¹

2. Mistake: No onward transfer visibility.
   Fix: Require sub-processor disclosures and change notification in contracting, then track changes in a register tied to the transfer inventory. ¹

3. Mistake: Treating “processor” as “not our problem.”
   Fix: Even as a processor, implement the same inventory and decision records for where and how you process customer data internationally, and provide this evidence in customer diligence. ¹

4. Mistake: Discovering transfers after implementation.
   Fix: Add a pre-implementation question in engineering delivery: “Will personal data be stored/accessed outside the EU/EEA (including support)?” Route “yes” to Privacy/GRC approval. ¹

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this page, so this section is intentionally limited to what Article 44 itself establishes: transfers are prohibited unless Chapter V conditions are met, and the obligation applies to controllers and processors, including onward transfers. The operational risk is predictable: if you cannot evidence the condition for a transfer, you may be forced to stop the transfer, redesign processing, or exit a third-party relationship on short notice. ¹

Practical 30/60/90-day execution plan

Use phases to avoid artificial timelines while still driving urgency.

First 30 days (Immediate: stop the bleeding)

• Assign owners and publish an Article 44 operating procedure with trigger events and approvers.
• Stand up a minimum viable international transfer inventory (top systems + top third parties).
• Add procurement and security intake questions that flag third-country storage or access and force Privacy/GRC review.
• Create an evidence packet template and require it for any new third party involving personal data.

Days 31–60 (Near-term: make it repeatable)

• Expand transfer mapping across remaining systems and third parties; reconcile against vendor master and SSO/app catalogs.
• Standardize contract fallback language and sub-processor/onward-transfer requirements for the procurement team.
• Implement a change notification workflow for sub-processor/location changes and tie it to reassessment.

Days 61–90 (Operationalize: prove it runs)

• Run an internal audit-style sampling: pick several transfers and verify the end-to-end evidence exists (inventory → mechanism decision → contract → onward transfer coverage).
• Add reporting: open exceptions, pending reviews, and upcoming renewals that involve international transfers.
• Prepare a customer/regulator-ready export: transfer inventory + decision records + contract artifacts.

Frequently Asked Questions

Does Article 44 apply if the data is stored in the EU but accessed by support staff outside the EU?

Article 44 applies to transfers to a third country, and organizations should treat cross-border access as a transfer scenario to assess and document under Chapter V conditions. Record the access model in your transfer inventory and tie it to an approved mechanism decision. ¹

We are a processor. Do we still need our own transfer inventory?

Yes. Article 44 states the conditions must be complied with by the controller and processor, and you need evidence of where and how you process personal data, including onward transfers through sub-processors. Build the inventory so you can answer customer diligence quickly. ¹

What counts as an “onward transfer” in practice?

An onward transfer is when personal data transferred to a third country or international organisation is then transferred onward to another third country or international organisation. Practically, this often occurs through sub-processors, affiliates, or support subcontractors. ¹

What should auditors see as proof that Article 44 is operational, not theoretical?

Auditors look for operating evidence: intake gates, documented transfer mechanism decisions, executed contracts that reflect the decision, and a maintained inventory that includes onward transfers. They also expect exceptions to be tracked and closed with evidence. ¹

How do we handle a third party that won’t disclose sub-processor locations?

Treat it as a blocker or a formal exception with executive risk acceptance, because Article 44 explicitly includes onward transfers and you need defensible visibility into downstream transfer pathways. Put the decision, rationale, and compensating controls in your evidence packet. ¹

What’s the fastest way to reduce Article 44 risk across many third parties?

Start with an inventory and a gate: identify where personal data leaves the EU/EEA (or is accessible from outside), then prevent new transfers from going live without an approved mechanism and evidence packet. Centralize the workflow in a system like Daydream so approvals and artifacts stay tied to the third party record. ¹

Footnotes

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