ISO 27001 A.5.21: Managing Information Security in the ICT Supply Chain

Quick Reference (60 Seconds)

ISO 27001:2022 Annex A 5.21 requires processes and procedures to manage the information security risks associated with the ICT products and services supply chain, looking beyond your direct supplier to the components, sub-suppliers, and software dependencies behind what you buy.

The Bottom Line: A.5.20 secures your direct supplier; A.5.21 looks deeper, at the open-source libraries inside your software, the components inside your hardware, and the sub-contractors behind your ICT services. SolarWinds, Log4j and xz all proved that an attacker who compromises something upstream compromises everyone downstream. A.5.21 is how you see, and govern, that depth.

What the Control Asks For

The ISO 27001:2022 Text

In short:

ISO 27001:2022 Annex A 5.21 asks organizations to define and run processes that manage security risk across the supply chain behind ICT products and services.

Do you need this control?

A.5.21 is not mandatory in itself: under clause 6.1.3 you include it if your risk assessment calls for it, and record the decision in your Statement of Applicability. Include it if you buy ICT products or services whose components come from further down a supply chain (software, cloud, hardware), which is most organisations. A small organisation may meet it largely through supplier due diligence and SBOM requests for critical software.

What ISO 27002:2022 Adds

In addition to the general supplier requirements (5.19, 5.20), ISO/IEC 27002 lists topics (a) to (m) to consider (paraphrased):

• (a) security requirements for ICT product and service acquisition
• (b) ICT service suppliers propagating your requirements to their sub-contractors
• (c) ICT product suppliers propagating security practices to their component suppliers (sub-contracted developers, hardware providers)
• (d) information describing the software components in products (in practice, an SBOM)
• (e) information on the product's security functions and the configuration needed for secure operation
• (f) monitoring and acceptable methods to validate that delivered products and services meet requirements (for example penetration testing, checking third-party attestations)
• (g) identifying critical components that need extra scrutiny, especially when built outside the organisation or further outsourced
• (h) assurance that critical components and their origin can be traced through the supply chain
• (i) assurance that delivered products work as expected, with no unexpected or unwanted features
• (j) checking components are genuine and unaltered (anti-tamper labels, hash verification, digital signatures; watch for out-of-specification behaviour) across the life cycle
• (k) assurance of security levels through formal certification or evaluation schemes, such as the Common Criteria Recognition Arrangement
• (l) rules for sharing information about supply-chain issues and compromises with suppliers
• (m) managing component life cycle and availability, including suppliers leaving the market, with alternative suppliers and transfer of software and know-how

27002 adds that ICT should be acquired from reputable sources, and that these practices build on, but do not replace, general security, quality and engineering practices.

The "shall vs should" Analysis

What Auditors Actually Check

1. A documented process for managing ICT supply-chain risk (not just generic supplier management).
2. Security requirements in ICT acquisition: embedded in procurement of software/hardware/ICT services.
3. Flow-down: suppliers required to propagate requirements to sub-suppliers.
4. Component/SBOM visibility: can you find out if a vulnerable dependency is in your stack?
5. A reaction capability: what you do when a widely-used component is compromised (Log4j test).

Why ICT Supply Chain Security Matters

The Business Risk Narrative

Modern software and hardware are assembled, not built, a typical application is mostly third-party and open-source code, and hardware contains components from dozens of sources. Each is an inherited risk you did not write and may not even know is there. The defining incidents of the last decade, SolarWinds (a compromised build pipeline), Log4j (a ubiquitous logging library), and xz/liblzma (a backdoored open-source dependency), were not breaches of any one company's perimeter; they were breaches of the supply chain that propagated to thousands of downstream victims simultaneously. A.5.21 exists because the perimeter no longer contains your risk.

Supply-Chain Threat Statistics

Indian Regulatory and Strategic Context

