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.
In this guide, I will show you exactly how to implement ISO 27001 Annex A 5.21 and ensure you pass your audit. You will get a complete walkthrough of the control, practical implementation examples, and access to the ISO 27001 templates and toolkit that make compliance easy.
I am Stuart Barker, an ISO 27001 Lead Auditor with over 30 years of experience conducting hundreds of audits. I will cut through the jargon to show you exactly what changed in the 2022 update and provide you with plain-English advice to get you certified.
Key Takeaways: ISO 27001 Annex A 5.16 Identity Management
ISO 27001 Annex A 5.21 requires organizations 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 organization 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.
Core requirements for compliance include:
- 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: Auditors will look for “The Sub-Processor Trail”:
- 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?”
- Reputable Sourcing: “How do you verify that the hardware or software you purchase comes from an authorized and reputable channel?”
- 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?”
Supply Chain Mapping Example (Audit Prep):
| Tier | Relationship | Vetting Responsibility | Example | ISO 27001:2022 Control |
|---|---|---|---|---|
| Tier 1 | Direct Vendor. | YOU check them. | Salesforce (CRM). | Annex A 5.21 / 5.19 |
| Tier 2 | Sub-Processor. | Tier 1 checks them. | AWS (Hosting Salesforce). | Annex A 5.21 |
| Tier 3 | Component / Library. | Tier 2 checks them. | OpenSSL (Library in AWS). | Annex A 5.21 / 8.8 |
| Tier 4 | Infrastructure. | Tier 3 checks them. | Data Center Power Grid. | Annex A 5.21 / 7.1 |
Table of contents
- What is ICT?
- What is ISO 27001 Annex A 5.21?
- Watch the ISO 27001 Annex A 5.21 Tutorial
- ISO 27001 Annex A 5.21 Podcast
- ISO 27001 Annex A 5.21 Implementation Guidance
- How to implement ISO 27001 Annex A 5.21
- Supply Chain Mapping Example
- ISO 27001 Supplier Register Template
- ISO 27001 Supplier Policy Template
- How to comply
- How to Audit ISO 27001 Annex A 5.21
- How to pass the ISO 27001 Annex A 5.21 audit
- What an auditor will check
- Top 3 ISO 27001 Annex A 5.21 Mistakes People Make and How to Avoid Them
- Applicability of ISO 27001 Annex A 5.21 across different business models.
- Fast Track ISO 27001 Annex A 5.21 Compliance with the ISO 27001 Toolkit
- ISO 27001 Annex A 5.21 Applicable Laws and Related Standards
- ISO 27001 Annex A 5.21 FAQ
- Related ISO 27001 Controls and Further Reading
- ISO 27001 controls and attribute values
ISO 27001 Certainty™: The Ultimate ISO 27001 Certification System & Toolkit
What is ICT?
ICT, or information and communications technology (or technologies), is the infrastructure and components that enable modern computing.
What is ISO 27001 Annex A 5.21?
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.
ISO 27001 Annex A 5.21 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.
ISO 27001 Annex A 5.21 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.
ISO 27001 Annex A 5.21 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
Watch the ISO 27001 Annex A 5.21 Tutorial
In the video ISO 27001 Managing Information Security In The ICT Supply Chain Explained – ISO27001 Annex A 5.21 I show you how to implement it and how to pass the audit.
ISO 27001 Annex A 5.21 Podcast
In this episode: Lead Auditor Stuart Barker and team do a deep dive into the ISO 27001 Annex A 5.21 Managing Information Security In The ICT Supply Chain. The podcast explores what it is, why it is important and the path to compliance.
ISO 27001 Annex A 5.21 Implementation Guidance
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.
I’ve sat in the Auditor’s chair for 30 years. Use the exact system and tools I use to guarantee a pass.
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). |
ISO 27001 Supplier Register Template
The ultimate ISO 27001 Supplier Register Template.
ISO 27001 Supplier Policy Template
The ultimate ISO 27001 Supplier Register Template.
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.
4. Audit contractual “flow-down” security clauses
- Review legally binding agreements to ensure they include specific ICT security obligations: such as vulnerability disclosure timelines.
- Verify the presence of flow-down clauses: requiring primary suppliers to apply your security standards to their sub-contractors.
- Check for “Right to Audit” and Rules of Engagement (ROE) documentation: resulting in enforceable oversight of the supply chain.
- Inspect the processes for verifying that delivered ICT products match the original specifications: result: protection against counterfeit assets.
- Review the use of tamper-evident packaging and secure shipping protocols for hardware: ensuring physical integrity during transit.
- Validate the use of cryptographic hashes for software downloads: resulting in verified, untampered code.
- Review the supplier’s Secure Development Lifecycle (SDLC) documentation: verifying that security is embedded in their coding practices.
- Inspect the patching and vulnerability management protocols for ICT assets: ensuring that critical updates are delivered securely and promptly.
- Confirm that suppliers use code-signing certificates: resulting in authentic software updates.
- Request visibility into the supplier’s own supply chain: resulting in a map of N-tier risks.
- Review how primary suppliers monitor their sub-contractors: ensuring that the security chain is not broken at lower levels.
- Update risk assessments whenever a critical sub-supplier changes: maintaining a dynamic risk posture.
- Verify that suppliers are contractually obligated to report security breaches within a defined window, such as 72 hours: resulting in rapid internal response.
- Review the escalation paths for supply chain incidents: ensuring that communication channels are tested and effective.
- Include suppliers in periodic incident response “desktop” exercises: ensuring technical coordination.
- Apply the Principle of Least Privilege (PoLP) for all third-party technical access: limiting supplier permissions to the minimum necessary.
- Enforce Multi-Factor Authentication (MFA) for any remote or privileged access to your infrastructure: resulting in robust authentication.
- Log and monitor all supplier activity within the production environment: ensuring an immutable audit trail.
- Verify that technical access is revoked immediately upon contract termination or personnel change: result: elimination of “orphan” accounts.
- Audit the certified destruction or secure return of data and assets at the end of the relationship: ensuring no data leakage.
- Review the transition plan for migrating services to new providers: ensuring security continuity during the hand-over.
5. Verify the integrity of ICT hardware and software deliveries
6. Audit secure development and maintenance practices
7. Monitor sub-supplier and N-tier risks
8. Assess ICT incident reporting and notification windows
9. Provision granular Identity and Access Management (IAM)
10. Validate secure transition and asset decommissioning
The Tools We Use.
100% Audit Success. Zero AI Guesswork.
How to pass the ISO 27001 Annex A 5.21 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 ISO 27001 Annex A 5.21 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.
Applicability of ISO 27001 Annex A 5.21 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. |
Fast Track ISO 27001 Annex A 5.21 Compliance with the ISO 27001 Toolkit
For ISO 27001 Annex A 5.21 (Managing information security in the ICT supply chain), the requirement is to manage the risks associated with your ICT products and services supply chain. This means ensuring that your security requirements are propagated through your suppliers to their subcontractors (the “supply chain tiers”) and that critical components can be traced and verified.
| Compliance Factor | SaaS Compliance Platforms | High Table ISO 27001 Toolkit | Audit Evidence Example |
|---|---|---|---|
| Strategy Ownership | Rents access to your risk strategy; if you cancel the subscription, your documented supply chain tiers and vendor configurations vanish. | Permanent Assets: Fully editable Word/Excel Third-Party Policies and Supplier Registers that you own forever. | A localized “ICT Supply Chain Register” identifying Tier 1 direct vendors and their critical sub-processors. |
| Governance Utility | Attempts to “automate” mapping via dashboards that cannot evaluate security functions or identify risky open-source libraries. | Governance-First: Formalizes your existing technical knowledge (e.g., AWS/Salesforce stack) into an auditor-ready framework. | A “Supply Chain Mapping Template” proving you have identified critical components and traced their origin. |
| Cost Efficiency | Charges a “Vendor Tier Tax” based on the depth of mapping or number of sub-processors monitored, creating perpetual overhead. | One-Off Fee: A single payment covers your supply chain governance for 3 tiers or 30. | Allocating budget to security penetration testing or better-vetted products rather than monthly dashboard fees. |
| Strategic Freedom | Mandates rigid reporting formats that often fail to align with agile development models or cloud-native stacks. | 100% Agnostic: Procedures adapt to any environment—high-end traceability tools or simple risk-managed questionnaires. | The ability to evolve your ICT procurement strategy and sub-processor list without reconfiguring a rigid SaaS module. |
Summary: For Annex A 5.21, the auditor wants to see that you have identified critical products and services and have a formal process for managing risks through the supply chain. The High Table ISO 27001 Toolkit provides the governance framework to satisfy this requirement immediately. It is the most direct, cost-effective way to achieve compliance using permanent documentation that you own and control.
ISO 27001 Annex A 5.21 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. |
The 2026 Climate Amendment: Geographic Resilience
In the 2024 and 2025 updates to the standard, ISO introduced a mandatory requirement to consider climate change as an issue for your ISMS. For Annex A 5.21, this means you must vet the geographic locations of your ICT providers. It is no longer enough to know who they are; you need to know where they are.
Compliance Action: Add an Environmental Risk column to your Supplier Register. If your primary cloud region or your supplier data center is in a flood zone or an area prone to wildfires, I will ask to see your failover plan to a different geographic region. This is about ensuring Availability in the face of environmental instability.
Hardware Integrity and Chain of Custody
You might buy your firewalls or servers from a reputable reseller, but how do you know they were not intercepted and tampered with before they reached your office? In a technical audit, I will look for your physical verification steps for new hardware.
Stuart’s Pro Tip: Implement a Receipt of ICT Goods checklist. This includes checking for broken tamper evident seals on packaging and verifying serial numbers against the manufacturer shipping notice before the device is ever plugged into your network. If you cannot prove the chain of custody, you cannot prove the integrity of the device.
Active Vulnerability Management for Tier 3 Risks
Having a Software Bill of Materials (SBOM) is a great first step, but in 2026, simply holding a list is a passive control. I want to see a living vulnerability management process for your code libraries. If a vulnerability like Log4j hits the news, you need to know exactly where that library exists in your stack.
Compliance Action: Show the auditor your Software Composition Analysis (SCA) dashboard. If a vulnerability is found in a library your ICT supplier uses, I want to see a record of you asking that supplier for their remediation timeline. This proves you are managing the risk, not just documenting it.
Technical Portability: Your Escape Clause
Succession planning is often just a document that sits in a folder gathering dust. In a Stage 2 audit, I am looking for Technical Portability. If your ICT provider goes bust or suffers a catastrophic failure, can you actually move your data and services elsewhere?
- No Vendor Lock-in: Prove that you are not locked into a supplier proprietary technical stack.
- Open Formats: Document your exit technical requirements, ensuring your data is stored in open formats like JSON or SQL.
- Migration Testing: Show me evidence that you have tested a data migration from one provider to another in the last 12 months. Without a test, you do not have a plan; you have a wish.
The ICT Supply Chain Quarantine Procedure
If a supplier notifies you that their software library has been compromised, a SolarWinds style event, how quickly can you isolate it? You need a technical kill switch for compromised ICT components.
Compliance Action: Integrate supply chain compromises into your Incident Response Plan. I want to see a playbook that defines how you would disable a specific third party API or segment a piece of hardware if the manufacturer reported a backdoor. Speed is the only thing that matters during a supply chain attack.
N-Tier Visibility and Concentration Risk
Most companies stop their due diligence at Tier 2. In 2026, for high risk ICT, you need to go deeper. If your CRM uses a sub-processor for AI, and that AI provider uses a specific data annotation firm in a high risk country, that is your risk to manage.
Compliance Action: Your Tier 1 contracts must mandate that they provide you with an updated list of their critical technical sub-processors every six months. You do not need to audit them all, but you must be able to see the chain to identify concentration risk, where multiple suppliers all rely on the same single point of failure.
The “Shadow Glue” Risk: Low-Code and No-Code Platforms
Modern ICT supply chains are often held together by “glue” platforms like Zapier, Make, or Microsoft Power Automate. These tools sit between your critical SaaS apps and have full access to your data. Because they are often managed by business users rather than IT, they are the biggest “Shadow ICT” risk in 2026.
Compliance Action: Your ICT Supply Chain Register must include these automation platforms. You must vet them as Tier 1 suppliers because a single compromised “Zap” can exfiltrate your entire customer database. I will check to see if your IT team has visibility into which integrations are active and who authorized them.
AI Model Pipeline Integrity: Weights and Provenance
If you are using AI, your ICT supply chain now includes the “weights” and “training sets” of the models you deploy. If a supplier provides you with a pre-trained model, how do you know the model itself has not been poisoned or tampered with? This is a unique 5.21 risk for 2026.
- Model Verification: For critical AI components, you should require the supplier to provide cryptographic hashes of the model weights.
- Provenance Audit: I want to see that you have asked your AI suppliers about the origin of their training data to ensure you are not inheriting legal or security liabilities from “stolen” or “poisoned” datasets.
Managing the “Legacy” Supplier: Technical Debt
A major supply chain risk is the supplier who no longer exists or the product that is End of Life (EOL). If you are still using legacy hardware or software that is no longer receiving security patches, your supply chain is broken. ISO 27001 Annex A 5.21 requires you to manage the “lifecycle” of components.
Stuart’s Pro Tip: Your ICT Register must include an End of Life date for every critical component. If an auditor sees you are running EOL software with no “Compensating Controls” (like network isolation), you will get a non-conformity. You must prove you have a plan to migrate away from dying technology.
Concentration Risk: The “Hidden” Single Point of Failure
You might have three different software suppliers, which looks like good diversification. But if all three of them host their services on the same AWS region, you have a Concentration Risk. If that region goes down, your entire business stops. In 2026, I am looking for your “N-Tier” concentration map.
Compliance Action: In your Supplier Register, track the “Infrastructure Provider” for every Tier 1 SaaS vendor. If you see that 80 percent of your stack relies on one cloud provider, you must document this as a strategic risk and explain how you would operate if that provider suffered a systemic failure.
Code Signing and Update Verification
Most organizations have “Auto-Update” turned on for everything. This is a massive supply chain vulnerability. If a supplier’s update server is compromised, they will push malware directly into your environment. You need a process for Update Integrity.
Compliance Action: For critical systems, your policy should mandate the verification of digital signatures or cryptographic hashes before updates are applied. I want to see that your systems are configured to reject any update that is not signed by a trusted, verified certificate from the supplier.
The “Supply Chain Attack” Tabletop Exercise
Finally, the most important thing is proving your process works during a crisis. I want to see evidence of a Supply Chain Incident Drill. This is more than just a standard fire drill; it is a simulation of a “SolarWinds” or “Log4j” style event.
- The Drill: Pick a critical ICT component and pretend it has been compromised. Can your team identify all the systems affected within 2 hours?
- Audit Evidence: Show me the “After Action Report” from this drill. If the drill showed that your team didn’t know which systems used a specific library, I want to see the “Corrective Action” you took to fix that visibility gap.
The Quantum Ghost: Post Quantum Cryptography (PQC)
By 2026, the threat of “Harvest Now, Decrypt Later” has moved from a theory to a boardroom risk. If your ICT suppliers are providing encryption that is vulnerable to quantum computing, your long lived data is already at risk. Auditors now want to see that you have assessed the Quantum Readiness of your critical technical partners.
Compliance Action: Add a column to your Supplier Register for PQC Roadmap. You should ask your Tier 1 encryption and cloud providers for their formal transition plan to NIST approved quantum resistant algorithms. If they do not have a roadmap, you must document this as a long term confidentiality risk in your Risk Register.
The 2026 Climate Amendment: Availability Under Fire
ISO has now strictly mandated that climate change be considered as a relevant issue for the ISMS. For Annex A 5.21, this is a direct attack on Availability. If your critical ICT infrastructure is clustered in a single geographic zone prone to extreme weather, you have a major single point of failure.
Stuart’s Pro Tip: Do not just list the supplier; list their data center regions. If your CRM, your Backup Provider, and your Identity Provider all sit in the same flood prone region, I will raise a non conformity for lack of geographic redundancy. You must prove you have diversified your ICT stack across multiple, climatically diverse regions.
Active SBOM Monitoring: Not Just a List
In the past, having a Software Bill of Materials (SBOM) was enough. In 2026, a static list is useless. I want to see Active SBOM Governance. This means you are not just filing the list away; you are actively monitoring the components within it for new vulnerabilities.
- SCA Integration: Show the auditor that your Software Composition Analysis tools are scanning your supplier SBOMs in real time.
- The Log4j Lesson: If a vulnerability is found in a Tier 3 library used by your Tier 1 supplier, I want to see the ticket where you challenged that supplier on their patching timeline. Proof of challenge is proof of governance.
The Zero Day Patching SLA
Standard contracts often say “we patch in a timely manner.” That is too vague for 2026. For critical ICT components, your agreements should specify a Zero Day Response Window. When a critical vulnerability is announced, you need a contractual guarantee for a response.
Compliance Action: For Tier 1 ICT suppliers, mandate a 48 hour window for an initial impact assessment and a 72 hour window for a mitigation or patch for any vulnerability with a CVSS score of 9.0 or higher. If it is not in the contract, you have no leverage when the next major exploit hits.
Out of Band Verification for High Risk Changes
Supply chain attacks often start with a simple email: “Our bank details have changed” or “Our support engineer needs admin access for a fix.” If your team follows these instructions without a second check, your 5.21 controls have failed. You need Out of Band Verification for any high risk change in the supply chain.
Audit Evidence: I will look for your Change Management logs. I want to see that when a supplier requested a significant change, your team called a known contact on a verified number to confirm the request. If you only have an email trail, you are vulnerable to a Business Email Compromise attack.
Concentration Risk: The Invisible Failure
You might use ten different SaaS tools, but if they all rely on the same underlying Identity Provider or the same Content Delivery Network (CDN), a single failure can take your entire business offline. This is Concentration Risk, and in 2026, it is a primary focus for Lead Auditors.
Compliance Action: Map your N-Tier dependencies. Identify the “Master Providers” that your Tier 1 suppliers rely on. If you find that a single cloud outage would disable 80 percent of your stack, you must document this in your Management Review and prove you have considered alternative offline workflows.
AI Model Provenance and Weight Integrity
If you are using a third party model, your supply chain risk starts with Provenance. Where did the model come from? Who trained it? In 2026, I want to see how you verify that the model weights have not been tampered with or “poisoned” before they reached your environment.
Compliance Action: For critical AI components, your ICT Supply Chain Register must include cryptographic hashes of the model weights. If you download a model from a repository like Hugging Face, you must verify the signature or hash. If you cannot prove the model is authentic, you cannot prove your system integrity.
The AIaaS Sub-processor Trap
Most AI services (AIaaS) are built on top of other platforms. Your AI vendor might use one provider for the Large Language Model and another for the GPU compute. This creates a deep and hidden N-Tier supply chain risk.
Audit Focus: I will check if you have identified the sub-processors used by your AI providers. If your AI vendor silently switches their underlying model or infrastructure provider, your risk profile changes instantly. Your contract must mandate Change Notification for any shift in their technical sub-stack.
Data Poisoning and Annotation Oversight
If you outsource data labeling or annotation, you are introducing a massive integrity risk. If a disgruntled worker at the annotation firm intentionally mislabels data, they can corrupt your model performance. This is a 5.21 supply chain integrity issue.
Stuart’s Pro Tip: Your vetting of annotation suppliers must include their personnel security controls. I want to see evidence that you have reviewed their quality assurance processes. If they do not have a double blind review process for their labels, your training data is a single point of failure.
Regulatory Alignment: The EU AI Act Bridge
In 2026, the EU AI Act is fully enforceable. If your ICT supplier provides a High Risk AI system, they are legally required to provide you with specific technical documentation and a Declaration of Conformity. Annex A 5.21 requires you to manage these technical risks.
Compliance Action: Do not just take their word for it. Your Supplier Register should link to the supplier Conformity Assessment. If they cannot provide the technical documentation required by the Act, they are a non-compliant supplier and a risk to your certification.
AI Exit Strategy: Model and Data Portability
Vendor lock-in is a catastrophic risk in AI. If your AI provider goes bust or raises their prices by 400 percent, can you leave? Most people have a plan to “export data,” but in AI, you need Model Portability.
- Weight Portability: Ensure you have the legal and technical right to export your fine-tuned model weights.
- Training Data Ownership: Explicitly state in your agreement that you own the cleaned and labeled training sets. If you lose access to the “recipe” for your model, your business continuity plan is worthless.
ISO 42001: The AI Assurance Anchor
Just as you look for ISO 27001, you should now look for ISO 42001 (AI Management System) certification for your critical AI suppliers. This provides the ultimate assurance that they are managing AI specific risks like algorithmic bias and model security. If a supplier has ISO 42001, it makes my job as an auditor much easier and reduces the depth of vetting you need to perform.
ISO 27001 Annex A 5.21 FAQ
What is ISO 27001 Annex A 5.21?
ISO 27001 Annex A 5.21 is an information security control that requires organisations to define and implement processes for managing security risks associated with the Information and Communication Technology (ICT) supply chain.
- Focuses on the technical complexities of hardware, software, and cloud services.
- Requires transparency across the entire supply chain, including subcontractors.
- Mandates that security requirements are embedded into procurement and service agreements.
- Aims to prevent “cascading” vulnerabilities from third-party technology providers.
How does Annex A 5.21 differ from general supplier management?
The primary difference is that Annex A 5.21 specifically targets technology-based risks within the ICT stack, whereas general supplier management (5.19) covers all types of vendors.
- Technical Depth: 5.21 looks at software code integrity and hardware authenticity.
- Nth-Party Risk: It requires your direct suppliers to manage their own technology subcontractors.
- Specialised Vetting: Involves checking for backdoors, malware in updates, and hardware tampering.
What are the core requirements for ICT supply chain security?
Compliance with Annex A 5.21 requires a formalised approach to identifying critical ICT suppliers and enforcing technical security standards through legal contracts.
- Risk Assessment: Perform deep-dive vetting of technology providers before onboarding.
- Contractual Clauses: Include “Right to Audit” and mandatory incident reporting requirements.
- Integrity Checks: Verify the authenticity of ICT products to prevent counterfeit components.
- Change Management: Review how suppliers manage updates and patches to their technology.
Does Annex A 5.21 require a Software Bill of Materials (SBOM)?
While the standard does not explicitly name an SBOM, it strongly implies the need for visibility into software components to manage vulnerabilities effectively.
- Provides a list of all open-source and third-party components within a product.
- Allows organisations to react quickly when a specific library (e.g. Log4j) is compromised.
- Supports the requirement for monitoring the security of ICT products over time.
How do you manage risks from cloud and SaaS providers under 5.21?
Managing cloud-based ICT risks requires defining clear shared responsibility models and verifying the provider’s independent security certifications.
- Review SOC 2 Type II or ISO 27001 certificates of the cloud host.
- Ensure data residency requirements are documented and legally binding.
- Assess the provider’s resilience and exit strategy to prevent vendor lock-in risks.
What evidence do auditors look for regarding Annex A 5.21?
Auditors expect to see a documented ICT supply chain risk register and evidence that security requirements were included in supplier selection processes.
- Vendor Risk Assessments: Completed security questionnaires for technology partners.
- Procurement Logs: Proof that security was a weighting factor in the selection process.
- Service Level Agreements (SLAs): Technical requirements for uptime and incident response.
- Audit Reports: Records of reviews conducted on high-risk ICT suppliers.
How much can supply chain breaches cost businesses?
Supply chain breaches can cost businesses an average of £3.5 million per incident in 2026. Beyond immediate financial loss, failure to comply with standards like NIS2 or the UK Cyber Security and Resilience Bill can lead to regulatory fines exceeding £17 million for systemic failures in technical supply chain oversight.
Related ISO 27001 Controls and Further Reading
| Related ISO 27001 Control | Relationship Description |
|---|---|
| How to Implement ISO 27001 Annex A 5.21 | This is the practical execution manual for the 5.21 control, providing the specific technical procedures required to move from high-level supply chain strategy to actual hardware and software verification. |
| ISO 27001 Annex A 5.21 Audit Checklist | I use this checklist during formal certifications to verify that your ICT supply chain isn’t just documented, but is actually resilient against tampering and counterfeit components. |
| ISO 27001 Annex A 5.19 Supplier Relationships | Control 5.19 provides the overarching policy framework for all vendors, while 5.21 dives into the specialized technical requirements for the ICT providers that build and maintain your infrastructure. |
| ISO 27001 Annex A 5.20 Supplier Agreements | This control provides the legal “teeth” for 5.21, ensuring that the technical integrity requirements for your ICT stack are codified into enforceable contracts with your primary vendors. |
| ISO 27001 Annex A 5.22 Monitoring and Review | Once the ICT supply chain is established, 5.22 provides the mechanism for continuous vigilance, ensuring that your technical partners maintain their security posture throughout the service lifecycle. |
| ISO 27001 Annex A 5.23 Cloud Services | Cloud security is a critical subset of the ICT supply chain. This control focuses on the unique risks of SaaS and IaaS, building on the general technical requirements established in 5.21. |
| ISO 27001 Annex A 8.30 Outsourced Development | This technical control overlaps with 5.21 by focusing specifically on the integrity of code produced by third parties, ensuring that external development teams follow your secure coding standards. |
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
