Protect · Playbooks · At work

Our files are locked, or there's a ransom note

Last updated 2026-10-14 · Written with AI assistance, reviewed by a person

This is the one everybody dreads, so let's be clear about two things up front. Most organizations do recover, usually from backups, sometimes with help. And the first hour matters most: cut off the affected machines, protect the backups, then call for help. Don't start restoring files into a network the attacker may still be inside.

Use this when files suddenly won't open, file names change, a ransom note appears, or your security software reports ransomware.

If medical care, machinery or anything safety-critical is involved, switch to its downtime or emergency procedure first. Involve the person responsible before changing those systems.

Who does what. Anyone can take the first steps below. Network, account, backup plus restore decisions belong to whoever runs IT, with the owner. Follow your own response plan, plus current vendor instructions, where they differ from ours.

Do this now

For whoever spots it:

1. Stop using the affected computer. Don't keep trying to open files, plug in a USB backup or follow the ransom note's instructions.
2. Disconnect it from the network. Unplug its network cable, then turn off Wi-Fi. A docking station may have its own cable. Closing the browser or the VPN isn't enough.
3. Leave it switched on once it's disconnected. Don't reboot it or run cleanup tools. If you can't disconnect it and the damage might spread, shut it down: you lose some evidence, but you may limit the harm. [1]
4. Call IT plus the owner, from a trusted phone. Say where you saw it, when it started, which computer or shared folder is involved. Use a number you know, never one in the note.
5. Photograph the note if it's safe. Note the time plus the computer's name. Don't click its links, scan its QR code or contact the attackers.

Files on a shared drive? Tell IT the drive or folder name. Unplugging your laptop doesn't stop encryption happening on the file server, or from another computer.

For the owner

Declare an incident, then name one person to coordinate. Call your IT provider, plus your cyber insurer's incident line if you have one, and ask for ransomware response support. If your provider can't contain it, bring in a qualified incident response firm quickly. Many insurers want you to use their approved firms, so ask them first, but don't let that delay containment.

Use phones, or a channel the responder sets up. Company email or chat may be visible to the attacker. [1]

Only one IT person? Their job right now is containment, protecting backups, getting help. Don't also expect them to investigate every machine, rebuild servers and answer every customer call.

Is it real? A pop-up in a browser, or an emailed demand on its own, doesn't prove anything was encrypted. Have IT check the files with your security alerts, without opening suspicious links. A believable claim of stolen data still needs investigating, even if every file opens. Don't shut the whole business down over an unverified email.

Stop it spreading

Whoever runs IT, or your responder:

CISA recommends isolating quickly, then isolating at the network switch when several systems are affected. Protect the critical services that still work while you scope it. [1]

Cutting the internet alone may not help: ransomware can still move across your own network. And a computer that looks fine isn't automatically safe to run recovery from.

Work from a trusted admin computer. Restrict compromised accounts, revoke sessions, close the remote access routes the attacker used. If your directory (Active Directory or Entra ID) or admin accounts are involved, plan credential resets with a specialist: resetting passwords from a machine the attacker controls just hands them the new ones. On-premises Active Directory usually needs a planned reset of the KRBTGT account, twice, done by someone who's done it before. [2] [3]

Is your IT provider's remote management tool involved? Contain its access, then work with an independently checked responder. Don't assume the same remote support channel is safe for recovery. Write down which tools plus communication routes are still trusted.

Protect the backups

Whoever runs IT, with your backup provider:

• Keep offline backups offline. Never plug a backup drive into an affected computer to check it.
• Shield reachable backup systems plus their admin accounts from compromised computers or passwords. Coordinate with your backup provider before isolating them.
• Keep every restore point. Ask the provider whether retention rules, deletion, replication or syncing could wipe out good versions, then have them lock things down.
• List what you have: which copies exist, where, who can reach them, when a restore was last actually tested. "Last successful backup job" isn't the same thing.
• Check local plus cloud options. A cloud copy isn't automatically safe from deletion, encryption or a compromised account. [4] [5]

