Data access is becoming a product workflow
The EU Data Act has applied since 12 September 2025 and is now moving from legal planning into product implementation. It gives users of connected products and related digital services more control over data they generate, while also setting expectations for data sharing, cloud switching and interoperability.
For software teams, the practical question is not only whether the company has a legal position. It is whether the product can handle data access in a way users, support teams and engineering can actually operate: clear request flows, explainable data scopes, secure exports, third-party sharing controls and enough evidence to review what happened later.
Start with a data access inventory
A Data Act readiness plan should start with the data the product creates, receives and transforms. Connected products, companion apps, SaaS dashboards and customer portals often mix raw device signals, pre-processed records, account data, billing events, analytics, documents and derived insights. Not every category belongs in the same access flow.
The product inventory should separate readily available product or service data from derived intelligence, confidential business logic and personal data that still needs a GDPR basis. That distinction helps teams avoid vague export promises and design a request flow that is useful without leaking trade secrets, personal data or operational internals.
- Map connected product data, related service data, account records, documents and analytics separately.
- Mark which data is raw, pre-processed, derived, personal, non-personal or trade-secret sensitive.
- Define which exports are user-facing, admin-only, partner-facing or authority-facing.
- Attach source system, owner, retention rule and review state to important data categories.
- Turn the inventory into test cases for the actual request and export screens.
Design the request flow before the API
Many teams will be tempted to start with an endpoint. The better starting point is the request journey: who is asking for data, what scope they can choose, whether a third party receives it, which permissions apply and how the user understands the consequences. A strong interface reduces support load because it explains the data package before the export is created.
That flow should show scope, format, timing, security checks and next steps. For a customer portal, the user may need a downloadable file and a history of previous requests. For an industrial dashboard, an authorized operator may need recurring machine-readable access. For a partner integration, the product may need consent, contract status, rate limits and revocation.
Make third-party sharing revocable and visible
The Data Act is not only about a user downloading a file. Users may ask a data holder to share data with a third party of their choice, subject to important limits. That makes data sharing a relationship that should be visible inside the product, not a hidden support ticket.
A practical portal needs a sharing registry: recipient, scope, start date, status, legal or contractual basis, technical endpoint, last transfer and revocation path. If personal data is involved, the workflow also needs the right privacy basis and a clear separation from non-personal industrial data. The user should be able to understand which access is active and how to stop it.
Cloud switching is an architecture signal
The Data Act also targets switching between data processing services, including cloud and edge services. For SaaS products and operational platforms, this does not mean every customer will migrate tomorrow. It does mean teams should know which data and digital assets can be exported, which services are tightly coupled and which contracts promise an exit path that the architecture cannot yet support.
The engineering work is often unglamorous but valuable: documented schemas, stable export formats, tenant-level backups, dependency maps, environment recreation notes and migration runbooks. Those same practices help with disaster recovery, enterprise procurement and future platform changes even when no formal switching request arrives.
Build evidence into operations
Data access workflows need logs that are useful without becoming a privacy problem. Teams should record request state, requester, scope, approvals, export generation time, delivery method, recipient, revocation and errors. They should avoid collecting unnecessary content in logs, but preserve enough operational evidence for support, audits and incident review.
This is where dashboards and automation become part of compliance quality. A support team should see pending requests, failed exports, expiring access grants and unusual transfer patterns. Product teams should see where users get confused. Engineering should see which data sources make exports slow or fragile.
A practical first build for 2026
For EDS Labs projects, a useful first Data Act-ready build is narrow and reviewable: choose one product or portal surface, map the relevant data categories, design the request and sharing screens, implement one secure export path, log the operational evidence and document what is intentionally out of scope.
That turns the Data Act from a late legal scramble into better product infrastructure. Users get understandable access to their data. Support teams get fewer unclear requests. Engineers get cleaner APIs, export boundaries and exit plans that make the platform more resilient.