Shaun Stockman, Senior Director of Business Development, Americas, Ontrack.
I’ve been on many calls, talking to insurance carriers and DFIR teams about what happens in the first hour after a ransomware attack. This is the question I get asked more than any other.
Call your incident response team first, then bring in data recovery
If your organization gets hit, call your incident response firm before you touch a backup, a decryption tool, or a reboot button. IR handles containment and evidence preservation. Data recovery handles getting the encrypted or damaged data back once the systems are stable enough to work on. They're not competing services. They run in sequence, and sometimes in parallel once the scene is secured. I've seen companies skip the IR step and go straight to "let's just restore from backup," and it usually costs them more than the hour they thought they saved.
Key takeaways
- Incident response comes first because it preserves the evidence your insurer, your legal counsel, and possibly law enforcement will need. Data recovery can destroy that evidence if it starts too early.
- Most cyber insurance policies require you to notify the carrier and use an approved vendor panel before engaging anyone. Calling your own IT guy first can put those hours outside coverage.
- Data recovery firms and IR firms aren't interchangeable. IR investigates and contains the incident, while data recovery rebuilds what's left afterward.
- The two teams need to talk to each other directly, not through you relaying messages back and forth. That's where recovery timelines get shorter.
Why does the order matter so much?
I think the order matters because forensic evidence has a shelf life measured in hours, not days. The moment someone reboots a server or restores from a backup, volatile memory data disappears. That data can show how the attacker got in and whether they're still inside. If your incident response firm can't answer those questions, you're recovering data into an environment that might get hit again next week.
Insurers have caught on to this. Most policies now bundle a panel of approved IR vendors that activate the moment you call in a claim, and they expect that call before any recovery work starts. I've heard from a few clients that they didn't realize their vendor choice was already made for them by their policy. That's a bad thing to learn mid-incident.
I also think there's a psychological piece to this that doesn't get talked about enough. When production is down and people are watching, the instinct is to do something visible right away, and restoring from a backup feels like progress. Calling a forensics team and waiting for them to image systems feels like standing still. It doesn't look like it, but it's the step that protects everything that comes after, including your claim.] It's the step that protects everything that comes after, including your claim.
What does an incident response team actually do that data recovery doesn't?
An IR team's job is to figure out what happened, stop it from continuing, and preserve what's needed for a claim or a legal case. That means isolating affected systems, capturing memory and logs before anything is touched, identifying the ransomware variant, and often negotiating with counsel on next steps. We wrote about the early decision points in dealing with a ransomware attack, and the short version is that the first few actions you take determine how much of your environment is still recoverable.
Data recovery is a narrower, more technical discipline. It's about getting bytes back off damaged, encrypted, or corrupted media, whether that's a RAID array that partially encrypted, a virtual machine that got hit mid-backup, or a NAS device the attacker tried to wipe. The people doing that work aren't investigators. They're engineers who understand storage architecture at a level most IT teams never touch.
Can data recovery start before incident response finishes?
Sometimes, yes, but it depends on what's been secured. Once IR has imaged the affected systems and confirmed the attacker is out, data recovery can start working from those images in parallel with the ongoing investigation. What you don't want is recovery starting on live, still-compromised systems, because you risk overwriting the very data you're trying to save.
I'd also say, and this is something people don't always want to hear, that recovery success depends heavily on what happened before either team showed up. If someone already tried a free decryption tool off a forum, or rebooted the server a few times trying to "fix it," the odds get worse. We've covered some of the mistakes that shrink recovery options in recovering data from ransomware attacks, and honestly, most of them come from good intentions and bad timing.
For DFIR and CIRT firms reading this, I'd add one thing from the recovery side. The engineers doing the actual recovery work do better when they get access to your case notes early, not just the drive images. Knowing which ransomware family you're dealing with, what the negotiation status is, and whether a decryptor exists changes the recovery approach. A recovery team working blind, without that context, ends up repeating diagnostic steps your IR team already ran.
Does paying the ransom change any of this?
Not as much as people assume. Paying doesn't guarantee a working decryption key, and even when it works, it doesn't undo the damage to files that were already corrupted during encryption or during a rushed attempt at recovery. IR teams that negotiate ransom payments still hand the resulting keys to a data recovery team to validate and apply, because decryption tools fail on some percentage of files almost every time. We go through the tradeoffs in more detail in ransomware: should we pay the ransom, and I'd say the short answer is that paying might get you a decryption key, but it doesn't replace the recovery work still ahead of you.]
What should you actually do with this
Before anything happens, know who your IR retainer is and confirm it against your cyber policy's approved panel. Do this before anything happens, not after. If you're an IT professional reading this without a retainer in place, that's the one thing I'd fix this week. When an incident does happen, call IR first, don't touch backups or run decryption tools until they say it's safe, and ask them to loop in a data recovery partner as soon as systems are imaged rather than waiting until the investigation fully closes. That single change, looping recovery in early instead of at the end, is where I've seen the most time saved.
FAQ
Do I need separate contracts with an IR firm and a data recovery firm?
Usually, yes. Some IR firms have recovery capability in-house, but many rely on outside partners for the deep technical recovery work. Check your incident response retainer to see whether recovery is included or needs to be arranged separately.
Will my cyber insurance cover both incident response and data recovery costs?
Most policies cover both, but check whether your policy requires a pre-approved vendor for each. Using a non-approved vendor, even a good one, can create coverage disputes later.
How long does data recovery take after an IR team clears the systems?
It depends on the ransomware variant, the storage type, and how much damage happened before recovery began. Sophos's 2025 State of Ransomware report found organizations with intact, tested backups recovered within a week nearly half the time, versus roughly a quarter of the time when backups were compromised.
Should I call data recovery directly if I'm confident it's just an encryption issue?
I'd still call IR first, even if you're confident. You may be right about the technical issue and still miss evidence the attacker left behind, and that gap can matter later even if recovery itself goes fine.
Ransomware isn't slowing down, and the average downtime companies report, close to 24 days, tells me most organizations are still figuring this order out during the incident instead of before it. I'd rather see that conversation happen at renewal time, over a coffee, than at 2am during a live attack.
United States | English
Locations
Search
Back to listing
