Article 44: General principle for transfers

Article 44 requires that any transfer of EU personal data to a third country or international organisation happens only under GDPR Chapter V transfer conditions, including onward transfers. To operationalize it, you need a complete transfer inventory, a decision workflow that selects and approves a valid transfer mechanism, and repeatable evidence that each transfer remains within the approved scope. ¹

Key takeaways:

• Inventory and classify every cross-border data flow, including onward transfers, before you approve or renew third-party processing.
• Implement a transfer decision workflow that blocks transfers unless Chapter V conditions are met and documented.
• Maintain an auditable evidence packet per transfer: mechanism, scope, approvals, and ongoing monitoring outputs.

“Article 44: General principle for transfers requirement” is the gatekeeper for cross-border data movement under the GDPR. It does not, by itself, give you a transfer mechanism. Instead, it states the operating rule: transfers to a third country or an international organisation may occur only if the Chapter V conditions are met by both controllers and processors, including for onward transfers. ¹

For a Compliance Officer, CCO, or GRC lead, the practical implication is clear: you must run transfers like a controlled business process, not an ad-hoc contracting exercise. Your job is to make sure the organization can answer three regulator-grade questions quickly: (1) Where are we transferring personal data? (2) On what lawful Chapter V basis? (3) How do we ensure the transfer stays within the approved scope over time?

This page gives requirement-level implementation guidance you can put into production: roles, triggers, step-by-step workflow, evidence to retain, and the questions auditors and customers will ask when they test cross-border transfer controls.

Regulatory text

GDPR Article 44 (excerpted): “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 …” ¹

What an operator must do

Article 44 is a control requirement: you must ensure no transfer occurs unless your organization has satisfied the applicable Chapter V transfer conditions, and you must extend that control to onward transfers initiated by your third parties. ¹

Operationally, treat Article 44 as:

• A scope definition (what counts as a transfer, who is covered: controllers and processors) ¹
• A preventive gate (block or redesign transfers that cannot meet Chapter V) ¹
• An ongoing obligation (transfers must remain compliant after go-live, including onward transfers) ¹

Plain-English interpretation

If personal data leaves the EEA (or is accessed from outside in a way that constitutes a third-country transfer for your operating model), you cannot “paper over” the risk with a generic privacy policy or a processor clause. You need a documented, approved transfer basis under Chapter V, and you need to control what your third party does next with the data (onward transfers). ¹

Who it applies to (entity + operational context)

Covered parties

• Controllers transferring personal data to a third country/international organisation. ¹
• Processors making transfers on behalf of a controller, including where a processor uses sub-processors that create onward transfers. ¹

Operational situations that typically trigger Article 44 work

• Contracting with a third party that stores, supports, or can remotely access EU personal data from outside the EEA.
• Enabling a sub-processor chain (cloud, support, analytics, fraud, HRIS) where the first third party discloses or makes data available onward.
• Corporate group data sharing (shared services, central IT, global SOC/support).
• Incident response, eDiscovery, or support workflows where data is exported to a non-EEA tool or reviewed by non-EEA personnel.

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

Below is an operator-grade workflow you can implement in procurement + security review + privacy review. The goal is to stop “silent transfers” and make transfer decisions repeatable.

Step 1: Build and maintain a transfer inventory (system-of-record)

Create a register that maps:

• Processing activity / product / business owner
• Controller vs processor role for the activity
• Data categories and approximate sensitivity (customer, employee, special categories if applicable)
• Source location (EEA) and destination (country / international organisation)
• Third parties involved (primary + sub-processors) and whether onward transfers occur
• Systems involved (storage, support tooling, admin access paths)

This addresses a common failure mode: teams cannot control transfers they cannot enumerate. Article 44 explicitly covers transfers and onward transfers, so inventory completeness matters. ¹

Practical control: make this register a required artifact for onboarding any third party that touches EU personal data, and a required field in change management when adding new hosting regions, support locations, or sub-processors.

Step 2: Define transfer “trigger events” and hard-stop gates

Codify triggers that force a transfer review before data moves:

