Customer Security Addendum Template (ISO/IEC 27001 A.5.20)

Customer Security Addendum: [Provider name] and [Customer name]

Structure and clause library for a security addendum (also called an information security schedule or security exhibit) attached to a customer agreement for a hosted or managed service. It covers the provider's security programme, maintenance of certifications, the security measures annex, personnel, sub-processors and subcontractors, data location, assessment and audit rights, security incident notification, vulnerability testing, continuity, return and deletion of data, customer responsibilities and a pointer to the liability terms of the main agreement. It supports ISO/IEC 27001:2022

• Amd 1:2024 Annex A controls A.5.20 (security terms in supplier agreements, seen from the supplier side), A.5.31 (legal, regulatory and contractual requirements), A.5.34 (privacy and PII protection) and A.5.14 (information transfer), with guidance from ISO/IEC 27002:2022 and ISO/IEC 27036-2:2022. Replace every [bracketed] value and every row marked Example. This is a documentation format, not legal advice.

Document control

Approvals

Revision history

Contents

• 1. Purpose and when to use
• 2. Definitions
• 3. Contract structure and order of precedence
• 4. Security programme and certifications
• 5. Personnel and confidentiality
• 6. Sub-processors and subcontractors
• 7. Data location and transfers
• 8. Security incident notification
• 9. Assessments and audit rights
• 10. Vulnerability management and testing
• 11. Business continuity
• 12. Return and deletion of customer data
• 13. Customer responsibilities, liability and term
• 14. Negotiation playbook and commitment register
• 15. Regulatory examples
• 16. Size tiers
• 17. Records and evidence
• 18. References
• Annex 1. Security measures
• Annex 2. Contacts and notification details

1. Purpose and when to use

This addendum sets out the information security commitments of [Provider name] ("Provider") to [Customer name] ("Customer") for the services described in the main agreement. It turns the Provider's ISMS into contractual terms that are clear, testable and consistent with what the Provider operates.

Use it:

• as a standard attachment to every customer agreement for the hosted service, or above a contract value or data sensitivity threshold set by management;
• as the reference when a customer sends its own security schedule: compare each customer clause with the matching clause here and use the playbook in section 14;
• as a checklist for operations: every clause has an owner and a record (section 17).

The addendum does not replace the data processing agreement, which governs personal data processing duties under data protection law. When both apply, section 3 sets the order.

2. Definitions

In this addendum, terms defined in the main agreement keep their meaning. In addition:

3. Contract structure and order of precedence

Clause template (Example):

3.1 This addendum forms part of the main agreement. If this addendum conflicts with the main agreement on a matter of information security, this addendum prevails. If it conflicts with the data processing agreement on the processing of personal data, the data processing agreement prevails, except that the shorter notification period applies to Security Incidents.

3.2 Nothing in this addendum extends or limits the liability terms of the main agreement unless clause 13.3 says so expressly.

4. Security programme and certifications

Clause template (Example):

4.1 Provider will maintain an information security management system that meets the requirements of ISO/IEC 27001:2022 (or a later edition) for the systems, people and processes that deliver the services, and will implement and maintain the Security Measures.

4.2 Provider will maintain the following Certification for the scope that covers the services: ISO/IEC 27001 certification issued by a certification body accredited by an accreditation body that is a signatory of the Global ACI MRA (formerly the IAF MLA), with a scope that includes the services. Provider will make the current certificate available on its trust centre and will provide the Statement of Applicability on request under confidentiality.

4.3 If a Certification is suspended or withdrawn, or is not renewed by its expiry, Provider will notify Customer within [10] Business Days, explain the reason and the remediation plan, and give Customer the assessment rights in clause 9.3 until the Certification is restored.

4.4 Provider may update the Security Measures, provided that the update does not materially reduce the overall protection of Customer Data. Provider will publish material changes on its trust centre.

Notes:

• Name only certifications actually held. A planned certification goes in a side letter or not at all, worded as a target (see isms/certification-mark-usage).
• Avoid naming specific products or tools in the clause: commit to the outcome (for example "encryption at rest using industry-standard algorithms") and keep detail in Annex 1.

5. Personnel and confidentiality

Clause template (Example):

5.1 Provider will ensure that personnel with access to Customer Data are bound by written confidentiality obligations, have been screened to the extent allowed by applicable law, and receive security and privacy training at onboarding and at least once a year.

5.2 Provider will grant access to Customer Data on a need-to-know and least-privilege basis, review privileged access at least every [three] months and remove access promptly when it is no longer needed.

6. Sub-processors and subcontractors

Clause template (Example):

6.1 Provider will impose on each Sub-processor and each Subcontractor with access to Customer Data written security obligations that protect Customer Data at least as well as this addendum, and remains responsible for their performance.

6.2 Provider will assess the security of each Sub-processor before engagement and review it at least once a year.

6.3 Provider will maintain a list of Sub-processors and notify Customer of any intended addition or replacement as set out in the data processing agreement, including Customer's right to object.

7. Data location and transfers

Clause template (Example):

7.1 Provider will store Customer Data at rest in the hosting regions stated in the order form, including backups and disaster recovery copies.

7.2 Provider may access Customer Data from other locations only to provide support, maintain security or comply with law, and only under the transfer mechanisms set out in the data processing agreement.

7.3 Provider will notify Customer at least [90] days before changing a hosting region stated in the order form.

8. Security incident notification

Clause template (Example):

8.1 Provider will notify Customer without undue delay, and in any event within [48] hours, after Provider becomes aware of a Security Incident. Notice is sent to the contacts in Annex 2.

8.2 The notice will describe, to the extent then known, the nature of the Security Incident, the categories and approximate volume of Customer Data affected, the likely consequences, the measures taken or proposed, and a contact for further information. Provider will provide updates as further information becomes available.

