ISO 27001 Annex A 5.20 is a security control that requires organisations to establish and formalise security requirements within legal agreements for all third-party partners. The primary implementation requirement focuses on embedding enforceable security clauses into contracts, providing a critical business benefit by legally safeguarding sensitive organisational information assets.
In this guide, I will show you exactly how to implement ISO 27001 Annex A 5.20 and ensure you pass your audit. You will get a complete walkthrough of the control, practical implementation examples, and access to the ISO 27001 templates and toolkit that make compliance easy.
I am Stuart Barker, an ISO 27001 Lead Auditor with over 30 years of experience conducting hundreds of audits. I will cut through the jargon to show you exactly what changed in the 2022 update and provide you with plain-English advice to get you certified.
Key Takeaways: ISO 27001 Annex A 5.20 Addressing Information Security within Supplier Agreements
ISO 27001 Annex A 5.20 requires that relevant information security requirements are established and agreed upon with each supplier that accesses, processes, stores, communicates, or provides infrastructure components for the organization’s information. While Annex A 5.19 focuses on the general relationship, this control is about the contractual “teeth.” The goal is to ensure that security obligations are legally binding, clearly defined, and leave no room for ambiguity regarding who is responsible for protecting data in the event of a breach.
Core requirements for compliance include:
- Explicit Security Clauses: Agreements must include specific clauses for data protection, confidentiality, and intellectual property. Generic “we will keep your data safe” statements are insufficient for an audit.
- Incident Notification Timelines: Suppliers must be contractually obligated to notify you of a security breach within a specific window (e.g., 24 or 72 hours) to allow you to meet your own legal obligations under GDPR or CCPA.
- Right to Audit: You must include the legal right to audit the supplier’s security controls or, at a minimum, require them to provide independent audit reports (such as SOC 2 or an ISO 27001 certificate) annually.
- Supply Chain Transparency: Agreements should require the supplier to manage their own “sub-suppliers” to the same standard, preventing security weak points further down the chain.
- Vulnerability Management: Contracts should specify the supplier’s responsibility for patching and vulnerability reporting for any software or hardware they provide.
- Secure Deletion/Return: Upon contract termination, the agreement must mandate the secure return or destruction of all organization data.
Audit Focus: Auditors will look for “The Legal Shield”:
- Contractual Sampling: “Show me the signed agreement for your cloud hosting provider. Where does it state their requirement to notify you of a breach?”
- Consistency Check: “Does your standard Data Processing Agreement (DPA) match the security requirements defined in your Risk Assessment?”
- Exit Clauses: “What happens to your data if this supplier goes bankrupt? Show me the ‘Return of Assets’ clause in their contract.”
Supplier Agreement Checklist (Audit Prep):
| Contract Requirement | Mandatory Inclusion | Why it matters | ISO 27001:2022 Control |
|---|---|---|---|
| Confidentiality / NDA | Required for all. | Prevents unauthorised disclosure of trade secrets. | Annex A 5.15 / 5.20 |
| Incident Reporting | Defined timeline. | Essential for meeting regulatory breach windows. | Annex A 5.20 / 5.24 |
| Right to Audit | Required for T1/T2. | Allows you to verify security claims independently. | Annex A 5.20 / 5.22 |
| Access Controls | Defined methods. | Ensures suppliers use MFA and Least Privilege. | Annex A 5.20 / 8.15 |
| Data Deletion | Post-termination. | Prevents “Data Residue” risks after the contract ends. | Annex A 5.20 / 8.10 |
Table of contents
- What is ISO 27001 Annex A 5.20?
- Watch the ISO 27001 Annex A 5.20 Tutorial
- ISO 27001 Annex A 5.20 Podcast
- ISO 27001 Annex A 5.20 Implementation Guidance
- How to implement ISO 27001 Annex A 5.20
- Contract Clause Checklist
- ISO 27001 Supplier Register Template
- ISO 27001 Supplier Policy Template
- How to comply
- How to audit ISO 27001 Annex A 5.20
- How to pass the ISO 27001 Annex A 5.20 audit
- What the auditor will check
- Top 3 ISO 27001 Annex A 5.20 Mistakes People Make and How to Avoid Them
- Applicability of ISO 27001 Annex A 5.20 across different business models.
- Fast Track ISO 27001 Annex A 5.20 Compliance with the ISO 27001 Toolkit
- ISO 27001 annex A 5.20 Applicable Laws and Related Standards
- ISO 27001 Annex A 5.20 FAQ
- Related ISO 27001 Controls and Further Reading
- ISO 27001 controls and attribute values
ISO 27001 Certainty™: The Ultimate ISO 27001 Certification System & Toolkit
What is ISO 27001 Annex A 5.20?
ISO 27001 Annex A 5.20 is about addressing information security in your supplier agreements which means you need legal agreements in place with suppliers that cover your information security requirements.
ISO 27001 Annex A 5.20 Addressing information security within supplier agreements is an ISO 27001 control that requires an organisation to establish and agree information security requirements with suppliers.
It is about having a legal mechanism in place. A contract or an agreement or terms of business.
Suppliers represent one of your biggest risks as you cannot directly manage them or influence them and it is likely you rely on them, they have your data and provide services that you need to be successful.
ISO 27001 Annex A 5.20 Purpose
The purpose of ISO 27001 Annex A 5.20 is a preventive control that ensures you maintain an agreed level of information security in supplier relationships.
ISO 27001 Annex A 5.20 Definition
The ISO 27001 standard defines ISO 27001 Annex A 5.20 as:
Relevant information security requirements should be established and agreed with each supplier based on the type of supplier relationship.
ISO 27001:2022 Annex A 5.20 Addressing information security within supplier agreements
Watch the ISO 27001 Annex A 5.20 Tutorial
In the video ISO 27001 Information Security Within Supplier Agreements Explained – ISO27001:2022 Annex A 5.20 I show you how to implement it and how to pass the audit.
ISO 27001 Annex A 5.20 Podcast
In this episode: Lead Auditor Stuart Barker and team do a deep dive into the ISO 27001 Annex A 5.20 Addressing Information Security Within Supplier Agreements. The podcast explores what it is, why it is important and the path to compliance.
ISO 27001 Annex A 5.20 Implementation Guidance
We are going to rely on a couple of mechanism to ensure Information Security In Supplier Relationships.
Supplier Agreements / Contracts
The number one recommendation is to seek professional legal counsel for the provision of all contracts. The following is guidance but you should always defer to professional legal counsel. Always. You are not a lawyer. We are not a lawyer.
Our first line of defence and go to is the supplier agreement or supplier contract. At its core it is a legal mechanism that is legally binding and provides the greatest level of overall protection.
- It sets out what is required, what will be done, who will do it, what happens if things go wrong.
- What information is to be provided, accessed and the methods of access.
- Legal, regulatory and contractual requirements. Elements such as intellectual property rights, copyright information, data protection requirements.
- The controls and levels of controls that are required by both parties to the agreement.
- Acceptable and unacceptable use of assets.
- How to grant and remove access
- Penalties, indemnities and remediation for failings to meet the contract.
- Contact information
- Screening requirements for staff were legally enforceable.
- How evidence and assurance of information security will be provided
- Rights to audit
- How to solve problems or conflicts with the contract
- Appropriate back up, business continuity and disaster recovery
- The process for change management
- Physical security as appropriate
- Information transfer processes
- Termination clauses and processes
- Destruction and removal of data processes
- Handover at the end of the contract
Contracts are kept and recorded in the ISO 27001 Supplier Register. They are reviewed at least annually, based on risk and significant change or event.
I’ve sat in the Auditor’s chair for 30 years. Use the exact system and tools I use to guarantee a pass.
How to implement ISO 27001 Annex A 5.20
Implementing ISO 27001 Annex A 5.20 is a critical governance activity that ensures your security requirements are legally enforceable. By embedding specific security clauses into your supplier agreements, you mitigate third-party risks and ensure that external partners adhere to your organisational standards throughout the contract lifecycle.
1. Categorise Suppliers within the Asset Register
- Identify all suppliers with access to organisational information assets or systems: recording them in a central register.
- Assign a risk tier to each supplier based on the sensitivity of the data they handle: categorising them as critical, high, or low risk.
- Update the Asset Register regularly to reflect changes in the supplier landscape: ensuring all third-party dependencies are visible.
2. Formalise Organisational Security Requirements
- Define the baseline security controls that must be present in every contract: including data protection and encryption standards.
- Align requirements with your internal Information Security Management System (ISMS): ensuring external partners meet internal benchmarks.
- Consult legal and procurement teams to standardise terminology: reducing ambiguity in contractual security obligations.
3. Integrate Data Protection and GDPR Clauses
- Specify how personal and sensitive data must be handled, stored, and processed: ensuring compliance with the UK Data Protection Act.
- Mandate that suppliers provide evidence of their own data protection impact assessments: verifying their internal privacy controls.
- Formalise the geographic locations where data is permitted to reside: preventing unauthorised cross-border transfers.
4. Provision Granular Identity and Access Management (IAM) Requirements
- Codify the requirement for the Principle of Least Privilege (PoLP): ensuring suppliers only access what is strictly necessary.
- Mandate the use of Multi-Factor Authentication (MFA) for any remote or privileged access to your network: reducing credential-based risks.
- Require the immediate notification of personnel changes: ensuring supplier accounts are revoked as soon as staff leave their roles.
5. Standardise the Right to Audit and Monitor
- Include explicit clauses that grant your organisation the right to perform security audits on the supplier: ensuring transparency.
- Define the frequency and scope of these audits: ranging from questionnaire-based reviews to on-site inspections.
- Specify that the supplier must provide independent audit reports, such as SOC 2 or ISO 27001 certificates: upon request.
6. Establish Technical Rules of Engagement (ROE)
- Document the boundaries for technical testing or monitoring within the agreement: ensuring no operational disruption occurs.
- Define the permitted methods for vulnerability scanning or penetration testing: setting clear expectations for both parties.
- Agree on the communication channels for reporting technical findings: ensuring a rapid response to identified weaknesses.
7. Codify Incident Management and Reporting Timelines
- Mandate a strict timeline for reporting security breaches: ensuring your internal team can respond within regulatory windows.
- Define what constitutes a reportable security incident: including near-misses or unauthorised access attempts.
- Require the supplier to cooperate fully during incident investigations: providing logs and forensic evidence as required.
8. Secure the ICT Supply Chain via Flow-Down Clauses
- Require primary suppliers to flow down your security requirements to their sub-contractors: ensuring security throughout the chain.
- Mandate that suppliers conduct due diligence on their own vendors: maintaining a chain of trust.
- Request visibility into the supplier’s own supply chain risk management processes: to identify potential fourth-party vulnerabilities.
9. Review Performance against Security KPIs
- Establish clear Key Performance Indicators (KPIs) for security within the service level agreement: such as patch management timelines.
- Schedule periodic compliance reviews to assess the supplier against these metrics: identifying areas for improvement.
- Document any non-conformities and track the completion of corrective actions: ensuring continuous security improvement.
10. Formalise Secure Termination and Exit Procedures
- Define the protocols for the secure return or certified destruction of data: at the end of the contract term.
- Specify the requirement for the supplier to revoke all logical and physical access: immediately upon termination.
- Maintain a post-contract checklist to verify that all organisational assets have been recovered: and risks are fully closed off.
Contract Clause Checklist
| Clause | Purpose | Why it matters? |
| Right to Audit | Allows you (or a 3rd party) to check their security. | Critical for “High Risk” vendors. |
| Incident Notification | “Must notify us within 72 hours of a breach.” | Required for your own GDPR compliance. |
| Data Return/Delete | “Must delete our data upon termination.” | Prevents data leakage after the contract ends. |
| Sub-processing | “Cannot outsource to others without permission.” | Stops them sending your data to a cheap, insecure 4th party. |
| SLA (Security) | “Must maintain 99.9% uptime & patch within 30 days.” | Turns “best effort” into a legal requirement. |
ISO 27001 Supplier Register Template
The ultimate ISO 27001 Supplier Register Template.
ISO 27001 Supplier Policy Template
The ultimate ISO 27001 Supplier Register Template.
How to comply
To comply with ISO 27001 Annex A 5.20 you are going to implement the ‘how’ to the ‘what’ the control is expecting. In short measure you are going to
- Implement a topic specific policy
- Implement an supplier management process
- Implement an ISO 27001 supplier register
- Have agreements with all suppliers that cover information security requirements
How to audit ISO 27001 Annex A 5.20
Auditing ISO 27001 Annex A 5.20 ensures that your organisation has legally enforceable security controls embedded within all third-party contracts. As a Lead Auditor, I look for evidence that security is not just a “handshake” agreement, but a formalised set of obligations that protect your data throughout the supplier lifecycle. This audit process verifies that your agreements mitigate supply chain risks and provide the necessary “right to audit” for continuous compliance.
1. Inspect the Supplier Asset Register
- Verify that all third-party suppliers are documented within a central Asset Register: ensuring full visibility of the supply chain.
- Confirm that each supplier has been assigned a risk tier based on data sensitivity: resulting in proportional security requirements.
- Check for a designated internal owner for each supplier relationship: establishing clear accountability for contract oversight.
2. Validate Contractual Security Clauses
- Review a sample of active contracts to confirm the presence of baseline security requirements: ensuring obligations are legally binding.
- Check for specific mandates regarding the protection of organisational information: resulting in a formalised security perimeter.
- Ensure that all agreements align with the internal Information Security Management System (ISMS) policies: avoiding compliance gaps.
3. Audit Data Protection and UK GDPR Obligations
- Verify that Data Processing Agreements (DPAs) are in place for all suppliers handling personal data: ensuring legal compliance with UK GDPR.
- Confirm that encryption standards for data at rest and in transit are explicitly defined: resulting in technical data protection.
- Inspect clauses regarding geographic data residency: ensuring data does not move to unauthorised jurisdictions without approval.
4. Verify Access Management and IAM Requirements
- Confirm that contracts mandate the Principle of Least Privilege (PoLP) for all supplier accounts: limiting potential attack surfaces.
- Audit the requirement for Multi-Factor Authentication (MFA) for remote or privileged access: ensuring robust identity verification.
- Check for clauses requiring immediate notification of supplier personnel changes: allowing for the rapid revocation of access rights.
5. Confirm Right to Audit and Assurance Clauses
- Ensure every critical supplier agreement includes an explicit “Right to Audit” clause: providing the legal authority to conduct inspections.
- Verify that suppliers are required to provide independent assurance reports, such as SOC 2 or ISO 27001 certificates: resulting in third-party validation.
- Check that the frequency and scope of audits are defined: ensuring the organisation can monitor performance without legal friction.
6. Inspect Rules of Engagement (ROE) for Technical Testing
- Validate that agreements define the boundaries for vulnerability scans and penetration testing: ensuring no operational disruption.
- Confirm that the process for reporting discovered technical weaknesses is documented: resulting in an established remediation path.
- Check for indemnification clauses related to authorised security testing: protecting the organisation from liability.
7. Assess Incident Reporting and Notification Timelines
- Verify that contracts specify mandatory breach notification windows: ensuring the organisation meets regulatory reporting deadlines.
- Confirm that suppliers are obligated to provide root cause analysis following an incident: resulting in improved supply chain resilience.
- Inspect the escalation paths for security events: ensuring 24/7 communication readiness between parties.
8. Audit Supply Chain Flow-Down Requirements
- Confirm that primary suppliers are contractually required to flow down security standards to their sub-contractors: mitigating fourth-party risk.
- Verify that the supplier assumes liability for the security posture of their own vendors: resulting in a secured end-to-end chain.
- Request evidence that the supplier conducts their own due diligence on sub-processors: ensuring a consistent level of trust.
9. Validate Business Continuity and Resilience Standards
- Check that agreements specify requirements for Business Continuity (BC) and Disaster Recovery (DR) testing: ensuring service uptime.
- Confirm that Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) are defined: resulting in predictable service restoration.
- Inspect clauses regarding the availability of backups: ensuring data remains accessible during a supplier-side failure.
10. Review Secure Termination and Exit Protocols
- Verify that contracts mandate the certified destruction or secure return of organisational data at the end of the term: closing the risk loop.
- Confirm that the revocation of all physical and logical access is a post-termination requirement: resulting in a clean exit.
- Inspect the requirement for a final compliance declaration from the supplier: providing evidence that all assets have been returned.
The Tools We Use.
100% Audit Success. Zero AI Guesswork.
How to pass the ISO 27001 Annex A 5.20 audit
To pass an audit of ISO 27001 Annex A 5.20 you are going to make sure that you have followed the steps above in how to comply.
What the auditor will check
The audit is going to check a number of areas. Lets go through the most common
1. That you have a supplier agreements in place
The auditor is going to check that you have agreements in place with suppliers that cover the information security requriements. It will check that those agreements are in date and cover the products and / or services acquired.
2. That you have an ISO 27001 Supplier Register
You will need an ISO 27001 Supplier Register to record and manage your suppliers. Make sure it is up to date and reflects your reality.
3. Documentation
They are going to look at audit trails and all your documentation and see that is classified and labelled. All the documents that you show them, as a minimum if they are confidential should be labelled as such. Is the document up to date. Has it been reviewed in the last 12 months. Does the version control match.
Top 3 ISO 27001 Annex A 5.20 Mistakes People Make and How to Avoid Them
The top 3 Mistakes People Make For ISO 27001 Annex A 5.20 are
1. You have no contracts or legal terms with a supplier
Make sure that there is a contract, agreement, terms of business or some legal mechanism for engaging with suppliers and you have a copy, it is in date and covers what you are using.
2. You have no assurance they are doing the right thing for information security
Make sure you have done your security assessment and can place your hands on an in date certificate such as an ISO 27001 Certification for assurance they are doing the right thing. It needs to be in date a cover the products and / or services you have acquired and are using form the supplier.
3. Your document and version control is wrong
Keeping your document version control up to date, making sure that version numbers match where used, having a review evidenced in the last 12 months, having documents that have no comments in are all good practices.
Applicability of ISO 27001 Annex A 5.20 across different business models.
| Business Type | Applicability & Interpretation | Examples of Control |
|---|---|---|
| Small Businesses |
Standard Terms & NDAs. You cannot renegotiate contracts with giants (Microsoft/Google), but you must understand them. For local suppliers (IT support, cleaners), you need explicit confidentiality agreements. |
• The “NDA” Check: Ensuring every external contractor (e.g., the accountant or IT fix-it person) has signed a Non-Disclosure Agreement before accessing your systems. • Reviewing T&Cs: Reading the “Data Backup” clause in your ISP contract to confirm they are not liable for data loss, prompting you to arrange your own backups. |
| Tech Startups |
“Right to Audit” & Code IP. When outsourcing development, the contract must define who owns the code and who is responsible for fixing bugs. Crucially, you must reserve the legal right to test their security. |
• Right to Audit Clause: Including a contractual clause that allows you to perform penetration testing on the software delivered by your development agency. • SLA Definitions: Defining strict “Incident Notification” times in the contract (e.g., “Supplier must notify us of a breach within 24 hours”). |
| AI Companies |
Data Usage & Model Rights. The agreement must explicitly state whether the supplier can use your data to train their models. Ambiguity here can lead to IP leakage. |
• Zero-Training Clause: A specific legal term in API agreements (e.g., with OpenAI or Anthropic) stating that inputs will not be used for model improvement. • Liability Cap: Negotiating terms regarding liability for “Hallucinations” or errors if the supplier’s model output causes downstream harm to your clients. |
Fast Track ISO 27001 Annex A 5.20 Compliance with the ISO 27001 Toolkit
For ISO 27001 Annex A 5.20 (Addressing information security within supplier agreements), the requirement is to ensure that information security requirements are established and agreed upon with each supplier that processes, stores, or accesses the organization’s information. This control is about making security expectations legally binding.
| Compliance Factor | SaaS Compliance Platforms | High Table ISO 27001 Toolkit | Audit Evidence Example |
|---|---|---|---|
| Legal Ownership | Rents access to your legal templates; if you cancel the subscription, your documented security schedules and clauses vanish. | Permanent Assets: Fully editable Word templates for Supplier Security Clauses that you own forever. | A signed Master Service Agreement (MSA) featuring your proprietary “Right to Audit” security clause. |
| Contractual Utility | Attempts to “automate” reviews via generic dashboards that cannot negotiate custom clauses or interpret local case law. | Governance-First: Provides the specific legal language needed to bake security into your existing procurement workflows. | A “Supplier Security Schedule” proving that data breach notification timelines are legally mandated for all vendors. |
| Cost Efficiency | Charges a “Contract Volume Tax” that scales aggressively as your vendor list and agreement count grows. | One-Off Fee: A single payment covers your legal governance for 5 supplier agreements or 500. | Allocating budget to specialized legal counsel for complex negotiations rather than monthly “dashboard” fees. |
| Legal Freedom | Mandates rigid workflows and metadata that may not align with specialized industry requirements like HIPAA or PCI-DSS. | 100% Agnostic: Templates are fully customizable to match your unique business model and jurisdictional laws. | The ability to evolve your legal strategy and update liability caps without reconfiguring a rigid SaaS compliance module. |
Summary: For Annex A 5.20, the auditor wants to see that your supplier contracts explicitly include information security requirements. The High Table ISO 27001 Toolkit provides the legal governance framework to satisfy this requirement immediately. It is the most direct, cost-effective way to achieve compliance using permanent documentation that you own and control.
ISO 27001 annex A 5.20 Applicable Laws and Related Standards
| Standard / Law | Relevant Section / Requirement | Mapping & Compliance Logic |
|---|---|---|
| NIST CSF v2.0 | GV.SC-06 (Supply Chain Risk Management) | NIST mandates that contracts with suppliers include specific security requirements: including obligations for risk mitigation and performance monitoring. |
| DORA (EU) | Article 30 (Contractual Provisions) | DORA provides a highly prescriptive list of what MUST be in ICT contracts: including full service descriptions, locations of data processing, and “Right to Audit” clauses. |
| NIS2 (EU) | Article 21 (Supply Chain Security) | Requires organisations to address vulnerabilities in the supply chain through contractual enforcement of security risk management measures. |
| SOC 2 (Trust Services) | CC9.2 (Vendor Management) | Focuses on whether security commitments and requirements are communicated to and agreed upon by third-party providers via formal agreements. |
| GDPR / UK GDPR | Article 28 (Processor Contracts) | Mandates a legally binding Data Processing Agreement (DPA) that specifies the subject matter, duration, and nature of data processing. |
| UK Data (Use & Access) Act 2025 | Part 1 (Trusted Data Flows) | Requires that contractual “high security thresholds” are maintained to benefit from reduced administrative burdens for data transfers. |
| UK Cyber Security & Resilience Bill | MSP Regulation Section | Expands mandatory reporting to MSPs: contracts must now include clauses for immediate incident notification to comply with the UK’s answer to NIS2. |
| CIRCIA (USA) | 72-Hour Reporting Mandate | For critical infrastructure: contracts with ICT suppliers must legally enforce a 72-hour notification window so the entity can meet federal reporting obligations. |
| EU AI Act | Article 16 (Provider Obligations) | Requires contracts with AI data providers to specify data quality, bias mitigation protocols, and technical transparency requirements. |
| ISO/IEC 42001:2023 | Control 8.5 (AI Supply Chain) | Directly leverages A 5.20 to ensure AI-specific risks: such as model transparency and training data integrity: are codified in agreements. |
| EU PLD (Product Liability Directive) | Cybersecurity Liability Update | Extends strict liability to software: contracts must now include indemnity and “duty of care” clauses regarding the remediation of cybersecurity flaws. |
| ECCF (European Cybersecurity Framework) | Harmonised Security Labels | Agreements will increasingly require suppliers to maintain specific EU security labels as a contractual prerequisite for service delivery. |
| HIPAA (USA) | § 164.308(b) (Business Associates) | Requires a Business Associate Agreement (BAA) that contractually obligates third parties to protect Protected Health Information (PHI). |
| CCPA / CPRA (California) | § 1798.140 (Service Provider Terms) | Mandates specific contractual language prohibiting service providers from “selling” or “sharing” personal information outside the direct relationship. |
The “SaaS Giant” Trap: Handling Non-Negotiable Terms
You cannot call up Amazon or Microsoft and ask them to sign your custom Security Addendum. If you try to tell an auditor you have “agreed” security terms with them via a custom contract, I will know you are lying. For these giants, your Annex A 5.20 compliance is about due diligence and documented acceptance.
Compliance Action: For non-negotiable suppliers, your “agreement” consists of their standard Online Service Terms (OST) and Data Protection Addendum (DPA). You must download these, review them against your risk assessment, and file them in your Supplier Register. If their terms do not meet your internal requirements (for example, if they only offer a 30 day backup and you need 90), you must document this as a Risk Acceptance signed by your CISO.
The 2026 AI Clauses: Guarding the Model
If your supplier provides AI services or uses AI to process your data, your standard 2022 clauses are out of date. In 2026, I am looking for specific legal “hooks” regarding Model Integrity and Data Sovereignty.
- The “No-Training” Guarantee: Explicitly state that the supplier has no right to use your inputs or data to train their foundational models.
- Algorithm Transparency: For high risk AI, include a clause that requires the supplier to disclose significant changes to the model that might affect the accuracy or security of the output.
- Hallucination Liability: Define who is legally responsible if the supplier’s AI provides incorrect or “hallucinated” information that leads to a security event.
The “Toothless” Clause: Liability and Indemnity
I often see beautiful security clauses followed by a “Limitation of Liability” clause that caps damages at the cost of one month’s subscription. If a supplier loses all your customer data and they only owe you fifty pounds, your security clause has no teeth.
Stuart’s Pro Tip: As an auditor, I look for Super-Caps. Your contract should have a standard liability cap for general issues, but a much higher “Super-Cap” (or unlimited liability) for breaches of confidentiality and data protection. This proves to me that the supplier is actually incentivized to follow your security requirements.
The 4th Party Problem: Sub-processing Control
Your contract is with Supplier A, but Supplier A uses Supplier B to host the data. If Supplier B is insecure, you are the one who fails the audit. Annex A 5.20 requires you to control this chain.
Compliance Action: Your agreement must mandate that the supplier cannot change or add a Sub-processor without your prior written consent. At the very least, they must provide a “Notice and Object” period. If they can move your data to a new sub-contractor without telling you, you have lost control of your security perimeter.
The Escrow Anchor: Protecting Availability
If you rely on a small, niche supplier for a critical business function, the best security contract in the world is useless if they go bankrupt tomorrow. To satisfy the Availability requirement of ISO 27001, you should consider Software Escrow.
Audit Evidence: For Tier 1 software vendors, show the auditor a clause that requires the supplier to deposit their source code with an independent third party. If the vendor vanishes, you get the code. Without this, your “Business Continuity” plan for that supplier is just a wish.
Personnel Security: The “Human” Flow-down
Does your contract require the supplier to conduct Background Checks on the staff who will be looking at your data? If your internal policy (Annex A 6.3) requires a DBS check for all staff, but your supplier is allowed to use un-vetted contractors, you have a massive compliance gap. The agreement must mandate that the supplier’s personnel security matches your own internal standards.
The Certification Maintenance Clause
I often see contracts that require a supplier to be ISO 27001 certified at the start of the deal. But what happens if they fail their re-certification audit six months later? If your contract does not address this, you are stuck with an uncertified, high risk vendor.
Compliance Action: Include a clause that mandates the supplier maintains their specified certifications (ISO 27001, SOC 2, PCI DSS) for the entire duration of the agreement. Crucially, specify that any lapse in certification or a “Qualified” audit opinion must be reported to you within 30 days and may be treated as a material breach of contract.
Defining the Evidence Format
The “Right to Audit” is useless if the supplier sends you 5,000 pages of unredacted logs that you cannot process. To satisfy Annex A 5.22 (Monitoring and Review), the contract in 5.20 must specify what evidence looks like.
- SOC 2 Bridge Letters: If they provide a SOC 2 report, they must contractually agree to provide a “Bridge Letter” covering the gap between the report date and your audit date.
- Redacted Penetration Tests: Mandate that they provide an executive summary of their annual third party penetration test, including proof that “Critical” and “High” findings have been remediated.
- Self Assessments: For Tier 2 suppliers, mandate that they complete your specific Security Questionnaire annually.
The Security Liaison and 24/7 Contact
If a breach happens at 2:00 AM on a Saturday, you do not want to be calling a general sales number. Your agreement should define the Communication Path for security matters.
Compliance Action: The contract should require the supplier to nominate a Security Liaison or a Data Protection Officer (DPO). It must also include a 24/7 emergency contact number or an automated alerting mechanism for high priority security incidents. I will check your contract to see if these contact details are actually there or if they are just generic placeholders.
Jurisdictional Law for Security Disputes
This is a major issue for global supply chains. If you are in the UK and your supplier is in the US, whose law applies when a data breach occurs? Jurisdictional conflicts can delay your incident response and legal recovery for years.
Stuart’s Pro Tip: Ensure the Governing Law and Jurisdiction clauses align with where your data is actually stored. If the data is in London, you want UK law to apply. If the supplier insists on their local law, you must document this as a specific legal risk in your Risk Register.
Zero Day Patching Obligations
Standard contracts often say “we patch regularly.” In 2026, that is not good enough. When a major Zero Day vulnerability (like a new Log4j) hits the news, you need to know your supplier is on it immediately.
Compliance Action: Include a Vulnerability Response clause. This should mandate that for any vulnerability with a CVSS score of 9.0 or higher, the supplier must provide an initial assessment within 24 hours and a mitigation plan or patch within 72 hours. This turns a generic “best effort” into a hard, auditable deadline.
The Golden Thread: Linking to the Risk Register
Finally, the most important thing I look for is the connection between the contract and your Risk Assessment (Clause 6.1.2). If your Risk Register says “Supplier Data Loss” is a high risk, I want to see a specific clause in the contract that directly addresses that risk (e.g. an enhanced indemnity or a specific encryption requirement).
Compliance Action: For every Tier 1 supplier, keep a simple mapping document. “Risk ID #42 is mitigated by Clause 12.4 in the Supplier Agreement.” This is the “Golden Thread” of compliance that makes a Lead Auditor very happy.
Change Management: The Contractual Veto
One of the biggest risks in a long term supplier relationship is Change. A supplier might decide to move your data to a cheaper, less secure data center or switch to a new sub-processor without telling you. If your contract only covers the security on the day you signed, you have a gap.
Compliance Action: Your agreement must include a Change Management Clause. This requires the supplier to notify you in advance of any significant changes to their service, location, or security controls. Crucially, it must give you the legal right to object to the change or terminate the contract if the change increases your risk beyond your appetite.
Unacceptable Use: Defining the Boundaries
Most contracts focus on what the supplier should do. ISO 27001 requires you to define what is unacceptable. If a supplier has access to your systems, you must contractually prohibit certain behaviors to prevent them from becoming an accidental or malicious insider threat.
- No Unauthorized Testing: Prohibit the supplier from running their own vulnerability scans or “stress tests” on your production environment without prior written approval.
- No Data Scraping: Explicitly forbid the use of automated tools to scrape your data for purposes outside the scope of the service.
- Credential Sharing: Mandate that supplier personnel use unique, named accounts and never share credentials.
Intellectual Property and Data Ownership
This is a major focus for auditors in 2026, especially regarding AI and outsourced development. The agreement must state, in no uncertain terms, that you own the data and any derivative insights or models created from that data. Without this, a supplier might claim that the “learned patterns” from your data belong to them, which is a significant loss of organizational value and a confidentiality risk.
Cyber Insurance Mandates
A security clause is only as good as the supplier’s ability to pay for a mistake. If a Tier 1 supplier causes a breach that costs you millions, but they have no assets, you are left holding the bill. To satisfy the risk treatment requirements of ISO 27001, your agreements should mandate that the supplier maintains a specific level of Cyber Liability Insurance.
Audit Evidence: I will ask to see the Certificate of Insurance from your top three critical suppliers. If they don’t have insurance, I will look for a Risk Acceptance on your side explaining why you are comfortable with that financial exposure.
Secure Development: If They Write Code
If your supplier is a dev agency or providing bespoke software, your contract must reference Annex A 8.25 (Secure Development). You cannot just hope they are writing secure code. The agreement should mandate that they follow a recognized secure coding standard (like OWASP) and provide evidence of Static and Dynamic Analysis before any code is deployed to your environment.
Personnel Vetting: The Trust Anchor
Your contract must force the supplier to meet your own standards for Human Resources Security. If your staff require a background check (Annex A 6.3), then the supplier’s staff who access your data must undergo the same level of vetting. I want to see a clause that requires the supplier to verify the identity and integrity of any employee they assign to your account.
Stuart’s Pro Tip: Do not just accept a “we do background checks” statement. Ask for the Vetting Policy of your Tier 1 suppliers. If their policy is weak, your “Legal Shield” is cracked.
Defining AI Roles: Provider vs Deployer
Under the EU AI Act and ISO 42001, you must define your role and the supplier’s role in the agreement. Are you the Deployer of a system built by a Provider, or are you a Provider using a third party model? If your contract does not explicitly define these roles, you are legally exposed when things go wrong.
Compliance Action: Your agreement must state who is responsible for the conformity assessment and the technical documentation required by regulators. If you are the deployer, the contract must mandate that the supplier provides you with all the necessary technical information to meet your own compliance obligations.
The “Zero Training” Guarantee: Protecting Your IP
The biggest risk in 2026 is that your data is used to train a supplier’s public AI model. If you upload sensitive code or customer data to an AI tool, and that tool is allowed to “learn” from it, you have suffered a major confidentiality breach. A standard data protection clause is not enough here.
- The No-Training Clause: Explicitly state that the supplier has no right to use your inputs, data, or outputs to train or improve their foundational models.
- Opt Out Confirmation: For “Big Tech” AI providers, the contract must reference the specific Enterprise or Zero Retention settings you have enabled. I will ask to see the evidence that this opt out is legally binding in your specific agreement.
Model Integrity and “Hallucination” Liability
If a supplier’s AI provides dangerously incorrect information (a hallucination) that leads to a security event or financial loss, who pays? In 2026, I want to see how you have allocated the risk of AI failure in your contracts.
Stuart’s Pro Tip: Ensure your agreement includes a Model Transparency clause. This requires the supplier to notify you of significant updates to the model architecture that could change the accuracy or reliability of the output. If the model changes and starts producing garbage, you need the legal right to suspend the service immediately.
Data Poisoning and Annotation Security
If you use a third party service for data labelling or annotation, you are at risk of Data Poisoning. If an attacker at the supplier end intentionally mislabels data, they can corrupt your model from the inside. Your contract with annotation suppliers must include:
- Personnel Vetting: Mandate that the people doing the labelling have undergone background checks.
- Quality Assurance SLAs: Contractual requirements for the accuracy of the labels, with penalties if the error rate exceeds a specific threshold.
- Provenance Logs: The legal right to see the audit trail of who touched which data point and when.
The AI “Right to Audit”
Traditional auditing does not work for AI models. You cannot just “look at the code” to see why a model made a specific decision. Your Annex A 5.20 agreement must include an Algorithmic Audit clause for Tier 1 AI suppliers. This allows you to request the results of their internal bias testing, red teaming exercises, and safety evaluations.
Audit Evidence: I will look for your latest AI Impact Assessment (as required by the EU AI Act) and check that the contractual terms with your AI supplier provide the data points needed to complete that assessment.
ISO 42001 Certification as a Pre-requisite
In 2026, I strongly recommend that your contracts for critical AI services mandate that the supplier maintains an ISO 42001 (AI Management System) certification. Just like ISO 27001 proves they are secure, ISO 42001 proves they are managing the unique ethical and technical risks of AI. If they do not have it, you should increase the frequency of your internal audits of that vendor.
The Chain of Trust: 4th Party Management
Your contract is with your supplier, but your risk often sits with their supplier. This is the 4th Party problem. Most agreements say “the supplier is responsible for their sub-contractors,” but as an auditor, I want to see how you legally enforce that. In 2026, the standard for a Tier 1 contract is much higher.
- The Pre-Approval Clause: The supplier must be contractually forbidden from adding a new sub-processor without your prior written consent. A generic notification is not enough; you must have a 30 day window to object and terminate if that sub-processor does not meet your security standards.
- Flow Down Assurance: The agreement must mandate that the supplier conducts an annual security audit of their own critical sub-contractors and provides you with the summary. If they cannot prove their chain is secure, yours isn’t either.
Exit Strategy vs Service Portability: The “Plan B” Hook
Many contracts mention data deletion at the end of the term (Annex A 8.10), but they forget about Service Portability. If your critical cloud provider goes offline or you need to leave them, getting a dump of raw data in a proprietary format is useless. You need the legal right to Portability.
Compliance Action: Include a clause that mandates the supplier provides your data in a common, structured, and machine readable format (like CSV or JSON) and requires them to provide “transition assistance” for a set period (e.g. 90 days) after termination. Without this, your Exit Strategy is just a document with no power to execute.
The Regulatory Bridge: DORA and NIS2 Clauses
If you are in the financial sector or an essential service, your Annex A 5.20 agreement is the primary tool for meeting DORA Article 30 or NIS2 Article 21. In 2026, I look for these specific “Regulatory Hooks”:
- Full Service Description: The contract must define not just the software, but the specific locations where data is processed and the specific security functions the supplier performs.
- Unrestricted Audit Rights: For DORA compliance, the Right to Audit cannot be limited to “once a year.” It must allow for audits at any time if a risk or incident is identified.
- Vulnerability Disclosure: Mandate that the supplier must disclose any zero day vulnerabilities in their product to you within 24 hours of discovery, even if they have not yet been exploited.
Data Residency and the Sovereign Cloud
Data residency is no longer just about “EU vs US.” In 2026, many clients require Digital Sovereignty. Your agreements must be explicit about where the data sits and, more importantly, who can see it.
Stuart’s Pro Tip: Look for the Foreign Access Clause. Your contract should prohibit the supplier from allowing access to your data by their staff in high risk jurisdictions, even for support purposes, without your explicit, per instance approval. If a support engineer in a sanctioned country logs into your database to “fix a bug,” that is a major security event.
The Golden Thread: Risk to Clause Mapping
The ultimate sign of a mature ISO 27001 system is the Golden Thread. I want to see that your contract clauses are not just boilerplate, but are direct responses to your Risk Assessment (Clause 6.1.2).
Compliance Action: In your Supplier Register, add a column for Mitigating Clause. If your risk assessment says “Unauthorized data access is a high risk,” you should link that directly to the Encryption and MFA clauses in the specific supplier agreement. This proves to me that your ISMS is a living, breathing system, not just a folder full of signed papers.
AI and the “Human in the Loop” Clause
Finally, for any AI enabled supplier, the contract must define the Human Oversight requirements. If the supplier uses AI for security monitoring or automated decision making, the agreement must specify that a qualified human reviews the high risk outputs. You are contractually agreeing that a machine will not be the final authority on your security posture.
ISO 27001 Annex A 5.20 FAQ
What is ISO 27001 Annex A 5.20?
ISO 27001 Annex A 5.20 is an information security control that requires organisations to formalise and document security requirements within legal agreements with all suppliers who access or process company data.
- It ensures that security expectations are legally binding and enforceable.
- It covers the entire lifecycle of the relationship, from onboarding to decommissioning.
- It reduces third-party risk by establishing clear boundaries of responsibility.
What must be included in a supplier security agreement?
To comply with Annex A 5.20, supplier agreements must include specific clauses that define how the provider will protect the confidentiality, integrity, and availability of your data.
- Right to Audit: The legal right for your organisation (or a third party) to verify the supplier’s security controls.
- Incident Reporting: Mandatory timeframes for the supplier to notify you of a security breach.
- Data Protection: Explicit requirements for encryption, access controls, and data residency.
- Return of Assets: Procedures for the secure return or destruction of data upon contract termination.
What is the difference between Annex A 5.19 and 5.20?
The primary difference is that Annex A 5.19 establishes the overarching policy for supplier relationships, whereas Annex A 5.20 focuses on the technical and legal clauses within the contracts themselves.
- Annex A 5.19: Strategic “what” and “why” of vendor management.
- Annex A 5.20: Operational “how” via legally binding contract language.
- Relationship: You use the policy (5.19) to dictate the requirements found in the agreement (5.20).
Does a standard NDA satisfy Annex A 5.20?
No, a Non-Disclosure Agreement (NDA) alone does not satisfy the requirements of Annex A 5.20 because it only addresses confidentiality, not integrity or availability.
- NDAs lack operational security requirements like patch management or physical security.
- NDAs do not typically include “Right to Audit” or specific incident management obligations.
- A 5.20 requires a broader Data Processing Agreement (DPA) or a Security Addendum.
How do you handle security for SaaS providers with non-negotiable contracts?
For large SaaS providers (e.g. Microsoft, AWS), you must assess their standard Terms of Service and independent audit reports (SOC 2 or ISO 27001) against your internal requirements.
- Review their standard Security Addendums to ensure they meet your minimum thresholds.
- Document the risk of non-negotiable terms in your Risk Register.
- Verify the scope of their certifications to ensure it covers the specific services you use.
What evidence do auditors expect for Annex A 5.20?
Auditors expect to see a sample of signed supplier contracts or security addendums that explicitly list the security obligations identified in your risk assessment.
- A Supplier Register: Mapping suppliers to their risk levels and contract status.
- Signed Agreements: Validating that security clauses were actually included and executed.
- Evidence of Review: Proof that you reviewed the supplier’s security posture before signing.
Related ISO 27001 Controls and Further Reading
| Related ISO 27001 Control | Relationship Description |
|---|---|
| How to Implement ISO 27001 Annex A 5.20 | This is the practical, boots on the ground manual for 5.20. It takes the legal requirements of the control and breaks them down into actionable steps for your procurement and legal teams. |
| ISO 27001 Annex A 5.20 Audit Checklist | I use this checklist during a formal assessment to verify that your contracts aren’t just templates, but actually contain the specific security anchors required for compliance. |
| ISO 27001 Annex A 5.19 Supplier Relationships | Control 5.19 is the “Parent” control to 5.20. It sets the high-level policy and risk framework, while 5.20 provides the specific contractual mechanisms to enforce that policy. |
| ISO 27001 Annex A 5.21 ICT Supply Chain | This control focuses on the deeper technical supply chain (hardware and software). It relies on the 5.20 agreement to legally enforce security requirements down to sub-contractors and vendors. |
| ISO 27001 Annex A 5.22 Monitoring and Review | Without 5.20, you have no right to monitor. This page explains how you use the “Right to Audit” clause established in your agreement to perform ongoing security reviews. |
| ISO 27001 Annex A 5.23 Cloud Services | Cloud agreements are a specialised subset of 5.20. This page highlights how cloud-specific terms (like shared responsibility) must be integrated into your standard supplier contracts. |
| ISO 27001 Supplier Policy Template | This is the foundational document that defines what your contracts must contain. It serves as the governing framework that 5.20 agreements are built upon. |
ISO 27001 Supplier Security Policy Beginner’s Guide
ISO 27001 controls and attribute values
| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains |
|---|---|---|---|---|
| Preventive | Confidentiality | Identify | Supplier relationships security | Protection |
| Integrity | Governance and ecosystem | |||
| Availability |
About the author
