ISO 27001 Annex A 5.20 Addressing Information Security Within Supplier Agreements Explained

ISO 27001 Addressing Information Security Within Supplier Agreements

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 means you need legal agreements in place with suppliers that cover your information security requirements.

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.

Key Takeaways

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 organisation’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.

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.

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

Explanation

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.

Requirement

• 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

1. Contractual Sampling: “Show me the signed agreement for your cloud hosting provider. Where does it state their requirement to notify you of a breach?”
2. Consistency Check: “Does your standard Data Processing Agreement (DPA) match the security requirements defined in your Risk Assessment?”
3. Exit Clauses: “What happens to your data if this supplier goes bankrupt? Show me the ‘Return of Assets’ clause in their contract.”

FREE Training Video

In this free training video you will learn How to implement ISO 27001 Information Security Within Supplier Agreements (Annex A 5.20).

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.

Supplier Security Policy Template

The supplier policy sets out your approach to information security of suppliers and contracts and agreements.

Supplier Register Template

The supplier register is a record of all your suppliers and is used to manage them.

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.

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.

How to pass the 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 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 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.

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.

FAQ

Related ISO 27001 Controls and Further Reading

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