The Way Out of the Cloud: Why the Data from Your Machines Belongs to You, What a Cloud Migration May Cost From January — and Why That Legal Question Has Very Technical Consequences

The Hook: The Invoice That Kills the Migration

Picture a situation that has played out thousands of times in European companies over the past fifteen years. A mid-sized firm runs its data platform on a large hyperscaler. The contracts tick along, costs creep upward, and at some point someone produces a spreadsheet: the same workload would be noticeably cheaper with a different provider. So a migration study begins. And then comes the moment when someone on the architecture team calculates the number that ends everything — the cost of data egress. Moving eighty terabytes of data lake out costs, depending on tariff and region, a five-figure sum, purely for the privilege of letting your own data leave the data center it happens to be sitting in. On top of that, part of the application estate is built on proprietary managed services with no equivalent at the destination. The migration would be not just expensive but a rebuild. The project is postponed. Permanently.

This pattern has a name: vendor lock-in. In economic terms it is a switching-cost barrier, and switching-cost barriers are to a market what friction is to a mechanical system. They make a decision, once taken, persist longer than it deserves to. If enough customers are stuck, price competition loses its disciplining effect — not because the provider is good, but because leaving costs more than staying.

The European Union answered this pattern with a regulation that has attracted far less attention than the GDPR or the AI Act, but whose practical effect on a company's IT landscape may well be more far-reaching: the Data Act, formally Regulation (EU) 2023/2854 on harmonised rules on fair access to and use of data. It was published in the Official Journal on 22 December 2023, entered into force on 11 January 2024, and has applied since 12 September 2025.

Two dates make this piece timely right now. The first is eleven days in the past: since 12 September 2026, every newly placed connected product is subject to the obligation of access by design — machines must be built so that their users can reach the data they themselves generate. The second is just under four months ahead: from 12 January 2027, a cloud provider may charge nothing at all for a switch to a competitor or back to the customer's own data center. No egress fee, no migration charge, nothing.

The Data Act is therefore one of those rare cases in which a legislator does not prohibit a behavior but abolishes a piece of market friction. It is economic law conceived like systems architecture. This article walks through the entire regulation: the logic of data access for connected products, the limits set by trade secrets and safety requirements, the switching regime for cloud and edge services with all its deadlines, the protection against third-country access, the German enforcement architecture — and finally the question of what will survive the Digital Omnibus.

Part 1: The Core Concept — Data as a Co-Product

Who Owns a Sensor Reading?

The legally most interesting property of data is that no one owns it. That sounds trivial but has enormous consequences. A physical object has an owner; a text has an author; an invention has a patent holder. A temperature reading from a refrigeration unit has none of these. It is not a work, not an invention, not a thing. It is simply a fact, and facts cannot be owned in law.

In practice this produced a simple rule for years: whoever actually holds the data decides about it. Not by virtue of ownership, but by virtue of technical control. The maker of an agricultural machine, an elevator, a machine tool or a connected vehicle installed the sensors, operated the telemetry pipeline, stored the data in its own cloud — and was free to determine in its terms what the customer got to see. Often that was: a web interface, a dashboard, a few PDF reports. What the customer did not get was the raw data stream in machine-readable form. And without that raw stream, the customer could not engage an independent maintenance provider doing predictive maintenance, could not build its own fleet analytics, could not feed an insurer offering usage-based tariffs.

The Data Act intervenes here, and it does so with a conceptual move that carries the whole construction: it speaks of co-generated data. A sensor reading arises neither from the device alone nor from the user alone, but from the use of the device by the user. The manufacturer built the capacity to measure; the user caused the event that was measured. From this dual authorship the regulation derives not a property claim but something more pragmatic: a right of access. The user gets no right in the data, but a right to it.

This is a pattern that recurs throughout European digital regulation. Rather than creating new property rights — legally delicate, doctrinally contested, practically hard to delimit — the legislator creates rights of access, portability and switching. The same principle underpins Article 20 GDPR (data portability), the interoperability duties of the Digital Markets Act and, as we shall see, the whole of Chapter VI of the Data Act.

The Four Roles

To work with the regulation, four roles must be kept cleanly apart. They are the reason many projects stumble at the very start of a Data Act analysis.

