A.5.21 ICT supply chain security: requirements and evidence

What A.5.21 asks for, and why it is harder than supplier management

When an auditor or customer asks how ICT supply chain risk is managed, the organization needs a documented process for the information security risks that come through the products and services it buys to build, run and deliver its own services. A.5.21, Managing information security in the ICT supply chain, asks for exactly that: defined processes and procedures, applied in practice, that identify and manage these risks. The control carries forward ICT supply chain control A.15.1.3 from the 2013 edition, so organizations that mapped the older control will find its intent largely unchanged, though the wording and attributes in the 2022 edition are new. Confirm the current text and implementation guidance in ISO/IEC 27002:2022 before you draft your own procedure.

The distinction from A.5.19 and A.5.20 matters for scoping. A.5.19 covers the general approach to supplier risk, A.5.20 covers what goes into each agreement, and A.5.22 covers monitoring and change after signature. A.5.21 reaches further, into the ICT components that a direct supplier relies on: the sub-suppliers, open-source libraries, container base images, firmware and hardware parts that end up inside your systems. Your direct supplier can pass a due diligence review and still ship a component whose origin, maintainers or build pipeline you never saw. Asking a supplier to flow down security requirements, and checking that they do, is usually the hardest part.

Three things make this control harder than ordinary supplier management. First, the dependency tree is deep and changes often, so an inventory that was accurate at the last audit can be wrong today. Second, provenance is hard to prove: you need to know where a component came from, which version was built, and whether the artifact you deploy matches what was built. Third, integrity can fail silently after release, through a compromised package or a modified build. A practical starting point is to ask each ICT supplier for a software bill of materials, and to confirm with them which sub-suppliers and components are in scope. Tools such as OWASP Dependency-Track can consume CycloneDX SBOMs and track known vulnerabilities and license risk against them, which turns a one-off questionnaire into evidence you can sample.

Which ICT products, components and suppliers fall in scope for A.5.21

A.5.21 reaches well beyond the suppliers you contract with directly. The decisions below set how far the supply chain work extends, and each one changes the evidence you must produce. Settle them in writing before you build the process, so the scope matches what your assessor will sample.

What counts as ICT

Start with the products and services your organization uses to process, store, transmit or control information: software, cloud services, network equipment, endpoints, managed services and embedded devices. A.5.21 is about ICT products and services, so a supplier that delivers no technology can still fall outside it while a commodity vendor that ships software does not. Check the boundary against your asset inventory (A.5.9) rather than against procurement categories, because the two often disagree.

How deep sub-supplier tiers go

Decide how many tiers you will trace, for example whether you stop at the vendor that sells to you or follow the hosting provider, the component maker and the contractor beneath it. Most organizations can only reach the first tier through contract clauses, so the second and third tiers need a stated approach: a flow-down requirement, a disclosure obligation or a risk-based sampling rule. Write down the depth you chose and the reason for it.

Open-source components and dependencies

Decide whether open-source libraries, container base images and third-party packages are supplier components under A.5.21. In most ICT stacks they are, even when no supplier invoices for them. Recording them in a software bill of materials and tracking them for known vulnerabilities and license risk gives you the component-level view this control expects. Confirm who owns the update decision for each dependency.

Build pipelines and developer tooling

Decide whether your build systems, code repositories, package registries and CI runners are in scope. A compromised build step can alter a product that passed every review, so many organizations treat them as ICT suppliers to their own release process. Confirm who administers each pipeline, which external services it calls, and how signing keys and build outputs are protected and recorded.

Hardware and firmware

Decide how you will verify hardware and firmware from manufacturers, distributors and refurbishers. Check whether devices arrive in sealed packaging, whether firmware images are signed and checked against published hashes, and whether the vendor commits to security updates for the product's expected life. Where a device cannot be verified or patched, record the risk decision and the compensating controls, because an assessor will ask how you handled it.

Exceptions and their records

Decide which suppliers fall outside the process, such as one-time purchases, free tools or products used only in isolated test environments, and document the reason for each exclusion. Exclusions reviewed at a set interval show a deliberate decision rather than an omission. Ask your assessor early whether they expect the exclusion list to appear in your risk assessment and Statement of Applicability.

