---
title: "ISO 27001 Annex A 5.21: information security in the ICT supply chain"
canonical: https://www.grcmana.io/vault/iso-27001/annex-a-5-21-information-security-in-the-supply-chain
published: 2023-03-06
updated: 2026-10-07
author: "Harry West"
framework: "ISO 27001"
control: "A.5.21 Managing information security in the ICT supply chain"
journeyStage: implementation
---

# ISO 27001 Annex A 5.21: information security in the ICT supply chain

## Key takeaways

ISO 27001 Annex A 5.21 asks you to look through direct vendors to the software components, subcontractors and hardware origins beneath them. A 25–250 person firm meets it with a procurement checklist, flow-down terms for critical vendors and automated dependency tracking. Auditors sample one or two critical suppliers and test whether the process worked in a real event such as Log4j.

- **Scope** — Control A.5.21 extends supplier management below your direct vendors to software components, subcontractors and hardware origins, so you can show what your technology is built on.
- **Classification** — Preventive control touching confidentiality, integrity and availability: it stops compromised or counterfeit technology reaching production and plans ahead for critical products being discontinued.
- **Core expectations** — Five expectations: acquisition-time security requirements, flow-down to subcontractors, visibility of components, verification of what arrives, and succession plans for critical components or providers that disappear.
- **Proportionate path** — A procurement checklist, flow-down clauses for critical vendors and automated dependency tracking meet the control at 25–250 staff. SBOM demands on every SaaS tool are over-engineering.

A client's security team emails on a Monday morning. A library-level flaw is all over the news, and they want to know whether you are exposed. You can name your direct vendors, but not what those vendors are built on. ISO 27001 Annex A managing information security in the ICT supply chain, control A.5.21, is the control that turns that silence into an answer.

This guide covers what A.5.21 requires, how it differs from A.5.19 and A.5.20, a seven-step path for a 25–250 person firm, what auditors sample and how to automate the evidence. It is written for the CTO, Head of IT or security lead heading into a Stage 2 or surveillance audit.

## What does ISO 27001 Annex A managing information security in the ICT supply chain cover?

ISO 27001 Annex A managing information security in the ICT supply chain, control A.5.21, asks you to look through direct vendors to what they are built on: software components, subcontractors and hardware origins. It is a preventive control: it keeps compromised or counterfeit technology out before it reaches production, and it protects confidentiality, integrity and availability.

Three layers sit below your direct vendors, and each fails differently. A software component, such as an open-source library inside a vendor's product, can carry a flaw you never see. A subcontractor, such as the facility behind your hosting provider, handles your data under terms you never signed. A hardware origin can mean a counterfeit or tampered device that is compromised before first boot.

Confidentiality, integrity and availability can each fail through the supply chain. A poisoned dependency can leak data, a tampered component corrupts what you process, and a discontinued product strands the service built on it.

The 2013 edition grouped this topic under supplier relationships. The 2022 control is more technical, because it expects you to know what your technology is made of, not only whom you pay. Searches for ISO27001 IT supply chain management usually mean this control.

## What does ISO 27001 Annex A 5.21 require of you?

ISO 27001 Annex A 5.21 requires five things: security requirements stated when you acquire technology, flow-down of those requirements to your suppliers' own suppliers, visibility of what is inside products, verification that what arrives is genuine and behaves as specified, and plans for critical components or providers disappearing.

Each expectation leaves a different trace in your records:

- **Acquisition-time requirements.** State what you need before you buy: a supported product, security update commitments, breach notification and, for bespoke work, evidence of secure development. The requirement exists before the purchase order does.
- **Flow-down.** Oblige direct suppliers to hold their own suppliers to equivalent security obligations. Your contract is the only lever you have over a layer you cannot see.
- **Component visibility.** Seek component lists, the product's security functions and its secure-configuration needs. A software bill of materials (SBOM), which is a component inventory, is the usual form.
- **Verification of what arrives.** Confirm that products are genuine and behave as specified. For most firms that means authorised channels and signature checks, not forensics.
- **Succession planning.** Know which components or providers you cannot operate without, and what you would do if one vanished through insolvency, acquisition or end-of-life.

Read the five as questions you can answer, not deliverables you must produce for every vendor. The control scales down further than its enterprise reputation suggests, because depth is a risk decision. A small firm and a large firm both need an answer for each expectation. Only the larger one needs a team to produce it.

## How does A.5.21 differ from A.5.19 and A.5.20?

A.5.19 governs the suppliers you contract with directly, and A.5.20 puts security terms into those agreements. A.5.21 reaches through them to components, subcontractors and provenance, the layers where you hold no contract. Auditors test the supplier register under A.5.19 and the reach-through under A.5.21, so the evidence differs.

Think of the five supplier controls as a relay, each handing evidence to the next:

- **A.5.19, supplier relationships:** the supplier register, with tiering and criticality.
- **A.5.20, agreements:** the contract machinery, including clauses that carry flow-down and breach-notification windows.
- **A.5.21, ICT supply chain:** the technology subset of the register, with dependencies, subcontractor answers, component disclosures and succession notes.
- **A.5.22, monitoring:** the ongoing review of the commitments you have recorded.
- **A.5.23, cloud services:** the cloud-specific case.