• DPDP Act 2023: A vulnerable ICT component that exposes personal data is still your safeguard failure (Section 8(5)); supply-chain risk management is part of "reasonable security safeguards."
• Telecom: the DoT National Security Directive on the telecom sector (2021) requires licensees to buy network equipment only from trusted sources, a regime carried forward under the Telecommunications Act, 2023.
• MeitY / government procurement: empanelled cloud services and security-tested products are preferred for government ICT (for example MeitY cloud empanelment conditions).
• RBI / SEBI: Expect technology-vendor risk management, including the technology supply chain, for regulated entities.
• CERT-In: the Directions (2022) set a 6-hour reporting deadline, and CERT-In's Technical Guidelines on SBOM (October 2024) set minimum SBOM elements and formats for Indian organisations.
• SEBI CSCRF (August 2024): regulated entities are expected to obtain SBOMs for their core and critical software.
• Defence/CII: Provenance, anti-tamper, and trusted-source requirements for critical and strategic systems.

Industry-Specific Consequences

impact of Non-Compliance

The cost of a supply-chain incident is uniquely high because it is systemic, when the upstream is compromised, every downstream system is at risk at once, and remediation means hunting a dependency across your entire estate under time pressure. Investing in SBOM, flow-down, and a tested reaction process turns "we have no idea if we're affected" into "we checked, here's our exposure, here's our fix", which is the difference between a controlled response and a crisis.

Scope and Applicability

What the Control Covers

• The information security risks in the supply chain behind ICT products (hardware, software, firmware) and services (managed services, cloud, development) you acquire.
• Acquisition requirements: flow-down to sub-suppliers, component visibility (SBOM), provenance/authenticity, and validation/monitoring of delivered ICT.

Who It Applies To

Every organisation acquiring ICT, universal, but the depth scales with how software/hardware-intensive you are. A software product company and a critical-infrastructure operator implement 5.21 most rigorously; a services SME focuses on acquisition requirements and SBOM for key software.

Size-Based Applicability

Key Definitions and Terminology

Relationship to Other Controls

Two Directions of Supply Chain

