What Recommendations 01/2020 asks exporters to prove about supplementary measures
An Article 46 tool alone does not prove a transfer is safe. Once an exporter relies on standard contractual clauses or binding corporate rules, the EDPB's Recommendations 01/2020 (version 2.0, adopted 18 June 2021) expect a documented walk through six steps: know your transfers, verify the transfer tool, assess third-country law and practice, adopt supplementary measures, take any formal procedural steps, and re-evaluate at appropriate intervals. The file you produce is the evidence. An assessor will ask for the transfer map, the assessment of the destination's law, the measures chosen, and the dates on which each was reviewed. Read the EDPB Recommendations 01/2020 itself before scoping this work.
Supplementary measures are needed only where the assessment shows that third-country law or practice impinges on the effectiveness of the tool you rely on. That conditional matters. Many transfers end at step three with a reasoned conclusion that no extra measure is required, and the record of that conclusion is as important as any control. The hard part is usually the legal assessment and the access design, not the cipher. Someone must establish which public authority powers apply to the importer, whether they are necessary and proportionate, and who in practice can read the data. Encryption helps only when the keys sit with the exporter or a trusted entity in the EEA or an equivalent jurisdiction and the importer never needs the data in the clear.
Effort and cost follow from a few drivers: the number of transfers and importers, how many of them need access in the clear (such as support or analytics), how often third-country law changes, and whether counsel must review each assessment. Ask any implementation partner or auditor to state which parts are one-time (the initial mapping and assessment) and which recur (monitoring and re-evaluation), and to confirm who signs the assessment. The exporter owns that decision. Outside help can prepare the transfer register, key architecture and evidence, but the legal conclusion must come from the controller's own counsel or the supervisory authority.
Which transfers and systems the Recommendations 01/2020 method covers
Before any assessment starts, a few scoping decisions determine how much work the six-step method involves. Each card below is one decision, what it changes, and what to check, so that the transfer register and assessments cover the right flows.
Whether a data flow is a transfer
A transfer under Chapter V requires that personal data be sent or made accessible to a recipient in a third country, and that the exporter is subject to the GDPR for that processing. Storage on infrastructure you control inside the EEA, with no third-party access, is usually not a transfer. Remote access from outside the EEA, a backup replicated abroad or a vendor support session can be. Confirm each flow against the definition before scoping assessments, since a wrong answer either wastes effort or leaves a gap.
Which Article 46 tool is relied on
The assessment of third-country law is tied to the transfer tool you rely on. Standard contractual clauses, binding corporate rules and other Article 46 safeguards each require a documented assessment of the destination, while an adequacy decision removes the need for one. Record the tool per flow, including its version and the module used, so the assessment can be reviewed when the tool or the destination's law changes. Ask counsel to confirm the tool before technical work begins.
Processors that need data in the clear
A cloud provider, SaaS vendor or managed service that must process personal data in readable form is the hardest case in the method. Encryption that the provider cannot break is not available when it must compute on the data. Map each processor that receives plaintext, what it does with it, and where its staff and systems sit. Where the destination's public authority powers go beyond what is necessary and proportionate, the Recommendations state that no effective technical measure may be available, so these flows drive the largest effort and may require a different architecture.
Storage that needs no access in the clear
Backups, archives and object storage that hold data the recipient never needs to read are where technical measures work best. Strong encryption applied before transmission, with keys held only by the exporter or a trusted entity in the EEA or an equivalent jurisdiction, can be effective in this case. Scope these stores separately from processing systems, and confirm that key material never travels with the data. Document where keys are generated, stored, rotated and retained, because that record is what an assessor will test.
Key custody and key location
Whether encryption counts as a supplementary measure depends on who holds the keys. Keys held by a US-based provider in its own key service generally leave the exporter outside the protection the method expects. Plan key custody as a scoping decision: exporter-managed keys in an EEA-hosted key service, or a hardware security module the exporter controls. Confirm with the key management vendor where key material is stored, who can administer it and whether any operator outside the EEA can reach it.
Remote support and administrative access
Support engineers, managed service staff and administrators who connect from outside the EEA are transfers even when the data never leaves European servers. Each such session can expose personal data in the clear, which affects the technical measures available. List every role with remote access, its location and its tools, then decide whether access is restricted, logged, time-limited or routed through an EEA-based bastion. The count of roles and locations drives the work more than the number of systems.
Re-evaluation triggers
The method requires re-evaluation at appropriate intervals, so the scope must include triggers that reopen the assessment. Changes to the destination's law, new government access reports, a new sub-processor or a move of hosting location all change the result. Define these triggers in advance and assign an owner for each source, so monitoring is a routine task instead of an emergency response.
How an assessor tests a supplementary measures decision
This table sets out how a supervisory authority or auditor would test each of the six EDPB steps, the evidence they request and the findings they commonly raise. Read each row as a question the file must answer before the next step can be credited.
| Step | Evidence requested | Common findings |
|---|---|---|
| 1. Transfer register (know your transfers) | Map of every flow to a third country, including remote access, support sessions and backups, with the data categories, recipients and onward transfers | Transfer map covers the main SaaS vendor but omits support access from outside the EEA, backups and sub-processors |
| 2. Tool verification | Identified Article 46 tool for each flow, such as signed standard contractual clauses, with the version used and the module chosen | Clauses are signed but the module does not match the actual role of the importer, or an outdated clause version is still in use |
| 3. Third-country law assessment | Written assessment of the importer's legislation and practice on public authority access, with sources, dates and a conclusion for each flow | Assessment restates the existence of a law but does not address public authority access powers, proportionality or redress |
| 4. Chosen supplementary measures | Technical measure design, key custody records, encryption configuration, access logs and a reasoned statement of why each measure is effective for that flow | Keys held by the importer or the cloud provider, so the exporter cannot exclude access in the clear; no reasoning on why a measure works |
| 5. Procedural steps | Evidence of any formal steps the tool requires, such as notifications, authorization requests or contract amendments, with dates | Steps identified in the analysis were never completed, or the contract does not reflect the measures the file relies on |
| 6. Re-evaluation record | Review schedule, triggers for early review such as changed laws or new access requests, and minutes or sign-offs from each review | No review dates set, or the file was not updated after a change in the importer's law or infrastructure |
How to run the six steps from transfer map to re-evaluation
The EDPB sequence turns a list of data flows into a documented decision on whether a transfer tool works in practice, what extra measures it needs, and when the assessment must be repeated. Each step produces a record that the next step depends on.
Build the transfer map
Start by listing every flow of personal data to a third country or to an entity that can be reached from one, including remote support access and backups. The privacy or data protection team owns the map, with input from engineering on where systems, subprocessors and administrator accounts sit. The step closes with a transfer register that names the exporter, importer, country, data categories, purpose, transfer tool and the systems involved. Confirm with each team that no flow is missing, since remote access from outside the EEA is a common gap.
Verify the transfer tool
For each flow, confirm which Article 45 or Article 46 mechanism the transfer relies on, such as an adequacy decision, standard contractual clauses or binding corporate rules, and that it is correctly executed and covers the data and importer. Counsel usually leads this check, because it turns on contract wording and the scope of any adequacy decision. The output is a tool record per flow that cites the signed instrument or decision and the date it was checked. Transfers that rely on an Article 49 derogation need separate treatment, since the EDPB states those cannot become the rule in practice.
Assess third-country law and practice
Assess whether the law and practice of the destination country, including public authority access powers, could impinge on the effectiveness of the chosen tool for this specific transfer. Counsel leads the legal analysis, drawing on the EDPB's essential guarantees and information about how the importer has handled past requests. The output is a written assessment for each destination, which records the conclusion and the sources relied on. Where the importer is a cloud provider that must see data in the clear, the assessment should address what its access to the data would require, because that is where the EDPB's findings on no effective technical measure apply.
Decide and document supplementary measures
Supplementary measures are needed only where the previous assessment finds a gap. Engineering teams then design the technical measures, such as encryption before transmission with keys held by the exporter or a trusted entity in the EEA, or pseudonymization, and organizational measures such as access policies and transparency commitments. The EDPB's use cases define when a technical measure can be effective, so the design should be tested against them. The output is a measures decision record and an architecture note that shows which system holds which key, and where data is in the clear. If no measure closes the gap, the record must say so and the transfer should not proceed on that basis without counsel's advice.
Take formal procedural steps
Where the chosen measures or the tool require it, take the procedural steps that apply, such as agreeing amended contract terms with the importer or seeking authorization from the competent supervisory authority for ad hoc clauses. Counsel coordinates these steps and keeps the correspondence. The output is the executed amendment, the authority decision where one is needed, and an updated transfer register entry. Ask the importer in writing to confirm the measures it has implemented, so the exporter holds evidence that the design is actually in place.
Set a re-evaluation interval
Transfers change when laws, importers, subprocessors or system architectures change, so the assessment needs a defined review point. Set the interval and triggers in the transfer register, and include events such as a new subprocessor, a change in destination law, a new authority request or a change to the adequacy decision relied on. Engineering reviews key management and access logs against the measures record at each review. The output is a dated review entry and a signed decision by the accountable owner. The interval length is a governance choice; confirm it with counsel and document the reasoning.
When no technical measure works and the transfer must stop or change
The distinctive point of this section is that some transfers cannot be fixed with technology. The EDPB's Use Case 6 covers the case where a cloud provider or other processor needs to see personal data in the clear, and the destination's public authorities have powers that go beyond what is necessary and proportionate. In that situation the EDPB states that it cannot envision an effective technical measure, so encryption, pseudonymisation or access controls will not make the transfer compliant. Your assessment under step three must record this conclusion with the specific third-country powers and the processing that requires clear-text access, because that record is what a supervisory authority will ask to see.
When the conclusion is reached, the exporter has to choose among a small set of consequences. The transfer can be suspended, the processing can move to the EEA or to a jurisdiction the EDPB considers equivalent, or the architecture can be changed so that the importer no longer receives data in the clear. A fourth option is to reassess the Article 46 tool itself, for example by confirming whether contractual clauses still provide the level of protection they promise. Each option has a cost in engineering time, contract changes and possibly service disruption. Ask your provider in writing which processing operations require clear-text access, where they occur and whether an EEA-only deployment is available for them before you commit to a path.
Article 49 derogations cannot be used as the regular fallback. The EDPB states that these derogations cannot become the rule in practice and must be restricted to specific situations. Relying on consent or contract necessity to keep a stopped transfer running would turn an exception into a standing data flow, which is the outcome the recommendations rule out. Plan for the stop or change before the assessment is finished, confirm that a compliant alternative exists for each affected flow, and document the decision with the date it was taken. Where you are unsure whether a proposed architecture still involves clear-text access by a third-country authority, confirm the point with your data protection officer or qualified legal counsel before the flow resumes.
Which evidence shows a supplementary measures decision was made and kept current
An assessor reviewing a transfer does not accept a conclusion alone. The records below show what was mapped, what was checked, what was decided and when the decision was last revisited. Each record needs an owner and a refresh trigger so it stays accurate between reviews.
Transfer register
A current inventory of every transfer lists each flow to a third country, the exporter and importer, the data categories, the purpose, where the data is stored and every onward recipient. Assessors start here because every later record depends on it. Check that remote support access from outside the EEA appears as a transfer, not only storage. Update the register when a new processor is onboarded, a region changes or a data category is added.
Documented tool verification
This record shows which Article 46 tool covers each transfer, such as standard contractual clauses or binding corporate rules, and confirms the tool is still in force and correctly executed. Keep the signed version, the module chosen and the annex completed for each importer. Re-check it whenever a contract is amended or a sub-processor is added, because a tool that no longer matches the actual flow gives no protection.
Third-country law assessment
The written assessment records the laws and practices of the destination that could reach the data, such as public authority access powers, with the sources relied on and the date of review. Keep the sources themselves so the reasoning can be reproduced. Refresh it when the destination's law changes, when a court or authority publishes a relevant decision or when the data categories become more sensitive.
Measures decision with reasoning
The measures decision states which supplementary measures were adopted for each transfer and why each one addresses the specific access risk identified in the assessment. It also records where no technical measure worked and what contractual, organizational or procedural step was taken instead, or whether the transfer was stopped. Ask for the reasoning per measure, not a list of controls.
Key custody record
Where encryption is the measure, this record shows who generates, holds and rotates the keys and confirms that the importer or a foreign authority cannot obtain them. Keep the key location, access logs for key use and the rotation history. For self-hosted platforms, record whether keys sit in a secrets engine such as OpenBao's transit engine under the exporter's control. Review it when administrators change or a hosting provider is replaced.
Procedural step and re-evaluation log
The procedural record captures any formal steps required by the Member State authority, such as notification or authorization. The re-evaluation log dates each review at the intervals the organization set, with the triggers that caused any earlier review. Assessors look for evidence that the decision was revisited, not just approved once. Assign a named owner and a next review date to every transfer in the log.
What a supplementary measures assessment costs in money and effort
This table lists the cost components of running the EDPB six-step supplementary measures process for a transfer tool, who is paid for each, and whether it is one-time or recurring. No fee figures are given, so use the drivers to shape a written scope and quote before work starts.
| Cost component | Who is paid or who carries it | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Transfer mapping and inventory | Internal staff, sometimes an implementation partner | One-time, then recurring on change | Up with the number of systems, processors and transfer routes; down with a maintained data flow register |
| Legal assessment of third-country law and practice | External counsel or privacy specialists | One-time per destination, then recurring review | Up with the number of destinations and how often their law changes; down when the same assessment covers several flows |
| Technical design and key management model | Security architects, internal or partner engineers | One-time design, recurring key operations | Up when a processor needs data in the clear; down when the exporter or an EEA-trusted entity holds keys |
| Tooling and licenses | Software vendors, or none for self-hosted open source | Often recurring if commercial | Self-hosted open-source components such as Nextcloud and OpenBao can remove license spend; hosting and operations remain |
| Engineering time to deploy measures | Internal engineers or a fixed-scope implementation partner | One-time, with changes when systems change | Up with the number of applications, storage locations and integrations; down with standard configurations and automation |
| Contract and processor changes | Legal, procurement and processor staff | Recurring with each sub-processor or contract change | Up with frequent sub-processor changes and non-standard contract terms; down with clear change notice and pre-agreed clauses |
| Evidence upkeep and re-evaluation | Compliance staff, security operations | Recurring | Up with more transfers and faster-changing foreign laws; down with a standard evidence pack reviewed at set intervals |
| External review | Independent auditors or privacy counsel, if engaged | Optional, periodic | Up with scope breadth and regulator-facing requirements; down with a narrow, well-documented assessment |
Which self-hosted open-source tools support the technical measures
The EDPB's technical measures depend on who holds the keys and whether data is ever readable in the clear outside the EEA. The tools below cover different parts of that question, and none of them makes a transfer lawful by itself.
Nextcloud server-side encryption
Nextcloud's server-side encryption protects file contents at rest on local and external storage, but the keys are kept on the server. That means the server operator, and anyone who can administer it, can read the data in the clear, so this does not meet the exporter-held key case in Use Case 1 on its own. File names and folder structure remain unencrypted. Confirm the key location, the storage backend and what metadata a foreign authority could still see before relying on it.
OpenBao transit engine for exporter keys
The OpenBao transit secrets engine encrypts and decrypts application data without storing the ciphertext, and it supports versioned keys with rotation. This is the component that can keep key control with the exporter or a trusted EEA entity, which is the condition Use Case 1 sets. Document who operates the OpenBao instance, where it runs, and whether any cloud or foreign administrator can reach the keys. Confirm these details in your own environment.
GitLab secret detection evidence
GitLab Community Edition runs pipeline secret detection on files committed and pushed to the repository, and writes detected secrets to a gl-secret-detection-report.json artifact in every tier. That artifact gives you dated evidence that keys and credentials were not left in code, which supports key hygiene claims in your transfer assessment. It does not encrypt data, and it covers only what is committed and pushed. Confirm that the job runs on every relevant repository and that reports are retained long enough for your assessor.
Licenses to confirm before deployment
Nextcloud is licensed under AGPL-3.0-only, OpenBao under MPL-2.0, and GitLab Community Edition under MIT. Each license governs redistribution and modification, so an internal deployment has different obligations from a distributed product. Confirm the version you run, your license obligations for any modifications, and whether your supplier or integrator has changed the code. Legal review is the right place to settle these questions, not this page.
Who owns the transfer assessment, who builds the measures and who reviews them
The organization that exports personal data remains the controller or processor accountable for every transfer. It decides which Article 46 tool it relies on, carries out the assessment of third-country law and practice, decides whether supplementary measures are needed, and records the outcome. Those decisions depend on legal judgment about the destination country and on the organization's own knowledge of its data flows, so they stay with the organization and its counsel or data protection officer.
- Transfer decision: Choosing the transfer tool and deciding whether the transfer may proceed at all.
- Legal assessment: Reviewing the third-country law and practice that the recipient is exposed to, and documenting the conclusion.
- Supplementary measures decision: Accepting or rejecting technical measures, including the case where no measure is effective.
- Ongoing accountability: Re-evaluating the transfer at appropriate intervals and responding to changes in law or practice.
- Governance records: Keeping the assessment, approvals and reasoning available to a supervisory authority on request.
Confirm that a named owner, with authority to stop a transfer, is recorded in your own governance documents before any partner work begins.
An implementation partner prepares the technical inputs that the organization needs for its assessment. In practice this includes helping to map where personal data moves, documenting how systems are configured, and deploying measures such as encryption with keys held by the exporter or a trusted entity in the EEA. The partner can also assemble the evidence that shows those measures work as described. The partner does not make the legal determination, does not decide whether a transfer is lawful, and cannot certify the transfer.
- Transfer map inputs: Gathering system inventories, data flow diagrams and hosting locations for the organization to review.
- Measure deployment: Configuring self-hosted platforms, for example server-side encryption and a key management service, inside the client's infrastructure.
- Technical documentation: Writing configuration records, key custody descriptions and access logs that the organization can use in its assessment.
- Evidence preparation: Packaging test results and configuration exports so the organization and an auditor can check them.
- Scope limits: Stating clearly which assumptions about foreign law rest with the organization's legal advisers.
Ask any partner to put its scope, deliverables and the division of legal and technical work in writing before work starts.
Supervisory authorities enforce the GDPR and can examine whether a transfer tool and its supplementary measures were applied as documented. Independent auditors may test the same controls on the organization's behalf when the organization commissions an assessment. Neither role is performed by the implementation partner. Supervisory authorities issue findings and orders, and auditors report what they tested and what they found, but neither issues a general transfer certificate for the organization's assessment.
- Testing: Checking that the documented assessment matches the actual data flows and configurations.
- Evidence review: Examining key custody records, access logs and encryption settings against the stated measures.
- Findings: Reporting gaps, including any transfer that relies on a measure that does not work in practice.
- Enforcement: Supervisory authorities may order a transfer suspended or brought into compliance.
- Independence: Reviewers should not have designed the measures they test.
Confirm with any auditor what evidence it needs, what it will test and what form its report will take before scheduling the review.
Where organizations usually fall short on supplementary measures
The gaps below cluster around the same weakness: the transfer assessment is treated as a one-time paperwork exercise instead of a working record of data flows, legal conditions and decisions. Each gap is easy to miss during a first review and tends to surface during a regulator inquiry or a customer audit.
Transfer register misses remote access and backups
The transfer register often lists the primary hosting location and the main SaaS vendor, but leaves out remote support sessions from outside the EEA, vendor engineers with production access, offsite backup copies and log shipping to third-country monitoring services. Each of these is a transfer under Recommendations 01/2020 if the data is accessible from a third country. Check the register against cloud accounts, support access logs, backup replication targets and monitoring integrations, and record who can see data from each location.
Law assessment stops at the contract
Many assessments of third-country law stop at the standard contractual clauses and the importer's own statement that it has never received a government request. The method expects the exporter to examine the law and practice of the destination country for public authority access, including surveillance powers, and to document the sources used. Check that the assessment names the specific laws, the authorities that can compel access, the importer's transparency reports and the conditions under which the importer would be required to disclose data.
Encryption where the importer holds keys
Encryption is only an effective supplementary measure where the keys stay with the exporter or a trusted party in the EEA or an equivalent jurisdiction. Organizations sometimes encrypt data at rest in a third-country cloud while the provider manages the keys, which leaves the data readable to anyone who can compel the provider. Server-side encryption that keeps keys on the same server offers weaker protection than exporter-held keys. Check where each key is generated, stored, rotated and used, and who holds administrative rights over the key service.
No record of rejected measures
Assessments often document the measure that was adopted but not the options that were considered and rejected. The method expects the exporter to explain why a measure does not work for a given transfer, for example because the importer needs data in the clear for processing. Without that reasoning, an assessor cannot tell whether the conclusion was tested or assumed. Keep a dated decision record for each rejected option, naming the technical or legal reason, the person who approved the decision and the evidence reviewed.
No re-evaluation trigger after change
A transfer assessment is valid only for the facts it was built on. Changes such as a new sub-processor, a new hosting region, an amendment to the destination country's surveillance law, a court ruling affecting an adequacy decision or a change in the importer's government access requests can all alter the conclusion. Many organizations review transfers only once a year. Define the events that reopen the assessment, assign an owner to watch for them, and record each re-evaluation with its date and outcome.
What buyers ask before bringing in help with transfer assessments
What drives the cost of a transfer impact assessment?
The cost is driven by how many transfers you have, how complex each destination's law is, and how much of the technical work needs to change. Each transfer needs to be mapped, each Article 46 tool checked, and each third country's laws and practice assessed against the data involved. Costs grow when many processors, sub-processors or support paths sit outside the EEA, or when the assessment has to be repeated for each jurisdiction. Part of the spend is one-time (the initial map and assessment) and part recurs (re-evaluation at appropriate intervals and after law changes). Ask any provider for a written scope listing the transfers in scope, the destinations, the tools relied on, and the deliverables, then compare quotes against that same scope. DeployOpen does not publish prices and quotes follow from the written scope.
How long does a transfer assessment usually take?
Duration depends mainly on how quickly the internal team can produce an accurate transfer map and the documents behind it. Timelines stretch when processing records are incomplete, when contracts with processors have to be retrieved from procurement, or when vendors take time to answer questions about government access requests. The assessment itself is not the slowest step: gathering facts about each destination and each vendor's technical setup usually is. Where a technical measure such as encryption with exporter-held keys is needed, the implementation and testing add further time. Ask for a timeline tied to named milestones and a list of inputs you must supply, and confirm which dates depend on your responses rather than on the provider.
What does the internal team need to provide?
The internal team owns the facts the assessment depends on. Typically this means:
- A current record of processing and a list of every system, vendor and support route that touches personal data
- Copies of the contracts, including the Article 46 tool relied on and any sub-processor terms
- Named owners who can answer questions about where keys, logs and backups live and who can access data in the clear
- Decisions on which transfers the business still needs and which can be stopped or moved
Without these inputs, any partner or auditor will spend most of its time chasing facts. Assign an accountable owner in legal or privacy and a technical owner for each system before work starts.
Can we run the transfer assessment in-house?
Yes, the EDPB method does not require an outside firm, and many organizations complete the six steps internally, especially where transfers are few and destinations are well understood. The work does require three skills working together: privacy law to read the tools and the third-country assessment, technical knowledge to judge whether encryption or access controls actually work, and documentation discipline to show the reasoning. External help tends to make sense when the transfer map is large, when a cloud or SaaS provider controls the technical facts, or when the team lacks someone to assess foreign law. Whichever route you take, the decision and its reasoning remain your responsibility.
What can a partner sign on our behalf, and what can it not sign?
A partner can prepare the transfer map, draft the assessment, configure and test technical measures, and document the evidence. It cannot take the legal decision to rely on a transfer tool, sign standard contractual clauses or a processing agreement for your organization, or issue any audit report or certificate. Those decisions and signatures belong to your authorized representatives. Independent auditors, assessors and certification bodies are the only parties who issue reports or certificates. DeployOpen plans, implements, hardens and documents self-hosted platforms and prepares systems and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Confirm this split in the written scope.
When must a transfer stop?
A transfer must stop, or be restructured, when the assessment concludes that the Article 46 tool cannot be made effective in practice. Under EDPB Recommendations 01/2020, supplementary measures are needed only where third-country law or practice affects the effectiveness of the tool. If the data must be accessed in the clear by a provider and the destination's public authority powers go beyond what is necessary and proportionate, the EDPB states it cannot envision an effective technical measure. In that case, the options are to move processing to a location where the risk does not arise, change the architecture so the provider never sees plaintext, or stop the flow. Article 49 derogations cannot be used to keep regular transfers running. Record the decision and the date it takes effect.
Does encryption solve a transfer problem by itself?
Encryption helps only when the design keeps the keys out of the hands of the party a foreign authority could compel. The EDPB treats strong, correctly implemented encryption before transmission as effective for storage that needs no access in the clear, provided keys are reliably managed and retained solely by the exporter or a trusted entity in the EEA or an equivalent jurisdiction. Server-side encryption where the server holds the keys, for example, does not meet that condition if the provider can be compelled to disclose the data. Check which encryption model a platform uses, who holds the keys, whether metadata such as file names is encrypted, and whether support staff in third countries can see plaintext. For self-hosted platforms, Nextcloud's encryption configuration documents that server-side encryption keeps keys on the server and does not encrypt file names or folder structure, which matters for this analysis.
How DeployOpen works on this
DeployOpen works on the transfer assessment as an implementation partner. We help prepare the systems, key management and documentation that an exporter needs to run the six EDPB steps, while the organization owns the assessment and the decisions that follow from it. Independent auditors and certification bodies issue any reports or certificates; DeployOpen does not.
How we scope
- We confirm which data flows leave the EEA and which systems and processors carry them, so the transfer map is complete before any build starts.
- The written scope names the Article 46 transfer tool relied on and the third-country access risks the assessment will examine.
- Scope states which self-hosted platforms, key stores and storage locations are in and out of the work, agreed in writing before work starts.
How we build
- We configure server-side encryption on self-hosted file platforms, confirming what it covers, such as file contents, and what it leaves visible, such as file names.
- Where the exporter must hold keys, we set up key management so keys stay under the exporter's or a trusted EEA entity's control, with rotation and retention documented.
- We test that encrypted data is unreadable without the exporter-held keys and record where a technical measure cannot work because a processor needs data in the clear.
How we hand over
- We deliver a transfer register, the configuration evidence for each measure, and a written record of the key custody arrangements.
- Documentation maps each step of the EDPB method to the evidence that supports it, so the organization and its assessor can trace every conclusion.
- We hand over runbooks for key rotation and for re-evaluating the transfer assessment at intervals the organization sets.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, which covers platform changes that could affect a transfer assessment.
- When a third-country law or processor changes, we can review the affected configuration and update the evidence under the agreed scope.
- Ask us to confirm in writing which parts of the assessment remain the organization's responsibility and which evidence an independent assessor will need to review.
