EU Data Act Interoperability Standards FAQ

No. The Data Act sets the legal framework and essential requirements, but teams should not describe the relevant standards as final unless an official reference has actually been published or adopted for the relevant requirement.

For Article 33 data-space interoperability and Article 36 smart contracts, harmonised standards can create a presumption of conformity only to the extent their references are published in the Official Journal of the European Union and only for the requirements they cover. The same articles also allow the Commission to adopt common specifications by implementing act if the conditions in the Data Act are met.

For Article 35 data-processing services, the Act refers to open interoperability specifications, harmonised standards, common specifications, and a central Union standards repository for references used for interoperability between data-processing services.

The Data Act context is the starting point for this answer. Article 33 applies to participants in data spaces that offer data or data services to other participants. It requires those participants to support interoperability of data, data sharing mechanisms and services, and common European data spaces.

The practical requirements are concrete: describe dataset content, use restrictions, licences, collection methodology, data quality, and uncertainty where applicable in machine-readable form; describe data structures, formats, vocabularies, classifications, taxonomies, and code lists in a public and consistent way where available; describe technical access means such as APIs, terms of use, and quality of service; and provide means for interoperability of tools that automate data sharing agreements, such as smart contracts, where applicable.

A useful implementation record for Article 33 should therefore map each data-space offer to metadata, semantic assets, API or access documentation, licence or use restrictions, quality information, and any smart-contract automation used in the transaction.

The Data Act context is the starting point for this answer. Article 35 uses harmonised standards and common specifications as conformity tools, not as a blank replacement for the law. Open interoperability specifications and harmonised standards for data-processing services should support interoperability, portability of digital assets, functional equivalence where technically feasible, and compatibility with security and future innovation.

In practice, teams should follow the published repository reference for Article 35 once it exists, then align service interfaces, export formats, and documentation with the requirements covered by the relevant standard or common specification. The 2026 Union work programme for European standardisation identifies interoperability for data-processing services as an action area under the Data Act, which confirms that the work is still being built out through the standardisation pipeline.

Until a reference is published in the central Union standards repository, teams should treat implementation guidance as preparatory and should not say that a Data Act cloud standard is controlling law.

The Data Act context is the starting point for this answer. Article 36 applies to the vendor of an application using smart contracts, or where there is no vendor, to the person deploying smart contracts for others in the context of executing an agreement or part of it to make data available.

Those smart contracts must meet essential requirements for robustness and access control, safe termination and interruption, data archiving and continuity, access control at governance and smart-contract layers, and consistency with the data-sharing agreement being executed.

For day-to-day implementation, this means vendors and deployers should be able to show how the contract can be stopped or reset, how data and transaction history are archived for auditability, and how access rules match the underlying agreement.

Under the Data Act, keep a standards register rather than a generic legal memo. Each entry should show the Data Act article, affected product or service, data-space or cloud role, standard or specification status, source URL, owner, implementation ticket, test evidence, customer or participant documentation, and next review trigger.

For Article 33, keep evidence of metadata, semantic assets, API or technical access descriptions, terms of use, quality of service, licences, data quality, and uncertainty where applicable. For Article 35, keep switching, portability, interoperability, security, service-type, and repository-reference evidence. For Article 36, keep conformity assessment and EU declaration evidence.

The key audit question is whether the team can show the difference between a binding Data Act requirement, a published harmonised standard, an adopted common specification, an open interoperability specification, and a standardisation deliverable that is still in development.

The Data Act context is the starting point for this answer. The main risk is overstating legal status. A page, contract clause, procurement requirement, or architecture standard should not imply that M/614 deliverables, open specifications, or technical reports are final binding standards unless the cited source says so.

Use precise status language: the Data Act imposes essential requirements; harmonised standards can support presumption of conformity when officially referenced; common specifications can be adopted by implementing act; Article 35 references are to be published in a central Union standards repository; and M/614 identifies requested standardisation deliverables to monitor.

This distinction matters for product and legal teams because implementation choices may change when a standard is adopted, cited, amended, replaced, or covered by a common specification.

Under the Data Act, the Commission issued standardisation request M/614 to CEN and CENELEC to develop deliverables that support the interoperability essential requirements, mainly for Article 33 data spaces. These deliverables are in development rather than published harmonised standards, so a team should track their status rather than treat them as binding.

The practical step is to record, for each deliverable, whether it is requested, drafted, adopted, or referenced in the Official Journal, so the team knows which can support a presumption of conformity and which are still preparatory.

Under the Data Act, Article 30 requires providers of data processing services to support interoperability for switching, while Article 35 is the mechanism that supplies the open interoperability specifications, harmonised standards, and repository references those providers rely on. The duty exists now even though the standards pipeline is still being built.

Teams should treat Article 30 as the live obligation and Article 35 as the source of the technical references, aligning export formats and interfaces with published references as they appear.

Under the Data Act, a harmonised standard whose reference is published in the Official Journal gives a presumption of conformity for the essential requirements it covers, which means a team that follows it is presumed to meet those requirements unless shown otherwise. It is a rebuttable presumption tied to the specific requirements the standard addresses.

Teams should not read the presumption more broadly than the standard's scope, and should keep evidence of how their implementation maps to the covered requirements.

Under the Data Act, an Article 36 vendor or deployer must carry out a conformity assessment and draw up an EU declaration of conformity covering robustness, access control, safe termination and interruption, data archiving, and consistency with the data-sharing agreement. The declaration is the artifact that demonstrates the essential requirements were tested.

The evidence file should connect each essential requirement to a test result and a version of the smart contract, so the conformity claim can be re-checked after a code change.

Under the Data Act, an Article 33 participant offering data or data services must describe dataset content, use restrictions, licences, collection methodology, data quality, and uncertainty in machine-readable form, and describe data structures, formats, vocabularies, taxonomies, and code lists in a public and consistent way where available. These descriptions are what make a data-space offer interoperable.

A participant should also document technical access means such as APIs, terms of use, and quality of service, so another participant can consume the data without bespoke negotiation.

Under the Data Act, the interoperability position should be revisited whenever a harmonised standard reference is published in the Official Journal, a common specification is adopted by implementing act, or a repository reference for data processing services is added. Each event can change what a team must support and what merely supports conformity.

Teams should also revisit the position when an M/614 deliverable advances or a relevant standard is amended or replaced, so the implementation tracks the current references rather than an outdated draft.