ISO 27001 Annex A 5.21 Managing Information Security in the ICT Supply Chain Explained

ISO 27001 Managing Information Security in the ICT Supply Chain

ISO 27001 Annex A 5.21 Managing information security in the ICT supply chain is an ISO 27001 control that requires an organisation to manage the risks associated the ICT products and services supply chain.

It is managing information security in your IT suppliers and means you need a process to handle information security risks of your third party suppliers, products, systems and services.

Key Takeaways

ISO 27001 Annex A 5.21 requires organisations to define and implement processes to manage the information security risks associated with the ICT (Information and Communications Technology) products and services supply chain. This control addresses the “layered” risk of modern computing; your organisation relies on a CRM, which relies on a Cloud Host, which relies on specific software libraries (like OpenSSL). This “preventive” control ensures that security requirements are propagated throughout the entire chain, reducing the risk of a supply chain attack.

What is ICT?

ICT, or information and communications technology (or technologies), is the infrastructure and components that enable modern computing.

Purpose

The purpose of ISO 27001 Annex A 5.21 is a preventive control that ensures you maintain an agreed level of information security in supplier relationships.

Definition

The ISO 27001 standard defines ISO 27001 Annex A 5.21 as:

Processes and procedures should be defined and implemented to manage the information security risks associated with the ICT products and services supply chain.

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

Explanation

ISO 27001 Annex A 5.21 Managing information security in the ICT supply chain is a security control that requires organisations to define and implement processes for managing risks within the digital technology stack. The primary implementation requirement involves hardware and software integrity vetting, offering a vital business benefit by preventing catastrophic supply chain cyberattacks.

Requirement

• Mapping the Chain: You must identify not only your direct vendors (Tier 1) but also understand their critical sub-processors (Tier 2). This is especially vital for Cloud Services.
• Propagated Requirements: Agreements should mandate that your suppliers apply your security requirements to their own sub-contractors and component suppliers.
• Component Traceability: For critical systems, you must be able to trace the origin of ICT components to ensure they come from reputable and vetted sources.
• Software Transparency: Suppliers should provide information on the software components they use (including open-source libraries) and provide assurance that they are free from known vulnerabilities.
• Continuous Monitoring: Organizations must implement validation steps to ensure that suppliers continue to meet agreed-upon security levels throughout the contract lifecycle.
• Succession Planning: You must consider alternate suppliers for critical ICT components to ensure business continuity if a primary vendor fails or becomes insecure.

Audit Focus

1. Direct Risk Assessment: “Show me how you assessed the security of your critical SaaS providers. Did you check if they use sub-processors located in high-risk jurisdictions?”
2. Reputable Sourcing: “How do you verify that the hardware or software you purchase comes from an authorized and reputable channel?”
3. Vulnerability Assurance: “When a major vulnerability (like Log4j) is announced, how do you verify if your ICT suppliers are affected and what they are doing to patch it?”

FREE Training Video

In this free training video you will learn How to implement ISO 27001 Information Security In The ICT Supply Chain (Annex A 5.21) & Pass Audit.

Implementation Guide

We discussed above that ICT means information and communications technology and we would include cloud services in that.

When we implement we are looking to build on existing best practices for information security, project management, quality management and engineering and not to replace those practices.

You are going to have to ensure that:

• you have information security requirements when acquiring products or services
• your suppliers propagate your security requirements through ‘their’ supply chain if they sub contract
• you request, and understand, of product suppliers, what software components they use
• you request and understand product security functions and how to configure it to be secure
• you implement monitoring and validation of security requirements in your suppliers
• you identify and document critical products and services
• critical components and their origin can be traced through the supply chain
• you have assurance products are functioning as expected
• you have assurance products meet required security levels
• you have rules for sharing information including issues and compromises
• you have process for managing component lifecycles, availability and associated security risks
• you have considered alternate suppliers and how to transfer to them if needed

It is always best and goes without saying, or it should, that you will acquire your products and services from reputable sources.

Supplier Security Policy Template

The supplier policy sets out your approach to information security of suppliers. ICT suppliers are treated the same as any supplier.

Supplier Register Template

The supplier register is a record of all your suppliers and is used to manage them. ICT suppliers are treated the same as any supplier.

How to implement ISO 27001 Annex A 5.21

