Start with the business interruption
Ask what happens if the practice system, file service, or identity platform is unavailable. Who cannot work? What can continue manually? Which systems depend on the affected service? This conversation sets the recovery priorities. A list of backed-up servers alone will not show the operational sequence needed to get the business working again.
Define two different objectives
A recovery point objective describes the amount of data loss the business is prepared to tolerate, expressed as time. A recovery time objective describes the target time to restore an agreed level of operation. Treat both as design objectives to validate, not promises inferred from a product brochure. Confirm the workload, dependencies, available resources, and assumptions behind them.
Protect copies from the same incident
A backup can be affected by the same account compromise, location failure, or administrative mistake as the original system. Review separation of access, retention, offline or immutable options, and who can alter or delete copies. CISA recommends protecting backups and testing backup procedures; the implementation should match your environment and recovery needs.
Test something a person can use
A restore test should go beyond a successful job status. Agree on a safe test environment, restore the required system or data, and verify an actual business task with the owner. Record elapsed time, missing dependencies, permissions, and any manual steps. Do not experiment on a production clinical or business system without an approved plan.
Make recovery an owned process
Keep a current runbook with decision owners, contact paths, recovery order, and the location of protected documentation. Schedule reviews after major application or infrastructure changes. The useful output is a repeatable process with evidence of what was tested, when it was tested, and what still needs improvement.