Managing information security in the ICT supply chain (ISO 27001 control 5.21)

A compromised open-source library slips into a vendor’s software update. Within hours, malware propagates through hundreds of downstream organizations, bypassing every internal firewall and endpoint control along the way. ISO 27001 control 5.21 exists because your security posture is only as strong as the weakest link in your Information and Communications Technology (ICT) supply chain, and that weakest link is often a supplier you’ve never directly assessed.

What 5.21 requires

Control 5.21, “Managing information security in the ICT supply chain,” requires organizations to establish and enforce processes that address security risks specific to ICT products and services throughout the entire supply chain. Unlike broader supplier controls 5.19 (Information Security in Supplier Relationships) and 5.20 (Addressing Information Security Within Supplier Agreements), this control zeroes in on the unique risks that come with procuring technology per the ISO 27001 standard: software dependencies, hardware provenance, and the cascade effect when a sub-supplier is compromised.

In practical terms, organizations must:

• Map the ICT supply chain beyond Tier 1 suppliers: Identify not just direct vendors but the sub-suppliers, open-source maintainers, and component manufacturers whose code or hardware ends up in your environment. A supplier register that stops at the contract holder misses the actual risk.
• Propagate security requirements contractually to sub-suppliers: Your vendor’s subcontractors need to meet the same security standards you’ve set. Without contractual flow-down clauses, your requirements evaporate at the first handoff.
• Verify software component transparency: Require Software Bills of Materials (SBOMs) for critical applications. Know which open-source libraries are embedded in the tools you depend on, and track their vulnerability status.
• Trace provenance of critical hardware and software components: Understand where components originate and whether they’ve been tampered with during manufacturing or distribution. This matters for firmware, embedded systems, and any hardware with programmable logic.
• Monitor supplier compliance continuously: Initial onboarding assessments tell you what a supplier’s security posture looked like on one day. Continuous monitoring tells you what it looks like today.
• Plan for supplier failure or discontinuation: If a critical ICT supplier goes out of business, gets acquired, or suffers a catastrophic breach, your organization needs a documented contingency plan that keeps operations running.

The control’s scope deliberately extends beyond software to include hardware, cloud services, and managed IT infrastructure as part of ISO 27001 compliance, recognizing that ICT supply chain risk is a multi-dimensional problem. Where controls 5.19 and 5.20 establish the general framework for supplier relationships and agreements, 5.21 adds the ICT-specific dimension: component-level transparency, provenance tracking, and the cascading risk that technology supply chains uniquely introduce.

Why 5.21 matters

A Tier 2 software vendor pushes a routine update containing a backdoor planted by an attacker who gained access to their build environment. The vendor’s direct customer, your managed services provider, distributes the update to every client on its platform. By the time anyone detects the compromise, hundreds of organizations have the malicious code running in production. No phishing email, no exploited vulnerability on your perimeter. The attack came through a trusted channel.

This is the risk class 5.21 addresses. Supply chain integrity attacks allow adversaries to target upstream suppliers and reach downstream victims at scale. Effective third-party risk management is the only defense against this attack pattern. The severity is potentially catastrophic because the compromised component arrives through established trust relationships and automated deployment pipelines that bypass traditional security controls. Unlike a direct attack against your infrastructure, there’s no anomalous traffic to detect, no unauthorized access attempt to block. The malicious payload arrives through the same channel as every legitimate update.

Gartner predicted that 45% of organizations worldwide would experience supply chain attacks by 2025. The reality landed at 75%, a gap that underscores how badly the industry underestimated supply chain exposure. ENISA’s NIS Investments 2025 report confirms the trend: supply-chain attacks rank at 47% concern among European organizations, just behind ransomware at 55%.

What attackers exploit

This control prevents a specific set of failure modes that adversaries actively target:

• Unvetted sub-suppliers with weak security practices that serve as a softer entry point than the primary vendor
• Software dependencies with no provenance verification, allowing tampered or malicious components to enter the build pipeline
• Missing SBOM visibility, leaving organizations unaware of which open-source libraries run in their critical systems
• No flow-down of security requirements to sub-contractors, creating security gaps at every tier below the direct supplier
• Hardware sourced through grey-market or unauthorized channels, introducing counterfeit or tampered components
• Supplier access not monitored post-onboarding, allowing security posture degradation to go undetected
• No succession planning for critical ICT components, leaving organizations stranded when a key supplier fails