How an assessor tests A.5.21

This table walks through the test steps an assessor typically follows for A.5.21, the evidence each step asks for, and the findings that come up most often. Read each row as a question the assessor will put to the organization, and prepare the answer and the record before the audit starts.

Test step	What the assessor checks	Evidence requested	Common finding
Review the documented process	Whether a defined process covers ICT supply chain risks, who owns it, and whether it reaches beyond direct suppliers to the components they rely on	Supply chain risk procedure, scope statement, role assignments, approval records	Process exists only for direct suppliers, with no reference to component or sub-supplier risk
Sample ICT suppliers and products	Whether the sampled ICT products and services were assessed under the process before adoption and are still assessed	Inventory of ICT suppliers, risk assessment records for a sample, dates of last review	Inventory of suppliers is incomplete or does not list the products actually in use
Trace risk decisions to procurement	Whether the risk assessment result changed the purchase, contract or deployment decision, or was recorded and then ignored	Risk ratings, procurement requests, approval notes, accepted-risk sign-off	No visible link between the risk assessment and procurement, so the assessment reads as paperwork
Check sub-supplier requirements	Whether contracts or onboarding steps require suppliers to disclose and manage the critical sub-suppliers and components they use	Contract clauses or security addenda, sub-supplier lists provided by suppliers, notification terms	Suppliers are not required to disclose sub-suppliers, so the organization cannot see the second tier
Test component provenance	Whether the organization knows where critical software and hardware come from and can confirm origin	Software bills of materials, component lists, approved source records, vendor attestations	Provenance is assumed rather than recorded, with no SBOM or equivalent for critical products
Test integrity checks in practice	Whether integrity checks such as signature or hash verification happen before products are deployed or updated, and whether the checks are performed	Verification logs, pipeline or deployment records, example of a rejected or quarantined artifact	Checks are described in the policy but no logs or records show they run
Review monitoring of known issues	Whether new vulnerabilities, outdated or modified components, and license risks in supplied components are tracked and acted on	Vulnerability and component reports, triage tickets, remediation or exception records	Component inventory exists but nobody reviews alerts or assigns follow-up
Confirm review and improvement	Whether the supply chain process is reviewed when suppliers, products or threats change, and whether findings lead to updates	Review minutes, updated risk register, change records linked to supplier events	Process has not been reviewed since it was written, or reviews do not reference incidents or supplier changes

Implementing A.5.21 step by step, with the output of each step

This sequence turns A.5.21 from a policy statement into a working process: it maps what enters the ICT supply chain, rates the risk, writes requirements into supplier terms, checks integrity, and sets the points at which the review starts again. Each step ends with a named output that an assessor can sample.

