The EU Data Act: A Practical Guide for Connected Product & Engineering Leaders

You’re already juggling roadmaps, customer commitments, technical debt, and half-finished platform work. Now there’s a new regulation that cuts across devices, cloud, data, and portals, with most of the pressure sliding your way.

While this is a joint effort between legal, compliance, security, and engineering, most of the real changes will still land inside the product stack. That’s why it helps to look at the Data Act from an engineering point of view. The regulation becomes clearer when seen through the lens of how your devices produce data, how your cloud platform structures it, and how your interfaces expose it.

In a nutshell, it’s all about making the data your products already generate accessible, consistent, and safe to share, without rebuilding the entire system. And here is what that looks like in practice, layer by layer.

What the Data Act Really Means for your Product in Practical Terms

Your equipment produces operational data every time it runs, and customers should be able to pull that information in a format they can actually use. When they want a service partner or another software vendor to work with the same data, there needs to be a reliable way to hand it over. That’s the basic expectation.

Things change once you look at how existing products behave. Most connected systems are built on years of accumulated decisions. We still see devices reporting values named after firmware from 2014. Backend services keep legacy API structures, and many portals were never meant to expose operational data. This isn’t unusual, but once a third party relies on that data, the gaps surface.

That’s where regulatory requirements start to have a real impact. Beyond the main articles, several obligations directly affect how data is structured and governed. These demand closer attention on the engineering side:

Interoperability and Data-format Consistency

The EU Data Act assumes that once data leaves your system, another provider’s software can read it without decoding your internal habits. That sounds reasonable, but most products aren’t built that cleanly. Data might technically be “available,” yet still unusable until someone aligns units, maps internal codes to domain conventions, writes proper metadata, and resolves conflicts across versions.

Many industries also expect you to produce established formats (BACnet, Haystack, OPC UA) rather than invent your own. Moving toward those standards usually exposes mismatches you didn’t know existed. A sensor that reports humidity as an integer needs to be converted to a float. A flag that only makes sense if you remember the boot sequence from five releases ago becomes a problem.

Interoperability ends up being less about “publishing a schema” and more about closing the gap between your system and real-world expectations. That usually forces cleanup, and it’s better to do that before any legal deadline arrives.

Distinguishing Raw Data from Sensitive or Proprietary Logic

The Act targets raw and pre-processed operational data, while allowing manufacturers to withhold algorithms and core logic. In practice, systems don’t separate these neatly. Raw data and computed values come mixed, and some calculations can reveal more than intended.

Once teams start pulling these pieces apart, they usually realize the export surface isn’t clean enough. A new boundary is needed, or the data model has to shift. Simply marking a few fields as “protected” rarely does the job.

Access Control and Delegation

The customer decides which third parties can access their data, and that can change with very little notice.

Most connected products weren’t built for this kind of constant delegation churn. Many older platforms still rely on broad, long-lived credentials because the original architecture had no practical way to issue per-partner, scoped access. When access needs to be revoked, things break. Removing a partner’s key might disable an unrelated workflow because multiple tenants ended up sharing the same token.

A more stable approach relies on short-lived keys, narrow scopes, clear deactivation paths, and an audit trail that settles questions about who had access at any given moment.

Governance, Auditability, and Lifecycle Alignment

The Act gives customers the right to see who accessed their data, under what permission, and when. That’s easy to imagine in a greenfield build, but much harder in a product that has lived through several architectural eras.

That’s why the teams need predictable rules for logging, retention, and tracking data origins. Without that, audit support turns into guesswork. Two customers may ask why their exported data differs across periods, and answering cleanly requires more than intuition.

Governance doesn’t fix technical debt, but it makes the debt visible. It gives teams a way to answer questions cleanly instead of relying on institutional memory. And once external parties rely on your data, that difference becomes critical.

Security Exposure Created by Opening the Surface to Third Parties

Once external partners use your interfaces, your security depends on theirs. You often don’t know how they store credentials, who has access to integration keys, or how quickly they react to a breach.

The Act assumes third parties meet certain expectations, and your legal team will put that in contracts, but none of that helps in the first 15 minutes after their environment is breached.

If a partner is breached, your API is at risk unless boundaries are strong. Protect it with tight token scopes, per-partner limits, and isolation at the edge. In theory, every partner should match your security standards. In real life, they won’t, so it’s safer to assume the weakest link sets the risk.

Cloud Portability Obligations

The EU Data Act expects customers to move their data to another provider without being locked into your internal structures.

On paper, that looks simple, but in real systems, the data tends to be scattered across different systems and layers. So, meeting portability requirements means gathering it from multiple sources and reshaping it without disrupting live operations.

