EU Data Act Article 36 Smart Contract Controls FAQ

Article 36 applies when a smart contract is used in the context of executing an agreement, or part of an agreement, to make data available. The trigger is not simply using blockchain, automation, or an electronic ledger. The trigger is the use of smart-contract functionality for execution of a data-sharing agreement covered by the Data Act context.

The first scoping check should name the agreement, the data being made available, the automated functions that execute the agreement, and whether the organization is the vendor of an application using smart contracts or the deployer for others where no vendor is present.

The Data Act context is the starting point for this answer. Article 36 lists five essential requirements. The smart contract must be designed for robustness and access control; support safe termination and interruption; allow archiving and continuity when terminated or deactivated; be protected by rigorous governance-layer and smart-contract-layer access controls; and remain consistent with the terms of the data-sharing agreement it executes.

A useful control matrix should map each requirement to the relevant code version, governance permission, operational runbook, test evidence, and agreement clause. The evidence should show that the control exists before relying on the smart contract in the data-sharing workflow.

The Data Act context is the starting point for this answer. Article 36 mentions access control twice: first as part of robustness against errors and third-party manipulation, and again as a requirement for rigorous access control at both the governance and smart contract layers. That means access control should not be limited to wallet ownership or a single administrator key.

Evidence should show who can deploy, upgrade, pause, terminate, reset, or change parameters; how those permissions are approved; how privileged actions are logged; and how the same controls are reflected in the agreement and operating process.

The Data Act context is the starting point for this answer. Article 36 requires a mechanism to terminate continued execution of transactions and internal functions that can reset, stop, or interrupt operation, especially to avoid future accidental executions. This is a technical-control requirement, not a license for one party to rewrite the commercial bargain unilaterally.

Recital 104 adds an important limit: the requirement to ensure smart contracts can be interrupted and terminated implies mutual consent by the parties to the data-sharing agreement. The runbook should therefore connect technical stop functions to the agreement's approval path, notices, and evidence of consent.

The Data Act context is the starting point for this answer. Article 36 requires the possibility to archive transactional data, smart contract logic, and code where the smart contract must be terminated or deactivated, so that past operations on the data remain auditable. The archiving plan should be designed before deployment, because a terminated contract may no longer expose the same operational state.

The archive does not need to become a public dump of sensitive data. It should preserve enough evidence to reconstruct what the smart contract did, under which agreement version, with which permissions, and with which data-sharing transaction history, while respecting separate confidentiality, security, and data protection controls.

The Data Act context is the starting point for this answer. No. Article 36 requires consistency between the smart contract and the data-sharing agreement it executes, but Recital 104 says applicable civil, contractual, and consumer protection law remains unaffected by using smart contracts for automated execution. Teams should avoid saying that the code itself resolves legal rights, consent, liability, or contract interpretation.

The practical requirement is alignment. The code, interface, access permissions, termination mechanism, and archive record should match the agreed terms. If the written agreement changes, the smart contract control record should show whether code or configuration changes are needed before continued use.

The Data Act context is the starting point for this answer. The vendor of a smart contract, or the deployer for others where there is no vendor, must perform a conformity assessment with a view to fulfilling the Article 36 essential requirements and issue an EU declaration of conformity when those requirements are fulfilled. Drawing up that declaration makes the actor responsible for compliance with the Article 36 essential requirements.

The evidence file should therefore be more than a security review. It should include the Article 36 requirement mapping, test results, access-control design, termination and interruption test evidence, archive plan, agreement-consistency review, version identifiers, approver sign-off, and the EU declaration of conformity.

The Data Act context is the starting point for this answer. Article 36 provides a presumption of conformity where a smart contract meets harmonised standards, or relevant parts of them, whose references are published in the Official Journal of the European Union, to the extent those standards cover the essential requirements. It also allows the Commission to adopt common specifications as a fallback where the listed conditions are met.

The wider Data Act standardisation work is active, but teams should not claim that a future or adjacent standard automatically proves Article 36 compliance. Use the Data Act text as the binding source, then track whether an Article 36 harmonised standard or common specification has been published and which requirement it covers.

The Data Act context is the starting point for this answer. A practical record should let a reviewer understand scope, ownership, controls, and evidence without reconstructing the project from code comments. The record should identify the data-sharing agreement, the smart contract version, the responsible actor, each Article 36 requirement, the evidence used to assess it, and the declaration or standards basis relied on.

The record should also show what changed over time. Article 36 controls can become stale when agreement terms change, access roles are modified, a new deployer takes over, code is upgraded, termination functions are adjusted, or relevant standards or common specifications are published.

The Data Act context is the starting point for this answer. The common mistake is treating Article 36 as a blockchain policy page instead of a concrete conformity and control obligation for smart contracts executing data-sharing agreements. Generic statements about security, immutability, decentralisation, or automation do not answer the Article 36 questions.

A defensible answer identifies the covered agreement, responsible actor, exact smart contract functions, access-control layers, termination and interruption path, archive plan, agreement-consistency check, conformity assessment, and EU declaration status. It also avoids uncited claims about fines, effective dates, or legal effects that are not needed to answer the Article 36 control question.

Keep the source evidence that shows why Article 36 applies and how the control decision was made. At a minimum, store the cited Data Act clause, the smart contract role identified by Article 36, the agreement version, the specific control tested, and the conformity evidence used to support the answer.

Also keep the decision date, the reviewer or approver, and the linked implementation artifact so future reviewers can see how the Article 36 control position was reached and whether the same conclusion still fits the current agreement and code version.

Assign one accountable owner for the Data Act Article 36 control record itself: the vendor of the smart contract or, where there is no vendor, the person deploying smart contracts for others in the context of executing the agreement. That owner should be responsible for the conformity assessment, the EU declaration of conformity, and the control record that links the smart contract to the agreement.

Other teams can contribute evidence, but the owner should be the person or function that can approve code, access control, interruption, archiving, and agreement changes. When responsibilities are split, keep the legal, product, security, and engineering contributors named separately so the accountable owner remains clear.