Implementing ISO 27001 Annex A 5.21 requires a robust Supply Chain Risk Management (SCRM) framework to protect the integrity of ICT products and services. By following these steps, you will secure your digital supply chain, mitigate the risk of tampered hardware, and ensure that sub-suppliers adhere to your organisational security standards throughout the technical lifecycle.

1. Categorise ICT Supply Chain Assets in the Register

• Identify all suppliers that provide hardware, software, or technical services, recording them within a formalised Asset Register.
• Assign risk tiers based on the criticality of the ICT component to your infrastructure, ensuring prioritised oversight for high-impact vendors.
• Document the technical dependencies for each supplier, allowing for a clear understanding of your digital attack surface.

2. Define Technical Security Requirements for ICT Procurement

• Establish clear security specifications for all technical acquisitions, including requirements for secure boot, code signing, and data encryption.
• Incorporate these requirements into your Supply Chain Risk Management policy, providing a benchmark for all new ICT tenders.
• Ensure that technical specifications address the entire product lifecycle, from initial development through to decommissioning and disposal.

3. Conduct Risk-Based Security Vetting of Technical Partners

• Perform due diligence on potential ICT suppliers by reviewing their security certifications, such as ISO 27001 or SOC 2, before signing.
• Utilise security questionnaires to evaluate their secure development lifecycles (SDLC) and their internal vulnerability management practices.
• Identify any geographic or geopolitical risks associated with the supplier, documenting these within your organisational risk register.

4. Execute Contractual Agreements with Technical Flow-Down Clauses

• Incorporate specific security requirements into legally binding contracts, ensuring that suppliers are obligated to protect your information.
• Define “Rules of Engagement” (ROE) documents for technical support, establishing clear boundaries for remote access and troubleshooting.
• Mandate that primary suppliers “flow down” your security requirements to their own sub-contractors, maintaining security throughout the chain.

5. Verify ICT Product Integrity and Provenance

• Inspect delivered hardware and software for evidence of tampering, utilising secure delivery channels and tamper-evident packaging where possible.
• Validate the authenticity of software updates by verifying cryptographic hashes and digital signatures before deployment.
• Request a Software Bill of Materials (SBOM) for bespoke applications, identifying all third-party components and potential vulnerabilities.

6. Manage N-Tier Sub-Supplier Transparency

• Require primary suppliers to provide visibility into their own supply chain, identifying the technical partners they rely on for service delivery.
• Assess the risks associated with the supplier’s sub-contractors, ensuring that your security posture is not undermined by fourth-party weaknesses.
• Document the geographic locations where sub-suppliers process your data, ensuring compliance with UK Data Protection regulations.

7. Provision Secure Access via IAM and MFA

• Apply the Principle of Least Privilege (PoLP) by creating granular Identity and Access Management (IAM) roles for supplier personnel.
• Enforce Multi-Factor Authentication (MFA) for all third-party remote access, mitigating the risk of credential theft and unauthorised entry.
• Log and monitor all supplier access to sensitive network segments, ensuring an immutable audit trail of technical activity.

8. Standardise ICT Incident Reporting and Notification Windows

• Contractually mandate specific notification windows for security breaches, requiring suppliers to report incidents within 24 or 72 hours.
• Establish a clear escalation path for ICT supply chain incidents, ensuring that your internal security team is notified immediately.
• Participate in joint incident response exercises with critical ICT partners, testing communication channels and coordination efforts.

9. Audit Technical Supplier Compliance Regularly

• Exercise your “Right to Audit” by conducting periodic security reviews of critical technical partners, focusing on their adherence to agreed controls.
• Review independent audit reports and vulnerability scan results provided by the supplier, verifying that identified risks are remediated.
• Schedule annual compliance meetings with high-risk ICT suppliers, ensuring that their security standards have not drifted over time.

10. Revoke Access and Manage Secure Service Termination

• Revoke all logical and physical access permissions immediately upon contract termination, ensuring no “orphan” accounts remain active.
• Verify the secure return or certified destruction of all organisational assets and data held by the supplier, closing the risk lifecycle.
• Formalise the exit strategy to ensure service continuity, including the transfer of technical knowledge to internal teams or new providers.

Supply Chain Mapping Example