The cost is another factor. Large exports put strain on storage and bandwidth. Until January 2027, you can pass direct costs plus a margin of up to 20% to the customer. Legal and commercial teams will handle the pricing, but engineering needs to quantify the underlying work. Otherwise, pricing becomes a guesswork.

Moving from “We Need to be Compliant” to a Workable Plan

When the compliance note arrives, most teams pause for the same reason: it’s not obvious where to begin. You read the regulation, break it into practical terms, and for a moment, it all makes sense. Then the real question hits: how on earth do you fit this into a roadmap that’s already full? Usually, it takes a bit of common sense, a bit of patience, and a bit of magic. And a structured approach, you have always relied on when working with your roadmap.

1. Assess where you stand across each layer and obligation

Look at the device layer, the connectivity stack, cloud services, the data model, APIs, and customer-facing interfaces. Most of this comes down to basics:

• how values are named
• which units appear in the payloads
• what metadata is present
• how tokens are scoped
• what the logs actually record
• where data sits in storage and in which version

You do not need a long audit for this. A short review from the engineers closest to each part of the system usually gives enough signal. The goal is clarity, not polish.

2. Map What’s Missing and Separate Quick Fixes from Structural Work

Once the current state is clear, look at what’s absent. Do not create a single list. Split it. The two lists will matter when you try to fold this into real delivery.

By splitting the gaps this way, you know what can move immediately and what needs a slot on the roadmap. It turns a vague list of issues into something you can actually sequence.

3. Align the Structural Work with your Existing Roadmap

Once the deeper changes are on the table, place them next to the work your team is already committed to. Most teams don’t have spare capacity waiting for a new stream. People are juggling feature delivery, platform fixes, support pressure, and upgrades that have been pushed forward from past quarters. Anything that lives outside that flow tends to slip.

That’s why the structural items need to travel with work that’s already in motion:

If a firmware release is planned, it’s usually the safest place to straighten out naming or units. The testing and validation loops are already set up, and you won’t need to coordinate a separate rollout.

If an API update is coming, it’s a good moment to tighten scopes, remove the wide tokens, and clean up the boundary before new consumers lock in assumptions. If the data model is being touched, that’s the window to address schema drift or consolidate stores. If observability work is happening, it’s the right time to add the logs that will matter later, instead of trying to wedge them in mid-quarter.

This approach also reduces context switching. When people are already working in a part of the system, it’s much easier to fold in the structural changes there. Once you see how the pieces line up, the work stops looking like a second backlog competing for attention. It becomes part of the roadmap you already have.

Fit the Remaining Work into the Plan, Even if it was Never Part of the Original Trajectory

Even after you align the major structural items with work that is already in motion, a few tasks usually remain on the side. They end up there for different reasons.

Some are deeper technical issues that were never addressed because they crossed old boundaries or did not have a clear owner.  Others come from new regulatory expectations. Things that worked when data stayed internal no longer work once it’s shared, and some requirements fall outside the original product strategy.

The reasons differ, but the situation is the same. These items will not move unless you give them space.

The practical path is to break them into small, contained pieces and place them into the roadmap where they will not disrupt your main delivery streams. They do not need a separate project. They need a slot, an owner, and room to be completed without competing for attention.

Taking care of this work raises the baseline quality of the product in ways that already matter to customers, support teams, and internal analytics. The regulation does not create that need. It simply makes it visible.

Making the Updated Roadmap Work in Real Life

There’s also the situation no one likes to admit out loud.
You can have a plan and structure, but still lack the people to execute it. Some teams are already at capacity, and others lack the security or data expertise they never needed before.

All this boils down to one question: how can the team absorb the work that needs to be done without dropping commitments or burning weekends? The most typical ways to solve the challenge are:

None of these options is perfect. Each solves one constraint and exposes another.
But the common thread is simple: the work only moves when someone has the space and mandate to go deep enough. Everything else is wishful thinking disguised as planning.

How Sigma Software Can Help

If you need support, we can plug into the parts of the work your team doesn’t have the time or depth to cover:

• Assessment and gap mapping across device, cloud, data, API, and security layers.
• Practical interpretation of the Data Act into concrete technical changes for your product.
• Architecture and data-model consulting to reshape export surfaces, schemas, and partner boundaries.
• Security review focused on token scopes, partner isolation, and exposure created by data sharing.
• Implementation support across firmware, backend, cloud, and data engineering when the roadmap is already full.

We step in where additional capacity or expertise is needed. Get in touch to discuss your next steps under the EU Data Act.

• #Cloud & DevOps
• #Information Technology