Prepare for your worst day with three habits: keep offline encrypted backups and prove you can restore them, keep a printed and offline copy of your incident response plan, and rehearse the plan in a tabletop exercise. None of this is exotic. It is the unglamorous work that decides how long recovery takes.
This guide uses CISA's ransomware guidance and NIST's incident response publication. We make no forecasts about when anything will happen.
Why offline?
CISA's ransomware guide explains that many ransomware variants try to find and delete or encrypt reachable backups. A backup on the same network, or attached with the same credentials, can be lost along with the data it protects. Its core recommendation is to maintain offline, encrypted backups of critical data.
It also notes some trade offs. A multi-cloud approach can mean one vendor's compromise does not affect every copy. Immutable cloud storage is an option, but CISA warns it can conflict with some compliance rules and cause costly misconfigurations. So think it through before turning it on.
What else should you keep?
The guide lists items that make a rebuild possible: golden images of critical systems, infrastructure as code templates under version control with offline copies, offline copies of software and license materials, and backup hardware, since older hardware can complicate a rebuild.
For software teams, add the source of everything you deploy, your build configuration, and your dependency inventory. If your registry or build service is down, you need to know what was in production and be able to rebuild it. Pinned versions and internal copies of critical packages help here.
Have you tested a restore?
A backup you have never restored is a hope. CISA says to test backup procedures regularly and to test availability and integrity in a disaster recovery scenario, including checking that restored systems can run on current hardware and platforms.
Time the test. Write down how long it took to get one critical service back from nothing. That number is what you will actually have on a bad day.
What goes in the response plan?
CISA says to create, maintain and regularly exercise a basic incident response plan and an associated communications plan. Keep a hard copy and an offline version. If your plan lives in the wiki that is encrypted, nobody can read it.
The plan should be approved in writing by the CEO or equivalent, and the chain of command should understand it. Include notification procedures, holding statement templates, and agreed levels of detail for internal and public sharing.
NIST published SP 800-61 Revision 3 in April 2025. It supersedes the 2012 revision and ties incident response to the Cybersecurity Framework 2.0, with the goal of better preparation, fewer and less damaging incidents, and more efficient detection, response and recovery.
How do you run a tabletop?
A tabletop is a discussion based exercise. Gather the people who would act: engineering, operations, legal, communications and an executive. Give them a realistic scenario and walk through decisions, one stage at a time. Who declares an incident? Who can disconnect a system? Who speaks to customers? Where is the plan, and does anyone have it printed?
Do not aim to pass. Aim to find gaps and write them down with owners and dates. CISA's ransomware guide lists no cost tabletop exercise packages as a resource.
What to do
- Identify the five systems you could not run without.
- Keep offline, encrypted backups of their data and configuration.
- Keep golden images, infrastructure code and deployment source offline too.
- Restore one system from backup and time it.
- Print the incident response and communications plans and store them offline.
- Get written approval of the plan from leadership.
- Run a tabletop twice a year and track the fixes.
Quick check
Are cloud backups enough?
Only if an attacker with your credentials cannot delete them. CISA recommends offline, encrypted backups and notes immutable storage has its own trade offs.
Who should attend a tabletop?
Anyone who would make a decision in a real incident: technical staff, legal, communications and an executive who can approve actions.
Sources
Last reviewed: 18 October 2026.