A.5.21 depends on the tiering from A.5.19 and the contract machinery of A.5.20 being in place. Without them, flow-down is an aspiration with nowhere to land.

A supplier register that stops at the vendors you pay isn't a supply-chain register.

The practical test is one question per critical vendor: what is behind this service, and where is the answer recorded? If the register cannot answer it, the gap belongs to A.5.21 rather than A.5.19.

## Why do SolarWinds, Log4j and MOVEit make upstream risk an enterprise diligence issue?

SolarWinds, Log4j and MOVEit each began a layer or two below anyone's direct supplier, then cascaded. Clients now ask within days: are we exposed, and how do we know? A firm with no view inside its stack cannot answer, and DORA makes ICT supply-chain oversight explicit for financial-sector clients, who push it onto providers.

Without that view, engineers search repositories one by one while the client waits. What answers the question is a component-level list built before the event, not during it.

Three incidents show three different entry points:

- **SolarWinds:** a trusted vendor's software update became the delivery route.
- **Log4j:** a logging library embedded in countless products, so customers often did not know they ran it.
- **MOVEit:** a file-transfer product whose flaw reached the firms relying on it, and their clients.

[ENISA threat landscape research](https://www.enisa.europa.eu/news/enisa-news/understanding-the-increase-in-supply-chain-security-attacks), published in 2021, found that for 66% of the supply chain attacks analysed, suppliers did not know, or failed to report, how they were compromised. A vendor's "no incident" answer is only as good as its own visibility. You need your own view of what you depend on.

This is where enterprise diligence is heading. Being able to say what you would do about the next Log4j, and to show the SBOM request or the vendor attestation on file, is becoming a condition of selling into regulated markets. It is no longer a mark of sophistication.

## How do you implement A.5.21 in a 25–250 person organisation?

Implement A.5.21 in seven proportionate steps: scope from the supplier register, add a procurement checklist, secure flow-down commitments from critical vendors, ask what is inside the software, verify what arrives, control support access, and write succession answers for components you cannot lose. Allow a week to start, then run it continuously.

Work through the steps in this order, because each one feeds the next:

1. **Scope from the supplier register.** Take the register built under A.5.19 and mark the technology suppliers: software products, cloud platforms, managed IT and hardware. Note what depends on each. Then add the layer below, meaning subcontractors for critical vendors and the open-source libraries in what you build. You end with a scope an auditor can read in minutes.
2. **Add a procurement checklist.** Turn the acquisition-time requirements above into a short standard that every new technology purchase must meet. At this scale it is a checklist in procurement, not a framework. Brief the people who buy and renew tools, engineering leads included, so no renewal skips it.
3. **Secure flow-down commitments.** For critical vendors, ask two questions at onboarding and renewal: who do you subcontract to for the service we buy, and will you hold them to equivalent security obligations? The [NCSC supply chain control guidance](https://www.ncsc.gov.uk/collection/supply-chain-security/principles-supply-chain-security/ii-establish-control) says to include security requirements in the sub-contracts your suppliers let. Where a large vendor will not amend its paper, record its published terms and the residual gap.
4. **Ask what is inside the software.** Request an SBOM where vendors will give one, or their published vulnerability-disclosure and component policy where they will not. You can then answer "are we exposed?" without emailing every vendor in one frantic week. The next section covers refusals.
5. **Verify what arrives.** Buy through authorised channels only, and validate signatures or checksums on firmware and software before deployment. It is minutes of effort that closes the counterfeit-and-tampering door. Lean on current certificates and SOC 2 reports rather than your own audits, because you will never inspect a vendor's factory.
6. **Control support access and incident flow.** Put vendor remote access for maintenance on scoped accounts, with MFA, defined engagement rules and logging. It is a supply-chain attack path, not a convenience. Agree how incident information flows both ways with critical suppliers, including how fast they must tell you about a compromise.
7. **Write succession answers.** For the handful of components or providers you cannot operate without, record the alternative product, the data-export route or the supported migration path. Flag anything approaching end-of-life. A one-page note turns an insolvency or forced migration into a planned move.

The control fails at the point of purchase, not in the policy document.

At this scale, the week of setup buys continuous coverage. After that, the work is renewals and the occasional new purchase passing through the checklist.

## What if SaaS vendors refuse to share an SBOM?

Take what the vendor publishes: vulnerability-disclosure policy, security advisories, sub-processor list, certificates. Record the residual gap against the vendor's tier. Reserve SBOM demands for software your service genuinely stands on, and make the request a selection criterion next time. An SBOM is an inventory, not a response plan.

Commodity SaaS rarely lists its components, and a refusal is not an audit failure. It is a known gap that you record. For each such vendor, note what you collected, what remains unknown and why the residual risk is acceptable for that tier.

The [NCSC analysis of SBOMs and inventory](https://www.ncsc.gov.uk/blog-post/sboms-and-the-importance-of-inventory) describes an SBOM as a way of recording component inventory, which other tools use to find software with known vulnerabilities. It supports vulnerability response and does not replace it. An SBOM that nobody matches against new advisories adds paperwork, not protection.

Two pitfalls sit either side of this fallback:

- **Over-engineering.** Demanding SBOMs from every SaaS tool, or running Common Criteria expectations at a 40-person firm.
- **Never asking.** Skipping the question until the next library-level flaw, then asking every vendor at once.

Tiering keeps the effort where the exposure is:

| Vendor tier | What to collect | What to record |
| --- | --- | --- |
| Foundational: platforms your service stands on | SBOM or component policy, sub-processor list, current independent assurance, flow-down clause | Succession note and any gap the vendor will not close |
| Important: managed IT and SaaS holding customer data | Vulnerability-disclosure policy, security advisories, sub-processor list, certificates | Residual gap, with the date you last checked |
| Commodity: low-impact tools | The published security page | The tier decision and why no further ask was made |

## What do auditors ask and sample for A.5.21, and how are findings graded?

Auditors typically pick one or two critical technology suppliers and trace the acquisition record, contract flow-down language, current assurance and remote-access arrangements. A recent vulnerability event such as Log4j is the favourite live test. A total absence of supply-chain consideration grades major; a single missing SBOM grades minor, aggregating to major as a pattern.

Expect five questions, each answered by a specific exhibit:

- **"Which of your suppliers are technology suppliers, and which could take you down?"** The supplier register, with technology vendors, criticality and dependencies marked.
- **"What security requirements did you put to the vendor when you bought this platform?"** The acquisition checklist and a completed example from a recent purchase.
- **"Your hosting provider subcontracts. How do you know, and what binds them?"** Contract flow-down language, breach-notification windows and the vendor's own answer about who sits behind the service.
- **"When Log4j broke, how did you work out whether you were exposed?"** The trail itself, with SBOMs, component disclosures or vendor vulnerability policies on file.
- **"This product goes end-of-life next year. What is the plan?"** The succession note for single-point-of-failure technology.

Expect to be asked for supporting records too: authorised-reseller purchase trails, checksum notes for deployed images, scope-checked independent assurance, and scoped accounts, MFA settings and session logs for vendor support channels.

That grading is GRCMANA's reading of certification-body practice, not wording in the standard, and it applies where dependencies are material. The major case means no acquisition requirements and no subcontractor visibility for critical vendors. An unrenewed attestation sits with the missing SBOM as a minor.

The strongest exhibit is the record of how you checked exposure during a real event. A dated ticket showing who searched, what they found and what was patched answers the question faster than any policy.

## How can GRC engineering automate A.5.21 evidence?

Treat the supply chain as data. Keep technology suppliers, the services they underpin, subcontractor disclosures and assurance expiry as structured records, so "what is our exposure to X?" becomes a query. Add CVE matching against SBOMs, dependency scanning in CI, sub-processor page monitoring and a procurement gate that enforces the security checklist before spend.

Where vendors supply component lists, matching a new CVE against them can be automated. For your own code, dependency scanning in CI is this control applied to the software you ship. It covers the open-source layer, which is where many real incidents originate.

Sub-processor watch turns a contractual promise into a signal. Monitoring critical vendors' published subcontractor pages means a notification clause produces something you actually receive, and it feeds the A.5.22 reviews.

A supplier questionnaire answered once at onboarding is a snapshot, not a control.

The procurement gate puts the acquisition checklist into the request form, so answers are captured before anyone approves the spend. The workflow enforces the requirement instead of anyone's memory, and buyers stop sitting outside the loop.

Judgement stays with people: which dependencies need deep assurance, where the acquisition bar sits, and who owns the exposure answer when a supply-chain event lands. That is Fractional CISO work, while the inventory, matching, monitoring and gating are engineered deliverables.

The commercial upside is speed. When a client asks whether you are exposed to the next Log4j, you answer in minutes with a query result and a trail attached.

## Frequently asked questions

### How does A.5.21 handle hardware provenance without defence-grade forensic testing?

Proportionately. Buy from authorised channels, keep the reseller purchase trail, check seals on delivery and validate firmware signatures where the vendor provides them. Record the checks in the ticket that deploys the device. Anti-counterfeit forensics belong to defence and critical-infrastructure supply chains, not a mid-market services firm.

### Who should own ISO 27001 Annex A 5.21 inside a 50-person organisation?

Whoever owns technology buying and renewal, usually the CTO or Head of IT, with security setting the requirements. Procurement alone rarely fits, because the questions are technical. If purchases are scattered, route every request through one gate with a named approver.

### Where does A.5.21 stop and A.5.23 cloud services begin?

A.5.23 covers buying, using, managing and leaving cloud services, while A.5.21 covers technology dependencies generally. A cloud platform therefore sits under both. We recommend filing the cloud arrangement itself under A.5.23 and the questions about that provider's components and subcontractors under A.5.21.

### Does A.5.21 cover the open-source libraries in our own code?

In practice, yes. Libraries are not suppliers you contract with, so they never appear in a vendor register. Include transitive dependencies, the libraries your libraries pull in, because a flaw there is invisible from your own code. Generate the list from each repository's lockfile at build time, and name who triages the findings.