Use this as a drafting outline for B2B Data Act data-sharing agreements: identify the user and data holder, define the dataset, record the access route, set permitted-use limits, protect trade secrets, price access transparently, and preserve evidence.
The structure is grounded in Regulation (EU) 2023/2854, the Commission Data Act FAQ, and Commission materials on data contracts and model terms. It is a practical drafting aid, supporting implementation planning and should be validated against jurisdiction-specific legal, contractual, and policy requirements before implementation.
A Data Act B2B data-sharing contract should not be a generic confidentiality addendum. It needs schedules that product, legal, security, privacy, and commercial teams can complete for a specific connected product, related service, user request, data recipient, dataset, delivery method, and compensation position.
1
Section 1
Data Act Template front sheet: parties, role, 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 data holder 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 data recipient under another EU or national legal obligation covered by Chapter III.
Required fields: agreement title, version, product or related service, user, data holder, data recipient or third party, trade secret holder 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.
Complaint and dispute fields: name the competent authority route, court route, and whether the parties agree to use a certified dispute settlement body for FRAND, safety, security, or trade-secret disputes.
Data Act 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.
The schedule should 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 data holder, 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.
Data Act Access method clause: delivery channel, service levels, security controls, and technical protection
The agreement should state how access happens, not just that access is allowed. A usable clause names 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.
Data Act 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 data holder's economic situation, assets, production methods, or use.
Data Act Trade secret annex: identification, safeguards, handbrake records, and notice
Do not hide trade secrets in a broad confidentiality clause. The annex should require the data holder or trade secret holder 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.
Data Act 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. Under Chapter III, compensation in B2B data availability arrangements 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 data recipient 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.
Data Act 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.
Data Act 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.
Unfair-term review belongs in the template because Chapter IV can apply to data-access and data-use terms inside a broader commercial contract, even when the main contract is not primarily a data-sharing agreement.
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: no unilateral term giving one party exclusive power to decide conformity or interpret the contract; no inappropriate limits on remedies; no unreasonable short-notice termination; no unjustified unilateral change to data nature, format, quality, quantity, or price.
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.
Data Act Turn the template into a reviewed 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.
Data Act 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.
FAQ Questions 42 and 42a explain when Article 13 unfairness control applies to data-related clauses, including clauses inside contracts primarily about another subject.
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.
Article 41 requires Commission-recommended non-binding model contractual terms for data access and use, reasonable compensation, and trade-secret protection.