Service · Software development

Data Act: data access and switching.

The EU Data Act gives the person using a device the right to the data it generates, and requires cloud services to make switching providers easier. Both affect your architecture more than your legal department. We build the integration, the access-control layer and the export route that make this possible.

Access for usersSharing with third partiesExit provisionsPermissions layer
Arrange an introductory call View related work

What the regulation changes, and where the work lies.

The Data Act (Regulation (EU) 2023/2854) has applied since 12 September 2025. It regulates two things that at first glance seem unrelated. First: whoever uses a connected product is entitled to the data it generates, and can also have that data requested by a third party. Second: whoever purchases a cloud service must be able to leave it without undue obstacles. For products placed on the market from 12 September 2026 onwards, it also applies that they must be designed so that this data is accessible by default.

The practical question underneath is who owns what a device knows. Until now that was implicitly the manufacturer, because it sent the data to its own platform. The regulation turns that into a right for the person using the device, and that affects business models that relied on this exclusivity. For providers this is not a disaster but a choice: selling maintenance because you are the only one who sees the measurement data is different from selling maintenance because you understand best what that data means. The first disappears; the second does not.

We don't do the legal work (for that you need a lawyer), but we build everything underneath: an integration through which data can be accessed without anyone needing to get into your system, an access-control layer that determines who may request what and how shared access is revoked, and an export route that is genuinely usable. This often touches integrations with other systems, IoT platforms and cloud exit projects.

We handle this separately and as part of custom software development. If it concerns equipment in the field, look at a custom IoT platform; if the question is where your data is stored, look at sovereign cloud and cloud exit. How we ourselves handle data is set out in our information security policy.

Three types of Data Act work we take on.

Which part affects you depends on what you supply: a device, a cloud service, or both. In the first conversation we will decide which of the three should come first.

First engagement · fixed sprint budget

Access for the user themselves

A route by which the person using the product gets access to their own data: measurements, states and events, in a common format and without anyone from your side having to get involved. To that end we separate the raw layer from the derived insights, because that boundary determines what you need to share and what stays with you. Anyone who only draws that distinction once a request comes in will have to take their system apart.

Raw layer kept separateCommon formatSelf-serviceTime series
Mid-sized project · fixed sprint budget

Sharing with third parties, with permissions and revocation

The user may have their data requested by a third party – a maintenance provider, an insurer, a competitor of yours. That calls for a permissions layer: who may access what, for how long, and how the user revokes that access again. Logging belongs to this too, so that access is verifiable and not merely possible. The protection of your trade secrets also takes shape here, as they remain intact under the regulation.

ConsentsRevocationAccess logTrade secrets
Larger project · fixed sprint budget

An exit arrangement your customers can test

For cloud services, leaving should not be unnecessarily difficult, and switching costs must be phased out. We build the export route: which format, within how much time, how complete, and with the option for the customer to try it out in advance. An export that only proves unusable at the point of departure is not an exit arrangement but a formality – and you only find out when it is too late to do anything about it.

Complete exportTestable in advanceTransition periodDocumentation

What you have at the end of an engagement.

Working integrations and an access model, plus the documentation you need when a customer or regulator asks how it is arranged.

  • A separation between raw and derivedMeasurements and events in a layer you can open up, and your own analyses and insights in a layer that stays with you.
  • An integration for accessA documented route through which the user and third parties they designate can request data, in a common, machine-readable format.
  • A permissions layer with revocationConsents per party and per type of data, with a term, and a button by which the user can end a shared access themselves.
  • An access logWho requested what and when, retained under your retention policy, so that access can be verified afterwards.
  • A testable export routeA complete export in a common format that your customer may try out in advance, with documentation on the structure and meaning of the fields.
  • Handover to your teamWorking sessions with your developers and with the people who will handle the requests, plus the documentation your lawyer needs for the contractual side.

When this sounds familiar.

Four situations we see again at organisations that have to get started on this. There is usually a concrete trigger, and the scope often turns out to be broader.

Connected products

Your devices send data to your platform

You supply machines, vehicles, meters or equipment that send measurement data to your own environment. From 12 September 2026, newly placed products must be designed so that this data is accessible to the user by default.

Revenue model built on exclusivity

Your service relies on only you seeing the data

Maintenance contracts, consumption advice or optimisation that you can offer because you alone hold the measurement data. That foundation is shifting, and it is wise to determine now where your value will lie afterwards.

Cloud service

You provide a service that customers are locked into

The regulation requires that leaving can happen without unnecessary barriers and phases out switching costs. Beyond the obligation, this is a selling point: whoever can show how easy it is to leave wins out over whoever is vague about it.

Requests are already coming in

Data has been requested and nobody knows how to handle it

A customer, or a third party they have engaged, has asked for access, and the answer was a manual export. That is not sustainable once requests become more frequent, and it is precisely the pattern the regulation aims to eliminate.

