Why test readiness
In our experience most continuity plans do not survive first contact with reality: contacts are out of date, the named owner has left, the backup will not restore, and decisions in the first hours are taken by someone without the authority to take them. Testing surfaces all of this early, while fixing it is still cheap. For companies working to ISO 22301, regular testing is a direct requirement of the standard.
Methods of testing: from simple to deep
- Tabletop exercises. The management team works through a scenario around a table: who finds out first, who decides, what we tell clients. Takes 3-4 hours and exposes most organisational gaps. More in the article on continuity exercises.
- Stress simulation. The team lives through a realistic scenario — most often a ransomware attack — with timed injects: decisions, communications, recovery. This is the format of our continuity stress test, run with an external facilitator.
- Technical tests. Actually restoring systems from backups with the clock running — part of the IT disaster recovery plan.
- Full stress test. A diagnostic of the continuity system plus a simulation plus the economics of downtime — the most complete snapshot of readiness in a short time.
What to measure
- Recovery time. How long recovery actually takes, against the target RTO.
- Data loss (RPO). How much data is lost when you roll back to the last backup.
- Money. The cost of a day of downtime and the share of revenue at risk — the language leadership actually responds to.
- Quality of decisions. Speed, gaps in authority, readiness of communications — recorded by an observer.
Checklist of first steps
- Pick one scenario — the most painful for your industry (ransomware fits almost everyone).
- Gather the management team and the owners of key functions — 6 to 12 people.
- Run a tabletop session: 3-4 hours on the scenario, with an observer recording the gaps.
- Cost a day of downtime — roughly is fine, based on revenue.
- Write down the findings and assign owners and deadlines for the fixes.
- Repeat in six to twelve months — readiness fades without repetition.
Frequently asked questions
Where do we start with readiness testing?
With a tabletop session on a single scenario with the management team: ransomware or the loss of a key supplier. It takes 3-4 hours and exposes the main gaps.
How often should readiness be tested?
At least once a year on one scenario, and more often for critical IT systems. After any significant change, run an unscheduled check.
What should be measured during a test?
Actual recovery time against the target RTO, tolerable data loss (RPO) and the cost of a day of downtime in money. Plus the quality of decisions and communications.
From standard requirements to a working system
The assessment shows the gap between documents and reality. The system is then built by your people in the programme or by ours turnkey.