Map ICT products and their components
Start with the ICT products and services the organization buys, builds or depends on, then record the components inside them: operating system packages, libraries, container base images, firmware, hardware parts and hosted services. Ask each direct supplier which sub-suppliers and components it relies on, and record the answer rather than assuming it. The output is a component inventory linked to each product and its owner. The step is complete when every in-scope product has a named owner and a component list that someone has checked against a real deployment. Open-source tools such as Trivy can generate a software bill of materials for container images and file systems, which gives a starting list for software components.
Classify supplier and component risk
Rate each product, supplier and critical component by how much harm a compromise, outage or tampered version would cause to confidentiality, integrity and availability. Consider whether the component runs with privileged access, handles regulated data, or would be hard to replace. Feed the results into the organization's existing risk assessment method so the ratings match other risk decisions. The output is a supply chain risk register with one entry per high-impact product or component, showing the rating, the reasoning and the risk owner. The step is complete when the register is approved and every high-rated entry has a planned treatment.
Set sub-supplier and provenance requirements
Write the requirements that suppliers must meet for the components they provide and for the sub-suppliers they use. Typical requirements cover disclosure of sub-suppliers, notice before a material change in sub-suppliers or components, the origin and maintenance status of key components, and the ability to provide an accurate software bill of materials. Tie the depth of the requirements to the risk rating from the previous step. Legal review is usually needed to fit these requirements into contracts, and the wording belongs with the organization's contract owner. The output is a set of supply chain clauses and a requirements schedule that the procurement team can attach to new and renewed contracts, linked to the supplier agreement controls A.5.20 and A.5.22.
Define integrity and verification checks
Decide how the organization confirms that a delivered product or component is what the supplier said it was, and that it has not been changed on the way. Options include checking cryptographic signatures and hashes on delivery, comparing the software bill of materials with what is actually deployed, scanning builds for known vulnerabilities, and reviewing hardware or firmware before it enters a secure environment. Confirm each check against the vendor documentation, because support for signatures, attestations and SBOM formats varies by product. The output is a verification procedure for each risk tier, with the tool, the owner and the record it creates. Dependency-Track can ingest CycloneDX SBOMs and VEX data to track known vulnerabilities and license risk over time, which supports this check.
Record and monitor the supply chain in one place
Bring the inventory, risk register, contract clauses and verification results into one system of record so that each component traces back to its supplier, its risk rating and its last check. Configure continuous monitoring for known vulnerabilities in the components already in use, and route the findings to the owners named in the inventory. Keep license and provenance data alongside the security data so audits can answer questions from one place. The output is a traceable link from each component to its owner, supplier clause and most recent verification, and a monitoring feed that produces dated records. The step is complete when an assessor can pick any in-scope component and follow the chain without asking for a separate spreadsheet.
Set review triggers and close the loop
Define the events that reopen the assessment for a product, component or supplier: a new major release, a change of sub-supplier, a published vulnerability in a critical component, a change in ownership, a failed verification, or a security incident traced to the supply chain. Assign who receives each trigger and how the outcome is recorded. Schedule periodic reviews of the high-risk entries as well. Feed the lessons from any supply chain incident into the risk register and the requirements schedule, which links this step to A.5.27. The output is a documented trigger list, a review log with dated decisions, and updated register entries. The step is complete when a sample of triggered events shows a recorded decision and a change where one was needed.

How SBOMs and component inventories make the supply chain visible

Under A.5.21, the organization needs visibility of what sits behind the products and services it buys, not only of the supplier it signed with. A software bill of materials (SBOM) is the core record for that visibility: a machine-readable list of the components, libraries and versions inside each application or image, including the dependencies pulled in by the suppliers' own suppliers. The OWASP Dependency-Track platform consumes and produces CycloneDX SBOMs and VEX data, and Trivy can generate SBOMs from container images, file systems and repositories or scan an SBOM that a supplier delivers. For hardware and firmware, the equivalent is an inventory of device models, firmware versions, and the sources and signing keys used for updates. Confirm with each supplier which of these artifacts they can provide and in what format before you write the requirement into the contract.

Assessors test whether the inventory matches the systems that are actually running. A common approach is to pick a production workload, compare its deployed image digest or package list against the SBOM on file, and ask who acted on any component flagged as vulnerable, outdated or modified. A mismatch between the recorded and running versions is a stronger finding than a missing document, because it shows the record was not generated from the environment. The evidence also has to stay current between audits. An SBOM generated once at procurement and never regenerated after a patch or release does not show the supply chain as it is today, and the organization should be able to show when each inventory was last refreshed.

The most frequent weakness is an inventory with no named owner and no review date. Such a list may be detailed and still fail, because nobody is accountable for updating it, reconciling it with supplier notices, or deciding what to do when a component is found to be risky. Before an assessment, record an owner for each product inventory, a review interval set by the organization, and a clear path from a finding to a decision. Your implementation partner can help set up the tooling and the reconciliation routine, but the organization must own the decisions and the sign-off.

Evidence that passes A.5.21 and how to keep it current

An assessor testing A.5.21 looks for a working process, not a policy alone. The artifacts below show that the organization knows what it buys, how far its suppliers reach, and whether the components it runs are what it expected. Each one needs a named owner and a refresh trigger so the evidence still describes reality at the next audit.

Supply chain risk procedure

