This is an operational checklist for the moment a specific software supplier will move personal data outside the European Economic Area. It assumes you already know why transfers are restricted and focuses on the sequence of steps and the record each one produces.
Two companion pieces sit around it. The assessment methodology, including how to evaluate the destination's legal environment, is in our transfer impact assessment guide. What to do when a sub-processor change creates a new transfer after signature is in subprocessor third-country transfers. This article is the pre-flight list for a single vendor.
Step 1: establish that there is a transfer
Chapter V of the General Data Protection Regulation (GDPR) applies when personal data is transferred to a third country or an international organization. In vendor relationships, four situations qualify, and only the first is routinely spotted:
- Data is stored in a third country.
- Data is stored in the European Economic Area but accessible from a third country, including by support or engineering staff.
- A sub-processor in the vendor's chain is established in a third country.
- The vendor's parent or affiliate in a third country can access the data, including for administration.
Remote access is a transfer. A supplier whose sales material stresses EU hosting may still route support through another region, and that is the point this step exists to catch.
Step 2: build the destination map
For the specific service you are buying, record:
- Every country where data is stored.
- Every country from which data can be accessed, and by whom.
- Every sub-processor, its location, and its function.
- Whether backups and disaster recovery sit in the same regions as production.
Backups are the item most often missed. A service configured for EU-only production with recovery capacity elsewhere has a transfer that the architecture diagram does not show.
Step 3: identify the mechanism for each destination
Every destination needs a lawful route, and destinations can use different ones. Work through them in order:
- An adequacy decision under Article 45, where the European Commission has found the country, territory, or framework to provide adequate protection. Confirm it covers this entity and this data rather than assuming it covers the country as a whole.
- Appropriate safeguards under Article 46, most commonly the Standard Contractual Clauses adopted in Implementing Decision (EU) 2021/914, or binding corporate rules.
- A derogation under Article 49, which is narrow and designed for occasional, specific situations rather than routine service relationships.
If your answer for a routine vendor relationship is a derogation, revisit it. Article 49 is not a mechanism for ongoing operational transfers.
Step 4: check the Standard Contractual Clauses were used properly
Where the mechanism is the Standard Contractual Clauses, confirm the mechanics rather than the presence of the words:
- The correct module for the relationship, since controller-to-processor and processor-to-processor are different modules.
- The annexes completed with the actual parties, processing description, and technical and organizational measures, rather than left as placeholders.
- The correct docking or onward-transfer arrangement for sub-processors.
- Incorporation into the contract in a way that binds the right entities.
Empty annexes are common and are a real defect: the annexes are where the clauses acquire their content. Our article on Standard Contractual Clauses and sub-processors covers the module and onward-transfer detail.
Step 5: run the assessment where Article 46 applies
Where you rely on safeguards rather than adequacy, Clause 14 of the Standard Contractual Clauses requires the parties to warrant that they have no reason to believe the destination's laws prevent the importer from meeting its obligations. That assessment considers the specific circumstances of the transfer, the laws and practices of the destination, and any supplementary measures.
The European Data Protection Board's Recommendations 01/2020 on measures that supplement transfer tools remain the working reference for that analysis. Transfers covered by adequacy do not require it.
Step 6: record supplementary measures where you rely on them
If the assessment concludes that the destination's environment requires supplementation, record the specific measures and why they address the identified problem. Encryption where the importer holds no key, pseudonymization that the importer cannot reverse, and routing or storage restrictions are the measures most likely to be effective. Contractual assurances alone rarely resolve a legal-access concern.
Step 7: write the decision record
For each vendor, retain a record containing:
- The destination map, with dates.
- The mechanism relied on per destination.
- The assessment, where one was required, and its conclusion.
- Any supplementary measures and their rationale.
- The sub-processor list as captured on the assessment date.
- The decision, its owner, and the date.
- The review trigger and interval.
Capture the vendor's published disclosures rather than linking to them. The pages will change, and the version you relied on is the one you will need.
Step 8: define what invalidates the analysis
Transfer positions decay. Set the triggers in advance:
- A new sub-processor, particularly in a new country.
- A change of hosting region or a new access location.
- A change of transfer mechanism by the vendor.
- A change in the adequacy status of a destination.
- A material change in the data set being sent.
Our article on monitoring sub-processor changes covers detecting the first three, which are the ones that arrive without warning.
Frequently asked questions
Does EU hosting mean there is no transfer?
Not necessarily. Storage location and access location are separate questions, and remote administrative access from a third country is a transfer even where all storage stays in the European Economic Area.
Do we need an assessment for every destination?
Only where you rely on Article 46 safeguards. Destinations covered by an adequacy decision do not trigger the Clause 14 analysis, although you should still track whether the decision remains in force.
Who runs this, privacy or the vendor owner?
Privacy usually owns the analysis; the vendor owner supplies the facts. The failure mode is privacy guessing at the architecture rather than asking.
What about United Kingdom transfers?
Transfers from the United Kingdom use United Kingdom mechanisms: the International Data Transfer Agreement, or the European Union clauses with the United Kingdom Addendum, together with a United Kingdom transfer risk assessment. The Information Commissioner's Office publishes guidance on international transfers. Where a vendor serves both, run both.
Where DPAFlow fits in
Steps 7 and 8 are where transfer work usually decays: the record is written once and the facts move afterwards. DPAFlow checks vendor sub-processor lists, Data Processing Agreement pages, and trust-center pages on a scheduled, recurring basis, records what changed with dated evidence including captured page text and change differences, and sends email alerts when a change appears. Detected changes enter a review workflow where your team decides whether the transfer analysis needs revisiting.
DPAFlow does not perform the legal assessment and does not provide legal advice. The transfer assessment module is described on the transfer impact assessment page.
This is an operational checklist, not legal advice. The transfer conclusions belong to your privacy function and counsel.