We have backups. Isn't that our disaster recovery plan?

The difference shows up on the worst day. Say the server dies or ransomware locks everything on a Tuesday morning. The backup means your data still exists somewhere; it does not answer the operational questions: which system comes back first? Where does it run now that the hardware is gone? Who calls the insurance carrier, who tells customers, and can the team keep working from phones and paper in the meantime? A disaster recovery plan is simply those decisions made in advance, calmly, instead of at 8am with the whole staff standing around.

Two numbers do most of the work, and they have plain-English versions. Recovery time objective: how long can each system be down before the damage gets serious? Recovery point objective: how much recent work can you afford to lose, which is really a question about how often backups run? The answers differ by system: card processing might tolerate an hour, the document archive a few days. A real plan lists your critical systems in priority order with a target for each, plus the restore method that can actually meet it. If the target is measured in hours but the backup is a nightly copy that takes two days to restore onto hardware you do not own yet, the plan is what exposes that mismatch before it costs you.

For a small business this does not need to be a binder. One or two pages: systems ranked, recovery targets, where the backups live and who can access them, the order of operations, and a contact list (IT provider, insurer, key vendors). Then test it: a restore drill once or twice a year turns theory into rehearsal. The question to ask your provider today: if the server died right now, how long until we are working again, and when did we last prove it? A measured answer means a plan exists. A guess means it does not.