Search every question across sub-FAQs

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.

Yes, but the Data Act does not give data holders an open-ended right to set deterrent access fees. Article 9 says compensation agreed between a data holder and a data recipient for making data available in B2B relations must be reasonable and non-discriminatory, and it may include a margin.

The first scoping question is whether Chapter III applies: the data holder must be obliged in a B2B relationship to make data available under Article 5 or under applicable EU law or national legislation adopted in accordance with EU law. If the sharing is voluntary, consumer-facing, business-to-government, or cloud switching, use the rules for that workflow instead.

The Data Act context is the starting point for this answer. Article 9 points to concrete inputs, not a generic market-price uplift. The parties must take into account costs incurred in making the data available, especially formatting, electronic dissemination, and storage. They must also consider investments in collecting and producing the data where applicable, including whether other parties contributed to obtaining, generating, or collecting the data.

The compensation may also depend on the volume, format, and nature of the data. That allows different calculations for materially different data requests, but it does not support unexplained charges, punitive access fees, or prices that cannot be tied back to the Article 9 inputs.

Article 9 says compensation may include a margin, but the margin still sits inside the rule that the overall compensation must be reasonable and non-discriminatory. The Data Act therefore supports a documented margin analysis, not an arbitrary profit line or a charge designed to make access unattractive.

The margin position should be checked against the recipient category. Where the data recipient is an eligible SME or not-for-profit research organisation, Article 9(4) limits compensation to the costs incurred in making the data available, which excludes a margin above those cost elements for that protected recipient category.

The Data Act gives protected treatment to data recipients that are SMEs or not-for-profit research organisations, provided the recipient does not have partner enterprises or linked enterprises that do not qualify as SMEs. For those recipients, compensation cannot exceed the costs incurred in making the data available under Article 9(2)(a).

The grounding materials support SME treatment, but not a separate startup-only threshold or discount. A startup should therefore be assessed through the Data Act SME test and any partner or linked enterprise facts, rather than by assuming that all startups receive a special fee rule.

The Data Act context is the starting point for this answer. The data holder must provide the data recipient with information setting out the basis for calculating compensation in enough detail for the recipient to assess whether Article 9(1) to 9(4) are met. A single line item such as "data access fee" is unlikely to be useful for that assessment.

A practical disclosure should show the relevant data scope, cost categories, investment assumptions where used, volume or format factors, margin treatment where applicable, and whether the SME or not-for-profit research organisation cap was assessed.

The Data Act context is the starting point for this answer. Compensation clauses should be reviewed together with Chapter IV on unfair contractual terms. Article 13 applies to contractual terms concerning access to and use of data, or liability and remedies for breach or termination of data-related obligations, when an enterprise unilaterally imposes the term on another enterprise.

A compensation term is higher risk when it is take-it-or-leave-it, cannot be meaningfully negotiated, lets the imposing party interpret conformity alone, limits remedies inappropriately, or allows substantial price changes without a valid reason and termination right. Article 13 does not assess adequacy of price against data supplied, but surrounding terms can still be unfair.

Trade secrets are a safeguard issue, not a blank cheque for compensation. The Commission FAQ explains that a data holder may require confidentiality and secrecy safeguards before disclosure, and the Data Act allows withholding, suspension, or exceptional refusal only under specific conditions. A trade secret label alone is not enough to block the access right.

Where trade secret protection affects cost, separate the protection measure from the compensation calculation. For example, confidentiality arrangements, strict access protocols, or technical controls may affect the effort needed to make data available, but the data holder should still be able to show how those measures relate to the requested data and Article 9 cost basis.

Keep a file that lets someone else reconstruct the Data Act Article 9 decision. The record should show the mandatory sharing trigger, the recipient category, the cost items used, any margin analysis, and the disclosure given to the recipient. It should also show why similar recipients were treated the same or differently.

Because Article 10 allows certified dispute settlement bodies to resolve FRAND and compensation disputes, teams should also keep the material they would need if the amount is challenged: the worksheet, recipient correspondence, and the rationale for any SME or research-organisation cap.

Avoid treating the Data Act as if it supplies a fixed tariff table. The grounding sources support cost categories, margin possibility, protected-recipient caps, calculation transparency, and dispute routes; they do not support invented per-API-call fees, percentage-of-revenue formulas, statutory penalty amounts for overcharging, or universal startup discounts.

Also avoid using compensation to do work that belongs to another rule. Trade secret risk should be handled through safeguards and, where justified, the Data Act handbrake. Bargaining-power problems should be handled through unfair-term review. Personal data issues still need GDPR compliance, because the Data Act does not create a new legal basis for personal data processing.

Keep the source material that shows why this Data Act FAQ answer is grounded in Article 9 and related Commission guidance. For a compensation question, the most useful evidence is the exact legal trigger, the cost basis used, the recipient type, and any transparency note that was shared with the recipient.

Also keep the version of the source you relied on, because the current answer depends on the Data Act text, the Commission explanation page, and the FAQ guidance on compensation, margin limits, and disclosure. If the calculation later changes, reviewers should be able to see what changed and why.

Assign the Data Act question to the team that can actually change the compensation workflow. In practice, that is usually legal for the Article 9 analysis, finance or pricing for the worksheet, and the product or operations owner for the request process and recipient notice.

One person should own the final decision, but legal, commercial, privacy, and security reviewers should each have a clear role. That helps avoid a single compensation amount being reused in situations that have different recipient categories, different cost bases, or different trade secret constraints.

The Data Act answer is only useful later if someone can trace it back to the actual request, the data scope, and the cost model. Keep the request or contract clause that triggered Chapter III, the internal calculation, the recipient-facing explanation, and any note showing whether the cap for SMEs or not-for-profit research organisations was applied.

It also helps to keep evidence of any trade secret safeguards, because those often affect the amount and the wording of the disclosure. If the issue is ever challenged, the reviewer should be able to reconstruct both the amount and the reason the amount was disclosed in that form.