Crucially, these roles are determined by contract, not by technology. Who counts as data holder follows from the web of contracts around the product and the related service — not from whose servers the data happens to sit on. In practice several data holders can coexist: the maker of the connected fridge and the provider of the app that regulates its temperature are both data holders, while there is only one user.

What Falls Within Scope — and What Does Not

Chapter II covers all raw and pre-processed data generated by the use of a connected product or related service that is readily available to the data holder — including the relevant metadata needed to interpret it. Both personal and non-personal data are covered.

Not covered is inferred or derived data. This is the central boundary and at the same time the regulation's largest interpretive construction site. The raw reading of an accelerometer is in scope. The wear index computed from it by a model embodying the manufacturer's engineering knowledge is not. The Commission illustrates the line with a memorable example: if someone watches a film on a connected television, the film itself is out of scope — data on screen brightness is squarely within it.

For anyone who builds systems, this is the decisive design question: where exactly, in my pipeline, does the line run between "pre-processed" and "derived"? A median filter over a sensor signal is pre-processing. A trained model that estimates remaining useful life from twenty signals is derivation. Between them lies a broad grey zone — aggregations, resampling, calibrations, unit conversions — where classification depends on the concrete design and where the case law of the coming years will be made.

Part 2: Chapter II in Practice — Access by Design

The Logic of the Deadlines

Chapter II applies in stages, and the stages must be kept apart because they are constantly confused in practice.

Since 12 September 2025 the access and provision duties apply in principle — including to legacy products already in the field. Anyone operating a connected product can demand access to the data it produces; the data holder must make it available without undue delay, of the same quality as is available to itself, easily, securely, free of charge, in a comprehensive, structured, commonly used and machine-readable format. For installed fleets this often means a provision path has to be created, if necessary through an API or an export mechanism.

Since 12 September 2026 — that is, for eleven days now — the sharper duty applies that the literature calls access by design. Article 3(1) requires that connected products placed on the market after that date be designed and manufactured, and related services designed and supplied, such that product data is accessible by default, easily, securely, free of charge and — where relevant and technically feasible — directly. "Directly" means: not via the detour of the manufacturer's cloud, but at the device itself, through a local interface.

The difference between these two stages is the difference between a retrofitting duty and a construction duty. The first can be discharged with an export endpoint. The second reaches into product development: anyone specifying a connected device today must answer, in the requirements document, which data arises, how it is structured, over which interface the user retrieves it, how authentication works and how the interface is secured. You no longer wait until a customer asks.

Read through the eyes of a security architect, the tension is immediate: a mandatory, locally reachable data interface on every device is new attack surface. This is exactly where the Data Act interlocks with the Cyber Resilience Act, which imposes lifecycle security requirements on the same class of devices (see Security by Default: The EU Cyber Resilience Act and the End of the Insecure Product). The two regulations work on the same device from opposite directions: the Data Act demands that data gets out; the CRA demands that nothing wrong gets in. A company treating them separately will inevitably build contradictory requirements.

Pre-Purchase Information Duties

The Data Act bites before the contract is signed. The seller or lessor must inform the user, in clear and comprehensible form, which type of data the product generates, in what volume and at what frequency, whether generation is continuous or real-time, how the data is stored, whether the manufacturer itself accesses it, and how the user can obtain it.

This is more than paperwork. It is an attempt to lift the data question out of the fine print and into the purchasing decision — the same move by which energy labels lifted power consumption out of the datasheet and onto the shelf. And it has a practical side effect: a company that buys can now state Data Act conformity as a procurement criterion. For anyone who writes tenders, a line on Article 3 belongs in the criteria catalogue from now on.

The Limits: Trade Secrets and Safety

Unlimited access rights would amount to expropriating engineering knowledge. The regulation therefore draws two limits.

The first is trade secrets. The data holder may require the user or third party to agree appropriate confidentiality measures; if these are not observed, it may suspend provision. Under the current text, outright refusal is possible only where the holder demonstrates that it is highly likely to suffer serious economic damage — a high bar, designed as an exception.