How to implement 5.21

For your organization (first-party)

Implementing 5.21 starts with building visibility into your ICT supply chain and establishing governance mechanisms that extend beyond your direct vendors.

1. Build an ICT supplier register with risk tiers. Catalogue every ICT supplier, including sub-suppliers where visibility exists. Assign risk tiers based on the criticality of the product or service they provide, the sensitivity of data they access, and their position in the supply chain. A cloud infrastructure provider and a peripheral firmware vendor don’t warrant the same assessment depth.

2. Define security requirements for procurement. Establish baseline security requirements that apply to all ICT procurements: secure boot, encryption at rest and in transit, code signing for software updates, and vulnerability disclosure processes. Tailor additional requirements to the risk tier. Document these in a procurement security standard that procurement teams can reference without needing to interpret ISO 27001 clauses. An ISO 27001 implementation checklist can help structure this process.

3. Require contractual flow-down clauses to sub-suppliers. Insert clauses that obligate your direct suppliers to impose equivalent ISO 27001 third-party risk requirements on their own sub-suppliers. Without these clauses, your security requirements legally stop at your vendor’s front door.

4. Implement SBOM collection and Software Composition Analysis (SCA). For critical applications, require vendors to provide SBOMs in a standard format (Software Package Data Exchange (SPDX) or CycloneDX). Feed these into an SCA tool that cross-references components against vulnerability databases like the National Vulnerability Database (NVD) and the Cybersecurity and Infrastructure Security Agency’s (CISA) Known Exploited Vulnerabilities (KEV) catalog. This turns a static inventory into an active risk signal.

5. Establish continuous monitoring cadence. Set monitoring frequencies proportional to supplier risk tiers. High-risk ICT suppliers should be monitored continuously through automated security ratings and periodic deep assessments. Lower-risk suppliers can follow annual or biannual review cycles, but never go unmonitored entirely.

6. Create succession plans for critical ICT dependencies. Identify single points of failure in your ICT supply chain. For each critical dependency, document alternative suppliers, data portability procedures, and transition timelines. Test these plans periodically.

7. Define incident communication protocols with suppliers. Agree on notification timelines, escalation contacts, and information-sharing formats before an incident occurs. When a supply chain compromise happens, the speed of your response depends on communication channels that were established in advance.

Common mistakes:

• Treating supply chain risk as a one-time procurement check. Onboarding assessments capture a snapshot. Supply chain risk is continuous, and a supplier’s security posture can degrade significantly between annual reviews.
• Ignoring Tier 2+ dependencies. If your security program stops at direct vendors, you have a blind spot that attackers actively exploit.
• Collecting SBOMs without monitoring them for vulnerabilities. An SBOM sitting in a folder is an inventory, not a security control. Value comes from continuous analysis against emerging vulnerability disclosures.
• No contractual right to audit suppliers. Without audit rights, you’re relying entirely on self-reported attestations, which may not reflect actual practices.
• Assuming ISO 27001 certification means adequate supply chain controls. Certification confirms a management system exists. It doesn’t guarantee that supply chain controls are mature or that sub-suppliers are assessed.

For your vendors (third-party assessment)

When assessing vendor compliance with 5.21, structure your evaluation around four areas: questionnaire, evidence, red flags, and verification. A structured third-party risk assessment process helps ensure consistency across your vendor portfolio.

Questionnaire guidance:

• Do you maintain a Software Bill of Materials (SBOM) for products delivered to customers? If so, in what format and at what frequency is it updated?
• Do you flow security requirements down to your sub-suppliers contractually? Can you share sample clauses?
• What is your patch management Service Level Agreement (SLA) for critical vulnerabilities in supplied components?
• Can you identify all Tier 2 suppliers involved in delivering your product or service to us?
• Do you have a documented process for verifying the provenance and integrity of software components before release?
• How do you monitor for compromised dependencies or vulnerabilities introduced through your own supply chain?

