Managing information security in the information and communication technology (ICT) supply chain

Plain-language summary

Extending supplier risk management down the ICT supply chain — the hardware, software, cloud components and sub-suppliers behind your direct suppliers — so that a weakness in a component or a subcontractor two layers down does not become your incident.

What the clause is really asking

Your IT provider resells a firewall built by one company, running code from dozens of open-source projects, supported by a subcontractor you have never met. This control asks you to define and apply processes for managing the security risks in that chain for ICT products and services. Practically: require direct suppliers to pass your security requirements down to their own suppliers; ask them to identify the components and sub-suppliers that matter for critical products; prefer vendors with a published vulnerability disclosure and patching process; get notice of end-of-support dates; buy from authorised channels to avoid counterfeit or tampered equipment; and know which products you depend on so you can act quickly when a component vulnerability is announced. Where the product matters, ask for a list of its software components, often called a software bill of materials. The common misunderstanding is that this applies only to software houses. Any organisation that buys firewalls, laptops, SaaS or a managed service has an ICT supply chain; the depth of effort should match how critical the product is to you.

What auditors look for

Auditors ask which ICT products and services are critical, then pick one — often the firewall, the ERP or the managed service — and ask how you know about its components and sub-suppliers. They check whether supplier contracts require security terms to be passed down to subcontractors, whether equipment was bought through authorised channels, and how you hear about vulnerabilities and end-of-support dates. A favourite test is a recent, widely publicised component vulnerability: did you know within days whether you were affected, and where is the record? They also ask what happens when a key product reaches end of support.

Typical evidence

List of critical ICT products and services with vendor, reseller and known sub-suppliers; contract clauses requiring flow-down of security requirements; subscriptions to vendor security advisories and response records; end-of-support register; purchase records from authorised resellers; software component lists for critical or in-house software; impact assessment records for major component vulnerabilities.

How to comply — recommendations

Mark the ICT products and services in the supplier register that would stop the business or expose sensitive information if compromised; most organisations of this size end up with ten to twenty. For each, record the vendor, the reseller or integrator, any known subcontractor, and the end-of-support date. Add a flow-down clause to the supplier security schedule so direct suppliers must apply equivalent terms to their own suppliers. Subscribe a named person to each critical vendor's security advisories and log what was done about each relevant one. Buy network and security equipment only through authorised channels. For in-house or commissioned software, require a component list and keep it current. Revisit the list whenever you buy a new critical product.

Common nonconformities

No identification of critical ICT products or their supply chain; supplier contracts with no flow-down of security requirements to subcontractors; no process for receiving vendor security advisories; products past end of support still in production with no risk decision; equipment bought from unauthorised sources; no knowledge of third-party components in in-house software; major component vulnerability with no recorded impact assessment.

Resources for this clause

• ArticlePOPIA section 19 and ISO 27001: how the standard evidences the law — and why a certificate is not compliance
• ArticleISO/IEC 27001:2022 Annex A explained: the 93 controls in plain English, theme by theme, with the 114-to-93 map and the attribute tags
• ArticleThe Statement of Applicability, explained — what ISO/IEC 27001 clause 6.1.3 requires, the four ways an SoA fails Stage 1, and how to build one from the risk register
• ArticleISO/IEC 27001:2022 explained for people who already run ISO 9001: what is the same, what is new, and how to get certified
• Toolkit · $39Risk & SoA ToolkitScore your information security risks on a documented method, pick the Annex A controls that treat them, and the Statement of Applicability writes its own first draft — every justification citing the risks behind it.
• Toolkit · $29ISMS Metrics & Evidence TrackerThe three things an ISMS has to show after certification, in one workbook: measures with a live Green / Amber / Red status, management review minutes that cover every required input, and an evidence register that gives every control an owner, a rhythm and a due date.
• Free downloadAnnex A 93 Controls Quick ReferenceOne A3 page: all 93 Annex A controls in their four themes, the eleven new in 2022 flagged, and the ISO/IEC 27002:2022 attribute legend — the poster for the wall beside the Statement of Applicability.
• Free downloadISO 27001 Gap Analysis ChecklistWhere you stand against ISO/IEC 27001:2022 in one afternoon — the 30 management-system requirements and all 93 Annex A controls, scored, with owners, dates and a readiness figure that calculates itself.
• Free masterclass · ~27 minISO 27001 MasterclassYou already know four fifths of ISO 27001. Here is the other fifth — the risk method, the SoA, the 93 controls, the evidence rhythm, POPIA, and a 44-week path.
• Free appAudit ManagerPlan the programme, anchor each finding to its clause and drive the NC to closure.