Search every question across sub-FAQs

Yes. Article 32 requires the provider to inform the customer about a third-country authority request before complying. The exception applies where the request serves law-enforcement purposes, for as long as withholding notice is necessary to preserve the effectiveness of that activity.

Customer notice should be a controlled workflow, not an informal support message. The record should show whether notice was given, what was said, when it was sent, and, if notice was delayed or withheld, the documented law-enforcement reason.

International government access under Article 32 is separate from Chapter V business-to-government data sharing. Chapter V concerns qualifying EU public-sector bodies, the Commission, the European Central Bank, and Union bodies requesting privately held data because of an exceptional need. Article 32 concerns third-country governmental access to or transfer of non-personal data held in the Union by providers of data processing services.

Keeping those workflows separate matters because their triggers, requesters, data categories, and safeguards differ. A provider receiving a non-EU authority request should not reuse an EU public-emergency request template without checking Article 32.

Keep the received request, requester identity and authority, requested-data inventory, EU or Member State conflict assessment, international-agreement analysis, any national-authority opinion request or response, customer-notice record, minimisation analysis, and final disclosure or refusal log.

For standing compliance, keep the published Article 28 web disclosure, contract references to that web page, safeguard descriptions, control-owner assignments, and change history for technical, organisational, legal, and contractual measures. These records show that the provider had preventive controls before the request, not only a one-off response after escalation.

Freeze the request record and route it to legal, security, cloud operations, and the customer account owner. Confirm Article 32 scope, any international agreement supporting recognition or enforceability, the no-agreement safeguards, the national-authority opinion route, customer notice, and the minimum data that may be disclosed.

An ordinary support workflow is insufficient. The Data Act requires a provider-level conflict review in addition to identity verification of the requester.

Under the Data Act, record the legal basis first: whether the request is enforceable under an in-force international agreement or must pass the Article 32(3) conflict checks. If there is doubt, document the national-body opinion request, the one-month reply window, and the final reason for accepting or rejecting access.

Then keep the record narrow. Note the minimum amount of data disclosed under Article 32(4), the date and method of customer notice under Article 32(5), and the safeguard controls used to prevent broader access than the Regulation allows.

Article 32 expressly governs third-country governmental access to non-personal data held in the Union by providers of data processing services. It does not supply a route for personal data. A request spanning a mixed dataset can engage Article 32 for its non-personal part and EU data-protection, law-enforcement, or other applicable rules for its personal-data part.

Separate the personal and non-personal elements before deciding whether and how to respond. Do not assume that satisfying Article 32 makes disclosure of personal data lawful.

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.

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.

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. Access control should therefore 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.

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.

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. Design the archiving plan 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.

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. The code itself does not resolve 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 vendor of an application using smart contracts, 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.

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.

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.