How such a project runs.

1

Introduction and scoping

Which products or services are affected, who is the user in your case, and what data the product actually generates. That last question often generates more discussion than expected, because far more is usually recorded than is ever used.

2

The line between raw and derived data

A working session in which we determine, for each type of data, whether it falls under what the product generates or under what you have made of it. The regulation does not draw that line sharply, so we document the reasoning. That is what you can explain later, even as the practice evolves.

3

Building in sprints

We work in sprints and begin with access for the user themselves, as it is the simplest and the rest builds on it. Then the rights layer for third parties, followed by the export route. Your own developers work alongside us.

4

Testing with a real request

We run a complete request end to end with someone from your organisation playing the user: requesting access, sharing with a third party, and revoking it again. We also have an export actually loaded into a different system. Only then will you know that the route works.

5

Documentation and handover

Documentation for your customers and your lawyer, a handover to the people who handle the requests, and agreements on what happens when a request arrives that falls outside the established path.

Frequently asked questions about the Data Act.

What product managers, architects and directors ask us before they get started.

From when does this apply?
The regulation entered into force on 11 January 2024 and has applied since 12 September 2025. For connected products placed on the market from 12 September 2026, a design requirement also applies: the product must be built so that data is accessible to the user by default and easily. The provisions on switching charges for cloud services follow their own timeline, under which those charges are gradually phased out.
What exactly counts as "data generated by the product"?
Raw data and what directly follows from it: measurements, states, events, usage data. What falls outside this is information that is the result of substantial investment in processing and analysis. That line is not sharply drawn and there will be discussion about it in the coming years. For your design, the main implication is to keep the two separate, so that you can expose one layer without taking your system apart.
May we charge for access?
For the user requesting their own product data, access must not be unnecessarily hindered, and there are limits on what you may charge. When making data available to a third party at the user's request, different rules apply, including the possibility of reasonable compensation, with a lighter regime for small enterprises. This is very much a question for your lawyer; we ensure that your system can support both.
What happens to our trade secrets?
They remain protected. The regulation expressly provides for measures you can attach to sharing data that contains trade secrets, and in exceptional cases allows you to refuse sharing. What does not work is labelling everything a trade secret to escape the obligation. In practice, separating raw and derived data largely resolves this: your analysis is where your secret lies, not in the measured value.
Do we have to offer this in real time?
Where the product generates data continuously or almost continuously and this is technically possible, direct availability is the obvious choice. For many applications, periodic delivery is sufficient. What matters most is that access is simple, secure and in a common format, without anyone from your side needing to be in between. We design the integration so you can adjust the rhythm later without rebuilding.
How long do we need to keep data available?
That cannot be captured in a single period. It depends on the nature of the product, on what you have agreed contractually and on other retention obligations that apply to you. What we do is justify that choice and record it, rather than guess, and set up the retention policy so that it differs per type of data. That saves storage costs and makes it easier to explain.
We are a recipient, not a supplier. Is this of any use to us?
Certainly. As a recipient you gain rights: access to the data from the equipment you use, and the ability to have another party work with that data. That opens up maintenance contracts that were previously closed off and makes comparison possible. On your side, we help with retrieving that data, making it usable, and working out what you need to set out contractually to actually receive it.
How does this relate to the GDPR?
They sit alongside each other. If the product data relates to an identifiable person, the GDPR applies in full and you need a lawful basis for it; the Data Act does not widen that. In practice, most machine data is not personal, but with vehicles, wearables and devices in the home it is different. We flag this in the working session so that your lawyer knows where to look.
What does this mean for our architecture?
Three things. Data must sit somewhere it can be accessed without anyone needing to get into your system; that is an integration, not database access. There must be an access-control layer around it, because giving access to the user is different from giving access to everyone. And logging belongs with it, so that access is verifiable. These three are straightforward work if you include them in the design, and a rebuild if you have to add them later.
What belongs in an exit arrangement?
The format in which data is handed over, the timeframe, the terms, and how long you continue to deliver after termination so that the transition can be made. That last point is most often missing and gives the greatest peace of mind. Add to that that the customer may test the export format in advance – that is the difference between an arrangement that works and one that exists only on paper.
Will we lose our customers as a result?
That is the fear, and rarely the outcome. Customers leave mainly when they feel they cannot get away. In procurement processes, a demonstrably working exit arrangement is now an advantage, not a risk. What you do need to think about is which part of your service relied on exclusive access – that part becomes vulnerable, and that is a strategic question better put on the table now than later.

Talk to us about the Data Act.

A half-hour introductory call, no obligation. Tell us what your product produces and who uses it, and we will say where your architecture is likely to be under strain and what should come first – even if we ultimately do not work together.

Book an introductory callOr see our work

Edit content