Search every question across sub-FAQs

Receive the electronic request, verify only what is necessary, identify the connected product or related service, classify the requested data, run personal-data, security, and trade-secret checks, choose user or third-party delivery, communicate the outcome, and close the record with delivery evidence or written reasons for any limit.

Treating indirect access as a generic support ticket loses the required legal and technical trail: why direct access was unavailable, what readily available data was in scope, which safeguards changed the response, and what the user or third party was told.

For indirect access request flows, keep the specific Article 4 or Article 5 citation, the official source URL, and the internal decision note together with the request record. That makes it easier to show which Data Act rule supported the action.

Keep the evidence pack focused on the decision itself: who approved it, which request it covered, what data categories were in scope, and what safeguard or limit was applied.

For Data Act indirect access request flows, the owner should be the team member who can coordinate product, legal, privacy, and support actions for the specific request path. The legal rule may sit with one team, but the operational response usually needs cross-functional ownership.

Use one named owner for each request path, then record the supporting teams that need to review verification, security, trade-secret, or delivery issues.

For indirect access request flows, the most useful supporting material is whatever lets a later reviewer reconstruct the decision without guessing. That usually means the Data Act citation, request logs, product or service data map, the verification method, and any security or trade-secret notes.

Keep the evidence set practical. The goal is to show how the team handled the request, not to create a large archive of unrelated operational material.

For Data Act indirect access request flows, the answer should be reviewed when the product, service model, dataset, customer role, or contract wording changes, or when the team changes how requests are received or routed.

Set both a calendar review date and an event-based trigger. That helps keep the answer aligned with the live request process instead of relying on a one-time note.

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.