Don't erase backup catalogs, rotate media or start a big cleanup now. Changes made to "get backups working again" can destroy what you need.

Cloud syncing isn't a backup. Confirm that usable earlier versions, or independent backups, really exist. Protect them before any large restore. [3] [4]

Keep the evidence, without slowing containment

Whoever runs IT, or your responder: keep the ransom note, examples of affected file names, security alerts, logs, a timeline. Let a responder take forensic images or memory captures before anything is wiped or rebuilt. Never ask an untrained colleague to handle the malware. [1]

Store evidence outside the affected network, with restricted access. Record where each item came from, plus when. Your responder should hash forensic copies, record handovers, then work on copies. Don't hold up containment for perfect evidence. Keep encrypted files where you can: they may be decryptable later.

Don't upload confidential documents, system images or the ransom note to public analysis sites. Ask your responder how to share samples safely.

Not now, please:

• Rebooting every machine to see if it goes away.
• Deleting the note, or mass-renaming encrypted files.
• Downloading a "ransomware remover" from a search result.
• Plugging backup drives into infected computers.
• Starting a company-wide restore before you've agreed a clean recovery plan.

Work out what's affected

The incident lead asks. IT investigates. The owner sets business priorities.

The encryption is when you found out, not when it started. Attackers are often inside for days or weeks first. Recovery has to close their access, not just remove the encryption. [2]

A ransom note's claims aren't proof, and the absence of a data theft alert isn't proof nothing was taken. Record what's confirmed, what's possible, what you can't see. Restoring files doesn't settle the data exposure question.

Keep essential work going

The owner: pick a few essential things that can run safely while systems are down: taking customer calls, tracking urgent orders, recording sales by hand. Decide who approves each workaround, where the records live, how they'll be entered later.

Don't move customer data into personal email, unapproved file sharing or unknown USB drives to get around the outage. Agree approved alternatives with the incident lead.

Give staff one contact, with a set time for updates. Tell them which services they may use, plus which must stay disconnected. Tell customers what affects them, without guessing at recovery times or promising their data is safe.

Recover in an order that fits both the business plus the technology. A restored accounting app is useless if its database, or the sign-in service it needs, is still down or untrusted. [2] [6]

The ransom demand, and who to tell

The owner, with your responder and qualified advisers.

Nobody else negotiates. No employee should reply, send a test payment or share information with the attackers. Keep the demand plus any deadline, but leave decisions with the incident lead.

The FBI doesn't support paying. Paying doesn't guarantee your files come back, or that stolen data won't be published. Report it at ic3.gov, or to your local FBI field office. You can also report to CISA. Keep containing while you report. [7]

If payment is being considered at all, involve qualified lawyers, your insurer plus incident specialists before committing to anything. US sanctions rules may make some payments illegal, including for anyone who helps make them. An intermediary or an insurance policy doesn't make a payment lawful. [8]

Name someone to work out who must be told: customers, partners, regulators, others. That depends on your organization, the data, the circumstances. Getting systems running again doesn't settle it. Some sectors, including critical infrastructure, may face mandatory reporting deadlines: ask your adviser early.

Check outside contacts independently. Someone offering guaranteed decryption may be running a second scam.

Legitimate ways to get files back

Backups plus earlier versions

Have your responder check candidate backups in an isolated environment first. A backup from before the encryption can still contain the attacker's tools, or their changes. Inspect it, then test it, before restoring into the real network. [4]

For cloud services, ask the provider what version history, deleted-item recovery or point-in-time restore your subscription includes. Confirm what a rollback would overwrite. Keep the originals before you experiment.

A trusted decryptor

Ask your responder, or law enforcement, whether a legitimate decryptor exists for this particular ransomware. No More Ransom publishes free tools, but many variants have no working public fix. [9]

