Disaster recovery restores technology. Business continuity keeps the organization functioning while the technology is unavailable. Organizations often build the first, call it the second, and discover the gap during an incident when somebody asks how orders will be taken for the next six hours.
This page covers the wider discipline: what a continuity plan contains, how it relates to the technical recovery work, and why the exercise matters more than the document.
Two questions, not one
The recovery question is how a system is brought back and how long it takes. The continuity question is what the organization does in the meantime, which is a business question with technical inputs rather than the other way round.
They need each other. A recovery plan with no continuity plan leaves people idle and customers unanswered for the duration. A continuity plan with no recovery plan describes a manual workaround with no end date. The objectives arithmetic underneath both is set out in Disaster Recovery: RTO, RPO and Recovery Planning.
Start with impact, not with systems
A business impact analysis asks what the organization does, what it needs in order to do it, and what happens as the outage lengthens. It is deliberately not a technology inventory, because the useful output is an ordering of business functions by how quickly their loss becomes serious.
That ordering then determines the technical priorities, and it frequently reorders them. The system with the most users is not always the system whose loss stops revenue, and a technically led priority list tends to rank by size and visibility rather than by consequence.
Dependencies are where the analysis earns its keep
Every important function depends on more than the application it runs on. Authentication, DNS, network connectivity, a payment processor, a supplier portal, a single spreadsheet, a licence server, a person.
Mapping those dependencies produces the two findings that matter: functions that cannot be recovered in the order the plan assumes, and single points of failure sitting underneath several supposedly independent services. Identity is the usual example. Almost nothing recovers before it, and almost no plan sequences it first.
What a continuity plan actually contains
The parts that get used during an incident are narrow and practical: who decides that the plan is active, who does what, how people communicate when the normal channels are part of the outage, how each critical function operates in degraded mode, and what the criteria are for returning to normal.
Everything else in a typical continuity document is context. Useful for the audit, not consulted at three in the morning. A plan that cannot be acted on from its first two pages is unlikely to be acted on at all.
Declaring a disaster is a decision with an owner
Recovery actions are frequently disruptive and sometimes irreversible. Failing over to a secondary site, cutting DNS, or restoring from a point in time all discard something. Deciding to do them is a judgement about whether the outage will outlast the alternatives, and that judgement needs a named owner and a deputy.
Without that, the common failure is delay: an hour of hoping the problem resolves itself, spent because nobody was sure they had the authority to act. The decision criteria should be written down while nobody is under pressure.
Communications fail first and matter most
Incident communications frequently depend on the systems that are down. Email, chat, the intranet, the phone list stored in a directory that will not authenticate.
An out-of-band contact method, held somewhere that does not depend on the estate, is a small piece of preparation with an outsized effect. So is deciding in advance what customers are told, by whom, and how often, because the alternative is that the first public statement is written by whoever is least busy.
Recovery is a framework function, not an afterthought
Recovery is treated as a first-class concern in the current federal framework rather than as an appendix to security. The NIST Cybersecurity Framework 2.0 organizes outcomes into six functions: GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND, and RECOVER. See The NIST Cybersecurity Framework (CSF) 2.0.
Putting recovery alongside protection makes a point worth keeping: preventing incidents and surviving them are separate programs of work, and an organization can be strong at one and absent at the other.
Alternate processing, and what it costs
If a function has to continue while its primary environment is unavailable, something has to run it. Federal control catalogues treat this explicitly, with the ALTERNATE PROCESSING SITE control requiring an alternate site along with the agreements that make it usable within the organization's own recovery time objective. See NIST SP 800-53 Revision 5.
The agreements are the part most often missing. Capacity that exists in principle and cannot be claimed during a regional event is not capacity, and that is a contractual question rather than a technical one.
Cloud changes the economics and not the discipline
Standby capacity used to mean a second set of hardware, mostly idle. In cloud environments the same outcome can be arranged as configuration and paid for when used, which makes a warm secondary affordable for organizations that could never justify a second data center.
What it does not change is the need to test it, the need to keep configuration in step between the two, and the need to understand what a regional failure would do to both. LABUSA has designed and configured failover of this kind, and it is current practice rather than a theoretical capability. Hybrid Cloud Infrastructure covers the wider arrangement.
Data, and what gets recovered to when
Continuity planning assumes the data will be there. That assumption rests on the backup regime, which is covered in Backup and Data Protection, and the two need to be checked against each other rather than assumed to agree.
They frequently do not. A plan promising a two-hour recovery point on a system whose backups run nightly is a plan describing something the estate cannot do, and the discrepancy is only visible when somebody compares the two documents.
Availability design reduces how often the plan is needed
Resilient architecture and recovery planning solve different halves. Redundancy handles the common failures automatically and without a decision; recovery handles the failures that defeat it.
Investing only in redundancy produces an estate that survives component failure and has no answer to a regional event or a logical error. Investing only in recovery means invoking a heavyweight process for problems that should have been absorbed. Designing Infrastructure for High Availability covers the first half.
Suppliers have continuity plans, or do not
Most organizations depend on third parties for functions they could not perform themselves, and inherit those suppliers' resilience without examining it. A continuity plan that assumes a supplier will be available is making a claim about somebody else's estate.
The practical step is modest: know which suppliers are critical, ask what their recovery commitments are, and know what your organization does if a critical one is unavailable for a day. The answer is often uncomfortable and always better known in advance.
Exercises find what documents hide
A plan that has never been exercised is a hypothesis. Exercises range from a discussion around a table to a full failover, and the cheap end is worth far more than its cost.
What they reliably find is unglamorous: contact details that are wrong, a procedure that assumes access nobody has, a step that depends on a person who has left, a dependency nobody documented, and an estimate of recovery time that is wrong by a factor. None of these are visible in a review, and all of them are visible within an hour of walking through the scenario aloud.
Returning to normal is part of the plan
Plans describe how to fail over and go quiet about how to come back. Failback is often harder than failover: data has changed in the secondary environment, the two are out of step, and returning means a second planned outage nobody budgeted for.
Deciding in advance how reconciliation works, and whether the secondary simply becomes the new primary, removes a decision from a moment when everyone is already tired.
Keeping the plan true
Plans decay. Systems change, people move, suppliers are replaced, and a continuity document eighteen months old is describing an organization that no longer exists in that shape.
Attaching review to change rather than to the calendar is what keeps it current: a new critical system, a new supplier, or a reorganization each triggers a look. How LABUSA runs continuity alongside day-to-day operations sets out where this sits with monitoring, backup and infrastructure management.