Supply chain resilience is the ability to keep your critical activities running when a supplier fails, degrades or becomes unavailable. It is a continuity question rather than a procurement one. The test is not whether you have assessed a supplier’s security, but whether you know what stops if they stop, how long you could absorb it, and whether you could realistically move.
- Ranked by consequence of loss, not by contract value or spend.
- Concerned with availability and substitutability as much as with security.
- Extends past your direct suppliers to the ones they depend on.
- Concentration is the risk that hides best and hurts most.
- An exit route you have never tested is an assumption, not an option.
What is supply chain resilience?
Most organisations have some form of supplier assessment. It usually establishes whether a supplier takes security seriously, holds the right certifications and will sign the right clauses. That is worth doing, and it answers a different question from the one resilience asks.
Resilience asks what happens next. If this supplier is unavailable for a week, which of your activities degrade, how quickly, and what do you do in the meantime? A supplier can be entirely competent, fully certified and still represent a single point of failure, because resilience is a property of your dependency structure rather than of their control environment.
That reframing changes what you measure. Instead of a questionnaire score, you want to know which activities sit behind each supplier, what the recovery timeframe for those activities is, and whether the alternative arrangement could actually deliver it. The activity level view comes from your business impact analysis, which is why supplier work done in isolation from continuity work tends to protect the wrong relationships.
How is this different from third party risk management?
The two overlap and both are necessary, but they are asking different questions and they produce different artefacts. Third party risk management is largely about assurance: has this supplier got adequate controls, and can we demonstrate that we checked. Supply chain resilience is about continuity: what breaks, how fast, and what we do instead.
The practical consequence is that a mature third party risk programme can coexist with a fragile supply chain. If every supplier has been assessed but four of your critical activities run through the same cloud region, your assurance is in good order and your resilience is not. Conversely, a supplier with a modest security posture may present very little resilience risk if they are easily replaced and nothing time critical depends on them.
If your immediate need is tooling for the assurance side, that is covered separately under third party risk management software and vendor risk management software. If your scope is set by regulation, the NIS 2 view of supplier obligations is set out under NIS 2 supply chain security and the clauses that follow from it under expected contract clauses. This page is about the resilience layer that sits across all of them.
Which suppliers actually matter?
Tiering by spend is the default and it is close to useless for this purpose. The suppliers that can stop your business are frequently cheap: a small integration provider, a single specialist, a niche data feed. Tier by consequence of loss instead, and let the tier set what you ask for.
| Tier | What you require | Evidence that proves it |
|---|---|---|
| Critical Loss stops a critical activity inside its recovery timeframe. |
Continuity and recovery obligations in contract, tested exit route, named contacts, joint exercising, visibility of their key dependencies. | Their continuity test results, a joint exercise record, and your own documented exit walkthrough. |
| Important Loss degrades an activity but a workaround holds for a while. |
Continuity commitments, notification duties on incidents, an identified alternative even if not tested. | Their certification scope, incident notification terms, and your documented alternative arrangement. |
| Standard Loss is inconvenient and absorbable. |
Baseline security terms and a replacement that could be sourced normally. | Standard assessment on file, refreshed on a defined cycle. |
| Embedded Not a supplier relationship but a component inside your product. |
Component inventory, vulnerability monitoring, a maintained update path. | A current component inventory and a record of how vulnerabilities are triaged. |
The fourth row is the one most registers omit entirely. Open source libraries and embedded components carry no contract and no account manager, so they never enter a procurement led register, and they sit inside the products your critical activities run on.
There's a bigger picture behind this.
This page covers one part of business resilience. Real Resilience — IO’s framework for connecting security, privacy and AI governance — is where the full picture comes together.
Where does concentration risk hide?
Concentration is the failure mode that a supplier by supplier assessment is structurally unable to see. Each relationship looks adequately managed. The exposure only appears when you look across them, and it usually appears in one of four shapes.
| Shape | How it stays hidden | What to do about it |
|---|---|---|
| Single supplier, many activities | The relationship is well managed, so nobody counts how many critical activities depend on it. | Map activities to suppliers rather than suppliers to owners, and count the dependencies in the other direction. |
| Shared sub processor | Two or three independent looking suppliers all sit on the same provider underneath. | Ask each critical supplier who they depend on, and look for the repeated name across the answers. |
| Single region or facility | Redundancy exists on paper but every copy lives in the same failure domain. | Confirm where data and processing physically sit, including backups and the failover target. |
| Single person or skill | It is a resourcing matter, so it never reaches the supplier register at all. | Treat a sole specialist as a critical dependency and plan for their absence explicitly. |
The second shape is the one that catches capable organisations. Deliberately contracting two providers for redundancy achieves nothing if both are built on the same platform, and you will not discover that from either supplier’s assessment because neither is wrong about their own arrangements.
How do you build supply chain resilience?
The sequence matters more than the tooling. Most programmes start at the assessment step, which means they are assessing a list that was never derived from what the business actually needs.
Two of these deserve more attention than they usually get. Requiring continuity obligations contractually is the only point at which you have real leverage, and it is far cheaper at renewal than during an incident. Exit is the step almost everyone documents and nobody tests. An exit plan that has never been walked through tends to assume data will be returned in a usable format, that someone retains the knowledge to reimplement, and that the timeline is measured in weeks rather than quarters.
Monitoring is not a questionnaire refresh. What changes between assessments is usually structural: your supplier acquires a new sub processor, consolidates a data centre, or shifts a service onto a platform you already depend on elsewhere. Those are the changes that create concentration, and they do not show up in a security questionnaire.
What about fourth parties and software components?
Your suppliers have suppliers. For a critical dependency you need at least a name level view of theirs, because a failure two steps away reaches you just as effectively as a direct one and you will have no contractual relationship to work with. The reasonable ask is not a full sub tier audit but disclosure of the dependencies that would interrupt the service you rely on, plus notification when those change.
Software components are the same problem in a different form. Modern applications are assembled largely from third party libraries, and a vulnerability or an abandoned project in one of them is a supply chain event with no supplier attached. A software bill of materials, a machine readable inventory of what a product is built from, is what makes that population visible. It is increasingly asked for by customers in procurement, and it is a practical prerequisite for answering the only question that matters during a component vulnerability: are we affected, and where.
For organisations that supply technology services to others, this cuts both ways, since you are also somebody’s critical dependency. That perspective is covered under resilience for managed IT providers.
ISO 27001 made easy
An 81% Headstart from day one
We’ve done the hard work for you, giving you an 81% Headstart from the moment you log on. All you have to do is fill in the blanks.
How does supply chain resilience connect to business resilience?
Suppliers are where the boundary of your control environment stops and your exposure does not. That makes the supply chain the clearest illustration of why resilience has to be governed as one system rather than assembled from separate assessments.
The Resilience Loop runs information security under ISO 27001, data privacy under ISO 27701 and AI governance under ISO 42001 as one connected system. Supplier work is where the saving is most obvious. The same supplier is a security dependency, a processor of personal data and, increasingly, a provider of an AI component with its own accountability questions. Assessed three times by three teams, you get three registers that disagree. Assessed once against one control set, the answer serves all of them, which is the argument set out in the business resilience framework.
ISO 27001 supplies the supplier controls in Annex A, covering security in supplier relationships, what agreements must address, the ICT supply chain specifically, and monitoring of supplier services as they change. ISO 22301 adds the continuity dimension, requiring that dependencies including suppliers are accounted for in the recovery arrangements. Together they cover assurance and availability, which is the pairing this page is about. For organisations under regulatory dependency requirements, the operating model is described under operational resilience.
How do you prove supplier resilience?
A register of completed questionnaires demonstrates diligence, not resilience. What answers the harder question is narrower and more specific: the mapping from critical activities to the suppliers behind them, the tier assigned to each and why, the continuity obligations actually secured in contract, the evidence each critical supplier has provided about their own arrangements, a record of any joint exercise, and the exit route with a note of when it was last walked through.
The gap most often found is between the register and the reality: a supplier tiered as critical two years ago whose service has since been consolidated onto a platform you already depend on, with nobody having connected the two facts. Keeping the mapping current is the work, and it is the part that produces the evidence as a by-product. The general approach is set out in how to evidence resilience, and the Resilience Score gives you a baseline. Where a supplier failure would interrupt a critical activity, the response belongs in your business continuity arrangements rather than in the supplier file.
Why choose ISMS.online for supply chain resilience?
The difficulty is never assessing one supplier. It is holding the whole picture accurately as it changes. ISMS.online is built for that.
- Activities mapped to suppliers: see which critical activities sit behind each relationship, and count dependencies in both directions so concentration becomes visible.
- Tiering that drives the work: assign a tier by consequence of loss and let it set what you require and how often you revisit it.
- One assessment, every framework: assess a supplier once against a mapped control set and reuse it across ISO 22301, ISO 27001, ISO 27701 and ISO 42001.
- Contract obligations tracked: continuity terms, notification duties and review dates held with the supplier record rather than in a contract folder.
- Evidence from suppliers stored in context: their certifications and test results sit alongside the activities that depend on them.
- Change and exit ready: review triggers, exit arrangements and the date each was last examined, so the register reflects today.
- Built for UK and regulated markets: designed for organisations that have to prove resilience to win and keep contracts.
See how it fits together on the business resilience platform, or book a demo.
FAQs
What is the difference between supply chain resilience and supply chain security?
Supply chain security is concerned with whether a supplier protects your information and systems adequately. Supply chain resilience is concerned with whether your critical activities survive that supplier becoming unavailable. A supplier can be secure and still be a single point of failure. Both matter, and they produce different work: security produces assurance evidence, resilience produces dependency mapping and alternative arrangements.
How do you identify a critical supplier?
Start from your critical activities rather than your supplier list. For each activity, identify what it depends on and how quickly it must be restored. A supplier is critical where their loss would prevent an activity being delivered within that timeframe. This routinely surfaces low value suppliers as critical, and high value ones as merely important, which is why spend based tiering misleads.
What is concentration risk in a supply chain?
It is exposure created by multiple dependencies resting on the same underlying point of failure. That can be one supplier serving many of your critical activities, several suppliers built on the same sub processor or cloud region, or all of your redundancy sitting inside one facility. It is invisible to supplier by supplier assessment because no individual relationship looks wrong. You only see it by looking across the whole set.
Do we need a software bill of materials?
If you build or ship software, it is becoming difficult to operate without one, both because customers ask for it in procurement and because it is what lets you answer whether a newly disclosed component vulnerability affects you. If you only consume software, the equivalent question is whether your suppliers can tell you, which is a reasonable thing to require of a critical supplier.
How often should supplier resilience be reviewed?
Critical suppliers warrant at least an annual review, and additionally whenever something structural changes: a new sub processor, an acquisition, a service consolidation, a contract renewal or a real disruption. The structural changes matter more than the calendar, because they are what creates new concentration. Lower tiers can sit on a longer cycle, provided the tiering itself is revisited when your critical activities change.
