A newly written disaster recovery plan for a cloud-hosted ERP system has never been exercised, and several of the people it names have not yet read it. What should the organization do first to begin validating the plan?
Select an answer to reveal the explanation.
Short Explanation
You wouldn't run a fire drill on the first day before anyone knows where the exits are. Start with a tabletop: walk the people through the plan, find the gaps on paper, then graduate to live tests. Jumping straight to a failover is the trap; it tests the plan and the people at once, and both will fail.
Full Explanation
Exercise programs build maturity in stages. When a plan has never been exercised and its participants do not yet know their roles, the first step is a discussion-based exercise such as a tabletop or structured walkthrough. Participants step through a realistic scenario, confirm who does what, and expose gaps such as missing contacts, unclear decision authority or procedures that depend on unavailable systems, all at no operational risk. Findings are corrected before more demanding tests. A full interruption test at this stage would put production at risk while the plan and people are untested, and any failure would be expensive and hard to diagnose. A parallel test is a sound later step that proves the recovery site processes workloads, but it assumes the team can already execute the procedures, which is not yet true. Asking the provider to certify the plan misreads shared responsibility: the provider can describe its own resilience features and assurance reports, but it cannot validate the customer's plan, roles or recovery procedures. Exam caveat: on the exam, the least disruptive test that meets the objective comes first, and tests escalate as confidence grows. Operational check: record tabletop attendance, findings and owners, update the plan, and schedule the next, more technical test against a date.