EU Data Act Interoperability Standards FAQ

No. The Data Act sets the legal framework and essential requirements, but a requested or draft deliverable is not a binding standard. Check the Official Journal, any applicable implementing act, and the central Union repository before assigning legal effect.

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.

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.

Article 35 specifies what open interoperability specifications and harmonised standards for data processing services must address. They must support same-service-type interoperability, portability of digital assets, functional equivalence for the infrastructure services in Article 30(1) where technically feasible, security and integrity, and future technical development.

Article 30(3), not Article 35 alone, creates the operational compatibility trigger for non-IaaS services: compatibility is due at least 12 months after the relevant harmonised-standard or common-specification reference is published in the central Union repository. The 2026 Union work programme identifies interoperability for data processing services as ongoing standardisation work.

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.

Article 36 applies to the vendor of an application using smart contracts or, if there is no vendor, to a person whose trade, business, or profession involves deploying smart contracts for others to execute all or part of an agreement to make data available. It does not regulate every smart contract used for an unrelated purpose.

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 team must be able to distinguish 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.

Do not overstate 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 an official source gives them that status.

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.

Implementation choices may change when a standard is adopted, cited, amended, replaced, or covered by a common specification.

The Commission issued standardisation request M/614 for a European Trusted Data Framework, and CEN, CENELEC, and ETSI accepted work on seven deliverables. Four are European Standards, two of which are intended for possible Official Journal citation, and three are Technical Specifications. The request mainly supports Article 33 data-space requirements. A requested deliverable does not create a presumption of conformity before the required adoption and official reference.

Record whether each deliverable 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.

Article 30 already requires non-IaaS providers to make open interfaces available for switching and to provide a structured, commonly used, machine-readable export where no relevant repository reference has been published. Article 35 supplies the standards and common-specification mechanism for the separate compatibility duty.

The compatibility duty is not immediate on publication: Article 30(3) gives providers at least 12 months after the relevant reference appears in the central Union repository. Track current interface and export duties separately from that future trigger.

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.

An Article 36 vendor or covered deployer must perform a conformity assessment and, after fulfilling the essential requirements, issue an EU declaration of conformity. The declaration records responsibility for compliance; the supporting file should show the assessment method and evidence for robustness, access control, safe termination and interruption, data archiving, and consistency with the data-sharing agreement.

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.