Transfer Impact Assessment for Cloud Services Guide 2026

A transfer impact assessment for cloud services examines whether personal data placed with a cloud provider will receive essentially equivalent protection when it can be reached from outside the European Economic Area. Storing data in a European region does not settle the question. Support staff, engineers, sub-processors and parent companies elsewhere may be able to see it, and each such access is potentially a transfer. This guide explains how to carry out a transfer impact assessment for cloud services: mapping where data is stored and accessed, identifying the transfer tool, assessing the destination law, using encryption and key control, asking the provider the right questions, and recording the outcome.

Why a transfer impact assessment for cloud services is different

Cloud arrangements differ from a simple export of a file. The provider operates a service that may be hosted in one place, supported from several others, and built on sub-processors. The GDPR treats remote access from a third country as a transfer, so a European hosting region combined with support from the United States or India creates transfers that must be covered by a Chapter V mechanism and assessed. The Court of Justice’s Schrems II judgment requires that, where standard contractual clauses are used, the exporter check whether the law and practice of the destination allow the clauses to be honored, and the 2021 clauses require the assessment to be documented.

Our guide to the transfer impact assessment template gives the general structure. This article adds the points that are specific to cloud services.

Map the data and the access paths

Start by establishing facts from the provider’s documentation and contract. You need to know the following.

1. Storage location. Which regions hold the primary data, backups, logs and replicas.
2. Processing location. Where the data is processed, including analytics, machine learning and support tooling.
3. Access by provider staff. Who can reach customer data, from where, under what approval and with what logging.
4. Sub-processors. Their names, locations and roles.
5. Corporate structure. Whether the provider or its parent is subject to laws that allow access to data held abroad.
6. Metadata and telemetry. What data about your use flows to the provider, and where it goes.

Take special care with support access. Many outages are fixed by engineers in other regions who need temporary access to customer environments. Ask whether follow-the-sun support is used, and whether access can be restricted to the EEA.

Transfer tool in a transfer impact assessment for cloud services

For each transfer, record the Chapter V mechanism: an adequacy decision, standard contractual clauses, binding corporate rules or, exceptionally, a derogation. Where the provider is certified under the EU-US Data Privacy Framework and the data is within the scope of its certification, the adequacy decision adopted in July 2023 may cover transfers to it. Confirm the certification for the relevant data type and check the current legal status of the framework before relying on it. Our guide on the Data Privacy Framework and TIAs explains the position. Where the provider is not covered, the standard clauses will usually be the tool, and the parties must complete the annexes accurately, including sub-processors and security measures.

Check that the contract and the reality match

Cloud contracts are often standard forms with a data processing addendum. Check that the addendum incorporates the clauses in the right module, lists the sub-processors, obliges the provider to notify you of access requests and to challenge unlawful ones, and lets you object to changes of sub-processors. Compare it with what the provider’s documentation says about locations and access.

Assessing the destination law for a cloud provider

For each destination country from which data can be accessed, assess whether laws allow public authorities to demand access to data held by the provider, and whether there are safeguards, oversight and remedies. Our guide to assessing third-country laws explains how to research and record this. Consider practice as well as law, for example the provider’s transparency reports on government requests, and its stated approach to challenging them. Note that a large provider may face requests in several countries, so the assessment may need to cover more than one destination.

Encryption and key control as supplementary measures

Where the destination law falls short, supplementary measures may close the gap. In its Recommendations 01/2020 on supplementary measures, the European Data Protection Board considered cloud scenarios in its use cases. It found that strong encryption, where the exporter keeps the keys under its exclusive control in the EEA or an adequate country and the provider cannot access the data in the clear, can be an effective measure. It also found that where a cloud provider needs access to the data in the clear to deliver the service, it could not envisage an effective technical measure if the local law gives authorities powers going beyond what is necessary and proportionate. You can read the recommendations on the EDPB website.

Cloud use	Provider needs data in the clear?	Key measure
Backup or archive storage	No	Strong client-side encryption, keys held by you
Infrastructure hosting of your own application	Generally no, subject to design	Customer-managed keys, confidential computing where available, access controls
Software-as-a-service processing personal data	Yes	Regional hosting, access limits, contractual commitments, careful assessment
Collaboration and analytics tools	Yes	Data minimization, pseudonymization, choice of provider and region

Customer-managed keys, held in a key service you control and separate from the provider’s administrators, are a common way to reduce risk, but they are not a complete answer if the provider can still decrypt data during processing. See our guide to supplementary measures for data transfers for a fuller treatment.

Questions to ask the cloud provider

Send a written questionnaire and keep the answers. Ask where data, backups and logs are stored, who can access customer data and from which countries, how access is approved and logged, whether customer-managed keys are available and what they protect, what the provider does on receiving a government access request, whether it publishes transparency reports, which sub-processors exist and how changes are notified, and whether the provider can commit to restricting support access to the EEA. Where answers are vague, record that and consider whether the transfer can proceed.

For the wider rules on moving personal data abroad, see our guide to international data transfers.

A short worked example

A company moves its customer relationship data to a software-as-a-service provider hosted in an EU region. The provider’s support team is in two other countries and can access customer data on request. The provider is certified under the Data Privacy Framework for non-human-resources data, which covers the customer data. The company records the framework as the tool for the United States support access, standard clauses for the third country with no adequacy decision, assesses the law of that second country, and finds broad government access powers with limited redress. It concludes that the risk is not acceptable for support access from that country, negotiates a commitment that support for its tenant be provided only from the EEA and the United States, and records the conclusion, the measures and a review date in twelve months.

Recording a transfer impact assessment for cloud services

Record the facts, the tool, the legal analysis, the measures and the conclusion, in the same structure as your other assessments, and keep the provider’s answers with the file. Set triggers for review: a new sub-processor, a change of hosting or support location, a court ruling, the end or challenge of an adequacy decision, a government access request and a change of ownership of the provider. Our transfer impact assessment example shows a completed record.

Common mistakes in a transfer impact assessment for cloud services

Teams assume an EU region means no transfer, ignore support access, rely on the provider’s generic statements, forget metadata and logs, treat a certification as covering all data types, apply encryption that does not protect against the actual threat and fail to review after sub-processor changes. Another mistake is assessing each cloud service in isolation without seeing that many run on the same underlying provider, which concentrates exposure.

Using a ready structure

If you want to avoid building the forms from scratch, the Transfer Impact Assessment Report and Workbook provides a structured report, scoring and a working register into which cloud-specific questions can be added. Whichever tool you use, a transfer impact assessment for cloud services should rest on verified facts about locations and access, not on the region shown on the invoice.

Transfer impact assessment for cloud services FAQ

Does hosting in the EU avoid the need for a transfer impact assessment?

Not necessarily. Access from a third country by support staff, affiliates or sub-processors can be a transfer, so you must map access as well as storage.

Is encryption enough to protect cloud transfers?

It can be effective when you hold the keys and the provider does not need the data in the clear. It is much less effective when the provider must process the data unencrypted.

Can I rely on the provider’s Data Privacy Framework certification?

Possibly, for data within the scope of its certification. Check the certification for your data type and the current status of the framework before relying on it.

What should I ask the provider?

Ask about storage and processing locations, access by staff and affiliates, key management, handling of government requests, transparency reporting and sub-processors, and keep the written answers.

How often should the assessment be reviewed?

Review it at planned intervals and when triggers occur, such as new sub-processors, changes of hosting or support locations, legal changes or a government access request.