Contract TemplateEUData Act

EU Data Act B2B Data-Sharing Contract Template

Use this drafting outline for B2B Data Act agreements: identify the user, data holder, and recipient; define the dataset and access route; set use limits; protect trade secrets; calculate compensation; and preserve evidence.

The outline draws on Regulation (EU) 2023/2854 and Commission guidance and model terms. It is not an official form or mandatory wording. Adapt it to the parties, dataset, applicable access rule, data protection law, and national contract law.

Back to main artifact Review sources

Author

Sorena AI

Published

May 6, 2026

Updated

Jul 25, 2026

Sections

Structured answer sets in this page tree.

Primary sources

Cited legal and guidance references.

Publication metadata

Sorena AI

Published May 6, 2026

Updated Jul 25, 2026

Overview

A Data Act B2B agreement needs schedules for the parties' legal roles, including the user, , third party, or ; the connected product or related service; the user's request; each dataset; delivery method; recipient purpose; trade-secret safeguards; personal-data conditions; and any compensation. The Data Act has applied since 12 September 2025, but the access rule, exemptions, and contract consequences depend on the specific relationship.

Section 1

Template front sheet: parties, roles, request authority, and source rule

Start the template with a front sheet that makes the Data Act role map explicit. The same company can be a user for one product and a for another, so the agreement should not rely on generic supplier or customer labels.

The front sheet should also state whether the data is made available to the user under Article 4, to a third party at the user's request under Article 5, or to a under another EU or national legal obligation covered by Chapter III.

Required fields: agreement title, version, product or related service, user, , or third party, if different, privacy contact, security contact, and commercial owner.
Authority fields: evidence that the requester is the user or acts on the user's behalf, the request channel used, the requested purpose, and any limits on the information collected only to what is necessary to verify the role.
Scope switch: mark whether this is direct user access, data-holder-to-third-party sharing, or another legally required B2B data availability arrangement.
Scope exclusions: record whether Article 7 excludes Chapter II because the product or related service comes from a qualifying microenterprise or small enterprise, or falls within the one-year medium-enterprise and product transition. Check partner, linked-enterprise, and subcontracting conditions before relying on the exclusion.
Application fields: record the contract date and legal source. For data-making-available duties created by other EU law or national legislation adopted in accordance with EU law, Chapter III applies where that legislation entered into force after 12 September 2025. Chapter IV applies to contracts concluded after that date and, from 12 September 2027, to specified older long-term or indefinite contracts.
Complaint and dispute fields: name the competent-authority route, court route, and whether the parties agree to use a certified dispute settlement body for disputes covered by Article 10.

Sources for this answer

Regulation (EU) 2023/2854 (Data Act)

Articles 4, 5, 7, 8, and 10 and Article 50 support the fields for user requests, third-party sharing, Chapter II enterprise exclusions, B2B FRAND arrangements, dispute settlement, and application dates.

European Commission - Data Act FAQ

The FAQ explains role mapping, multiple-user scenarios, and that companies may have different Data Act roles in different product or service relationships.

Section 2

Data schedule: connected product, related service, data categories, metadata, and exclusions

The data schedule is the operational core of the contract. It should identify the connected product or related service, then list each dataset in enough detail for engineering to locate, prepare, and deliver it without inventing a scope after signature.

For Article 4 and Article 5 requests, the schedule should identify , then separate raw data, pre-processed data, relevant metadata, inferred or derived material, trade-secret material, personal data, and data that is outside the agreed request.

Dataset fields: dataset name, product or service source, sensor or system source, data category, sample fields, timestamp or event context, basic metadata, expected volume, historical coverage, and update frequency.
Format fields: CSV, JSON, XML, API, bulk export, stream, dashboard export, or another comprehensive, structured, commonly used, machine-readable format that the parties can actually operate.
Quality fields: whether the data is provided at the same quality available to the , known gaps, refresh delay, latency expectation, and whether continuous or real-time access is relevant and technically feasible.
Exclusion fields: inferred or derived insights, proprietary algorithm outputs, data not readily available without disproportionate effort, new product test data where third-party use is not contractually permitted, and any legal security restriction.

