What is ISO 27001 Annex A 5.21?
ISO 27001 Annex A 5.21 focuses on managing information-security risks associated with the ICT supply chain.
Modern organizations rarely build every technology component themselves.
A SaaS startup may depend on:
- Cloud infrastructure
- SaaS applications
- Open-source software
- Software libraries
- APIs
- Managed service providers
- Hardware manufacturers
- Software vendors
- Data processors
- Cloud subprocessors
- Development partners
- Security providers
- DNS and CDN providers
- Payment providers
This creates a chain of technology dependencies.
For example:
Your SaaS application
→ Cloud provider
→ Database service
→ Open-source library
→ Third-party API
→ Another cloud service
A security weakness anywhere in this chain can potentially affect your organization.
Simple Explanation
Know what technology you depend on, understand where the security risks are, and manage those risks throughout the ICT supply chain.
Why is A.5.21 Important?
Organizations increasingly depend on technology they do not fully control.
A company may have strong internal security but still be affected by:
- A compromised software update
- Vulnerable third-party software
- Compromised dependencies
- A malicious package
- Cloud-provider failure
- Supplier compromise
- Insecure API integration
- Compromised development tools
- Hardware or firmware vulnerabilities
- A supplier’s subcontractor
Example
A startup uses a third-party software library in its application.
A vulnerability is discovered in the library.
The startup’s application is affected even though:
- Its own developers followed secure coding practices.
- Its internal systems were properly configured.
- Its employees followed security policies.
The risk came through the technology supply chain.
Simple Principle
You cannot secure your technology environment effectively if you do not understand the technology it depends on.
A.5.19 vs A.5.20 vs A.5.21
These controls are closely connected.
| Control | Primary Focus |
|---|---|
| A.5.19 | Information-security risks in supplier relationships |
| A.5.20 | Security requirements within supplier agreements |
| A.5.21 | Managing information security across the ICT supply chain |
| A.5.22 | Monitoring, reviewing, and managing changes to supplier services |
| A.5.23 | Security for use of cloud services |
Simple Flow
Who are our suppliers?
→ A.5.19
What security requirements should we agree with them?
→ A.5.20
What technology and dependencies make up our ICT supply chain?
→ A.5.21
How do we monitor and manage supplier services over time?
→ A.5.22
How do we manage cloud-specific security?
→ A.5.23
What is the ICT Supply Chain?
The ICT supply chain includes the technology products, services, components, and dependencies used to deliver an organization’s information-processing capabilities.
This can include:
Cloud Services
- AWS
- Microsoft Azure
- Google Cloud
- Cloud databases
- Cloud storage
- Serverless platforms
SaaS
- Google Workspace
- Microsoft 365
- Salesforce
- Jira
- Slack
- GitHub
Software Components
- Open-source libraries
- Frameworks
- Packages
- Container images
- Third-party SDKs
- Commercial software
Technology Services
- Managed IT
- Managed security
- Software development
- Hosting
- Infrastructure management
APIs
- Payment APIs
- Identity APIs
- AI APIs
- Communication APIs
- Data APIs
Hardware
Where relevant:
- Servers
- Network devices
- Laptops
- Security appliances
- IoT devices
- Firmware
Why Supply Chain Security Is Different
Traditional security thinking often focuses on:
“What systems do we own?”
Supply-chain security asks:
“What systems, services, software, components, and providers does our environment depend on?”
This difference is important.
For example, a company may own its application but depend on:
- 100+ open-source packages
- 10 SaaS platforms
- 3 cloud services
- 5 external APIs
- 2 managed service providers
The organization’s effective technology environment is therefore much larger than its directly managed infrastructure.
Activities Required to Implement A.5.21
Step 1: Identify the ICT Supply Chain
Create an inventory of important technology dependencies.
For example:
| Component | Provider | Purpose | Criticality |
|---|---|---|---|
| Cloud | AWS | Production infrastructure | Critical |
| Source Control | GitHub | Source code | High |
| CI/CD | GitHub Actions | Deployment | High |
| Database | Cloud DB | Customer data | Critical |
| Payment API | Payment Provider | Payments | High |
| Email API | Email Provider | Transactional email | Medium |
| Monitoring | Monitoring SaaS | Observability | Medium |
| Open-source library | External project | Application functionality | Medium |
The inventory should focus on dependencies that can materially affect security, confidentiality, integrity, or availability.
Step 2: Identify Critical Dependencies
Not every dependency deserves the same level of attention.
Identify components where failure or compromise could significantly affect the organization.
Examples:
Critical
- Production cloud
- Customer database
- Identity provider
- Core payment infrastructure
High
- Source-code repository
- CI/CD
- Security monitoring
- Important external APIs
Medium
- Internal collaboration tools
- Marketing systems
Low
- Non-critical productivity applications
Step 3: Understand the Supply Chain
For important technology components, determine:
- Who provides the service?
- Where is it hosted?
- What data does it process?
- What systems depend on it?
- Does it use subcontractors?
- What happens if it becomes unavailable?
- What happens if it is compromised?
- What security assurance is available?
- What alternatives exist?
Step 4: Assess Supply-Chain Risks
Consider risks such as:
Confidentiality
Could a supplier or compromised component expose sensitive information?
Integrity
Could a compromised component modify:
- Software
- Data
- Configuration
- Transactions
Availability
Could supplier failure stop:
- Applications
- Payments
- Customer access
- Internal operations
Authenticity
Can the organization verify that software, packages, updates, and components come from legitimate sources?
Step 5: Manage Software Dependencies
For software-producing organizations, third-party dependencies are particularly important.
Maintain awareness of:
- Open-source packages
- Libraries
- Frameworks
- Container images
- SDKs
- Build tools
Where appropriate, use:
- Software composition analysis
- Dependency scanning
- Vulnerability monitoring
- Approved package repositories
- Dependency update processes
Step 6: Maintain a Software Bill of Materials Where Appropriate
A Software Bill of Materials (SBOM) provides information about the software components included in an application or product.
For example:
Application
→ React
→ Node.js package
→ Authentication library
→ Database driver
→ Logging library
An SBOM can help organizations understand what components are present and respond more quickly when a vulnerability affects a particular component.
An SBOM is not necessarily required for every organization or every application, but it can be a useful supply-chain security capability, particularly for software-producing organizations.
Step 7: Secure the Software Development Supply Chain
For development environments, consider protecting:
- Source repositories
- Build pipelines
- CI/CD systems
- Package repositories
- Developer accounts
- Deployment credentials
- Build artifacts
- Container registries
Important controls may include:
- MFA
- Least privilege
- Branch protection
- Code review
- Dependency scanning
- Secret scanning
- Artifact integrity
- Access reviews
- Build-system protection
Step 8: Evaluate Third-Party Software
Before introducing important third-party software or components, consider:
- Security reputation
- Maintenance status
- Vulnerability history
- Support
- Update frequency
- Licensing
- Security documentation
- Supplier assurance
- Business criticality
For open-source software, consider whether the project is:
- Actively maintained
- Widely used
- Supported
- Receiving security updates
Step 9: Manage Supplier and Subsupplier Dependencies
A direct supplier may depend on other organizations.
For example:
Your Company
↓
SaaS Provider
↓
Cloud Provider
↓
Data Center
The organization may not control every level of this chain.
However, for important services it should understand material dependencies and obtain appropriate assurance where practical.
Step 10: Monitor Supply-Chain Security Risks
Supply-chain risks change over time.
Monitor relevant information such as:
- Vulnerability disclosures
- Security advisories
- Supplier incidents
- Major changes to suppliers
- End-of-life software
- Dependency vulnerabilities
- Supplier ownership changes
- Service changes
Step 11: Establish an Incident Response Process
The organization should know what to do when a supply-chain security event occurs.
Example:
Vulnerability discovered in third-party component
↓
Identify affected applications
↓
Assess exposure
↓
Determine severity
↓
Apply patch/update/mitigation
↓
Test
↓
Deploy
↓
Monitor
↓
Document
Step 12: Plan for Supplier Failure
For critical dependencies, consider:
“What happens if this supplier becomes unavailable?”
Possible measures include:
- Backup provider
- Alternative technology
- Data backup
- Export capability
- Recovery procedures
- Manual workaround
- Disaster recovery plan
The appropriate approach depends on business criticality.
Startup Example
Imagine a SaaS startup that operates an AI-powered customer platform.
Its technology supply chain includes:
- AWS
- GitHub
- GitHub Actions
- PostgreSQL
- Open-source Python packages
- OpenAI API
- Stripe API
- Cloudflare
- Email delivery provider
The company identifies several critical dependencies.
AWS
Risk: Production availability and customer data
GitHub
Risk: Source code and development environment
GitHub Actions
Risk: Software build and deployment pipeline
Open-source dependencies
Risk: Vulnerabilities introduced through application components
OpenAI API
Risk: External processing dependency and availability
Stripe
Risk: Payment processing
The company documents these dependencies, assesses their risks, monitors important security information, and maintains appropriate contingency arrangements.
ICT Supply Chain Register
A practical register could look like:
| Component | Supplier | Purpose | Data | Criticality | Security Assurance | Owner |
|---|---|---|---|---|---|---|
| Cloud | AWS | Production | Customer data | Critical | Available | CTO |
| Source Code | GitHub | Development | Source code | High | Available | Engineering |
| CI/CD | GitHub Actions | Deployment | Build artifacts | High | Available | DevOps |
| Payment | Stripe | Payments | Transaction data | High | Available | Finance/Engineering |
| CDN/DNS | Cloudflare | Network delivery | Traffic data | High | Available | DevOps |
| AI API | AI Provider | AI processing | Application data | High | Review required | Product/Engineering |
| Open-source package | External | Application function | Code | Medium | Dependency monitoring | Engineering |
Supply Chain Risk Assessment
A startup can assess critical ICT dependencies using questions such as:
| Question | Example |
|---|---|
| What does the component do? | Hosts production |
| What information does it process? | Customer data |
| What happens if it fails? | Application unavailable |
| What happens if compromised? | Data/infrastructure exposure |
| Is there an alternative? | Secondary provider |
| Is security assurance available? | SOC 2 / ISO 27001 / other evidence |
| Is vulnerability monitoring available? | Yes |
| Is the dependency actively maintained? | Yes |
| Who owns the relationship? | CTO |
| When was it last reviewed? | 2026-09 |
Audit Evidence
An auditor may look for evidence that ICT supply-chain risks are actually managed.
Governance Evidence
- Information Security Policy
- Supplier Security Policy
- Third-Party Risk Management Policy
- Secure Development Policy
- Vulnerability Management Policy
Inventory Evidence
- ICT supplier register
- Technology dependency inventory
- Software inventory
- Critical supplier register
- Application inventory
Software Supply Chain Evidence
- Dependency inventory
- SBOM where applicable
- Dependency scanning
- Vulnerability reports
- Software update records
- Container scanning
- Secret scanning
Supplier Evidence
- Supplier assessments
- SOC 2 reports
- ISO 27001 certificates
- Security questionnaires
- Contractual security requirements
Monitoring Evidence
- Security advisories
- Vulnerability monitoring
- Supplier security reviews
- Dependency alerts
- Risk reassessments
Incident Evidence
- Supply-chain security incidents
- Vulnerability remediation
- Emergency patching
- Supplier incident assessments
ISO 27001 A.5.21 Audit Checklist
Supply Chain Identification
- Has the organization identified important ICT suppliers?
- Are critical technology dependencies documented?
- Are important software dependencies identified?
- Are cloud and SaaS dependencies identified?
Risk Assessment
- Are supply-chain security risks assessed?
- Are critical dependencies identified?
- Are confidentiality, integrity, and availability considered?
- Are supplier and subcontractor dependencies considered?
Software
- Are third-party software components identified?
- Are vulnerabilities in dependencies monitored?
- Are unsupported or obsolete components identified?
- Is software updated when required?
- Is software provenance considered where appropriate?
Development
- Are source-code repositories protected?
- Are CI/CD systems protected?
- Are build environments controlled?
- Are secrets protected?
- Are third-party packages monitored?
Suppliers
- Is relevant supplier security assurance obtained?
- Are security requirements established?
- Are critical supplier changes monitored?
- Are supplier incidents assessed?
Resilience
- Are critical dependencies identified?
- Are alternatives or recovery arrangements considered?
- Can important data be recovered or exported where required?
Evidence
- Can the organization demonstrate its important ICT dependencies?
- Can it demonstrate risk assessments?
- Can it demonstrate vulnerability monitoring?
- Can it demonstrate remediation of supply-chain vulnerabilities?
Common Mistakes
1. Looking Only at Direct Suppliers
A company may maintain a supplier register but ignore:
- Open-source software
- APIs
- Software libraries
- Subprocessors
- Cloud dependencies
ICT supply-chain security is broader than procurement.
2. Ignoring Open-Source Software
Open-source components can introduce vulnerabilities even when no commercial supplier relationship exists.
3. No Dependency Inventory
Developers may install packages without the organization knowing what components are actually running in production.
4. No Vulnerability Monitoring
A company may know which libraries it uses but have no process for identifying newly discovered vulnerabilities.
5. Protecting Production but Not CI/CD
An attacker who compromises the build pipeline may potentially influence software before it reaches production.
Development and deployment infrastructure therefore deserve appropriate protection.
6. No Alternative for Critical Dependencies
A startup may rely entirely on one provider without considering what happens if the provider experiences a major outage.
7. Treating an ISO Certificate as Complete Supply-Chain Assurance
A supplier’s certification can provide useful assurance, but the organization should still consider:
- Scope
- Relevance
- Service covered
- Current validity
- Its own risks and requirements
8. No Owner
Every important ICT dependency should have someone accountable for understanding and managing its risk.
Practical Startup Implementation Model
A startup can implement A.5.21 using:
1. Discover
Identify technology suppliers and dependencies.
↓
2. Map
Understand what systems depend on them.
↓
3. Classify
Identify critical and high-risk dependencies.
↓
4. Assess
Evaluate security, availability, integrity, and confidentiality risks.
↓
5. Protect
Apply appropriate technical and contractual controls.
↓
6. Monitor
Track vulnerabilities, incidents, changes, and supplier risks.
↓
7. Respond
Remediate or mitigate supply-chain security issues.
↓
8. Recover
Maintain appropriate alternatives or recovery arrangements for critical dependencies.
Simple Model
Discover → Map → Classify → Assess → Protect → Monitor → Respond → Recover
Policy vs Process vs Evidence
| Component | Example |
|---|---|
| Policy | ICT supply-chain risks shall be managed according to business and security requirements |
| Standard | Critical dependencies require documented risk assessment |
| Procedure | Third-party software assessment |
| Procedure | Dependency vulnerability management |
| Procedure | Critical supplier review |
| Procedure | Supply-chain incident response |
| Technical Control | Dependency scanning |
| Technical Control | SBOM where appropriate |
| Technical Control | Secret scanning |
| Evidence | ICT dependency register |
| Evidence | Vulnerability report |
| Evidence | Supplier assessment |
| Evidence | Remediation record |
| Evidence | Security assurance report |
The audit trail should demonstrate:
Dependency → Risk → Control → Monitoring → Response
Relationship With Other ISO 27001 Controls
| Control | Relationship |
|---|---|
| A.5.19 Information Security in Supplier Relationships | Manages information-security risks associated with supplier relationships |
| A.5.20 Information Security Within Supplier Agreements | Establishes relevant security requirements in supplier agreements |
| A.5.21 ICT Supply Chain | Manages information-security risks throughout the ICT supply chain |
| A.5.22 Monitoring, Review and Change Management of Supplier Services | Addresses ongoing monitoring and changes to supplier services |
| A.5.23 Information Security for Use of Cloud Services | Addresses security considerations specific to cloud services |
| A.8.8 Management of Technical Vulnerabilities | Supports identification and management of vulnerabilities in technology components |
| A.8.25 Secure Development Life Cycle | Supports security throughout software development |
| A.8.26 Application Security Requirements | Helps establish security requirements for applications |
| A.8.29 Security Testing in Development and Acceptance | Supports testing of software and systems |
| A.8.32 Change Management | Helps control changes to systems and technology components |
Useful Documents for A.5.21
- ICT Supply Chain Security Policy
[Insert Draft Document Link] - ICT Dependency Register
[Insert Draft Document Link] - Software Dependency Inventory
[Insert Draft Document Link] - Third-Party Software Assessment Checklist
[Insert Draft Document Link] - Software Bill of Materials (SBOM) Template
[Insert Draft Document Link] - Critical Technology Dependency Assessment
[Insert Draft Document Link] - Supply Chain Risk Assessment
[Insert Draft Document Link] - Third-Party Component Vulnerability Procedure
[Insert Draft Document Link] - Supply Chain Security Incident Response Procedure
[Insert Draft Document Link]
Final Takeaway
ISO 27001 Annex A 5.21 recognizes that an organization’s security does not stop at its own network, applications, or employees.
Modern organizations depend on a chain of:
Suppliers → Cloud → Software → Libraries → APIs → Platforms → Subprocessors
Any important dependency can introduce security risk.
For a startup, the goal is not to document every technology component in excessive detail.
The practical objective is to:
Know your critical ICT dependencies, understand the risks they introduce, establish appropriate controls, monitor important changes and vulnerabilities, and have a response when something in the supply chain goes wrong.
Simple implementation model:
Discover → Map → Classify → Assess → Protect → Monitor → Respond → Recover
A strong A.5.21 implementation therefore goes beyond asking “Who are our vendors?”
It asks:
“What technology does our business depend on, who provides it, what happens if it is compromised or unavailable, and how will we know and respond?”