International data transfers under GDPR: why signing the SCCs is not the approval (2026)

Procurement asks: “The cloud vendor has signed the SCCs. Can we approve the transfer?”

Not yet. The signature answers one question: whether the parties have selected and accepted contractual safeguards. It does not show where the data actually goes, who can reach it, whether the destination’s law lets the importer honour its promises, or whether another control closes the gap. Under GDPR Article 44, a transfer under Chapter V must preserve the level of protection guaranteed by the Regulation. 1

That is the practical concept to keep in view: an international-transfer approval is a chain of decisions. Standard Contractual Clauses (SCCs) can be an important link, but they are not the chain’s conclusion.

The three routes are not interchangeable

Start by separating the legal route from the review method. Adequacy, an Article 46 safeguard, and an Article 49 derogation are different ways to support a transfer. A transfer risk assessment is the method used to test whether the chosen route works for the actual flow; it is not a transfer mechanism in its own right.

Route or mechanism	What it does	What the reviewer still has to check	Workplace boundary
Adequacy decision — Article 45	The European Commission recognises that a third country, territory, specified sector, or international organisation provides an adequate level of protection for the scope covered.	Whether the decision covers this destination, recipient, data and purpose; whether it remains valid; and whether the rest of the GDPR is satisfied.	“The vendor is based in an adequate country” is not enough if a subprocessor, support team, or onward recipient sits outside the decision’s scope.
Appropriate safeguards — Article 46	The exporter uses a safeguard such as SCCs, binding corporate rules, an approved code with binding commitments, certification with binding commitments, or authorised ad hoc clauses.	Whether the safeguard is correctly selected and documented, and whether destination law and practice leave it effective for this particular transfer. Supplementary measures may be necessary.	“The SCC module is signed” identifies the contractual layer. It does not finish the destination-law or access-path analysis.
Derogation — Article 49	A specific exception can permit a transfer in defined circumstances, such as a genuinely necessary contract-related transfer or explicit consent, subject to the conditions for that derogation.	Whether the narrow conditions really apply and whether the transfer is specific and non-routine rather than a standing way to run a service.	A recurring vendor export should not be relabelled as an exception simply because no one wants to complete the Article 46 analysis.

The Commission describes the modernised SCCs as pre-approved model clauses for covered transfers from EU/EEA exporters to controllers or processors outside the EU/EEA that are not subject to the GDPR for the relevant processing. That explains what the document is. It does not turn the document into a finding about the destination’s public authorities or every technical path the service may use. 2

Run the six-check transfer screen

The EDPB’s recommendations give practitioners a usable sequence. The order matters: a reviewer who starts with a signed form can miss the flow that the form was supposed to govern. 3

Check	Question	Evidence or output	Decision consequence
1. Know the transfer	What data is sent or made accessible, by whom, to whom, for what purpose, and through which system?	A flow map covering cloud processing, remote access, support access, subprocessors, and onward transfers.	If the map is incomplete, the approval is not ready.
2. Identify the route	Is the flow supported by an adequacy decision, an Article 46 safeguard, or a specific Article 49 derogation?	The route, scope, SCC module or other instrument, parties, and required formalities.	If the proposed route does not cover the flow, select another route or redesign the flow.
3. Test destination law and practice	Could the destination’s laws or practices prevent the importer from meeting the chosen safeguard, or expose the data to access that the safeguard cannot control?	A transfer-specific assessment using relevant law, practice, recipient information, and the characteristics of the flow.	If the safeguard is not effective for this flow, identify a supplementary measure or do not proceed.
4. Add effective supplementary measures	What technical, contractual, or organisational measure addresses the demonstrated gap, and where is it enforced?	A control-to-threat explanation: for example, who controls the keys, who can see plaintext, and what happens during support.	A measure that does not block the relevant access path is not a completed mitigation.
5. Complete the procedure	Have the required documentation, authorisations, contractual steps, and internal records been completed?	Signed instrument, approvals, records of analysis, instructions, and conditions of use.	A technically plausible design can still be procedurally incomplete.
6. Re-evaluate	What could change the answer, and when will the review happen?	An owner, date, review interval, and triggers such as a new subprocessor, architecture change, legal change, or new access route.	Treat approval as conditional and reviewable, not permanent.

The EDPB’s conclusion is deliberately operational: if the exporter cannot find effective supplementary measures, the transfer must be avoided, suspended, or terminated. 3

Test the measure against the access path

The most useful question is not “Do we use encryption?” It is “Which actor can obtain usable data through which path, and what exactly stops that path?”

