Auditor asks for business continuity plan. You produce forty-page document, signed by board. Then: when did you last failover to backup region? Never. What RTO did you measure? We do not know. BCP exists — capability does not.
In hosting, business continuity plays at intersection of your application, your backups, and host commitments (SLA, redundancy, incident support). Compliant PDF without measured test protects neither users nor your controller liability during prolonged outage.
Document vs capability: two distinct deliverables
BCP document describes scenarios, roles, contacts, service priorities, trigger criteria. Essential for governance.
Capability proves you can actually recover: measured restore, network failover, emergency admin access, client communication.
| Element | Document | Proven capability |
|---|---|---|
| Backup | Written policy | Dated restore < RPO |
| Failover | Architecture diagram | Recent DNS / failover test |
| Support | Escalation number | Timed ticket on exercise |
| Data | Processing register | Reloaded test dataset |
Untested BCP is regulatory fiction — useful on paper audit, dangerous in real incident.
Credible hosting scenarios
Prioritize plausible breaks over Hollywood disaster.
Regional datacenter outage. Does host failover automatically? Must you restore to another region yourself?
Ransomware encrypting prod plus backups. Are immutable or offline copies outside compromised perimeter?
Human error (DROP, bucket deletion). Point-in-time recovery available? Delay?
Provider failure (bankruptcy, abrupt termination). Reversibility plan — see Cloud reversibility.
Per scenario: target RPO/RTO, owner, host dependency, last test proof.
What host contract must clarify
Availability SLA ≠ full continuity. Read exclusions: maintenance, force majeure, massive DDoS, client backup responsibility.
Require: primary and backup location, support restore window, "production down" incident priority, temporary access if credentials lost.
Compare players via directory crossing SLA, regions, snapshot options — not "high availability" slogan.
The summit: continuity measures in minutes, not pages
Decide and move forward without blind spots
Pick a realistic scenario — e.g. full staging restore from backup — and time it. Document gaps versus target RTO and RPO, then update BCP with dated results. Schedule next annual test before fiscal year end. Cross-check with Restore proof and comparator to validate host.
Frequently asked questions
Does host-provided BCP suffice for audit?
No. Their BCP covers infrastructure; yours covers application, data, contacts, SLA dependency. Both documents complement.
What is the difference between RTO and RPO?
RPO = max acceptable data loss. RTO = max delay to restore service. Confusing both falsifies fast recovery promises.
How often test?
At minimum annually for sensitive processing; after major architecture or provider change. Dated test beats recent PDF.
Does multi-region guarantee continuity?
Not without replication, tested DNS failover, documented runbook. Multi-region without test = expensive empty shell.
Credible BCP fits one sentence: last test on [date] restored [service] in [duration] with [data loss].