Is remote access by a vendor's support team outside the EEA a transfer?

Yes. Under EDPB Guidelines 05/2021, making personal data available to another controller or processor located in a third country is a transfer, and remote access from a third country by another entity, such as a processor's support staff, falls within that. An employee of your own organisation accessing data while travelling abroad is not a transfer, because no other entity is involved, but it still requires appropriate security.

Do we still need a transfer impact assessment if we use standard contractual clauses?

Yes. Since the CJEU's Schrems II judgment (C-311/18, 16 July 2020), exporters relying on SCCs must assess, case by case, whether the law and practice of the third country allow the importer to comply with them, and adopt supplementary measures where needed, as described in EDPB Recommendations 01/2020.

Can encryption make a transfer to a problematic jurisdiction acceptable?

It can be an effective supplementary measure when the encryption is strong and the keys remain under the exporter's control in the EEA, so the importer never sees the data in the clear. The EDPB found no effective measure for cloud processing that requires access to data in the clear in a problematic jurisdiction.

International Data Transfers: A Technical GDPR Guide

For most IT teams, international transfers are not an abstract legal topic. They are a support engineer in another continent opening a session on your tenant, a log pipeline forwarding events to a SIEM region you never chose, or a backup replicated to a data centre outside the EEA. Chapter V of the GDPR (Articles 44 to 49) sets strict conditions on moving personal data out of the European Economic Area, and infringing them sits in the higher fine tier of Article 83(5): up to EUR 20 million or 4% of total worldwide annual turnover, whichever is higher. This guide explains the transfer mechanisms, how the Schrems II judgment changed the work, and which technical measures actually help.

What counts as a transfer

The GDPR does not define "transfer". The EDPB Guidelines 05/2021 on the interplay between Article 3 and Chapter V (final version, February 2023) set three cumulative criteria:

A controller or processor is subject to the GDPR for the given processing.
It discloses by transmission or otherwise makes personal data available to another controller or processor (the importer).
The importer is in a third country or is an international organisation, whether or not the importer itself is subject to the GDPR.

Two consequences are important for engineers. First, "makes available" covers remote access: if a processor's support staff in a third country can view your data, that is a transfer even if the data is never stored there. Second, the "another entity" criterion means that your own employee accessing company systems from a hotel abroad is not a transfer. It is still processing, and it still needs security controls, but it is not a Chapter V question.

Situation	Transfer under Chapter V?	Notes
Data hosted in an EU region of a cloud provider, no third-country access	No	Check the provider's support and sub-processor model
Vendor's follow-the-sun support in a third country can access tenant data	Yes	Remote access by another entity
Your employee on a business trip logs in from abroad	No	Same entity; still apply access security
Logs forwarded to a SIEM instance hosted outside the EEA	Yes	Logs contain personal data
Backup replicated to a third-country region	Yes	Storage by an importer in the third country

Article 44: the general principle

Article 44 states that any transfer may take place only if the conditions of Chapter V are complied with, including for onward transfers, so that the level of protection guaranteed by the GDPR is not undermined. In practice you need one of three routes: an adequacy decision, appropriate safeguards, or a derogation.

The transfer tools

Adequacy decisions (Article 45)

Where the Commission has decided that a third country ensures an adequate level of protection, transfers to it need no further specific authorisation. The UK, for example, has an EU adequacy decision. Always check the current list on the Commission's website, as decisions are reviewed and can change.

The EU-US Data Privacy Framework is a special case. The Commission adopted an adequacy decision on 10 July 2023, but it only covers US organisations that have self-certified under the DPF. Transfers to a US company that is not on the DPF list need another tool. The EU General Court dismissed an annulment action against the decision (Latombe v Commission, T-553/23) on 3 September 2025, but further challenges remain possible. Given that its predecessor, the Privacy Shield, was invalidated in Schrems II, keep a fallback such as SCCs in your contracts.

Appropriate safeguards (Article 46)

Without adequacy, Article 46 allows transfers subject to appropriate safeguards, provided enforceable rights and effective legal remedies are available to data subjects. The two you will meet most often are:

Standard data protection clauses adopted by the Commission (Article 46(2)(c)). The current standard contractual clauses are in Commission Implementing Decision (EU) 2021/914 of 4 June 2021 and come in four modules: controller to controller (C2C), controller to processor (C2P), processor to processor (P2P) and processor to controller (P2C).
Binding corporate rules (Article 46(2)(b) and Article 47), approved group-wide policies used by multinational groups for intra-group transfers.

Derogations (Article 49)

Article 49 lists derogations for specific situations: explicit consent, necessity for a contract, important reasons of public interest, legal claims, vital interests, and transfers from a public register, plus a limited fallback based on compelling legitimate interests. They are interpreted restrictively and suit occasional transfers. A recurring data flow to a SaaS platform should not be built on a derogation.

