Introduction
Your IT team restores a virtual server from backup. The application starts. Users can log in. That is a meaningful recovery milestone, but leadership still needs answers: is the environment trustworthy, what happened to sensitive information, and can the business operate safely?
A backup can help replace unavailable data. It does not, by itself, establish how an attacker entered, which identities remain compromised, or whether information left the organization. Microsoft's ransomware response guidance pairs restoration with removing malicious access and verifying that the environment is no longer accessible to the attacker. Microsoft ransomware response playbook (opens in a new tab)
The practical goal is to prepare for operational recovery and an informed investigation together. The recommendations below are a leadership planning framework. They should be adapted by your IT and response teams, and they do not define the deliverables of every BreachReady engagement.
Start with business services, not a list of servers
Ask department leaders what must work first. Payroll, shipping, patient scheduling, production, and customer support have different dependencies and tolerance for disruption. “Restore everything” is not a useful order of operations when recovery capacity is limited.
For each critical service, document:
- The business owner and minimum acceptable operating capability.
- The applications, identities, network services, and vendors it depends on.
- The maximum tolerable interruption and acceptable data loss.
- A safe temporary workaround and the people who can authorize it.
- The evidence required before the business owner accepts restoration.
Then ask IT to test whether the proposed order is technically possible. Restoring an application before its authentication service, database, or required configuration is available may produce a running server and an unusable business process.
This is an organizational responsibility. NIST's current incident-response guidance integrates preparation, response, and recovery into cybersecurity risk management rather than treating incident response as an isolated technical event. NIST SP 800-61 Revision 3 (opens in a new tab)
Understand the virtual-server backup blind spots
A virtual-machine backup protects the data and configuration included in its scope. Do not assume it also captures every dependency, management system, or source of evidence surrounding that machine.
Our recommended coverage review asks separately about guest operating systems, hypervisor hosts, virtualization management, storage, identity infrastructure, backup administration, and cloud services. Each has a different role in recovery and investigation. Ask your provider to show which components are protected and which require another method.
A VMware snapshot or Hyper-V checkpoint is also not equivalent to an independent backup. Veeam explains that snapshots can support backup operations but, on their own, remain different from backups. Their usefulness depends on the underlying disks and infrastructure they reference. Veeam: Snapshots versus backups (opens in a new tab)
The executive test is straightforward: if an attacker gains control of the virtualization or backup management plane, what recoverable copy remains outside that control? “We have snapshots” is an incomplete answer. So is “the backup job succeeded” without evidence that the required service can be restored.
Separate backup protection from production access
CISA recommends offline or otherwise protected backups and regular restoration testing. Protection should address the possibility that attackers reach administrative systems, not only ordinary user accounts. CISA #StopRansomware Guide (opens in a new tab)
For planning purposes, ask your technical team to explain the failure boundaries in plain language. Which accounts can delete backups? Who can shorten retention? Can production administrators reach every recovery copy? How are recovery credentials available if normal identity services are down?
Do not treat the word “immutable” as the end of that conversation. Ask what is protected, for how long, against which administrative actions, and under whose control. Review dependencies on subscription status, encryption keys, storage capacity, and vendor access. Product capabilities and configuration determine the answer.
Document exceptions explicitly. A workload excluded because of cost or technical limitations should be visible to its business owner, along with a recovery alternative or a conscious acceptance of the gap.
Test a business outcome, not just a successful restore job
A useful exercise restores representative systems in an isolated environment and checks whether people can complete a business transaction. Choose tests that reflect your dependencies rather than an arbitrary sample of files.
For example, a finance application test might require the restored database, an authorized user, a reporting component, and a reconciled transaction. A manufacturing service may require configuration outside the virtual machine. Work with system owners to define safe tests that do not accidentally trigger real payments, customer notifications, or production activity.
Record the elapsed time, missing prerequisites, manual steps, and staff involved. Compare the measured result with leadership's recovery expectations. Include how you determine which recovery point is appropriate and how responders assess it for signs of compromise.
The output should be a short gap list with owners and dates. A test that reveals a recoverable problem is valuable; repeating a reassuring test that avoids the difficult dependencies is much less useful.
Preserve evidence outside the server you plan to rebuild
A restored server cannot tell the whole incident story. Our recommended evidence map follows the paths an attacker could use: identity, remote access, endpoints, virtualization administration, backup administration, network controls, email, and cloud management.
For each source, identify the owner, collection method, retention period, timestamp handling, and access needed during an outage. Verify that logs actually arrive at their destination and that they are protected from unauthorized changes or deletion. A configured connector with no recent events deserves investigation before an emergency.
Cloud retention needs particular attention. Microsoft documents different retention periods by log type and license. It also distinguishes Entra sign-in and audit logs from the Microsoft 365 Unified Audit Log. Expired Entra activity is not recovered simply by upgrading a license later. Microsoft Entra data retention (opens in a new tab)
Choose retention according to your investigation needs, obligations, and budget, with qualified advice where appropriate. More logging is not automatically better if nobody checks collection health or can retrieve the records when needed.
Balance evidence preservation with urgent containment
CISA's response guidance recommends isolating affected systems and preserving short-lived evidence. It also explains the tradeoff with powering down: shutdown loses volatile memory, but may be necessary when other means cannot stop spread. CISA ransomware response checklist (opens in a new tab)
Turn that principle into a prepared decision path. Identify who can authorize isolation, who coordinates evidence collection, and how responders communicate if ordinary email is compromised. Preserve what can safely be preserved without allowing an active incident to continue for the sake of a perfect evidence set.
Do not give general staff a blanket instruction to leave every machine running, reconnect infected devices, or perform memory captures themselves. Qualified responders should guide technical preservation. They should record collection times, sources, handling, and consequential containment decisions so later analysis has context.
Before wiping or rebuilding systems, coordinate with the incident lead about evidence needed for investigation. Immediate safety and containment remain priorities; the purpose of preparation is to reduce avoidable conflict between them.
Give leadership a decision structure before the incident
The incident lead needs authority, a deputy, and a reliable way to reach executives. IT needs a clear route to obtain emergency resources. Business owners need to distinguish a technical estimate from a committed service-restoration time.
Our recommended leadership checklist is:
- Establish the current facts, unknowns, and next decision time.
- Prioritize safety, essential operations, and containment.
- Coordinate qualified incident responders, counsel, and the insurer under applicable arrangements.
- Confirm notification responsibilities and who approves external statements.
- Record emergency spending, vendor approvals, and significant decisions.
- Require business validation before declaring a service recovered.
Discuss insurer contacts, reporting requirements, and any provider-approval conditions before an incident. Coverage and obligations depend on the policy and circumstances. Counsel should advise on legal duties and communications; a technical article cannot determine them for your organization.
Ask one final question during the exercise: what would prevent us from carrying out this plan if our usual administrator, email system, or office were unavailable?
Turn readiness into maintained capability
BreachReady is DFI's annual, DFI-led service for making real resilience easier to establish and maintain. DFI takes on the heavy lifting within the agreed scope, while client IT and business leaders provide access, validate dependencies, approve priorities, and carry out their assigned responsibilities.
An initial 30–60-day target is a planning goal, not a promise that every environment can be made ready on that schedule. Scope, system access, remediation dependencies, and client availability affect timing. Confirm which reviews, testing, evidence-readiness work, implementation tasks, and ongoing maintenance your engagement includes.
The measure of progress is concrete: you understand what can be recovered, have tested important dependencies, know what evidence is available, and have people ready to make decisions. Backups are essential. Readiness connects them to a business that can recover with confidence grounded in evidence.