Tier	Relationship	Who checks them?	Example
Tier 1	Direct Vendor	YOU check them.	Your CRM Provider (e.g., Salesforce).
Tier 2	Sub-Processor	Tier 1 checks them.	AWS (Hosting the CRM).
Tier 3	Component	Tier 2 checks them.	OpenSSL (Library used by AWS).

How to comply

To comply with ISO 27001 Annex A 5.21 you are going to implement the ‘how’ to the ‘what’ the control is expecting. In short measure you are going to

• Implement a topic specific policy
• Implement an supplier management process
• Include in your supplier management process supplier acquisition and supplier transfer
• Implement an ISO 27001 supplier register
• Have agreements with all suppliers that cover information security requirements
• Have information security assurances for critical suppliers as a minimum and ideally all relevant suppliers

How to Audit ISO 27001 Annex A 5.21

Auditing the ICT supply chain under ISO 27001 Annex A 5.21 requires a forensic approach that goes beyond standard vendor management. This process evaluates how your organisation manages the complex risks associated with hardware, software, and technical infrastructure providers to ensure that security is maintained across the entire digital lifecycle. By following these steps, you will verify that your technical supply chain is resilient against tampering, counterfeit components, and unauthorised access.

1. Categorise ICT supply chain partners within the Asset Register

• Identify every supplier that provides hardware, software, or technical services: recording them in the central Asset Register.
• Assign risk tiers based on the criticality of the ICT component provided: resulting in a prioritised audit scope.
• Document the technical dependencies for each critical supplier: ensuring full visibility of the supply chain architecture.

2. Formalise technical security requirements for ICT products

• Define specific security specifications for all ICT acquisitions: including requirements for secure boot, encryption, and code signing.
• Ensure technical requirements are documented in the Supply Chain Risk Management (SCRM) policy: resulting in a standardised procurement benchmark.
• Communicate these specifications to all relevant internal stakeholders: ensuring alignment between IT and procurement.

3. Evaluate supplier selection and due diligence processes

• Review the criteria used to select ICT suppliers: verifying that technical competence and security history are weighted heavily.
• Inspect the due diligence records for critical vendors: ensuring that their security certifications and past performance have been verified.
• Document identified risks during the selection phase: resulting in informed risk-acceptance decisions.

ISO 27001 Templates

How to pass the audit

To pass an audit of ISO 27001 Annex A 5.21 Managing information security in the ICT supply chain you are going to make sure that you have followed the steps above in how to comply.

What an auditor will check

The audit is going to check a number of areas. Lets go through the most common

1. That you have a supplier agreements in place

The auditor is going to check that you have agreements in place with suppliers that cover the information security requirements. It will check that those agreements are in date and cover the products and / or services acquired.

2. That you have an ISO 27001 Supplier Register

You will need an ISO 27001 Supplier Register to record and manage your suppliers. Make sure it is up to date and reflects your reality.

3. Documentation

They are going to look at audit trails and all your documentation and see that is classified and labelled. All the documents that you show them, as a minimum if they are confidential should be labelled as such. Is the document up to date. Has it been reviewed in the last 12 months. Does the version control match.

Top 3 Mistakes People Make and How to Avoid Them

The top 3 Mistakes People Make For ISO 27001 Annex A 5.21 are

1. You have no contracts or legal terms with a supplier

Make sure that there is a contract, agreement, terms of business or some legal mechanism for engaging with suppliers and you have a copy, it is in date and covers what you are using.

2. You have no assurance they are doing the right thing for information security

Make sure you have done your security assessment and can place your hands on an in date certificate such as an ISO 27001 Certification for assurance they are doing the right thing. It needs to be in date a cover the products and / or services you have acquired and are using form the supplier.

3. Your document and version control is wrong

Keeping your document version control up to date, making sure that version numbers match where used, having a review evidenced in the last 12 months, having documents that have no comments in are all good practices.

Applicable Laws and Related Standards

