When a supplier with privileged access to your network gets breached, the first question your incident response team asks is not “what happened?” — it’s “what were they contractually required to do about it?” If the answer is nothing, because the agreement never addressed information security, you have no notification timeline, no right to audit, and no leverage to force remediation. Control 5.20 exists to prevent exactly that gap.
What 5.20 Requires
ISO 27001 control 5.20 requires your organization to establish formal, documented agreements with every supplier that explicitly define information security requirements, service levels, and compliance obligations. The scope is broad: any supplier that accesses, processes, stores, communicates, or provides IT infrastructure components for your information falls under this control.
The operative word is “explicit.” A generic confidentiality clause buried in a master services agreement does not satisfy 5.20. You need security requirements that are specific to the relationship — proportionate to the sensitivity of the data involved, the level of access granted, and the criticality of the service. A cloud hosting provider processing customer PII needs materially different contractual security obligations than an office supplies vendor.
These agreements must also address the full supplier lifecycle, a core element of ISO 27001 third-party risk requirements. Onboarding clauses define initial security expectations. Operational clauses cover incident notification, vulnerability management, and subcontractor controls. Termination clauses mandate secure data return or destruction and access revocation. The control forces you to think about supplier security not as a checkbox at contract signing, but as an ongoing obligation that evolves with the relationship.
Why 5.20 Matters
Organizations that fail to implement this control often discover the consequences during an incident, not before one. In a common pattern, a managed service provider with broad network access experiences a ransomware attack. The provider has no contractual obligation to notify you within a specific timeframe — so you learn about the compromise weeks later, after attackers have already moved laterally into your environment through the supplier’s access. Without a right-to-audit clause, you cannot independently verify the provider’s claim that “no customer data was affected.” Without termination provisions, you cannot force data deletion from their compromised systems.
The IBM Cost of a Data Breach Report 2025 found that third-party breaches doubled year-over-year, now accounting for 30% of all incidents and costing an average of $4.91 million per breach — significantly above the global average.
Supply chain risk compounds because a single weak agreement can create exposure across your entire organization. Understanding third-party risk at this structural level is essential before addressing it contractually. The risk class here is systemic: it is not a single vulnerability, but a structural gap in how you transfer trust to external parties.
What attackers exploit
- No incident notification timeline — breaches at the supplier go unreported for weeks or months, giving attackers time to pivot into your environment
- Missing right-to-audit clauses — you cannot verify supplier security claims or investigate incidents independently
- No subcontractor flow-down requirements — the supplier outsources to a fourth party with no security obligations, and that fourth party becomes the entry point
- Absent data handling restrictions — supplier personnel access data well beyond the scope of the engagement, expanding the blast radius of any compromise
- No vulnerability management obligations — unpatched software in the supplier’s environment becomes your attack surface
- Missing termination provisions — after the contract ends, your data lingers on the supplier’s systems with no deletion mandate or verification mechanism
How to Implement 5.20
Implementing 5.20 is less about writing one perfect contract template and more about building a repeatable process that scales across your supplier portfolio.
For your organization (first-party)
1. Classify suppliers by risk tier. Not every supplier relationship carries the same risk. Tier your suppliers based on the sensitivity of data they handle, the level of access they have, and the criticality of their service to your operations. A SaaS provider processing customer data is tier 1. A marketing agency with access to your CMS is tier 2. A facilities vendor with no data access may require only baseline terms.
2. Build a standard security schedule template. Create a modular contract addendum that can be adapted per tier. The schedule should cover: data handling and classification requirements, incident notification timelines (specify hours, not vague “promptly” language), right-to-audit provisions, subcontractor flow-down obligations, vulnerability management and patching responsibilities, and secure data return or destruction at termination.
3. Maintain a supplier register. This register links every active supplier to their agreement, risk tier, data access scope, last assessment date, and review status. Without it, you cannot demonstrate to an auditor that you know who your suppliers are and what agreements govern them.
4. Establish a review cadence. High-risk suppliers should be reviewed at least annually. Reviews should verify that agreements remain current, that the supplier’s security posture has not materially degraded, and that any scope changes are reflected in updated contractual terms.
5. Produce the evidence trail. Every step above generates audit artifacts: signed agreements, the supplier register, assessment records, and review meeting minutes. These are not byproducts — they are the primary evidence an auditor evaluates.
Common mistakes:
- Using a generic NDA as a substitute for specific security clauses — NDAs protect confidentiality but do not address incident response, access controls, or vulnerability management
- Applying an identical agreement template to every supplier regardless of risk — this either over-burdens low-risk vendors or under-protects high-risk relationships
- Failing to update agreements when the supplier’s scope of access changes — the contract no longer reflects reality
- Omitting subcontractor flow-down requirements — your supplier meets your standards, but their sub-processor does not
- Treating the agreement as a one-time onboarding exercise rather than a living document tied to periodic review
For your vendors (third-party assessment)
When assessing whether a supplier can meet your 5.20 requirements, focus your security questionnaire on the areas that matter most: data handling practices, access control models, incident management procedures, subcontractor policies, business continuity planning, and encryption standards for data at rest and in transit.
Request hard evidence, not just policy documents. A thorough vendor risk assessment goes beyond self-attestation. An ISO 27001 certificate demonstrates a management system is in place. A SOC 2 Type II report verifies that controls operated effectively over a period. A penetration test executive summary shows whether the supplier tests their own defenses. A data processing agreement formalizes GDPR or privacy obligations. An ISO 27001 vendor questionnaire template can standardize this evidence collection process.
Red flags in vendor responses that should trigger deeper investigation:
- The supplier refuses to include a right-to-audit clause or will not share independent audit reports
- There is no documented incident response plan, or the supplier cannot articulate notification timelines
- The supplier cannot identify their sub-processors or claims they do not use any
- Security responsibilities are described in vague terms like “best efforts” or “commercially reasonable” without defined controls
- The supplier has never undergone a third-party security assessment
Verification beyond self-attestation is critical. Independent audit reports (SOC 2, ISO 27001) provide assurance that controls are not just documented but operational. On-site or remote assessments let you validate specific controls. Continuous monitoring through vendor risk platforms with continuous monitoring capabilities provides ongoing visibility between point-in-time assessments.
Audit Evidence for 5.20
Auditors assess 5.20 by verifying that documented agreements exist, that they contain the right security clauses, and that your organization actively manages compliance with those agreements.
| Evidence Type | Example Artifact |
|---|---|
| Supplier Security Policy | Policy defining supplier classification criteria, security requirements by risk tier, and review cadence |
| Supplier Agreement Template | Standard security schedule with clauses for data handling, incident notification, right to audit, and termination obligations |
| Signed Supplier Agreements | Executed contracts with security schedules for each active supplier relationship |
| Supplier Risk Register | Register mapping each supplier to their risk tier, data access scope, agreement status, and last review date |
| Supplier Assessment Records | Completed security questionnaires, independent audit reports (SOC 2, ISO 27001 certificates), and gap remediation tracking |
| Periodic Review Records | Meeting minutes or review reports from annual supplier security reviews documenting findings and actions |
| Incident Notification Logs | Records of supplier-reported security incidents and your organization’s response actions |
| Termination Checklists | Completed checklists confirming data return or destruction and access revocation at contract end |
Cross-Framework Mapping
Control 5.20 maps directly to several controls across major compliance frameworks, making it a high-leverage implementation target for organizations managing multiple compliance obligations.
| Framework | Equivalent Control(s) | Coverage |
|---|---|---|
| NIST 800-53 | SA-04 (Acquisition Process) | Full |
| NIST 800-53 | SR-02 (Supply Chain Risk Management Plan) | Full |
| NIST 800-53 | SR-03 (Supply Chain Controls and Processes) | Full |
| NIST 800-53 | SR-05 (Acquisition Strategies, Tools, and Methods) | Full |
| SOC 2 | CC9.2 (Risk Mitigation Through Vendor Management) | Partial |
| CIS Controls v8.1 | 15.1 (Establish and Maintain an Inventory of Service Providers) | Partial |
| NIST CSF 2.0 | GV.SC (Supply Chain Risk Management) | Full |
| DORA (EU) | Article 28 (ICT Third-Party Risk — Key Contractual Provisions) | Full |
The NIST 800-53 mappings cover the full scope of 5.20 — from acquisition processes (SA-04) through supply chain risk planning (SR-02), control implementation (SR-03), and procurement methods (SR-05). SOC 2’s CC9.2 addresses vendor risk mitigation but does not prescribe specific contractual clause requirements, making the coverage partial. DORA Article 28 is the closest regulatory equivalent for financial entities, mandating specific contractual provisions for ICT third-party service providers.
Related ISO 27001 Controls
Control 5.20 does not operate in isolation. It connects to a network of organizational and operational controls that collectively manage supplier risk across the relationship lifecycle.
| Control ID | Control Name | Relationship |
|---|---|---|
| 5.19 | Information security in supplier relationships | Establishes the overarching supplier risk policy that 5.20 agreements enforce contractually |
| 5.21 | Managing information security in the ICT supply chain | Extends 5.20 to ICT-specific risks including software supply chain and sub-supplier management |
| 5.22 | Monitoring, review, and change management of supplier services | Operationalizes the review rights and change notification requirements in 5.20 agreements |
| 5.23 | Information security for use of cloud services | Applies 5.20 principles to cloud service providers with cloud-specific requirements |
| 5.10 | Acceptable use of information and other associated assets | Defines the acceptable use policies that supplier access clauses reference |
| 5.12 | Classification of information | Provides the classification scheme that determines data handling requirements in supplier agreements |
| 5.31 | Legal, statutory, regulatory, and contractual requirements | Identifies the compliance obligations that must be reflected in supplier agreement clauses |
| 5.34 | Privacy and protection of personal data | Adds data protection and privacy requirements to agreements involving personal data processing |
Frequently Asked Questions
What is ISO 27001 5.20?
ISO 27001 control 5.20 is an organizational control that requires you to establish formal agreements with all suppliers, explicitly defining information security requirements, service levels, and compliance obligations appropriate to each relationship. It ensures that security expectations are contractually enforceable rather than assumed, covering the full lifecycle from onboarding through termination.
What happens if 5.20 is not implemented?
Without 5.20, your organization has no contractual mechanism to enforce supplier security obligations, audit their controls, or mandate timely breach notification. You inherit the security posture of every supplier in your chain without any ability to verify or remediate it — and you bear the liability when that posture fails.
How do you audit 5.20?
Auditors verify that signed agreements with security-specific clauses exist for all active suppliers and that these agreements are proportionate to the risk each supplier represents. They review your supplier register, assessment records, periodic review documentation, and incident notification logs to confirm the agreements are not just signed but actively managed.
How UpGuard Helps
Enforce supplier security requirements with continuous visibility
Contractual clauses only protect you if you can verify compliance. UpGuard Vendor Risk provides continuous monitoring of your suppliers’ security posture, automated security questionnaire workflows, and evidence collection — so you can validate that the obligations in your 5.20 agreements are being met, not just promised.