The second is the safety of the product. Where disclosure of particular data could undermine the product's safety requirements and thereby cause serious adverse effects on the health, safety or security of persons, the data holder and user may limit provision. Those requirements must, however, be anchored in Union or national law — it is not enough that the manufacturer considers them important.

In both cases there is a duty to notify the competent national authority, and the user may challenge the decision before a court, with the authority, or before a certified dispute settlement body.

The Decisive Limit on Use

There is one limitation that looks technically unremarkable and carries the greatest competitive charge: the data obtained may not be used to develop a competing connected product. Competition in related services and in the aftermarket — maintenance, repair, insurance, analytics — is expressly permitted and is indeed the purpose of the regulation. Competition in the product itself is not.

This line is the compromise that holds the whole structure up. Without it no manufacturer would have an incentive to develop sensing and data processing, since every competitor could learn from it. With it, the return on innovation stays with the manufacturer while the service markets are opened. Whether the boundary between "competing product" and "aftermarket service" is as sharp in practice as it sounds on paper is an open question — for software-defined products whose function emerges from updates, it will inevitably blur.

Finally: the data holder may not use non-personal data generated by the product without the user's agreement. That is a remarkable inversion. For non-personal data no comparable limit previously existed; here it arises purely from the contractual relationship with the user.

Part 3: Chapters III to V — The Institutional Frame

Chapter III: When the Law Compels Sharing

Chapter III does not govern whether data must be shared but how, once another norm — the Data Act itself or a sectoral statute — imposes a provision duty. The standard is fair, reasonable and non-discriminatory (FRAND) terms, a principle borrowed from standard-essential patent law.

In return, the data holder may request reasonable compensation, which may cover the costs of making the data available as well as technical costs of dissemination and storage. Toward micro enterprises, SMEs and not-for-profit research organisations, compensation is capped at the bare costs incurred — a deliberate redistribution in favor of smaller market participants that runs through the whole regulation.

Chapter IV: Unfairness Control Between Businesses

Chapter IV is legally the most radical part, because it intervenes in B2B contractual freedom — an area where European law is traditionally reticent. The hook is the unilaterally imposed term: a condition on data access and use that one party imposes on the other with no genuine opportunity to negotiate, the classic take it or leave it.

The regulation contains a non-exhaustive list of terms that are always unfair (such as excluding liability for intent and gross negligence) and a list of terms presumed unfair (such as inappropriately limiting remedies for non-performance). An unfair term is invalid and, where possible, is severed from the contract; where the term is merely presumed unfair, the party that imposed it may rebut the presumption.

Anyone who has negotiated cloud framework agreements knows how much weight this section carries. It means the standard terms of an overwhelmingly strong provider no longer apply merely because they were signed.

Chapter V: The State in Exceptional Need

Chapter V allows public sector bodies to request data held by private companies where there is an exceptional need. The regulation distinguishes two scenarios. In a public emergency — natural disaster, pandemic, severe cyber incident — non-personal data should be requested first and, if that is insufficient, personal data too, which should be anonymised where possible. In non-emergency situations only non-personal data may be requested, and only where the body can show it could not obtain the data by other means.

Requests must be specific, transparent and proportionate, trade secrets must be protected, and the data must be deleted once no longer needed. One elegant detail is the once-only principle: the same data may not be requested repeatedly by different bodies, which is why all requests are published by the national data coordinator.

The compensation logic again follows the size gradation:

Part 4: Chapter VI — The Switching Regime, Read Technically

For anyone who builds or owns cloud architectures, Chapter VI is the heart of the regulation. It comprises Articles 23 to 31 and addresses providers of data processing services — digital services enabling ubiquitous, on-demand network access to a shared pool of configurable, scalable and elastic computing resources. The definition covers IaaS, PaaS and SaaS.

The Scope Trap

Before turning to the obligations, the awkward question is worth asking: is my service even a data processing service?

For virtual machines and object storage the answer is trivially yes. For a functional SaaS — a project management tool, a CRM, industry-specific planning software — it is anything but clear. Such services derive their value from business functionality, not from giving the customer access to underlying computing resources. Prevailing advisory practice therefore recommends an individual assessment per service — and anyone running a portfolio of thirty SaaS products has an inventory exercise on their hands that is rarely finished in an afternoon.