Standard / Law	Requirement Reference	Mapping & Compliance Logic
NIST CSF v2.0	GV.SC (Cybersecurity Supply Chain Risk Management)	NIST places heavy emphasis on the use of Software Bill of Materials (SBOM) and verifying the integrity of hardware/software components, directly mirroring A 5.21.
NIS2 (EU)	Article 21 (Supply Chain Security)	Requires entities to assess the security practices of direct suppliers and the quality of cybersecurity in the products/services they provide (e.g., secure development).
DORA (EU)	Chapter V (ICT Third-Party Risk)	The most technical mapping for finance. DORA requires testing the resilience of ICT systems provided by third parties and managing “concentration risk” in the ICT stack.
UK Cyber Security & Resilience Bill	MSP Regulation & Reporting	Expanding the scope of NIS2 to Managed Service Providers (MSPs). A 5.21 is the primary control used to audit how MSPs secure their own technical supply chains.
EU Product Liability Directive (PLD)	Strict Software Liability	This update makes software providers liable for flaws. A 5.21 acts as the “due diligence” evidence to prove you verified the integrity of the software before implementation.
EU AI Act	Article 16 (High-Risk AI Systems)	Providers of high-risk AI must ensure the integrity of the datasets and software libraries used in training. A 5.21 covers the provenance of these technical inputs.
UK Data (Use & Access) Act 2025	Part 1 (Secure Data Infrastructure)	Requires technical “Smart Data” providers to maintain high security thresholds. A 5.21 ensures the hardware and code handling this data hasn’t been tampered with.
CIRCIA (USA)	Critical Infrastructure Reporting	Mandates 72-hour reporting for incidents. If an ICT supply chain compromise occurs (e.g., a SolarWinds-style event), A 5.21 provides the detection and response evidence.
SOC 2 (Trust Services)	CC9.1 / CC9.2 (Vendor Mgmt)	Focuses on whether the service organisation evaluates the technical risks of their own sub-service providers (N-tier supply chain).
ISO/IEC 42001:2023	Control 8.5 (AI Supply Chain)	Specifically targets the unique technical supply chain of AI (data labelling, model hosting). It uses A 5.21 as the baseline for ICT component integrity.
ECCF (EU Cybersecurity Framework)	Harmonised Security Labels	A 5.21 is the audit mechanism used to verify that products purchased by the organisation actually carry and maintain their ECCF-certified security status.
GDPR / UK GDPR	Article 28 & 32 (Sub-processors)	Focuses on technical measures. A 5.21 ensures that “Sub-processors” (the ICT supply chain) maintain the technical integrity required to protect personal data.
HIPAA (USA)	§ 164.306 (Security Standards)	Requires “Technical Safeguards” that protect ePHI. A 5.21 ensures that the hardware/software used to transmit PHI hasn’t been compromised at the manufacturing level.
CCPA / CPRA (California)	§ 1798.140 (Service Providers)	Requires “Reasonable Security.” In the event of a breach, A 5.21 documentation proves that the organisation took steps to secure its digital supply chain.

Applicability across different business models

Business Type	Applicability & Interpretation	Examples of Control
Small Businesses	Off-the-Shelf Hardware & SaaS. You don’t need to audit Intel or Microsoft’s code. Focus on buying from reputable sources (e.g., Dell, Apple) rather than grey-market resellers to avoid tampered hardware.	• Authorized Channels: Policy mandating all laptops/phones be purchased directly from the manufacturer or authorized distributors. • Software Integrity: Downloading software only from official App Stores or verified vendor websites, never from third-party mirrors.
Tech Startups	Software Supply Chain (SBOM). Your biggest risk is “Tier 3” dependencies (e.g., a compromised npm or PyPi package). Auditors expect you to know what libraries are inside your code.	• SCA Scanning: Using tools like Snyk or GitHub Dependabot to automatically map and monitor your “Software Bill of Materials” (SBOM). • Vendor Assessment: Sending a security questionnaire to critical API partners asking if they scan their own libraries for vulnerabilities like Log4j.
AI Companies	Model & Compute Provenance. Traceability of where your model weights and training data come from. Ensuring your GPU cloud provider isn’t silently offloading jobs to insecure regions.	• Model Signing: Using cryptographic signatures (e.g., Sigstore) to verify that the AI models deployed in production haven’t been tampered with since training. • Data Lineage: Maintaining a “Data Supply Chain” register that tracks the source and licensing terms of all datasets used for training.

FAQ

Related ISO 27001 Controls and Further Reading

• ISO 27001 Annex A 5.30 ICT Readiness For Business Continuity
• The complete guide to ISO/IEC 27002:2022

ISO 27001 controls and attribute values

Control type	Information security properties	Cybersecurity concepts	Operational capabilities	Security domains
Preventive	Confidentiality	Identify	Supplier relationships security	Protection
	Integrity			Governance and ecosystem
	Availability

About the author