Staying up is a design decision, not an aspiration.
We map the services your customers and regulators actually care about, trace them to the people, systems and suppliers that carry them, set impact tolerances that can be measured, and test until the plan either holds or tells you where it does not.
- Important business services defined by customer impact
- Dependencies traced through to fourth parties
- Impact tolerances set where they can be tested
- Recovery demonstrated, not asserted
The findings that recur across resilience engagements, in roughly the order they surface.
- A critical service depends on one person's knowledge
- Recovery has been tested for the system, never the service
- Two independent vendors share an upstream provider
- The workaround assumes a system that is also down
- Restore works; restore inside the stated RTO does not
What we deliver.
Programme design where resilience is new, and targeted work where the framework exists but has never been proven against a real disruption.
Important business services
Resilience work fails at the first step more often than the last: a service defined from the org chart rather than from what a customer would notice going missing.
- Service identification & definition
- Customer and market impact analysis
- End-to-end process mapping
- People, premises and system dependencies
- Third-party dependency linkage
- Service ownership & accountability
Impact tolerances
A tolerance is a statement about the point at which disruption becomes intolerable — expressed in time, volume or customers, and set where it can actually be tested.
- Tolerance definition & calibration
- Metric selection and measurement
- RTO / RPO alignment
- Board approval and review cycle
- Vulnerability identification
- Remediation planning against gaps
Continuity and recovery
Recovery capability demonstrated rather than documented. A plan nobody has executed under time pressure is a hypothesis.
- Business continuity plan design
- Disaster recovery assessment
- Backup and restore testing
- Failover and workaround design
- Crisis management & communications
- Third-party exit and substitution plans
Testing and assurance
Severe but plausible scenarios chosen because they are uncomfortable, run against the real dependency map, with findings that change the design.
- Scenario design & severe-but-plausible testing
- Live and simulated exercises
- Incident analysis & root cause
- Lessons-learned to structural change
- Resilience risk register & indicators
- Regulatory reporting & self-assessment
How a resilience programme earns its conclusion.
Five steps that separate a continuity plan on a shared drive from a service you can defend in front of a regulator.
- 01
Define services from the outside in
Start where disruption is felt — a payment that does not settle, a claim that cannot be filed — and work back through the processes, systems, people and suppliers that deliver it.
- 02
Map the dependencies honestly
Including the ones that are inconvenient: the single engineer, the unsupported component, the two vendors that turn out to share an upstream provider.
- 03
Set tolerances you can be held to
Expressed in time and volume, agreed at board level, and low enough to be meaningful. A tolerance nobody could breach is not a control on anything.
- 04
Test against the tolerance, not around it
Scenarios designed to breach the tolerance are the ones that produce information. Exercises that confirm the plan works confirm only that the scenario was chosen kindly.
- 05
Close the vulnerabilities you find
Testing produces a remediation backlog or it produced nothing. Actions are sequenced by the exposure they remove, tracked to closure and re-tested.
Find out where the service actually breaks.
Start with one important business service: mapped end to end, tolerance set, and tested against a scenario chosen to hurt.