Skip to content

Supply Chain & Resilience

Supply chain and resilience

In short

Supply chain security is the practice of identifying, assessing and monitoring the risk an organisation inherits from its suppliers, service providers and software dependencies. It covers criticality tiering, evidence-based supplier assessment, contractual security requirements, software bill of materials, and the resilience planning that determines what happens when a supplier fails.

The problem

You are accountable for an estate you do not control, and the questionnaire is not evidence.

Most organisations discover the shape of their supply chain risk during an incident rather than before one. A provider goes down, or is breached, and the questions arrive at once: what did they have access to, what does this stop us doing, which of our customers need telling, and how many other suppliers are in the same position.

The usual control is an annual security questionnaire. It is better than nothing and it is not evidence of anything: it is a supplier's own account of themselves at a point in time, usually completed by someone in sales, rarely verified, and out of date within months. Regulators have noticed. DORA, NIS2 and the UK Cyber Security and Resilience Bill all move in the same direction, towards demonstrated oversight of critical providers rather than collected attestations.

The work that changes the position is unglamorous: know which suppliers you actually depend on, tier them honestly by what a failure would do to you, verify the top tier against evidence, put enforceable terms in the contracts, and monitor the ones that matter continuously.

Who this is for

  • Financial entities in scope of DORA, which has applied since 17 January 2025.
  • Organisations in NIS2 sectors, and those likely to fall in scope of the UK Cyber Security and Resilience Bill once it becomes law.
  • Suppliers to central government and critical national infrastructure, where assurance flows down the chain.
  • Companies whose board asked about aggregate exposure after a supplier was breached and did not get a clear answer.
  • Organisations running supplier assurance on spreadsheets and self-assessments that nobody reads.

Delivery

How the engagement actually runs

Sprints inside your engineering cycle, with findings arriving continuously rather than a report arriving at the end. Durations are elapsed time for a typical scope, and get re-scoped against your estate before anything is committed.

  1. 012-3 weeks

    Discovery

    Build the real dependency picture from procurement, finance, SSO and the teams who use the services. Shadow suppliers surface here the same way shadow AI does.

  2. 021-2 weeks

    Tier by criticality

    Tier by operational, regulatory and customer impact of failure. This is the decision that determines where all subsequent effort goes, so it is done with the business rather than for it.

  3. 034-8 weeks

    Verify the top tier

    Evidence-based assessment of tier 1: certificate scope checked, audit reports read, control claims tested where they matter. Findings arrive as they land, not at the end.

  4. 04Ongoing

    Contract, monitor, rehearse

    Security schedules into contracts at renewal, continuous monitoring on tier 1, and a supplier-failure scenario rehearsed with the people who would actually run it.

Deliverables

What you actually receive

Artefacts your team owns and can maintain after the engagement, not a report that ages the moment it lands.

Deliverables for Supply chain and resilience, with what each one contains and when it lands
DeliverableWhat it containsWhen
Supplier and dependency registerWho you actually depend on, including the fourth parties your critical suppliers depend on, and the sub-processors nobody catalogued.Sprint 1
Criticality tieringSuppliers tiered by what their failure would do to your operations, customers and obligations - not by contract value, which is the usual and wrong proxy.Sprint 1-2
Evidence-based assessmentsTier 1 suppliers assessed against evidence: certificates verified as current and in scope, reports read rather than filed, controls tested where it matters.Sprint 2-4
Contractual security scheduleEnforceable terms for new and renewing contracts: notification windows, audit rights, sub-processor change control, exit provisions.Sprint 3
SBOM positionWhere software bills of materials exist, where they are required, and how they are consumed rather than collected.Sprint 3-4
Concentration and exit analysisWhere you are concentrated on a single provider, what substitutability looks like, and what an exit would actually take.Sprint 4
Continuous monitoringOngoing signal on the suppliers that matter, so a change in their posture surfaces before an incident rather than during one.Ongoing

Frameworks this touches

In this practice

The individual services

FAQ

Questions people actually ask

How should suppliers be tiered for security assessment?

Tier by the impact of failure, not by spend. The questions that matter are what data the supplier holds or can reach, whether an outage stops a service you provide to customers, whether a regulatory obligation depends on them, and how quickly they could be replaced. A low-cost provider holding customer data or embedded in a critical path is tier 1; an expensive provider of something substitutable is not.

Is a supplier questionnaire enough?

No, and increasingly not for regulators either. A questionnaire is a supplier's self-description at a point in time, usually completed by someone in a commercial role and rarely verified. It is a reasonable screening tool for lower tiers. For critical suppliers, evidence is what counts: a certificate checked as current and in scope, an audit report actually read, penetration test results reviewed, and specific control claims tested.

What does DORA require for third-party risk?

DORA, which has applied since 17 January 2025, requires in-scope financial entities to maintain a register of information on all contractual arrangements for ICT services, to conduct due diligence before contracting, to include specific contractual provisions covering access, audit, subcontracting and exit, and to have documented exit strategies for critical ICT providers. It also establishes direct oversight of designated critical third-party providers at EU level.

What is an SBOM and do we need one?

A software bill of materials is a machine-readable inventory of the components inside a piece of software, including transitive dependencies. It matters because it turns the question 'are we exposed to this newly disclosed vulnerability?' from a multi-day investigation into a query. Organisations building software increasingly need to produce them for customers; organisations buying software need a way to consume them, which is the part usually missing.

Does the UK Cyber Security and Resilience Bill apply to us?

The Bill is before Parliament and is not yet law, so nothing applies today. As drafted it would extend the existing NIS Regulations to cover medium and large managed service providers, data centres, large load controllers and designated critical suppliers to essential services, with initial incident notification within 24 hours and a fuller report within 72. Commencement is staged from Royal Assent and the substantive duties are left to secondary legislation, with the government having said it intends to consult during 2026.

Free tools

Answer it yourself first.

Nothing is gated. Each one shows you the answer before it asks you for anything, and every date and rate carries the source it came from.

Every tool we publish lives at cloudgap.ai/tools.

Start

Three ways in, depending on how close the deadline is.

Or just email a human: hello@cloudgap.ai

We reply within24 hours