Disaster recovery planning sounds like something only large enterprises need. A workable version for a small organization is much simpler than it sounds.
Define what "disaster" means for you
A ransomware incident, a building fire, a prolonged internet outage, and a key vendor going down are all different scenarios with different responses. Name the two or three most realistic ones for your organization.
Know your recovery priorities
If everything went down at once, what needs to come back first? Email, a client-facing system, and payroll are common priorities — but the answer is specific to your organization.
Write down who does what
A plan that only exists in one person's head isn't a plan. Name who has authority to make decisions, who contacts vendors, and who communicates with staff and clients during an incident.
Keep a copy outside your own systems
A disaster recovery plan stored only on the network it's meant to help you recover has an obvious flaw. Keep a copy somewhere accessible even when your systems aren't.
Test it, even informally
A tabletop exercise — walking through the plan out loud once a year — reveals gaps far more reliably than leaving the document untouched until an actual incident forces the question.
A one-page plan that's actually been discussed beats a detailed plan that's never been read.