Skip to content

Supply Chain & Resilience

Inventory and risk mapping

What this is

Supplier inventory and criticality mapping identifies every third party an organisation depends on, including the fourth parties its critical suppliers rely on, and tiers them by the operational, regulatory and customer impact their failure would cause. Tiering determines where assurance effort is spent, which is the decision that makes a supplier programme finishable.

The problem

The approved vendor list is not the supplier list, and spend is not criticality.

Every organisation has a vendor list. Almost none of them have a dependency picture. The vendor list contains what procurement onboarded; the dependency picture contains that plus the SaaS tools bought on a card, the free tier that became load-bearing, the sub-processor your critical supplier uses, and the API a single engineer integrated three years ago.

The second failure is tiering by spend. It is the available number, so it gets used, and it is systematically wrong. The most dangerous suppliers are frequently cheap: an authentication provider, a monitoring agent with production access, a small tool holding a copy of the customer database for reporting. Meanwhile the biggest line item is often the most substitutable.

Get the tiering right and the programme is finishable, because most suppliers need almost nothing and a small number need real work. Get it wrong and you spend the year assessing suppliers whose failure would be an inconvenience.

Who this is for

  • Organisations starting a supplier assurance programme who need to know where to point it.
  • Companies in scope of DORA, which requires a register of information on all ICT contractual arrangements.
  • Teams who cannot currently answer which suppliers could stop them operating.
  • Firms whose supplier list lives in a spreadsheet last updated by someone who has left.
  • Anyone who found out about a fourth-party dependency during an outage.

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

    Multi-source discovery

    Procurement records, card and expense data, SSO and identity logs, DNS and network egress, plus interviews. Expect the register to be materially larger than the vendor list.

  2. 021 week

    Tier with the business

    Impact of failure assessed with the people who would experience it, not derived from spend.

  3. 032 weeks

    Map tier 1 in depth

    Data held, access granted, fourth parties, and concentration. This is where the useful answers come from.

  4. 041 week

    Hand over

    Register handed to an owner with a maintenance process wired into procurement onboarding, so it does not decay.

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 Inventory and risk mapping, with what each one contains and when it lands
DeliverableWhat it containsWhen
Dependency registerEvery third party, sourced from procurement, finance, SSO, DNS and the teams themselves - four routes, because each misses different suppliers.Week 2-3
Fourth-party map for tier 1Who your critical suppliers depend on, which is where concentration risk actually lives and where most registers stop.Week 4
Criticality tieringTiered by operational, regulatory and customer impact of failure, agreed with the business rather than assigned by us.Week 4
Data and access mappingWhat each tier 1 supplier holds, what they can reach, and through which route - which is the question everyone asks during an incident.Week 5
Concentration analysisWhere multiple critical services depend on one provider or one region, and what that means for a single failure.Week 6
Maintained registerHanded over with an update process tied to procurement, so it stays true instead of ageing from the day it is delivered.Week 6

Frameworks this touches

FAQ

Questions people actually ask

How do you find suppliers that procurement does not know about?

Four routes used together. Card and expense data surfaces SaaS bought outside procurement. SSO and identity logs show which third-party services staff authenticate to. DNS and network egress data shows where systems are actually talking. And structured conversations with engineering and operations surface integrations nobody catalogued. Any single route misses a significant share - card data misses free tiers, SSO misses anything not federated.

What is fourth-party risk?

Fourth-party risk is the risk inherited from your suppliers' suppliers. If your payments provider depends on a single cloud region, or three of your critical SaaS tools all use the same authentication provider, you carry that dependency without a contract with it. Most supplier registers stop at the third party, which is where concentration risk becomes invisible - and it is the layer that produces correlated failures.

How should suppliers be tiered?

By the impact of their failure across three dimensions: operational, meaning whether an outage stops you delivering to customers; regulatory, meaning whether a compliance obligation depends on them; and data, meaning what they hold or can reach. A supplier scoring high on any one dimension is tier 1. Spend is not a dimension, and using it as a proxy systematically misclassifies cheap, deeply embedded providers.

What does DORA require in the register of information?

DORA requires in-scope financial entities to maintain a register of information covering all contractual arrangements for ICT services, distinguishing those supporting critical or important functions. It includes details of the provider, the service, the function it supports, data locations, sub-outsourcing arrangements, and exit and substitutability assessments. The register is submitted to competent authorities, so its completeness is directly examinable.

More in Supply Chain & Resilience

Start

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

Or just email a human: hello@cloudgap.ai

We reply within24 hours