Consider three common designs:

Storage in one country, support access from another. The database may remain in an EU data centre while a support engineer or administrator in a third country can view records, run queries, or retrieve logs. The storage location does not describe the whole transfer. The access path belongs in the map.
Encryption with keys controlled outside the service. If the provider never receives usable keys and the design keeps the data unintelligible to the provider, encryption may address a particular access risk. The reviewer still has to test key custody, recovery, search, support, backups, metadata, and whether any part of the service requires plaintext.
A service that needs plaintext. Encryption at rest may protect disks but do little against a provider that must read the content to index it, moderate it, troubleshoot it, or generate a response. In that design, the control does not answer the access path merely because the word “encrypted” appears in the security description.

The same discipline applies to pseudonymisation, tokenisation, split processing, strict access controls, and contractual commitments. These are possible measures, not universal cures. Their value depends on the data, the importer’s role, the destination’s law and practice, the technical architecture, and whether the measure remains enforceable when access is compelled. The EDPB treats supplementary measures as case-specific and allows combinations of technical, contractual, and organisational measures; the analysis must test their effectiveness against the actual transfer. 3

This is also where procurement, engineering, and legal review often talk past one another. Procurement sees a signed contract that creates obligations. Engineering sees a design that can reduce exposure. Legal review asks whether the importer can still perform those obligations and whether people retain effective protection if a public authority or another actor seeks access. All three observations can be true. The decision turns on the connection between the threat, the control, and the point at which the control is actually enforced.

Common failure modes

Treating the signature as the approval

Mistake: The parties sign the SCCs and the ticket is closed.

Correction: Record the SCCs as the selected Article 46 tool, then complete the flow and destination-law analysis. The contract binds the parties. It does not bind a public authority that is not a party to it.

Reviewing the vendor headquarters instead of the flow

Mistake: The assessment names the supplier’s main country and stops there.

Correction: Trace hosting, remote administration, support, subprocessors, backups, logging, and onward transfers. A service can have several actors and several destinations.

Confusing an EU storage region with no international transfer

Mistake: The vendor says the primary region is in the EU, so the reviewer does not ask who can access the data from elsewhere.

Correction: Test access as well as storage. Remote access, troubleshooting, and onward support can change the transfer analysis.

Using Article 49 as a standing vendor workaround

Mistake: A recurring export is justified by a broad reference to necessity, consent, or the absence of another convenient route.

Correction: Test the exact derogation and its conditions. If the service is a regular operational arrangement, return to the ordinary transfer routes instead of turning an exception into infrastructure.

Recording a control without its boundary

Mistake: The record says “encryption, access controls, and contractual protections” without naming the actor or access path each measure blocks.

Correction: For every measure, state who controls it, what data remains usable, what event activates it, and what evidence shows that it works in this architecture.

Approving once and forgetting the change triggers

Mistake: The assessment is treated as a one-time vendor questionnaire.

Correction: Set a re-review trigger. A new subprocessor, new support model, new data type, architecture change, destination-law development, or change in key control can change the answer even when the SCC text has not changed.

The reviewer record

A defensible transfer decision should let another reviewer reconstruct the reasoning without reopening the entire procurement file. The record should contain:

Purpose and context: the processing purpose, lawful basis, business function, and why the transfer is needed.
Data and people: categories, sensitivity, volume where material, data-subject groups, and whether the data is stored, viewed, queried, or exported.
Actors and destinations: exporter, importer, processors, subprocessors, support teams, backup locations, remote-access locations, and onward recipients.
Route: adequacy decision and covered scope, or Article 46 instrument and applicable SCC module; if Article 49 is proposed, the exact derogation and its conditions.
Destination analysis: the relevant law and practice, the sources and recipient information used, and why they matter to this specific flow.
Controls: each supplementary measure, the threat it addresses, its enforcement point, residual access, and the evidence that supports its effectiveness.
Outcome and governance: approval conditions, unresolved uncertainty, owner, date, review interval, and change triggers that require the assessment to be reopened.

The operational standard is simple: treat the SCC signature as the start of the transfer decision, not its conclusion. Know the flow, select the route, test the destination against the real access paths, add measures that work against the demonstrated gap, and stop when the protection cannot be maintained.

References

1
GDPR, Chapter V (Articles 44–49)
eur-lex.europa.eu
2
European Commission: Standard Contractual Clauses
commission.europa.eu
3
EDPB Recommendations 01/2020 on supplementary measures
edpb.europa.eu