Article 23: The Prohibition of Obstacles

The principle sits in Article 23 and is deliberately broad: providers may not impose or maintain pre-commercial, commercial, technical, contractual or organisational obstacles that inhibit customers from

• terminating the contract,
• concluding a contract with a different provider,
• porting exportable data and digital assets,
• achieving functional equivalence at the destination,
• unbundling individual services from a wider bundle.

The last point deserves attention. The unbundling requirement strikes at one of the most effective lock-in strategies there is: the package whose attractive price holds only so long as everything is bought together.

All of this is flanked by a duty to cooperate in good faith that expressly binds both providers — source and destination. That is notable, because at the time of migration the destination provider usually has no fully formed contract with the customer at all.

Article 25: The Mechanics of the Deadlines

The operationally most important article describes a sequence best read as a state machine:

1. Notice period: a maximum of two months. The contract may not stipulate a longer period for initiating the switch. It begins when the customer notifies the provider of the desire to switch.
2. Transitional period: a maximum of 30 calendar days, starting when the notice period ends. During this time the provider must give reasonable assistance, maintain business continuity, provide clear information on continuity risks, and maintain a high level of security.
3. Exception for technical infeasibility: if the 30-day period is not technically feasible, the provider must notify the customer within 14 working days, give a duly justified explanation, and indicate an alternative period of no more than seven months. The duty of service continuity remains.
4. Retrieval period: at least 30 calendar days after the end of the transitional period, during which the customer may still retrieve its data.
5. Erasure guarantee: once the retrieval period expires, all exportable data and digital assets of the customer must be fully erased.

Added to this is an exhaustive specification of all categories of data and digital assets that can be ported — expressly including the categories excluded because of trade secret risks. That list belongs in the contract, not in a knowledge base.

Compute the worst case and you get a window of two months' notice plus seven months' transition plus one month's retrieval: ten months. That is no sprint. But it is a defined, enforceable, plannable period — and thus the opposite of what went before.

Anyone who writes exit strategies for regulated industries will immediately recognise the kinship with DORA, which requires exit strategies, minimum contractual content and concentration-risk analysis for the financial sector (see When IT Is Not Allowed to Fail: DORA and Digital Operational Resilience in Finance). DORA requires that a financial institution be able to plan an exit; the Data Act makes the exit possible and affordable in the first place. The two regimes mesh like a pair of gears.

Article 29: The End of Switching Charges

The financially most consequential article has a two-stage mechanic:

Two distinctions are decisive. First, switching charges are not the same as ordinary service fees. The running price for storage, compute and traffic in normal operation is untouched. What is prohibited is the surcharge that arises only because the customer is leaving. Second, early termination penalties under fixed-term contracts are a separate matter and remain possible in principle.

The economic effect is considerable, because egress fees were not merely a revenue line but above all a price signal that pushed every architectural decision toward "everything stays inside." Once that exit toll disappears, the calculus of multi-cloud, backup and archive strategies changes fundamentally: a second provider for cold data, or geographically distributed storage using erasure coding (see Eleven Nines: Erasure Coding, Reed-Solomon, and How the Cloud Makes Data Practically Unlosable), typically failed not on storage cost but on transfer.

Article 30: Functional Equivalence and Open Interfaces

The technically most demanding part differentiates by service model:

• IaaS providers must take measures so that a customer switching to a service of the same type achieves functional equivalence: for the same input, and for features both services share, the customer should obtain a materially comparable output. The Commission cites as an example tools for shifting computing workloads from one virtualization technology to another.
• PaaS and SaaS providers must make open interfaces available and, at minimum, export data in a commonly used, machine-readable format.

The difference is honest. For IaaS, equivalence is a realistic aim because the abstraction level — cores, block storage, networking — is broadly comparable between providers. For PaaS and SaaS it is not. A managed database with proprietary extensions, or a workflow engine with its own expression language, has no functionally identical counterpart anywhere else. So the regulation demands only data release in open form there — reconstructing the functionality stays with the customer.

One can read that as weakness. I am of the opinion that it is rather realism: the legislator demands what is technically enforceable and refrains from what it cannot decree. A law requiring functional equivalence for every SaaS would be either unfulfillable or a prohibition on innovation.