This is the documented process that defines how ICT products and services are assessed for supply chain risk before purchase, during use and at replacement. It should name the risk criteria, the people who approve exceptions and the points where a supplier's sub-suppliers are examined. Keep it current by reviewing it on a fixed schedule and after any incident involving a third-party component. Ask an assessor's view on the scope early, since a procedure that ignores software components will be questioned.

ICT product and component inventory

An inventory of the hardware, software, firmware and cloud-delivered ICT products the organization relies on, with owners, versions and the supplier behind each. Auditors sample it against running systems, so gaps between the list and production are the most common finding. Refresh it through change tickets and automated discovery rather than annual rewrites. Tie each entry to the asset inventory under A.5.9 so the two records do not diverge.

Software bills of materials

A software bill of materials lists the components inside each application or image, including transitive dependencies. Dependency-Track consumes and produces CycloneDX SBOMs and VEX, and Trivy can generate SBOMs or scan existing ones, which lets the team track known vulnerabilities and license risk per component. Regenerate SBOMs at each build or release, not once per audit, and check that the archived copy matches what was deployed.

Sub-supplier requirements in contracts

Contracts with direct suppliers should require them to disclose material sub-suppliers, to flow security obligations down the chain and to notify the organization before changing a critical component. This is where A.5.20 and A.5.21 meet. Keep a register of which sub-suppliers each contract covers and set a reminder to revisit it when a supplier announces an acquisition, a hosting move or a new subcontractor.

Integrity verification records

Records showing that delivered software, firmware and hardware were checked against the provider's published hashes, signatures or provenance attestations before installation. Store the verification output with the change record, including the check performed and who approved the install. Recheck the procedure when tooling changes and sample records each quarter so that verification is shown to happen in practice, not only in design.

Supplier review and exception records

Dated records of periodic supplier reviews, risk re-ratings and any accepted exceptions, each with a rationale and an expiry date. These show that the supply chain procedure is operated and that decisions are revisited. Set a review calendar tied to supplier criticality and close any exception that has passed its expiry. Note that the organization owns these decisions, while an independent auditor tests them.

What meeting A.5.21 costs in money and effort

This table breaks the cost of meeting A.5.21 into components, showing who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to build a quote request and to see where open-source tooling reduces licence spend, while effort on inventories and supplier review remains.

Cost component	Who is paid or who carries it	One-time or recurring	What drives it
Tooling and licences	Software vendors or hosting provider; self-hosted open source avoids per-seat licence fees but not hosting or staff time	Licences recur; setup is one-time	Number of users, scanning volume, and whether the tool is commercial or open source
Engineering time for component inventories	Internal platform or security engineers, or an implementation partner under a fixed-scope agreement	One-time build, then recurring upkeep	Number of ICT products, depth of dependency tracking, and how many systems lack existing asset records
SBOM pipeline build	Internal DevOps or an implementation partner who wires Trivy and Dependency-Track into CI/CD	One-time build, recurring maintenance	Number of build pipelines, release frequency, and languages or base images in use
Supplier security requirements and review	Procurement, legal and security staff; outside counsel if contract terms are negotiated	Initial clauses are one-time; reviews recur	Number of ICT suppliers, sub-supplier depth, and how often suppliers change their components
Evidence upkeep	Internal compliance or security staff who keep SBOMs, vendor records and provenance checks current	Recurring	Release frequency, component churn, and how often sub-supplier lists change
External testing or review	Independent testers or assessors, paid per agreed scope	Recurring if scheduled at intervals	Scope of software reviewed, depth of testing, and number of critical components
Auditor sampling	Certification body or auditor, paid under its own agreement with the organization	Recurring at each audit cycle	Number of suppliers and components sampled, and how well records match actual deployments

Who owns A.5.21 and what a partner can prepare

Your organization owns the control. A.5.21 asks you to define and implement processes for managing information security risks from the ICT product and service supply chain, and those processes must reflect decisions your leadership actually makes. Choosing which components are acceptable, which suppliers receive trust, what sub-supplier obligations to require and what risk to accept remain management decisions that no partner or auditor can make for you.

