IT disaster recovery plan: priorities, people and tests
Build an IT recovery plan around important systems, clear owners and tested backups. Set realistic recovery targets and record the gaps your business must fix.
An IT disaster recovery plan records how your business will restore important systems and data after disruption. Start with the work that needs to resume first, the people responsible and a safe test of the recovery method. Build the plan from that evidence, then extend it to the remaining systems.
Separate business continuity from technical recovery
Business continuity covers how work continues during an interruption: staff arrangements, customer communication, suppliers and temporary processes. IT recovery addresses the systems and information needed to support that work. A small team can keep both in one manageable document, provided responsibilities and actions are clear.
For each important activity, record its dependencies. Invoicing might need an accounts application, identity service, internet connection and access to records. Restoring only the application may leave the team unable to work.
Set recovery targets before choosing equipment
Recovery time objective (RTO) is the target time for restoring a system after disruption. Recovery point objective (RPO) describes the point in time to which data must be recovered, expressing the acceptable loss of recent data. Set both from the business impact, then check whether your arrangements can meet them. These concepts are explained in NIST’s contingency planning guide.
For example, a business might decide it can tolerate losing no more than one hour of bookings. A nightly backup alone would not meet that requirement. The backup schedule does not determine what loss the business can accept. Likewise, having a recent copy does not prove how quickly a replacement system can be made usable.
Write down targets, the current recovery method and the evidence from testing. Where they do not match, record a decision: improve the arrangement, change the business process or explicitly accept the gap. Do not label an untested target a guarantee.
Build a practical recovery record
- Systems: application, device or cloud service, business owner, supplier and dependencies.
- People: recovery lead, technical contacts, deputies and who authorises changes.
- Priorities: which business activities resume first and the agreed RTO/RPO for each supporting system.
- Instructions: where approved recovery procedures are held and how an authorised person can access them.
- Communication: how staff and customers receive updates when normal email is unavailable.
- Evidence: last relevant test, result, unresolved issues, owner and next review date.
Keep a protected offline copy of essential instructions and contact routes. Do not put passwords, recovery codes or private keys in the general plan or a printed contact sheet. Document how authorised people reach the approved credential store, with appropriate emergency access arrangements.
Check what the backup actually protects
File backups and system images serve different recovery needs; either can be unsuitable if coverage, frequency or recovery process does not meet the business requirement. Check application consistency, retention, restore permissions and dependencies. Test Microsoft 365 and Google Workspace workloads separately from device backups.
Copies need protection from compromise of the live environment. CISA’s ransomware guidance includes securing backups and checking that they remain usable. During a security incident, follow the incident lead’s containment and recovery decisions; restoring data before the environment is safe can expose it again.
Choose tests that answer different questions
A file restore checks a selected copy. A tabletop exercise checks people and decisions without changing production. A system recovery rehearsal checks more dependencies and can carry operational risk. Plan disruptive testing with the system owner, a safe environment, recovery steps and a rollback route.
Agree a schedule based on business impact, system changes and contractual requirements. Record elapsed time and the age of the recovered data, then compare them with the relevant targets. Open the recovered material and check usability; a completed job alone is not the result.
Use the free editable backup restore log to record a test, its owner and follow-up actions. Start with a critical system and broaden coverage over time. A successful sample is not proof of complete disaster recovery.
Keep the plan current
Review affected steps when suppliers, accounts, devices or business processes change, and after every exercise or incident. Give unresolved issues a named owner and due date. Keep old results as evidence, while making current instructions easy to identify.
Our cloud backup coverage guide helps with the data-protection part of this exercise. The broader plan should address your organisation’s legal, contractual and reporting responsibilities with the appropriate advisers.
Get help with the recovery work
hostme.ie provides business backup and recovery support. We agree systems, testing and responsibilities before work begins. New recovery arrangements, migrations and incident response beyond triage and containment are separately scoped; they are not automatically included in routine support.
Managed support has an initial 12-month term, then rolls monthly with 30 days’ written notice. Read the support scope and terms. There is no blanket promise of a particular restore time or zero data loss.
