When two organisations share personal or confidential data as independent or joint controllers, neither is the other's processor, so the usual supplier security clauses do not fit and the security terms often end up as a single line saying both parties will "keep the data secure". This template is a mutual security schedule to attach to a data sharing agreement, memorandum of understanding or information exchange agreement. Every obligation applies to both parties: classification, security baseline, identities and credentials used for the exchange, transfer, onward sharing, retention and deletion, incident notice, rights requests, assurance and termination. It is written for security, privacy and legal teams setting up controller-to-controller sharing, research and public sector partnerships, and data exchanges between group companies. Where one party processes data on the other's behalf, use the Third-Party Security Contract Clauses Template instead.
How to use this template
- Replace text in square brackets, such as [Party A], [Party B], [Shared Data] and [24 hours], with your own terms. Timings shown are illustrative starting points, not legal minimums.
- "Each Party must" marks a mutual obligation. Where only the recipient of a flow is bound, the clause says "the Receiving Party". In two-way sharing, each Party is a Receiving Party for the data it receives.
- Complete the Annex A table in section 2 first: the classification of each data set drives which optional clauses apply.
- The ICO describes a data sharing agreement as good practice rather than mandatory, and expects it to cover common technical and organisational security arrangements, common retention and deletion rules, procedures for breaches of the agreement, and regular review. Joint controllers under UK and EU GDPR Article 26 must also set out their respective responsibilities in an arrangement. This schedule covers the security elements, not lawful basis or transparency.
- Note that the ICO data sharing code shows a banner saying the guidance is under review and may be subject to change; check the current version before finalising.
1. Parties, roles and purpose
1.1 This Schedule applies to [Shared Data] exchanged between [Party A] and [Party B] for the purpose of [purpose] under the [Data Sharing Agreement dated ...].
1.2 Each Party acts as [an independent controller / a joint controller] for the Shared Data it holds. Neither Party processes the Shared Data on the other's behalf under this Schedule.
1.3 Each Party must name a security contact and a data protection contact in Annex B and keep them current. Changes must be notified within [5 working days].
1.4 Each Party must use Shared Data received under this Schedule only for the stated purpose.
2. Data in scope and classification
2.1 The Parties must record each data set in Annex A before the first transfer:
| Annex A field | Example entry | Why it matters |
|---|---|---|
| Data set and fields | [Customer ID, postcode, risk score] | Limits the exchange to named fields |
| Direction | [A to B / B to A / both] | Decides who is the Receiving Party |
| Classification | [Confidential / Restricted] | Selects baseline and optional clauses |
| Special category or criminal offence data | [Yes / No] | Triggers the Restricted controls |
| Transfer method and frequency | [SFTP, daily / API, real time] | Fixes the transfer controls in section 5 |
| Retention at Receiving Party | [X months] | Drives deletion in section 7 |
2.2 Each Party must handle Shared Data at no lower protection than the classification agreed in Annex A, mapped to its own classification scheme. See the Data Classification Guide.
2.3 Each Party must minimise the fields shared. Where pseudonymised or aggregated data meets the purpose, the Disclosing Party must share that instead of identifiable data.
3. Security baseline
3.1 Each Party must maintain technical and organisational measures appropriate to the risk, taking account of the measures listed in GDPR Article 32(1): pseudonymisation and encryption; ongoing confidentiality, integrity, availability and resilience; timely restoration after an incident; and regular testing of the measures.
3.2 As a minimum, for systems that store or process Shared Data, each Party must:
- encrypt Shared Data at rest using [AES-256 or equivalent], with keys managed under its key management policy;
- keep Shared Data in [named environment or region] and not move it outside [jurisdictions] without prior written agreement;
- apply security updates rated critical within [14 days] and maintain endpoint protection;
- log access to Shared Data and retain the logs for at least [12 months];
- keep Shared Data separate from unrelated data sets, or tagged so it can be found, reported and deleted;
- maintain [ISO/IEC 27001 certification / Cyber Essentials Plus / SOC 2 Type II / an equivalent stated in Annex B] for the relevant scope, or a self-assessment against Annex C.
3.3 For data marked Restricted in Annex A, each Party must also [hold the data in a dedicated environment / prohibit download to endpoints / require privileged access workstations for administration].
4. Access, identities and credentials
4.1 Each Party must limit access to Shared Data to named individuals and service identities with a need for the stated purpose, and review that list at least every [90 days].
4.2 Each Party must require multi-factor authentication for all human access to systems holding Shared Data, and phishing-resistant authentication for administrators.
4.3 Credentials used for the exchange itself (SFTP keys, API keys, OAuth clients, certificates, service accounts) must be:
- unique to this exchange and to each direction, never shared with other partners or reused from other integrations;
- stored in a secrets manager, never in email, tickets or source code;
- scoped to the minimum endpoints and data sets in Annex A;
- rotated at least every [90 days] and immediately on suspicion of compromise or staff change in the integration team;
- revoked by the issuing Party within [24 hours] of termination of this Schedule.
4.4 Each Party must keep a register of the credentials it has issued to, and holds from, the other Party, with owner and expiry date, and share the relevant entries on request. See the API Key Management Guide.
4.5 Staff with access must have completed data protection training, and must be bound by confidentiality, before access is granted.
5. Transfer
5.1 Shared Data must be transferred only by the method in Annex A, encrypted in transit with [TLS 1.2 or later / SFTP with key authentication], with mutual authentication of both endpoints where the method supports it.
5.2 The Parties must not transfer Shared Data by email attachment, removable media or consumer file-sharing services unless agreed in writing for a specific transfer, encrypted and logged.
5.3 The Receiving Party must validate each transfer for completeness and confirm receipt within [1 working day]. Misdirected or excess data must be reported to the Disclosing Party and deleted.
5.4 Where an API is used, the providing Party must rate-limit, log and monitor calls, and alert the other Party to anomalous volumes.
6. Use, onward sharing and combination
6.1 The Receiving Party must not disclose Shared Data to any third party, including affiliates, except to its own processors bound by terms no less protective than this Schedule, or where required by law.
6.2 The Receiving Party must notify the Disclosing Party in advance of any new processor that will hold Restricted data, with [30 days] to object.
6.3 The Receiving Party must not combine Shared Data with other data to re-identify individuals in a pseudonymised or aggregated data set, and must not use Shared Data to train machine learning models outside the stated purpose without prior written agreement.
6.4 Where disclosure is required by law, the Receiving Party must, where lawful, inform the Disclosing Party before disclosure.
7. Retention, return and deletion
7.1 The Receiving Party must retain Shared Data no longer than the period in Annex A and then securely delete it, including copies in working areas and exports.
7.2 Backups containing Shared Data must expire within [X days] of deletion from live systems and must not be restored for use after that.
7.3 Within [30 days] of termination, each Party must delete or return Shared Data received, as the Disclosing Party elects, and provide a written certificate of deletion signed by [a named officer].
7.4 Deletion must use methods suitable for the media, consistent with NIST SP 800-88 or an equivalent standard named in Annex B.
8. Security incidents and breaches
8.1 Each Party must notify the other's security contact within [24 hours] of becoming aware of a security incident affecting Shared Data or the exchange credentials, including suspected credential compromise, whether or not personal data is confirmed as affected.
8.2 The notice must include, as far as known: nature of the incident, data sets and approximate number of records and individuals, credentials involved, containment taken, and a contact. Updates follow every [24 hours] until closure.
8.3 Each Party remains responsible for its own regulatory notifications as a controller. UK and EU GDPR Article 33(1) requires a controller to notify the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a reportable personal data breach. Where both Parties hold the affected data, they must agree who notifies, and coordinate messages to individuals and regulators, within [48 hours].
8.4 On notice of a suspected compromise of exchange credentials, the issuing Party must revoke and reissue them, and both Parties must review logs for the exposure window.
8.5 Each Party must cooperate with the other's investigation and preserve relevant logs for [90 days] from notice.
9. Individual rights requests
9.1 Each Party handles rights requests about Shared Data it holds. Where a request concerns data that originated with the other Party, it must inform that Party within [5 working days] where the request affects it, such as erasure or rectification that should propagate.
9.2 Joint controllers must state in Annex B which Party is the contact point for individuals. Under Article 26(3), individuals may still exercise their rights against each controller.
10. Assurance and audit
10.1 Each Party must, on reasonable request and no more than [once a year], provide evidence of compliance with this Schedule: current certificates, a completed Annex C self-assessment, and the credential register entries in section 4.4.
10.2 For Restricted data, either Party may conduct or commission an audit of the other's controls relevant to the Shared Data on [30 days] notice, at its own cost, subject to confidentiality.
10.3 Each Party must notify the other of any material change to its security controls, hosting location or certification scope affecting Shared Data within [30 days].
11. Review, suspension and termination
11.1 The Parties must review this Schedule and Annex A at least every [12 months] and after any security incident, significant complaint or change to the data sets or purpose.
11.2 Either Party may suspend transfers immediately on reasonable belief that the other Party is in material breach of this Schedule or that Shared Data is at risk, with written notice giving reasons.
11.3 On termination, sections 6, 7 and 8 continue to apply to any Shared Data still held until deletion is certified.
Implementation guidance
Processor clauses or a mutual schedule?
| Question | Use this mutual schedule | Use supplier security clauses |
|---|---|---|
| Who decides purposes and means? | Each party for its own use, or both jointly | The customer alone |
| Who acts on instructions? | Neither party | The supplier, as processor |
| Who notifies the regulator? | Each controller, coordinated | The customer, after the processor tells it (Art. 33(2)) |
| Typical examples | Fraud data exchanges, research partnerships, public sector sharing, group company sharing | SaaS, hosting, outsourced services |
For fraud intelligence exchanges specifically, see the Fraud Data Sharing and Consortium Intelligence Guide; for platform-native shares without copying data, see Zero Copy Data Sharing.
Framework mapping
| Section | NIST CSF 2.0 | NIST SP 800-53 Rev 5 | Law or guidance |
|---|---|---|---|
| 1, 2. Roles and scope | GV.SC-05 | CA-3, AC-21 | UK and EU GDPR Art. 26; NIST SP 800-47 Rev. 1 |
| 3, 4. Baseline and access | PR.DS-01 | CA-3 | GDPR Art. 32(1), 32(4) |
| 5. Transfer | PR.DS-02 | SC-8 | ICO data sharing code |
| 7. Retention and deletion | GV.SC-10 | MP-6 | ICO data sharing code |
| 8. Incidents | GV.SC-05 | IR-6 | GDPR Art. 33 |
NIST SP 800-47 Rev. 1, Managing the Security of Information Exchanges, names interconnection security agreements, memoranda of understanding or agreement and information exchange agreements as ways to document protection before, during and after an exchange; this schedule can serve as the security part of any of them.
Rolling it out
- Inventory existing sharing: list every outbound and inbound data feed with a partner that is not a processor, with its credentials and owner.
- Classify and minimise: complete Annex A for each, removing fields the purpose does not need before signing.
- Agree the schedule: security drafts sections 3 to 5 and 8, privacy drafts 6, 7 and 9, legal owns liability. Pre-agree fallbacks, such as accepting the other party's certification instead of audit rights for Confidential data.
- Cut over credentials: issue new per-exchange credentials, register them, and revoke shared or legacy ones.
- Test incident notice: run a joint tabletop on a credential leak at one party and confirm contacts and timings work. The Third-Party Incident Response Playbook gives a starting scenario.
Measures
- Share of active data sharing arrangements with a signed schedule and current Annex A.
- Exchange credentials older than the agreed rotation period, per partner.
- Deletion certificates received within the agreed period after termination.
- Median time from partner incident to notice received.
- Reviews completed on schedule.
Common gaps: one shared SFTP key used by every partner; no deletion certificate when a partnership ends; incident notice limited to confirmed personal data breaches, which misses credential theft; onward sharing to affiliates never discussed.
Related NHI Mgmt Group resources: Third-Party Security Contract Clauses Template · Data Classification Policy Template · GDPR Compliance Guide for Security Teams · Data Minimisation. This template summarises security terms under the UK and EU GDPR and related guidance and is not legal advice.