Draft B2B data-sharing clauses around the Data Act rule that data holders make data available to data recipients on fair, reasonable, non-discriminatory, and transparent terms.
Use this drafting map to cover access scope, recipient duties, compensation, trade secrets, unfair-term review, audit evidence, termination, and personal data boundaries.
Use this clause checklist to apply the Data Act's B2B data-sharing rules, including the baseline, to contracts between data holders, users, and data recipients. It identifies what each clause needs to decide and document but does not supply model wording or support a negotiation preference that lacks a legal basis.
1
Section 1
Start with the statutory Data Act B2B access scenario before drafting clauses
A Data Act B2B data-sharing clause should first state why the is making data available. Article 8 applies where, in a business-to-business relationship, a data holder is obliged under Article 5 or other applicable Union law, or national legislation adopted in accordance with Union law, to make data available to a . For obligations created by other Union law or qualifying national legislation, Article 50 applies Chapter III only where that law or legislation entered into force after 12 September 2025.
Define the user, , , connected product or related service, dataset, and request route before drafting commercial protections. The Commission's model contractual terms separate the data-holder-to-user, user-to-data-recipient, and data-holder-to-data-recipient relationships, which is a useful drafting structure even when the parties use their own language.
Identify whether the recipient receives data at the user's request or under another legal obligation.
State that access terms are subject to fair, reasonable, non-discriminatory, and transparent conditions.
Separate mandatory Data Act rights from voluntary data sharing or broader commercial data licenses.
Do not make the user's Data Act sharing right conditional on the parties first signing a bespoke contract.
Review Data Act B2B data-sharing clauses against cited obligations
Use Sorena to check data-holder, user, and data-recipient clause packs against Data Act source text, Commission model terms, compensation guidance, and the personal-data boundary.
Describe the data package precisely so the Data Act sharing scope is unambiguous
The data schedule should be specific enough for engineering to deliver the package and for legal to test the Data Act scope. Include the connected product or related service, data categories, metadata, quality, format, update frequency, delivery route, security controls, exclusions, and any dependencies on the user's request.
For Chapter II connected-product data, the access right targets readily available product data and related service data, including metadata necessary to interpret and use the data. The Commission FAQs describe the practical boundary as raw and pre-processed data, while inferred or derived outputs from additional investments are outside that access scope unless the parties agree otherwise.
List raw and pre-processed data separately from inferred, derived, enriched, or excluded data.
Include metadata such as timestamp, basic context, units, source system, and delivery schema when needed for use.
State whether access is direct, indirect, continuous, real-time, batch, API-based, or file-based.
Record why each exclusion applies instead of using broad labels such as proprietary data or confidential information.
Draft FRAND terms that can be checked against the Data Act fairness requirements
wording should be measurable. A clause that says access is provided on FRAND terms is weak unless it also explains delivery quality, request verification, support, availability, change notice, security conditions, and how the will show comparable recipients are not treated differently without objective reasons.
Article 8 requires the not to discriminate between comparable categories of data recipients. If a gives a reasoned request, the data holder must provide information showing there has been no discrimination without undue delay.
Define comparable recipient categories, such as repair providers, analytics vendors, fleet operators, or research recipients.
Keep a pricing and delivery matrix that explains differences in volume, format, interface, service level, or risk controls.
Avoid exclusivity unless it is requested by the user and compatible with the Data Act scenario.
Limit information requests to what is necessary to verify contractual compliance or legal obligations.
Set compensation within the Data Act calculation rules
A compensation clause should show the calculation basis. Article 9 allows reasonable, non-discriminatory compensation that may include a margin. The parties must take account of the costs of making data available and, where applicable, investments in collecting and producing the data, including whether other parties contributed. Volume, format, and the nature of the data may also affect compensation.
For SME data recipients and not-for-profit research organisations without non-SME partner or linked enterprises, compensation cannot exceed the costs incurred in making the data available. The Data Act also requires the to give the enough detail to assess whether the Article 9 requirements are met.
Separate formatting, electronic dissemination, storage, interface, support, and request-handling costs.
Identify any margin separately and switch it off where the recipient is covered by the SME or not-for-profit research organisation cap.
Describe the charge as compensation for making data available and show how the Article 9 factors produce the amount.
Attach a calculation note to each negotiated fee or subscription model.
Build trade secret safeguards before disclosure as the Data Act allows
Trade secret clauses should not be blanket refusals. Articles 4 and 5 require protected trade secrets to be identified, including in relevant metadata, and disclosed only where the parties take necessary measures before disclosure to preserve confidentiality.
The clause should list the technical and organisational measures that apply to the recipient: confidentiality undertakings, access controls, named users, secure environments, encryption, logging, onward-sharing limits, deletion duties, and incident notice. If no agreement is reached on necessary measures, or if agreed measures are not implemented or confidentiality is undermined, the may withhold or suspend the sharing of identified trade-secret data with written reasons.
Identify the trade secret holder when it is not the .
Mark protected data and metadata at field or dataset level where possible.
Use proportionate safeguards instead of excluding an entire dataset by default.
Write the suspension notice clause so it records the missing safeguard, affected data, and competent-authority notification where required.
Limit recipient use, onward sharing, and misuse remedies under the Data Act
Recipient clauses should state the permitted purpose, prohibited uses, onward-sharing controls, data security duties, deletion triggers, and remedies for misuse. Article 11 allows data holders to use technical protection measures such as smart contracts and encryption, provided those measures do not discriminate between data recipients or hinder the user's rights.
The Data Act gives specific response tools when a recipient uses false information, deceptive or coercive means, abuses technical gaps, uses data for unauthorised purposes, unlawfully discloses data, fails to maintain trade-secret safeguards, or removes technical protection measures without agreement.
Ban use of the data to develop a competing connected product where the Data Act prohibits it.
Require deletion of data and copies when the purpose ends, the contract terminates, or misuse is substantiated.
Require notice to the user for unauthorised use or disclosure where Article 11 calls for it.
Include compensation for misuse or disclosure of unlawfully accessed or used data.
Screen data clauses for unfair-term risk under the Data Act fairness test
Article 13 applies to B2B terms concerning access to and use of data, or liability and remedies for breach or termination of data-related obligations, when they are by one enterprise on another. Chapter IV applies to contracts concluded after 12 September 2025. From 12 September 2027 it also reaches older contracts of indefinite duration and older contracts due to expire at least 10 years from 11 January 2024. If an unfair term is severable, the rest of the contract remains binding.
Do not give one party exclusive power to decide whether supplied data conforms to the contract, remove all remedies for non-performance, block termination within a reasonable period, block copies of data after termination, or allow unexplained unilateral changes to data price, format, quality, nature, or quantity.
The party that supplied a contested term bears the burden of proving that it was not . Article 13 does not review terms defining the contract's main subject matter or the adequacy of the price against the data supplied, but parties cannot contract out of the unfair-term rule.
Keep drafts, redlines, objections, meeting notes, and approvals showing whether the other enterprise could influence the term after attempting to negotiate it.
Give both parties usable remedies for data non-performance and safeguard breaches.
Avoid one-sided interpretation, conformity, audit, suspension, and termination rights.
Allow reasonable termination and post-termination data copy rights where Article 13 would presume the opposite unfair.
Use logs for necessity, security, and audit evidence of Data Act compliance
Audit and logging clauses should be narrow enough to respect the Data Act's necessity limits. Article 4 says a must not keep user access information, especially log data, beyond what is necessary for sound execution of the access request and for security and maintenance of the data infrastructure.
For B2B recipient access, the contract should keep enough evidence to verify compliance with the access terms and Data Act obligations, but Article 8 prevents the parties from demanding information beyond what is necessary for that verification.
Log request identity, authority check, dataset, delivery time, format, recipient endpoint, safeguard version, and suspension or refusal reasons.
Set retention by purpose: execution, security, maintenance, dispute evidence, and legal hold should not be mixed without explanation.
Avoid broad audit rights that expose unrelated systems, unrelated customers, or personal data not needed for verification.
Record responses to discrimination, compensation, trade secret, and misuse disputes.
Keep personal data boundaries outside the commercial bargain in Data Act deals
The Data Act covers personal and non-personal data, but it does not supersede GDPR or ePrivacy rules. Article 1 says that where there is a conflict, Union or national personal data and privacy law prevails.
If the user is not the data subject, the may make personal data generated by the connected product or related service available to the user only where there is a valid GDPR legal basis and, where relevant, the conditions for special category data and terminal-equipment access are met. The clause should therefore separate Data Act access mechanics from controller, processor, lawful basis, transparency, minimisation, security, and data-subject-rights terms.
Classify each field as personal data, non-personal data, mixed data, anonymised data, or excluded content.
Identify the controller and processor roles for each personal data flow.
Use anonymisation, filtering, or field suppression where the user is not the data subject and no valid basis supports disclosure.
Do not present the Data Act as a standalone legal basis for collecting, generating, or sharing personal data.
Assemble a Data Act clause pack that survives negotiation and later audits
The finished contract pack should include the operative clauses, a dataset schedule, a recipient-use schedule, a compensation calculation note, trade-secret safeguard schedule, personal-data boundary note, logging and audit schedule, and termination and post-termination data handling terms.
Use Commission model contractual terms as drafting support, not as mandatory wording. The public Commission page says the model terms are voluntary, mainly drafted for B2B contracts, and designed to help parties implement the Data Act.
For -to-recipient terms, include access route, data package, commitments, compensation, safeguards, technical protection measures, and dispute route.
For user-to-recipient terms, include the user's instruction, permitted use, data security, onward sharing, deletion, and misuse remedies.
For -to-user terms, include user request mechanics, direct or indirect access, trade-secret controls, personal-data handling, and termination of sharing.
For all terms, keep source citations, negotiation history, calculation evidence, and version control with the contract record.
If the parties choose an Article 10 certified dispute settlement body, record its fees and whether they consented in advance to a binding decision. The body must issue a reasoned decision within 90 days, without removing either party's right to go to court.
Confirms that GDPR applies to personal data processing under the Data Act and that data protection authorities remain competent for personal-data issues.
Article 10 sets the certified dispute-settlement process and 90-day decision period; Article 41 required non-binding model terms covering data access, reasonable compensation, trade secret protection, and FRAND rights and obligations.