The Regulatory Landscape
Beyond GDPR
EU Data Act · DORA · ePrivacy — three regulations, three different slices of the data world your Data Vault already handles
"Regulation" (EU sense) — a specific legal instrument that is directly binding in all 27 EU member states without requiring national legislation to implement it. A Directive says "member states, make a law that achieves this goal." A Regulation IS the law, identical everywhere, the moment it enters into force.
GDPR is a Regulation. The EU Data Act is a Regulation. DORA is a Regulation. ePrivacy is currently still a Directive — which is one reason it's messier in practice.
"Data Act" — "Act" in EU law is just an English word for a legislative instrument (same usage as "EU AI Act" — both are formally Regulations, but commonly called Acts). "Data Act" = legislation about data — specifically, who can access, share, and use non-personal machine-generated data.
Think of it as property law for data that GDPR doesn't cover. GDPR says: here are the rights of people whose personal data you process. The Data Act says: here are the rights of people who generate data through the devices they use.
The EU Data Act says: if you use a connected device — a thermostat, a factory machine, a car — you have the right to access the data that device generates. You can share it with a third party of your choice. Manufacturers can't just lock that data inside their ecosystem and sell it back to you.
Your device, your data. Simple.
The Data Act creates data access rights similar to the way open banking (PSD2) created payment data access rights. It targets IoT and industrial data — the billions of data points generated by connected devices every day.
The regulation defines: who can request the data (the user of the device), who must provide it (the manufacturer/service provider), under what terms (FRAND — Fair, Reasonable, And Non-Discriminatory), and how it must be portable (cloud switching without lock-in barriers).
FRAND is borrowed from telecommunications patent law — the standard used for essential patents on mobile phone technology. In data: you can't charge unreasonable prices for data access that users are legally entitled to.
Key provisions:
- Articles 3–7: Users of connected products have a right of access to data generated by those products in real-time, in a structured, machine-readable format.
- Article 8: Data holders sharing data with third parties at the user's request must do so under FRAND terms.
- Articles 23–31: Cloud switching and portability. Cloud providers must enable customers to switch to a competing provider within a defined timeframe, without punitive exit fees or technical lock-in.
Enforcement timeline:
- Sep 12, 2025: Most provisions — IoT data access rights, data sharing obligations, cloud switching/portability
- Sep 12, 2026: Design obligations for new connected products
- Sep 12, 2027: Contractual terms for B2B data sharing; full enforcement
The FRAND requirement creates conceptual complexity: what counts as "reasonable" pricing for data access? The regulation doesn't specify a formula — interpretation will emerge through enforcement cases and guidance.
The cloud switching provisions directly challenge hyperscaler business models. AWS, Azure, and GCP have historically benefited from egress fees and proprietary APIs that make migration painful. The Data Act requires this to be genuinely feasible — with architectural implications for how data platforms are designed (vendor-neutral APIs, portable data formats, no proprietary lock-in at the schema level).
ScaleFree's published position: Data Vault 2.0 is well-suited for Data Act compliance because its layered architecture maintains data provenance at every step, and its vendor-neutral design principles (methodology, not platform-specific) support portability. This is a key advantage for BI consultants advising European clients.
"Digital" — specifically about information and communication technology (ICT) systems — servers, software, networks, cloud providers, SaaS tools. Not "digital" in the vague marketing sense.
"Operational" — the ongoing, day-to-day functioning of a system, as opposed to a one-time event or a design quality.
"Resilience" — the ability to absorb shocks and recover, not just the ability to avoid them. Like a building designed to flex in an earthquake (resilient), not just one designed to avoid earthquakes (avoidance). A resilient system doesn't promise zero failures; it promises to keep functioning or recover quickly when failures occur.
So: DORA = the EU rule that financial entities must keep their digital systems running — or recover fast — even when things go wrong. And they must prove it.
DORA tells banks and financial firms: you must have a plan for when your technology fails — not just for fires and floods, but for cyberattacks, software bugs, cloud outages, and supplier failures. And you must be able to prove it to regulators.
It's the financial sector's answer to the question: "What happens if your IT breaks?"
DORA has five pillars:
- ICT risk management framework — identify assets, assess risks, implement controls
- Incident classification and reporting — major ICT incidents must be reported to financial regulators
- Digital operational resilience testing — regular testing including penetration tests for significant institutions
- ICT third-party risk management — document all supplier relationships, monitor ongoing risk
- Information sharing — financial entities can share cyber threat intelligence with each other
DORA applied from January 17, 2025, giving financial firms two years from adoption to comply (entered into force January 2023, obligations applied from January 2025).
Key obligations for data infrastructure:
- Article 6: Maintain a register of all ICT assets and their interdependencies — know what you have and how it connects.
- Article 17: Classify and report ICT incidents by severity to the relevant financial supervisory authority.
- Article 25: Digital operational resilience testing proportionate to firm size. For large institutions: TLPT (Threat-Led Penetration Testing) — red team exercises against live production systems.
- Articles 28–44: Third-party risk. Critical ICT Third-Party Providers (CTPPs) may face direct EU-level oversight — supervisory authorities can examine cloud providers directly.
The CTPP framework (Articles 28–44) is novel: EU financial regulators can now directly examine the ICT practices of US cloud providers serving European banks. AWS, Microsoft Azure, and Google Cloud are likely among the first designees. Their EU sovereign cloud offerings are partly a response to this oversight exposure — "look, we have EU-controlled infrastructure" — but the CLOUD Act problem (US government can compel access to data wherever it's stored) remains unresolved.
For ScaleFree specifically: as a data consultancy working with financial clients, DORA's third-party provisions mean clients must document and manage the risk that ScaleFree's people and tools represent. This is not a barrier — it's a differentiator. A consultancy that understands DORA, can articulate its architecture in DORA terms, and has standardized delivery methods (like datavault4dbt) is easier for a bank to onboard under DORA compliance than a consultancy that doesn't.
Data Vault's insert-only architecture directly supports DORA's incident reconstruction requirements — and this is a genuine professional advantage:
- Temporal reconstruction:
load_datetimestamps on every Satellite row mean you can reconstruct the exact state of any data at any point in time. For a DORA incident investigation: what did the system know at 09:45? - ICT asset tracing:
record_sourceon every row identifies the source ICT component. You can trace a data anomaly back to its origin system. - Non-destructive history: Satellite append-only design means the evidence trail cannot be accidentally destroyed by a normal data update. No UPDATE statement exists.
- Documented data flow: Staging → Raw Vault → Business Vault → Mart is a documented transformation chain. Regulators don't just want to know what happened — they want to see the chain of custody.
"e" = electronic. "Privacy" = the right to be left alone, to control what others know about you in a given moment.
ePrivacy = privacy in the context of electronic communications — not privacy in general, but specifically the moment when data moves over a network, gets stored on a device, or when you receive an unsolicited marketing message.
Think of it as the traffic law for data in motion, not the property law for data at rest. GDPR governs what you do with data after you have it. ePrivacy governs whether you were allowed to collect it the way you did.
ePrivacy says: before you put a cookie on someone's browser, before you send them a marketing email, before you log their phone call metadata — you need their permission. It's the "please don't track me without asking" law.
ePrivacy operates as lex specialis — the specific law for electronic communications. When both GDPR and ePrivacy apply to the same situation, ePrivacy takes precedence on its specific question.
For cookies: ePrivacy governs the consent-before-placing question. GDPR governs what you do with the data afterward. You need both to be right. Cookie banner? That's ePrivacy. Data retention policy? That's GDPR.
Lex specialis is the same principle from Roman law you encountered in the GDPR context: the more specific law takes precedence over the more general law for the specific situation it addresses.
As a Directive, ePrivacy varies by national implementation. The core concepts: "terminal equipment" (your device) cannot have information stored on it without clear consent, except for strictly necessary purposes.
Exempt (strictly necessary): session management cookies, shopping cart cookies, authentication cookies — these keep the service functioning.
Require consent: analytics cookies (Google Analytics), advertising cookies, personalization cookies, third-party tracking pixels.
Germany's implementation (TDDDG (formerly TTDSG), in force December 2021) has specific requirements around cookie consent that affect what data legitimately enters an analytics pipeline. If a client's DV ingests website analytics, the consent chain upstream of data collection matters.
The ePrivacy Regulation — meant to modernize the Directive and align it with GDPR — was formally withdrawn by the EU Commission in February 2025 after 8 years of failed negotiations. The advertising industry, telecom operators, and privacy advocates had irreconcilable positions. An 8-year stalemate in the Council ended with withdrawal.
The Commission proposed a "Digital Omnibus" package in late 2025 that may fold some ePrivacy territory into a broader legislative revision. Whether this succeeds in the 2025–2027 legislative cycle is genuinely uncertain.
What this means in practice: Know the Directive exists. Know it's the cookie law. Know the Regulation was withdrawn. Know cookie consent requirements remain, just unevenly implemented across member states. This is current affairs, not textbook content — it signals awareness of the regulatory space.
"GDPR gets all the attention, but European clients are dealing with a stack of overlapping regulations — the Data Act for IoT data portability, DORA for financial ICT resilience, and the AI Act on top. What they all share is a requirement for data lineage and auditability. That's what Data Vault delivers by design, not as a feature added later."
"The Data Act is a significant but often overlooked regulation for data engineering. It creates data access and portability rights for IoT data that didn't exist before September 2025, and it requires cloud switching without vendor lock-in. Data Vault's vendor-neutral design and layered architecture map directly to both requirements — and ScaleFree has published explicitly on this alignment."
"DORA is especially interesting from a Data Vault perspective. Financial firms must demonstrate their ICT systems can be reconstructed after an incident — regulators want to see the exact state of data at any point in time. Data Vault's insert-only design and load_date timestamps mean you can do exactly that without any additional infrastructure. The compliance capability is the base architecture."
"ePrivacy is the cookie law — technically the lex specialis for electronic communications, taking precedence over GDPR for consent before placing tracking technologies. Worth noting: the Regulation that was meant to modernize it was withdrawn in February 2025, so we're still running on the 2002 Directive with national implementations. For a Data Vault client ingesting web analytics or telecom data, ePrivacy determines what data legitimately enters the pipeline upstream — PII Satellite isolation handles it downstream."
A legal background changes how these regulations read — from checklists to structural patterns. The pattern is that Data Vault's architectural choices — record_source, load_date, insert-only, layered separation — weren't designed as compliance features, but they're exactly what regulators are asking for across GDPR, DORA, the Data Act, and the AI Act. That's not coincidence. It's the same underlying principle: if you can reconstruct what happened and where data came from, you can prove compliance.
The ePrivacy Regulation was formally withdrawn in February 2025 after about eight years of failed negotiations — the Commission accepted that consensus between the advertising industry, telecom operators, and privacy advocates wasn’t achievable in the current cycle. A Digital Omnibus package is in discussion, but it’s early.
In practice, cookie consent requirements remain in place via the 2002 ePrivacy Directive, just implemented unevenly across member states. The Directive still applies — the Regulation that was supposed to replace it never materialized.
These are two different regulations that are commonly confused:
- DGA (Regulation 2022/868, in force Sep 2023): Enables re-use of public sector data through trusted intermediaries. Three pillars: public sector data re-use, data intermediation services, data altruism. For the DV: provenance metadata needed for data arriving from public sector sources.
- Data Act (Regulation 2023/2854, in force Sep 2025): IoT device data access rights, FRAND sharing, cloud portability. The one covered in this tutorial.
One-line disambiguation: DGA = public sector data intermediation. Data Act = connected device data access rights. Both part of the EU data strategy; different subject matter.
Match each scenario to the regulation that primarily applies. Some scenarios may have more than one correct answer — pick the most specific one.
One of these four statements contains a misconception. Which one?
A fintech client's supervisory authority is conducting a DORA audit. They want to know: at 09:45 on the day of a system incident, what was the state of the client's position data?
Which Data Vault features support answering that question? Match each feature to what it provides in this scenario.
load_date timestamp on every Satellite rowrecord_source on every Hub, Link, and Satellite row