Data controllers are accountable for evaluating whether a transfer mechanism still works in practice and for choosing additional safeguards where needed. That responsibility cannot be outsourced to a contract alone. Legal, privacy, and security teams usually share the work, but the organisation sending the data must be able to justify the transfer and document the decision.
Who remains accountable after Schrems II?
Under Schrems II, accountability stays with the organisation that decides to transfer the data. It must show that the chosen transfer tool still works in the destination context and that any added safeguards are effective in practice. That accountability sits with the controller or, where relevant, the exporting party, not with a clause on its own.
What the accountability standard actually requires
Defensibility is not a paper exercise. The exporter has to assess the legal and technical environment in the receiving country, decide whether the transfer mechanism remains valid, and document why the transfer can proceed. In practice, that means separating the legal basis for transfer from the security and privacy controls that make the transfer tolerable.
The key point is that contractual promises do not remove the need for an independent assessment. If local law, government access, or enforcement conditions undermine the transfer tool, the organisation sending the data has to add safeguards, suspend the transfer, or choose a different route. That decision-making duty is part of accountable governance, not a box-ticking task.
Why shared execution does not mean shared accountability
Legal, privacy, and security teams often contribute different pieces of the work, but they do not dilute the core responsibility. Counsel may interpret transfer mechanisms, privacy teams may assess data flows, and security teams may evaluate encryption, access controls, and operational exposure. Still, the organisation exporting the data must own the final justification and be able to defend it to regulators.
This is why the most common failure mode is governance drift: one team assumes another has validated the transfer, or a vendor contract is treated as proof that the risk has been solved. Good practice is to treat the transfer decision as an owned control with evidence, review cadence, and an explicit stop or escalate path when the assessment changes.
Risk and Threat Considerations
Schrems II creates a real exposure when organisations rely on standard clauses or policy language without validating whether foreign-access risk has been reduced to an acceptable level. The practical risk is not abstract compliance drift, but a transfer that becomes unjustifiable once surveillance, access, or enforcement conditions are considered.
Failure mechanism: The exporter treats the contract as sufficient and fails to test whether the destination country, service model, or encryption design still protects the data in use. That leaves a gap between legal form and operational reality.
Impact: The organisation can end up with an unlawful or indefensible transfer, forced remediation, suspension of processing, or regulatory challenge after the fact.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
GDPR and ISO/IEC 27001:2022 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| GDPR | A.5.15 — Legal, Statutory, Regulatory and Contractual Requirements | Cross-border transfer defensibility depends on meeting GDPR transfer obligations. |
| A.5.34 — Privacy and Protection of PII | Schrems II is about protecting personal data during international transfers. | |
| Recommendation — Document the transfer basis and verify safeguards before exporting personal data. Assess transfer safeguards and record why the destination remains acceptable. | ||
| ISO/IEC 27001:2022 | A.5.31 — Legal, statutory, regulatory and contractual requirements | Transfer accountability requires compliance with external legal requirements and contract terms. |
| A.5.36 — Compliance with policies, rules and standards for information security | The organisation must prove that its transfer governance is followed and reviewed. | |
| A.5.12 — Classification of information | Transfer defensibility depends on knowing what data is being moved and how sensitive it is. | |
| Recommendation — Track legal transfer obligations and maintain evidence for the decision. Review transfer controls regularly and retain proof of compliance. Classify transferred data before deciding what safeguards are required. | ||
Practitioner Guidance
What to verify: Verify that the transfer assessment is owned by the exporting organisation, updated when the destination or processing model changes, and backed by evidence of any supplemental safeguards. If the assessment cannot explain why the transfer remains defensible in practice, it is not complete.
Decision rule: If the destination risk cannot be reduced to a defensible level with technical and organisational safeguards, do not rely on the contract alone, and do not treat approval as permanent. Reassess the transfer, the data category, and the necessity of the transfer before scaling it further.
Practitioner takeaway: After Schrems II, accountability is measured by the exporter’s ability to justify the transfer, not by the existence of a template clause or a vendor commitment.
Related resources from NHI Mgmt Group
- How should organisations assess cross-border data transfers after Schrems II?
- Why does unrestricted cross-border access to personal data create compliance risk under Schrems II?
- Why do cross-border data transfers and automated decision-making create compliance risk under Law 25?
- Why do cross-border data transfers still create GDPR risk even after the EU-U.S. Data Privacy Framework?