Use only verified tools from trusted sources. Test on copies, in a clean isolated environment, keeping the encrypted originals. Follow the tool's instructions exactly. Decrypting files doesn't remove the attacker.

No backup, no decryptor

Work out what can be rebuilt from cloud services, suppliers, customer records, exports or paper. Keep the encrypted data safe in case a fix appears later. Be honest with the owner about likely losses. Never promise recovery based on an attacker's "proof" that they can decrypt.

Restore in safe stages

IT or your responder leads. The owner approves the priorities, plus the remaining risk.

1. A trusted base. Clean installation media, admin access the attacker doesn't control.
2. Close the way in. Fix the weakness they used. Remove their access, including in sign-in plus remote management systems. Write down anything still open.
3. Rebuild or clean each system. Follow the recovery plan. A clean antivirus scan alone isn't enough to trust a compromised server.
4. Restore a little validated data. Confirm apps open it, with their dependencies working.
5. Test with a real user. Open an order, run a report, process a test transaction.
6. Reconnect gradually, watching closely. Expand only once checks pass. Turn syncing back on deliberately, so old or damaged copies don't overwrite recovered work. [3] [6]

If encryption, strange access or unexplained changes come back, isolate again, then stop expanding.

For each restored service, record how much recent work is missing, how long it was down, what's still outstanding, plus the business owner's sign-off. Confirm a new backup works, with a test restore, before calling recovery complete. If you never found how they got in, your responder should set compensating controls, then the owner should accept the remaining risk in writing. Reopening is a recorded decision, not a claim of certainty.

Recovery checklist

• Containment actions, with their results, are written down.
• Backups plus evidence are protected.
• Known attacker access is closed, with remaining doubts recorded.
• Recovered systems have protection, monitoring, working backups.
• Restored files plus key business processes have been tested.
• Data exposure plus notification work has an owner.
• Manual records plus lost work have a plan to catch up.
• Staff know which services are approved, and how to report problems.
• Follow-ups have owners, due dates, a person who signs off.

Track technical recovery, business recovery, the data exposure investigation as separate pieces of work: one can finish long before the others. Agree post-recovery monitoring with your responder. No number of quiet days proves an attacker is gone.

A simple incident record

Never put passwords, recovery keys or active tokens in the record. Start a short notification log early too: who might need telling, by when, under which rule, with your adviser deciding which rules apply.

Before the next one

Choose improvements that match what failed:

• Backups an attacker can't delete, with backup admin kept separate from everyday accounts. Test a full restore of a real business service, not just one file. [5]
• Close the way in: the unpatched system, the exposed remote access, the reused password.
• Cut unnecessary admin rights, then add phishing-resistant sign-in for the admins left.
• Fill the monitoring gaps that let this run unnoticed.
• Keep a paper copy of this playbook, your emergency contacts, plus your critical systems' recovery order. A plan saved only on the encrypted file server won't help next time.
• Practice once a year: who calls whom, who can authorize pulling the plug.

Sources

Checked October 14, 2026. Reporting routes are US-focused. Recovery features, insurance cover plus legal duties vary. This playbook follows NIST SP 800-61 Rev. 3 for incident response, with the scenario guidance below. It's a careful, documentation-based guide. An experienced ransomware responder hasn't reviewed it yet, and it hasn't been exercised in a live environment.

1. CISA: StopRansomware Guide
2. Microsoft Incident Response: Ransomware approach
3. Microsoft Defender: Responding to ransomware attacks
4. UK NCSC: Mitigating malware and ransomware attacks
5. UK NCSC: Ransomware-resistant backups
6. UK NCSC: Recovering from a highly disruptive cyber attack
7. FBI: Ransomware
8. US Treasury OFAC: Ransomware payment sanctions advisory
9. No More Ransom: Questions and answers

Related playbooks

• Someone at work clicked a phishing link
• A work email account was hacked
• A work laptop is lost or stolen