Evidence requests:

• Service Organization Control (SOC) 2 Type II report covering the relevant trust services criteria
• ISO 27001 certificate with Statement of Applicability confirming supply chain controls are in scope
• SBOM exports for products in your environment, in SPDX or CycloneDX format
• Penetration test summaries covering supply chain attack vectors
• Sub-supplier security assessment records demonstrating due diligence beyond Tier 1

Red flags:

• Cannot name or identify sub-suppliers involved in product delivery
• No SBOM process or claims that component tracking “isn’t applicable”
• No contractual flow-down requirements to sub-suppliers
• Responses limited to vague “best practices” language without specific controls or evidence
• Resistance to providing audit rights or independent assessment access

Verification approaches:

• Independent audit rights: Contractual provisions allowing your organization or a designated third party to audit the supplier’s supply chain controls directly, rather than relying solely on self-attestation
• Automated security rating monitoring: Continuous external assessment of the supplier’s security posture through platforms that track vulnerabilities, configuration issues, and exposure indicators across their internet-facing infrastructure
• Periodic reassessment: Scheduled re-evaluation at intervals proportional to the supplier’s risk tier, with triggered reassessments following significant changes, mergers, or security incidents
• Subcontractor disclosure requirements: Obligations for the vendor to notify you when they change or add sub-suppliers involved in delivering services to your organization, ensuring your risk assessment stays current

Audit evidence for 5.21

Auditors assessing 5.21 will look for documented processes and artifacts that demonstrate ICT supply chain risk is actively managed, not just acknowledged in policy. The key distinction is between documentation that describes intent and evidence that demonstrates execution. Effective ISO 27001 audit preparation starts well before the auditor arrives. Prepare the following evidence types in advance.

Cross-framework mapping

Control 5.21 aligns closely with supply chain security requirements across major compliance frameworks. Organizations operating under multiple regulatory obligations can use the mapping below to identify where 5.21 implementation satisfies parallel requirements, reducing duplicate audit preparation and evidence collection effort. “Full” coverage indicates the external framework’s control objectives are substantially met by a mature 5.21 implementation, while “Partial” indicates overlap that requires additional controls to achieve full compliance.

Related ISO 27001 controls

Control 5.21 operates within a cluster of supplier and asset management controls. Understanding these relationships helps ensure your ISO/IEC 27001 implementation is comprehensive and avoids gaps between overlapping requirements.

Frequently asked questions

What is ISO 27001 5.21?

ISO 27001 control 5.21 requires organizations to manage information security risks across the ICT supply chain. It covers the full lifecycle of ICT products and services, from procurement through ongoing monitoring, and extends security requirements beyond direct vendors to sub-suppliers and component providers.

What happens if 5.21 is not implemented?

Without 5.21, organizations lack visibility into the security practices of their ICT supply chain. Compromised software updates, tampered hardware, and vulnerable open-source dependencies can enter the environment through trusted supplier channels, creating attack vectors that internal security controls won’t catch.

How do you audit 5.21?

Auditors verify that the organization maintains an ICT supplier register with risk tiers, enforces contractual flow-down clauses, collects and monitors SBOMs for critical applications, and has documented succession plans for critical suppliers. Evidence typically includes policy documents, supplier assessment records, and monitoring reports.

How UpGuard helps with ICT supply chain security

Gaining continuous visibility across your ICT supply chain requires more than periodic assessments and spreadsheet-based tracking. UpGuard Vendor Risk provides automated, continuous monitoring of supplier security posture, helping organizations detect emerging risks across their vendor ecosystem before they escalate into incidents.

• Vendor Risk: Continuously monitors ICT suppliers for security vulnerabilities, misconfigurations, and exposure changes across their internet-facing infrastructure. Automates vendor questionnaire workflows and centralizes evidence collection, including SOC 2 reports, ISO 27001 certificates, and SBOMs, giving your team a single view of supply chain risk across every tier. Security ratings update daily, replacing point-in-time assessments with always-current risk intelligence.

Start a free trial to experience the UpGuard cybersecurity platform.