ISO 27001 Supplier Security Policy: The 5 Annex A Controls, Risk Tiering, and a Free Policy Skeleton

An auditor reviewing your ISO 27001 supplier controls will ask a version of the same question five different ways: “show me how you decided this vendor was safe to onboard.” If the honest answer is a one-line NDA and a gut feeling, that’s a nonconformity waiting to be written up. Supplier relationships are one of the most heavily tested areas of Annex A precisely because industry incident data consistently points to third parties and supply chains as a leading source of breaches — and a written policy that exists but was never actually applied to a real vendor decision won’t survive an internal audit, let alone a certification audit.

This guide covers the exact Annex A controls a supplier security policy needs to address, why this is arguably the single strongest overlap point between NIS2 and ISO 27001, a risk-based tiering approach so you’re not running full due diligence on your office coffee supplier, and a free mini policy skeleton you can adapt today — not a teaser, a genuinely usable starting draft.

The Five Annex A Controls a Supplier Security Policy Must Address

ISO/IEC 27001:2022 Annex A groups supplier-related requirements into five controls, all sitting in the Organizational theme. Together they cover the full lifecycle of a supplier relationship, from the decision to onboard through to the decision to exit.

Control	Title	What it requires in practice
A.5.19	Information security in supplier relationships	The overarching policy: a defined process for identifying and assessing information security risk before engaging any supplier [1]
A.5.20	Addressing information security within supplier agreements	Specific security terms written into the contract itself — confidentiality, incident notification timelines, audit rights, sub-processor disclosure, exit arrangements
A.5.21	Managing information security in the ICT supply chain	Extending scrutiny to a supplier’s own suppliers and subcontractors, and to the security of the hardware/software components they provide
A.5.22	Monitoring, review and change management of supplier services	Ongoing checks that a supplier is still delivering the agreed security level, and a defined process for handling changes to their service
A.5.23	Information security for use of cloud services	A dedicated process for acquiring, using, managing, and exiting cloud services, reflecting that security responsibility is shared with the provider [2]

A.5.19 is the policy layer — the “why and how we decide” — while A.5.20 through A.5.23 are its operational extensions: contract clauses, ICT-specific scrutiny, ongoing monitoring, and a cloud-specific carve-out. A.5.23 was introduced as a new, standalone control in the 2022 revision precisely because generic supplier management doesn’t cover cloud’s non-negotiable agreements and shared-responsibility model well on its own. [2] A policy that only addresses A.5.19 and stops there is the single most common gap auditors flag here — it reads as complete but leaves the contract, ICT supply chain, and cloud obligations undocumented.

Why This Is the Strongest NIS2-ISO 27001 Overlap Area

If you’re already NIS2-compliant, this is likely the section of Annex A where you have the least new work to do. Article 21(2)(d) of the NIS2 Directive requires entities to address “supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers.” [3][4] Article 21(2) also requires entities to weigh “the vulnerabilities specific to each direct supplier and service provider” and “the overall quality of products and cybersecurity practices of their suppliers and service providers, including their secure development procedures.” [4]

Read that language next to A.5.19 through A.5.21 and the overlap is close to one-to-one: both frameworks want a documented risk assessment before onboarding, both want it to weigh the specific supplier’s vulnerabilities rather than a generic checklist, and both extend that scrutiny into the ICT/software supply chain rather than stopping at the direct contract. This tracks with the roughly 70-80% foundational overlap between NIS2 and ISO 27001 generally — and supplier security sits toward the high end of that range, not the low end. For the full control-by-control technical mapping between the two frameworks, see our NIS2 vs ISO 27001 comparison.

Where the two frameworks diverge is format and depth, not intent. NIS2 doesn’t prescribe a specific document structure — an entity can satisfy Article 21(2)(d) with a risk register and a set of internal procedures. ISO 27001 certification requires that same risk logic to show up as a controlled, versioned policy document mapped explicitly to Annex A control numbers, plus the A.5.23 cloud-specific process that Article 21(2)(d) doesn’t call out separately. If you’ve already built a working NIS2 supplier risk process, you are not starting from zero on this control group — you’re reformatting and extending it. Our guide to pursuing ISO 27001 after NIS2 compliance covers the broader business case and head-start argument in more depth.

Risk-Based Supplier Tiering: Not Every Vendor Needs the Same Scrutiny

A cleaning contractor and your cloud hosting provider are both “suppliers,” but treating them identically wastes effort on the low-risk one and under-scrutinizes the high-risk one. Neither NIS2 nor ISO 27001 mandates a specific tiering model, but both frameworks’ emphasis on risk proportionality — Article 21(2)(d)’s focus on “vulnerabilities specific to each direct supplier” [4] and A.5.19’s risk-assessment basis — effectively requires you to have one. A flat, one-size-fits-all supplier checklist is a common finding auditors treat skeptically, because it suggests risk wasn’t actually assessed, just documented.

Tier	Criteria	Typical due diligence	Review frequency
Tier 1 — Critical	Access to sensitive/regulated data, or failure would disrupt core service delivery (e.g. cloud host, core SaaS, MSSP)	Full security questionnaire, contract clauses per A.5.20, evidence of the supplier’s own certifications, on-request audit rights	Annually, plus after any material change
Tier 2 — Moderate	Limited data access or a supporting (not core) system dependency	Standard questionnaire, baseline contract clauses, self-attestation accepted	Every 1-2 years
Tier 3 — Low	No data access, no system dependency (e.g. office supplies, facilities)	Standard confidentiality terms only	At contract renewal

