When a supplier goes down,you don't.

A continuity plan you have never tested is a hypothesis, not a capability.

Most organisations can produce a business-continuity document. Far fewer can show, for a given critical service, exactly which suppliers and systems it depends on, how long it can be down before real harm, and the date they last proved they could recover. That gap is precisely what regulators and boards now probe - and where a supplier outage quietly becomes a service failure.

E2ERisk connects business impact analysis, dependency mapping and tested recovery into one live picture. Each important service carries its RTO, RPO and dependencies - including the suppliers behind it - and every exercise and failover test is tracked to closure, rolling up into a Prevent, Absorb, Recover posture you can defend rather than a binder nobody has opened.

Most of the outages that take a service down start outside your own estate, with a supplier you depend on. When they go down, you go down - yet that dependency rarely appears in the continuity plan. E2ERisk maps it before the incident, and makes the link between supplier risk and business continuity visible all the way up to your board.

The FCA, the PRA, DORA and the NCSC CAF all expect the same thing: proven recovery of important business services within a defined impact tolerance. A regulator wants that position current, not reconstructed from a binder on a shelf. The view below shows it live - every critical service, its recovery posture and the gaps that still need closing.

Resilience is not a single number; it is a posture across the whole lifecycle - what you do to prevent disruption, absorb it when it lands, and recover within tolerance. E2ERisk scores all three and keeps the score live, moving as your controls, dependencies and tested recovery plans change rather than freezing on the day the document was written.

The gap is rarely the plan itself; it is whether anyone has proved it works. A BIA frozen two years ago, recovery targets nobody has tested and undocumented dependencies mean the first real test of your continuity capability is the incident itself - which is exactly when you cannot afford to be wrong.

Resilience is built service by service: identify the critical services and their owners, run a BIA for RTO, RPO and tolerance, map the suppliers and systems each one depends on, write the recovery plan, then test it from tabletop to full failover and feed the lessons back in. The position stays current because the cycle keeps running.

A BIA spreadsheet, a folder of BCP documents and a CMDB each hold one piece - impact, plan or wiring - and none of them connects to the supplier risk that actually triggers an outage. The comparison below shows what changes when all three live on one model alongside your assurance data.

The result is recovery you can evidence rather than assert: every critical service carries a tested plan, an achieved RTO and the dependency map behind it - and the resilience score moves as the evidence does.

Recovering an important business service inside its tolerance is what ISO 22301, the CAF's Objective D, the operational-resilience regime and NIST's recover function all ask for, in different words. Evidence the recovery once and it answers all of them.

The point of the module is what it lets you prove: a Prevent-Absorb-Recover readiness score, exercises from tabletop to full failover, an achieved RTO logged against target for each service, and alignment to ISO 22301 and CAF Objective D - all from the dependency and supplier data you already hold.

Three things come out of the module, each in a form a regulator or a board accepts: the BIA with recovery targets, the dependency map that exposes concentration risk, and the tested recovery plans with their exercise findings tracked to closure.

One body of resilience evidence, mapped to every continuity and operational-resilience regime a UK organisation answers to - so a recovery proven once is reported against ISO 22301, the CAF, DORA and the rest without being rebuilt.