Don't Panic — Business Continuity for IT

Business continuity is the discipline of keeping essential work going when normal conditions have taken the afternoon off. It is not a promise that nothing fails. It is the plan for deciding what matters first, what can run in a reduced form, and what proof is needed before declaring the situation less alarming.

The trap is to begin with a server list. Servers are very keen to look important, particularly when arranged in a spreadsheet. But payroll depends on approvals, employee data, banking connectivity, and identity. An order service depends on payment, inventory, fulfillment, and support. The useful starting point is the business impact analysis, or BIA: identify the outcome, the interruption it can tolerate, and every person, service, data source, and supplier needed to keep it moving.

Three clocks keep the argument honest. Maximum tolerable downtime says when a business interruption becomes unacceptable. Recovery time objective, or RTO, says how long restoration may take. Recovery point objective, or RPO, says how much recent data may be lost. They are not decorative numbers. If identity, data, application recovery, and validation take longer than the stated RTO, the RTO has made a brave suggestion rather than described a capability.

Recovery also comes in an awkwardly sensible order. First comes activation and notification: decide what happened and who may act. Then recover prerequisites before dependent services. Finally comes reconstitution, the controlled return to normal work, including reconciliation of anything done through a manual workaround. A recovered application with no usable identity service is a beautifully restored door with no handle.

The other surprise is that a backup job is not a recovery test. Training prepares people for roles. An exercise lets them rehearse decisions. A technical test shows whether systems and components work. The evidence that matters includes timestamps, validation results, decisions, gaps, owners, and retests. A document with a recent date is pleasant. A measured restore and a current dependency map are more convincing.

Read the Introduction when the distinction between continuity, disaster recovery, contingency planning, and incident response is still doing a small dance. Use the Slides for the dependency path and time-objective checks. Keep the Cheatsheet nearby when building procedures or exercises. The Practice Reference turns the idea into a BIA and tabletop method; the Exercise asks you to make the chain fit. After that, the plan has become less of a document and more of a capability, which is what it was trying to be all along.

Don't Panic — Business Continuity for IT

Relevant careers