Control Definition
The organization must define and operate processes and procedures for managing the information security risks of the ICT products and services supply chain — looking past its direct suppliers to the components, software, services, and sub-suppliers those products and providers are themselves built on.
Control Objective
To manage the security risks that enter through the layers beneath your direct ICT suppliers, so that requirements, visibility, and incident expectations propagate down the chain instead of stopping at the first contract.
What This Really Means
You sign a contract with one supplier and run code from a thousand. Every SaaS product you buy sits on a cloud provider you did not choose, authenticates through libraries nobody on your side has read, and is operated with tooling from vendors you will never meet. A.5.21 exists because attackers figured this out before procurement did: compromising one widely used product or build pipeline reaches every downstream customer at once, through the very update channel those customers trust. The publicly reported supply chain compromises of recent years — trojanized software updates, breached file transfer tools, a critical flaw in one free logging library surfacing inside thousands of commercial products — all exploited the gap between who you contract with and what you actually run.
Where A.5.19 manages the supplier in front of you, this control asks what is behind them, proportionate to risk. For ICT suppliers specifically, that means a handful of concrete practices: knowing which of your suppliers are ICT suppliers and capturing the material parties beneath them — hosting providers, sub-processors, key component vendors; requiring critical suppliers, through A.5.20 clauses, to flow your security requirements down to their own subcontractors and to disclose and notify changes in them; asking software vendors about component provenance — vulnerability disclosure practices, patch cadence, support lifecycles, and increasingly a software bill of materials (SBOM); and watching upstream advisories so that news about a component becomes a question you can answer about your own estate.
Two chain risks deserve named attention. Managed service providers are aggregation points: an MSP with standing privileged access into many customers is one of the highest-value targets in the entire ecosystem, and its access into you deserves PAM-grade control and monitoring, not a VPN account from 2019. Concentration risk is the quieter one — when several of your "independent" critical suppliers all sit on the same cloud region, identity provider, or connectivity layer, one upstream failure takes them down together, and no individual supplier review will ever show it.
Auditors read this control through proportionality and the "are we affected?" test. Nobody expects you to audit a chip foundry. They do expect the supplier register to show which relationships are ICT, what material sub-suppliers sit beneath the critical ones, contracts that push requirements downstream — and, most tellingly, a record of how you established exposure the last time a major component vulnerability made the news. If that answer lives in one engineer's memory rather than in a process, the control is not operating.
Why It Matters
Supply chain attacks invert your trust model: the patch you install diligently, the library your developers pinned, the management agent your MSP requires — each is a delivery vehicle if the party upstream is compromised. The victims of these incidents were not careless about their direct suppliers; they had simply inherited risk from parties two and three levels removed whom no one had mapped. The component-vulnerability variant is just as costly in slow motion — organizations that could not say where a flawed library ran spent weeks in discovery while exploitation was already underway.
The commercial world is pricing this in. Enterprise customers now ask their vendors supply-chain questions — sub-processor lists, SBOM availability, build pipeline integrity — and financial regulators have made subcontracting visibility and concentration risk explicit supervisory themes. An organization that cannot see one level beyond its direct suppliers increasingly fails other people's due diligence, not just its own.
Left unmanaged, the ICT supply chain exposes you to:
- •Trojanized updates – a compromised vendor build pipeline ships signed malware through the channel you trust most, with your own patching discipline doing the delivery
- •Component flaws you cannot locate – when the next critical library vulnerability lands, no dependency visibility means days of guessing whether and where you are exposed
- •Fourth-party breaches – your supplier's sub-processor loses your data, and without flow-down and notification terms you have neither timely knowledge nor recourse
- •MSP aggregation – one compromised service provider credential hands an attacker privileged access to you and every other customer simultaneously
- •Correlated failures – several critical services silently share one upstream dependency, so a single regional outage or vendor failure cascades across what looked like a diversified estate
Regional Compliance Context
For India's regulated financial sector, RBI's outsourcing and IT directions make the chain explicit: material service providers' subcontracting needs the regulated entity's visibility and control, concentration risk is a named supervisory concern, and accountability stays with the bank or NBFC regardless of how many layers deep the failure occurred. SEBI's CSCRF carries comparable expectations for market intermediaries. Under the DPDP Act 2023, a fiduciary's responsibility follows personal data through every processor and sub-processor engaged on its behalf — so capturing sub-processor lists is not just hygiene but the basis of your legal position, with full compliance obligations landing 13 May 2027.
The Saudi PDPL and UAE federal PDPL apply the same logic — processor obligations must extend to sub-processing through contract — so the flow-down clauses and sub-processor registers built for one jurisdiction serve the others unchanged.
Implementation Guidance
Identify ICT Suppliers and Map What Sits Beneath Them
Flag in the A.5.19 supplier register which relationships are ICT — software, hardware, cloud, managed and telecom services. For the critical tier, capture the material parties underneath: hosting providers, published sub-processor lists, key subcontractors, and for hardware the provenance of significant components. Most SaaS vendors publish sub-processor pages; capturing and dating them is an hour of work per supplier.
Write Flow-Down and Disclosure into Contracts
Through A.5.20, require critical ICT suppliers to impose equivalent security obligations on their own subcontractors, to disclose material sub-suppliers, and to notify you of changes — ideally with an objection window for sub-processors touching your data. Add a duty to notify you of security incidents anywhere in their chain that affect your service, not only breaches of their own perimeter.
Demand Component Transparency from Software Vendors
Ask software and device vendors for their vulnerability disclosure policy, patch and support lifecycle commitments, and an SBOM where they can produce one. Treat the answers as tiering input: a vendor with no disclosure process and no lifecycle commitments is a riskier dependency regardless of feature set. For your own products, generate SBOMs and dependency manifests with SCA tooling so you can answer the same questions your customers will ask you.
Treat MSPs and High-Privilege Providers as a Special Class
Inventory every external party holding standing privileged access — MSPs, NOC/SOC providers, support vendors with admin tooling. Route their access through PAM or jump infrastructure with session logging, scope it to need, time-bound the credentials, and revalidate quarterly. Their administrative actions belong in your monitoring (A.8.16) exactly as internal admin activity does.
Map Concentration Risk Across the Estate
Chart which critical suppliers and services share upstream dependencies — the same cloud provider or region, the same identity provider, the same connectivity or payment rail. Review the map at architecture and continuity planning sessions, and either mitigate the worst single points (failover, second supplier) or record the concentration as an accepted risk with management sign-off.
Stand Up Advisory Monitoring and the Exposure Question
Subscribe to security advisories for your significant vendors plus national CERT and sector feeds, with a named triage owner. Maintain enough inventory data — asset register (A.5.9), configuration records (A.8.9), dependency manifests — that "do we run the affected component anywhere?" is answerable in hours. Wire confirmed exposures into vulnerability management (A.8.8) for remediation.
Rehearse a Supply Chain Incident
Run at least one tabletop on a chain scenario — a trojanized update from a trusted vendor, an MSP compromise, a critical library flaw — exercising the advisory triage, supplier notification clauses, and containment decisions like cutting an MSP's access. Feed the gaps into the incident plan and the contract uplift list; this is where flow-down clauses prove they were worth negotiating.
Audit Evidence
During your ISO 27001 certification audit, auditors will expect to see the following evidence to demonstrate compliance with A.5.21:
Documentation
- Supplier register identifying ICT suppliers, with material sub-suppliers and dated sub-processor lists captured for the critical tier
- Executed contract clauses for sampled critical ICT suppliers covering flow-down, subcontractor disclosure, and chain incident notification
- Records of an exposure check for at least one major published component vulnerability — who assessed, what was found, what was done
- Concentration risk analysis mapping shared upstream dependencies of critical services, with mitigation or acceptance decisions
- Advisory subscription and triage records showing upstream notices reaching a named owner and a disposition
Interviews
- CISO or supplier risk owner on how far down the chain scrutiny extends and how that depth was decided per tier
- Engineering or platform lead on how a critical component vulnerability would be located across products, dependencies, and vendor estates
- The relationship owner for an MSP on what access the provider holds, how it is controlled and monitored, and what subcontractors the MSP has disclosed
Observations
- Comparison of a critical SaaS supplier's sub-processor list in the register against the supplier's currently published list
- Inspection of PAM and session logging configuration covering a service provider's privileged access path
- Walkthrough of recent advisory triage records, traced from feed arrival to documented disposition
Practitioner Insights
My standard probe for this control is to name a component vulnerability that dominated the news and ask for the record of how the organization established its exposure. Mature programs produce a dated ticket: feeds caught it, inventory answered it, here is the disposition. Everywhere else I get a story about a heroic engineer who happened to remember where the library ran — which means the organization got lucky, not managed. The register tells you which suppliers to ask, the contract obliges them to answer, and the inventory covers what you run yourself; if any leg is missing, the question takes a week instead of an hour.
Small organizations read this control and picture auditing chip foundries, then freeze. The proportionate version is genuinely modest: capture the sub-processor lists your SaaS vendors already publish, subscribe to the advisories of your top ten dependencies, and keep lockfiles or SCA output current so the next library scare is an hour of grep rather than a week of archaeology. Write one paragraph on where you chose to stop and why — documented proportionality passes audits, silent omission does not. And if you sell software yourself, publishing your own sub-processor list and SBOM is the cheapest trust signal you can buy.
Common Challenges & Solutions
Challenge
Suppliers refuse to disclose their own suppliers, citing confidentiality or simply not knowing.
Solution
Ask for what already exists rather than bespoke disclosure: published sub-processor pages, the subservice organization sections of their SOC 2 report, shared-responsibility documentation. Contract for notification of material changes even where full lists are withheld. Where a critical-tier supplier stays opaque, treat the opacity itself as a risk — accept it formally, compensate with reduced data exposure, or re-source.
Challenge
SBOMs are unavailable or unusable for most commercial software the organization buys.
Solution
Do not make SBOM delivery a blanket gate yet — require vulnerability disclosure policies and support lifecycle commitments as the minimum, and take SBOMs where vendors can produce them. Apply SCA tooling to your own codebase so the dependencies you control are fully mapped. Revisit vendor SBOM expectations periodically; procurement leverage is shifting as large buyers and regulators normalize the ask.
Challenge
The "are we affected?" fire drill takes days because nobody knows where components actually run.
Solution
Invest in the inventory legs before the next event: asset register tied to software inventory (A.5.9), configuration baselines (A.8.9), and dependency manifests or SCA scans for everything you build. Rehearse with a real advisory once or twice a year and time yourselves. The drill converts an unbounded incident-day panic into a bounded lookup, and the timing record doubles as audit evidence.
Challenge
Concentration risk is invisible because each supplier review looks at one supplier at a time.
Solution
Add an upstream-dependency column to the register for critical suppliers — cloud provider and region, identity provider, connectivity — and review the aggregate picture at architecture or continuity reviews rather than per-supplier. Where several critical paths share one upstream, decide deliberately: documented failover, a second supplier, or a signed risk acceptance. The deliverable is the map; without it the discussion never happens.
Challenge
An MSP holds broad, standing, barely monitored access because the relationship predates the security program.
Solution
Re-baseline the access as if onboarding them today: scope to need, move connections behind PAM or jump hosts with session recording, time-bound and individually attribute credentials, and alert on activity outside agreed windows. Put the MSP's admin actions into your SIEM scope. Contractually, add subcontractor disclosure and incident notification at the next renewal — MSP compromises are exactly the scenario those clauses exist for.
