The email arrived on July 16, 2020, at 11:23 AM. Our legal counsel had forwarded the Court of Justice of the European Union's ruling with a single line: "We need to talk. NOW."
I was the CISO for a multinational SaaS company processing data for over 3,000 European customers. We had AWS servers in Virginia, analytics pipelines running through Google Cloud in Iowa, and a customer support system hosted in Oregon. Every single one of those data flows had just become legally questionable.
The Schrems II decision didn't just invalidate Privacy Shield—it fundamentally changed how we think about international data transfers. And four years later, I'm still helping organizations navigate the complexity it created.
Let me share what I've learned from conducting over 80 Transfer Impact Assessments (TIAs) and why getting this wrong could cost you everything.
What Schrems II Actually Changed (And Why Most People Get It Wrong)
Here's what I hear constantly: "Privacy Shield is gone, so we just use Standard Contractual Clauses (SCCs), right?"
Wrong. So painfully wrong.
The Schrems II ruling established something critical that most organizations miss: SCCs alone are not sufficient if the destination country's laws allow government access to data in ways incompatible with EU fundamental rights.
Think about what that means. The European Court basically said: "We don't care what contracts you sign. If the country you're sending data to has laws that could allow surveillance or government access that wouldn't be permitted in the EU, you need to do more."
"Schrems II didn't just kill Privacy Shield. It required organizations to become amateur constitutional lawyers, analyzing foreign surveillance laws and assessing their real-world impact on data transfers."
I remember a call with a frustrated VP of Engineering in late 2020. "I'm a software guy," he said. "Now you're telling me I need to understand FISA Section 702, Executive Order 12333, and how they might apply to our EU customer data? This is insane."
He wasn't wrong. But it's the reality we live in.
The Transfer Impact Assessment: What It Really Entails
Let me break down what a proper TIA actually involves. This isn't theoretical—this is the process I've used with dozens of organizations to achieve defensible compliance.
The Six-Phase TIA Framework
Phase | Key Activities | Typical Duration | Common Pitfalls |
|---|---|---|---|
1. Data Mapping | Identify all EU personal data transfers outside the EEA | 2-4 weeks | Missing shadow IT, third-party subprocessors |
2. Legal Basis Assessment | Evaluate transfer mechanisms (SCCs, BCRs, adequacy) | 1-2 weeks | Assuming old SCCs are still valid |
3. Destination Law Analysis | Research third country surveillance laws | 3-6 weeks | Surface-level analysis without legal depth |
4. Risk Evaluation | Assess practical likelihood of government access | 2-3 weeks | Theoretical vs. real-world risk confusion |
5. Supplementary Measures | Implement additional safeguards | 4-12 weeks | Technical measures without legal effectiveness |
6. Documentation | Create defensible records of assessment | 1-2 weeks | Insufficient detail for regulator scrutiny |
Phase 1: Data Mapping (The Part Everyone Underestimates)
In 2021, I worked with a European fintech company that was convinced they had "maybe five or six" data transfers to document.
Four weeks later, we'd identified 47 distinct data flows to third countries.
They had:
Marketing automation in the US
Customer support ticketing in Canada
Analytics platforms in the US
Cloud infrastructure spanning three continents
Payment processors with US parent companies
Email services routing through American servers
CDN providers caching data globally
HR systems with US-based vendors
Every. Single. One. Required assessment.
Here's the systematic approach that works:
Create a comprehensive transfer inventory:
Data Category | Receiving Entity | Destination Country | Transfer Volume | Data Sensitivity | Transfer Mechanism |
|---|---|---|---|---|---|
Customer contact info | Salesforce | United States | 125,000 records | Medium | SCCs (updated) |
Payment data | Stripe | United States | 45,000 transactions/mo | High | SCCs + encryption |
Support tickets | Zendesk | United States | ~3,000/month | Medium-High | SCCs (updated) |
Marketing analytics | Google Analytics | United States | Aggregated data | Low | SCCs + pseudonymization |
Employee HR data | Workday | United States | 450 employees | High | SCCs + access controls |
This table format became my standard. It forces you to think through every dimension of the transfer.
"If you can't map it, you can't protect it. And if you can't protect it, you can't legally transfer it."
Phase 2: Legal Basis Assessment (The Foundation)
Once you know WHAT you're transferring, you need to establish WHY it's legal.
The GDPR provides limited options for international transfers:
Transfer Mechanism Decision Tree:
Transfer Scenario | Recommended Mechanism | Requirements | Schrems II Impact |
|---|---|---|---|
To UK, Switzerland, or other adequate countries | Adequacy Decision | None (transfers treated like intra-EU) | Low - adequacy status under review but stable |
Repeated transfers to same entity | Standard Contractual Clauses (SCCs) | Updated SCCs + TIA | High - SCCs alone insufficient for US transfers |
Intra-company transfers | Binding Corporate Rules (BCRs) | DPA approval + comprehensive policies | Medium - still require TIA for problematic countries |
One-time transfer with consent | Explicit consent | Informed, specific, freely given | Low - limited use cases |
Necessary for contract | Contractual necessity | Actually necessary, not just convenient | Low - narrow interpretation |
Legal claims | Legal necessity | Documented legal proceeding | Low - specific circumstances only |
Most organizations default to SCCs. But here's what I learned the hard way: the new 2021 SCCs are not a rubber stamp.
I helped a healthcare provider implement the updated SCCs with their US-based cloud provider in 2022. The process took four months because we had to:
Review and update all existing SCCs to the 2021 version
Ensure the SCCs included the correct modules (there are four different modules depending on the transfer type)
Verify that data importers acknowledged and agreed to new obligations
Document the technical and organizational measures in place
Conduct a full TIA to determine if SCCs alone were sufficient
That last point is critical. The updated SCCs explicitly require you to conduct a transfer impact assessment. It's not optional—it's contractually mandated.
Phase 3: Destination Law Analysis (Where It Gets Complex)
This is where most organizations either give up or hire expensive law firms. Let me save you some pain by sharing what I've learned.
Key Legal Frameworks to Understand:
Country | Primary Surveillance Laws | Data Access Scope | Oversight Mechanisms | Schrems II Risk Level |
|---|---|---|---|---|
United States | FISA 702, EO 12333, CLOUD Act | Broad authority for foreign intelligence | FISA Court (ex parte, classified) | High - Identified in Schrems II |
United Kingdom | Investigatory Powers Act 2016 | Bulk collection powers | Investigatory Powers Commissioner | Medium - Adequacy decision exists but similar concerns |
Canada | CSEC Act, Privacy Act | Targeted foreign intelligence | NSICOP, Privacy Commissioner | Low-Medium - Generally GDPR-compatible |
Australia | Telecommunications Act, TOLA | Assistance and access orders | Inspector-General of Intelligence | Medium - Some concerning provisions |
India | IT Act, Telegraph Act | Government access with safeguards | Courts, limited oversight | Medium - Evolving framework |
Singapore | Computer Misuse Act, CMA | Limited surveillance powers | Strong privacy protections | Low - Generally protective framework |
In 2022, I conducted a TIA for a company transferring employee data to their US parent company. Here's what the analysis involved:
US Surveillance Law Assessment:
FISA Section 702 Analysis:
Does our organization qualify as an "electronic communication service provider"? (Probably not for most)
Could our data be incidentally collected in targeting? (Possible but unlikely)
Do we have US persons accessing the data? (Yes - key factor)
Executive Order 12333 Evaluation:
Could data be collected outside the US? (Theoretically yes)
Is there any oversight or limitation? (Minimal)
Practical likelihood given our business? (Very low)
CLOUD Act Considerations:
Could US law enforcement compel production? (Yes)
Would adequate legal process be followed? (Generally yes)
Conflict with EU blocking statutes? (Potentially)
This took three weeks of research, consultations with privacy lawyers in both the EU and US, and review of academic analyses.
Phase 4: Risk Evaluation (Theory Meets Reality)
Here's where experience matters. The law is one thing. Real-world risk is another.
I use this framework to evaluate actual risk:
Practical Risk Assessment Matrix:
Factor | Low Risk Example | High Risk Example | Our Assessment Criteria |
|---|---|---|---|
Data Sensitivity | Pseudonymized analytics | Health records, financial data | What harm if accessed? |
Data Volume | Small datasets, specific purposes | Mass data processing | Scale attracts attention |
Business Sector | General commerce | Defense, intelligence, activism | Government interest level |
Data Subject Profile | General consumers | Politicians, journalists, activists | Target attractiveness |
Access Patterns | Encrypted, need-to-know basis | Broad access, plain text | Practical accessibility |
Destination Entity | European subsidiary of US firm | US government contractor | Likelihood of legal demands |
Let me share a real example that illustrates this:
Case Study: European Marketing Agency
In 2023, I worked with a Berlin-based marketing agency using Mailchimp (US-based) for email campaigns.
Their initial panic: "Schrems II means we can't use any US services!"
Our risk assessment:
Data involved: Email addresses, names, basic engagement metrics
Volume: 15,000 contacts
Sensitivity: Low - publicly available information
Sector: Marketing services for SMBs
Subject profile: General business contacts
Realistic government interest: Nearly zero. The NSA is not going to invoke FISA 702 to access a German marketing agency's Mailchimp account.
Our approach:
Updated to new SCCs with Mailchimp
Implemented supplementary measures (encryption in transit, access controls)
Documented the risk assessment
Continued using the service with proper safeguards
"The European Court requires you to assess risk, not to assume the worst-case scenario in every situation. Proportionality matters."
Contrast that with a different client:
Case Study: EU Think Tank on Digital Rights
An advocacy organization focused on privacy and surveillance, with members including prominent EU politicians and activists.
Their data: Contact information, research documents, communication records
Our risk assessment:
Government interest: HIGH - subject matter directly relevant to intelligence agencies
Data subject profile: HIGH - politicians and activists explicitly mentioned in Schrems II
Practical risk: Documented cases of similar organizations being targeted
Our recommendation: Avoid US-based services entirely for core operations. Use EU-hosted alternatives even if more expensive or less feature-rich.
The data was similar. The risk was completely different.
Phase 5: Supplementary Measures (Beyond SCCs)
Once you've assessed risk, you need to implement additional safeguards. But here's the challenge: not all supplementary measures are legally effective.
The European Data Protection Board (EDPB) published recommendations on supplementary measures. I've distilled years of implementation experience into this framework:
Supplementary Measures Effectiveness Matrix:
Measure Type | Technical Implementation | Legal Effectiveness | Practical Difficulty | Best For |
|---|---|---|---|---|
Encryption in Transit | TLS 1.3, perfect forward secrecy | Low (data accessible at rest) | Easy | Baseline requirement |
Encryption at Rest | AES-256 with EU-held keys | Medium-High (if keys never leave EU) | Medium | Most scenarios |
End-to-End Encryption | Client-side encryption, zero-knowledge | High (data unreadable by provider) | Hard | Highest sensitivity data |
Pseudonymization | Tokenization, hashing with EU-held mapping | Medium (not effective alone) | Medium | Analytics, aggregated data |
Anonymization | Irreversible de-identification | High (no longer personal data) | Very Hard | Research, statistics |
Data Minimization | Collect/transfer only necessary data | Medium (reduces exposure) | Easy | All transfers |
Access Controls | Role-based access, audit logging | Low (doesn't prevent legal access) | Easy | Baseline requirement |
Contractual Restrictions | Data use limitations in contracts | Low (unenforceable against governments) | Easy | Baseline requirement |
Split Processing | Critical data never leaves EU | High (eliminates transfer) | Very Hard | Highest risk scenarios |
Real Implementation Example:
In 2022, I helped a European healthtech company implement a split-processing architecture for their US-based analytics provider.
The Challenge: They needed behavioral analytics on patient app usage (anonymized), but any transfer of health-related data to the US created unacceptable risk.
Our Solution:
EU Environment (Ireland):
├── Raw patient data (never transferred)
├── Pseudonymization engine
├── Aggregation layer
└── Only anonymized, aggregated metrics sent to USImplementation Details:
Data Processing in EU:
All patient identifiers stripped in EU
Aggregation to minimum 50 patients per cohort
Statistical disclosure control applied
Legal assessment: Data is anonymized, no longer personal data under GDPR
Transfer to US:
Only aggregate statistics transferred
No transfer impact assessment required (not personal data)
Maintained SCCs for contractual protections
Documented anonymization methodology
Cost: €180,000 in engineering time and infrastructure changes
Benefit: Eliminated GDPR transfer risk entirely while maintaining analytics capability
Lesson learned: Sometimes the best supplementary measure is architectural—preventing the transfer rather than trying to protect it.
Phase 6: Documentation (Your Shield Against Regulators)
I cannot stress this enough: documentation is not optional.
In 2023, I worked with a company facing a GDPR investigation triggered by a data subject complaint. The complainant alleged that their data was being illegally transferred to the US.
The company HAD done a transfer impact assessment. They HAD implemented supplementary measures. But they hadn't documented it properly.
The investigation took eight months, cost over €200,000 in legal fees, and resulted in a €150,000 fine—not because they violated GDPR, but because they couldn't prove they hadn't.
Essential TIA Documentation:
Document | Purpose | Key Contents | Update Frequency |
|---|---|---|---|
Transfer Inventory | Catalog all transfers | Data categories, destinations, volumes, legal basis | Quarterly |
TIA Report | Document risk assessment | Legal analysis, risk evaluation, supplementary measures | Per transfer + annual review |
SCC Execution Records | Prove legal basis exists | Signed SCCs, module selection justification | When agreements change |
Supplementary Measures Log | Evidence of additional protections | Technical measures, effectiveness analysis | Continuous |
Risk Assessment Methodology | Explain decision-making process | Framework used, criteria applied, expert consultations | Annual |
Monitoring Records | Prove ongoing compliance | Review dates, changes detected, actions taken | Continuous |
Legal Research Archive | Support destination law analysis | Statutes reviewed, case law, expert opinions | As laws change |
Decision Rationale | Explain why transfers continue | Balancing test, business necessity, alternatives considered | Per transfer |
Here's a real TIA executive summary template I use:
TRANSFER IMPACT ASSESSMENT Data Exporter: [EU Entity Name] Data Importer: [Third Country Entity] Assessment Date: [Date] Assessor: [Name, Title]
1. TRANSFER DESCRIPTION
Data Categories: Customer contact information, transaction history
Legal Basis: Standard Contractual Clauses (2021, Module Two)
Destination: United States
Purpose: Customer relationship management and support
2. DESTINATION LAW ANALYSIS
Primary Laws Reviewed: FISA Section 702, Executive Order 12333, CLOUD Act
Government Access Risk: Medium - theoretical authority exists but practical likelihood low given business context
Legal Protections: Some oversight via FISA Court; legal process required for CLOUD Act
Gaps Identified: Broad executive authority under EO 12333; limited recourse for data subjects
3. RISK ASSESSMENT
Data Sensitivity: Medium
Data Subject Profile: General business customers
Practical Likelihood of Government Access: Low
Potential Impact if Accessed: Medium
Overall Risk Level: Medium-Low
4. SUPPLEMENTARY MEASURES IMPLEMENTED
Encryption in transit (TLS 1.3)
Encryption at rest (AES-256, EU-managed keys)
Access controls and audit logging
Contractual data use limitations
Data minimization (only necessary data transferred)
5. EFFECTIVENESS ASSESSMENT Supplementary measures significantly reduce practical accessibility of data to third country authorities. Encryption at rest with EU-managed keys means data importer cannot access data in plaintext without key release, providing effective protection against most access scenarios.
6. MONITORING AND REVIEW
Quarterly review of legal landscape
Annual reassessment of risk
Immediate review if legal changes or government demands occur
Next scheduled review: [Date]
7. DECISION Transfer may continue with implemented safeguards. Risk is reduced to acceptable level given business necessity and supplementary measures in place.
"A documented transfer impact assessment isn't just compliance theater. It's your evidence that you took GDPR seriously and made informed, defensible decisions."
The Hard Conversations: When to Say No to Transfers
Here's something nobody wants to hear: sometimes the answer is "we can't do this transfer."
I've had to deliver this news more than once, and it's never pleasant.
Case Study: European Healthcare Provider
In 2021, a major European hospital wanted to use a US-based AI platform for diagnostic imaging analysis.
The Appeal:
Cutting-edge AI with 98.7% accuracy
Significantly better than available EU alternatives
Could improve patient outcomes
The Problem:
Required transfer of actual diagnostic images (highly sensitive health data)
AI processing happened in US data centers
No way to implement effective supplementary measures that wouldn't break the AI model
Destination country laws posed unacceptable risk for health data
Our Assessment:
Factor | Rating | Notes |
|---|---|---|
Data Sensitivity | Critical | Diagnostic images are special category health data |
Supplementary Measures Available | Inadequate | Encryption would break AI functionality |
Alternative Solutions | Available | EU-based alternatives exist, though less accurate |
Legal Risk | Unacceptable | Clearly falls within Schrems II problem scope |
Regulatory Scrutiny | High | Health data transfers under intense supervision |
Recommendation: Do not proceed with transfer
Hospital's Response: "But patients could benefit!"
My Response: "And your organization could face regulatory action, lose patient trust, and create precedent for other problematic transfers. The 1.3% accuracy difference doesn't justify the legal risk."
They chose an EU-based solution. Six months later, a competitor who had used the US service faced a GDPR investigation. Vindication is cold comfort, but it's something.
Regional Nuances: Not All "Third Countries" Are Equal
Through 80+ TIAs, I've learned that destination country matters enormously.
My Practical Country Risk Tiers (Based on Real-World Experience):
Tier 1: Low Risk (Generally Manageable with SCCs + Basic Measures)
Country/Region | Why Lower Risk | Typical Supplementary Measures |
|---|---|---|
Canada | PIPEDA provides strong protections; limited surveillance scope | SCCs + encryption in transit |
Singapore | Strong privacy framework; limited government access laws | SCCs + access controls |
Japan | Adequacy decision; cultural respect for privacy | SCCs (often sufficient alone) |
South Korea | Robust privacy law (PIPA); democratic oversight | SCCs + standard technical measures |
Tier 2: Medium Risk (Require Careful TIA + Robust Measures)
Country/Region | Key Concerns | Required Supplementary Measures |
|---|---|---|
United Kingdom | Post-Brexit uncertainty; Investigatory Powers Act | SCCs + encryption at rest with EU keys |
Australia | TOLA (encryption-breaking powers); Five Eyes member | SCCs + end-to-end encryption or split processing |
India | Evolving legal framework; government access concerns | SCCs + encryption + strict access controls |
Israel | Intelligence capabilities; ongoing adequacy assessment | SCCs + robust encryption + data minimization |
Tier 3: High Risk (Requires Maximum Measures or Avoidance)
Country/Region | Major Issues | Recommendation |
|---|---|---|
United States | Schrems II specifically addressed; broad surveillance authority | Maximum supplementary measures or avoid for sensitive data |
China | National security laws requiring data access; state oversight | Avoid for EU personal data unless absolutely necessary |
Russia | Data localization requirements; government access mandates | Avoid for EU personal data |
Real Example - South African Transfer:
In 2023, I assessed a transfer to South Africa (no adequacy decision, not specifically mentioned in Schrems II).
Our Process:
Researched South African surveillance laws (RICA, Cybercrimes Act)
Assessed practical government access capabilities
Evaluated oversight and legal protections
Determined risk was lower than US despite no adequacy decision
Outcome: Approved transfer with standard supplementary measures (SCCs + encryption + access controls)
Lesson: Don't assume "no adequacy decision" means "high risk." Do the actual assessment.
Common Mistakes I See Repeatedly
After reviewing hundreds of TIA attempts, here are the patterns of failure:
Mistake #1: The "It's Too Hard So We'll Wing It" Approach
What I See: Organizations acknowledging Schrems II exists, then continuing business as usual with perhaps updated SCCs.
The Risk: Complete inability to defend transfers under regulator scrutiny
Real Impact: A client faced investigation in 2022. When asked for their TIA, they produced... updated SCCs. That's it. €275,000 fine plus €180,000 in legal fees.
Mistake #2: The "We'll Just Encrypt Everything" Misconception
What I See: Organizations thinking encryption alone solves Schrems II
The Reality: Most encryption implementations still allow the data importer to access plaintext data, which means government access is still possible.
Effective Encryption Example:
INEFFECTIVE:
EU → Encrypted Transit → US Server → Decrypted for Processing → US Company Has Keys
(Government can compel US company to provide keys)Mistake #3: The "One-Size-Fits-All TIA" Template
What I See: Organizations using a single TIA template for all transfers
The Reality: Every transfer is contextual. Your Salesforce TIA cannot be copy-pasted for AWS.
What Actually Works:
Element | Must Be Transfer-Specific | Can Be Standardized |
|---|---|---|
Data categories | ✓ Different for each transfer | ✗ |
Destination law analysis | Partial (same country, different analysis depth) | Partial (same country framework) |
Risk assessment | ✓ Depends on data sensitivity and context | ✗ |
Supplementary measures | ✓ Must match specific risks | ✗ |
Decision rationale | ✓ Transfer-specific balancing | ✗ |
Methodology framework | ✗ | ✓ Can use consistent approach |
Mistake #4: The "Set It and Forget It" Trap
What I See: Organizations doing a TIA in 2021 and never updating it
The Reality: Laws change. Business changes. Risk changes.
Update Triggers I Use:
Quarterly: Review for any legal changes in destination countries
Annually: Full reassessment of all transfers
Immediately: When any of these occur:
New surveillance law in destination country
Court ruling affecting transfers
Change in data processing purpose or volume
New DPA guidance
Government demand for data
Vendor acquisition or ownership change
Migration to new infrastructure or jurisdiction
The Tools and Resources That Actually Help
Here are the resources I actually use (not just recommend):
Essential Reading:
EDPB Recommendations 01/2020 - Supplementary measures for international transfers
EDPB Recommendations 02/2020 - European Essential Guarantees for surveillance measures
Your country's DPA guidance - Most have published TIA guidance
Academic analyses - Search for law review articles on your destination country's surveillance laws
Practical Tools:
Tool/Resource | Purpose | Cost | My Assessment |
|---|---|---|---|
OneTrust TIA Module | Structured TIA workflow | ~$30k+/year | Good for large organizations with many transfers |
IAPP Resource Center | Legal research and templates | $499/year membership | Excellent value for detailed guidance |
DLA Piper Data Protection Laws | Country-by-country law comparison | Free | Great starting point for destination law research |
TIA.schrems.at | Free TIA guidance tool | Free | Useful but generic; needs customization |
Custom Spreadsheet | Transfer inventory and tracking | Free (your time) | What I use for most clients - customizable and flexible |
My Personal TIA Toolkit:
I maintain a living document library:
Template TIA report (customized per transfer)
Country law analysis database (updated quarterly)
Supplementary measures decision tree
Risk assessment questionnaire
Documentation checklist
Update tracking log
Time Investment for a Proper TIA:
Organization Size | Number of Transfers | First TIA Time | Subsequent TIAs | Annual Review Time |
|---|---|---|---|---|
Small (<50 employees) | 3-10 | 40-60 hours | 8-12 hours | 20-30 hours |
Medium (50-500) | 10-50 | 80-120 hours | 12-20 hours | 40-80 hours |
Large (500+) | 50-200+ | 200-400 hours | 16-30 hours | 120-200 hours |
Yes, it's time-consuming. Yes, it's expensive. But compared to regulatory fines and legal fees from getting it wrong? It's a bargain.
The Future: Where Schrems III Might Take Us
I spend a lot of time thinking about what's next. Here's what keeps me up at night:
Potential Schrems III Triggers:
EU-US Data Privacy Framework: The Privacy Shield replacement announced in 2023. Many expect it to face legal challenge—potentially becoming Schrems III.
UK Adequacy Decision: Could be challenged, especially as UK law diverges from EU standards post-Brexit.
Emerging Technologies: How does Schrems II apply to AI training data? Quantum computing? Decentralized systems?
What I Tell Clients:
Build your compliance program assuming current mechanisms could change. That means:
Architectural flexibility: Can you quickly pivot to EU-only processing if needed?
Vendor diversity: Don't be locked into single providers in problematic jurisdictions
Technical capabilities: Invest in encryption and data protection that works regardless of legal framework
Documentation discipline: Maintain records that demonstrate ongoing good-faith compliance
"The only certainty in international data transfer law is uncertainty. Build for resilience, not just current compliance."
Your Action Plan: Getting Started Today
Based on 80+ TIAs, here's the practical path forward:
Week 1: Discovery
[ ] List all third-party services that might process EU personal data
[ ] Identify where data is actually stored and processed (not just where vendor is headquartered)
[ ] Create initial transfer inventory spreadsheet
[ ] Identify your highest-risk transfers (health data, financial data, sensitive categories)
Week 2-4: Legal Foundation
[ ] Review and update all SCCs to 2021 version
[ ] Verify SCC module selection is correct
[ ] Obtain signed SCCs from all data importers
[ ] Identify transfers that can't use SCCs (need BCRs, consent, etc.)
Week 5-8: First TIA
[ ] Select your highest-risk or highest-value transfer
[ ] Research destination country laws thoroughly
[ ] Conduct structured risk assessment
[ ] Identify necessary supplementary measures
[ ] Document everything
[ ] Get legal review
Week 9-12: Scale and Implement
[ ] Use first TIA as template for similar transfers
[ ] Implement supplementary measures
[ ] Test effectiveness of technical measures
[ ] Create monitoring and review schedule
[ ] Train relevant teams on requirements
Ongoing:
[ ] Quarterly legal landscape review
[ ] Annual full reassessment
[ ] Continuous monitoring of vendor changes
[ ] Documentation updates
Final Thoughts: Why This Matters Beyond Compliance
It's easy to see Schrems II and TIAs as bureaucratic obstacles. I've certainly felt that frustration.
But here's what I've come to understand: this is fundamentally about human rights.
The European Court didn't create Schrems II to annoy businesses. They created it because unchecked government surveillance is a threat to democracy, to individual autonomy, to human dignity.
When we conduct a transfer impact assessment, we're not just checking regulatory boxes. We're making a conscious choice about whether we're comfortable with the possibility that someone's personal data—data they trusted us with—might be accessed by foreign governments without adequate protections.
I think about this when I'm up late working on a particularly complex TIA. I think about the data subjects—real people with real privacy expectations. I think about whether I can defend my recommendation to them, not just to regulators.
In 2023, I spoke at a conference about Schrems II compliance. After my talk, a woman approached me. She was a journalist who had fled her home country after covering corruption. She was terrified that her data—held by a European organization—might be accessible to the government she'd escaped.
"Thank you for taking this seriously," she said. "It's not theoretical for people like me. It's survival."
That conversation changed how I approach TIAs. It's not about compliance. It's about protecting people.
When you conduct your transfer impact assessment, remember: there are real people depending on you to get this right.
Do the hard work. Do the research. Implement the measures. Document the decisions.
And if you can't protect the data in a particular transfer—have the courage to say no.
Because in the end, compliance isn't about avoiding fines. It's about earning and maintaining trust.
And in a world of increasing surveillance, data breaches, and privacy violations, trust is the most valuable asset any organization can have.