GDPR supplementary measures are safeguards added to an Article 46 transfer tool when the assessment of a particular international transfer shows that the tool does not provide the required protection on its own. They can be technical, contractual or organisational. Their value depends on whether they address the actual weakness identified; selecting several items from a catalogue does not by itself make a transfer lawful.
The European Data Protection Board’s final Recommendations 01/2020 explain this assessment and provide seven technical use cases. This guide maps those cases accurately, distinguishes adequacy from Article 46 safeguards, and explains what evidence a controller or processor should obtain before relying on encryption, pseudonymisation or a supplier’s contractual promises.
Start with the transfer, recipient and legal route
Map what data leave the relevant environment, who receives them, why, and whether onward recipients can access them. A transfer can involve disclosure or remote access rather than physical relocation of the main database. European hosting is therefore not conclusive where a separate overseas support company or group entity can retrieve personal data.
There must, however, be a separate recipient for the transfer concept described in the EDPB’s final Guidelines 05/2021. Its example of an employee travelling abroad and accessing their own employer’s database does not involve another controller or processor and is not a Chapter V transfer. Disclosure to a separate overseas group company can be one. The employee example still requires assessment of security and other GDPR risks; it is not an exemption from protecting the data.
Establish the parties’ actual roles using the distinction between controllers and processors. A corporate group is not automatically one legal recipient, and the importer may remain a separate recipient even where its processing is itself subject to the GDPR. The broader cross-border data transfer guide helps organise the flow map, including support access, subprocessors and onward transfers.
Next identify the Chapter V route. An applicable Article 45 adequacy decision differs from Article 46 safeguards such as standard contractual clauses or binding corporate rules. Article 49 derogations have specific conditions and should not be treated as a convenient general substitute for an ineffective ongoing arrangement. The comparison of BCRs, SCCs and the Data Privacy Framework helps separate those mechanisms; the assessment must then address the route actually used.
What adequacy changes, and what it leaves in place
The European Commission’s current adequacy list includes US commercial organisations participating in the EU–US Data Privacy Framework. This is a scoped adequacy route, not a finding that every US recipient is covered. Verify the exact receiving organisation, its participation and the relevant coverage before relying on it, and retain evidence of that verification.
For a transfer within an applicable adequacy decision, Article 46 supplementary safeguards are not required as the basis for that transfer. The remaining GDPR duties still apply, including purpose limitation, minimisation, appropriate security and the relevant controller–processor requirements. Encryption may therefore remain necessary under Article 32 even though it is not needed to repair an Article 46 transfer tool.
If adequacy does not cover the recipient or processing, identify another available lawful route and assess its conditions. Do not assume that every uncovered transfer automatically requires the same measures or that every transfer to a country without adequacy is forbidden. The legal mechanism and the actual processing circumstances determine the analysis. Check current decision status and scope when making or reviewing the decision rather than relying on an old country list.
Apply the six steps to a defined processing arrangement
The final EDPB Recommendations 01/2020, adopted on 18 June 2021, organise the work into six stages: understand transfers, identify the transfer tool, assess relevant law and practice, adopt effective supplementary measures where needed, complete the applicable procedural steps and reassess the arrangement.
The assessment concerns the law and practice relevant to the particular data, importer, purposes and access pathways. Identify whether public-authority powers can undermine the safeguards and whether the identified concerns apply to this transfer. A general statement that a country has surveillance legislation, or that the supplier has never received a request, is not a substitute for that analysis. Use reliable, relevant and verifiable evidence and record its limitations.
The transfer impact assessment guide addresses the wider assessment process. Here the practical task is to connect each identified weakness to a measure that changes the outcome. If the problem is access to intelligible data by an importer subject to problematic disclosure powers, encryption that the importer can reverse may improve ordinary security while leaving that specific problem unresolved.
Use case 1: encrypted storage without access in the clear
The first EDPB use case concerns storage with a third-country hosting provider, for example a backup, where the provider does not need intelligible data. Strong encryption occurs before transmission. The algorithm, parameters, implementation and maintenance must be appropriate, including against the capabilities of the public authorities concerned and for the entire period during which confidentiality matters.
Key management is central. The EDPB requires keys to remain solely under the exporter’s control, or with an entity trusted by the exporter in the EEA or a jurisdiction offering an essentially equivalent level of protection. “Keys must always stay in the EU” is an inaccurate shortcut: the EEA and protection standard matter, together with effective control, not a geographic label alone.
For a backup service, examine who can obtain the keys, change permissions or trigger recovery. Verify whether support processes, recovery credentials or a managed key service provide another route to plaintext. Evidence should address the configuration actually deployed, not simply a product statement that encryption is available. The conclusion also depends on preventing unintended exposure in temporary files, logs and associated copies.
Use case 2: pseudonymisation that resists re-identification
The second case concerns data pseudonymised before transfer, for example for analysis. The exporter retains exclusive control over the additional information needed to reconnect the data to individuals, with the separation and safeguards described by the recommendations. The assessment must establish that the receiving country’s authorities cannot attribute the transferred data to identifiable people using other information they can reasonably be expected to possess and use.
Removing names is not enough. Precise locations, unusual combinations of characteristics or detailed activity sequences can reveal identity or single out a person. An importer that can request arbitrary re-identification from the exporter may also defeat the proposed separation. Examine the full workflow, including queries, outputs and support arrangements, instead of assessing only the initial file.
This use case concerns a transfer of pseudonymised personal data, not a claim that every coded dataset has become anonymous. Document the transformation, the separate information, access permissions and the analysis of possible linkage. A useful privacy by design approach starts by reducing what the recipient needs: aggregated or less granular information may satisfy the purpose with less exposure, provided the resulting identification risk is properly assessed.
Use case 3: protection while data are in transit
The third case concerns public-authority access during transmission between the exporter and importer. State-of-the-art transport encryption, trustworthy authentication infrastructure, protected endpoints and reliable key management can address that access pathway. The EDPB also addresses circumstances requiring additional end-to-end protection at the application layer where transport security alone is insufficient.
Its conclusion is limited to the threat being assessed. Protecting traffic while it crosses a network does not prevent the intended recipient from reading it after decryption. If the destination authority can compel that recipient to disclose plaintext, a secure connection does not by itself answer the separate disclosure concern. Treat transit protection and protection against recipient-side access as different parts of the architecture.
For implementation evidence, identify where encryption begins and ends, who authenticates each endpoint and whether intermediaries terminate the connection. Check temporary routing or support arrangements that bypass the expected path. A diagram can be useful, but the assurance comes from verified configuration and operation rather than the presence of a padlock icon in a supplier presentation.
Use case 4: a recipient specifically protected by local law
The fourth case is a protected recipient, such as a medical or legal professional whose relevant data are shielded from the problematic access under the receiving country’s law. It is not the catalogue’s example of an unprotected cloud service. The legal exemption must cover the particular information and purpose, including credentials or keys that could otherwise circumvent the protection.
The conditions also address onward processing. The importer must not expose the data through an unprotected processor or onward recipient. End-to-end encryption, controlled keys and reliable verification of the intended recipient form part of the EDPB scenario. Merely describing a recipient as a lawyer or doctor does not establish that all the conditions hold.
Evidence should therefore include the relevant local protection and its limits, the purpose for which the recipient receives the data, and the technical path used. Examine whether a cloud intermediary can access the information before relying on the professional’s protection. A national confidentiality obligation and a general contractual nondisclosure clause are not interchangeable safeguards.
Use case 5: split or multi-party processing
The fifth case involves dividing information between independent processors in different jurisdictions so that no individual part permits reconstruction or attribution to a person. The processors may perform secure multi-party computation, with the exporter combining the returned results. The design must avoid revealing additional information to a participant and use methods secure against the relevant active adversaries.
The analysis extends beyond the split itself. The EDPB requires assessment of other information the authorities may hold and of possible collaboration or powers allowing access across the relevant jurisdictions. If one authority can obtain all the pieces, the proposed separation may not protect against the identified threat. Sending duplicate complete files to two suppliers is plainly not this scenario.
This arrangement requires technical and legal expertise. Before treating it as a procurement option, establish that the processing purpose can be achieved with the split data, that outputs do not reverse the protection and that the independence assumptions are justified. Document the dependencies so a later change of ownership, subcontractor or processing location triggers a review of the conclusion.
Use cases 6 and 7: when access in the clear remains necessary
Use case 6 concerns a cloud provider or other processor that needs access to intelligible personal data to perform its task. Use case 7 concerns transfers for shared business purposes, including remote access by a separate third-country entity, where intelligible data are needed. Both scenarios assume that problematic third-country powers apply in practice to the transfers and exceed what is necessary and proportionate.
Under those stated conditions, the EDPB did not identify an effective technical measure, at the state of the art considered in the recommendations, that prevents the problematic access while retaining the required access in the clear. Transport encryption combined with encryption at rest does not solve that problem when the importer possesses the keys. A system can have strong encryption against outsiders while still making its contents available to the importer.
These conclusions are not a declaration that every service from a particular country is unlawful, nor that future technical developments can never change an assessment. The recommendations expressly recognise possible developments for case 6. A claimed new solution must nevertheless demonstrate the protection required in the actual environment. Terms such as confidential computing or customer-managed keys do not establish effectiveness without examining plaintext access, control paths and the relevant legal powers.
Consider a support arrangement in which a separate overseas entity opens customer records to diagnose problems. Limiting its access to specific records and short periods may reduce exposure. It does not by itself remove the disclosure issue for records it can read. Redesigning the task so support works on synthetic or appropriately protected data may change the analysis; documenting the original exposure without addressing it does not.
Contractual measures should reinforce a workable arrangement
Additional clauses can require implementation of specified technical safeguards, relevant transparency about government requests, cooperation with the exporter’s assessment and notification of changes affecting protection. They can also define procedures for assessing requests and seeking available remedies. Compare proposed additions with obligations already present in the transfer tool so that the contract remains clear and internally consistent.
Contractual promises generally cannot bind a third-country public authority that is not a party to the agreement. Where the identified problem is a legal obligation to disclose accessible data, an importer cannot neutralise that obligation simply by promising the exporter that it will not comply. The EDPB explains that contractual and organisational measures alone will generally not overcome access based on problematic law or practice.
That does not mean contracts have no purpose or that only one type of technical measure can ever be effective. The combination must fit the specific circumstances. The standard contractual clauses guide helps distinguish the transfer tool from additional safeguards. Supplementary clauses must not contradict the SCCs or restrict their rights and obligations. Adding compatible protections does not itself require supervisory authorisation; replacing the standard safeguards with bespoke clauses engages the applicable Article 46 procedure.
Organisational measures make the controls operable
Assign responsibility for government requests, legal analysis, security changes and escalation to the exporter. Train the relevant staff to recognise requests that need specialist review and to preserve the information required to make a decision. Establish how legally restricted notifications and incomplete information will be handled; a promise of unconditional transparency can be impossible to perform under the relevant law.
Restrict access by role and purpose, remove information unnecessary for the task and review permissions against actual use. Keep relevant evidence of requests and responses subject to applicable legal restrictions, and assess what an inability to provide information means for the transfer. An audit trail supports accountability, but logging a disclosure does not prevent it or establish that it was lawful.
For procurement, request evidence corresponding to the proposed control: key-control documentation for encryption, linkage analysis for pseudonymisation or the protected-recipient legal basis for case 4. Generic certifications can inform the assessment within their scope, but they do not decide whether the specific transfer has an essentially equivalent level of protection.
Record a decision, review its assumptions and stop where necessary
The GDPR accountability principle requires more than a completed form. Retain the transfer description, legal route, relevant law-and-practice assessment, chosen safeguards, implementation evidence, unresolved limits and the reason for the resulting decision. Link these materials in the evidence file used for a GDPR compliance audit, with owners who can explain both the legal and technical parts.
Monitor developments that could change the conclusion. Examples include a new recipient, a changed support location, access to keys, a revised purpose or a relevant legal development. Set review arrangements appropriate to the transfer and respond to material changes; the recommendations do not create a universal annual review deadline. Similar transfers may use a documented common assessment where the assumptions actually remain the same.
If effective supplementary measures cannot be identified or implemented for an Article 46 arrangement that needs them, do not start the transfer. Suspend or end an existing transfer and apply the relevant tool’s provisions concerning already transferred data and copies. An internal acceptance of commercial risk cannot lower the protection required by Article 44 and the transfer framework. The decision must connect the required protection to evidence that the chosen arrangement can deliver it.