Organisations should rely on a lawful transfer mechanism that still stands up under scrutiny, most commonly standard contractual clauses, and then assess whether the destination country’s laws or practices undermine the protection promised in those clauses. They should also document any supplementary measures, because the exporter and importer share responsibility for judging whether the transfer remains compliant.
What changed after Privacy Shield for cross-border transfer decisions
The invalidation of Privacy Shield did not remove the need to move personal data between the EU and the US, but it did remove a shortcut that many organisations had treated as a default. That shift matters because transfer compliance is no longer just a paperwork exercise. Teams now need a transfer basis that fits the transfer itself, the services involved, and the legal environment in the destination country. The EU General Data Protection Regulation (GDPR) remains the core reference point for deciding whether the transfer mechanism is valid and whether supplementary safeguards are needed.
Practitioners often get this wrong by treating contractual terms as if they alone solve the problem. They do not. A transfer mechanism can be formally valid and still fail in practice if foreign law or access practices make the promised protections unrealistic. In practice, many security and privacy teams discover that gap only after a vendor review, regulator challenge, or procurement renewal forces them to re-examine the transfer path.
How to operationalise SCCs and supplementary measures
Standard contractual clauses are the most common replacement mechanism, but they are only the starting point. Organisations need to map which personal data flows leave the EEA, identify the exporter and importer roles, and confirm that the SCC module used actually matches the relationship. That step sounds administrative, yet it often exposes hidden complexity such as subcontractors, support access, mirrored environments, or onward transfers that were never properly documented.
The next step is the transfer impact assessment. This is where organisations test whether the destination country’s laws, public authority access rules, or sector-specific practices could undermine the protection the SCCs are meant to provide. If the answer is yes, the organisation must decide whether supplementary measures can realistically close that gap. Those measures may be technical, such as encryption with strong key control, or organisational, such as tighter procedures and contractual restrictions. What matters is whether the combination is credible for the specific transfer, not whether it sounds robust on paper.
A practical transfer workflow usually includes:
- data flow mapping for the exact systems and vendors involved
- role and module selection for the correct SCC structure
- destination-country assessment focused on legal and access-risk realities
- supplementary measure selection matched to the exposure
- recordkeeping that shows the exporter’s decision was reasoned, not assumed
Documentation is not optional because accountability is shared. The exporter cannot outsource the judgment to the importer, and the importer cannot simply promise compliance without evidence that the promised safeguards are achievable. Organisations should also review whether their monitoring, incident handling, and contract governance can detect when a transfer ceases to be defensible. This guidance breaks down when the organisation does not know where data actually flows, because unknown onward transfers make any legal analysis incomplete.
Where the usual transfer answer breaks down
Tighter transfer controls often increase operational friction, so organisations must balance legal defensibility against vendor usability and business speed. That tradeoff becomes most visible when a service is globally hosted, when support staff need broad access, or when a single processor uses multiple sub-processors across different jurisdictions.
One common edge case is the difference between data that is merely stored in the US and data that is actively accessible from the US. A transfer analysis should focus on real access and not just server location, because remote administration and support can create the same legal issue as storage. Another edge case is encryption: it only works as a supplementary measure when the exporter retains meaningful control over the keys and the importer cannot readily defeat the protection. There is no universal consensus that one technical safeguard is enough for every transfer, so organisations should treat any “one-size-fits-all” claim with caution.
Organisations also need to distinguish between a compliant transfer path and a compliant vendor contract. A contract can support compliance, but it cannot fix an unreliable legal environment by itself. The strongest approach is usually the one that can survive a challenge, not the one that creates the least procurement friction.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST CSF 2.0 set the technical controls, while EU Cyber Resilience Act and NIS2 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| EU Cyber Resilience Act | Cross-Border Data and Security Assurance | Transfer governance depends on demonstrable safeguards for data moving across jurisdictions. |
| Recommendation — Map cross-border data flows and prove the transfer basis still protects the data end to end. | ||
| NIS2 | Risk Management and Supply Chain Security | Third-party processing and access paths can create material operational and governance exposure. |
| Recommendation — Review vendor and sub-processor access paths and tighten oversight where cross-border exposure increases risk. | ||
| CIS Controls v8 | 15 — Service Provider Management | EU-US transfers often rely on processors and sub-processors that must be governed and monitored. |
| Recommendation — Document provider obligations and monitor sub-processor handling of transferred personal data. | ||
| NIST CSF 2.0 | PR.DS — Data Security | Transfers require protection of personal data in transit, at rest, and under foreign access conditions. |
| GV.RM — Risk Management Strategy | Transfer-impact assessments are a governance decision about legal and operational risk tolerance. | |
| Recommendation — Apply data-security controls that preserve confidentiality and integrity across the transfer path. Use risk governance to decide when supplementary measures are needed or when a transfer should stop. | ||
Practitioner Guidance
What to prioritise: Focus first on the transfers that combine high data sensitivity, broad vendor access, and weak visibility into onward processing. Those are the transfers most likely to fail a real scrutiny test, even if they have been running for years without incident.
What to verify: Confirm three things before relying on a transfer arrangement: the correct SCC structure is in place, the destination assessment is current, and any supplementary measure is actually effective for the specific data and access pattern. If any one of those is missing, treat the transfer as unresolved rather than “probably fine.”
Practitioner takeaway: The best test is not whether the transfer looks compliant in isolation, but whether it still holds after you account for foreign access risk, vendor reality, and your own ability to prove the decision later.
Related resources from NHI Mgmt Group
- How should organisations implement the EU-US Data Privacy Framework when transferring personal data from the EU to the US?
- Why do EU-US data transfers still require careful governance after adequacy is adopted?
- What breaks when organisations treat the EU-US Data Privacy Framework as a one-time certification instead of an ongoing control?
- How should organisations handle EU Data Act data access and sharing requests without weakening privacy controls?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
