SekitCrosswalk
ISO/IEC 27001:2022 · derived mapping target

A.5.21Managing information security in the ICT supply chain

Manage the security risks that flow through your technology supply chain, including the products and services your suppliers themselves depend on. A weakness deep in the chain can still reach you.

Mapped from the Sekit CSF

The Sekit controls that cover this requirement, lens by lens.

RCF-0026Third-party risk management · ProcesssupportsEmbedding breach notification and assessment rights into supplier contracts extends risk management down the technology supply chain, A.5.21's specific concern beyond the direct supplier relationship.RCF-0295Supply chain continuity · PolicysupportsAssessing whether key suppliers could keep operating through a disruption is A.5.21's supply chain risk lens applied to continuity rather than to code or components.RCF-0296Supply chain continuity · ProcesssupportsKeeping a workable fallback for suppliers the business cannot operate without addresses the continuity dimension of the ICT supply chain risk A.5.21 targets.RCF-0316Vendor due diligence · PolicysupportsDocumented security checks before a contract is signed extend A.5.21's supply chain risk management to the point a new dependency is first introduced.RCF-0328Software supply chain (SBOM) · PolicysupportsInventorying the software components the company builds with or depends on, and managing their third-party risk, supports A.5.21's ICT supply chain requirement, which also extends to services, hardware and suppliers' own sub-processors.RCF-0329Software supply chain (SBOM) · ProcesssupportsKeeping the component inventory current and reviewing it for vulnerable or abandoned dependencies is what makes A.5.21's supply chain visibility hold up as dependencies change.RCF-0330Software supply chain (SBOM) · TechnicalsupportsAutomated dependency scanning in the pipeline flags components with known vulnerabilities before release, the technical control that catches risk introduced deep in the ICT supply chain.

NIST CSF 2.0 counterparts

Reached through the Sekit CSF controls both map to — a mapping, not a formal equivalence.

ISO/IEC 42001:2023 — Annex A counterparts

Cyber Essentials counterparts

Evidence that proves this control

What an auditor, or Sekit's evidence engine, asks for.

Vendor due diligence and monitoring
How the company assesses a supplier's security before hiring and monitors it during the relationship, including the process when it ends.
From the Sekit evidence catalog

In practice

This control extends supplier risk one layer deeper: not only the vendor a company contracts with directly, but the components and sub-processors that vendor depends on. In software terms this usually means a dependency inventory, often a software bill of materials, checked for known vulnerabilities before release, plus a question in the vendor questionnaire asking who the vendor's own critical sub-processors are. Auditors probe this by asking about a recent widely reported supply chain incident and whether the company could tell, from its own records, whether it was affected within a day rather than finding out from a customer.

Common gaps

The company tracks its direct suppliers but has no visibility into which sub-processors or fourth parties those suppliers depend on for critical services.
Dependency scanning flags vulnerable components in the pipeline, but nobody owns triaging the results, so known issues sit open for months.
When a widely reported supply chain incident hits a common library, the company has no fast way to check whether it is affected, only a manual search after the fact.

Questions your auditor will ask

Do you track the sub-processors your critical suppliers rely on?
Show the vendor due diligence records asking each critical supplier to disclose its own critical sub-processors and any recent change to them.
How do you know which third-party software components your applications depend on?
Point to the software component inventory, kept current and reviewed for vulnerable or abandoned dependencies on a regular cycle.
What happens when a known vulnerability is found in a widely used dependency?
Describe the automated dependency scanning in the build pipeline and the triage process that assigns and tracks remediation for what it flags.

Where regulation demands it

NIS2 art. 6.1 (Security in acquisition of ICT services or products) requires the same supply chain risk management A.5.21 asks organizations to extend beyond the direct supplier.
ENS op.pl.3 (Adquisición de nuevos componentes) is Spain's equivalent for assessing risk in newly acquired components and services.

Related controls

Via the shared Sekit CSF topic, not the framework's own index.

Ask Sekura: “What evidence proves A.5.21?”
Also via MCP, free with account