• New third party onboarding involving EU personal data
• Data residency change (new region, new tenant, new storage class)
• Support model change (new support center, follow-the-sun)
• Sub-processor additions or changes
• Material product changes that expand data categories or purposes

Hard-stop gate: do not allow production data flow until the transfer basis under Chapter V is approved and recorded. Article 44 frames this as “shall take place only if” conditions are met. ¹

Step 3: Implement a transfer decision procedure with named owners

Write an operating procedure that answers, every time:

1. Is this a transfer to a third country or international organisation? ¹
2. Who is acting as controller and who is acting as processor for this activity? Document the role determination because the obligations and contract posture differ.
3. What is the Chapter V condition relied upon? Record the specific mechanism used under Chapter V (do not rely on “GDPR compliant” statements).
4. What onward transfers are expected? Identify sub-processors and any onward disclosure paths; require contractual notice/approval controls where your model requires it. ¹
5. What is the permitted scope? Purposes, data categories, locations, retention, and security controls.

Ownership model (minimum viable):

• Privacy/DP function: approves transfer basis selection and scope statement.
• Security: confirms technical architecture and access paths match the documented scope.
• Procurement/Legal: ensures contract terms reflect transfer scope and sub-processing controls.
• Business owner: attests to accuracy of data mapping and validates operational necessity.

Step 4: Contract and configuration alignment (make paper match reality)

Article 44 failures often come from mismatch between contract language and actual architecture. Force alignment:

• Ensure your contract and sub-processor terms reflect the approved transfer basis and geographic scope.
• Configure systems to enforce the approved scope: region locks, access controls, admin access restrictions, logging, and DLP where appropriate.
• Ensure your third party onboarding checklist includes “transfer basis approved” as a mandatory completion criterion.

Step 5: Onward transfer control (sub-processor governance)

Because Article 44 explicitly includes onward transfers, build a sub-processor governance loop:

• Require and review the third party’s sub-processor list and change process.
• Track sub-processor country locations in your transfer inventory.
• Define approval/notice rules and document decisions when sub-processors change.

Step 6: Ongoing monitoring and evidence refresh

Set a recurring review cadence aligned to your vendor/third-party risk program:

• Reconfirm the transfer inventory against reality (new regions, new support locations, new sub-processors).
• Capture evidence of continued alignment (updated diagrams, sub-processor lists, access logs summaries where feasible).
• Record exceptions and compensating controls with an owner and remediation plan.

If you run Daydream for third-party governance, use it as the system-of-record to tie together: third-party onboarding, data flow mapping, transfer approvals, and the evidence packet you need for customer diligence and audits. Keep it factual: one place, consistent artifacts, clear owners.

Required evidence and artifacts to retain

Maintain an evidence packet per transfer relationship (one packet can cover multiple systems if scope is identical and clearly documented):

Artifact	What it proves	Owner
Transfer inventory entry	You know what is transferred, to where, and through whom	Privacy/GRC
Role determination (controller/processor)	Correct obligation mapping and contract posture	Privacy/Legal
Transfer decision record	Chapter V condition selected and approved	Privacy
Onward transfer/sub-processor record	You identified and governed onward transfers	Procurement/Privacy
System/data flow diagram (current state)	Actual architecture matches approved scope	Security/Engineering
Change control records	Transfers are re-approved when scope changes	IT/Engineering
Exception log + remediation plan	Known gaps are owned and tracked	GRC

Article 44’s text points directly at “controller and processor” responsibility and onward transfers; your evidence should map to those elements. ¹

Common exam/audit questions and hangups

Expect these questions from internal audit, external auditors, and enterprise customers:

• “Show me all third countries where EU personal data is transferred, including access for support.” ¹
• “For this specific third party, what is the transfer mechanism and who approved it?”
• “How do you control onward transfers to sub-processors and other locations?” ¹
• “What triggers a re-assessment when the vendor adds a sub-processor or a new region?”
• “Prove the implemented system configuration matches the documented scope.”

