Blog

EU Data Act: when the EU installs "emergency exits" in your data corridors (and no one has read the signs yet)

The EU Data Act sounds like something best postponed until "later". The problem is, "later" often turns into "too late".

I usually explain it like this: the EU requires your data flows to have emergency exits. Not to complicate matters, but so customers and users can access data, share it under fair conditions, and switch providers without getting trapped in digital lock-in.

What makes this interesting (and somewhat uncomfortable) is that it's not just a legal issue. It becomes a supplier matter, a governance challenge, and an operational risk concern. New rights and more data flows also mean new dependencies and larger attack surfaces if controls don't keep pace.

Sectors like energy, industry, transport, property, and connected products are often front and centre, but their suppliers are affected indirectly through contracts, requirements, and monitoring.

This article clarifies the topic with a focus on governance, vulnerabilities, and practical capability.

Robert Willborg

Co-founder and Chief Security Officer at OneMore Secure.

Imagine your organisation as a large building. Not a grand, glittering one, but a practical industrial facility with corridors, doors, keys, access cards, and plenty of "we'll sort it later" notes stuck on the lockers.

Within that building, data flows like people in corridors: in, out, between rooms, between suppliers and back again. Sometimes through glass doors. Sometimes through a side door installed in 2018, and no one quite remembers who holds the key.

At its core, the EU Data Act is the EU saying: "This building must have emergency exits, clear keys and signage, and they must work when there's a fire."

Not to make life difficult, but to give users and customers more control, reduce unhealthy lock-ins, and create a more resilient data economy. But like fire safety, it only provides security if it actually works in practice, not just on paper.

Why this will be a "missed law" for many

The Data Act is an EU regulation effective from September 2025. Yet it's often overlooked for three reasons:

It sounds administrative, as if it's about legalities rather than reality.
It hits indirectly, through supplier chains and contracts, leading many to think "that's someone else's responsibility".
It mixes roles: you can be a customer in one area, a supplier in another, and a "data holder" in a third.

The fact the EU Commission has had to create both support materials and a Data Act Legal Helpdesk (where organisations can ask interpretation questions about rights, obligations, cloud switching and interoperability) signals to me that many players need help understanding what the law actually means. The troubling part is many don't realise they're affected right now.

"Does this apply to us?" (more often than you'd think)

The EU Data Act doesn't cover "all software". But it broadly applies where there are:

Connected products and related services
"Data holders" who hold data others have rights to access
Cloud and SaaS-like services (data processing services) where the Data Act requires customers to be able to switch providers without undue barriers, with defined transparency and support in the process

The key point here, even if you don't see yourselves as directly affected, is that you may be a supplier to someone who is. Then you become part of their compliance through contractual requirements, monitoring and audit trails.

Note now, the law applies from 12 September 2025 (with some parts phased in later depending on chapters and contracts). This means "we'll deal with it later" quickly becomes "we'll deal with it when there's already downtime and contract disputes". We must learn from the mistakes of addressing GDPR and NIS2 retrospectively. Get started today.

The link to NIS2: different laws, same reality

It's important to be clear: Data Act and NIS2 are separate regulations. They have different purposes and core logic. But in practice, they meet in the same reality:

The Data Act drives more data access, sharing, portability and supplier switching.
Every new right, interface or transfer route is also a new surface that can be exploited if governance, authorisation, traceability and monitoring don't keep up.

Looking at this from an incident perspective: attackers often enter via the supply chain, something I've written extensively about. ENISA has described how supply chain attacks have increased in number and sophistication, meaning "the corridors between buildings" (suppliers, code, services, operations) are where many breaches begin. The Swedish Civil Contingencies Agency has also noted this.

In other words: the Data Act can make data more fluid and the market more dynamic but only if you build control at the same pace. Otherwise, organisations risk creating more open doors than working emergency exits, favouring attackers.

Which sectors should be first to act?

To be brutally practical: these sectors often find themselves early in the Data Act's scope, along with their suppliers:

Energy (meter data, operational data, platforms, OT/IT proximity, many suppliers)
Manufacturing/industry (machine data, production data, predictive maintenance, service ecosystems)
Transport and vehicles (connected vehicles, telematics, service chains)
Property/smart buildings (control systems, sensors, energy optimisation)
Health/medtech (connected products and related services)

And in almost all cases: cloud/SaaS providers, service providers and operations partners are indirectly impacted through customers' switching, transparency and rights requirements.

Where things tend to go wrong

Most organisations don't miss the Data Act out of negligence. They miss it by making the classic mistakes:

Some think it's a "legal issue", so it lands in an already overcrowded legal box of duties and requirements.
Some think it's an "IT issue", so it ends up on a project backlog.
Some don't realise it's a governance and supplier issue, so it should have been handled by leadership from the start.

It's a bit like buying a defibrillator, putting it in a cupboard, and feeling safe just because the law requires it. It only helps if it's accessible, known, trained on and tested. And that only happens if leadership takes clear charge.

Three actions the ultimate responsible person should take now

Here are three easy-to-start measures that deliver quick impact and work from an all-risk perspective (governance, contracts, operations, supply chain):

1) Create a clear "impact overview" for decision-making

Answer three questions:

Are we a supplier, customer, data holder, or all of these at once?
Which products/services are connected and generate data others may have rights to?
Which suppliers qualify as data processing services where switching might be required?

Present this as a single page to leadership: "This is our exposure and why."

2) Conduct a contract and dependency review as if you needed to switch supplier tomorrow

Not because you will switch, but to see if you can. Pay particular attention to: exportable data, obligations on switching, and technical, commercial or contractual barriers. The Data Act is clear that switching should be facilitated and obstacles removed.

3) Build "assurance in operations" across the supply chain

Contractual requirements are just the start. You need to continuously demonstrate:

a current list of dependencies
timely handling of vulnerabilities and remediations
monitoring that leads to change (not just reports)

This is especially important as the supply chain is a well-known attack vector in today's threat landscape.

It's not about folders, but functioning doors

The Data Act doesn't demand perfection. It requires you to demonstrate control over your data flows, your dependencies, and your ability to fulfil rights and obligations in practice.

To complete the analogy: the EU isn't asking you to build a new building. It's asking you to ensure emergency exits exist, are signposted and can be opened. Even under stress, with someone pulling at the door.

This isn't bureaucracy. It's mature governance of security in the supply chain.