Article 48: foreign authority requests

Article 48 provides that a judgment or decision of a third-country court or authority requiring a transfer is recognised or enforceable only if based on an international agreement such as a mutual legal assistance treaty. Your contracts should require processors to notify you of such requests where legally permitted and to challenge disproportionate ones.

Schrems II and the transfer impact assessment

In C-311/18 "Schrems II" (16 July 2020), the CJEU invalidated the EU-US Privacy Shield and held that exporters relying on SCCs must assess, case by case, whether the third country's law and practice allow the importer to meet its obligations. This is what practitioners call a transfer impact assessment (TIA).

The EDPB Recommendations 01/2020 on supplementary measures (final version 2.0, June 2021) set out a roadmap:

Step	What to do	Who in IT helps
1. Know your transfers	Map every flow and remote access path to third countries	Architecture, network, vendor management
2. Identify the transfer tool	Adequacy, SCCs, BCRs or derogation	DPO and legal
3. Assess third-country law and practice	Can public authority access undermine the safeguards?	Legal, with input on data exposure
4. Adopt supplementary measures	Technical, contractual, organisational	Security engineering
5. Procedural steps	Formalities required by the chosen tool	Legal
6. Re-evaluate	Monitor developments at appropriate intervals	Everyone

Step 1 is where security teams contribute most. Data flow diagrams, egress logs, CASB discovery and your vendor register are the best sources for an accurate transfer inventory, which also feeds Article 30(1)(e) in your records of processing activities.

Supplementary technical measures that work

The EDPB recommendations give examples of technical measures that can be effective, and cases where no effective measure was found.

Effective, if implemented properly:

Strong encryption with keys under the exporter's control in the EEA. The data is transferred or stored encrypted, the algorithm and key length are robust against cryptanalysis, and the keys are held only by the exporter or an entity in the EEA. The importer never has the keys.
Pseudonymisation before transfer, where the additional information needed to re-identify people stays in the EEA and the importer cannot re-identify them with other data. See our guide on pseudonymisation vs encryption for keyed hashing and tokenisation patterns.

No effective measure found:

Cloud processing that requires access to data in the clear in a jurisdiction where public authority access goes beyond what is necessary and proportionate. If the provider must decrypt to deliver the service, encryption at rest with provider-managed keys does not solve the transfer problem.

In practice this means asking concrete questions: where are the keys generated and stored, who can use them, can the vendor's third-country staff trigger decryption, and is support access to cleartext possible?

A transfer register entry

Keep one entry per transfer flow. This makes TIAs reviewable and helps you answer supervisory authority questions under Article 5(2) accountability.

# Transfer register - one entry per data flow
id: TR-2026-014
processing_activity: "Customer support ticketing"
exporter: "Example Org (controller)"
importer:
  name: "Example Helpdesk SaaS - support subsidiary"
  role: processor
  country: "third country (non-adequate)"
transfer_type: remote_access        # storage | remote_access | onward_transfer
data_categories: ["name", "email", "ticket content"]
special_categories: false
data_subjects: ["customers"]
frequency: continuous
transfer_tool:
  mechanism: "SCCs - Decision (EU) 2021/914"
  module: "Module 2 (C2P)"
  signed: true
tia:
  completed: true
  date: "2026-06-10"
  conclusion: "Supplementary measures required"
supplementary_measures:
  technical:
    - "Attachments encrypted with EEA-held customer-managed keys"
    - "Support access to ticket bodies only via just-in-time approval by EU team"
    - "Customer identifiers pseudonymised in analytics exports"
  contractual:
    - "Notification of public authority requests where legally permitted"
  organisational:
    - "Access logs reviewed monthly"
fallback_if_tool_invalidated: "Suspend third-country support access; EU-only support tier"
review_due: "2027-06-10"
owner: "security-engineering"
dpo_reviewed: true

Practical checklist for IT and security

Inventory third-country access paths, not only storage locations: support, monitoring, CI/CD, backups, log forwarding.
Prefer EEA regions and EU-based support tiers where available, and enforce them in configuration.
Use customer-managed keys held in an EEA key management service or HSM where the use case allows it.
Pseudonymise before exporting data for analytics, testing or offshore development.
Require just-in-time, approved and logged support access instead of standing access.
Track sub-processor changes, since a new sub-processor can introduce a new transfer.
Keep a documented fallback for each flow that relies on an adequacy decision that could be challenged.

Scope of this guide

This article is technical guidance for security and IT teams on GDPR international transfers. It is not legal advice. The choice of transfer tool, the conclusion of any transfer impact assessment and the acceptance of residual risk must be confirmed with your data protection officer and legal counsel.