A.5.21 runs in two directions. Inbound: the products/services you acquire (a vendor's software with its dependencies, hardware with its components). Your own product (outbound): if you build software/hardware, you are someone's supplier and must secure your supply chain, your open-source dependencies, your build pipeline, your sub-contracted developers (link A.8.30), and provide SBOMs to your customers. Mature organisations treat both directions as one discipline.

The ICT Supply Chain Threat Landscape

SBOM and Software Supply Chain Security

The single highest-use practice for the modern (software) supply chain.

What an SBOM Gives You

A machine-readable inventory of every component and dependency in a piece of software (formats: SPDX, CycloneDX). With it, when the next Log4j drops, you answer "are we affected, and where?" in minutes instead of weeks (27002 (d)).

SBOM in Practice

• Request SBOMs from software suppliers (make it a contract term, link 5.20).
• Generate SBOMs for your own software (build-time tooling: Syft, CycloneDX generators).
• Ingest and monitor SBOMs against vulnerability feeds (Dependency-Track, vendor platforms) so new CVEs in known components alert automatically.
• Triage and patch per A.8.8 (technical vulnerabilities).

Securing Your Own Software Supply Chain

If you build software: use SCA in CI/CD, pin and verify dependencies, secure the build pipeline (signed artefacts, provenance/SLSA), control your package registries, and adopt the NIST SSDF. This is A.5.21 applied to yourself, and is increasingly demanded by your enterprise customers.

Detailed Implementation Guidance

Define ICT Acquisition Security Requirements (27002 (a))

Create a standard set of security requirements applied to ICT purchases: secure development evidence, vulnerability-disclosure/patching commitments, SBOM provision, secure-configuration guidance, and support/end-of-life terms. Bake these into procurement.

Require Flow-Down (27002 (b), (c))

Through agreements (5.20), require service suppliers to propagate your requirements to sub-contractors and product suppliers to propagate security practices to component providers, extending governance beyond first-party.

Obtain Component and Configuration Information (27002 (d), (e))

Request SBOMs, lists of implemented security functions, and secure-configuration guidance from product suppliers; use the latter to harden on deployment (link A.8.9).

Validate and Monitor (27002 (f))

Define acceptable methods to validate that delivered products/services meet requirements, security testing/acceptance (link A.8.29), reviewing supplier certifications, monitoring SBOMs against vulnerability feeds, and periodic reassessment (link A.5.22).

Identify Critical Components and Provenance (27002 (g), (h))

Maintain a critical-component register; document provenance; address single-source dependencies and end-of-life risk; require authenticity/anti-tamper assurance for hardware.

Build a Reaction Capability

The Log4j test: when a widely-used component is found vulnerable or compromised, can you (i) determine exposure (via SBOM), (ii) prioritise, and (iii) remediate/mitigate fast? Document and rehearse this process, it is what auditors and incidents both probe.

Use Trusted Sources Where Mandated

For telecom, government, defence and critical infrastructure, acquire from trusted/approved sources per the applicable Indian regime, and document the basis.

Hardware and Component Provenance

Software gets the headlines, but hardware supply-chain risk is real, especially for OT/critical sectors:

• Provenance: know the origin and chain of custody of critical components.
• Authenticity / anti-counterfeit: verify components are genuine (counterfeits are unreliable and may be malicious).
• Anti-tamper: assurance components are unaltered in transit (secure handling, tamper-evidence).
• Lifecycle & availability: manage end-of-life, spares, and continued security support; avoid single points of failure.
• Trusted sources: for telecom/CII, procure network and critical hardware from designated trusted sources.

ICT Supply Chain Policy and Requirements (Template)

Illustrative extract (full version in the toolkit):

ICT Supply Chain Security Requirements — [Organisation Name] (A.5.21)

1. Acquisition. All ICT product/service acquisitions shall carry security requirements:
   secure development attestation, vulnerability disclosure & patch SLAs, SBOM provision,
   secure-configuration guidance, and end-of-life/support terms.

2. Flow-down. Suppliers shall propagate these requirements to their sub-suppliers and
   component providers, and disclose material sub-suppliers.

3. SBOM. Software suppliers shall provide a current SBOM (SPDX or CycloneDX). Acme shall
   ingest and monitor SBOMs against vulnerability feeds and triage findings per A.8.8.

4. Validation. Delivered ICT shall be validated against requirements via security testing/
   acceptance (A.8.29) and review of supplier certifications.

5. Critical components. Critical components shall be registered with documented provenance;
   authenticity/anti-tamper assurance required for critical hardware.

6. Reaction. On disclosure of a critical component vulnerability/compromise, the SC-RM
   process shall determine exposure (via SBOM), prioritise and remediate within defined SLAs.

7. Trusted sources. Where mandated (telecom/government/CII), acquire from approved trusted
   sources and document the basis.

Risk Assessment and Treatment

Audit and Compliance Checklist

(The toolkit 04-audit-evidence-checklist.md lists the evidence to prepare.)

Metrics and KPIs

Common Pitfalls and Audit Failures

Illustrative Scenarios

Illustrative scenario, a composite example for guidance, not a specific Singahi engagement or a verified outcome.

Illustrative Scenario 1, Indian SaaS Product Company (Bengaluru, 700 staff): SBOM and the Log4j Test

Challenge. When Log4Shell broke, this SaaS company spent 11 frantic days manually grepping repositories to find where the vulnerable Log4j library was used across its products and infrastructure, and still wasn't fully sure it had found everything. An enterprise customer's security review then demanded proof of a software supply-chain program; the company had none, threatening a renewal.

Solution (10 weeks).

1. Implemented SBOM generation (CycloneDX) in every build and SCA in CI/CD.
2. Stood up Dependency-Track to ingest SBOMs and continuously monitor components against vulnerability feeds.
3. Added SBOM provision and vulnerability-disclosure requirements to its own supplier contracts (5.20 flow-down) and began collecting SBOMs from key vendors.
4. Documented and rehearsed a supply-chain reaction runbook (the "Log4j test").

Results. Exposure to a newly-disclosed critical component CVE can now be determined in under an hour; the enterprise renewal passed; and the SBOM/SC-RM evidence became standard sales collateral, accelerating future security reviews.

Illustrative Scenario 2, Indian Telecom/Network Operator: Trusted Sources and Component Provenance

Challenge. A network operator preparing for ISO 27001 (and subject to India's telecom trusted-source requirements) could not demonstrate provenance for critical network equipment, had no flow-down requiring equipment vendors to secure their own component supply chains, and no anti-tamper assurance for field-deployed hardware.

Solution (14 weeks).

1. Built a critical-component register with documented provenance and trusted-source basis for network equipment.
2. Added flow-down and propagation requirements to vendor agreements (security practices through the component supply chain), plus secure-configuration and vulnerability-disclosure obligations.
3. Implemented anti-tamper/secure-handling controls for field hardware and a lifecycle/EOL plan for critical components.
4. Established a validation process (acceptance testing + supplier certification review) for delivered equipment.

Results. Provenance and trusted-source compliance demonstrable for all critical network components; vendor flow-down in place; the operator passed ISO 27001 certification and aligned with telecom trusted-source obligations in one program.

Advanced Implementation Guidance

Figure · Tiers

Maturity levels for ict supply chain

Operationalising SBOM (beyond "have one")

An SBOM only delivers value when it is continuously monitored and actionable. The mature operating model is a loop: generate an SBOM on every build (Syft / CycloneDX / build-tool plugins); ingest it into a monitoring platform (OWASP Dependency-Track or a commercial equivalent); correlate components against live vulnerability feeds (NVD, GitHub Advisories, vendor PSIRTs); alert when a known component gains a new critical CVE; triage by exploitability and exposure; and remediate through your vulnerability-management process (A.8.8). The same loop applies to SBOMs you receive from suppliers, request them contractually (A.5.20), ingest them, and monitor the components your vendors ship to you. Without the monitoring loop, an SBOM is a static document that ages into irrelevance within weeks.

Securing Your Own Build Pipeline (SLSA)

If you produce software, your build pipeline is itself a supply-chain attack surface, SolarWinds was a build compromise. Harden it: least-privilege, short-lived pipeline identities (link A.5.16 non-human identity); signed, verifiable build artefacts (Sigstore/cosign); build provenance attestations (the SLSA framework's levels progressively raise assurance that an artefact was built from the expected source by the expected process); controlled, curated package registries to defeat dependency-confusion and typosquatting; and secret scanning so credentials never enter the pipeline. Customers increasingly ask for SLSA level or provenance evidence in security reviews, it is becoming table stakes for selling software to enterprises.

Hardware and Component Provenance (deeper)

For OT, telecom, and critical-infrastructure operators, hardware supply-chain risk is concrete. Build and maintain a critical-component register capturing origin, chain of custody, lifecycle/EOL status, and single-source dependencies. Require authenticity/anti-counterfeit assurance (counterfeit components are unreliable and may be malicious) and anti-tamper controls for components in transit (tamper-evident packaging, secure handling). Manage end-of-life: an unsupported critical component with no security patches is a standing risk that must be tracked and planned out. For mandated sectors, procure from trusted/approved sources and document the basis.

Nth-Party Visibility

Your direct (first-party) supplier is rarely the whole story, the risk often lives several tiers deep (the open-source maintainer, the sub-contracted developer, the component vendor). Require flow-down (A.5.20) so first-party suppliers propagate your requirements, and seek disclosure of material sub-suppliers for your most critical data flows and products. You will not map the entire nth-party universe, but you should have visibility into the chain behind your crown-jewel systems.

Sector-Specific Notes (India)

• SaaS / product companies: the dominant risk is your software supply chain (dependencies + build). SBOM + SCA + SLSA are the priorities; enterprise customers will audit them.
• BFSI / fintech: ICT-vendor and update integrity for core systems; RBI expects technology-supply-chain risk management; validate vendor build/update security.
• Telecom / CII: trusted-source obligations and hardware provenance dominate; anti-tamper and component lifecycle are key.
• Manufacturing / OT: counterfeit/tampered components in control systems; provenance and trusted sources.

ICT Supply-Chain Maturity Model (L1–L5)

Target L3 for certification; software product companies and CII operators are typically expected at L4.

Anatomy of a Supply-Chain Attack (and how 5.21 stops it)

In the SolarWinds pattern, an attacker compromised the vendor's build pipeline and inserted malicious code into a signed, legitimate update that thousands of customers then installed, the malware arrived through a trusted channel. The Log4j pattern was different: a critical flaw in a ubiquitous open-source library buried deep in countless applications, where the hard problem was simply finding where it was used. A.5.21 addresses both: validation and monitoring of supplier integrity and flow-down reduce the chance of a poisoned update reaching you; SBOM + continuous monitoring mean that when the next Log4j drops, you determine your exposure in minutes rather than weeks; and a tested reaction runbook turns a frantic estate-wide hunt into a controlled, evidenced response.

Key Takeaways

• A.5.21 looks past your direct supplier to the components, sub-suppliers, and dependencies behind ICT products and services.
• SBOM is the highest-use practice for software-centric organisations, generate, ingest, monitor, and act.
• Flow-down extends your requirements to sub-suppliers; provenance and trusted sources address hardware.
• The "Log4j test": can you determine exposure to a new critical component CVE quickly?, is what auditors and incidents both probe.
• Secure your own build pipeline (SLSA, signed artefacts) if you produce software; customers increasingly require it.
• In India, A.5.21 supports DPDP safeguards, the telecom trusted-source rules, CERT-In's SBOM guidelines and SEBI CSCRF's SBOM expectations.

Multi-Framework Mapping

Implementation Roadmap

Phase 1, Foundation (Weeks 1–3)

• Define ICT acquisition security requirements; identify critical components/systems.
• Assess current software dependencies (SCA) and biggest supply-chain exposures.

Phase 2, SBOM & Flow-Down (Weeks 4–7)

• Stand up SBOM generation/ingestion and continuous monitoring.
• Add SBOM, vulnerability-disclosure and flow-down requirements to supplier agreements (5.20).

Phase 3, Validate & Harden (Weeks 8–10)

• Implement validation/acceptance for delivered ICT; apply secure-configuration guides (8.9).
• Build the critical-component register with provenance; address EOL/single-source risks.

Phase 4, React & Assure (Weeks 11–12+)

• Document and rehearse the supply-chain reaction runbook (Log4j test).
• Build KPI dashboard; connect to A.5.22 monitoring; internal audit dry-run.

FAQ

Q1: Is A.5.21 mandatory for certification? Not automatically: it is selected through risk treatment (clause 6.1.3) and recorded in your Statement of Applicability. If you acquire ICT products or services (essentially everyone), you will normally include it, and auditors then look for a real process and component visibility, not just generic supplier management.

Q2: How is A.5.21 different from A.5.19 and A.5.20? 5.19 is the supplier-risk process; 5.20 is the contract terms with your direct supplier; 5.21 looks deeper at the ICT supply chain, components, sub-suppliers, software dependencies, provenance.

Q3: What's the single most valuable practice? For software-centric organisations, SBOM, generated for your software and requested from suppliers, then monitored against vulnerability feeds. It is what lets you answer "are we affected?" in minutes.

Q4: We're not a product company, does 5.21 still apply? Yes. Even as a pure consumer of ICT, you should require security in acquisition, obtain SBOMs/component info for key software, and be able to react when an upstream component is compromised.

Q5: How does 5.21 relate to vulnerability management (A.8.8)? SBOM/component visibility feeds A.8.8, you cannot patch a vulnerable dependency you don't know you have. 5.21 supplies the inventory; 8.8 runs the remediation.

Q6: What about "trusted sources"? For telecom, government and critical infrastructure in India, certain ICT must come from designated trusted/approved sources; document compliance where this applies to you.

References and Further Reading

Primary standards

• ISO/IEC 27001:2022: Annex A control 5.21.
• ISO/IEC 27002:2022: Clause 5.21 (ICT supply-chain guidance (a)–(m)).
• ISO/IEC 27036 (series): Information security for supplier relationships / ICT supply chain.

Supporting frameworks

• NIST SP 800-161 Rev 1: Cyber Supply Chain Risk Management (C-SCRM).
• NIST CSF 2.0: GV.SC (Cybersecurity Supply Chain Risk Management).
• NIST SP 800-218: Secure Software Development Framework (SSDF).
• CIS Controls v8: Control 15 (Service Provider Management), Control 16 (Application Software Security).
• PCI DSS v4.0.1: Requirements 6.3.2 and 12.8.
• SBOM formats: SPDX, CycloneDX; SLSA (build provenance).

Indian & global context

• Digital Personal Data Protection Act, 2023: Section 8(5).
• Indian telecom security rules: trusted sources/products for network equipment.
• MeitY: government ICT procurement and empanelment.
• CERT-In: Directions under Section 70B of the IT Act, 2000 (2022).

Singahi resources: the A.5.21 toolkit and related guides for A.5.19 Supplier relationships, A.5.20 Supplier agreements, A.8.8 Technical vulnerabilities, and A.8.30 Outsourced development.