The EU Data Act is easy to underestimate because it doesn’t sound like a classic “IT compliance law.” In practice, it hits product architecture, data platforms, APIs, cloud contracts, and portability engineering.
Many organizations will feel it most through:
- Requests for access to data generated by connected products and related services
- Contract negotiations that require new data-sharing and switching terms
- Cloud portability demands that stop being “commercial nice-to-have” and become implementation work
Note: This article is implementation guidance, not legal advice. Confirm applicability and obligations with legal counsel and your contracting partners.
What changed (in plain language)
Depending on what you sell or operate, the Data Act can require you to rethink:
1) Data access for connected products and related services
If data is generated by a connected product/service, you may need a defensible approach to:
- Who can request access (and under what conditions)
- What data is provided (and what is excluded)
- How it is delivered (API/portal/export)
- How requests are authenticated, authorized, and logged
2) B2B data sharing and “unfair terms”
Data-sharing terms that were previously “whatever the contract says” may need rework:
- Clarity of rights and limitations
- Reasonable technical and commercial conditions
- Guardrails for trade secrets and security
3) Cloud switching and portability
Switching is not just about exit clauses. It is engineering:
- Data export formats
- Identity and access portability
- Network and integration dependencies
- Documentation and repeatable runbooks
The “latest news” hook you can use
European Commission messaging has emphasized that the Data Act is applicable (often referenced as applicable since 12 September 2025) and framed it as a major step toward a fair EU data economy.
Even if your organization hasn’t been asked about it yet, your customers and partners may start asking in 2026 as contracts renew.
A 2026 action plan (technical + contractual)
Step 1: Identify in-scope products and services
Create a shortlist:
- Connected/IoT products
- Platforms that generate operational data
- Services where customers reasonably expect access to “their” data
Step 2: Map the data
For each product/service:
- What data is generated?
- Where does it live (device, edge, cloud, third party)?
- What is personal vs non-personal?
- What is sensitive (security, trade secrets)?
This step prevents chaotic “API requests” later.
Step 3: Design the access path
You typically need:
- An API or portal
- Authentication and authorization
- Rate limiting and abuse prevention
- Logging and audit trails
- Support and dispute handling workflow
Treat this like any externally exposed platform feature: it needs reliability, monitoring, and lifecycle ownership.
Step 4: Refresh contracts (customer, partner, cloud)
Work with legal/procurement to:
- Update customer terms for data access requests
- Update partner agreements for data sharing conditions
- Strengthen cloud contracts with switching and exit clauses that are technically feasible
Step 5: Align with GDPR and trade secrets (guardrails, not excuses)
Organizations get into trouble by treating GDPR and trade secrets as reasons to do nothing.
Build guardrails:
- Clear separation of personal vs non-personal data
- Lawful basis and transparency where personal data is involved
- Controlled redaction/anonymization approaches where appropriate
- Security controls for sensitive datasets
Budgeting reality: this is not a one-person compliance project
In 2026, plan for effort across:
- Product and platform engineering (APIs/portals, logging, reliability)
- Data engineering (mapping, exports, lineage)
- Security (access control, audit, abuse prevention)
- Legal and procurement (contract refresh)
- Customer support/operations (request handling)
Key date
- 12 September 2025: often referenced as the date the Data Act became applicable across the EU.
Final thought
The Data Act is “compliance engineering.” If you invest in scope clarity, data mapping, a controlled access path, and realistic switching runbooks, you’ll reduce risk—and you’ll also improve customer trust and product maturity.