Organisations should map each transfer, identify the transfer tool in use, and assess whether the destination country undermines the protection expected under GDPR. If protection is not essentially equivalent, they must add supplementary measures, suspend the transfer, or stop it. The assessment should be documented, rechecked regularly, and tied to accountability duties rather than treated as a one-time legal review.
What Schrems II changed about cross-border transfer assessments
Schrems II did not ban cross-border transfers outright, but it shifted the burden onto organisations to prove that their transfer mechanism still protects the data in practice. The assessment is no longer a paperwork exercise, it is a country-by-country and transfer-by-transfer review of whether the receiving jurisdiction and the chosen transfer tool together preserve the level of protection expected under GDPR.
That means the core question is not whether the destination country has some privacy law on the books. The real test is whether public authority access, local laws, and operational realities can undermine the safeguards built into the transfer arrangement. If they can, supplementary measures may be needed, and if they cannot be made effective, the transfer should not continue.
For practitioners, the critical distinction is between legal availability and practical effectiveness. A transfer tool such as SCCs can still be valid, but only if the surrounding legal and technical environment does not neutralise its protections.
How to structure the assessment in practice
Start by mapping every transfer path, including onward transfers, processors, and sub-processors, so that the assessment covers the real data flow rather than just the contract chain. Then identify the transfer tool in use, because the analysis differs depending on whether you rely on SCCs, an adequacy decision, BCRs, or another lawful mechanism.
Next, assess the destination jurisdiction for factors that can affect effective protection, especially access by public authorities, availability of redress, and any legal or technical limits on supplementary measures. Where the risk is not reduced to an essentially equivalent level, the organisation must narrow the transfer, strengthen controls, or stop the transfer entirely.
Documentation matters as much as the decision itself. The assessment should show what was transferred, why the mechanism was chosen, what country risks were considered, what supplementary measures were tested, and why the final outcome was accepted. That record is what makes the decision reviewable later when laws, vendors, or data flows change.
- Map the specific transfer and any onward disclosures.
- Confirm the legal transfer tool and its assumptions.
- Test whether supplementary measures are actually effective in the destination context.
- Escalate or halt the transfer if equivalent protection cannot be maintained.
Risk and Threat Considerations
Cross-border transfer failures usually arise when an organisation treats a legal mechanism as sufficient even though local law or state access can still defeat the intended safeguards. The main exposure is not abstract non-compliance, it is unintended disclosure, unenforceable protections, and a transfer chain that looks lawful on paper but fails under scrutiny.
Failure mechanism: The organisation assumes the transfer tool alone resolves the issue, but destination-country law or access conditions make supplementary measures ineffective, so the promised level of protection is not maintained.
Impact: The transfer can become unlawful, data subjects can face weaker protection than GDPR requires, and the organisation may need to suspend processing, renegotiate controls, or unwind business dependencies built on the transfer.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, CIS Controls v8, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the technical controls, while EU Cyber Resilience Act define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | Cross-border transfer assessments require risk-based decisions and repeat review. |
| GV.RR-03 — Roles, Responsibilities, and Authorities | Schrems II assessments depend on clear accountability for transfer decisions and approval. | |
| PR.DS-01 — Data-at-Rest Protection | Supplementary measures often rely on protecting data before and during transfer. | |
| Recommendation — Embed transfer reviews in the organisation's risk management process and revisit them regularly. Assign clear ownership for transfer assessments, escalation, and sign-off. Apply strong data-protection controls that preserve confidentiality across transfer paths. | ||
| CIS Controls v8 | 3 — Data Protection | Transfer assessments hinge on protecting data in transit and limiting exposure in foreign jurisdictions. |
| 6 — Access Control Management | Cross-border transfers can fail when access paths are broader than intended or not adequately restricted. | |
| Recommendation — Classify sensitive data and enforce protective controls before cross-border transfer. Restrict access to transferred data and validate that permissions remain tightly scoped. | ||
| NIST SP 800-63 | Identity Assurance and Federation | Transfer governance can depend on trusted authentication and federation where access to transferred data is mediated by identities. |
| Recommendation — Use strong identity assurance when access to transferred data depends on authenticated users or services. | ||
| NIST Zero Trust (SP 800-207) | SC-7 — Boundary Protection | Transfer design should preserve trust boundaries and limit implicit trust in the destination environment. |
| Recommendation — Limit trust placed in the receiving environment and segment data flows across boundaries. | ||
| EU Cyber Resilience Act | Cybersecurity requirements for products with digital elements | Cross-border transfer controls may rely on the security properties of products and services used to protect data in transit and storage. |
| Recommendation — Use secure-by-design products and services when they underpin transfer safeguards. | ||
Practitioner Guidance
What to prioritise: Focus first on high-volume, sensitive, and operationally critical transfers, because those create the greatest blast radius if the transfer basis fails. A low-risk administrative transfer and a production dataset exported to a high-exposure jurisdiction should not be treated with the same urgency.
What to verify: Verify that the supplementary measures you rely on can survive the specific legal and technical conditions in the destination country. If encryption, key control, or access segregation is part of the solution, confirm that the control remains outside the reach of the receiving environment where that is what the assessment depends on.
Practitioner takeaway: The useful test is not whether the transfer has a lawful label, it is whether the protection still holds after the data arrives and the destination environment is taken seriously as part of the control design.
Related resources from NHI Mgmt Group
- How should organisations avoid hidden cross-border data transfers in ZTNA?
- Why do cross-border data transfers create governance risk when organisations store government or regulated data in cloud services?
- How should organisations apply geo-fencing as an additional safeguard for cross-border data transfers?
- Why does unrestricted cross-border access to personal data create compliance risk under Schrems II?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