Sources for this answer

Regulation (EU) 2023/2854 (Data Act)

Article 4 and Article 5 require readily available data and relevant metadata to be made available in a structured, commonly used, machine-readable format.

European Commission - Data Act FAQ

FAQ Question 22a supports practical schedule fields for format, quality, timeliness, latency, convenience, and security.

Section 3

Access-method clause: delivery channel, service levels, security controls, and technical protection

The agreement should name the interface, authentication method, delivery frequency, error handling, support route, and evidence kept for each transfer.

Security language should protect the data and the connected product without becoming a hidden veto over the user's access right.

Delivery fields: API endpoint, export workspace, on-device or remote access route, authentication method, encryption in transit, credential owner, start date, frequency, and termination or pause trigger.
Service-level fields: expected response time, batch or real-time delivery, data refresh interval, planned downtime notice, incident contact, and fallback delivery if the main route fails.
Technical protection fields: encryption, access logs, strict access protocols, smart contract or other control where used, and an express rule that controls cannot discriminate between comparable recipients or obstruct Data Act access rights.
Security restriction fields: the legal security requirement relied on, the serious adverse effect being avoided, the narrower restriction proposed, the notice to the competent authority if sharing is refused, and the user's challenge route.

Sources for this answer

Regulation (EU) 2023/2854 (Data Act)

Article 4 supports secure access and limited security restrictions; Article 11 supports technical protection measures that prevent unauthorised use without blocking lawful access.

European Commission - Data Act FAQ

The FAQ explains practical format, latency, convenience, security, and the safety and security handbrake for access restrictions.

Section 4

Permitted-use clause: purpose, recipient obligations, onward sharing, and competing-product limits

The permitted-use clause should be short enough to enforce and specific enough to audit. It should tie use of the data to the purpose agreed with the user and identify uses that the Data Act does not allow.

For third-party recipients, the template should include recipient undertakings rather than leaving them in a separate service proposal.

Purpose fields: agreed service or business purpose, user instruction, authorised users, authorised systems, data retention period for the purpose, and erasure or return step when the purpose ends.
Recipient promises: do not use coercive or deceptive means to obtain data, do not abuse technical gaps, do not undermine agreed trade-secret safeguards, and do not remove technical protection measures without agreement.
Onward sharing fields: whether onward sharing is allowed, identity of onward recipient, contract with the user, confidentiality measures carried forward, and a prohibition on making data available to a Digital Markets Act gatekeeper through the Article 5 route.
Competition limits: do not use the data to develop a competing connected product and do not use non-personal product or related service data to derive insights about the 's economic situation, assets, production methods, or use.

Sources for this answer

Regulation (EU) 2023/2854 (Data Act)

Article 6 supports recipient-purpose limits, erasure, profiling limits, onward-sharing controls, gatekeeper limits, and competing-product prohibitions.

European Commission - Data Act FAQ

FAQ Questions 35 and 36 explain what third parties may do with received data and why DMA gatekeepers cannot rely on the Article 5 mandatory sharing route.

Section 5

Trade-secret annex: identification, safeguards, handbrake records, and notice

Do not hide trade secrets in a broad confidentiality clause. The annex should require the or to identify the protected data, including relevant metadata, before disclosure and to agree proportionate safeguards with the user or third party.

The same annex should record the limited cases where sharing is withheld, suspended, or refused and the notices that must follow.

Identification fields: trade secret owner, dataset rows or fields affected, metadata marking, reason for confidentiality, jurisdictions or recipients that increase risk, and whether a redacted or filtered dataset can satisfy the request.
Safeguard fields: confidentiality agreement, strict access protocol, access list, encryption, secure workspace, export limits, deletion duty, audit trail, technical standard, code of conduct, or Commission model term where used.
Withhold or suspend record: missing safeguard agreement, failed implementation, confidentiality undermined, data affected, written reasons, competent-authority notice, and restart condition.
Exceptional refusal record: specific data refused, objective evidence of highly likely serious economic damage, why safeguards are insufficient, written notice, competent-authority notice, and challenge route.

