What should data owners, infrastructure teams, and security teams do together before a ransomware incident hits?

They should run a cross-functional review of critical data stores, rank the most likely availability threats, and agree on controls for prevention, detection, response, and recovery. The most useful next step is a joint tabletop exercise with disaster recovery testing, because it exposes how teams actually behave under pressure and reveals gaps in ownership, process, and recovery assumptions.

Why this matters before ransomware hits

A pre-incident review is not just a planning exercise. It forces the people who own data, run infrastructure, and defend the environment to agree on which stores matter most, which outage scenarios are realistic, and what “good recovery” actually means for business-critical systems.

That shared view matters because ransomware pressure usually lands on the gap between teams, not inside one team’s plan. If ownership, recovery expectations, and decision rights are unclear, the incident response becomes slower, more political, and more dependent on guesswork.

What the joint review should cover

Start with the critical data stores and map them to the systems that create, move, back up, and restore them. The review should identify where the highest availability risk sits, whether that comes from encryption, deletion, corruption, storage failure, backup compromise, or a dependency that would make recovery incomplete even if the primary platform comes back.

The same review should also rank the controls that matter most for this scenario: prevention controls that reduce exposure, detection controls that show early signs of tampering, response controls that slow spread and isolate affected systems, and recovery controls that restore trusted data in the right order. NIST Cybersecurity Framework 2.0 is a useful structure here because it keeps prevention, detection, response, and recovery in one conversation.

In practice, the review should not stop at documents. It should surface who can actually approve restoration, who can declare data trustworthy, and which dependencies must be available before a restore is considered successful. A system that restores quickly but fails integrity or business use is not a real recovery.

Why tabletop exercise and disaster recovery testing belong together

A tabletop exercise gives teams a realistic way to walk through decisions before the pressure is real, while disaster recovery testing proves whether the technical recovery path actually works. Used together, they expose both process failure and technical failure: the first shows how people behave, the second shows whether the environment can be rebuilt, validated, and returned to service.

The most valuable tests are the ones that challenge assumptions. Teams often assume backups are usable, that roles are clear, or that a restore order is obvious. A combined exercise can show the opposite, especially when the incident affects multiple data stores, shared services, or downstream applications that depend on the same storage and access paths.

For teams that want adversary context, ransomware operators commonly aim at speed, disruption, and backup recovery degradation, which is why recovery assumptions deserve the same attention as perimeter defenses. MITRE ATT&CK Enterprise Matrix is a practical reference for mapping those tactics to likely attack paths, while CISA cyber threat advisories help teams anchor the exercise in current ransomware patterns.

Risk and Threat Considerations

Ransomware planning fails when recovery is treated as a storage problem instead of an operational trust problem. If backups are untested, ownership is unclear, or restore dependencies are missing, the organisation can have data copies and still be unable to resume business safely.

Failure mechanism: Attackers or operational failures can corrupt primary data, disable systems, or undermine backup confidence, and the team may discover too late that restore order, credential access, or validation steps were never agreed.

Impact: Recovery time stretches, critical services stay offline longer, and the business may restore the wrong version of data or bring systems back before they are trustworthy.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0 provides the primary governance reference for this topic.

Framework	Control / Reference	Relevance
NIST CSF 2.0	RC.RP-01 — Recovery Plan Execution	Joint DR testing directly validates the recovery plan for critical data stores.
	ID.RA-01 — Asset Vulnerabilities and Risks Identified and Documented	The review ranks likely availability threats to critical data and dependencies.
	RC.IM-01 — Improvements are Identified from Recovery Exercises and Events	Tabletop exercises are meant to expose gaps in ownership, process, and recovery assumptions.
Recommendation — Test restore procedures for critical data stores and confirm recovery order works under pressure. Document the most likely availability threats to each critical data store and its dependencies. Capture gaps from tabletop and DR tests and turn them into tracked recovery improvements.

Practitioner Guidance

What to prioritise: Put the most business-critical data stores, their backup paths, and their restore dependencies at the top of the review. If a dataset cannot be restored in a way the business can actually use, treat that as a material recovery gap rather than a technical detail.

What to verify: During the tabletop, require named owners, named approvers for restore decisions, and evidence that backup restoration has been tested under realistic conditions. If the exercise cannot produce a credible restore sequence, it has identified a control weakness, not a paperwork issue.

Practitioner takeaway: The goal is not to predict the exact ransomware playbook, but to make sure the organisation can still make fast, trusted recovery decisions when pressure, confusion, and competing priorities arrive together.