Where Data Lives,
Whose Laws Follow
Data sovereignty, cross-border transfers, and how auditors verify it all
You learned what data must be protected (GDPR). You learned what rules govern sharing (Data Act, DORA). But none of that answers the question that keeps European CTOs awake: where does the data physically live, and whose laws follow it there?
Sessions 5 and 7 covered the regulatory layer — the rules themselves. GDPR says protect personal data. The Data Act says share IoT data. DORA says ensure operational resilience.
This session covers the operational layer beneath — the mechanisms that make those rules enforceable in practice:
Data Sovereignty — Who has authority over data based on where it lives?
Cross-Border Transfers — What legal tools allow data to move between jurisdictions?
Audit Frameworks — How do auditors verify that all of this actually works?
"GDPR, the Data Act, and DORA all set rules — but compliance mechanisms like data sovereignty, cross-border transfer tools, and audit frameworks are what make those rules operational. Understanding both layers is essential: what the regulation requires, and what mechanisms enforce it in practice."
AWS has a data center in Frankfurt. German data on German soil. Problem solved, right? Not exactly. The company that owns that data center is headquartered in Seattle.
"Sovereignty" — from Old French soverain, from Latin superanus ("above all others"). In political theory: the supreme authority within a territory. A sovereign state decides its own laws within its borders.
Data sovereignty applies exactly this idea to data: the principle that data is subject to the laws of the jurisdiction where it is collected or stored. The "sovereign" — the government with supreme authority — gets to decide what happens to data within its territory. The problem is that digital data crosses borders in ways that physical territory never could.
When you store data somewhere, the government of that "somewhere" gets a say in what happens to it. That is data sovereignty. The tricky part: if the company storing your data is from a different country, that country may also claim a say. Two governments, one piece of data, conflicting rules.
Data sovereignty has three dimensions, and all three must be satisfied:
Legal sovereignty — Which country's laws apply to data stored in a specific location? If data is on a server in Germany, German law applies. But if the server operator is American, US law may also apply.
Infrastructure sovereignty — Who owns and operates the physical servers? An EU company using AWS still depends on American-owned infrastructure.
Political sovereignty — Can a foreign government compel access? The US CLOUD Act says yes: if you are an American company, the US government can demand data you hold, wherever in the world you store it.
Gaia-X — A European initiative for federated, sovereign data infrastructure. Not a cloud provider itself — it defines standards and trust frameworks so European organizations can share data under European rules.
Sovereign cloud offerings — AWS European Sovereign Cloud, Azure EU Data Boundary, Google Sovereign Cloud. These address infrastructure sovereignty but the legal sovereignty question under the CLOUD Act remains contested.
EUCS debate — The EU Cybersecurity Certification Scheme for Cloud Services is debating whether the highest certification level should require EU ownership and control.
The US CLOUD Act (2018) creates a direct conflict with GDPR. Under the CLOUD Act, a US company must comply with a US government demand for data even if that data is stored on EU soil. Under GDPR, transferring EU personal data to the US without a valid legal basis is illegal. The company is caught between two sovereigns issuing contradictory commands.
For a BI consultant: Cloud provider selection is not just a technical decision. It is a legal architecture decision.
"Data sovereignty is not just about where your servers are — it has three dimensions: legal, infrastructure, and political. The CLOUD Act means that data stored on a US provider's EU servers may still be accessible to US authorities. That is a legal architecture problem, not just an infrastructure problem."
One Austrian law student has personally destroyed two transatlantic data transfer agreements. His name is Max Schrems, and he is probably the single most influential privacy activist in history.
The Schrems cases are named after a person, not a legal concept. But the pattern they established is the concept: no data transfer agreement between the EU and the US is safe until US surveillance law fundamentally changes.
The pattern is clear: every EU-US data transfer framework has been struck down within a few years. This means data warehouse architectures should be designed so that data can be re-localized if needed. Cloud-agnostic design — one of Data Vault's principles — is a compliance asset.
"The Schrems cases have shown that EU-US data transfer agreements are structurally fragile — Safe Harbor lasted 15 years, Privacy Shield lasted 4, and the current Data Privacy Framework faces an anticipated challenge. For data architecture, this means building for portability, not assuming any single transfer mechanism will last."
A French company stores German customer data in an AWS data center in Ireland. The analytics team in India needs access. The backup replicates to Singapore. How many cross-border transfers just happened?
The EU treats every movement of personal data outside the EEA as a "transfer" that requires a legal basis. Think of the EEA as a walled garden — data moves freely inside, but every exit needs a gate pass.
The legal tools that serve as gate passes are called transfer mechanisms. There are four main categories.
Analogy: A visa-free travel agreement. The EU says "that country's laws are good enough." No extra steps needed.
How it works: The EU Commission evaluates a country's entire data protection legal framework: independent supervision, judicial redress, safeguards against mass surveillance.
Currently adequate: Andorra, Argentina, Canada (commercial), Faroe Islands, Guernsey, Israel, Isle of Man, Japan, Jersey, New Zealand, Republic of Korea, Switzerland, UK, Uruguay, and the US under the DPF (for certified organizations only).
Effort: None — automatic once the country is on the list.
Risk: Low (but can be revoked — see Schrems saga).
Analogy: A standard visa with a background check. Both parties sign a pre-approved contract template.
How it works: The contract binds the data importer to GDPR-level protection. After Schrems II, the contract alone is not enough — you must conduct a Transfer Impact Assessment (TIA) to verify that the destination country's surveillance laws do not undermine the contractual promises.
If TIA fails: You need supplementary measures (encryption, pseudonymization, data localization).
Effort: Medium — TIA per transfer.
Risk: Medium (depends on TIA outcome).
Analogy: A multinational getting a custom travel arrangement. The company writes its own internal rules for handling data across its global offices.
How it works: Must be approved by a lead supervisory authority. Typically used by large multinationals with significant data flows between group companies. More flexible than SCCs but much harder to set up.
Effort: High — months of approval.
Risk: Low (once approved).
Analogy: An emergency travel exception — allowed, but you cannot build a regular route on it.
How it works: Narrow exceptions for specific situations: explicit consent, contractual necessity, important public interest.
Key rule: Not for systematic or regular transfers. "I need to transfer medical records for an emergency surgery" qualifies. "We routinely transfer all European customer data to our US analytics team" does not.
Effort: Low per transfer.
Risk: High (not for regular use).
| Mechanism | How It Works | Effort | Risk Level |
|---|---|---|---|
| Adequacy Decision | EU says the country is safe | None | Low (but revocable) |
| SCCs + TIA | Standard contract + risk assessment | Medium | Medium |
| BCRs | Custom corporate policy, authority-approved | High | Low (once approved) |
| Derogations | Case-by-case exceptions | Low | High (not for regular use) |
A US law says: if you are an American company, we can demand your data — wherever in the world you store it. The law is called the CLOUD Act, and it is the reason "just use an EU data center" is not a complete answer.
"CLOUD Act" — Clarifying Lawful Overseas Use of Data Act (2018). Despite the name, it has nothing to do with cloud computing as a technology. It "clarifies" that US law enforcement warrants apply to data held by US companies regardless of the data's physical location.
The CLOUD Act says: "US companies must hand over data to the US government, wherever it is stored." GDPR says: "You cannot transfer EU personal data to the US without a valid legal basis."
Scope: Applies to any company subject to US jurisdiction — not just US-headquartered companies.
What it covers: All "electronic communications, records, or other information" in the provider's "possession, custody, or control."
The sovereign cloud gap: AWS European Sovereign Cloud, Azure EU Data Boundary, and Google Sovereign Cloud create EU-controlled entities. Whether they are truly beyond CLOUD Act reach has not been fully tested in court.
Regulations say what you must do. Auditors verify that you actually did it. An audit framework is the checklist they use — and Data Vault is designed to pass it.
"Audit" — from Latin auditus, "a hearing." Originally, accounts were verified by being read aloud to an auditor who listened.
"Framework" here means the structured set of criteria the auditor checks against. Like a building inspector's code book.
| Audit Area | What They Check | How Data Vault Delivers |
|---|---|---|
| Data Lineage | Can you trace any data point back to its source? | record_source + load_date on every row. |
| Change History | Is data history preserved? | Append-only Satellites. Nothing overwritten. |
| Access Controls | Who can see what data? | PII Satellites have restricted access. |
| Data Quality | Are validation rules documented? | Business Vault applies and documents business rules. |
| Process Docs | Are data flows documented? | Standardized loading patterns + datavault4dbt. |
Click any framework to expand details.
The dominant information security standard in Europe. Provides a systematic approach to managing sensitive information: risk assessment, access controls, incident management, business continuity.
Think of it as the general health checkup for information security. Organizations get certified by external auditors — the certificate is valid for 3 years with annual surveillance audits.
An extension of ISO 27001 specifically for privacy. Maps directly to GDPR requirements: data processing records, DPIAs, data subject rights handling, breach notification procedures.
If ISO 27001 is the general health checkup, ISO 27701 is the specialist examination for privacy compliance.
US-originated (AICPA) but increasingly required by European multinationals. Evaluates five "Trust Service Criteria": security, availability, processing integrity, confidentiality, and privacy.
Two types: Type I (point-in-time), Type II (over a period, typically 6-12 months). Type II is the one that matters — it proves controls actually work over time, not just that they exist on paper.
International Standard on Assurance Engagements — the international equivalent of SOC 1 (ISAE 3000 covers SOC 2’s territory). Issued by IAASB (International Auditing and Assurance Standards Board).
Often required when a service organization (like a data warehouse provider) needs to demonstrate controls to its clients' auditors. ScaleFree clients may request ISAE 3402 reports as part of vendor due diligence.
"Data Vault is effectively audit-ready by design. Every row carries record_source and load_date for lineage, Satellites are append-only for full change history, and PII isolation enables fine-grained access control."
GDPR, the AI Act, DORA, and BCBS 239 were written by different people, at different times, for different purposes. And yet they all independently arrived at the same requirement: data lineage.
4 Regulations → 1 Requirement
GDPR • AI Act • DORA • BCBS 239 — all independently require data lineage.
| Regulation | Article / Principle | What It Requires |
|---|---|---|
| GDPR | Art. 30, 15, 17 | Know where personal data lives, where it came from, be able to find or delete it |
| EU AI Act | Art. 10 | Document data provenance, transformation steps, quality measures |
| DORA | Art. 6 | Map information assets, identify dependencies, document data flows |
| BCBS 239 | Principle 3 | Risk data traceable to source with documented transformation steps |
record_source on every row → identifies the origin system.
load_date on every row → identifies when data entered each layer.
Insert-only Satellites → full history preserved.
Hash keys → deterministic identifiers verifiable across systems.
This is not a compliance feature added to Data Vault. It is the base architecture.
"A key strength of Data Vault for European clients is that GDPR, the AI Act, DORA, and BCBS 239 all independently require data lineage — and Data Vault provides it by architecture, not by adding features."
"GDPR gets all the attention, but ScaleFree's European clients are dealing with a stack of overlapping regulations. What they all have in common is a requirement for data lineage and auditability, which is exactly what Data Vault provides by design."
Exercise 1 — Cross-Border Scenario Classification
Match each data transfer scenario to the correct legal mechanism.
Exercise 2 — Audit Question Matching
An auditor asks these questions. Match each to the Data Vault feature that answers it.
Exercise 3 — Sovereignty Risk Assessment
Classify each cloud architecture by sovereignty risk level for EU personal data.