Risk decisions: Set the acceptance criteria for third-party components, including when a risk is accepted, mitigated or rejected, and record who signed each decision.
Supplier relationships: Own the contracts, due diligence and escalation paths with your ICT suppliers and their key sub-suppliers.
Acquisition rules: Define which product sources, build pipelines and update channels are permitted in your environment.
Review cadence: Run the periodic review of supply chain risk and the response to changes in suppliers or components.
Ownership of evidence: Keep the records in your own systems so you can produce them to the auditor without the partner present.

Before accepting any partner deliverable, confirm that your named owner can explain each risk decision without referring to the partner's documents.

Where A.5.21 programs usually fall short

Most ICT supply chain programs fail in the same few places: they stop at the direct supplier, treat the software bill of materials as a one-time artifact, and trust components without checking them. The cards below set out the usual gaps, why each one weakens A.5.21 evidence, and the fix an assessor will expect to see.

No sub-supplier visibility

The organization knows its direct vendors but not the suppliers those vendors depend on for hardware, libraries, hosting or support. A.5.21 reaches beyond direct suppliers, so an assessor will ask who sits two or three tiers down and what risk that creates. Fix it by asking each critical supplier for a list of its own material sub-suppliers, recording that list in the supplier register, and marking which tiers carry access to your information or systems.

SBOMs generated once and never refreshed

Teams often produce a software bill of materials at release and then leave it untouched while dependencies receive new versions and new vulnerability disclosures. The inventory quickly stops matching what is running. Fix it by regenerating SBOMs from each build or deployment, loading them into a tool such as OWASP Dependency-Track, and keeping the history so you can show which component versions were in use at a given date.

No integrity checks on received components

Software packages, container images and hardware firmware are often accepted from a repository or vendor without verifying that they are the artifacts the producer published. Anyone who can alter a package in transit or in a mirror can change what you run. Fix it by verifying checksums or signatures at intake, pinning versions, and recording who approved each component before it entered production.

Contracts silent on sub-suppliers

Supplier agreements frequently say nothing about subcontracting, so a vendor can move data or delivery to a new party without notice or approval. This is a gap between A.5.21 and the contract controls in A.5.20. Fix it by adding clauses that require notice before new material sub-suppliers are used, the right to object, flow-down of security requirements, and a list of sub-suppliers to be kept current.

Component license and provenance unknown

Many teams cannot say where a component came from, which upstream project maintains it, or under what license it is distributed. Unknown provenance makes it hard to judge vulnerability exposure and hard to answer questions on license compliance, which also sits in A.5.32. Fix it by recording the source, maintainer and SPDX license identifier for each component, and flagging any component that lacks them for review before use.

Risk reviews that never reach procurement

Supply chain risk is assessed by security staff but not built into purchasing, so new ICT products are bought before anyone reviews their components or suppliers. The assessment then becomes a retrospective exercise. Fix it by adding an ICT supply chain check to the procurement workflow for new products and services, with defined triggers for a deeper review, and keeping the decision record with the purchase.

How much effort does A.5.21 take, and can we do it ourselves?

What drives the effort and cost of meeting A.5.21?

The effort scales with how many ICT products and services reach your systems, how deeply they are built on third-party components, and how much evidence you already hold. A.5.21 asks for processes that manage supply chain information security risk, so the work is mostly defining the process, applying it to a real inventory of suppliers and components, and keeping records. The main cost drivers are:

The number of ICT products and services in scope, including open-source components pulled into your builds
Whether software bills of materials and supplier security information already exist or must be created
How many teams own procurement, engineering and operations decisions that the process must cover
The state of your asset inventory and supplier register, which the process depends on

No fixed cost figure is supplied for this control, so ask any provider to price from a written scope that names these drivers.

How long does it take to implement A.5.21?

Duration depends on the size of your ICT estate and how much of the work is new. A.5.21 is one control among 93 in the Annex A set, so it is usually implemented alongside A.5.19, A.5.20 and A.5.22, which share the same supplier records and contract clauses. Plan the work in phases: define the supply chain risk process, build the inventory of ICT products and their components, set requirements for sub-suppliers and provenance, then collect evidence over a full operating period before an assessor samples it. No timeline is supplied for this control, so confirm durations with your certification body and with any partner against your own inventory and calendar.