Sources for this answer

Regulation (EU) 2023/2854 (Data Act)

Articles 4(6)-(9) and 5(9)-(12) support trade-secret identification, safeguards, withholding, suspension, exceptional refusal, notices, and challenge routes.

European Commission - Data Act FAQ

FAQ Question 23 explains that trade-secret protection continues and describes the Data Act handbrake mechanism for withholding, suspension, and exceptional refusal.

Section 6

Compensation schedule: FRAND terms, cost basis, SME cap, and invoice evidence

The compensation schedule should make the pricing basis visible before the parties argue about the number. The user must receive Article 4 access free of charge, while a making data available to a third party under Article 5 may agree reasonable compensation with that recipient under Article 9. Across covered B2B data-availability arrangements, the terms must be non-discriminatory and reasonable, and the data holder must explain the calculation in enough detail for the recipient to assess it.

If the is an SME or a not-for-profit research organisation without non-SME partner or linked enterprises, the template should flag the narrower cost ceiling.

Pricing fields: cost elements for formatting, electronic dissemination, storage, access setup, support, anonymisation or pseudonymisation where relevant, volume, format, nature of the data, and any margin.
SME and research fields: recipient status, linked or partner enterprise check, whether the SME or not-for-profit research cost limit applies, and excluded margin if the limit applies.
Non-discrimination fields: comparable recipient category, comparable prior terms, differences justified by volume, format, nature, access route, support level, or legal obligation.
Invoice evidence: calculation worksheet, cost assumptions, access logs, delivered volume, credit or adjustment mechanism, and dispute route for FRAND or compensation disagreement.

Sources for this answer

Regulation (EU) 2023/2854 (Data Act)

Articles 8 and 9 support FRAND access terms, transparent compensation, cost factors, SME and research limits, and calculation disclosure.

European Commission - Data Act FAQ

FAQ Questions 38 to 40 explain comparable-recipient analysis, compensation transparency, SME margin limits, and dispute settlement.

Section 7

GDPR boundary clause: personal data, mixed datasets, controller roles, and minimisation

The Data Act does not supersede GDPR or ePrivacy rules. The contract should therefore treat mixed personal and non-personal datasets as a privacy review trigger rather than as ordinary commercial data.

The clause should record whether the user is the data subject, whether the requested data includes personal data of other people, and which legal basis and safeguards are relied on for each processing step.

Boundary fields: personal data present, special-category data present, terminal-equipment access issue, user is or is not the data subject, controller or processor allocation, and data subject rights owner.
Legal basis fields: Article 6 GDPR basis, Article 9 GDPR condition if needed, ePrivacy condition if terminal-equipment access is relevant, and why the Data Act is not being treated as a standalone legal basis to collect or generate personal data.
Minimisation fields: data fields removed, pseudonymisation, anonymisation, filtering to the user's own data where feasible, retention period, erasure step, and audit log retention limited to access execution, security, and infrastructure maintenance.
Conflict rule: the agreement should state that Data Act access, recipient use, and onward sharing do not reduce data subject rights under Union or national data protection law.

Sources for this answer

Regulation (EU) 2023/2854 (Data Act)

Recital 7 and Articles 4(12), 5(7), 5(13), and 6 support GDPR and ePrivacy boundaries for personal data in Data Act access flows.

European Commission - Data Act FAQ

The FAQ explains that the Data Act complements GDPR portability and that different personal-data scenarios require separate analysis.

Section 8

Audit, unfair-term review, breach remedies, and termination

The final schedules should make the agreement reviewable after signature. Keep records showing which data was requested, what was delivered, what was withheld or restricted, why compensation was charged, and how misuse or termination is handled.

Article 13 applies when one enterprise supplies a data-access, data-use, liability, remedy, or termination term and the other enterprise cannot influence it despite trying to negotiate. An unfair unilaterally imposed term is not binding on the enterprise that received it. The rule can reach data-related terms inside a broader commercial contract, but it does not review the main subject matter or the adequacy of the price against the data supplied.

