# Data Sharing Agreement: [Disclosing party] and [Receiving party]

> Agreement format for sharing data between organisations that each
> decide how they use it: controller-to-controller sharing of personal
> data, joint controllers under Article 26 of the General Data
> Protection Regulation (Regulation (EU) 2016/679), and business-to-
> business sharing of product and related service data under the EU
> Data Act (Regulation (EU) 2023/2854, applicable from 12 September
> 2025). It records parties and roles, purpose, data scope, lawful
> basis, transfers and onward sharing (GDPR Chapter V), security,
> retention, return and deletion, data subject rights, breach notice,
> audit, compensation and term. Its contents also follow the topics of
> the UK ICO "Data sharing: a code of practice" (statutory code under
> section 121 of the Data Protection Act 2018, in force 5 October 2021).
> Where a party acts only on the other's instructions, use a Data
> Processing Agreement (`legal-lite/dpa`) instead. Replace every
> `[bracketed]` value and every row marked *Example*. This is a
> documentation format, not legal advice: have qualified counsel review
> the final agreement.

<!--
Guidance: How to use this template
- Decide the roles first (section 2). The roles decide which sections
  apply: controller-to-controller, joint controllers, Data Act data
  holder and data recipient, or a mix. Controller-to-processor
  relationships belong in `legal-lite/dpa`.
- Fill the summary sheet in section 1 last, once the detail is agreed,
  so it matches the clauses.
- Data Act section 7 applies only to product data and related service
  data from connected products and related services, or to other cases
  where Union law obliges a data holder to make data available. For
  purely voluntary sharing, the Commission's model contractual terms
  include a set for voluntary sharing; see section 7.6.
- Keep schedules as separate tables at the end (data description,
  security measures, contacts) so they can change without renegotiating
  the main body.
- Related documents: Data Protection Impact Assessment
  (`compliance/dpia`), Records of Processing (`compliance/gdpr-ropa`),
  Privacy-by-Design Review (`compliance/privacy-by-design-review`),
  De-identification Assessment (`compliance/de-identification-assessment`),
  PET Selection Assessment (`compliance/pet-selection-assessment`),
  Data Residency and Sovereignty Assessment
  (`compliance/data-residency-sovereignty-assessment`), Data
  Classification Policy (`data/data-classification-policy`), Data
  Contract (`data/data-contract`), Data Retention and Deletion Standard
  (`data/data-retention-deletion-standard`), Incident Response Plan
  (`compliance/incident-response-plan`).
- The worked example: the fictional retailer Corvid Commerce shares
  order delivery data with the fictional carrier Larkspur Logistics,
  each as an independent controller.
-->

## Document control

<!-- Guidance: Track the agreement as a controlled document. Any change to purpose, data scope, recipients or transfer mechanism is a new major version and needs re-signature. -->

| Field | Value |
|---|---|
| Document ID | [DSA-001] |
| Agreement reference | [Contract number in the contract management system] |
| Parties | [Disclosing party legal name] and [Receiving party legal name] |
| Relationship type | [Controller to controller / Joint controllers / Data Act data holder to data recipient / Mixed] |
| Linked master agreement | [MSA or commercial contract reference, or "Standalone"] |
| Linked DPIA | [DPIA ID or "Screened out, reason"] |
| Governing law and jurisdiction | [Country] |
| Version | [0.1] |
| Status | [Draft / In negotiation / Signed / Under review / Terminated] |
| Owner | [@data-sharing-owner] |
| Approvers/reviewers | [@dpo], [@legal], [@security], [@data-governance-lead] |
| Effective date | YYYY-MM-DD |
| Last updated | YYYY-MM-DD |
| Next review | YYYY-MM-DD |
| Classification | [Confidential] |

### Approvals

