Verification is the difference between hoping a system works and knowing it does. This question set provides a structured protocol for confirming that a recovered system is truly operational, not just file-present.
The Verification Gap
Teams verify what is easy to measure: files present, services started, ports listening. They skip what is hard to measure but actually matters: can a user complete a transaction? Does the database return correct results? Are downstream systems receiving data? The gap between easy and hard verification is where silent failures survive.
How to Use This Question Set
Work through these questions in order after file restore is complete. Each question must be answered with evidence, not assertion. “Yes” is not an answer; “Yes, here is the proof” is. Any question that cannot be answered with evidence blocks advancement to the next stage.
Verification Question Categories
Questions are organized by verification layer. Each layer builds on the previous one. A system that fails at any layer is not operational, regardless of whether higher layers pass.
Priority
What returns first and why. Without a defined restore sequence, teams attempt parallel restorations that fail when upstream dependencies are missing.
Are all required services running and reporting healthy?
Are system resources (CPU, memory, disk) within normal operating ranges?
Are system logs free of critical errors during the past 15 minutes?
Dependencies
Every restored system depends on other systems, credentials, network paths, and storage locations that may not exist in the recovery environment.
Can the system resolve and connect to all required database endpoints?
Can the system reach all required external APIs and services?
Can the system access all required file shares and storage paths?
Assumptions
Teams carry silent assumptions about what will be available during recovery. Testing validates or disproves these assumptions before they cause failures.
Do test queries return expected results from all database connections?
Are cross-system data references consistent (no orphaned records)?
Can the system read and write to all required storage locations?
Ownership
Recovery requires decisions at every stage. Without pre-assigned ownership, decisions stall or conflict.
Can a synthetic user authenticate and receive a valid session?
Can a test transaction be submitted, processed, and verified?
Do background jobs and scheduled tasks execute without errors?
Verification
“Files restored” is not “service operational.” Verification must test at the application level, not just the file level.
Can an external client reach the service through the expected path?
Do monitoring systems report the service as healthy?
Are error rates and response times within acceptable thresholds?
Question Set Output
The completed question set produces an evidence-backed verification record that confirms the system is operational at every layer. Any unanswered question becomes a blocker that must be resolved before the service is declared operational.
Evidence is observable, reproducible, and documented. Examples: a screenshot of a successful test transaction, a log entry showing a successful authentication, a monitoring dashboard showing healthy status. Verbal confirmation is not evidence.
Use read-only queries for data verification, synthetic transactions that mimic user behavior without affecting real users, and monitoring data that is already being collected. Avoid stress tests or high-volume transactions during the initial verification window.
A failed verification question stops the recovery progression. The system is not declared operational. The failure is documented, investigated, and resolved before re-running the verification. Never skip a failed verification question to expedite service restoration.