A supplier changes a hosting region, swaps a sub-processor, or quietly drops a security control — and nobody on your side notices until the audit. According to the Verizon 2025 Data Breach Investigations Report, 30% of breaches now involve a third-party vendor, double the previous year’s figure. Control 5.22 exists to close that blind spot. As part of the broader third-party risk management lifecycle, it requires organizations to continuously monitor what their suppliers are doing, review whether security commitments still hold, and govern any changes before they introduce new risk.
What 5.22 Requires
ISO 27001 5.22 is a control requiring organizations to regularly monitor and evaluate supplier service delivery and security practices against agreed requirements, while actively managing any changes to supplier services to maintain compliance and minimize risk.
The control rests on three pillars: monitor performance, review security posture, and govern changes.
Monitor performance means tracking whether suppliers deliver what they promised. That includes uptime, incident response times, patching cadence, and any other metrics defined in your service level agreements. Monitoring is not a passive activity — it requires defined cadences, documented evidence, and escalation paths when suppliers miss targets.
Review security posture means verifying that a supplier’s security controls remain effective over time. Certifications expire. Personnel change. Infrastructure moves. A SOC 2 Type II report from eighteen months ago does not tell you what a supplier’s security looks like today. Reviews should assess whether the supplier’s current practices still align with the requirements you agreed on during onboarding.
Govern changes means requiring suppliers to notify you before they make material changes to their services — new sub-processors, infrastructure migrations, changes to encryption standards, or personnel shifts affecting your data. You then assess the security impact of those changes and formally approve or reject them.
Contracts alone do not ensure security. Suppliers evolve their services constantly — updating platforms, restructuring teams, adopting new technologies. Without active monitoring, you only discover that a supplier weakened your security posture after a breach, audit failure, or compliance gap surfaces. Control 5.22 makes ongoing oversight a formal, auditable requirement rather than something that happens informally (or not at all).
Why 5.22 Matters
Organizations that fail to implement this control often face audit nonconformities or, worse, active security incidents. A supplier silently migrates infrastructure to a different jurisdiction. A sub-processor with access to your data changes hands. An encryption standard gets downgraded during a platform update. Without structured monitoring, these changes go unreviewed — creating gaps where security controls degrade without detection.
The financial exposure is significant. IBM’s 2025 Cost of a Data Breach report found that third-party vendor and supply chain compromises cost an average of $4.91 million per incident, making them one of the most expensive breach categories. Gartner research indicates that third-party breaches cost roughly 40% more to remediate than incidents originating within an organization’s own systems. The added cost comes from managing investigations that span multiple entities and legal jurisdictions.
The blast radius is growing. According to Black Kite’s 2026 Third-Party Breach Report, every vendor breach now claims an average of 5.28 downstream victims — the highest level ever recorded. A single supplier failure does not stay contained; it cascades through shared platforms, APIs, and service dependencies. Understanding how to prevent supply chain attacks starts with the monitoring discipline 5.22 establishes.
And the notification gap makes things worse. A RiskRecon and Ponemon Institute study found that only 34% of organizations have confidence that a primary third party would notify them of a data breach. If your monitoring relies on suppliers self-reporting problems, you are likely operating with a significant blind spot.
What attackers exploit
Attackers target the weakest link in the chain. When supplier monitoring fails, several specific vulnerabilities emerge:
- Unmonitored infrastructure changes — suppliers shift hosting regions or add new sub-processors without notification, expanding your attack surface without your knowledge
- Expired or lapsed certifications — SOC 2 or ISO 27001 certificates lapse and nobody rechecks, meaning you are relying on security assurances that may no longer be valid
- Supplier personnel changes — staff with access to your systems leave the supplier organization, but access reviews do not propagate to your environment
- Unpatched supplier systems — vendors handling your data fall behind on patching, and without monitoring you have no visibility into their vulnerability management
- Buried change notifications — supplier communications about material changes get lost in email or ignored because there is no formal governance process to triage them
- Supplier incident response failures — a supplier experiences a security incident but lacks the processes or contractual obligation to notify you promptly, allowing the compromise to cascade into your environment
How to Implement 5.22
For your organization
Start with a supplier risk register. Classify every supplier by criticality and data access level. A cloud hosting provider processing customer PII sits in a different risk tier than a marketing analytics tool with no access to sensitive data. This classification drives everything else — monitoring cadence, review depth, and change management rigor.
Define monitoring cadence. Critical suppliers should be reviewed quarterly. Standard suppliers can follow an annual cycle. The review should be a documented meeting with specific agenda items: SLA performance, security posture changes, certification status, incident history, and upcoming service changes.
Track SLA performance metrics. Uptime, incident response time, patching cadence, and availability against contractual thresholds. These are not vanity metrics — they are leading indicators. A supplier consistently missing SLA targets is a supplier that may also be cutting corners on security. Vendor risk monitoring tools can automate much of this tracking.
Implement formal change management. Require suppliers to provide advance notice of any material change to their services. This includes new sub-processors, infrastructure migrations, changes to data processing locations, and modifications to security controls. Each notification should trigger a security impact assessment and formal approval before the change proceeds.
Monitor certifications and audit reports. Track expiry dates for supplier certifications (ISO 27001, SOC 2 Type II) and request updated reports before they lapse. Do not assume a supplier has renewed — verify it.
Assign service owners. Each critical supplier relationship needs an internal owner responsible for managing the monitoring cadence, reviewing reports, and escalating issues.
Common mistakes:
- Treating supplier assessment as a one-time onboarding exercise instead of ongoing monitoring
- Relying solely on supplier self-attestation without independent verification
- No formal process for supplier change notifications — changes go unreviewed
- Monitoring only critical suppliers while ignoring niche providers that still have data access
- Failing to exercise audit rights even when contracts include them
For your vendors
When assessing suppliers, structured questionnaires surface risks that self-attestation alone will miss. A vendor risk assessment provides the framework for this evaluation, and an ISO 27001 vendor questionnaire template can accelerate the process.
Key questions to ask:
- How do you notify customers of changes to sub-processors or hosting infrastructure?
- What is your incident notification timeline?
- Can you provide your most recent SOC 2 Type II or ISO 27001 certificate?
- How do you manage access for personnel who leave your organization?
- What is your vulnerability management and patching cadence?
Evidence to request: SOC 2 Type II reports, ISO 27001 certificates, penetration test summaries, and business continuity plans. These are not optional extras — they are baseline evidence that a supplier takes security seriously.
Red flags to watch for:
- Outdated certifications with no renewal timeline
- Reluctance to share audit reports or penetration test summaries
- No documented change management process
- Vague incident response commitments (e.g., “we will notify you as soon as practicable” with no defined timeline)
- Inability to identify their own sub-processors
Verification beyond self-attestation: Request third-party audit reports directly. Exercise contractual audit rights when risk warrants it. Cross-check claimed certifications against certification body registries — a supplier claiming ISO 27001 certification should be verifiable through their certification body’s public directory.
Audit Evidence for 5.22
Auditors verify 5.22 by looking for documented, repeatable processes — not just policies. Here is what they expect to see:
| Evidence Type | Example Artifact |
|---|---|
| Supplier Risk Register | Register classifying suppliers by criticality, data access level, and review cadence |
| Supplier Review Meeting Minutes | Documented quarterly or annual review records with security discussion items and action items |
| SLA Performance Reports | Dashboard or report tracking uptime, incident response times, and patching cadence against contractual thresholds |
| Supplier Change Log | Record of supplier-initiated changes with security impact assessment and approval sign-off |
| Certification Tracking Register | Log of supplier certifications (ISO 27001, SOC 2) with expiry dates and renewal verification |
| Supplier Security Questionnaire Responses | Completed questionnaires with evidence of review and risk rating assignment |
| Incident Response Records | Documentation of supplier-related security incidents, notifications received, and resolution tracking |
| Audit Rights Exercise Records | Evidence of contractual audit rights being exercised or third-party assurance reports reviewed |
The key theme auditors look for is consistency. A supplier risk register that was last updated twelve months ago, or meeting minutes that skip quarters, signals that monitoring exists on paper but not in practice.
Cross-Framework Mapping
Control 5.22 does not exist in isolation. If your organization operates across multiple compliance frameworks, understanding the overlap reduces duplicate effort and strengthens your control environment.
| Framework | Equivalent Control(s) | Coverage |
|---|---|---|
| NIST 800-53 | RA-09 (Criticality Analysis) | Partial — covers supplier criticality assessment |
| NIST 800-53 | SA-09 (External System Services) | Full — requires monitoring of external service providers |
| NIST 800-53 | SR-06 (Supplier Assessments and Reviews) | Full — directly maps to supplier review and assessment |
| NIST 800-53 | SR-07 (Supply Chain Operations Security) | Partial — covers operational security in supply chain |
| SOC 2 | CC9.2 (Risk Mitigation for Vendor and Business Partner Relationships) | Partial — addresses vendor risk but with less prescriptive monitoring requirements |
| NIST CSF 2.0 | GV.SC (Supply Chain Risk Management) | Partial — provides governance framework for supply chain risk |
| CIS Controls v8.1 | 15.2 (Establish and Maintain a Service Provider Management Policy) | Partial — covers policy but not ongoing monitoring specifics |
| DORA (EU) | Article 28 (Third-party ICT risk management) | Partial — EU-specific requirements for ICT third-party monitoring |
| CPS 230 (APRA) | Requirements on material service providers | Partial — Australian prudential requirements for outsourcing oversight |
The NIST 800-53 mappings are sourced from the official OLIR (Online Informative References) crosswalk between ISO 27001 and NIST 800-53. SA-09 covers external service provider monitoring. SR-06 covers supplier assessments and reviews. Organizations subject to both frameworks can use 5.22 evidence to satisfy these NIST controls with minimal additional documentation.
Related ISO 27001 Controls
Control 5.22 connects to a cluster of supplier and compliance controls within ISO 27001. Understanding these relationships — and the broader ISO 27001 third-party risk requirements — helps you build a coherent control environment rather than treating each control in isolation.
| Control ID | Control Name | Relationship |
|---|---|---|
| 5.19 | Information security in supplier relationships | Establishes the supplier security requirements that 5.22 monitors |
| 5.20 | Addressing information security within supplier agreements | Defines contractual terms that 5.22 reviews for compliance |
| 5.21 | Managing information security in the ICT supply chain | Extends supply chain oversight to ICT-specific risks |
| 5.23 | Information security for use of cloud services | Applies 5.22 monitoring principles specifically to cloud providers |
| 5.29 | Information security during disruption | Supplier continuity monitoring feeds into disruption planning |
| 5.31 | Legal, statutory, regulatory and contractual requirements | Compliance obligations that supplier monitoring must address |
| 5.36 | Compliance with policies, rules and standards | Verifies supplier adherence to organizational security policies |
| 8.1 | User endpoint devices | Supplier-managed endpoints require access monitoring under 5.22 |
In practice, 5.19 and 5.20 set the foundation — they define what security you expect from suppliers and embed those expectations in contracts. Control 5.22 then provides the ongoing assurance that those expectations are being met. If you implement 5.22 without 5.19 and 5.20, you have nothing to monitor against.
Frequently Asked Questions
What is ISO 27001 5.22?
ISO 27001 5.22 is a control requiring organizations to regularly monitor and evaluate supplier service delivery and security practices against agreed requirements, while managing any changes to supplier services. It covers three activities: performance monitoring, security posture review, and change management governance. The control applies to any organization with suppliers that handle, process, or have access to its information or information systems.
What happens if 5.22 is not implemented?
Without 5.22, supplier changes go unreviewed, creating blind spots where security controls degrade without detection. This exposes the organization to supply chain compromise, regulatory nonconformity during ISO 27001 audits, and potential data breaches through unmonitored third-party access. Given that 30% of breaches now involve third-party vendors (Verizon DBIR 2025), the absence of structured supplier monitoring represents a material risk.
How do you audit 5.22?
Auditors verify 5.22 by reviewing supplier risk registers, service review meeting minutes, change management logs, and certification tracking records. They look for evidence that monitoring is consistent and documented — not just that policies exist. Gaps between stated review cadences and actual records, missing change approvals, or outdated supplier certifications are common audit findings.
How UpGuard Helps
UpGuard Vendor Risk automates continuous supplier monitoring, tracks security posture changes in real time, and surfaces risk before auditors do — giving you the ongoing oversight 5.22 demands without the manual overhead.