Search every question across sub-FAQs

Robustness covers both reliability and resistance to manipulation. Before deployment, the team should test error handling, boundary conditions, manipulation attempts, dependency failures, and upgrade or migration paths that could change execution outcomes.

Access control needs coverage at two levels. Governance-layer controls should restrict who can deploy, pause, upgrade, terminate, or change parameters. Smart-contract-layer controls should restrict who can trigger functions, submit data, approve transactions, retrieve records, or operate privileged methods.

The smart contract should include internal functions that can reset, stop, or interrupt operation, especially to avoid accidental future executions. The stop mechanism should be tested before production use and documented so authorized personnel know when and how it can be used.

Recital 104 also says the requirement to interrupt and terminate smart contracts implies mutual consent by the parties to the data sharing agreement. Do not design a one-sided kill switch that conflicts with the agreement terms or later claim that a stop function changes the contract by itself.

If the smart contract is terminated or deactivated, Article 36 expects a possibility to archive the transactional data, smart-contract logic, and code so past operations on data remain auditable. The archive should preserve the relevant version, execution history, stop event, consent record, and agreement link.

A smart contract can automate execution of a data sharing agreement, but it does not replace the agreement. The agreement should still state the parties, data, use conditions, access limits, compensation if relevant, trade-secret measures, remedies, and termination terms.

The Commission has published non-binding model contractual terms for Data Act data access and use. Those terms are voluntary implementation tools; they can help structure the agreement that the smart contract executes, but using them does not by itself prove Article 36 conformity.

Article 36 creates two conformity routes that may matter over time. A smart contract that meets harmonised standards cited in the Official Journal is presumed to conform to the covered Article 36 requirements. If the standards route is unavailable under Article 36 conditions, the Commission may adopt common specifications by implementing act, and meeting those specifications can also create a presumption of conformity for the covered requirements.

The cited source materials show active Data Act standardisation work around a European Trusted Data Framework, trusted data transactions, and Article 33 interoperability deliverables. They do not support telling readers that a specific Article 36 harmonised standard is already cited in the Official Journal for smart contracts. Treat standards status as a live dependency and cite the binding Article 36 text before making conformity claims.

Keep an Article 36 evidence pack for each smart-contract deployment used to execute a data sharing agreement. The pack should let a reviewer connect the legal agreement, deployed code, controls, tests, conformity assessment, declaration, and later termination or archiving event without reconstructing the decision from tickets.

At minimum, the pack should include the agreement terms being executed, the responsible vendor or professional deployer, code and logic version, deployment address or environment, access-control design, robustness tests, stop and reset tests, archive procedure, conformity assessment, EU declaration of conformity, and review notes for any standard or common-specification updates.

Article 36 does not validate the legal agreement, replace national contract law, certify a blockchain protocol, require a particular ledger technology, or make all automated data-sharing controls smart contracts. It applies essential requirements to smart contracts used by the relevant vendor or professional deployer to execute a data sharing agreement or part of one.

Also avoid using Article 36 to bypass the Data Act rules on data access, trade secrets, unfair contract terms, or technical protection measures. A smart contract can help enforce agreed terms or prevent unauthorized access, but Data Act technical measures must not be used to discriminate between recipients or hinder user and third-party rights.

For smart contracts for data sharing, the Data Act record should identify the source clause, Commission guidance, actor role, dataset, request or contract trigger, and the owner who approved the interpretation.

For smart contracts for data sharing, keep the cited external URL, decision date, reviewer, unresolved assumptions, and implementation artifact together so the answer remains auditable.

If Article 36 controls are reused across teams, note which contract version, deployment environment, and standardization reference the team relied on so later reviews can see why the decision was made.

For smart contracts for data sharing, the Data Act workflow should name the legal, product, procurement, cloud, support, or security owner who can change the affected process.

For smart contracts for data sharing, use one accountable owner per action, then record consulted teams and evidence dependencies separately.

Ownership should also cover follow-up work: keeping the Article 36 evidence pack current, updating the agreement when the deployed logic changes, and checking whether new harmonised standards or common specifications affect the deployment.

User-directed sharing is the Article 5 route where the user, or someone acting on the user's behalf, asks the data holder to make readily available data and the metadata needed to interpret and use it available to a third party. The data holder must make the data available without undue delay, with the same quality as is available to the data holder, easily, securely, in a comprehensive, structured, commonly used and machine-readable format, and where relevant and technically feasible continuously and in real time.

This is not an open data-publication duty. It depends on a user request, a qualifying user, a qualifying third party, and data generated by the connected product or related service that is readily available to the data holder.

For Chapter II sharing, the practical scope is raw and pre-processed data generated from the use of a connected product or related service that is readily available to the data holder, plus relevant metadata. Commission guidance gives examples such as sensor data on temperature, pressure, flow rate, audio, pH value, liquid level, position, acceleration, or speed.

Do not include inferred or derived information merely because it came from the same product ecosystem. The Commission explains that inferred or derived data, highly enriched data, and content such as audiovisual material are outside the Chapter II scope.

Before users need to exercise the right, Data Act transparency rules require information on how the user can request that data be shared with a third party and, where applicable, end that sharing. During the request, the data holder may verify user or third-party status, but it must not require more information than necessary and must not keep third-party access information beyond what is needed for execution, security, and infrastructure maintenance.

Where the data holder is obliged to make data available to a data recipient, Article 8 requires fair, reasonable, non-discriminatory, and transparent terms. The data holder cannot make data available to a data recipient on an exclusive basis unless the user requested it under Chapter II.

The third party may process the data only for the purposes and under the conditions agreed with the user, and must erase the data once it is no longer necessary for the agreed purpose unless the user agreed otherwise for non-personal data. If personal data is involved, Union and national data-protection law and data-subject rights still apply.

Article 6 also blocks several recipient behaviours: manipulating the user interface or user choices, profiling unless necessary to provide the service requested by the user, onward sharing without a user contract and trade-secret measures, sharing with a designated gatekeeper, using the data to develop a competing connected product, harming security, undermining trade-secret safeguards, or preventing a consumer user from sharing the data with others.

No. An undertaking designated as a gatekeeper under the Digital Markets Act is not an eligible third party for Article 5. The gatekeeper also must not solicit or commercially incentivise a user to make data available to one of its services or ask the data holder to do so.

Article 6 adds a downstream control: a third party that received the data must not make the data available to a designated gatekeeper.

Trade secrets are not a blanket reason to ignore Article 5. They must be preserved and may be disclosed to third parties only to the extent strictly necessary for the purpose agreed between the user and the third party. The data holder or trade secret holder must identify protected data, including relevant metadata, and agree proportionate technical and organisational confidentiality measures with the third party.

If measures are not agreed, the third party fails to implement them, or confidentiality is undermined, the data holder may withhold or suspend sharing of the identified trade-secret data, give a duly substantiated written decision to the third party without undue delay, and notify the competent authority. Refusal is reserved for exceptional case-by-case circumstances where the data holder is also the trade-secret holder and can demonstrate a high likelihood of serious economic damage despite the measures.

Security is relevant, but the Data Act frames it narrowly. Users and data holders may contractually restrict or prohibit access, use, or further sharing where the processing could undermine security requirements of the connected product laid down by Union or national law and result in serious adverse effects on the health, safety, or security of natural persons.

A recipient also must not use the data in a way that adversely affects the security of the connected product or related service. Security controls should therefore be tied to legal security requirements and the specific risk, not used as a generic objection to third-party access.