If you can’t test your BCP right now, from your phone, you don’t have a BCP
Gleb Etinzon, DORA Consultancy.
A boutique consultancy addressing complex regulatory requirements in a pragmatic way. London, UK.
Give an authorised incident responder an approved mobile phone. Take away the laptop, cut them off from the office environment and start a ten-minute timer. In that time they should be able to find the current business continuity plan, see who can activate it, read the first actions and reach the people responsible for the response.
If they cannot, the organisation does not have an operational BCP. It has a document describing what people hope will happen.
I see the same illusion again and again. Someone commissions a plan, a consultant fills in a template, management approves it and a line is added to the compliance register. Everybody feels safer. Nobody has checked whether the plan can be used on the day it is needed.
My position is simple. If the essential parts of your BCP cannot be reached and used from a phone, away from your normal working environment, you have not finished building it.
Why should you be able to test your BCP from a phone?
Because disruption does not wait for office hours or working logins.
Picture a Monday morning. The identity provider is down. Corporate email is unreachable. The document repository authenticates through the same identity provider. The office network is out, and the person who coordinates incidents is travelling.
Where is the BCP? Possibly in SharePoint. Possibly as a PDF in somebody’s Downloads folder, or a printout from last year’s audit. Possibly the one person who knows cannot log in.
None of this is exotic. It is a plain dependency problem: the emergency instructions sit behind the infrastructure that needs recovering.
ISO 22301:2019 deals with exactly this. Clause 8.4.4.3 requires each plan to be usable and available at the time and place it is required. The phone test is my practical reading of that requirement. It is not a separate ISO rule. (ISO 22301:2019)
What should a ten-minute test prove?
That the first layer of the response exists independently of normal operations. I ask five questions:
- Can you find the current plan? The latest approved version, with an owner and a revision status. An attachment from six months ago does not count.
- Who can activate it? The incident lead, the deputy, the escalation conditions, and who steps in when the nominated director is unreachable.
- What happens first? Real first actions: which services to protect, which activities take priority, what can run on an alternative process. “Management will convene” is not an action.
- How do you reach the response team? A contact list inside the failed email system is no use. There has to be a route that does not depend on the thing that broke.
- What gets restored first? The critical suppliers, systems and people, and the order of recovery.
If the responder cannot answer, record it as a failure. “They were not familiar with the document” is the finding, and should not be offered as the excuse.
Ten minutes will not validate a whole continuity programme. It will show whether anyone can get to the front door.
What actually breaks once you get past the front door?
Finding the plan is the easy part. The failures that hurt show up when somebody tries to follow it. These are the ones I expect to find, roughly in the order they appear.
Circular dependencies. The recovery runbook lives in the wiki. The wiki sits behind single sign-on. Single sign-on is what failed. The same loop turns up with the password manager, the ticketing system, the chat tool everyone planned to coordinate in, and the status page hosted on the platform that is down. Draw the dependency chain for the recovery itself, and not only for the production service. If any step needs the thing being recovered, the plan stops there.
Expired or unknown secrets. The break-glass account exists, and its password is in a sealed envelope that nobody has opened since the person who sealed it left. The certificate at the recovery site expired in the spring. The API keys were rotated in production and never updated in the standby environment. The backup encryption key is stored in the key vault that the backup is supposed to restore. Every one of these looks fine on paper, because the paper only records that a secret exists. Whether it still works is something only a login attempt will tell you.
Missing privileges. The engineer on call at the weekend can see the failover button and cannot press it. The role that can press it belongs to two people, one on a flight and one asleep. Just-in-time elevation would solve it, except the approval workflow runs through the identity provider. A plan that names a responder without confirming that the responder holds the rights to act, today, on the recovery environment, has named a spectator.
MFA left at home. The hardware key is in a desk drawer at the office that has been evacuated. The authenticator app is on the old phone. The recovery codes were saved to the laptop that is now encrypted by ransomware. Strong authentication is the right default, and it is also a continuity dependency like any other. Somebody has to decide in advance what a responder does at 03:00 with no token, and that route needs to be as well protected as the front one.
Third parties nobody knew about. The customer login depends on an SMS gateway bought on a credit card four years ago. The payments flow calls a sub-processor that the main supplier quietly introduced. The DNS is with a registrar whose account belongs to a former employee’s email address. You find these in an outage, when a service you restored still does not work. DORA’s register of information is meant to stop this, but a register built from the contracts database only lists what procurement knows about. A real failover finds the rest.
The database copy that failed quietly. Replication to the standby broke seven weeks ago and the alert was muted during a noisy migration. The nightly backup job reports success because it successfully backed up an empty directory. The snapshot schedule was attached to a volume that has since been replaced. Green dashboards describe the job, and the job is not the data. The only evidence that a copy exists is a restore.
No integrity validation. The restore completes, the service starts and everyone goes home. Nobody checked whether the last four hours of transactions are there, whether the ledger balances, or whether the restored files were already encrypted when they were backed up. For a financial entity this is the part that turns an outage into a reportable problem. DORA’s Article 12 asks for checks and reconciliations on recovery to protect data integrity, and that needs a defined method: record counts, checksums, reconciliation against an independent source, and a named person who signs off before the service reopens.
No map from business processes to systems. IT restores by tier, and tier one comes back on schedule. Then the operations team points out that settlement also needs a file transfer server from tier three, a shared mailbox and a spreadsheet macro on one person’s desktop. If the business impact analysis lists systems without tracing each critical process through every system, person and supplier it touches, the recovery order is a guess. The quickest way to test this is to ask the process owner to complete one real transaction in the recovered environment, end to end.
RTO and RPO figures the architecture cannot deliver. This is my favourite, because it is arithmetic. The plan promises a four-hour recovery time. The database is two terabytes, the restore runs at about fifty megabytes a second, and that alone is eleven hours before anyone validates anything. The plan promises a fifteen-minute recovery point, and the backups run nightly. Somebody chose those numbers in a workshop because they sounded responsible, and nobody asked what they would cost to build. An objective with no architecture behind it and no test result to support it should not be in the plan. Either fund the design that meets the number or write down the number the current design can meet. Both are defensible. The gap between them is the part no supervisor will accept.
None of these appear in a document review. All of them appear in the first hour of a real test.
And here is the uncomfortable part. Everything on that list happens to the relatively advanced organisations, the ones that have a recovery site, a break-glass account and a backup schedule to get wrong in the first place. They made an effort and got caught by the detail. Most companies are nowhere near this level of thinking. They have a plan nobody has opened since it was approved, and they have not yet reached the stage where an expired certificate could be their problem.
What does DORA expect beyond having a plan?
A good deal more than a document, and the text is specific about it.
Article 11(6) of DORA requires financial entities to test their ICT business continuity plans and their ICT response and recovery plans at least yearly, and again after substantive changes to the systems supporting critical or important functions. Crisis communication plans are tested as well. (Regulation (EU) 2022/2554, Article 11)
The supporting technical standard says what a test has to look like. Under Article 25, testing uses scenarios that are severe but plausible. It covers services delivered by ICT third-party providers where applicable. For entities other than microenterprises, it includes switching from primary infrastructure to redundant capacity, backups and redundant facilities. And it has to be designed to challenge the assumptions the plans rest on, governance and crisis communications included. Results are documented, and deficiencies go to the management body. (Delegated Regulation (EU) 2024/1774, Articles 24 to 26)
Read that list again with the phone test in mind. “Challenge the assumptions” is the important phrase. The largest assumption in most plans is that the plan itself, the contact list and the people named in it will all be reachable when the primary environment is gone. Very few organisations have ever checked.
DORA also refuses to treat continuity as disaster recovery under another name. The ICT continuity policy has to line up with the overall business continuity plans. Restoring a database is a technical task. Deciding that normal service cannot be maintained, moving customer support to another channel, telling the right customers, dealing with transactions stuck in the queue and approving temporary arrangements are business decisions, and the plan has to say who makes them.
Where does ISO 22301 fit?
For organisations certifying to ISO 22301, the same idea runs through the operational clauses, and it is what a Stage 2 audit looks for. Stage 1 reviews the documents. Stage 2 checks that the system operates as described.
| Clause | What has to be demonstrable | Practical evidence |
|---|---|---|
| 8.4 | Usable plans and a response structure | Current plans, activation criteria, named roles and alternates |
| 8.5 | A working exercise and test programme | Schedule, scenarios, reports, actions closed |
| 8.6 | Evaluation of documents and capabilities | Test results, supplier evaluations, updated plans |
A test that finds a failure and then disappears into a folder is unfinished business under either regime.
Isn’t putting the BCP on a phone a security risk?
It is the first objection I hear, and it weighs the wrong risk. In a crisis the priorities change. When production is down and customers cannot be served, nobody is harmed by a responder reading the escalation list on a phone. The harm comes from the responder who cannot read it at all. Confidentiality still matters, but for those few hours availability matters more, and a plan locked away so securely that nobody can reach it has failed at the one thing it exists to do.
So I treat the phone as a real challenge, with different risks from the ones people raise.
The first is staleness. A copy that leaves the controlled repository starts ageing the same day. The deputy changed in March, the supplier’s emergency number changed in June, and the phone still holds January’s version. An out-of-date plan followed with confidence can do more damage than no plan, so the offline copy needs an owner, a refresh routine and a visible version date.
The second is content. The plan should say where the credentials are and who can release them. It should never contain them. If it holds no passwords, keys or recovery codes, a lost phone is an inconvenience. Written the other way, it turns one lost handset into a second incident.
The third is the single device. Phones run out of battery, get dropped and lose signal in a regional outage. The phone test proves independence from ordinary corporate access and nothing more. A resilient arrangement has more than one route to the instructions and more than one way to reach people.
All of this is settled in advance through managed devices, named responders and an approved out-of-band store. That is ordinary design work, and it is a poor reason for keeping the plan somewhere it cannot be reached.
What happens when the BCP has never been exercised?
You have what I call Schrödinger’s BCP. Until somebody tries to use it, the plan is both functional and useless, and the organisation assumes the first because nobody has demonstrated the second.
It is the untested backup problem. A green backup job does not prove the data can be restored, and an approved plan does not prove the business can run on its instructions.
So test it for real, and measure. Start with the phone. Then work through the list above with a stopwatch:
- Log in with the break-glass account, using only what a responder would have at home.
- Fail over to the redundant environment and time it against the stated RTO.
- Restore the largest database from backup, time it, and reconcile the data before calling it done.
- Compare the age of the newest recoverable data with the stated RPO.
- Have a process owner complete one real transaction in the recovered environment.
- Run the call tree out of hours and record each acknowledgement time.
- Ring each critical supplier’s emergency line and note who answers.
Put the people who would make the decisions in the test, and not only the continuity manager who wrote the document. Record what failed, give each failure an owner and run it again. The first run will be embarrassing, and it is supposed to be. It is far cheaper to be embarrassed in a test than in an incident.
Why will a manual recovery still let you down?
Suppose every item above is fixed. The secrets work, the privileges are right, the dependencies are mapped and the numbers are realistic. The recovery is still a sixty-step runbook carried out by tired people in the middle of the night, who last did it eleven months ago, on an environment that has changed every week since.
The odds of that going to plan are poor. Each manual step has a small chance of failing: a command typed into the wrong console, a step skipped, a screenshot in the runbook that no longer matches the screen. Multiply small chances across sixty steps and the result is predictable. Meanwhile the environment drifts. Every deployment, patch and configuration change since the last test is an untested difference between the runbook and reality.
An annual test does not solve this. It confirms the recovery worked once, on that day, with those people.
I have come to think there is only one way out of this mess, which is frequent and fully automated recovery. The standby environment is built from code, the same code as production. Restores run on a schedule, weekly or nightly, into a clean environment, with integrity checks and reconciliation built into the pipeline. Failover becomes a routine operation that the team performs often enough to find boring. Every run reports how long it took and how old the recovered data was, so the RTO and RPO come from last week’s measurement and no longer from a workshop.
When recovery is automated, people keep the decisions: whether to invoke, what to tell customers, when to return to normal. The execution belongs to the machine, because a machine does the same sixty steps the same way every time, and its failures show up on an ordinary Tuesday when nothing is at stake.
It also changes the evidence. A supervisor or auditor asking for proof of testing gets fifty-two dated recovery runs with timings and integrity results, where most organisations offer one annual report.
Does passing prove the company would survive a disaster? No. Nothing in business continuity offers that guarantee. It does remove one basic failure that should never reach a supervisor or an auditor: emergency instructions nobody can get to.
Preparation happens before the incident. There is an old saying about preparing food before the Shabbat: you cannot start cooking once the guests have arrived.
A BCP is an operating capability, and a Word document is only its record. If your organisation cannot find and use its own plan from an approved phone, it should stop saying it is prepared.
Please reach out to the team to test your plan the way it will actually be used.
Ready to discuss your DORA compliance challenges?
Our team of experienced consultants is here to help.
Get in Touch