ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
Encryption in a TIA is the supplementary measure most teams reach for first, and the one most often misjudged. Encryption can be a genuinely strong safeguard when the recipient country cannot reach the data in readable form, but it does very little if the importer needs the data in the clear or if someone in that country holds the keys. The whole assessment turns on those two facts.
This guide explains when encryption works as a supplementary measure, who should hold the keys, which use cases fall short, how to document your reasoning and how to keep the assessment current. It is general information, not legal advice, and you should check the current version of the guidance for your regime.
A transfer impact assessment asks whether the law and practice of the destination country would undermine the protection promised by the transfer tool, such as standard contractual clauses. If it would, the exporter must add supplementary measures, and technical measures are usually the most effective, because they work even if a contract or policy is ignored.
Encryption is attractive because it can make the data unreadable to anyone without the key. That is why the European Data Protection Board discusses it prominently in EDPB Recommendations 01/2020 on supplementary measures. But the value of encryption in a TIA depends entirely on how it is applied, and a badly designed scheme gives a false sense of security.
First: does the importer need to see the data in the clear to provide the service? If the importer only stores or forwards the data, strong encryption may fully protect it. If the importer must process it in readable form, such as a support agent reading tickets or an analytics service reading records, encryption at rest does not stop access requests at the point of use.
Second: who controls the keys? If keys are held by you, or by a party in a jurisdiction with adequate protection, and the importer never has them, foreign authorities cannot obtain readable data from the importer. If the importer or its affiliates hold the keys, they can be compelled to hand them over or to decrypt. Record the answers to both questions in the assessment.
Free transfer impact assessment
Can this transfer of personal data go ahead?
Check whether the transfer needs a TIA, map it, assess the laws and practice of the destination, rate the risks from 27 transfer scenarios and choose supplementary measures. Covers the EU SCCs and the UK IDTA and Addendum, free.
Encryption is most effective for storage and transit use cases. Examples include backups stored with a foreign provider, archives, and data moving through a foreign network on its way back to your region. In each case the importer does not need readable data, and you keep control of the keys.
To qualify, the algorithm and key management must be robust and up to date, the implementation must be correct and the keys must be under the exporter’s control or that of a trustworthy entity in an adequate jurisdiction. Note the residual risks, such as metadata that remains visible, and assess whether they matter.
| Scenario | Does encryption help? | Why |
|---|---|---|
| Backup or archive stored abroad, keys held in your region | Yes, usually | Importer cannot read the data |
| Transit only, decryption in your region | Yes, usually | Data unreadable in the third country |
| Cloud service that must process data in the clear abroad | Limited | Importer sees plaintext, so access laws still apply |
| Encryption with keys held by the importer | Limited | Authorities can compel the importer to decrypt |
| Pseudonymised data, with the mapping table kept in your region | Often yes | Data cannot be attributed without the extra information |
Many cloud and SaaS arrangements require the provider to process data in readable form. In those cases, encryption at rest with provider-held keys does not prevent access under foreign law, because the provider can decrypt on demand. The EDPB has said it cannot envisage an effective technical measure in some of these cases where the importer needs the data in the clear and the legal powers go beyond what is necessary and proportionate, so check the current text for your regime.
If encryption cannot solve the problem, consider other measures such as pseudonymisation, splitting data across providers, keeping the processing in your region, or choosing a different provider. If nothing works, you may need to suspend the transfer. See supplementary measures for data transfers for the wider list.
The strongest design keeps keys in a system under your control, such as your own hardware security module or a key management service in your region, with strict access rules. Customer-managed keys offered by cloud providers help only if the provider cannot access them without your action, and if the design is technically sound.
Ask suppliers who can reach the keys, how access is logged, what happens on a legal demand and whether you would be notified. Include commitments in the contract, such as an obligation to challenge disproportionate requests and to tell you about them where the law allows. Our guides to TIAs for cloud services and TIAs for sub-processors explain what to ask.
Pseudonymisation replaces direct identifiers with codes, with the mapping stored separately. If the importer cannot link the data back to individuals without information that only you hold, and the data cannot be attributed by other means, the risk from access can fall considerably. This works well for analytics and research where names are not needed.
Test whether the data is really unattributable. Rich datasets can be re-identified from other sources, so consider all the information an authority might combine. Document the analysis, and combine pseudonymisation with encryption where possible.
A good record for encryption in a TIA states the transfer, the destination law concerns, the encryption design, the key holders, the residual risks and the conclusion. Include evidence such as architecture diagrams, key management policies and supplier statements. Keep the record with the wider assessment, compare it with the third-country law analysis, as in the transfer impact assessment example.
Explain why you consider the measure effective in the specific context, and note any assumptions. If the reasoning depends on a supplier’s claim, seek proof or contractual commitment. Regulators will read the reasoning, not just the conclusion.
Encryption is not a one-off decision. Algorithms age, keys are rotated, systems change and laws evolve. Review the measure at least annually, and whenever the supplier changes its architecture, the destination country changes its legal framework or an incident reveals a weakness.
Track indicators such as key access logs, incident reports and supplier changes. Keep the TIA up to date so that it matches the real system. Our page on the Data Privacy Framework and TIAs explains how adequacy developments interact with your assessment.
Frequent errors include assuming encryption solves every problem, ignoring who holds the keys, relying on encryption in transit alone when the importer processes plaintext, accepting supplier marketing claims without evidence, forgetting metadata and never revisiting the assessment. Another is using encryption to justify transfers to a provider that must in practice read the data.
Avoid these by working through the two deciding questions for each transfer, checking the design with security specialists and recording the answers.
Assessing encryption in a TIA is not only a legal task. Ask security engineers to confirm the design, the algorithms and the key management, and ask legal counsel to interpret the destination country’s law. Hold a short joint review, record who attended and what was decided, and have the accountable owner sign off the conclusion. This shared review catches gaps that either group would miss alone and gives you a defensible record if a regulator asks how the decision was reached.
Where the design is complex, consider an independent technical review or penetration test of the key management. The cost is small compared with the risk of relying on a control that does not work as assumed.
A European company backs up its databases to a provider in a third country. The provider only stores encrypted files, and the company generates and holds the keys in its own region using strong, current algorithms. The TIA concludes that access requests in the destination country would yield only unreadable data, and it records the design, evidence and review date.
The same company also considers using that provider’s analytics tool on customer records. Because the tool needs plaintext, encryption does not solve the problem, so it keeps analytics in its own region. The two decisions show why the analysis is specific to each use.
If you want a report and workbook that carry the transfer description, legal analysis, supplementary measures and decision together, the Transfer Impact Assessment Report and Workbook provides a structured layout for transfer impact assessments. Whatever the format, sound analysis of encryption in a TIA asks who can read the data, who holds the keys and how you know.
No. It helps when the importer cannot read the data and does not hold the keys. If the importer needs plaintext, or holds the keys, encryption offers limited protection.
Ideally the exporter or a trusted party in a jurisdiction with adequate protection, with the importer having no access to the keys.
Only if the data is decrypted back in your region. If the importer processes readable data abroad, transit encryption does not prevent access under local law.
It can complement it. Pseudonymisation works if the importer cannot link data to individuals without information you hold and re-identification is not feasible.
At least annually and whenever architecture, suppliers or the destination country’s legal framework change.
September 30, 2026