| Party and role | Name | Decision | Date |
|---|---|---|---|
| Disclosing party, authorised signatory | [@name] | [Sign / Return with comments] | YYYY-MM-DD |
| Disclosing party, DPO (advice) | [@name] | [Advice reference] | YYYY-MM-DD |
| Receiving party, authorised signatory | [@name] | [Sign / Return with comments] | YYYY-MM-DD |
| Receiving party, DPO (advice) | [@name] | [Advice reference] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@author] | First draft from the request form |
| [0.2] | YYYY-MM-DD | [@author] | [Counterparty comments on sections 4 and 11 resolved] |
| [1.0] | YYYY-MM-DD | [@author] | [Signed version] |
| [1.1] | 2026-10-24 | [@author] | *Example:* Recipient lawful basis corrected to Art. 6(1)(f) and (c); classification and retention values aligned with the disclosing party's policy and standard |

## Contents

- [1. Agreement summary](#1-agreement-summary)
- [2. Parties and roles](#2-parties-and-roles)
- [3. Purpose and permitted use](#3-purpose-and-permitted-use)
- [4. Data scope](#4-data-scope)
- [5. Lawful basis and transparency](#5-lawful-basis-and-transparency)
- [6. Joint-controller arrangement](#6-joint-controller-arrangement)
- [7. EU Data Act obligations](#7-eu-data-act-obligations)
- [8. Transfers and onward sharing](#8-transfers-and-onward-sharing)
- [9. Security](#9-security)
- [10. Data quality and accuracy](#10-data-quality-and-accuracy)
- [11. Retention, return and deletion](#11-retention-return-and-deletion)
- [12. Data subject rights](#12-data-subject-rights)
- [13. Breach and incident notification](#13-breach-and-incident-notification)
- [14. Audit, review and reporting](#14-audit-review-and-reporting)
- [15. Fees and compensation](#15-fees-and-compensation)
- [16. Liability, term, suspension and termination](#16-liability-term-suspension-and-termination)
- [17. Dispute resolution](#17-dispute-resolution)
- [18. Schedules and signatures](#18-schedules-and-signatures)
- [19. Glossary and references](#19-glossary-and-references)
- [Standard and licence note](#standard-and-licence-note)

## 1. Agreement summary

<!-- Guidance: One page that a business owner can read in two minutes. It must match the clauses; where it differs, the clauses prevail. Common pitfall: a summary written at the start and never updated. -->

| Item | Summary |
|---|---|
| Why the data is shared | [One sentence on the objective and benefit] |
| Direction | [One-way from A to B / Two-way / Pooled] |
| Roles | [See section 2] |
| Data | [Categories, about whom, approximate volume] |
| Frequency and method | [Daily SFTP batch / API / Data product subscription] |
| Lawful basis (each party) | [See section 5] |
| International transfer | [None / Yes, mechanism in section 8] |
| Retention by recipient | [Period, see section 11] |
| Compensation | [None / Amount and basis, see section 15] |
| Term | [Start date, duration, renewal] |
| Key contacts | [Schedule C] |

*Example*: Corvid Commerce shares the name, delivery address, phone
number and parcel details of each customer order with Larkspur
Logistics so the parcel can be delivered. Daily volume about 40,000
orders, sent by API at order dispatch. Larkspur keeps name, address and
phone for 90 days after delivery, and parcel data with the order
reference for 24 months for claims. No international transfer. No fee
for the data itself. On Corvid's side, the order records behind each
disclosure stay under its own retention rule RET-002 (orders and
invoices, 7 years from the end of the financial year).

## 2. Parties and roles

<!-- Guidance: Decide the role of each party for each processing activity, based on who actually decides purposes and essential means, not on what the parties would prefer. Common pitfall: labelling a vendor "independent controller" to avoid processor terms when it only follows instructions. -->

| Party | Legal name and registration | Address | Role under GDPR | Role under the Data Act (if relevant) | Representative in the EU or UK (if required) |
|---|---|---|---|---|---|
| Party A | [Name, number] | [Address] | [Controller / Joint controller] | [Data holder / User / Data recipient / Not applicable] | [Name] |
| Party B | [Name, number] | [Address] | [Controller / Joint controller] | [Data holder / User / Data recipient / Not applicable] | [Name] |

Use the decision flow below and record the reasoning.

```mermaid
flowchart TD
  A[Does the receiving party process the data only on the discloser's documented instructions?] -->|Yes| P[Processor: use a DPA, legal-lite/dpa]
  A -->|No| B[Do the parties decide purposes and means together?]
  B -->|Yes| J[Joint controllers: complete section 6]
  B -->|No| C[Independent controllers: this agreement, skip section 6]
  C --> D[Is the data product or related service data from a connected product, or shared under a Union law obligation?]
  J --> D
  D -->|Yes| E[Complete section 7 Data Act obligations]
  D -->|No| F[Mark section 7 not applicable]
```

| Processing activity | Party A role | Party B role | Reasoning |
|---|---|---|---|
| Disclosure of delivery data *(Example)* | Controller | Controller | Corvid decides to sell and ship; Larkspur decides how to run its delivery network and keeps its own proof-of-delivery records |
| Customer delivery tracking page *(Example)* | Joint controller | Joint controller | Both design the tracking page and decide which events customers see |
| [Activity] | [Role] | [Role] | [Reasoning] |

## 3. Purpose and permitted use

<!-- Guidance: Write the purpose narrowly enough that a third person could decide whether a given use is in or out. Common pitfall: "business purposes" or "improving our services", which permit almost anything. -->

The receiving party may use the shared data only for the purposes in
the table. Any other use needs a written amendment signed by both
parties, and, for personal data, a compatibility assessment under GDPR
Article 6(4) or a new lawful basis.

| Purpose ID | Permitted purpose | Prohibited uses | Compatibility notes |
|---|---|---|---|
| DSA-PUR-001 *(Example)* | Deliver the parcel and contact the recipient about delivery | Marketing, profiling, sale or licensing to others | Same purpose as collection |
| DSA-PUR-002 *(Example)* | Keep proof of delivery and handle claims | Building a consumer database | Compatible: needed to perform the carriage contract with Corvid and to defend claims |
| [DSA-PUR-003] | [Purpose] | [Prohibited uses] | [Notes] |

State any automated decision-making or profiling the receiving party
will carry out with the data, or state that there is none.

## 4. Data scope

<!-- Guidance: List data elements, not systems. Questions to answer: about whom, which fields, at what precision, how many records, how often? Common pitfall: sending the whole customer record because it is easier than filtering. -->

| Data ID | Data element | Data subjects | Personal data? | Special category or criminal data? | Classification | Minimisation applied |
|---|---|---|---|---|---|---|
| DSA-DAT-001 *(Example)* | Recipient name | Customers and gift recipients | Yes | No | Confidential (CR-05) | First name and surname only, no title |
| DSA-DAT-002 *(Example)* | Delivery address | Customers and gift recipients | Yes | No | Confidential (CR-05) | No billing address |
| DSA-DAT-003 *(Example)* | Phone number | Customers | Yes | No | Confidential (CR-05) | Sent only if the customer provided one for delivery |
| DSA-DAT-004 *(Example)* | Parcel weight, size, order reference | Customers and gift recipients, through the order reference | Indirectly (order reference) | No | Confidential (CR-05) | Order reference is a delivery-specific identifier, not the internal order ID |
| [DSA-DAT-005] | [Element] | [Subjects] | [Yes / No] | [Yes / No] | [Level (CR-NN)] | [Measure] |

Classification values quote the level and criterion ID of the
disclosing party's Data Classification Policy
(`data/data-classification-policy`). Any element that can be linked to
a person, such as the order reference, is personal data and is at
least Confidential under CR-05.

Describe the format and technical delivery in Schedule A: schema or
data contract reference (`data/data-contract`), file or API format,
frequency, volume, encryption in transit and the endpoint owner.

If data is shared after pseudonymisation or anonymisation, record the
assessment reference (`compliance/de-identification-assessment`).
Data that the recipient can re-identify is personal data in its hands.

## 5. Lawful basis and transparency

<!-- Guidance: Each controller needs its own lawful basis for its own processing. Questions to answer: what is the basis for disclosing, what is the basis for receiving and using, and how are people told? Common pitfall: assuming the discloser's basis covers the recipient. -->

| Party | Processing | Lawful basis (GDPR Art. 6) | Condition for special category data (Art. 9) if any | Evidence |
|---|---|---|---|---|
| Party A *(Example)* | Disclosure to carrier | Contract with the customer (Art. 6(1)(b)) | Not applicable | Terms of sale, clause [x] |
| Party B *(Example)* | Delivery and proof of delivery | Legitimate interests (Art. 6(1)(f)) in delivering parcels and keeping proof of delivery, for customers and other recipients; legal obligation (Art. 6(1)(c)) where national postal or tax law requires records. Contract (Art. 6(1)(b)) is not available, because the customer contracts with Corvid, not with Larkspur | Not applicable | Larkspur legitimate interests assessment LIA-[x] |
| [Party] | [Processing] | [Basis] | [Condition] | [Evidence] |

Transparency: state who tells data subjects what. The disclosing party
normally informs people at collection (GDPR Art. 13); the receiving
party must meet Article 14 for data it did not collect directly, unless
an exception applies.

| Notice item | Provided by | Where | Checked on |
|---|---|---|---|
| Identity of recipient or category of recipients | [Party] | [Privacy notice section] | YYYY-MM-DD |
| Purposes and basis of recipient processing | [Party] | [Location] | YYYY-MM-DD |
| How to exercise rights against each party | [Party] | [Location] | YYYY-MM-DD |

Record a DPIA where the screening requires one (`compliance/dpia`)
and update each party's records of processing (`compliance/gdpr-ropa`).

## 6. Joint-controller arrangement

<!-- Guidance: Complete only where section 2 identified joint control. GDPR Article 26 requires a transparent arrangement that sets out each party's responsibilities, in particular for data subject rights and information duties, and the essence of it must be available to data subjects. Common pitfall: an arrangement that splits duties on paper but leaves no single contact point for people. -->

| Obligation | Responsible party | Detail |
|---|---|---|
| Providing information to data subjects (Arts. 13 and 14) | [Party] | [Which notice, where] |
| Contact point for data subjects | [Party] | [Channel, response target] |
| Handling access, rectification, erasure, objection | [Party] | [Process in section 12] |
| Security of the shared system | [Party] | [Measures in section 9] |
| Breach notification to authority and individuals | [Party] | [Process in section 13] |
| DPIA, if required | [Party] | [Reference] |
| Records of processing | [Each party] | [Reference] |

Summary of the arrangement made available to data subjects: [link or
location of the published summary].

Data subjects may exercise their rights against each joint controller,
whatever the arrangement says (Art. 26(3)). Agree how the receiving
party passes on requests it receives about the other party's part.

*Example*: For the delivery tracking page, Corvid Commerce is the
contact point and answers rights requests within its standard process;
Larkspur supplies tracking events and forwards any request it receives
to Corvid within two working days.

## 7. EU Data Act obligations

<!-- Guidance: Complete when one party is a data holder making product data or related service data available to a user or a third party (data recipient), or when other Union law obliges a data holder to share. Mark "Not applicable" with a reason otherwise. Check the consolidated text and Commission guidance before relying on this section. Common pitfall: assuming the Data Act replaces GDPR; it does not (Art. 1(5)). -->

Applicability: [Applicable / Not applicable, reason]

### 7.1 Scope and timing

The Data Act applies from 12 September 2025 (Art. 50). The design
obligation in Art. 3(1) (data accessible by default) applies to
connected products and related services placed on the market after 12
September 2026. Chapter IV on unfair contractual terms applies to
contracts concluded after 12 September 2025, and from 12 September 2027
to earlier contracts of indefinite duration or due to expire at least
ten years from 11 January 2024. Record which rules apply to this
agreement.

| Question | Answer |
|---|---|
| Does the data come from a connected product or related service? | [Yes / No] |
| Is the data holder's obligation to share based on a user request under Art. 4 or Art. 5? | [Yes / No] |
| Is another Union or national law the source of the obligation (Chapter III)? | [Law, article] |
| Is the data holder a micro or small enterprise exempt under Art. 7? | [Yes / No] |
| Is the data recipient an SME or not-for-profit research organisation (Art. 9(4))? | [Yes / No] |
| Is the data recipient a designated gatekeeper (Art. 5(3), Art. 6(2)(d))? | [Must be No for Art. 5 sharing] |

### 7.2 Conditions for making data available (Art. 8)

Where the data holder is obliged to make data available to a data
recipient, agree terms that are fair, reasonable and non-discriminatory
and transparent. Record how the terms meet that standard.

| Condition | How this agreement meets it |
|---|---|
| Fair, reasonable and non-discriminatory terms (Art. 8(1)) | [Same terms as for comparable recipients, reference to standard offer] |
| No discrimination between comparable recipients, including group companies (Art. 8(3)) | [Evidence] |
| Data made available only at the user's request where Chapter II applies (Art. 8(4)) | [User request reference] |
| Information requested limited to what is needed to verify compliance (Art. 8(5)) | [Fields requested] |

### 7.3 Trade secrets (Art. 4(6) to (8), Art. 5(9) to (11))

| Item | Agreed position |
|---|---|
| Data or metadata identified as trade secrets | [List] |
| Confidentiality measures agreed before disclosure | [Technical and organisational measures, NDA (`legal-lite/nda`)] |
| Grounds and procedure for withholding or suspending sharing | [Summary, with notice to the competent authority where required] |

### 7.4 Third-party (data recipient) obligations (Art. 6)

When the receiving party obtains data at a user's request, it must use
the data only for the purposes agreed with the user. Record the agreed
restrictions in original wording, covering at least: no use that makes
the user's choices unduly difficult, no profiling unless necessary for
the requested service, no onward sharing except under a contract with
the user, no sharing with a designated gatekeeper, no use to develop a
competing connected product, and no use that harms the security of the
product.

### 7.5 Unfair terms check (Art. 13)

A term on data access and use, or on liability and remedies, that one
enterprise imposed unilaterally on another is not binding if it is
unfair. Before signing, review the liability, termination and data use
clauses and record the result.

| Clause | Unilaterally imposed? | Review result | Reviewer |
|---|---|---|---|
| [Clause reference] | [Yes / No, negotiated] | [Fair / Amended / Removed] | [@legal] |

### 7.6 Model contractual terms (Art. 41)

Article 41 asks the Commission to recommend non-binding model
contractual terms on data access and use, including reasonable
compensation and trade secret protection. The Commission published
four sets on 19 November 2025 (draft Recommendation approved under
C(2025) 7750): data holder to user, user to data recipient, data holder
to data recipient, and data sharer to data recipient for voluntary
sharing. Check the current adopted text and any Official Journal
reference before use.

| Item | Answer |
|---|---|
| Model terms set used, if any | [Name of set, version or date] |
| Deviations from the model terms | [List and reason] |

## 8. Transfers and onward sharing

<!-- Guidance: Record where the data goes after it leaves the disclosing party, including the recipient's own processors. Questions to answer: is any transfer outside the EEA or UK, under which mechanism, and who may receive the data next? Common pitfall: the recipient's cloud provider or support desk in a third country. -->

### 8.1 International transfers (GDPR Chapter V)

| Transfer | From | To (country) | Mechanism | Transfer impact assessment |
|---|---|---|---|---|
| [Transfer] | [Party, country] | [Recipient, country] | [Adequacy decision (Art. 45) / Standard contractual clauses (Art. 46(2)(c)) / Binding corporate rules (Art. 47) / Derogation (Art. 49)] | [Reference] |

Any transfer must meet the general principle in Article 44. Use the
Data Residency and Sovereignty Assessment
(`compliance/data-residency-sovereignty-assessment`) for the analysis.
For non-personal data, also consider Data Act Art. 32 on unlawful
international governmental access.

### 8.2 Onward sharing and processors

| Rule | Agreed position |
|---|---|
| Onward sharing to other controllers | [Prohibited / Allowed only with prior written consent of Party A] |
| Use of processors by the recipient | [Allowed under an Art. 28 contract; list in Schedule D] |
| Notice of new processors | [Days of notice] |
| Disclosure to public authorities | [Notify the other party unless legally prohibited; challenge overbroad requests] |

## 9. Security

<!-- Guidance: Each party secures its own processing (GDPR Art. 32), but the agreement must cover the exchange and the minimum level each side keeps. Common pitfall: a list of generic controls with no link to the classification of the data shared. -->

| Measure ID | Measure | Applies to | Evidence |
|---|---|---|---|
| DSA-SEC-001 *(Example)* | Mutual TLS on the delivery API, certificate rotation every 12 months | Exchange | Configuration and certificate inventory |
| DSA-SEC-002 *(Example)* | Encryption at rest of shared data in recipient systems | Party B | ISO/IEC 27001 certificate scope statement |
| DSA-SEC-003 *(Example)* | Access limited to delivery and claims roles, reviewed quarterly | Party B | Access review record |
| DSA-SEC-004 *(Example)* | Logging of API access with 12-month retention | Both | Log sample |
| [DSA-SEC-005] | [Measure] | [Party] | [Evidence] |

Set the minimum measures by the classification in the Data
Classification Policy (`data/data-classification-policy`). Keep the
detailed list in Schedule B so it can be updated without re-signature
where the master terms allow.

## 10. Data quality and accuracy

<!-- Guidance: State who is responsible for accuracy and how corrections flow between the parties. Common pitfall: a correction made by one party never reaching the other. -->

| Item | Agreed position |
|---|---|
| Accuracy at disclosure | [Party A shares data as held; no warranty beyond reasonable care] |
| Validation on receipt | [Party B rejects records failing the data contract checks] |
| Corrections | [Party A sends corrections within [x] hours of becoming aware] |
| Quality metrics reported | [Rejected record rate, late delivery of files] |

Reference the data contract and the quality expectations in it
(`data/data-contract`).

## 11. Retention, return and deletion

<!-- Guidance: Each controller sets its own retention for its own purposes, but the agreement should record it and set what happens at the end. Questions to answer: how long, when does the clock start, return or delete, and how is deletion proved? Common pitfall: "until no longer needed" with no number. -->

| Data ID | Retention by recipient | Clock starts | End-of-retention action | Proof |
|---|---|---|---|---|
| DSA-DAT-001 to 003 *(Example)* | 90 days | Delivery date | Delete; claims records keep only the order reference (DSA-DAT-004) | Monthly deletion report |
| DSA-DAT-004 *(Example)* | 24 months | Delivery date | Delete | Monthly deletion report |
| [Data ID] | [Period] | [Event] | [Return / Delete / Anonymise] | [Evidence] |

On termination, the receiving party [returns / deletes] the shared data
within [30] days, except where law requires it to keep data, and
confirms in writing. Backups are deleted on their normal rotation and
are not restored for any other purpose. These periods are the
recipient's own decisions as a controller. The disclosing party's
copies follow its Data Retention and Deletion Standard
(`data/data-retention-deletion-standard`): in the *Example*, Corvid's
order records stay under RET-002 and its customer account data under
RET-003; quote rule IDs and periods exactly as the standard states
them.

## 12. Data subject rights

<!-- Guidance: People must be able to exercise their rights with each controller. Agree how requests that concern the other party are passed on, and how erasure or objection reaches the copies. Common pitfall: an erasure request completed by one party while the other keeps sending or holding the data. -->

| Right | Handled by | Coordination with the other party | Target |
|---|---|---|---|
| Access (Art. 15) | Each party for its own processing | Forward misdirected requests within [2] working days | 1 month |
| Rectification (Art. 16) | Party receiving the request | Send corrections to the other party (section 10) | [Days] |
| Erasure (Art. 17) | Party receiving the request | Notify the other party where it holds a copy, unless impossible or disproportionate (Art. 19) | [Days] |
| Objection (Art. 21) | Party relying on legitimate interests | Stop sharing for that person where the objection succeeds | [Days] |
| Portability (Art. 20) | Party relying on consent or contract | Not applicable to shared copy unless agreed | 1 month |

For data covered by section 7, Data Act requests by users are separate
from GDPR rights and do not limit them (Data Act Art. 1(5), Art.
5(8)).

## 13. Breach and incident notification

<!-- Guidance: Each controller must assess and notify its own personal data breaches (GDPR Arts. 33 and 34), but the parties must tell each other fast enough to meet the 72-hour deadline. Common pitfall: a contract that gives the other party 72 hours, leaving no time for the controller's own assessment. -->

| Item | Agreed position |
|---|---|
| Notice to the other party | Without undue delay, and within [24] hours of becoming aware *(Example)* |
| Content of notice | Nature, data and people affected, likely consequences, measures taken, contact |
| Channel | [Security contact in Schedule C, phone and email] |
| Who notifies the supervisory authority | Each controller for its own processing; joint controllers per section 6 |
| Who informs individuals | [Party], with the wording agreed where possible |
| Cooperation | Share logs and findings needed for the other party's assessment |

Link the notice process to each party's incident response plan
(`compliance/incident-response-plan`). Where severity is used, use the
SEV1 to SEV4 scale from the incident severity matrix
(`ops/incident-severity-matrix`).

## 14. Audit, review and reporting

<!-- Guidance: Agree how each party can check the other keeps its promises, at a cost proportionate to the risk. Common pitfall: an unlimited on-site audit right nobody will use, and no lighter evidence route. -->

| Mechanism | Frequency | Content |
|---|---|---|
| Annual compliance statement | Yearly | Signed confirmation of purpose limitation, retention and security |
| Third-party certification or report | On request, yearly | ISO/IEC 27001 certificate, SOC 2 report or equivalent |
| Questionnaire | Yearly | Supplier Security Assessment (`compliance/supplier-security-assessment`) |
| Audit | On reasonable notice, at most [once] a year, or after a breach | Scope limited to this agreement |
| Agreement review | Yearly and on any change in law | Purpose, data scope, retention, contacts |

Under the Data Act, information requested to verify compliance must
not go beyond what is necessary (Art. 8(5)); keep audit requests
proportionate.

## 15. Fees and compensation

<!-- Guidance: Record whether money changes hands for the data and on what basis. Under the Data Act, compensation for business-to-business data making available must be non-discriminatory and reasonable (Art. 9). Common pitfall: charging an SME recipient a margin where the Data Act limits compensation to cost. -->

| Item | Agreed position |
|---|---|
| Fee for the data | [None / Amount, currency, period] |
| Basis of calculation | [Costs of formatting, dissemination and storage; investment in collection; margin where allowed] |
| SME or research recipient cap applied (Art. 9(4)) | [Yes, costs only / Not applicable] |
| Information on calculation given to recipient (Art. 9(7)) | [Reference] |
| Invoicing and payment terms | [Terms] |

*Example*: No fee for the data. Each party bears its own integration
costs, estimated at USD 12,000 for Corvid and USD 18,000 for Larkspur.

## 16. Liability, term, suspension and termination

<!-- Guidance: Set the duration and the exits. Questions to answer: when can sharing be paused, on what notice can either party leave, and what survives termination? Common pitfall: no right to suspend sharing quickly after a breach. -->

| Item | Agreed position |
|---|---|
| Start and duration | [Effective date], [initial term], [renewal rule] |
| Suspension | Either party may suspend sharing immediately after a suspected breach or material non-compliance, with notice |
| Termination for convenience | [Notice period] |
| Termination for cause | Material breach not remedied within [30] days |
| Liability | [Each party liable for its own processing; cap and exclusions per master agreement] |
| Indemnities | [If any] |
| Survival | Confidentiality, retention and deletion, audit for [12] months, liability |
| Change in law | Parties renegotiate in good faith; sharing suspended if it becomes unlawful |

Check liability and remedy clauses against the Data Act unfair terms
test in section 7.5 where it applies.

## 17. Dispute resolution

<!-- Guidance: Agree the escalation path before it is needed. Common pitfall: going straight to court on an operational disagreement. -->

1. Operational contacts try to resolve the issue within [10] working
   days.
2. Escalation to the executive sponsors named in Schedule C.
3. [Mediation / Arbitration / Courts of governing law].

For disputes within the Data Act's scope, users, data holders and data
recipients can use a dispute settlement body certified under Data Act
Art. 10, without losing the right to go to court. Record the body
chosen, if any: [Name].

## 18. Schedules and signatures

<!-- Guidance: Keep operational detail in schedules so the main terms stay stable. -->

**Schedule A: Data description and technical delivery**

| Field | Value |
|---|---|
| Data contract or schema | [Reference] |
| Format and protocol | [JSON over HTTPS API / CSV over SFTP] |
| Frequency and volume | [Daily, about 40,000 records] |
| Endpoint owner | [Party, team] |

**Schedule B: Security measures** (detail of section 9)

**Schedule C: Contacts**

| Role | Party A | Party B |
|---|---|---|
| Agreement owner | [Name, email] | [Name, email] |
| Data protection officer | [Name, email] | [Name, email] |
| Security incident contact | [24/7 phone, email] | [24/7 phone, email] |
| Executive sponsor | [Name] | [Name] |

**Schedule D: Recipient's processors**

| Processor | Service | Location | Contract |
|---|---|---|---|
| [Name] | [Service] | [Country] | [Art. 28 contract reference] |

**Signatures**

| Party | Name | Title | Signature | Date |
|---|---|---|---|---|
| [Party A] | [Name] | [Title] | [Signature] | YYYY-MM-DD |
| [Party B] | [Name] | [Title] | [Signature] | YYYY-MM-DD |

## 19. Glossary and references

<!-- Guidance: Use the legal definitions where they exist and say which law they come from. -->

### 19.1 Glossary

| Term | Meaning in this agreement |
|---|---|
| Controller | Party that decides purposes and means of processing personal data (GDPR) |
| Joint controllers | Two or more controllers that decide purposes and means together (GDPR Art. 26) |
| Processor | Party processing personal data on behalf of a controller (GDPR Art. 28), covered by a DPA |
| Data holder | Under the Data Act, a party with the right or obligation to use and make available product or related service data |
| Data recipient | Under the Data Act, a party, other than the user, to whom the data holder makes data available |
| User | Under the Data Act (Art. 2(12)), a natural or legal person that owns a connected product, to whom temporary rights to use it have been contractually transferred, or that receives a related service |
| FRAND | Fair, reasonable and non-discriminatory terms |
| Onward sharing | Disclosure by the recipient to any other party |

### 19.2 References

| Reference | Version or date | Use |
|---|---|---|
| Regulation (EU) 2016/679 (GDPR), OJ L 119, 4.5.2016 | Check the consolidated text | Articles 5, 6, 9, 13, 14, 15 to 21, 26, 28, 32 to 35, 44 to 49 |
| Regulation (EU) 2023/2854 (Data Act), OJ L, 2023/2854, 22.12.2023 | Applicable from 12 September 2025; check the consolidated text | Articles 1, 3 to 10, 13, 32, 41, 50 |
| Commission draft Recommendation on non-binding model contractual terms on data access and use and standard contractual clauses for cloud computing contracts | Published 19 November 2025, C(2025) 7750; check final adoption | Section 7.6 |
| ICO, Data sharing: a code of practice | Statutory code, in force 5 October 2021; under review after the Data (Use and Access) Act 2025 | UK topics and checklist |
| UK GDPR and Data Protection Act 2018 | Check the current text as amended | UK sharing |

## Standard and licence note

Based on Regulation (EU) 2016/679 (GDPR) and Regulation (EU) 2023/2854
(Data Act) as published in the Official Journal of the European Union,
with reference to the European Commission's draft Recommendation on
model contractual terms under Data Act Article 41 (approved 19 November
2025, C(2025) 7750) and the UK
Information Commissioner's Office "Data sharing: a code of practice".
EU legislative texts are free to reuse; articles are cited and
obligations summarised in original wording, and no legal text, model
term or ICO text is reproduced. The template text is original. Check
the consolidated texts on EUR-Lex, the current Commission model terms,
the ICO's current guidance (under review after the Data (Use and
Access) Act 2025) and national law before use. This is a documentation
format, not legal advice. Template licence: MIT.