Business Continuity& TechnologyResilience Planning
Which systems the business genuinely cannot trade without, what those systems depend on, how long you could manage without each of them, and what everybody does in the first hour.
Most continuity plans have never been read by the people who would need them.
There are two common positions. Either there is no plan at all, or there is a substantial document produced some years ago that references a server that no longer exists and two members of staff who have left.
We produce something shorter and more useful: an accurate map of what the business depends on, an honest assessment of how exposed each dependency is, and procedures written so that somebody can follow them under pressure without needing to interpret them.
This is deliberately practical work. It is not a formal certification exercise and we do not pretend otherwise — but a plan that is correct and three pages long is worth considerably more than one that is comprehensive and out of date.
Critical services down to the things they quietly depend on.
The dependency layer is where the surprises are. Almost every organisation we speak to discovers at least one dependency it had not thought about.
Exposures this engagement is built to find.
- 01Backups assumed rather than verifiedA backup that has never been restored is a belief, not a control. Establishing whether a restore actually works frequently changes the whole conversation.
- 02Undocumented single points of failureOne server, one account, one supplier or one colleague on whom a critical process silently depends.
- 03Recovery order never agreedWhen several systems fail together, the order of restoration matters. Deciding it during an incident wastes the hours that matter most.
- 04No agreed tolerance“How long could we manage without this?” is a commercial question, not a technical one, and it should be answered by the business before an incident.
- 05Supplier obligations overestimatedContracts usually promise less protection than people assume. Reading what the supplier is actually committed to is a short task with a long benefit.
- 06Plans nobody could followA procedure written in general terms is useless at seven o'clock in the morning. Steps, names and telephone numbers are what make a plan usable.
What the engagement covers.
When organisations commission this.
Five stages over three to five weeks.
Stage one requires business input rather than technical input. Tolerance is a commercial judgement and has to come from the people accountable for it.
- Stage 01Critical services and toleranceA working session with the business to agree what cannot stop, and for how long. Output: an agreed, written statement of tolerance.
- Stage 02Dependency discoveryTracing each critical service through the systems, connections, suppliers and people it relies on. This stage produces the surprises.
- Stage 03Risk and protection assessmentCurrent protection compared against stated tolerance, including a genuine examination of backup and restore arrangements.
- Stage 04Fallback and recovery designPractical interim arrangements and recovery steps, written with your team so that they are workable rather than theoretical.
- Stage 05Documentation and walkthroughA concise plan document plus a walkthrough session in which we talk through a scenario with the people who would be responding.
What you hold at the end.
- A written continuity and resilience plan, kept deliberately short
- Critical service register with agreed tolerances
- Dependency map covering systems, suppliers and people
- Technology risk register suitable for a board paper
- Backup and restore findings, stated plainly
- Step-by-step recovery procedures with named responsibilities
- Communication plan and contact list
- A recommended review cycle so the plan does not go stale
This is practical continuity planning. It is not certification against a formal standard, and we will say so clearly if that is what your situation requires.
And who it is not for.
A good fit
- Organisations that would lose money or reputation within a day of an outage
- Businesses asked to evidence continuity arrangements by clients or insurers
- Anyone who has recently had a near miss and wants to act on it
- Organisations with critical knowledge held by one or two individuals
- Boards wanting an independent view of technology exposure
Probably not a fit
- Formal certification against ISO 22301 or a comparable standard
- Organisations needing day-to-day incident response or a managed service
- Cyber incident response retainers and forensic investigation
- Anyone wanting a document for a tender with no intention of using it
Often taken alongside this one.
Frequently asked.
No. This is practical continuity planning: identifying what matters, mapping dependencies, agreeing tolerances and writing procedures people can follow. Formal certification against a standard is a separate discipline requiring an accredited body, and we will tell you plainly if that is what your obligations actually require.
The work we produce is a reasonable foundation should you later pursue certification, but we make no claim that it satisfies a standard.
We review what is backed up, how frequently, where copies are held, who is able to restore them and when a restore was last performed. Where you or your provider can carry out a test restore during the engagement, we will ask for that and record the result.
We do not perform restores on live production systems ourselves. That work belongs with whoever administers the system, working under your own change arrangements.
That is a useful outcome, and it is common. The plan then prioritises: which exposures to address immediately, which to address at the next natural opportunity, and which to accept knowingly. Accepting a risk deliberately, in writing, is a legitimate position — accepting one by accident is not.
It covers the continuity dimension: if systems become unavailable or data is compromised, how the business continues to operate, what is restored and in what order, and who is told. It is not a cyber security assessment, penetration test or incident response retainer, and those are specialist services we do not offer.
The plan is written to be short and maintainable, with a recommended review cycle — typically annually, plus after any significant system change. We also recommend a brief walkthrough exercise each year, because reading a plan aloud reveals gaps that reading it silently does not.
Someone senior enough to make commercial judgements about tolerance, whoever administers the key systems, and one or two people who run the day-to-day operations. The total time commitment is usually a half-day session plus a few shorter conversations.