A disaster recovery plan is one of the easiest documents in a business to write and one of the hardest to make true, so an audit of it is largely a search for evidence that it was ever exercised. The checklist has four parts. What the organisation says it needs, in terms of how fast systems must come back and how much data it can afford to lose. What the recovery actually depends on. What has been tested and what the test found. And whether the plan reflects the organisation as it is today rather than as it was when the plan was written.
Objectives that somebody in the business actually agreed
Recovery time and recovery point objectives should come from the business rather than from what the technology currently achieves. The audit test is whether a named person outside the technology function agreed them, and whether they are consistent with contractual commitments to customers. Objectives written by the team that will be measured against them tend to describe current capability, which makes them unfalsifiable: the plan can never fail to meet a target set to what it already does.
Dependencies, including the ones outside the building
For each critical system, what does its recovery depend on: other systems, network, identity and authentication, licences, encryption keys, third-party services, and the specific people who know how. Two dependencies are missed almost universally. Identity, because everything else needs it and it is assumed to be there, and key or credential recovery, because the credentials needed to restore are often stored in the system being restored. Both are cheap to find on paper and catastrophic to find during an incident.
Test evidence, which is the whole audit
The plan is worth what the last test proved. Ask for the date, the scope, who took part, what the objectives were, whether they were met, what went wrong and what changed afterwards. A test that met every objective and produced no lessons is usually a walkthrough being described as a test. The strongest evidence is a restoration performed to a point in time with a measured duration, because it converts the recovery time objective from an aspiration into a measurement.
Currency: does the plan describe this organisation
Check the system inventory in the plan against the systems that exist, the contact list against the current staff, and the supplier arrangements against current contracts. Plans decay quietly, and the decay is invisible until an incident. A quick test that finds most of it is to pick three names from the call tree and check they still work here, and to pick one system added in the last year and look for it in the plan. If neither is current, the plan's age is the finding rather than any particular gap in it.
Questions people ask about disaster recovery audit checklist
How often should a disaster recovery plan be tested?
At a frequency justified by risk and stated in the plan, and after significant change. What auditors reject is a plan whose stated test frequency is not being met, which is more common than no schedule at all.
Does a cloud provider's resilience cover this?
It covers their infrastructure, not your configuration, your data restoration or your ability to operate. The audit question is what you would do if your data were corrupted or your access were lost, which no provider resilience answers.
Is disaster recovery the same as business continuity?
Disaster recovery is the technology restoration part. Business continuity is the wider question of how the organisation keeps operating, including people, premises and suppliers. An audit of one should say which it is covering.
What is the most common finding?
Untested plans, followed by dependency gaps around identity and credentials. Both are found in an afternoon on paper, which is why they are worth looking for before an auditor arrives.