What does the work need from engineering and procurement?

Procurement owns the contract side: adding sub-supplier disclosure, provenance and notification requirements to purchasing terms, and recording which suppliers provide ICT products or services. Engineering owns the technical evidence: producing software bills of materials for applications and images, checking component integrity, tracking known vulnerabilities in dependencies, and deciding how changes in upstream components are reviewed. Security or GRC staff define the process and risk criteria, and someone must own the register that ties the two together. Agree these roles in writing before work starts, because an assessor will ask who performs each step.

Can an in-house team implement A.5.21 without outside help?

Often yes, if the team has someone who can write the process, someone who can run component inventory and vulnerability tooling, and procurement staff willing to change contract templates. The work is not unusually technical, but it crosses several departments, which is where in-house efforts usually stall. Check three things honestly: whether you have an inventory of ICT suppliers and components today, whether anyone has operated software composition tooling, and whether the people who approve purchases will follow a new procedure. If any answer is no, budget time for that gap or bring in help for the specific part.

What does a partner change, and what stays with us?

A partner can plan the process, set up self-hosted tooling in your own infrastructure, configure component inventory and vulnerability tracking, and prepare the records an assessor will sample. DeployOpen plans, implements, integrates and documents self-hosted open-source platforms inside the client's own environment, and runs security testing that can check the systems involved. It does not issue audit reports or certificates. Your organization still owns the control, approves the supplier risk decisions, signs the contracts and makes the final call on which suppliers are acceptable. An independent certification body performs the audit.

How do we ask a partner for a fixed-scope quote?

Most DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. DeployOpen does not publish a price list, so a quote follows from that written scope. To get a comparable proposal from any provider, supply the list of ICT products and services in scope, the number of teams and sites involved, the systems that will host the tooling, your current supplier and component records, and the evidence you expect to produce. Ask each bidder to state what is included, what the client must provide, what is one-time work and what recurs, and what support or retainer is offered afterwards.

Is there ongoing work after the first implementation?

Yes. A.5.21 is not a one-off project, because new ICT products, new sub-suppliers and new component versions appear continuously. Recurring work includes reviewing supplier and component changes, updating software bills of materials, acting on new vulnerability findings, and keeping the risk process current. Ask any provider which of these are in the fixed-scope deliverable and which move to a retainer for upgrades, support and continuous testing. Agree in advance who performs each recurring task, since that determines how much of the cost recurs.

How DeployOpen prepares A.5.21 systems and evidence

DeployOpen's work on A.5.21 starts with a written scope that names the ICT products and services in the supply chain under review, the systems that will hold the SBOM and vulnerability data, and the people who own each part of the process. Before anything is deployed, the scope fixes which inventories exist, which sub-supplier requirements are written into contracts, and which evidence the assessor will sample. The organization decides what counts as in scope and approves the scope. DeployOpen then deploys and hardens the tooling inside the client's own cloud accounts, data centers or air-gapped network, so that software inventories and vulnerability records never leave the environment the organization controls.

The core tooling is usually OWASP Dependency-Track, which consumes and produces CycloneDX SBOMs and VEX and tracks components with known vulnerabilities, outdated or modified components and license risk by SPDX license ID, and Trivy, which can generate SBOMs from container images, filesystems and repositories and scan existing SBOMs. DeployOpen configures these tools, wires their outputs into the client's build and procurement pipelines, and documents how each supplier's SBOM is requested, stored and reviewed. Confirm with your engineering team which build systems and artifact registries must feed the tools, and confirm the current Dependency-Track and Trivy release notes before you commit to a version.

DeployOpen does not issue audit reports, attestations or certificates. Only an independent auditor or accredited certification body can assess A.5.21 and issue a certificate. The organization owns its controls, decides how its supplier risk is accepted, and signs off on the procedures. DeployOpen prepares the systems, the inventories and the evidence packs an assessor will ask for, and it documents what each record shows and where it is kept. Ask any implementation partner to state this division of roles in the statement of work, and ask your certification body in advance which evidence format and sampling approach it expects.

A.5.21 Managing information security in the ICT supply chain