Supplier Contract Security Clause Library
Supplies ready security clauses by supplier tier and data type so requirements reach the contract rather than staying in the assessment.
Available soon
- Format
- Word
- Size
- 70 KB
- Length
- 26 pages
- Version
- 1.0
- Updated
What's inside
- Purpose
- How to use this library
- Classification fields
- Clause selection matrix
- Coverage: regulatory contract content
- The clauses
- Worked examples
- Negotiating with suppliers
- Related documents
- Adapting this template
- Framework references
- Definitions
Preview
The document from section 1, as you will receive it. Highlighted [[text]] is for you to replace; shaded guidance boxes are for you to delete before approval. The cover and document control pages are in the file.
Purpose
This library gives [[Organisation Name]] ready security clauses for supplier contracts, so the requirements found in an assessment reach the contract instead of staying in a report. Each clause has a stable ID (CL-01 to CL-21), says when to use it, what it achieves and how suppliers usually push back, and is written in plain contract English with the values you set in [[double brackets]].
It applies the Third-Party Security Policy's rule TP-07: Contracts must carry the security clauses for the supplier's tier and data type before they are signed. The tier comes from the Supplier Criticality & Tiering Model; the selection matrix below turns the tier and the data type into a list of clauses.
Guidance — delete before approval
This library is not legal advice. The clauses are a starting point written for security coverage. Your legal adviser must review them against the governing law of the contract, your standard terms and the rest of the agreement — definitions, liability, and how schedules are referred to — before they are used.
Numbering: clause CL-nn is written as clause nn, with paragraphs nn.1, nn.2. Cross-references between clauses use that numbering. Renumber them when you assemble a contract.
How to use this library
- Find the supplier's tier in the Supplier Security Risk Register. If it has none, it has not been screened: stop and screen it (TP-01).
- Read the tier column of the selection matrix: every clause marked Yes (or Short) goes in.
- Add the data-type clauses: read the column for the most sensitive data the supplier will hold or see, and add every clause marked Yes there.
- Check the conditions: for every clause marked 'If …' in either column, read its 'When to use' and include it if the condition applies.
- Add the regulatory clauses if you are a DORA financial entity: every clause in the 'DORA: all ICT services' column for an ICT service, and the 'DORA: critical or important' column when the service supports a critical or important function.
- Add the conditions from the assessment. Where the decision was 'Approve with conditions', list the findings and their deadlines in the schedule to CL-19.
- Negotiate, then record the result. Any clause the supplier refuses, and which you accept without it, is a gap: record it as an exception under the Security Exception & Waiver Standard, or as a risk in the Information Security Risk Register if it leaves the supplier outside appetite.
Guidance — delete before approval
Where the supplier's own terms are offered instead, as large cloud and software providers usually insist, do not try to rewrite them. Read them against this library clause by clause, note which points they cover and which they do not, and treat the gaps as step 7 says.
Classification fields
Field | Meaning |
|---|---|
ID | CL-nn. Stable: a clause keeps its ID when its wording changes. Retired IDs are not reused. |
Topic | Security, Assurance, Supply chain, Data protection, Incidents, Access, Resilience, Exit, People, Regulatory, Cloud. |
When to use | The tiers, data types and conditions that call for the clause. |
By tier | The selection code for each tier (T1 to T4). |
What it achieves | The outcome the clause secures: the reason to hold firm in negotiation. |
Rule it serves | The Third-Party Security Policy rule (TP-nn) the clause puts into the contract. |
Framework | The framework points the clause helps meet. The coverage tables give the detail. |
Negotiation notes | The usual pushback, an acceptable fallback, and what not to give up. |
Selection codes:
Code | Meaning |
|---|---|
Yes | Include the clause. |
If … | Include it when the condition applies (see the clause's 'When to use'). |
Short | Include the short form only (the first paragraph). |
— | Not needed for this column. |
Clause selection matrix
By tier, and for DORA financial entities
Tier 1 Critical takes every core clause, and the DORA clauses if they apply; Tier 4 Minimal takes the short security clause only.
Clause | Tier 1 | Tier 2 | Tier 3 | Tier 4 | DORA: all ICT services | DORA: critical or important |
|---|---|---|---|---|---|---|
CL-01 Security requirements and standards | Yes | Yes | Yes | Short | Yes | Yes |
CL-02 Certification and independent assurance | Yes | Yes | — | — | — | — |
CL-03 Right to audit and access | Yes | Yes | If … | — | — | Yes |
CL-04 Sub-processors and subcontracting | Yes | Yes | If … | — | — | — |
CL-05 Locations of service and data | Yes | Yes | If … | — | Yes | Yes |
CL-06 Data protection: processor terms | If … | If … | If … | — | Yes | Yes |
CL-07 Security incident notification | Yes | Yes | Yes | — | Yes | Yes |
CL-08 Vulnerability management | Yes | Yes | If … | — | — | Yes |
CL-09 Access control and multi-factor authentication for supplier staff | Yes | Yes | If … | — | — | Yes |
CL-10 Business continuity and disaster recovery | Yes | If … | — | — | — | Yes |
CL-11 Cooperation in our incident response | Yes | Yes | — | — | Yes | Yes |
CL-12 Penetration testing and security testing | Yes | If … | — | — | — | Yes |
CL-13 Data return and deletion | Yes | Yes | If … | — | Yes | Yes |
CL-14 Exit and transition assistance | Yes | Yes | — | — | — | Yes |
CL-15 Termination rights for security reasons | Yes | Yes | Yes | — | Yes | Yes |
CL-16 Security awareness and training of supplier staff | Yes | Yes | — | — | Yes | Yes |
CL-17 Cooperation with competent authorities | If … | If … | If … | — | Yes | Yes |
CL-18 Service levels and security reporting | Yes | If … | — | — | Yes | Yes |
CL-19 Remediation of assessment findings | Yes | Yes | If … | — | — | — |
CL-20 Notice of material changes | Yes | Yes | — | — | — | Yes |
CL-21 Cloud services | If … | If … | If … | — | — | — |
- Tier 1 Critical: CL-01, CL-02, CL-03, CL-04, CL-05, CL-07, CL-08, CL-09, CL-10, CL-11, CL-12, CL-13, CL-14, CL-15, CL-16, CL-18, CL-19, CL-20; if they apply, CL-06, CL-17, CL-21.
- Tier 2 Important: CL-01, CL-02, CL-03, CL-04, CL-05, CL-07, CL-08, CL-09, CL-11, CL-13, CL-14, CL-15, CL-16, CL-19, CL-20; if they apply, CL-06, CL-10, CL-12, CL-17, CL-18, CL-21.
- Tier 3 Standard: CL-01, CL-07, CL-15; if they apply, CL-03, CL-04, CL-05, CL-06, CL-08, CL-09, CL-13, CL-17, CL-19, CL-21.
- Tier 4 Minimal: CL-01, first paragraph only. Tier 4 suppliers hold no data and have no access, so the main contract's ordinary terms do the rest.
- The DORA columns come from the coverage tables below. Override 1 of the tiering model makes an ICT service supporting a critical or important function Tier 1, so it also takes every Tier 1 clause.
By data type
Read the column for the most sensitive data the supplier holds or can reach (criterion TC-2 of the Supplier Criticality & Tiering Model). A processor of personal data is at least Tier 2 (override 2), so also read that tier's column.
Clause | No data, or public data only | Internal non-personal data | Personal data processed for us | Customer data, or sensitive or personal data at scale |
|---|---|---|---|---|
CL-01 Security requirements and standards | Short | Yes | Yes | Yes |
CL-02 Certification and independent assurance | — | If … | Yes | Yes |
CL-03 Right to audit and access | — | — | Yes | Yes |
CL-04 Sub-processors and subcontracting | — | If … | Yes | Yes |
CL-05 Locations of service and data | — | If … | Yes | Yes |
CL-06 Data protection: processor terms | — | — | Yes | Yes |
CL-07 Security incident notification | — | Yes | Yes | Yes |
CL-08 Vulnerability management | — | If … | Yes | Yes |
CL-09 Access control and multi-factor authentication for supplier staff | — | If … | If … | If … |
CL-10 Business continuity and disaster recovery | — | — | — | — |
CL-11 Cooperation in our incident response | — | — | Yes | Yes |
CL-12 Penetration testing and security testing | — | — | — | If … |
CL-13 Data return and deletion | — | Yes | Yes | Yes |
CL-14 Exit and transition assistance | — | — | — | — |
CL-15 Termination rights for security reasons | — | Yes | Yes | Yes |
CL-16 Security awareness and training of supplier staff | — | — | If … | Yes |
CL-17 Cooperation with competent authorities | — | — | — | — |
CL-18 Service levels and security reporting | — | — | — | — |
CL-19 Remediation of assessment findings | — | — | — | — |
CL-20 Notice of material changes | — | — | Yes | Yes |
CL-21 Cloud services | — | If … | If … | If … |
Coverage: regulatory contract content
DORA Article 30(2): all contracts for ICT services
For a financial entity under DORA, every contract for ICT services must contain the key provisions in Article 30(2). The table lists the points named in this pack's summary of that paragraph, and the clauses that address each.
Point in Article 30(2) | Clauses | Note |
|---|---|---|
Services | — | The description of the services is in the main contract, not in this library. |
Locations | CL-05 | Locations of service and data |
Data protection | CL-01, CL-06 | Security requirements and standards |
Data return | CL-13 | Data return and deletion |
Service levels | CL-18 | Service levels and security reporting |
Incident assistance | CL-07, CL-11 | Security incident notification |
Cooperation with authorities | CL-17 | Cooperation with competent authorities |
Termination rights | CL-15 | Termination rights for security reasons |
Training | CL-16 | Security awareness and training of supplier staff |
DORA Article 30(3): critical or important functions
Contracts for ICT services supporting critical or important functions must also contain the additional provisions in Article 30(3). The points named in this pack's summary:
Point in Article 30(3) | Clauses | Note |
|---|---|---|
Full service levels | CL-18 | Service levels and security reporting |
Notice duties | CL-20, CL-07 | Notice of material changes; Security incident notification |
Contingency plans and security | CL-10, CL-01, CL-08, CL-09 | Business continuity and disaster recovery; Security requirements and standards; Vulnerability management; Access control and multi-factor authentication for supplier staff |
Testing participation | CL-12, CL-10 | Penetration testing and security testing; Business continuity and disaster recovery |
Audit and access rights | CL-03 | Right to audit and access |
Exit strategies | CL-14, CL-13 | Exit and transition assistance; Data return and deletion |
Guidance — delete before approval
Your lawyer checks the full Article. These tables follow a summary of Article 30(2) and 30(3), not the text. The Article sets out each provision in more detail — for example what a service description, a notice period or an exit strategy must contain — and it may require points the summary does not name. Before relying on this library for DORA, have your legal adviser check each contract against the full text of Article 30 and any technical standards made under it.
Record DORA-scope contracts in the register of information (Article 28(3)); the Supplier Security Risk Register can hold the flag.
GDPR Article 28: processor contracts
Where the supplier processes personal data on our behalf, GDPR Article 28(3) requires a binding contract covering the points below, and Article 28(2) forbids sub-processors without our prior written authorisation (CL-04, paragraph 4.1).
Point in Article 28(3) | Clause | Paragraphs |
|---|---|---|
Documented instructions | CL-06 | 6.1 |
Confidentiality | CL-06 | 6.2 |
Security | CL-06, CL-01 | 6.3; 1 |
Sub-processors | CL-04 | 4.1 to 4.3 |
Assistance | CL-06 | 6.3, 6.4 |
Return or deletion of data | CL-13 | 13.1 to 13.3 |
Audits | CL-03, CL-06 | 3; 6.5 |
The Data Protection Officer checks the processor terms, and the description of the processing in CL-06's schedule, before signature. Where the supplier offers its own data processing agreement, check it against this table.
The clauses
Each entry gives the classification fields, the clause text ready to paste, and negotiation notes. Where a paragraph refers to "Schedule [[X]]", create that schedule in the contract. "Security Incident" is defined in CL-07; use the contract's own defined terms for "the Supplier", "the Customer", "the Services" and "this Agreement". The notification window in CL-07 is [[24]] hours by default.
CL-01 Security requirements and standards
Field | Entry |
|---|---|
When to use | Every supplier contract. Tier 4 and suppliers with no data take the first paragraph only. |
By tier | T1 Yes · T2 Yes · T3 Yes · T4 Short |
What it achieves | Makes security a contractual duty with a standard behind it, so a gap found later is a breach the supplier must fix, not a request it may decline. |
Rule it serves | TP-07 |
Framework | ISO/IEC 27001 A.5.20; DORA 30(2): data protection; DORA 30(3): contingency plans and security; GDPR 28(3): security |
Clause text — 1. Security requirements and standards
1.1 The Supplier shall maintain appropriate technical and organisational measures to protect the confidentiality, integrity and availability of the Customer's information and of the Services, taking into account the state of the art, the cost of implementation and the risk to the Customer.
1.2 Without limiting clause 1.1, the Supplier shall operate an information security management system that meets [[ISO/IEC 27001:2022 / the Customer's Supplier Security Requirements in Schedule X]], and shall comply with the Customer's security policies listed in Schedule [[X]] when working on the Customer's premises or systems.
1.3 The Supplier shall encrypt the Customer's data in transit over public networks and at rest, using [[industry-standard algorithms and key lengths]], and shall keep the Customer's data logically separated from the data of its other customers.
1.4 The Supplier shall not reduce the overall level of security of the Services during the term.
Negotiation notes
- Pushback: 'We follow our own standards, not yours.' Fallback: accept their certified standard in place of your schedule, if the certificate's scope covers the service you buy.
- Hold firm: clause 1.4 (no reduction in security during the term). Without it, the assessment that approved the supplier stops describing it.
CL-02 Certification and independent assurance
Field | Entry |
|---|---|
When to use | Tier 1 and Tier 2, and any supplier holding personal or customer data. |
By tier | T1 Yes · T2 Yes · T3 — · T4 — |
What it achieves | Keeps the evidence behind the tiering decision current, so reassessment (TP-09) starts from a valid certificate or report, not a promise. |
Rule it serves | TP-04, TP-09 |
Framework | ISO/IEC 27001 A.5.20 |
Clause text — 2. Certification and independent assurance
2.1 The Supplier shall hold, for the whole term, [[an ISO/IEC 27001 certification / an independent assurance report]] whose scope covers the Services, issued by [[an accredited certification body / an independent auditor]].
2.2 The Supplier shall provide the current certificate or report, and its scope or statement of applicability, on signature and within [[30]] calendar days of each renewal or reissue, and shall tell the Customer within [[10]] working days if the certificate is suspended, withdrawn or reduced in scope, or the report is qualified.
2.3 Where the certificate or report does not cover a part of the Services, the Supplier shall give the Customer equivalent evidence for that part on request.
Negotiation notes
- Pushback: 'Our report is confidential.' Fallback: sign the supplier's non-disclosure agreement for the report; do not accept a marketing summary in its place.
- Check: the scope. A certificate for the supplier's head office says nothing about the data centre that runs your service (TP-04).
CL-03 Right to audit and access
Field | Entry |
|---|---|
When to use | Tier 1 and Tier 2; any processor of personal data (GDPR audits); Tier 3 where a finding needs to be checked on site. |
By tier | T1 Yes · T2 Yes · T3 If … · T4 — |
What it achieves | Lets the Customer, its auditors and, where they apply, its regulators check that the controls exist, rather than relying on the supplier's word. |
Rule it serves | TP-04 |
Framework | ISO/IEC 27001 A.5.20; DORA 30(3): audit and access rights; GDPR 28(3): audits |
Clause text — 3. Right to audit and access
3.1 The Supplier shall allow the Customer, its auditors and any competent authority with jurisdiction over the Customer to audit and inspect the Supplier's compliance with this Agreement, including its premises, systems, records and personnel involved in the Services, on [[30]] calendar days' notice, or on [[2]] working days' notice after a Security Incident or where a competent authority requires it.
3.2 The Customer shall not carry out more than [[one]] audit in any 12 months except after a Security Incident, on a regulator's request, or where a previous audit found a material failure.
3.3 The Customer may first ask for the Supplier's current certification or independent report (clause 2), and shall rely on it where it covers the matter to be audited.
3.4 Each party bears its own costs, unless the audit finds a material breach, when the Supplier bears the reasonable costs of the audit.
Negotiation notes
- Pushback: 'No on-site audits; we serve thousands of customers.' Fallback: a document-based audit, with the right to go on site only after an incident or a material finding. Pooled audits with other customers are a reasonable compromise.
- Hold firm (regulated entities): access and audit rights for the competent authority. For DORA critical or important functions this is not negotiable away.
CL-04 Sub-processors and subcontracting
Field | Entry |
|---|---|
When to use | Tier 1 and Tier 2; any supplier that processes personal data for us; Tier 3 where the supplier subcontracts the work it does on our data. |
By tier | T1 Yes · T2 Yes · T3 If … · T4 — |
What it achieves | Stops our data or service moving to a party we have not assessed, and meets GDPR's rule that a processor engages no sub-processor without the controller's prior written authorisation. |
Rule it serves | TP-07 |
Framework | ISO/IEC 27001 A.5.20; GDPR 28(2); GDPR 28(3): sub-processors |
Clause text — 4. Sub-processors and subcontracting
4.1 The Supplier shall not subcontract any part of the Services, or engage any sub-processor to process the Customer's personal data, without the Customer's prior written authorisation. The sub-processors authorised on signature are listed in Schedule [[X]].
4.2 The Supplier shall give the Customer at least [[30]] calendar days' written notice of any intended addition or replacement of a subcontractor or sub-processor, with its name, location and the services it will provide. The Customer may object on reasonable security or data protection grounds within that period; if the parties cannot agree, the Customer may terminate the affected Services without penalty.
4.3 The Supplier shall impose on each subcontractor and sub-processor security and data protection obligations no less protective than those in this Agreement, and remains fully liable to the Customer for their performance.
Negotiation notes
- Pushback: 'We give general authorisation and publish changes on our website.' Fallback: general written authorisation is allowed, but only with advance notice to you and a right to object; watching a web page is not notice.
- Hold firm: 4.3, flow-down and full liability. Without it, a breach at a sub-processor is nobody's contractual problem.
CL-05 Locations of service and data
Field | Entry |
|---|---|
When to use | Tier 1 and Tier 2; any supplier holding personal or customer data; Tier 3 where data leaves [[the EEA / the UK]]. |
By tier | T1 Yes · T2 Yes · T3 If … · T4 — |
What it achieves | Fixes where our data is stored and processed and where the service runs from, so a transfer or a new site cannot happen without us knowing. |
Rule it serves | TP-07 |
Framework | ISO/IEC 27001 A.5.20; DORA 30(2): locations |
Clause text — 5. Locations of service and data
5.1 The Supplier shall provide the Services, and store and process the Customer's data, only in the locations listed in Schedule [[X]] ([[countries or regions, and data centres where relevant]]).
5.2 The Supplier shall give the Customer at least [[60]] calendar days' written notice before changing any of those locations, and shall not transfer the Customer's personal data outside [[the EEA / the UK]] except under a transfer mechanism permitted by data protection law and approved in writing by the Customer.
Negotiation notes
- Pushback: 'Our support staff work from anywhere.' Fallback: list the countries remote support is given from, separately from where data is stored.
CL-06 Data protection: processor terms
Field | Entry |
|---|---|
When to use | Every supplier that processes personal data on our behalf, whatever its tier. A processor is always at least Tier 2 (override 2 of the tiering model). |
By tier | T1 If … · T2 If … · T3 If … · T4 — |
What it achieves | Gives the binding processor contract GDPR Article 28(3) requires: documented instructions, confidentiality, security, sub-processors, assistance, return or deletion, and audits. |
Rule it serves | TP-07 |
Framework | ISO/IEC 27001 A.5.20; DORA 30(2): data protection; GDPR 28(3): documented instructions, confidentiality, security, assistance, audits |
Clause text — 6. Data protection: processor terms
6.1 The Supplier shall process the Customer's personal data only on the Customer's documented instructions, including those in Schedule [[X]] (subject matter, duration, nature and purpose of the processing, types of personal data and categories of data subjects), unless required to do otherwise by law, in which case it shall tell the Customer first unless the law forbids it.
6.2 The Supplier shall ensure that everyone it authorises to process the Customer's personal data is bound by a duty of confidentiality.
6.3 The Supplier shall take the security measures in clause 1 and Schedule [[X]], and shall assist the Customer, taking into account the nature of the processing and the information available to it, in meeting the Customer's obligations on security, breach notification, data protection impact assessments and prior consultation.
6.4 The Supplier shall assist the Customer, by appropriate technical and organisational measures, in responding to requests from data subjects exercising their rights, and shall pass any such request it receives to the Customer within [[5]] working days.
6.5 The Supplier shall make available to the Customer all information necessary to demonstrate compliance with this clause, and shall tell the Customer immediately if, in its opinion, an instruction infringes data protection law.
6.6 Sub-processors are governed by clause 4; return and deletion by clause 13; audits by clause 3.
Negotiation notes
- Pushback: 'Sign our data processing agreement instead.' Fallback: acceptable if it covers every point in the GDPR Article 28(3) table in this library. Check it against the table, not against its title.
- Check with your Data Protection Officer: whether the supplier is really a processor. A supplier deciding the purposes of processing itself is a controller, and these terms do not fit.
CL-07 Security incident notification
Field | Entry |
|---|---|
When to use | Tier 1 to Tier 3, and any supplier holding our data or with access to our systems. |
By tier | T1 Yes · T2 Yes · T3 Yes · T4 — |
What it achieves | Tells us of an incident at the supplier within [[24]] hours, early enough to meet our own notification duties to regulators and customers. |
Rule it serves | TP-10 |
Framework | ISO/IEC 27001 A.5.20; DORA 30(2): incident assistance; DORA 30(3): notice duties |
Clause text — 7. Security incident notification
7.1 The Supplier shall notify the Customer's security contact in Schedule [[X]] without undue delay, and in any event within [[24]] hours of becoming aware, of any actual or reasonably suspected Security Incident affecting the Customer's data, the Services or the Supplier's systems used to provide them.
7.2 The notification shall state, as far as known: what happened and when; the data, systems and services affected; the likely consequences; the measures taken or proposed; and a named contact. The Supplier shall send updates at least every [[24]] hours until the incident is closed, and a written report of its cause and the actions taken within [[10]] working days of closure.
7.3 'Security Incident' means any event that compromises, or is reasonably likely to compromise, the confidentiality, integrity or availability of the Customer's data or the Services, including a personal data breach.
Negotiation notes
- Pushback: '72 hours, as GDPR allows.' Hold firm: GDPR gives the controller 72 hours to notify the authority. If the processor takes 72 hours to tell you, you have none left. Accept an initial notice within the window with details to follow.
- Pushback: 'Only confirmed incidents.' Fallback: confirmed incidents, plus suspected incidents that affect your data.
CL-08 Vulnerability management
Field | Entry |
|---|---|
When to use | Tier 1 and Tier 2; Tier 3 where the supplier hosts our data or connects to our systems. |
By tier | T1 Yes · T2 Yes · T3 If … · T4 — |
What it achieves | Sets how fast the supplier fixes weaknesses in the systems that hold our data or run our service, with deadlines we can check. |
Rule it serves | TP-07 |
Framework | ISO/IEC 27001 A.5.20; DORA 30(3): contingency plans and security |
Clause text — 8. Vulnerability management
8.1 The Supplier shall identify and remediate vulnerabilities in the systems, software and components used to provide the Services, and shall apply security patches rated critical within [[14]] calendar days and high within [[30]] calendar days of release, or apply an effective mitigation within those periods.
8.2 The Supplier shall tell the Customer within [[2]] working days of becoming aware of a critical vulnerability that affects the Services and cannot be fixed within the period in clause 8.1, with the mitigation it has applied.
8.3 Where the Supplier provides software to the Customer, it shall provide security updates for the supported versions for the term, and shall give at least [[12]] months' notice of the end of support for any version in use by the Customer.
Negotiation notes
- Pushback: 'We patch according to our own risk assessment.' Fallback: accept their timescales if they are no longer than yours and they will report exceptions.
CL-09 Access control and multi-factor authentication for supplier staff
Field | Entry |
|---|---|
When to use | Any supplier whose staff or systems have access to our systems or data: remote support, remote user, integration, network or privileged access (criterion TC-3). |
By tier | T1 Yes · T2 Yes · T3 If … · T4 — |
What it achieves | Limits supplier access to named people, the minimum needed, protected by multi-factor authentication and removed promptly, which closes the route most supplier-borne attacks use. |
Rule it serves | TP-07, TP-08 |
Framework | ISO/IEC 27001 A.5.20; DORA 30(3): contingency plans and security |
Clause text — 9. Access control and multi-factor authentication for supplier staff
9.1 The Supplier shall ensure that only named personnel who need access to perform the Services have access to the Customer's systems and data, with the minimum privileges required, and shall keep a list of them available to the Customer on request.
9.2 All remote access by the Supplier to the Customer's systems, and all access to systems holding the Customer's data, shall use multi-factor authentication and individual accounts. Shared or generic accounts are not permitted.
9.3 The Supplier shall remove access within [[1]] working day of a person leaving the Supplier or no longer needing it, and shall review access rights at least every [[6]] months.
9.4 Privileged access shall be logged, and the logs kept for at least [[12]] months and provided to the Customer on request.
Negotiation notes
- Pushback: 'Our support tool does not support multi-factor authentication.' Hold firm: this is the gap behind many supplier-borne breaches. If it cannot be closed before signature, record it as a finding with a deadline (clause 19) or as an exception under the Security Exception & Waiver Standard (P02), not as silence.
CL-10 Business continuity and disaster recovery
Field | Entry |
|---|---|
When to use | Tier 1; Tier 2 where the supplier supports an important internal service. |
By tier | T1 Yes · T2 If … · T3 — · T4 — |
What it achieves | Commits the supplier to plans, recovery targets and tests that match how long our services can be without it. |
Rule it serves | TP-10 |
Framework | ISO/IEC 27001 A.5.20; DORA 30(3): contingency plans and security, testing participation |
Clause text — 10. Business continuity and disaster recovery
10.1 The Supplier shall maintain, test at least [[annually]] and keep up to date business continuity and disaster recovery plans for the Services, designed to restore the Services within a recovery time of [[X hours]] and with data loss of no more than [[X hours]].
10.2 The Supplier shall give the Customer a summary of each test and its results within [[30]] calendar days of the test, and shall fix any failure found within a period agreed with the Customer.
10.3 On request, the Supplier shall take part in the Customer's own continuity tests involving the Services.
Negotiation notes
- Check: the recovery targets against your own. A supplier recovering in 72 hours cannot support a service you need back in 24.
CL-11 Cooperation in our incident response
Field | Entry |
|---|---|
When to use | Tier 1 and Tier 2, and any supplier holding personal or customer data. |
By tier | T1 Yes · T2 Yes · T3 — · T4 — |
What it achieves | Makes the supplier part of our incident response: named contacts, evidence and help when an incident at either party affects the Services. |
Rule it serves | TP-10 |
Framework | ISO/IEC 27001 A.5.20; DORA 30(2): incident assistance |
Clause text — 11. Cooperation in our incident response
11.1 The Supplier shall name in Schedule [[X]] a security contact available [[24 hours a day, 7 days a week / during business hours]], and shall keep the Customer informed of any change.
11.2 When an incident affects the Customer's data or the Services, whether it starts at the Supplier or at the Customer, the Supplier shall [[at no additional charge / at the rates in Schedule X]]: take part in the Customer's incident response as reasonably requested; preserve and provide logs and other evidence; and support the Customer's notifications to regulators, customers and data subjects.
11.3 The Supplier shall take part in the Customer's incident response exercises involving the Services at least [[once every 12 months]].
Negotiation notes
- Pushback: 'Assistance is chargeable.' Fallback: free for incidents that start at the supplier; at agreed rates for incidents that start with you.
CL-12 Penetration testing and security testing
Field | Entry |
|---|---|
When to use | Tier 1; Tier 2 where the supplier hosts customer data or an internet-facing service we rely on. |
By tier | T1 Yes · T2 If … · T3 — · T4 — |
What it achieves | Ensures the systems we depend on are tested independently, and that the supplier takes part when we or a regulator test ours. |
Rule it serves | TP-04 |
Framework | ISO/IEC 27001 A.5.20; DORA 30(3): testing participation |
Clause text — 12. Penetration testing and security testing
12.1 The Supplier shall have the systems used to provide the Services tested by an independent, qualified tester at least every [[12]] months and after any significant change, and shall provide the Customer with a summary of the findings and the remediation plan within [[30]] calendar days of the report.
12.2 The Supplier shall fix critical and high findings from such tests within the periods in clause 8.1.
12.3 The Supplier shall take part in, and cooperate with, security testing of the Customer's systems that involves the Services, including testing required by a competent authority, subject to reasonable notice and agreed rules of engagement.
12.4 The Customer shall not test the Supplier's systems without the Supplier's written consent.
Negotiation notes
- Pushback: 'The full report is confidential.' Fallback: an executive summary with the count and severity of findings and their status is enough for Tier 1 evidence; the full report can be seen under a non-disclosure agreement.
CL-13 Data return and deletion
Field | Entry |
|---|---|
When to use | Every supplier that holds our data. Tier 3 only where it holds data. |
By tier | T1 Yes · T2 Yes · T3 If … · T4 — |
What it achieves | Gets our data back in a usable form and makes sure no copy is left behind, with a certificate as evidence (TP-11). |
Rule it serves | TP-11 |
Framework | ISO/IEC 27001 A.5.20; CSF GV.SC-10; DORA 30(2): data return; DORA 30(3): exit strategies; GDPR 28(3): return or deletion of data |
Clause text — 13. Data return and deletion
13.1 On termination or expiry, or earlier on the Customer's written request, the Supplier shall, at the Customer's choice, return all the Customer's data in [[a commonly used, machine-readable format agreed in Schedule X]] and then delete it, or delete it, within [[30]] calendar days of the Services ending, unless the law requires the Supplier to keep it.
13.2 Deletion includes copies held by subcontractors and sub-processors. Backup copies shall be deleted in the normal backup cycle, within [[90]] calendar days of the Services ending, and protected until then.
13.3 The Supplier shall confirm deletion in writing, signed by an authorised officer, within [[10]] working days of the deletion being complete.
13.4 Where data is returned, the Supplier shall also return or destroy any encryption keys, credentials and devices belonging to the Customer.
Negotiation notes
- Pushback: 'Deletion from backups is impossible.' Fallback: deletion when the backups expire, with the data protected until then (clause 13.2); get the backup retention period in writing.
CL-14 Exit and transition assistance
Field | Entry |
|---|---|
When to use | Tier 1 and Tier 2: every contract with an exit plan under TP-11. |
By tier | T1 Yes · T2 Yes · T3 — · T4 — |
What it achieves | Keeps the service running while it moves to another provider or back in house, so leaving a failing supplier does not stop a critical service. |
Rule it serves | TP-11 |
Framework | ISO/IEC 27001 A.5.20; CSF GV.SC-10; DORA 30(3): exit strategies |
Clause text — 14. Exit and transition assistance
14.1 The Supplier shall maintain an exit plan for the Services, agreed with the Customer within [[90]] calendar days of signature and reviewed [[annually]], covering data return, removal of access, the knowledge and documentation to be handed over, and a transition timetable.
14.2 On termination for any reason, the Supplier shall continue to provide the Services, on the terms of this Agreement, for a transition period of up to [[6]] months at the Customer's request, and shall cooperate with the Customer and any replacement supplier to transfer the Services in an orderly way.
14.3 Transition assistance beyond continued provision of the Services is charged at the rates in Schedule [[X]].
Negotiation notes
- Pushback: 'We cannot commit to a transition period if you terminate for our breach.' Hold firm: that is exactly when you will need it most.
CL-15 Termination rights for security reasons
Field | Entry |
|---|---|
When to use | Tier 1 to Tier 3. Tier 4 relies on the main contract's ordinary termination terms. |
By tier | T1 Yes · T2 Yes · T3 Yes · T4 — |
What it achieves | Lets us leave without penalty when a supplier's security fails badly, instead of paying to stay with a supplier we can no longer trust. |
Rule it serves | TP-11 |
Framework | ISO/IEC 27001 A.5.20; CSF GV.SC-10; DORA 30(2): termination rights |
Clause text — 15. Termination rights for security reasons
15.1 The Customer may terminate this Agreement, in whole or in part, on written notice and without penalty if: the Supplier commits a material breach of clauses [[1, 6, 7, 9 or 13]]; a Security Incident at the Supplier causes material harm to the Customer; the Supplier fails to remedy a High finding by its agreed deadline under clause 19; or a competent authority requires the Customer to end the arrangement.
15.2 Termination under this clause does not affect the Customer's rights under clauses 13 and 14.
Negotiation notes
- Pushback: 'Termination only after a cure period.' Fallback: a cure period of [[30]] calendar days for breaches that can be remedied, none for a regulator's requirement or a serious incident.
CL-16 Security awareness and training of supplier staff
Field | Entry |
|---|---|
When to use | Tier 1 and Tier 2, and suppliers whose staff handle customer or sensitive data. |
By tier | T1 Yes · T2 Yes · T3 — · T4 — |
What it achieves | Ensures the people who work on our data and systems are trained, and, where we require it, take part in our own awareness programme. |
Rule it serves | TP-07 |
Framework | ISO/IEC 27001 A.5.20; DORA 30(2): training |
Clause text — 16. Security awareness and training of supplier staff
16.1 The Supplier shall ensure that all personnel involved in the Services receive information security awareness training on joining and at least every [[12]] months, and shall keep records of that training available to the Customer on request.
16.2 Where the Customer so requires, the Supplier's personnel with access to the Customer's systems shall take part in the Customer's security awareness and training programmes.
Negotiation notes
- Usually accepted. Where the supplier resists 16.2, limit it to personnel with privileged access.
CL-17 Cooperation with competent authorities
Field | Entry |
|---|---|
When to use | Any ICT service to a regulated entity that must give its supervisors access, including every ICT contract of a DORA financial entity. |
By tier | T1 If … · T2 If … · T3 If … · T4 — |
What it achieves | Commits the supplier to cooperate fully with our regulators, including their inspections, so an outsourced service does not put us out of reach of supervision. |
Rule it serves | TP-07 |
Framework | ISO/IEC 27001 A.5.20; DORA 30(2): cooperation with authorities |
Clause text — 17. Cooperation with competent authorities
17.1 The Supplier shall cooperate fully with any competent authority with jurisdiction over the Customer, and with any person appointed by it, including by giving access, information and assistance as the authority requires.
17.2 The Supplier shall tell the Customer promptly, unless the law forbids it, of any request from a competent authority concerning the Services.
Negotiation notes
- Hold firm (regulated entities): this is not a commercial point; the regulator can require it.
CL-18 Service levels and security reporting
Field | Entry |
|---|---|
When to use | Tier 1; Tier 2 where the supplier supports an important internal service. For DORA critical or important functions, the service levels must be complete and measurable. |
By tier | T1 Yes · T2 If … · T3 — · T4 — |
What it achieves | Sets measurable targets for the service and a regular security report, so performance is checked on facts at each review (TP-09). |
Rule it serves | TP-09 |
Framework | ISO/IEC 27001 A.5.20; DORA 30(2): service levels; DORA 30(3): full service levels |
Clause text — 18. Service levels and security reporting
18.1 The Supplier shall meet the service levels in Schedule [[X]], including availability of [[99.9]]% per calendar month, incident response and resolution times, and recovery targets, and shall report performance against them every [[month]].
18.2 The Supplier shall give the Customer a security report every [[quarter]] covering: Security Incidents; open critical and high vulnerabilities; progress on findings under clause 19; changes to subcontractors, sub-processors and locations; and the status of certifications.
18.3 Where a service level is missed, the Supplier shall give the Customer a corrective plan within [[10]] working days.
Negotiation notes
- Pushback: 'Standard service levels only.' Fallback: standard service levels plus the quarterly security report; the report costs the supplier little and tells you most.
CL-19 Remediation of assessment findings
Field | Entry |
|---|---|
When to use | Whenever the assessment decision is 'Approve with conditions', whatever the tier. Recommended in every Tier 1 and Tier 2 contract so that later findings have a contractual deadline. |
By tier | T1 Yes · T2 Yes · T3 If … · T4 — |
What it achieves | Turns the findings of the security assessment into contract conditions with deadlines, so 'Approve with conditions' means something (TP-05, TP-08). |
Rule it serves | TP-05, TP-08 |
Framework | ISO/IEC 27001 A.5.20 |
Clause text — 19. Remediation of assessment findings
19.1 The Supplier shall remedy the findings listed in Schedule [[X]] by the deadlines stated there, and shall report progress to the Customer every [[month]] until each is closed.
19.2 For findings from later assessments, the Supplier shall agree a remediation plan within [[20]] working days of the Customer's report, with deadlines of no more than [[90]] calendar days for High findings and [[180]] calendar days for Medium findings, counted from the date of the report.
19.3 A High finding not remedied by its deadline is a material breach for the purposes of clause 15.
Negotiation notes
- Pushback: 'We will fix it in our next release.' Fallback: agree the date, but put it in the schedule. A finding without a contractual date is not a condition.
CL-20 Notice of material changes
Field | Entry |
|---|---|
When to use | Tier 1 and Tier 2, and suppliers holding personal or customer data. |
By tier | T1 Yes · T2 Yes · T3 — · T4 — |
What it achieves | Tells us of the changes that make the last assessment out of date, so we can reassess (TP-09) before the risk changes, not after. |
Rule it serves | TP-09 |
Framework | ISO/IEC 27001 A.5.20; DORA 30(3): notice duties |
Clause text — 20. Notice of material changes
20.1 The Supplier shall give the Customer at least [[30]] calendar days' written notice of any change that may materially affect the security, resilience or performance of the Services or its ability to meet this Agreement, including: a change of control; a material change to the systems, architecture or security measures; the loss of a certification; and material financial difficulty.
20.2 Where notice in advance is not possible, the Supplier shall give it as soon as it becomes aware of the change.
Negotiation notes
- Pushback: 'We cannot disclose a change of control before it is public.' Fallback: notice as soon as the law allows.
CL-21 Cloud services
Field | Entry |
|---|---|
When to use | Any cloud service (software, platform or infrastructure as a service) that holds our data, added to the clauses for its tier. |
By tier | T1 If … · T2 If … · T3 If … · T4 — |
What it achieves | Makes the division of security duties between us and the cloud provider explicit, so neither assumes the other is doing it. |
Rule it serves | TP-07 |
Framework | ISO/IEC 27001 A.5.20; A.5.23 |
Clause text — 21. Cloud services
21.1 The Supplier shall document which security controls it operates and which the Customer must configure or operate (the shared responsibility), and shall keep that document current.
21.2 The Supplier shall make available to the Customer the logs of access to and activity in the Customer's environment for at least [[90]] calendar days, and shall support the Customer's use of [[multi-factor authentication / single sign-on]] for all users.
21.3 The Supplier shall give the Customer the means to export all its data in a usable format at any time during the term, not only at exit.
Negotiation notes
- Large cloud providers rarely negotiate. Map their standard terms against this clause and the others for the tier, record the gaps, and treat each as a risk (P05) or an exception (P02). Configure your own side of the shared responsibility; most cloud breaches start there.
Worked examples
Two EXAMPLE suppliers of the distributor used throughout the pack (a wholesale distributor with about 900 staff, three warehouses and an online ordering service that takes 60% of its orders), as at 30 September 2026 (EXAMPLE; replace with your own date). The distributor is not a financial entity, so the DORA columns do not apply.
Example 1 — SUP-004, conditions from the assessment
SUP-004 (ERP software provider (hosted)) is Tier 1: it supports finance and payroll and warehouse dispatch. It was assessed on 21 April 2026 and the decision was Approve with conditions: proceed; named findings fixed by their deadlines, recorded as conditions in the contract or the register. The findings go into the schedule to CL-19:
Finding | Severity | Clause it relates to | Deadline (calendar days from the report) | Status at 30 September 2026 |
|---|---|---|---|---|
F-01 Support staff reach our ERP without multi-factor authentication | High | CL-09 (paragraph 9.2) | 20 July 2026 (90 days from 21 April 2026) | Open; 72 days past deadline |
F-02 No evidence that our data is deleted at contract end | Medium | CL-13 (paragraph 13.3) | 18 October 2026 (180 days from 21 April 2026) | Open |
- What the contract changes. Without CL-19, F-01 is a request in a report. With it, the deadline of 20 July 2026 is a contract term, and under CL-15 a High finding not remedied by its deadline is grounds for termination without penalty.
- What happens now. F-01 is past its deadline, so under TP-08 it is escalated to the business owner, who decides whether to enforce, agree a new date recorded as an exception under the Security Exception & Waiver Standard, or plan exit (TP-11). The Third-Party Risk Dashboard counts it in TPM-03.
- What the renewal adds. SUP-004 holds personal data for us, so CL-06 applies; F-02 shows why CL-13.3, the signed deletion certificate, belongs in the contract and not only in the questionnaire.
Example 2 — SUP-012, selecting clauses for a new contract
SUP-012 (Payroll bureau) is Tier 1 by service and data (see the Supplier Criticality & Tiering Model), processes staff personal data for us, and is a hosted service. Its assessment is planned for 17 November 2026; the contract is renewed after it.
Step | Result |
|---|---|
Tier column (Tier 1) | CL-01, CL-02, CL-03, CL-04, CL-05, CL-07, CL-08, CL-09, CL-10, CL-11, CL-12, CL-13, CL-14, CL-15, CL-16, CL-18, CL-19, CL-20 |
Data column (personal data processed for us; staff data at scale) | Adds CL-06 (processor terms) |
Conditions | CL-21: yes, the bureau's portal is a cloud service holding our data. CL-17: no, the distributor has no supervisor requiring it. |
DORA | Not applicable |
Assessment conditions | Any findings from the assessment go in the schedule to CL-19 |
Clauses in the contract | CL-01, CL-02, CL-03, CL-04, CL-05, CL-06, CL-07, CL-08, CL-09, CL-10, CL-11, CL-12, CL-13, CL-14, CL-15, CL-16, CL-18, CL-19, CL-20, CL-21 — 20 clauses |
Negotiating with suppliers
- Start from the tier. A supplier asked for Tier 1 clauses because it is Tier 1 will understand; one asked for everything because it is in the template will not. Say why.
- Know your must-haves. For every supplier that holds our data: incident notification (CL-07), return and deletion of data (CL-13) and, for processors, the processor terms (CL-06). For Tier 1: also access control (CL-09), exit (CL-14) and audit (CL-03).
- Accept equivalent wording. The supplier's own clause is fine if it achieves the same outcome. Compare it with 'What it achieves', not word for word.
- Trade evidence for audit. A current certification or independent report with the right scope is a fair substitute for on-site audit, except after an incident and for a regulator.
- Record what you did not get. A clause given up is a known gap: record it as an exception or a risk (step 7 of 'How to use this library'), and look at it again at the next reassessment (TP-09).
Related documents
Document | Relationship |
|---|---|
Third-Party Security Policy | Rule TP-07, which this library puts into practice, and TP-10 and TP-11, which several clauses serve |
Supplier Security Assessment Procedure | Where clause selection happens in the assessment process |
Supplier Criticality & Tiering Model | Sets the tier that selects the clauses |
Supplier Due Diligence Evidence Checklist | The evidence that shows a clause is being met (TP-04) |
Supplier Security Risk Register | Records the tier, the contract and any gaps |
Supplier Security Review Report Template | Records findings and conditions that go into CL-19 |
Security Exception & Waiver Standard | Where a clause the supplier refuses is recorded as an exception |
Information Security Risk Register | Where a supplier left outside appetite by a missing clause is recorded |
Adapting this template
Guidance — delete before approval
Small organisation: you will rarely have negotiating power with large suppliers. Use this library as a checklist against their standard terms, insist on CL-06, CL-07 and CL-13 where you can, and record the rest as known gaps. For your own small suppliers, attach the clauses for their tier as a security schedule to your standard purchase terms.
Regulated entity: NIS2 Article 21(2)(d) makes supply chain security, including the security aspects of supplier relationships, part of the required measures; contracts are where they are fixed. A DORA financial entity uses the DORA columns and coverage tables, has its legal adviser check each ICT contract against the full text of Article 30, and records the arrangements in its register of information. For processors, GDPR Article 28(2) and 28(3) apply whatever the sector.
IT run by a service provider: your managed IT provider will usually be Tier 1 with privileged access: CL-09 (multi-factor authentication for its staff), CL-11 (cooperation in incident response) and CL-14 (exit) matter most. If it subcontracts parts of your service, CL-04 applies even where no personal data is involved.
Set every [[bracketed]] value before first use and keep them consistent across contracts; changes are made here and recorded in the revision history.
Delete this section before approval.
Framework references
These references show where this document supports an external framework. They indicate relevance only and do not reproduce the text of any standard. Editions referenced: ISO/IEC 27001:2022 incl. Amd 1:2024; NIST CSF 2.0; Directive (EU) 2022/2555 (NIS2); Regulation (EU) 2022/2554 (DORA); Regulation (EU) 2016/679 (GDPR).
Framework | Reference | Supported by |
|---|---|---|
ISO/IEC 27001:2022 | Annex A 5.20 — Addressing information security within supplier agreements | Whole library: security requirements agreed with each supplier according to its tier |
ISO/IEC 27001:2022 | Annex A 5.23 — Information security for use of cloud services | CL-21 Cloud services; the note on standard cloud terms |
NIST CSF 2.0 | GV.SC-05 — “Requirements to address cybersecurity risks in supply chains are established, prioritized, and integrated into contracts and other types of agreements with suppliers and other relevant third parties” | Selection matrix and clauses: requirements prioritised by tier and put into contracts |
NIST CSF 2.0 | GV.SC-10 — “Cybersecurity supply chain risk management plans include provisions for activities that occur after the conclusion of a partnership or service agreement” | CL-13 Data return and deletion, CL-14 Exit and transition, CL-15 Termination |
NIS2 — Directive (EU) 2022/2555 | Article 21(2)(d) — “supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers” | Whole library, as the contractual part of supply chain security |
DORA — Regulation (EU) 2022/2554 | Article 30(2) — minimum contract content: services, locations, data protection, data return, service levels, incident assistance, cooperation with authorities, termination rights, training | Coverage table for all ICT contracts; DORA: all ICT services column |
DORA — Regulation (EU) 2022/2554 | Article 30(3) — additional contract content for critical or important functions: full service levels, notice duties, contingency plans and security, testing participation, audit and access rights, exit strategies | Coverage table for critical or important functions; DORA: critical or important column |
GDPR — Regulation (EU) 2016/679 | Article 28(2) — no sub-processor without the controller's prior written authorisation | CL-04 paragraph 4.1: no sub-processor without prior written authorisation |
GDPR — Regulation (EU) 2016/679 | Article 28(3) — a binding contract with the processor, covering documented instructions, confidentiality, security, sub-processors, assistance, return or deletion of data, and audits | CL-06 and the GDPR coverage table |
Definitions
Term | Meaning in this library |
|---|---|
Clause | A ready contract provision with a stable CL-nn ID. |
Core clause | A clause marked Yes for a tier: always included for that tier. |
Critical or important function | A function whose disruption would materially impair a financial entity, as DORA defines it. |
DORA | The Digital Operational Resilience Act, Regulation (EU) 2022/2554, which applies to financial entities. |
Exit plan | How data is returned or deleted, access removed and the service moved on termination (TP-11). |
NIS2 | Directive (EU) 2022/2555 on a high common level of cybersecurity. |
Processor | A supplier that processes personal data on our behalf (GDPR Article 28). |
Schedule | An annex to the contract holding details a clause refers to: security requirements, locations, sub-processors, findings. |
Security Incident | As defined in CL-07, paragraph 7.3. |
Short form | The first paragraph of a clause only, used for Tier 4. |
Sub-processor | A party the processor engages to process our personal data. |
Tier | One of four levels — Tier 1 Critical, Tier 2 Important, Tier 3 Standard, Tier 4 Minimal — set by the Supplier Criticality & Tiering Model. |