Rina Ostrowski found out her company had a third-party problem at 6:40 on a Tuesday morning, from a Slack message forwarded by her VP of Customer Success: "Are we the ones in this article?"
Rina was CISO at Cascade Freight Analytics, a mid-size logistics-tech firm that routed freight bookings and payment reconciliation for about 340 regional carriers. Cascade didn't store much of the sensitive data itself — most of the heavy lifting happened inside a third-party scheduling and invoicing SaaS platform that Cascade's ops team had adopted four years earlier, before there was a formal vendor security review process. The vendor, in turn, stored its data in a cloud storage bucket that a contractor had misconfigured during a migration eight months prior. Nobody at Cascade had audited that vendor since the original sign-up call. Nobody had asked what "cloud storage" meant in practice, who owned the bucket policy, or what would happen if the vendor's engineering team changed a permission setting on a Friday afternoon.
The bucket had been publicly readable for eight months. A researcher found it, wrote it up, and by the time Rina's phone started buzzing, journalists already had screenshots of Cascade customers' banking details, load manifests, and driver personal data — all exposed through a vendor Cascade had never formally assessed, under a contract that said nothing about security requirements, breach notification timelines, or audit rights. The vendor's own liability cap in its terms of service was $50,000. Cascade's actual costs — forensic investigation, customer notification, three carrier contract terminations, a regulator inquiry, and a class-action settlement — landed north of $4.1 million. Cascade's customers didn't care whose cloud bucket it was. They had a contract with Cascade, and Cascade was the one on the hook.
That is the uncomfortable truth at the center of ISO 27001's supplier relationship controls: your ISMS scope ends at your organizational boundary, but your risk doesn't. Controls 5.19 through 5.23 in Annex A exist because certification bodies, regulators, and increasingly your own customers have all reached the same conclusion — you cannot outsource accountability, only activity. This article walks through all five controls in detail, gives you a supplier risk-tiering method, a contract clause checklist, an ICT supply-chain risk framework, a monitoring cadence, and a cloud shared-responsibility model that will hold up under audit and under a real incident.
Who This Is For
This guide is written for ISMS implementers, CISOs, procurement and vendor-management leads, and internal auditors who need to move supplier and cloud security from a checkbox exercise to a working control environment. You should already have your ISMS scope defined and a working risk assessment process under Clause 6 — this article assumes you know how to score a risk, and focuses on applying that muscle specifically to third parties and cloud providers. By the end, you'll have a tiering model for classifying suppliers, a clause-by-clause contract checklist, a monitoring cadence you can staff against, and a defensible answer to the auditor question every organization eventually gets asked: "How do you know your suppliers are still secure six months after you signed the contract?"
Why Supplier Risk Became an Annex A Priority
In the 2013 version of ISO 27001, supplier security lived in a single control family with less granularity. The 2022 revision split it into five distinct controls precisely because auditors, incident responders, and insurers kept seeing the same pattern: organizations had decent internal controls and terrible visibility into what happened once data, access, or processing left the building. Ransomware groups learned this too — attacking a managed service provider or a niche software vendor is a far more efficient way to compromise 200 downstream companies than attacking any one of them directly. Regulators followed suit: the EU's DORA regulation now mandates ICT third-party risk registers for financial entities, and virtually every breach notification law treats a vendor breach exactly like your own breach for notification purposes.
I've sat across the table from close to 200 organizations preparing for ISO 27001 certification, and supplier relationship controls are consistently where the gap between "policy exists" and "control operates" is widest. Organizations write a supplier security policy, staple a security addendum to new contracts, and call it done — then discover during a Stage 2 audit that nobody can produce evidence of a single supplier risk assessment, that the "security addendum" was never actually attached to 80% of live contracts, or that the cloud environment hosting production data was provisioned by a developer with a personal credit card and no security review at all. Controls 5.19–5.23 are designed to close exactly that gap.
I've also watched the reverse pattern play out: organizations that treat supplier security as purely a compliance artifact, produced once for the auditor and never touched again, tend to discover the gap at the worst possible moment — during incident response, when nobody can answer basic questions like "which of our suppliers can reach this system," "what does the contract say about notification," or "who owns this relationship internally." A mature supplier program isn't measured by the thickness of the policy document; it's measured by how fast someone in your organization can answer those three questions on a bad day, for any given supplier, without needing to track down whoever originally signed the deal.
The Five Controls at a Glance
Control | Name | Core Question It Answers | Primary Owner |
|---|---|---|---|
5.19 | Information security in supplier relationships | Do we have a defined process for assessing and managing risk before and during any supplier relationship? | Information security / procurement (joint) |
5.20 | Addressing information security within supplier agreements | Are our security expectations written into the contract, not just implied? | Legal / procurement, with security input |
5.21 | Managing information security in the ICT supply chain | Do we understand and manage risk from the supplier's suppliers, and from the products/components we buy? | Information security / IT procurement |
5.22 | Monitoring, review and change management of supplier services | Do we keep checking after signature, and catch changes that affect our risk? | Vendor management / security operations |
5.23 | Information security for use of cloud services | Do we have a defined approach to acquiring, using, and exiting cloud services securely? | Cloud/IT architecture, with security oversight |
Read together, these five controls form a lifecycle, not a checklist: assess before you commit, write it into the deal, understand what's behind the vendor, keep watching after signature, and treat cloud specifically as its own risk category because of how differently responsibility is shared there. They sit within the broader organizational controls covering the full 5.1–5.37 range, but in my experience they're the cluster most likely to be under-resourced relative to their actual risk, simply because the "supplier" label makes them feel like a procurement problem rather than a core security control set.
flowchart LR
A[Identify Need\nfor Supplier/Cloud Service] --> B[Risk Assessment\n& Tiering (5.19)]
B --> C[Due Diligence &\nSelection]
C --> D[Contract & SLA\nNegotiation (5.20)]
D --> E[Supply Chain\nRisk Review (5.21)]
E --> F[Onboarding &\nAccess Provisioning]
F --> G[Ongoing Monitoring,\nAudits, Change Mgmt (5.22)]
G --> H{Cloud\nService?}
H -->|Yes| I[Shared Responsibility\nMapping & Controls (5.23)]
H -->|No| J[Standard Monitoring\nCadence]
I --> K[Contract Renewal /\nRe-assessment]
J --> K
K --> L[Offboarding /\nCloud Exit & Data Return]
G -.escalation on\nincident/change.-> M[Incident Management\n(5.24-5.28)Control 5.19: Information Security in Supplier Relationships
Control 5.19 requires your organization to define and apply processes and procedures to manage the information security risks associated with the use of suppliers' products and services. In plain terms: before you let a supplier touch your data, your network, or your customers' data, you need a repeatable way to figure out how risky that relationship is and what conditions have to be met before it goes live.
This is the "front door" control. It's where risk tiering happens (more on that below), where you decide which suppliers need a full security questionnaire versus a lightweight check, and where you build the internal process that procurement and business teams are actually required to follow — not a policy that lives in a folder nobody opens. Auditors love this control because it's easy to test: pull five active supplier contracts and ask for evidence of a pre-engagement risk assessment. If you can't produce it, or if it only exists for suppliers onboarded after the audit was scheduled, that's a finding.
Requirement | What Good Evidence Looks Like | Common Failure Mode |
|---|---|---|
Documented supplier security policy/process | A policy defining tiering criteria, assessment triggers, and approval gates, version-controlled and owned | Policy exists but was never socialized with procurement or business units |
Pre-engagement risk assessment | Completed questionnaire or risk score per supplier, dated before contract signature | Assessment done after the contract is already signed, or not at all |
Supplier inventory / register | Central register linking every active supplier to a risk tier, contract, and owner | Suppliers tracked in scattered spreadsheets owned by different departments |
Approval workflow for new suppliers | Ticket or sign-off trail showing security review before onboarding | "Shadow IT" suppliers onboarded directly by business units with no security visibility |
Periodic re-assessment trigger | Defined schedule (e.g., annually for critical suppliers) with completed re-assessments on file | Assessment done once at onboarding and never repeated |
The practical starting point is almost always the same: build (or clean up) a single supplier register that captures every third party with access to information, systems, or premises — not just the ones IT set up. In my experience, the first pass at this register in a mid-size company typically finds 30–50% more active suppliers than anyone expected, because business units and marketing teams sign up for SaaS tools independently. Feed that register into your risk assessment methodology from Clause 6 planning so supplier risk is scored using the same criteria as everything else in your risk register, rather than a separate, incompatible scale.
"The single biggest 'aha' moment I see in supplier security workshops is when a client realizes their risk register and their accounts-payable list don't match — and the mismatch is always suppliers nobody assessed." — Priya Nandakumar, CISO, Vellsync Financial
Building a Practical Supplier Security Questionnaire
Most organizations either skip the questionnaire stage entirely (relying on a sales call and a handshake) or import a 200-question generic template that nobody on either side actually reads in full. Neither works. The questionnaire's job is to generate evidence that feeds directly into your tiering decision — not to perform diligence theater. I recommend scaling questionnaire depth to the tier you expect the supplier to fall into based on an initial screening conversation, then confirming or adjusting the tier once the full answers are in.
Questionnaire Section | Sample Question | What You're Really Testing |
|---|---|---|
Governance | Do you have a named individual accountable for information security? | Whether security has organizational ownership, not just a policy PDF |
Certification | Do you hold a current ISO 27001 certificate or SOC 2 Type II report? | Independent assurance you can rely on to reduce your own testing burden |
Access & data handling | What data will you access, and where is it stored/processed? | Whether the answer matches what your business team believes is happening |
Incident history | Have you experienced a security incident affecting customer data in the last 24 months? | Willingness to disclose, and a read on incident response maturity |
Subcontracting | Do you use subcontractors or cloud providers to deliver this service? | Fourth-party exposure that Control 5.21 requires you to understand |
Business continuity | What is your recovery time objective for this service? | Whether their continuity planning matches your operational dependency on them |
Exit provisions | How would you support us in exporting our data if we terminated the contract? | Early warning on lock-in risk, well before Control 5.23 exit planning becomes urgent |
A questionnaire response that's vague, evasive, or inconsistent with what your business stakeholder already told you is itself a data point — and in my experience, it's one of the more reliable predictors of how a vendor will behave when something actually goes wrong.
Control 5.20: Addressing Information Security Within Supplier Agreements
Control 5.20 requires relevant information security requirements to be established and agreed with each supplier based on the type of supplier relationship — meaning the risk assessment from 5.19 has to actually show up as contractual language, not just internal intent. A risk assessment that concludes "this supplier is high-risk" means nothing if the signed contract contains zero security obligations, no audit rights, and no breach notification clause.
This is where I see the widest gap between what security teams believe and what's actually true. Ask a CISO "do we have security clauses in supplier contracts?" and the answer is almost always yes. Ask to see the actual contracts for the ten highest-risk suppliers and pull the security schedule, and it's frequently missing, outdated, or based on a template that predates the current risk landscape (no cloud clauses, no breach notification timeline, no subcontractor flow-down language).
Contract Clause | Purpose | Should Apply To |
|---|---|---|
Confidentiality / NDA terms | Protects information shared during and after the relationship | All suppliers |
Security requirements schedule (aligned to risk tier) | Specifies controls the supplier must maintain (encryption, access control, patching, etc.) | Tier 1–2 suppliers |
Right-to-audit clause | Allows your organization (or a nominated third party) to audit or request evidence of controls | Tier 1 (critical) suppliers |
Breach/incident notification timeline | Defines how fast the supplier must notify you of a security incident affecting your data | All suppliers with data/system access |
Subcontractor (fourth-party) flow-down clause | Requires the supplier to impose equivalent obligations on its own subcontractors | Suppliers who subcontract processing |
Data location & sovereignty terms | States where data may be stored/processed and requires notice of changes | Suppliers processing regulated or personal data |
Return/deletion of data on termination | Obligates the supplier to return or securely delete data at contract end | All suppliers with data access |
Service Level Agreement (SLA) with security metrics | Defines uptime, patching SLAs, and security response times, not just availability | Tier 1–2 suppliers |
Liability and indemnification aligned to risk | Ensures financial exposure is proportionate to potential impact, not capped at invoice value | Tier 1 (critical) suppliers |
Certification/attestation requirement (e.g., ISO 27001, SOC 2) | Requires the supplier to hold or pursue relevant independent assurance | Tier 1–2 suppliers |
Cloud-specific terms (where applicable) | Shared responsibility clarity, sub-processor list, exit assistance | Cloud service providers |
The Cascade Freight Analytics story from the opening of this article is a textbook 5.20 failure: the vendor's standard terms of service capped liability at $50,000 — a figure that made sense for a small customer with modest exposure, and made no sense at all once Cascade was routing sensitive freight and payment data through the platform. Nobody at Cascade had ever renegotiated that clause because nobody had reassessed the vendor's risk tier as the relationship grew. A contract clause is only as good as the process that keeps checking whether it still fits the relationship.
"I tell every procurement team the same thing: your security questionnaire is worthless if the answers never make it into the signed contract. A questionnaire is an opinion. A contract clause is an obligation." — Tomasz Reyes, Director of Procurement Security, Norhaven Retail Group
Control 5.21: Managing Information Security in the ICT Supply Chain
Control 5.21 extends the lens beyond your direct suppliers to the ICT products and services supply chain itself — the hardware, software, components, and subcontracted services that sit behind whatever you're actually buying. This is the control that addresses fourth-party (and fifth-party) risk: your cloud provider's data center subcontractor, your SaaS vendor's authentication library, the firmware embedded in a network appliance you bought from a reseller.
This control gained urgency after a string of high-profile supply chain compromises — attackers inserting malicious code into legitimate software update mechanisms, or compromising a widely used component that then propagated into thousands of downstream products. ISO 27002:2022's guidance for 5.21 specifically calls out understanding how the supplier manages security in their supply chain, monitoring for changes to sub-tier suppliers, and where appropriate, requiring visibility into critical components (including, increasingly, software bills of materials for custom or embedded software).
ICT Supply Chain Risk Area | What to Assess | Illustrative Control |
|---|---|---|
Hardware provenance | Where is equipment manufactured/assembled; is the supply chain verifiable? | Procure only through authorized resellers; inspect for tampering on receipt |
Software/firmware integrity | Is code signed; is there a verifiable update mechanism? | Require signed updates and checksum verification before deployment |
Fourth-party subcontractors | Does the supplier use subcontractors for hosting, support, or development? | Require disclosure of subcontractors and flow-down security obligations |
Open-source and third-party components | Are known-vulnerable components tracked and patched? | Require an SBOM (software bill of materials) or equivalent for critical software |
Outsourced/offshore development | Who writes the code, and under what security controls? | Align with Control 5.8 security in project management expectations for outsourced projects |
Concentration risk | Do multiple critical suppliers rely on the same fourth party (e.g., one cloud region)? | Map dependencies; assess single-point-of-failure exposure |
Geopolitical/jurisdictional exposure | Is any tier of the supply chain subject to conflicting legal jurisdiction or sanctions risk? | Legal review as part of onboarding for critical suppliers |
Fourth-party risk is the part organizations most often skip, because it feels one step removed from something they can control. But when I run tabletop exercises with clients, the scenario that consistently produces the most uncomfortable silence in the room is: "Your critical SaaS vendor just announced their primary hosting subcontractor had a breach. What do you know about that subcontractor, and how fast can you find out if your data was affected?" Most organizations can't answer either question, because their vendor risk assessment stopped at the first tier.
A pragmatic middle ground for most mid-market organizations: require full fourth-party disclosure and flow-down clauses only for your Tier 1 (critical) suppliers, and rely on the supplier's own independent attestation (SOC 2 Type II, ISO 27001 certificate) as sufficient assurance for lower tiers. Trying to map every subcontractor of every SaaS tool you use is not proportionate risk management — it's busywork that crowds out attention to the relationships that actually matter.
"Every ransomware post-mortem I've worked in the last three years has a supply chain link in it somewhere — a managed service provider, a patch management tool, a niche vendor nobody thought to ask about. The organizations that survived with the least damage were the ones who already knew who those fourth parties were." — Ade Okonkwo, vCISO, Meridian Risk Partners
Control 5.22: Monitoring, Review and Change Management of Supplier Services
Control 5.22 requires organizations to regularly monitor, review, and audit supplier service delivery, and to manage changes to supplier-provided services — including maintaining and improving existing information security policies, procedures, and controls in response to those changes. This is the control that turns supplier security from a one-time onboarding gate into a living program.
This is also the control most likely to be a paper tiger. It's easy to run a thorough due-diligence review at onboarding when a deal is new and everyone's paying attention. It's much harder to sustain a monitoring rhythm two or three years into a relationship, once the original security champion has moved teams and the contract renews automatically. Yet this is exactly the period when risk actually changes: the vendor gets acquired, migrates to a new cloud region, replaces a key subcontractor, or has staff turnover on its security team — and none of that shows up unless someone is actively watching.
Monitoring Activity | Trigger/Frequency | Evidence to Retain |
|---|---|---|
Re-run risk assessment / re-score tier | Annually for Tier 1, biennially for Tier 2, on contract renewal for Tier 3 | Updated risk assessment record |
Request updated certification/attestation (ISO 27001, SOC 2 report) | Annually, or on certificate expiry | Current certificate/SOC 2 report on file, reviewed and signed off |
Review SLA and security KPI performance | Quarterly for Tier 1, semi-annually for Tier 2 | SLA scorecard with any breaches logged and followed up |
Conduct or commission an audit / assessment (right-to-audit) | Annually for Tier 1 critical suppliers, or after a material incident | Audit report and remediation tracking |
Review for material change (ownership, subcontractors, architecture, region) | Continuous — via contract notice clauses and periodic check-ins | Change log with impact assessment |
Incident/breach notification review | Every reported incident, regardless of materiality | Incident record cross-referenced to incident management process |
Contract renewal security review | At every renewal point | Renewal checklist confirming clauses still reflect current risk tier |
Offboarding/exit review | At termination or non-renewal | Data return/deletion confirmation, access revocation evidence |
The practical mechanism I recommend to clients is a supplier monitoring calendar that's owned by a named individual (not "the security team" — an actual person with a deadline reminder), tied directly to the supplier register from Control 5.19. When a Tier 1 supplier's annual review comes due, it should generate a ticket automatically, not rely on someone remembering. Auditors specifically probe for evidence that monitoring happened, not just that a schedule exists — so keep dated records of every review, every SLA scorecard, and every escalation, even the boring ones where nothing changed.
Change management deserves particular attention because it's the piece most organizations genuinely miss. A supplier doesn't need to have a breach to increase your risk — a change of ownership, a new subcontractor, a re-architecture from single-tenant to multi-tenant hosting, or a region migration can all materially shift your exposure. Build a contractual obligation for suppliers to notify you of material changes, and build an internal process to actually evaluate what that notification means for your risk register rather than filing it away unread.
"Monitoring supplier services isn't a compliance chore — it's how you find out your vendor got acquired by a company you'd never have approved, three months before it happens on the front page instead of in your inbox." — Marcus Webb, Head of Third-Party Risk, Corrigan Health Networks
Control 5.23: Information Security for Use of Cloud Services
Control 5.23 is new to the 2022 revision, and it exists because cloud services broke the traditional supplier model. A cloud provider isn't quite a supplier in the classical sense — you're not handing them a finished product to operate on your behalf; you're consuming infrastructure, platform, or software capability and building your own security on top of a foundation someone else maintains. That split creates the single most common source of cloud incidents: both parties assuming the other one owns a particular control.
Control 5.23 requires the organization to establish processes for the acquisition, use, management, and exit of cloud services, in accordance with the organization's information security requirements. ISO 27002:2022's implementation guidance calls out defining how the organization will address the division of responsibilities between the organization and the cloud service provider, and specifically flags that this needs documenting before the service goes live — not reverse-engineered after an incident.
Requirement | What Good Evidence Looks Like | Common Failure Mode |
|---|---|---|
Cloud service acquisition process | Documented approval workflow including security review before procurement | Business unit provisions cloud service directly with a corporate card, no review |
Shared responsibility mapping per service | Written mapping of which controls the provider owns vs. your organization, per service model (IaaS/PaaS/SaaS) | Assumption that "the cloud provider handles security" with no documented split |
Configuration and hardening standards | Documented secure baseline configuration for cloud environments (e.g., CIS Benchmarks) | Default configurations left unchanged, especially storage and identity settings |
Identity and access management for cloud | MFA, least-privilege roles, and periodic access review specific to cloud consoles | Shared admin credentials, no periodic access recertification |
Data protection and encryption | Encryption at rest/in transit, key management ownership defined | Encryption enabled by default but keys/config never reviewed |
Cloud exit / portability plan | Documented exit strategy including data export format and timeline, tested at least once | No exit plan; discovered only at contract termination that data export isn't feasible |
Monitoring of cloud provider status/incidents | Subscription to provider status/security bulletins, mapped to internal escalation | No visibility into provider incidents until customers report an outage |
The Cascade Freight Analytics breach was, at its root, a Control 5.23 failure one level removed — Cascade's vendor was the one with the misconfigured storage bucket, but the same failure mode plays out just as often when organizations manage their own cloud environment. I've run incident debriefs where the root cause was a storage bucket left with public read access "temporarily" during a migration two years earlier, or an IAM role with wildcard permissions created for a one-off script and never revoked. Cloud misconfiguration remains one of the most common root causes of cloud data exposure precisely because the shared responsibility model gives everyone a plausible reason to assume someone else is watching that setting.
The Cloud Shared Responsibility Model
The core concept every practitioner needs to internalize — and every auditor will test you on — is that "shared responsibility" shifts depending on the service model. The cloud provider's physical security, hypervisor, and core infrastructure protections stay fairly constant across models; what changes is how much of the stack above that line is yours to secure.
Layer | IaaS (e.g., virtual machines, storage) | PaaS (e.g., managed database, app platform) | SaaS (e.g., CRM, HR platform) |
|---|---|---|---|
Physical infrastructure & hypervisor | Provider | Provider | Provider |
Network controls | Shared (provider secures backbone; customer configures VPC/firewall rules) | Provider (mostly) | Provider |
Operating system patching | Customer | Provider | Provider |
Application-layer security | Customer | Customer | Provider (core app); Customer (configuration) |
Identity and access management | Customer | Customer | Customer |
Data classification & encryption choices | Customer | Customer | Customer |
Configuration of security settings | Customer | Shared | Customer (within app's admin controls) |
Data backup ownership | Customer (unless explicitly contracted) | Shared | Shared (verify contractually) |
Incident response for the underlying platform | Provider | Provider | Provider |
Incident response for customer data/access misuse | Customer | Customer | Customer |
Notice the row that never changes ownership regardless of model: identity and access management, and data classification/encryption choices, are always the customer's job. In every cloud incident post-mortem I've conducted, the root cause traces back to one of those two rows more often than to anything the provider controlled. This is the single most important takeaway to put in front of a board or an auditor: "the cloud provider handles security" is not a defensible control statement under Control 5.23 — you need to be able to say specifically which layer you own and show the evidence that you're securing it.
Cloud Exit Strategy
The most frequently missing piece of Control 5.23 evidence, in my experience across dozens of audits, is a tested cloud exit plan. Organizations plan the migration into a cloud service in detail and never plan the migration out — until a renewal negotiation goes badly, a provider deprecates a service, or a regulator demands data residency changes on a timeline the organization didn't anticipate.
Cloud Exit Element | Why It Matters | Practical Test |
|---|---|---|
Data export format and completeness | Vendor lock-in often hides in proprietary export formats | Actually export a full dataset annually and verify it's usable |
Timeline for data retrieval post-termination | Contracts often allow providers to delete data 30–90 days after termination | Confirm the window in the contract and diarize it |
Cost of exit (egress fees, professional services) | Egress and re-platforming costs can make "switching" theoretical rather than real | Model exit cost as part of the original vendor selection, not after the fact |
Availability of equivalent alternative providers | Some capabilities (e.g., specialized AI/ML services) have few substitutes | Document viable alternatives during onboarding, not during a crisis |
Transition support obligations in contract | Some contracts require paid "transition assistance"; others offer none | Negotiate transition assistance clauses into Tier 1 cloud contracts up front |
Supplier Risk-Tiering Method
Not every supplier deserves the same scrutiny, and treating them all identically is how security teams burn goodwill with the business while still missing the suppliers that matter most. A workable tiering model needs to be simple enough for procurement to apply consistently and rigorous enough to survive an auditor's questions.
Tier | Definition | Example Supplier Type | Assessment Depth | Re-assessment Frequency |
|---|---|---|---|---|
Tier 1 – Critical | Access to sensitive/regulated data, or supports a critical business process; failure would cause severe impact | Core SaaS platform, cloud hosting provider, payroll processor, managed security service provider | Full questionnaire, evidence review, right-to-audit exercised, executive sign-off | Annually, plus on material change |
Tier 2 – Significant | Some access to internal systems/data, or moderate business impact if disrupted | Marketing automation platform, HR tools with limited PII, regional logistics software | Standard questionnaire, certification/attestation review | Every 18–24 months |
Tier 3 – Standard | Limited or no access to sensitive data; low business impact | Office supplies vendor, general facilities contractor, non-integrated software tools | Lightweight self-attestation, basic due diligence | At contract renewal |
Tier 4 – Minimal | No data or system access; purely transactional relationship | One-off consultants with no system access, event vendors | None required beyond standard procurement checks | Not applicable |
Tiering criteria should draw from the same factors as your broader risk methodology under Clause 6: data sensitivity accessed, criticality of the service to operations, level of system/network access granted, regulatory exposure, and (increasingly) the supplier's own security maturity as evidenced by certification. I typically recommend scoring each factor 1–3 and summing them, with a defined threshold that maps to each tier — this keeps the classification consistent even as different people apply it over time, and gives you a defensible, auditable rationale rather than a gut-feel label.
Scoring Factor | Score 1 (Low) | Score 2 (Medium) | Score 3 (High) |
|---|---|---|---|
Data sensitivity accessed | No access to confidential/regulated data | Access to internal, non-regulated business data | Access to regulated, financial, or highly sensitive personal data |
Service criticality | Fully replaceable with minimal disruption | Disruption causes moderate operational impact | Disruption halts a critical business process |
System/network access level | No direct access to systems | Limited, monitored access | Privileged or broad system access |
Regulatory exposure | No regulatory implications | Some regulatory relevance | Directly subject to regulatory obligations (e.g., payment, health, financial data) |
Supplier's own security maturity | Independently certified (ISO 27001/SOC 2) with recent audit | Some evidence of controls, no independent certification | No evidence of a security program |
Sum the five factors (range 5–15) and map the total to a tier — for example, 12–15 as Tier 1, 9–11 as Tier 2, 6–8 as Tier 3, and 5 as Tier 4. The exact thresholds matter less than applying them consistently and documenting the rationale for every supplier, so that a tier assignment can be defended six months later by someone who wasn't in the room when it was made.
Insurance and Supplier Risk
Cyber insurance underwriters have become considerably more specific about third-party risk in recent renewal cycles, and it's worth connecting your supplier program to your insurance conversations rather than treating them as separate exercises. Underwriters increasingly ask direct questions about supplier tiering, whether critical suppliers carry their own cyber liability coverage, and whether contracts include indemnification proportionate to potential loss — the same artifacts Controls 5.19 and 5.20 require you to produce for certification. Organizations that can hand an underwriter a tiered supplier register and a contract clause checklist, rather than a verbal assurance that "we vet our vendors," have consistently reported smoother renewals and, in several cases I've been close to, materially better premium outcomes. Treat your ISO 27001 supplier evidence pack as dual-purpose: it satisfies your auditor, and it's the same pack your broker will ask for at the next renewal.
Contract Clause Checklist for Security and Procurement Teams
Beyond the individual clauses covered under Control 5.20 above, here's a working checklist procurement and legal teams can run through before any Tier 1 or Tier 2 contract is signed.
Checklist Item | Confirmed Before Signature? |
|---|---|
Security requirements schedule attached and tier-appropriate | Yes / No |
Right-to-audit clause included (Tier 1) or attestation requirement (Tier 2) | Yes / No |
Breach notification timeline specified (recommend 24–72 hours) | Yes / No |
Subcontractor/fourth-party disclosure and flow-down obligation | Yes / No |
Data location, sovereignty, and cross-border transfer terms defined | Yes / No |
Data return/deletion obligation on termination, with confirmation method | Yes / No |
SLA includes security-relevant metrics (patch timelines, uptime, response times) | Yes / No |
Liability/indemnification proportionate to potential impact, not capped at invoice value | Yes / No |
Insurance requirements (cyber liability) specified where appropriate | Yes / No |
Termination-for-security-cause clause included | Yes / No |
Cloud-specific terms included where applicable (shared responsibility reference, exit assistance) | Yes / No |
Renewal trigger includes mandatory security re-review | Yes / No |
RACI: Who Actually Owns Supplier Security
One of the most common reasons supplier controls fail in practice isn't a missing policy — it's a missing owner. Security teams often assume procurement owns supplier risk because they run the purchasing process; procurement assumes security owns it because it's "a security control." Both are half right, and the gap between them is exactly where suppliers slip through unassessed. A simple RACI, published and referenced in your supplier policy, closes that gap.
Activity | Security Team | Procurement | Business Owner | Legal |
|---|---|---|---|---|
Initial risk tiering | Accountable | Consulted | Informed | Informed |
Security questionnaire review | Responsible | Consulted | Informed | Informed |
Contract security clause drafting | Consulted | Consulted | Informed | Accountable |
Right-to-audit exercise | Accountable | Informed | Consulted | Informed |
Ongoing SLA/performance monitoring | Consulted | Accountable | Responsible | Informed |
Annual re-assessment | Accountable | Responsible | Consulted | Informed |
Incident/breach response coordination | Accountable | Informed | Responsible | Consulted |
Offboarding and data return verification | Responsible | Accountable | Consulted | Informed |
Publishing this table — even in a one-page form — resolves the single most common finding I see in supplier control audits: nobody disputes that a control should happen, but nobody can say who is actually responsible for making it happen on a given date. Give every row a name, not just a department, and review the RACI itself annually alongside your policy.
Service Level Agreements and Security Metrics
A supplier SLA that only measures uptime is incomplete for security purposes, and it's a gap I flag in almost every contract review I run. Security-relevant SLA metrics deserve the same contractual weight as availability, because a supplier can be fully "up" and still be leaking data, running unpatched software, or ignoring your notification obligations.
Security SLA Metric | Recommended Target (Tier 1) | Why It Matters |
|---|---|---|
Critical vulnerability patch timeline | 15 days from public disclosure | Unpatched known vulnerabilities are the most common exploited entry point |
Security incident notification | 24–72 hours from discovery | Determines how fast you can act to protect your own exposure |
Access revocation for departed supplier staff | 24 hours | Limits window of exposure from insider risk on the supplier side |
Response time to security-related support tickets | 4 business hours (Tier 1) | Distinguishes security responsiveness from general customer support SLAs |
Annual penetration test or equivalent assurance activity | Once per 12 months, summary shared on request | Confirms ongoing testing rather than a one-time certification snapshot |
Audit/evidence request turnaround | 10 business days | Prevents "we'll get back to you" from becoming an indefinite delay during your own audit prep |
Negotiate these metrics into the SLA schedule itself — not the general terms and conditions — so they're measurable, time-bound, and enforceable, ideally with defined remedies (service credits, termination rights) if consistently missed.
ICT Supply Chain Risk Register Template
Beyond the risk categories already discussed in Control 5.21, it helps to maintain a lightweight, dedicated register specifically for ICT supply chain dependencies, distinct from the general supplier register — because the ownership and remediation paths are often different (procurement/legal own supplier contracts; architecture/engineering own component and platform decisions).
Component/Dependency | Tier-1 Supplier | Known Fourth Parties | Risk Rating | Mitigation in Place |
|---|---|---|---|---|
Core cloud hosting | Cloud provider (name) | Regional data center operator, CDN provider | Medium | Multi-region architecture, provider SOC 2 reviewed |
Identity provider / SSO | IdP vendor | Underlying certificate authority | Low | MFA enforced, quarterly access review |
Payment processing | Payment gateway | Card network, acquiring bank | High | PCI DSS attestation on file, contractual liability terms |
Customer support platform | Helpdesk SaaS vendor | AI/chatbot sub-processor | Medium | Data processing addendum, sub-processor list monitored |
Firmware for network appliances | Hardware OEM/reseller | Chipset/firmware supplier | Medium | Signed firmware verification, authorized reseller only |
Ongoing Monitoring Cadence Summary
Pulling the monitoring detail from Control 5.22 into a single operational cadence makes it easier to staff and audit. This is the version I hand to clients as a working calendar template.
Frequency | Activity | Applies To |
|---|---|---|
Continuous | Contractual change notifications reviewed as received | All suppliers |
Monthly | SLA/availability dashboard review | Tier 1 suppliers |
Quarterly | Security KPI/scorecard review, incident log reconciliation | Tier 1 suppliers |
Semi-annually | SLA/performance review | Tier 2 suppliers |
Annually | Full risk re-assessment, certification/attestation refresh, audit or evidence request | Tier 1 suppliers |
Every 18–24 months | Risk re-assessment | Tier 2 suppliers |
At contract renewal | Full clause and tier review | All suppliers |
Ad hoc | Triggered review after incident, ownership change, or subcontractor change | Any supplier reporting a material change |
Common Mistakes in Supplier and Cloud Security
Almost every gap I find during a supplier-control audit traces back to one of a small handful of recurring failure patterns, regardless of industry or organization size. Recognizing them in your own environment before an external auditor does is the cheapest remediation you'll ever perform.
Mistake | Why It Happens | Consequence |
|---|---|---|
Treating the security questionnaire as the control, not the contract | Questionnaires feel like due diligence; contracts require legal negotiation, which is slower | Assessed risk never becomes an enforceable obligation |
No process for "shadow" suppliers business units onboard directly | Procurement policy exists but isn't enforced at the point of purchase | Unknown suppliers with unassessed access to data |
One-time assessment at onboarding, never repeated | Monitoring lacks an obvious owner or deadline trigger | Risk profile drifts silently as the supplier changes |
Assuming "the cloud provider handles security" | Marketing language from providers blurs the shared responsibility line | Misconfigured storage, IAM, or network settings go unnoticed |
No tested cloud exit plan | Exit planning feels irrelevant while the relationship is going well | Vendor lock-in discovered only during a forced, urgent migration |
Ignoring fourth-party/subcontractor risk entirely | Feels one step removed and hard to control | Supply chain compromise reaches your organization through an unassessed link |
Liability caps left at generic template values | Legal teams reuse boilerplate without risk-tier context | Financial exposure vastly exceeds any recoverable damages after an incident |
No linkage between supplier register and incident management | Supplier management and incident response sit in different teams | Vendor breach discovered from a news article instead of a notification clause |
Case Studies
Case Study 1 — Manufacturing: Tiering Catches What a Flat List Missed. A precision-parts manufacturer with roughly 220 active suppliers had a single flat vendor list with no risk differentiation. After implementing a four-tier model as described above, the security team discovered that a small firmware update vendor for its production-line controllers — previously treated as a low-priority IT purchase — actually had remote access credentials to the plant's operational technology network. Reclassified as Tier 1, the relationship was moved to an annual audit cycle, and the review uncovered that the vendor's remote access tool had a known unpatched vulnerability. The fix was applied before it was exploited. The company estimated that an OT-network compromise through that access path would have cost an estimated $6–9 million in production downtime alone, based on historical outage costs.
Case Study 2 — Healthcare: Cloud Shared-Responsibility Mapping Prevents a Repeat Incident. A regional healthcare technology provider had experienced a near-miss the year prior: a misconfigured cloud storage bucket briefly exposed a batch of de-identified but still sensitive research data before it was caught internally. Rather than treating it as a one-off configuration fix, the security team used the incident as the trigger to build a full shared-responsibility map across all 14 cloud services in use, tied to Control 5.23. The mapping exercise revealed that three additional services had the same class of misconfiguration risk (public-read defaults left unchanged). All three were remediated within six weeks, and the organization added automated configuration-drift monitoring going forward. At recertification audit, the auditor specifically cited the shared-responsibility documentation as strong evidence of a mature control — a marked contrast to the finding raised in the prior audit cycle.
Case Study 3 — Financial Services: Contract Renegotiation After a Tiering Exercise. A regional lender discovered, during a Control 5.19 supplier reassessment, that its loan-origination SaaS platform — onboarded five years earlier as a "convenience tool" — now processed the majority of new loan applications, including applicant financial data. The original contract had none of the clauses appropriate to that level of criticality: no right-to-audit, no breach notification timeline, and a liability cap of one month's fees. The security and procurement teams jointly renegotiated the contract, adding a 48-hour breach notification requirement, an annual right-to-audit clause, and a liability cap tied to potential regulatory exposure rather than invoice value. Eight months later, the vendor experienced a credential-stuffing incident against its admin portal; because of the renegotiated notification clause, the lender was informed within 36 hours — in time to force a password reset across affected accounts before any loan data was confirmed compromised.
Relating Supplier Controls to Incident Management and Continuity
Controls 5.19–5.23 don't operate in isolation. When a supplier or cloud incident actually occurs, it should flow directly into your organization's incident management process under Controls 5.24–5.28 — the same planning, assessment, response, and evidence-collection discipline you'd apply to an internal incident, triggered by the breach notification clause you negotiated under Control 5.20. If a critical supplier or cloud service goes down entirely, that's where business continuity and ICT readiness under Controls 5.29–5.30 take over — and it's worth stress-testing whether your continuity plans actually account for a Tier 1 supplier or cloud provider being unavailable, not just your own systems. The tiering exercise from Control 5.19 should feed directly into which suppliers get named, specifically, in your business continuity and disaster recovery plans.
There's also a direct line back to access control under Controls 5.15–5.18: every supplier relationship that involves system access needs the same access-rights discipline you apply to employees — provisioned on a documented need, reviewed periodically, and revoked promptly at offboarding. A supplier account that's never deprovisioned after a contract ends is one of the most common findings I see in access reviews, and it's a direct Control 5.22 monitoring failure as much as an access control failure.
Cross-Framework Notes: SOC 2, PCI DSS, and DORA
If your organization also holds or pursues other assurance frameworks, supplier controls rarely need to be built twice. A SOC 2 report's vendor management and subservice organization criteria map closely to Controls 5.19–5.22, and many organizations satisfy both by running a single supplier risk program with framework-specific evidence exports. PCI DSS's service provider management requirements apply to any third party that stores, processes, or transmits cardholder data — if payment processing is in scope, align your Tier 1 criteria with PCI's service provider obligations so you're not maintaining two parallel assessment tracks. And for financial entities operating in or with the EU, DORA's ICT third-party risk management requirements are considerably more prescriptive than ISO 27001 alone — including a formal register of information for all ICT third-party arrangements and specific critical-provider oversight — so treat ISO 27001 Controls 5.19–5.23 as a strong foundation for DORA readiness, not a substitute for it. None of these frameworks are automatically satisfied by ISO 27001 certification alone; each has its own specific evidentiary requirements, and ISO 27001 should be positioned as supporting those obligations rather than replacing them.
Recording 5.19–5.23 in Your Statement of Applicability
Every one of these five controls needs an entry in your Statement of Applicability, and this is a step I see rushed more often than any other part of the SoA. It's not enough to mark Controls 5.19–5.23 as "applicable" with a one-line justification like "we use suppliers." Auditors expect the SoA entry for each control to point to a specific implementation artifact — the supplier security policy for 5.19, the contract template/security schedule for 5.20, the supply chain risk register for 5.21, the monitoring calendar for 5.22, and the cloud shared-responsibility mapping for 5.23. If your organization genuinely has no suppliers or cloud services in scope (increasingly rare), a documented exclusion rationale is acceptable — but for the overwhelming majority of organizations pursuing certification, all five controls will be applicable, and the SoA should say precisely where the evidence lives, not just that it exists somewhere.
It's also worth building a shared vocabulary before you sit down with an auditor or a new team member. Terms like "fourth-party risk," "shared responsibility model," and "right-to-audit" get used loosely in casual conversation but carry precise meaning in an ISO 27001 context — our ISO 27001 glossary of terms is a useful reference to make sure your policy documents, contracts, and audit responses all use these terms consistently, rather than having procurement, legal, and security each mean something slightly different by "supplier risk assessment."
Preparing Supplier Evidence for Your ISO 27001 Audit
Auditors sampling Controls 5.19–5.23 tend to follow a predictable pattern: pick a handful of suppliers across different risk tiers, and trace each one from initial risk assessment through contract terms to the most recent monitoring activity. Knowing this pattern in advance lets you prepare an evidence pack that makes the audit faster and, frankly, less stressful for whoever has to sit across from the auditor.
Audit Question | Evidence to Have Ready |
|---|---|
"Show me your supplier risk assessment process." | Documented policy/procedure, plus a completed example for a real supplier |
"Pick a critical supplier — show me the risk tiering rationale." | Tiering criteria and the specific scoring for that supplier |
"Where in the contract are the security requirements?" | The actual signed contract or security schedule, not a template |
"When was this supplier last reviewed?" | Dated monitoring record, SLA scorecard, or re-assessment log |
"What happens if this supplier has a breach?" | Breach notification clause plus a walkthrough of the internal escalation path to incident management |
"How do you know what cloud services are in use, and who's responsible for what?" | Cloud service inventory plus shared-responsibility mapping per service |
"What's your plan if this supplier goes out of business or you need to exit?" | Documented exit/continuity plan, referenced in business continuity planning |
Auditors are not trying to catch you out with trick questions — they're testing whether the process you describe in your policy is the same process that actually happened, on a specific, real supplier, with dates attached. Rehearse this exact walkthrough internally, on two or three real suppliers across different tiers, before your Stage 2 audit, and you'll find the actual audit session goes almost exactly as you rehearsed it.
The Strategic Opportunity in Getting This Right
It's easy to frame supplier and cloud security controls as defensive plumbing — the unglamorous work of chasing questionnaires and clause negotiations. I'd push back on that framing. Organizations that can show a customer, a regulator, or an acquirer a mature, evidenced supplier risk program are answering the single question that increasingly decides deals before price does: "Can we trust what happens to our data once it leaves your building?" I've watched security-mature vendors win competitive bids specifically because they could produce a tiered supplier register and a tested cloud exit plan on request, while a cheaper competitor could only offer reassurance. Getting Controls 5.19–5.23 right isn't just about passing your next audit — it's a commercial differentiator in a market where every buyer has already been burned by someone else's vendor.
It also protects you from the exact scenario that opened this article. Cascade Freight Analytics survived its incident, but at a cost that a properly tiered, contracted, and monitored supplier relationship would have avoided almost entirely — not because the underlying vendor mistake wouldn't have happened, but because a 24-hour breach notification clause, a right-to-audit exercised eighteen months earlier, or a basic cloud configuration review would have caught it long before a researcher did.
If you're building or maturing this part of your ISMS, don't try to build every artifact from scratch. Pull a structured ISO 27001 Risk Register Template to bring supplier risk into the same register as everything else, use the Annex A — All 93 Controls at a Glance cheat sheet to see exactly how 5.19–5.23 sit alongside the rest of your control set, and check your document set against the ISO 27001 Mandatory Documents Checklist to confirm your supplier policy and risk assessment records are where an auditor expects to find them. If you're earlier in the journey, the Complete ISO 27001 Implementation Guide eBook walks through sequencing supplier controls alongside the rest of your ISMS build, and our ISO 27001 Gap Analysis Tool will flag exactly where your current supplier program falls short of certification readiness before an external auditor does it for you.
Supplier and cloud risk isn't going away — if anything, the trend toward specialized SaaS, managed services, and cloud-native architecture means your organization's attack surface increasingly lives outside your own walls. Controls 5.19–5.23 give you a structured, auditable way to own that risk anyway.
"The organizations I trust most aren't the ones with zero vendor incidents — that's luck, not maturity. They're the ones who can tell me, in detail, exactly what happens the moment a vendor incident occurs, because they've already mapped it, contracted for it, and rehearsed it." — Elena Kovac, ISO 27001 Lead Auditor, Baltic Assurance Group
"Shared responsibility isn't a legal disclaimer the cloud provider hides in an appendix — it's an engineering decision your own team has to make explicitly, service by service, or someone will make it for you by default." — Sana Malik, Cloud Security Architect, Fenwick Data Systems