What Is a Cyber Business Continuity Plan?
Key takeaways
- RTO and RPO are the two numbers that matter: how fast a service must be back, and how much data loss is acceptable, and both must be set per service rather than per company.
- An RPO of zero is a design decision, not a hope, and it requires synchronous replication or immutable copies rather than a nightly backup job.
- Offline or immutable backups are the ones that survive ransomware, and a backup that has never been restored is not a backup.
- Every critical service needs a manual workaround, because the first hours of an outage are worked manually or not at all.
- A business continuity plan without a test is a document, and the test that matters is a timed restore onto clean infrastructure, not a review meeting.
As of 24 October 2026: the service descriptions, prices and turnaround figures on this page are current.
What should a cyber business continuity plan contain?
Seven parts. A business impact analysis, so you know which services stop the business and which can wait. The RTO and RPO for each critical service, agreed with the business owner rather than with the IT team alone. A prioritised recovery sequence, usually identity and DNS first, then core transactional systems, then communications. The dependency map, because a database restored before its identity provider is not much use. Manual workarounds for the first hours, with a named owner for each. The communication plan, covering customers, staff, bank, regulator and insurer. And the test schedule, with a restoration test twice a year and a full tabletop annually, each with an owner and a date.
What is the difference between RTO and RPO?
RTO is time and RPO is data. The recovery time objective is how quickly a service must be working again, and it is a business commitment, so it has to be agreed with whoever owns the revenue. The recovery point objective is how much data you can afford to lose, expressed in time, so an RPO of one hour means you can lose the last hour of transactions. The two constrain each other: a tight RPO of fifteen minutes needs replication, continuous backup or immutable snapshots, while a loose RPO of twenty-four hours can be met by a nightly job. Put the RTO and RPO for every service in one table, because surprises come from services with no number attached.
How do offline backups change the ransomware outcome?
They change the ending. A ransomware operation that reaches the backup console can delete snapshots, shorten retention and encrypt the backup store, and if your restore points live behind the same credentials, your recovery options shrink to whatever the attacker left. An offline, immutable or air-gapped copy cannot be reached with the access the attacker already holds, so the restore does not come from a corrupted store. Two rules follow. Separate the backup administration identity from day-to-day administration, so a compromised domain admin does not open the vault. And test the restore onto clean infrastructure on a schedule, because a backup set encrypted six months ago is still encrypted. Offline storage also protects against accidental deletion and physical events.
How do we test a cyber business continuity plan without a real outage?
In three layers. First a tabletop, one scenario walked through with the roles speaking their sections, which finds missing decisions and out-of-date contacts. Second a technical restore test, where a team restores a random production service from the backup set onto clean infrastructure and the RTO and RPO are measured against the plan. Third a failed restore drill, where you deliberately attempt to restore something broken, because discovering a bad backup set is the whole point of testing. For a small Indian business, one tabletop and one timed restore a year is a reasonable target, and the measurement that reaches management is the actual restoration hours against the promised RTO.
| Component | What it defines | Proof it works |
|---|---|---|
| Business impact analysis | Which services stop the business | A signed ranking per service |
| RTO and RPO | How fast it returns and how much data is lost | A table agreed with business owners |
| Recovery sequence | The order systems come back in | A restore run in that order |
| Manual workarounds | How the business trades in the first hours | A rehearsed process with a named owner |
| Offline or immutable backups | The restore point that survives ransomware | A timed restore onto clean infrastructure |
| Test schedule | How often the plan is exercised | Tabletop and restore test records |
What are the frequently asked questions?
Get a straight answer on this
Send us a list of your critical services and your last restore test date, and we will draft the RTO and RPO table for your business to approve.
Send us the details See pricing