Audit fields: request log, authority evidence, completed data schedule, delivery logs, access logs, trade-secret decisions, compensation worksheet, security incidents, erasure confirmations, and version history.
Unfair-term checks for terms that may be unilaterally imposed: no exclusive power for the imposing party to decide conformity or interpret the contract; no inappropriate limits on remedies; no unreasonable short-notice termination; and no substantial unilateral change to price or another data condition without the conditions Article 13 permits.
Misuse remedies: erase data and copies, stop infringing uses, notify the user of unauthorised use or disclosure, compensate the harmed party where Article 11 conditions apply, and preserve evidence for dispute or authority review.
Termination fields: duration, termination notice period, data access end date, survival of confidentiality and trade-secret safeguards, copy or export right within a reasonable period where relevant, return or deletion duty, and post-termination audit evidence.

Sources for this answer

Regulation (EU) 2023/2854 (Data Act)

Articles 11 and 13 support remedies for specified unauthorised use or disclosure and define when unfairness control applies to unilaterally imposed B2B data access, use, liability, remedy, and termination terms.

European Commission - Data Act FAQ

FAQ Questions 42 and 42a explain when Article 13 unfairness control applies to data-related clauses, including clauses inside contracts primarily about another subject.

Recommended next step

Turn the template into a reviewed Data Act agreement pack

Use Sorena to connect each clause, schedule, and fallback position to the Data Act source text, the product data map, and the evidence needed for negotiation or review.

Research workflow

Open Research Copilot

Check Data Act scope, clause support, and source citations before sending a template for review.

Explore next step

Talk to Sorena

Talk through implementation

Review product scope, data schedules, trade-secret controls, compensation evidence, and GDPR boundaries.

Explore next step

Section 9

How to use Commission model contractual terms without overstating them

The Data Act requires the Commission to recommend non-binding model contractual terms on data access and use. Those materials can help drafting, especially for SMEs, but the template should not present them as mandatory clauses or as a substitute for checking the actual product, dataset, role, and legal basis.

Use model terms as a clause library, then keep a clause matrix showing which term supports access mechanics, permitted use, trade secrets, compensation, security, termination, or dispute handling.

Model-term fields: model term used, clause amendment, mandatory Data Act rule supported, optional commercial position added, reviewer, and reason for departure from the model.
Do not replace the data schedule, GDPR boundary clause, or trade-secret annex with a generic reference to model terms.
Do not cite model terms as the legal basis for refusing, pricing, or narrowing access; cite the Data Act article and the facts that support the position.
Review the template when Commission model terms, FAQs, sector guidance, product architecture, or data categories materially change.

Sources for this answer

Regulation (EU) 2023/2854 (Data Act)

Article 41 requires Commission-recommended non-binding model contractual terms for data access and use, reasonable compensation, and trade-secret protection.

European Commission - Model contractual terms and cloud SCCs

The Commission model-terms page supports the page's distinction between voluntary drafting support and binding Data Act obligations.

European Commission - Innovative technologies and data in contracts

The Commission contract-law page explains why data-sharing and data-provision contracts need data-specific rights and obligations in addition to general contract law.

Primary sources

References and citations

European Commission - Data Act FAQ

ec.europa.eu

Referenced sections

FAQ Questions 42 and 42a explain when Article 13 unfairness control applies to data-related clauses, including clauses inside contracts primarily about another subject.

European Commission - Innovative technologies and data in contracts

commission.europa.eu

Referenced sections

The Commission contract-law page explains why data-sharing and data-provision contracts need data-specific rights and obligations in addition to general contract law.

European Commission - Model contractual terms and cloud SCCs

digital-strategy.ec.europa.eu

Referenced sections

The Commission model-terms page supports the page's distinction between voluntary drafting support and binding Data Act obligations.

Regulation (EU) 2023/2854 (Data Act)

eur-lex.europa.eu

Referenced sections

Article 41 requires Commission-recommended non-binding model contractual terms for data access and use, reasonable compensation, and trade-secret protection.

Related guides