The data recovery blog by Ontrack

What does a real cyber preparedness checklist look like?

Written by Ontrack | Nov 9, 2026, 1:00:03 PM

 

By Shaun Stockman, Senior Director of Business Development, Americas at Ontrack.

I been on many calls, talking with insurers and incident response teams about what separates a fast recovery from an expensive one.

I get some version of this question a lot. What actually makes an organization ready for a ransomware attack? The honest answer is four things, working together: a written incident response plan you've tested, backups you've actually verified you can restore, access controls that assume someone will get in anyway, and a cyber insurance policy you've read before you need it. I've watched IT teams discover mid-attack that their backups sat on the same network the ransomware had just encrypted. That's a preparedness failure, not a technology one.]

Key takeaways

    • A written incident response plan only helps if it's been tested. Run a tabletop exercise. Don't just file the document.
    • Backups need to follow the 3-2-1-1-0 rule (3 copies, 2 media types, 1 offline, 1 offsite, 0 errors) and get test-restored on a real schedule.
    • Cyber insurers in 2026 want proof of controls like MFA, EDR, and network segmentation. A checked box on an application isn't enough anymore.
    • Decide your organization's stance on paying a ransom before an attack happens, with legal counsel involved, not during the chaos of one.

Do you actually have an incident response plan, or just a document?

Most organizations I talk to have something called an incident response plan. Fewer have tested it, and that gap matters more than people think. Unit 42's 2026 Global Incident Response Report found the fastest quarter of intrusions reached data exfiltration in just 72 minutes in 2025, down from 285 minutes the year before. Attackers move fast, so your response plan has to move faster than they do. That means deciding roles, outside contacts, and first containment steps ahead of time, not figuring them out on the fly.

Spin.AI's research found 69% of businesses believed they were well prepared for ransomware before an attack hit. Only 22% actually recovered within 24 hours when one did. That gap between confidence and reality is usually a testing problem. A plan sitting in a shared drive doesn't tell you whether your team knows who to call first, whether that's legal counsel, a data recovery partner, your insurer, or law enforcement. Our own guide to dealing with a ransomware attack walks through the sequence we see work in practice, starting with isolating infected devices before anything else.

Run a tabletop exercise at least once a year. Insurers increasingly expect it as a baseline control anyway.

Are your backups actually recoverable, or just present?

A backup that runs on schedule isn't the same as a backup you can restore. I've seen ransomware wipe out live systems and the backup tapes in the same event, because both were reachable from the same infected network. The 3-2-1-1-0 rule exists for this reason: three copies of your data, on two different types of media, with one copy offline and one offsite, verified to have zero errors.

Sophos's State of Ransomware 2025 report found 53% of organizations fully recovered within a week, up from 35% in 2024 and just 22% in 2023. That improvement tracks closely with better backup hygiene and testing, not luck. Test-restore your backups on a real schedule, ideally quarterly, and confirm the restored data is clean before you trust it. If your organization does end up recovering encrypted or damaged data after an incident, our examples of ransomware data recovery show how varied that work can get, down to rebuilding RAID groups by hand from drives that were sitting in a lab.

Have you locked down access before someone else does?

Insurers now treat a specific set of controls as table stakes for coverage in 2026. The baseline list includes:

    • Phishing-resistant multi-factor authentication on email, remote access, and privileged accounts
    • Endpoint detection and response (EDR or MDR) with continuous monitoring
    • Privileged access management
    • Timely patching, with no unsupported end-of-life systems still running
    • Network segmentation

None of these are new ideas. What's changed is enforcement. Carriers are running their own attack-surface scans now and asking for proof, like screenshots and restore-test logs, instead of taking your word for it.

I think segmentation gets underweighted the most. If one compromised laptop can reach your entire file share, the blast radius of a single phishing email becomes your whole environment. Segmenting critical systems, especially backup infrastructure, from the general network is one of the cheaper controls to put in place and one of the most effective at limiting damage once someone does get in.

I'd also add patch management to that list of underweighted controls. It's not glamorous work, and it's easy to let a handful of end-of-life systems linger because replacing them is expensive or disruptive. But those unsupported systems are usually the ones an attacker finds first, and insurers know it. If you can't retire a legacy system right away, at least isolate it behind its own segment until you can.

Do you know your stance on paying, and does your insurer?

Nobody wants to have this conversation before an attack, but that's exactly when it has to happen. Most guidance on ransomware advises against paying.] By some estimates, only about 3 in 5 organizations that pay actually regain access to their data, and roughly 18% of victims who paid still had sensitive data exposed on the dark web anyway. There's no guarantee attached to the payment.

At the same time, some organizations weigh the ransom against the cost of permanent data loss, regulatory fines, or a halted business, and land somewhere different. That's a legitimate call. But it should be a decided policy, not an in-the-moment negotiation. Our post on whether organizations should pay the ransom breaks down what typically drives that decision either way. Whatever you land on, loop in your insurer and legal counsel now so everyone's aligned before an incident forces the question.

Practical takeaway: If you do one thing this quarter, run a tabletop exercise and test-restore a backup from an isolated environment while you're at it. That single exercise tends to surface the gaps nobody catches on paper, like a contact list that's out of date or a backup that's been quietly failing. Identify your data recovery partner and breach counsel now, while you have time to vet them, not while you're under pressure to pick whoever answers the phone first.

FAQ

What is the 3-2-1-1-0 backup rule?

It means keeping three copies of your data, on two different types of media, with one copy stored offline and one stored offsite, and confirming those backups have zero errors through regular test restores.

Should organizations pay the ransom if they're attacked?

Most cybersecurity experts and federal agencies advise against it, since payment doesn't guarantee data recovery and can fund further attacks. Some organizations still choose to pay when the alternative is permanent data loss, but that decision should be made as policy ahead of time, with legal counsel, not during the attack itself.

How often should an incident response plan be tested?

At least once a year through a tabletop exercise. Insurers increasingly require evidence of this testing as part of their baseline controls for coverage.

What do cyber insurers require for coverage in 2026?

Phishing-resistant MFA, EDR or MDR with continuous monitoring, tested and immutable or offline backups, a dated and exercised incident response plan, timely patching, privileged access management, and network segmentation, along with proof those controls are actually enforced.

Preparedness is a habit, not a one-time project, one you keep testing until it holds up under real pressure. I'd rather see an organization spend an afternoon on a tabletop exercise than spend a week explaining to their board why the backups didn't work. If you're building out your incident response plan and want a second opinion on where the recovery gaps might be, that's a conversation I'm glad to have.