Recovery Testing - Question Guide
Last updated: May 8, 2026
If you're feeling lost on what information to include in your recovery test, use this as your guide for which questions to ask yourself. The questions are grouped by topic: Disaster Recovery and Incident Response.
Disaster Recovery Testing
Where is your data currently stored?
Do you have a staging or development environment we can run the test in, or would we be touching your live production system?
You never want to run a recovery test directly on the live system clients are using - if something goes wrong, it could actually take down your service. A staging or dev environment is a safe copy you can test without any real-world impact. If you don't have one, skip to the tabletop option
Walk through how your backups work - how often do you back up, where does the backup go, and who's responsible for making sure it happens?
Have you ever actually restored from a backup before, or has this only existed on paper?
If you triggered a restore right now, how long would you expect it to take?
This is called the RTO (Recovery Time Objective). It means: if something goes wrong, how quickly can you be back up and running? For compliance, the client needs to know their target (e.g. "back online within 4 hours") and whether they actually hit it. Make a note of what they say.
How far back does your most recent backup go? If you had to restore right now, how much data could potentially be lost?
This is the RPO (Recovery Point Objective). It means: if the system crashes, how old is the most recent copy of your data? If backups run daily, you could lose up to 24 hours of data. You should know and determine what's acceptable for your business.
If you are not doing a tabletop exercise, and are conducting an actual recovery test, share your screen and walk through the restore process. Even just triggering it on a dev environment would be perfect.
Who has access to trigger a restore - and is there an approval step before it can happen?
⚠ If you don't have a staging environment or can't do a live restore: That's okay - you can do a tabletop exercise instead. This means you walk through the process verbally, showing data wherever relevant.
Incident Response Testing
Do you have a written incident response plan? An incident response plan covers things like:
What counts as an "incident" — not every bug is an incident. The plan defines what's serious enough to trigger a formal response (e.g. customer data exposed, service fully down, etc.)
Who's in charge — one person owns the incident. Everyone knows who that is.
How it gets logged — in a ticket, a Slack channel, a tool like Jira. There has to be a record.
What the steps are — detect → contain → fix → communicate → close out
How customers get told — if their service is affected, there's a process for letting them know
The post-mortem — after it's over, someone writes up what happened and what to do differently next time
If you don't have a document in place currently, use the following questions as a guide to create an internal report.
When an incident happens, how do you log it and track it? Do you have a ticketing system, or is it handled in your internal communication channels?
Auditors typically want to see a paper trail of incidents recorded somewhere, even if it is informal.
Who's responsible for owning an incident when it happens? Do you have anyone on-call?
Can you walk through what happens from the moment something goes wrong - from detecting the problem all the way through to marking it resolved?
Be as detailed as possible here.
What does your post-mortem process look like after incidents?
Do you create a writeup of what happened, why, and what you'd do differently?
How/when do you communicate to your customers when an incident affects their service?