Obligations in scope
Article 35 — standardisation bodies
Open interoperability specifications and harmonised standards shall enhance portability of digital assets between different data processing services covering the same service type. Action required: enhance.
Article 35 — standardisation bodies
Open interoperability specifications and harmonised standards shall achieve interoperability between different data processing services covering the same service type where technically feasible. Action required: achieve.
Article 35 — standardisation bodies
Open interoperability specifications and harmonised standards shall facilitate functional equivalence between different data processing services referred to in Article 30(1) covering the same service type where technically feasible. Action required: facilitate.
Article 35 — standardisation bodies
Open interoperability specifications and harmonised standards shall not have an adverse impact on the security and integrity of data processing services and data. Action required: ensure.
Article 35 — standardisation bodies
Open interoperability specifications and harmonised standards shall be designed to allow for technical advances and the inclusion of new functions and innovation in data processing services. Action required: design.
Article 35 — standardisation bodies
Open interoperability specifications and harmonised standards shall adequately address cloud interoperability aspects including transport, syntactic, semantic, behavioural, and policy interoperability. Action required: address.
Article 35 — standardisation bodies
Open interoperability specifications and harmonised standards shall adequately address cloud data portability aspects including syntactic, semantic, and policy portability. Action required: address.
Practical steps
What the obligations on this page actually require you to do, ordered by article. Use this as a starting checklist; verify each item against the underlying article text before treating it as legal advice.
- Art 35 — enhance (standardisation bodies)
- Art 35 — achieve (standardisation bodies)
- Art 35 — facilitate (standardisation bodies)
- Art 35 — ensure (standardisation bodies)
- Art 35 — design (standardisation bodies)
- Art 35 — address (standardisation bodies)
- Art 35 — comply (standardisation bodies)
Obligation reference table
| Article | Obligated entity | Deadline | Penalty |
|---|---|---|---|
| Art 35 | standardisation bodies | — | — |
| Art 35 | standardisation bodies | — | — |
| Art 35 | standardisation bodies | — | — |
| Art 35 | standardisation bodies | — | — |
| Art 35 | standardisation bodies | — | — |
| Art 35 | standardisation bodies | — | — |
| Art 35 | standardisation bodies | — | — |
| Art 35 | standardisation bodies | — | — |
| Art 35 | standardisation bodies | — | — |
| Art 35 | Commission | — | — |
Penalty exposure
None of the 13 obligations on this page carry an explicit penalty figure in the Data Act text itself — the fine ceiling is set elsewhere in the regulation and applies by reference. Refer to Data Act's general penalties article (or the diagnostic below) to estimate exposure before signing off on a compliance programme.
Cross-regulatory conflicts
Data Act interacts with other EU regulations in ways that can pull compliance teams in opposite directions. The most concrete conflicts in the Fontvera corpus involving this regulation:
- DSA Art 10 ↔ Data Act Art 18 (medium) — [entity affected: provider of intermediary services / data holder] DSA Art 10 requires providers to inform authorities of the receipt and effect of orders without undue delay, while Data Act Art 18 allows data holders up to 30 working days to decline or modify requests, potentially conflicting with the immediacy expected under DSA enforcement orders.
- Data Act Art 14 ↔ Data Governance Act Art 4 (medium) — [entity affected: public sector body] The Data Act allows public sector bodies to request data from private holders under exceptional needs, while the DGA restricts public sector bodies from granting exclusive rights to re-use data, potentially creating tension if a public body tries to exclusively control data obtained via the Data Act.
- DMA Art 1 ↔ Data Act Art 14 (high) — [entity affected: Member States] DMA Art 1 prohibits Member States from imposing further obligations on gatekeepers, while Data Act Art 14 imposes specific data sharing obligations on data holders (which may include gatekeepers) for public interest tasks, potentially creating a conflict if interpreted as a 'further obligation' under DMA.
- DORA Art 18 ↔ Data Act Art 18 (high) — [entity affected: Financial entities acting as data holders] DORA requires classification and reporting of ICT incidents based on specific criteria, while the Data Act requires anonymization or pseudonymization of data before sharing with public bodies, potentially conflicting if incident data contains personal data that must be preserved for forensic analysis under DORA.
- Data Act Art 14 ↔ ePrivacy Directive Art 5 (high) — [entity affected: data holder / provider of publicly available electronic communications service] The Data Act mandates making data available to public bodies upon request, while ePrivacy strictly prohibits interception or surveillance of communications without user consent, creating a tension between mandatory disclosure and confidentiality obligations.
- Data Act Art 14 ↔ GDPR Art 6 (high) — [entity affected: data holder] The Data Act mandates data sharing for public interest tasks, which may conflict with GDPR's requirement for a specific lawful basis if the public interest task does not explicitly override data subject rights or if consent was the original basis.
Related Fontvera pages
- data act article 37 commission
- data act vs data governance act comparison
- data act vs dma comparison
- data act vs dora comparison
Check your full compliance exposure with the 5-minute Fontvera diagnostic →