Hangup to anticipate: teams produce a policy statement but cannot produce a per-transfer decision record tied to the actual data flow. Article 44 is satisfied by meeting Chapter V conditions in practice, not by having a generic policy. ¹

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Treating transfers as a legal-only activity.
   Fix: make Security and Engineering co-owners of the transfer scope statement and architecture evidence.

2. Mistake: Missing onward transfers through sub-processors.
   Fix: require sub-processor lists and change notifications, and reflect them in your inventory and decision records. ¹

3. Mistake: Inventory exists but is not connected to procurement/change management.
   Fix: add hard-stop fields to intake workflows. No completed transfer record, no go-live.

4. Mistake: Approving a transfer once and never revisiting it.
   Fix: add recurring reviews and trigger-event reassessments tied to vendor changes and architecture changes.

5. Mistake: Unclear role decisions (controller vs processor) per processing activity.
   Fix: maintain a role-and-scope register for this requirement across products and systems, and train procurement and product teams on when to escalate for determination.

Enforcement context and risk implications

No public enforcement cases were provided in the approved source catalog for this page, so do not treat this as an enforcement digest.

Risk-wise, Article 44 is a dependency requirement: if your transfer mechanism fails or your onward transfer chain is uncontrolled, a regulator can view the transfer as unlawful under Chapter V because Article 44 requires that Chapter V conditions be complied with for transfers and onward transfers by controllers and processors. ¹

Practical 30/60/90-day execution plan

Use phased delivery without making unsupported timeline claims about completion speed. Adjust scope based on transfer volume and organizational complexity.

First 30 days (Immediate stabilization)

• Name owners and publish the Article 44 operating procedure: triggers, approval steps, required evidence.
• Stand up the transfer inventory template and begin population for top-risk third parties (cloud hosting, core processors, support tooling).
• Add intake gates to procurement/third-party onboarding: transfer identified, inventory record created, privacy review required.

Next 60 days (Operational control)

• Expand inventory coverage to remaining in-scope third parties and internal cross-border access patterns.
• Implement sub-processor governance: list capture, change notification routing, and approval/exception workflow.
• Start collecting standardized evidence packets and store them in a system-of-record (Daydream or your GRC platform) tied to each third party and system.

Next 90 days (Audit readiness and scaling)

• Run a table-top audit: pick several transfers and test whether you can produce the complete evidence packet quickly, including onward transfers.
• Close gaps between documented scope and system reality (region settings, admin access, logging).
• Implement recurring monitoring: scheduled reviews plus automated alerts where feasible for sub-processor and region changes.

Frequently Asked Questions

Does Article 44 itself tell me which transfer mechanism to use?

No. Article 44 states the general rule that transfers can occur only if the Chapter V conditions are complied with. Your procedure must select, approve, and document the specific Chapter V condition relied upon. ¹

Are processors responsible for transfers too, or only controllers?

Both. Article 44 explicitly states the conditions must be complied with by the controller and processor, including for onward transfers. Build your controls so processors cannot initiate or expand transfers without documented approval. ¹

What counts as an “onward transfer” for operational purposes?

Treat any disclosure or making data available from the initial third country/international organisation to another third country/international organisation as onward transfer scope that you must identify and govern. Capture it through sub-processor management and architecture reviews. ¹

What evidence should I have ready for an audit or customer diligence request?

Maintain a per-transfer evidence packet: inventory entry, role determination, transfer decision record, sub-processor/onward transfer record, and architecture evidence showing the actual data flow and access paths. Article 44 is tested by proving compliant conditions exist for the real transfer, not a theoretical one. ¹

We have a GDPR policy that says “we only transfer data lawfully.” Is that enough?

No. Article 44 is operational: you must show each transfer takes place only when Chapter V conditions are met, including onward transfers. Auditors expect per-transfer decisions, approvals, and evidence tied to systems and third parties. ¹

How do I keep the transfer inventory accurate when third parties change their sub-processors?

Make sub-processor changes a trigger event with an intake path to privacy/security review, and require the third party to provide a current list and change notices. Update the inventory and attach the change record to the evidence packet. ¹

Footnotes

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