The tiering decision itself should be traceable back to your organization’s broader risk assessment criteria, not invented separately for suppliers — our ISO 27001 risk assessment methodology guide covers how to build the underlying likelihood/impact scoring this tiering model borrows from. Once a supplier is tiered, that tier should drive everything downstream: which contract clauses apply, how often you review them, and how quickly a security incident at that supplier needs to reach you under your own incident response policy.

Free Mini Supplier Security Policy Skeleton

Below is a condensed, genuinely usable starting-point policy. It is intentionally short and generic — enough structure to put something real in front of an auditor or a colleague today, not a substitute for a policy scoped to your specific supplier base and contract language.

Purpose
To ensure that information security risks arising from suppliers and third-party service providers, including cloud services, are identified, assessed, and managed throughout the supplier relationship lifecycle.

Scope
This policy applies to all suppliers, vendors, contractors, and service providers — including cloud service providers — that access, process, store, or transmit the organization’s information, or that support systems critical to service delivery.

Policy Statements

• All prospective suppliers must undergo a documented information security risk assessment and be assigned a risk tier before any contract is signed or system access is granted (A.5.19).
• Contracts with suppliers handling sensitive data or critical systems must include defined security requirements covering confidentiality, incident notification timelines, and audit rights (A.5.20).
• Suppliers providing ICT hardware, software, or development services must be evaluated for the security practices of their own upstream supply chain, not only their direct deliverable (A.5.21).
• Supplier security performance must be reviewed at a frequency proportional to their assigned risk tier, and any material change to a supplier’s service must trigger a re-assessment (A.5.22).
• Cloud services must be acquired, used, and exited only in accordance with a documented process that defines data location, encryption, and the division of security responsibility between the organization and the provider (A.5.23).
• Supplier access to organizational systems and data must be revoked, and any organizational data held by the supplier returned or securely destroyed, at contract termination (A.5.20).

Role	Responsibility
Supplier/Business Owner	Initiates the risk assessment before engaging a new supplier; flags material service changes
Information Security Lead	Defines security requirements per tier, reviews cloud service due diligence, approves risk tier assignment
Procurement/Legal	Embeds required clauses into contracts; maintains the supplier register
ISMS Owner/Top Management	Approves risk acceptance for Tier 1 suppliers; reviews this policy annually

Review Cadence
This policy is reviewed at least annually, or following any material change to the organization’s supplier base, technology stack, or applicable legal and regulatory requirements.

Contracts, Monitoring, and the Supplier Register in Practice

A policy document alone doesn’t satisfy A.5.20 through A.5.23 — it has to translate into artifacts an auditor can actually inspect. Three are worth building deliberately rather than improvising when a certification audit is scheduled:

Contract clauses (A.5.20). At minimum, Tier 1 and Tier 2 supplier contracts should specify an incident notification window (a fixed number of hours or days, not “promptly”), the right to request evidence of the supplier’s own security controls, and what happens to your data and access at contract end. Generic vendor paper rarely includes all three unmodified.

Ongoing monitoring (A.5.22). “Monitoring” doesn’t have to mean continuous technical scanning of every supplier — for most organizations it means a scheduled review against the cadence set by the supplier’s tier, plus an ad hoc trigger whenever the supplier changes its service, subcontracts a function, or discloses an incident of its own. The review itself, and its outcome, needs to be recorded somewhere — an email thread that nobody can find eighteen months later is not evidence.

Cloud-specific due diligence (A.5.23). Cloud providers typically operate on standard, non-negotiable contract terms, so due diligence shifts from “negotiate better clauses” to “document the shared responsibility model”: what the provider secures, what you’re responsible for, and how you’d exit if needed. Treating a cloud provider like any other Tier 1 supplier is a common reason A.5.23 shows up as a separate finding even when A.5.19 and A.5.20 pass.

FAQ

Do I need five separate policy documents for A.5.19 through A.5.23?
No. A single supplier security policy can address all five controls, provided each obligation is clearly traceable to its control number — which is exactly what an auditor is checking for. Splitting it into multiple documents is a formatting choice, not a certification requirement.

Is a NIS2-compliant supplier risk process automatically “ISO-ready”?
Close, but not automatic. Article 21(2)(d)’s risk-based approach to direct suppliers and the ICT supply chain maps closely onto A.5.19-A.5.21, [3][4] but ISO 27001 certification also requires the documented A.5.23 cloud process and a version-controlled policy mapped explicitly to Annex A control numbers — two things a NIS2 programme doesn’t always produce as a byproduct.

How many suppliers actually need full Tier 1 due diligence?
There’s no fixed percentage in the standard — it depends entirely on how many suppliers genuinely access sensitive data or sit on your critical service path. In most organizations that’s a minority of the total supplier list; the tiering exercise itself is what reveals the real number rather than assuming it in advance.

Does ISO 27001 require a formal supplier register or inventory?
The standard doesn’t mandate a specific document called a “register,” but without one it’s difficult to demonstrate that every supplier has been risk-assessed, tiered, and reviewed on schedule — which is what A.5.19 and A.5.22 are actually testing for. In practice, almost every certified organization maintains one.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

• [1] ISO 27001:2022 Annex A Control 5.19 Explained, ISMS.online
• [2] ISO 27001:2022 Annex A Control 5.23 Explained, ISMS.online
• [3] NIS 2 Directive, Article 21 — Cybersecurity risk-management measures, nis-2-directive.com (verbatim mirror of Directive (EU) 2022/2555)
• [4] Directive (EU) 2022/2555 (NIS2), official consolidated text, EUR-Lex