Added to this are transparency duties under Articles 26 and 28: providers must maintain an up-to-date online register of all relevant data structures, formats and interoperability specifications, and must disclose the jurisdiction to which their ICT infrastructure is subject and the measures they have taken against unlawful foreign governmental access.

Article 31: Exemptions

Exempt above all are services whose main features have been custom-built for an individual customer and are not offered at broad commercial scale. Even these services, however, remain bound by part of the Chapter VI obligations — the exemption is not a free pass.

Part 5: Chapters VII and VIII — Sovereignty and Interoperability

Protection Against Unlawful Third-Country Access

Chapter VII addresses a concern for anyone storing European data in the systems of international providers: what happens when an authority outside the EU wants access to non-personal data processed or stored in the Union?

The regulation does not prohibit cross-border data flows. It ensures that the protection applicable in the EU travels with the data. Where no international agreement governs the access, transfer or access is permitted only under specific conditions — the third-country decision must state reasons and be proportionate, the third country's legal system must offer certain guarantees, and the provider may involve the competent national body in the assessment. Providers must also take all reasonable technical, organisational and legal measures — encryption, audits, certification schemes — to prevent such access, and publish those measures.

This chapter is the non-personal sibling of the debate that has been conducted for personal data for years under the name Schrems (see The Man Who Toppled Three Agreements: Max Schrems, Transatlantic Data Transfers, and the Puzzle of Adequacy). The change of perspective is notable: where the GDPR protects the individual, Chapter VII protects the company — an interest that sits closer to "economic sovereignty" than to "fundamental rights."