8.3 Provider will take reasonable steps to contain and remediate the Security Incident, preserve relevant evidence, and give Customer the information Customer reasonably needs to meet its own legal notification duties.

8.4 Provider will provide a written summary of the root cause and corrective actions within [20] Business Days after closing the Security Incident.

8.5 Notification of a Security Incident is not an admission of fault or liability by Provider.

Operational alignment: the incident response plan (DOC-ISMS-020) must contain a step that checks every affected customer's contractual period in the commitment register (section 14) before the internal deadline. Many customers have their own short regulatory deadlines (for example under NIS2 or DORA, section 15), so they ask for short periods; agree to a period only if the incident process can meet it at night and at weekends.

9. Assessments and audit rights

Clause template (Example):

9.1 Provider will make available on request, under confidentiality, its current Certification, Statement of Applicability, the summary of its most recent independent penetration test and a completed standard security questionnaire.

9.2 Customer may send one security questionnaire per contract year, and additional ones after a Security Incident affecting Customer Data. Provider will answer within [30] days.

9.3 If the information in clauses 9.1 and 9.2 does not reasonably show compliance with this addendum, or a regulator with authority over Customer requires it, Customer or an independent auditor bound by confidentiality may conduct an audit, no more than once per contract year, on at least [30] days' written notice, during Business Days, in a way that does not disrupt the services or compromise the security or confidentiality of other customers' data. The audit is remote unless an on-site visit is necessary for its purpose.

9.4 Each party bears its own audit costs unless the audit reveals a material breach of this addendum by Provider. Provider will remedy confirmed findings within a reasonable period agreed with Customer.

Customer audits are managed like other external reviews: findings enter the audit findings register (DOC-ISMS-086) and evidence is shared at tier T3 under the answer library rules (DOC-ISMS-115 section 7).

10. Vulnerability management and testing

Clause template (Example):

10.1 Provider will maintain a vulnerability management process, remediate vulnerabilities according to their severity, and have an independent penetration test of the services performed at least once a year.

10.2 Customer may perform its own security testing of its own tenant only with Provider's prior written approval and under Provider's testing rules. Testing of shared infrastructure or of other customers' data is not allowed.

11. Business continuity

Clause template (Example):

11.1 Provider will maintain and test at least once a year business continuity and disaster recovery plans for the services, and will back up Customer Data in a way that allows recovery within the targets stated in Annex 1.

11.2 Service availability commitments are set out in the service level agreement.

12. Return and deletion of customer data

Clause template (Example):

12.1 During the term and for [30] days after it ends, Customer may export Customer Data using the export features of the services.

12.2 After the export window, Provider will delete Customer Data from production systems within [30] days, and backup copies will be deleted as they expire, within a further [35] days, unless law requires Provider to keep them. Retained data stays protected under this addendum until deleted.

12.3 On request, Provider will confirm deletion in writing.

13. Customer responsibilities, liability and term

Clause template (Example):

13.1 Customer is responsible for the security of its own systems and accounts, including managing its users and their access rights, enabling the authentication features offered, keeping credentials confidential, protecting data it exports and promptly reporting suspected unauthorised use of its accounts.

13.2 Customer will not upload to the services data types excluded in the order form (for example payment card data) unless agreed in writing.

13.3 Liability arising from this addendum is subject to the limitations and exclusions of the main agreement. [If a separate cap for data protection or security breaches is agreed, state it in the main agreement and refer to it here.]

13.4 This addendum applies for as long as Provider processes Customer Data. Clauses 8, 12 and the confidentiality of audit information survive termination until all Customer Data is deleted.

14. Negotiation playbook and commitment register

14.1 Positions per clause

14.2 Commitment register (Example, Quillmere Analytics Ltd)

Quillmere Analytics Ltd (46 staff) has 4 deviations across 3 customers in this example; the 0.5 FTE ISMS manager reviews the register each quarter with legal counsel and before every surveillance audit.

15. Regulatory examples

These rows are short summaries in our own words, given as examples to discuss with counsel. They are not legal advice and not a complete statement of any law: read the official texts (EUR-Lex for EU law), the national transposition laws for NIS2, and any delegated or implementing acts before you rely on them. DORA Art. 30, for example, has a general list of key provisions for all ICT service contracts (Art. 30(2)) and additional provisions for ICT services that support critical or important functions (Art. 30(3)).

Keep the regimes that apply to your customers in the legal, regulatory and contractual register (DOC-ISMS-014).

16. Size tiers

17. Records and evidence

18. References

Related templates: legal-lite/master-services-agreement-outline, legal-lite/dpa, legal-lite/sla-outline, legal-lite/subprocessor-list, isms/supplier-security-agreement-27036, isms/security-questionnaire-answer-library, isms/security-whitepaper-trust-center, compliance/incident-response-plan, compliance/statement-of-applicability, compliance/legal-register, isms/certification-mark-usage, isms/control-evidence-matrix.

Annex 1. Security measures

Annex 2. Contacts and notification details

Standard and licence note

Structure aligned with ISO/IEC 27001:2022 + Amd 1:2024 Annex A controls A.5.14, A.5.20, A.5.31 and A.5.34, with ISO/IEC 27002:2022 and ISO/IEC 27036-2:2022 as guidance. The clause wording, positions and examples are original. Control numbers are cited with short descriptive labels; no ISO/IEC text is reproduced, and you need the official standards to implement the controls. Laws are summarised in our own words as international examples. This is a documentation format, not legal advice: have qualified counsel review every clause for your jurisdiction and contract. Check the current editions and legal texts before use. Template licence: MIT.