Anyone wanting to prepare technically ends up quickly at the question of how to hold data so that access to the system is not automatically access to the content — customer-held key management, confidential computing, isolation models at the hypervisor level (see Betting on a Stranger's Code: Firecracker microVMs and the End of the Container-versus-VM Dilemma).

Interoperability

Chapter VIII lays down essential requirements for participants in common European data spaces: descriptions of data structures, formats and vocabularies must be publicly accessible, and the interoperability of data-sharing agreements — for instance via smart contracts — must be ensured. Vendors of smart contracts face their own requirements: correct execution of the agreed terms, robustness against manipulation, the ability to terminate in a controlled way.

At the same time the chapter prepares the ground for harmonised standards and open interoperability specifications for cloud services. The Commission may task European standardisation organisations with drafting them and, if that fails, adopt common specifications as a fallback. Without this standardisation track, Article 30 would remain a promise without a tool.

Part 6: Enforcement — and What the Digital Omnibus Wants to Change

The German Architecture

Enforcement rests with the Member States. Each designates one or more competent authorities; where there are several, one must act as data coordinator, the single point of contact.

Germany took its time and delivered in spring 2026: the Bundestag adopted the implementing act on 26 March 2026; the Datenverordnung-Anwendungs- und -Durchsetzungs-Gesetz (DADG) entered into force on 30 May 2026. It establishes a dual-track model: the Bundesnetzagentur is the competent authority and data coordinator, while the Federal Commissioner for Data Protection and Freedom of Information (BfDI) remains responsible for matters involving personal data. The Bundesnetzagentur's fining range extends to EUR 500,000; where the data protection supervisor acts within its remit, the GDPR range applies.

The comparison is instructive. In Ireland, ComReg and the CCPC are designated, with sanctions of up to 4% of annual EU turnover for undertakings; in the Netherlands, the ACM may impose fines of up to EUR 1,030,000 or 10% of EU-wide annual turnover, whichever is higher. Article 40 requires only penalties that are "effective, proportionate and dissuasive" — there is no Union-wide ceiling as under the GDPR.

The result is an enforcement landscape with substantial gradients. For companies with a European footprint, risk is not measured at the mildest location. For regulatory theory it is a familiar pattern: the Brussels effect works through market access, not through the size of the fine.

The Digital Omnibus

On 19 November 2025 the Commission proposed amendments to the Data Act as part of its Digital Omnibus simplification package. The most important in practice:

• Trade secrets: refusal is to be made easier. The qualifier "exceptional circumstances" would be removed entirely, and the likelihood standard lowered from "highly likely" to "likely." Refusal would also be expressly available where there is a high risk of unlawful acquisition, use or disclosure to third-country entities.
• Custom-made services: the exemption from the switching regime would be extended to custom-made services other than IaaS for contracts concluded on or before 12 September 2025.
• SMEs and small mid-caps: a lighter regime would apply to their non-IaaS data processing services, including the ability to provide for early termination penalties in fixed-term contracts.

In parallel, on the same day, the Commission published a draft recommendation on non-binding standard contractual clauses (SCCs) for cloud computing contracts and model contractual terms (MCTs) for data access and use — modular clauses covering switching and exit, termination, security and business continuity, liability and non-amendment.

The Omnibus deserves a sober reading. It is neither a repeal nor mere drafting. It moves a boundary: refusal on trade-secret grounds shifts from exception to available tool. Whether that hollows out the purpose of Chapter II depends entirely on how authorities apply the new standard. I am of the opinion that this is the point at which the practical effectiveness of the Data Act will be decided over the next five years — more so than the deadlines of Chapter VI, which are technically unambiguous and therefore easy to audit.

Since this is a proposal that still has to pass the ordinary legislative procedure, the current text applies until further notice.

Part 7: A Framework for Practice

Anyone responsible for architecture, procurement or compliance can reduce the regulation to five questions.

1. Role clarity. For this product or service, am I user, data holder, third party — or several at once? The answer is in the contract, not the system diagram. It belongs in an inventory maintained per product line and per service.

2. Data classification. Which streams are raw or pre-processed (in scope), which are derived (out of scope)? This boundary should be documented in the data model, not in a legal opinion — and it should be reasoned, because it has to be defended if challenged.

3. Interface obligation. For connected products placed on the market after 12 Sep 2026: is there a direct, secured access path? Is it documented, authenticated, versioned — and was it designed together with the CRA requirements?

4. Exit capability. For each of my data processing services, do I know the answer to: which data and digital assets are exportable? In what format? Through what interface? In what time? And — the question asked least often — have I ever tested it?

5. Contract alignment. Do my cloud contracts contain the mandatory content of Article 25: notice period at most 2 months, transitional period at most 30 days, exhaustive data categories, retrieval period at least 30 days, erasure guarantee? And is the charging clause drafted so that it automatically drops to zero on 12 Jan 2027?

The fourth point deserves a remark, because it is the only one no authority will do for you. An exit plan that has never been executed is a document, not a capability. The kinship with a restore test after an outage is obvious: a backup that has never been restored is not a backup. From January 2027 the Data Act gives you the right to leave without an exit toll. Whether you can exercise it is decided not by the regulation but by your own architecture.

The Central Takeaway

At its core, the Data Act is neither a data protection law nor a prohibition law. It is a law for the reduction of switching costs — an intervention that comes from competition economics and lands in systems architecture.

The practical insight fits in one sentence: whoever designs a system today always designs its exit as well. Until now the exit was a residual risk written into the appendix of a risk analysis. From 12 January 2027 it is an enforceable customer right with defined deadlines and a price of zero. That changes two things at once: for providers, portability moves from a selling point to an obligation; for customers, the question "how do I get out of here?" moves from a theoretical exercise to one that requires a robust, tested answer.

So the concrete call to action is small and uncomfortable: in the coming weeks, take a single production service and run an exit rehearsal. Not the whole stack — one service. Export the data through the official interface, measure the duration, record the formats, attempt the import at the target system, and write down where it fails. The outcome of that one afternoon says more about the company's real switching capability than any contract review. And it produces the list of things that need clearing up before January.

Reflection Question

The Data Act assumes that switching costs are the central obstacle to competition in the cloud market, and therefore removes the price of switching. But the real binding force of a modern system rarely comes from egress fees — it comes from dependence on proprietary managed services, from staff knowledge, from integrations grown over years, from certifications and operating processes tailored to one platform.

Suppose your company runs a platform whose migration is technically feasible but would mean eighteen months of rebuilding: does abolishing switching charges actually change your negotiating position — or does it merely move the lock-in from a visible line on an invoice into an invisible architectural decision? And if the latter is true: which decision in your current stack would you take differently today if you knew you would have to undo it in five years?

Cross-References in the Vault

• When IT Is Not Allowed to Fail: DORA and Digital Operational Resilience in Finance — exit strategies, minimum contractual content and concentration risk: DORA requires the exit to be plannable, the Data Act makes it affordable.
• Security by Default: The EU Cyber Resilience Act and the End of the Insecure Product — the same class of devices from the opposite direction: the Data Act opens interfaces, the CRA has to secure them.
• The Man Who Toppled Three Agreements: Max Schrems, Transatlantic Data Transfers, and the Puzzle of Adequacy — the personal-data sibling of Chapter VII on unlawful third-country access.
• The Pyramid of Risk: How the EU AI Act Tames Artificial Intelligence – and Why It Concerns the Whole World — the sister regime of European digital legislation, likewise touched by the Digital Omnibus.
• The Algorithm as Judge: Article 22 GDPR, the SCHUFA Ruling, and the Right to a Human Decision — the interface between the Data Act and the GDPR, where co-generated data is personal.
• The ID That Stays Silent: eIDAS 2.0, the EU Identity Wallet, and the Art of Revealing Only What Is Needed — the same regulatory pattern: access and portability rights instead of new property rights.
• NIS2 and What It Really Means for Mid-Market IT Consulting Firms in Germany — the enforcement architecture in the German mid-market and the pattern of delayed national implementation.
• Eleven Nines: Erasure Coding, Reed-Solomon, and How the Cloud Makes Data Practically Unlosable — why the end of egress fees changes the economics of geographically distributed storage strategies.
• Betting on a Stranger's Code: Firecracker microVMs and the End of the Container-versus-VM Dilemma — isolation models as the technical answer to the sovereignty question of Chapter VII.
• The Noise That Protects Privacy: Differential Privacy and the Art of Revealing Nothing About the Individual — a tool for the anonymisation that Chapter V requires in emergencies.

Sources

1. Regulation (EU) 2023/2854 of the European Parliament and of the Council of 13 December 2023 on harmonised rules on fair access to and use of data (Data Act), OJ L, 22 Dec 2023. Consolidated text: EUR-Lex
2. European Commission, DG CNECT: Data Act explained (fact page, last updated 15 December 2025) — chapter overview, scope, compensation tables and the presentation of the staged withdrawal of switching charges. Shaping Europe's digital future
3. European Commission: Frequently Asked Questions about the Data Act and Draft Recommendation on non-binding Model Contractual Terms (MCTs) and Standard Contractual Clauses for cloud computing contracts (SCCs), published 19 November 2025. Commission library
4. Maples Group (Claire Morrissey), The EU Data Act's Switching Framework – A Practical Overview, 17 April 2026 — detailed account of the Article 25 mechanics (two months' notice, 30-day transition, 14 working days to justify, seven-month alternative period, 30-day retrieval) and the exemptions. Maples Group
5. European Commission: Digital Omnibus Regulation – Proposal, 19 November 2025 — proposed amendments to the Data Act on trade secrets, custom-made services, and SMEs and small mid-caps. Commission library
6. Bundesnetzagentur: Bundesnetzagentur wird zuständige Behörde für den Data Act in Deutschland, press release of 30 May 2026, and the topic portal Datenzugang und Datennutzung. Press release; Topic portal
7. German Bundestag: Bundestag verabschiedet EU-Vorgaben zum Datenzugang und zur Datennutzung, text archive for the sitting of 26 March 2026 (Datenverordnung-Anwendungs- und -Durchsetzungs-Gesetz, DADG). Bundestag
8. heise online: Data Act: Access by Design wird ab Herbst 2026 zur Pflicht — context on the 12 September 2026 deadline and the design duty under Article 3(1). heise online
9. Bird & Bird / White & Case: analyses of the Digital Omnibus Package and the proposed Data Act amendments, November/December 2025. Bird & Bird; White & Case
10. DLA Piper: Germany's Data Act enforcement architecture: what practitioners need to know now, March 2026 — the dual track of Bundesnetzagentur and BfDI. DLA Piper

← All articles