What to Do If Your Newsroom Is Hit by Ransomware (October 2026)

If your newsroom is hit by ransomware, the first hour decides how bad the next week gets. Disconnect affected machines from the network without powering them off, open a phone line and a chat channel nobody else can reach, write down the time you discovered it, and start calling. Do not reboot, do not pay, and do not restore anything yet.

That ordering matters more in a newsroom than in most organizations, because your website and your email are also how you tell readers what happened. When those are the systems an attacker has taken, the outage and the explanation for it are the same crisis. Unpublished drafts, embargoed material, source contact files and subscriber records are sitting inside that same estate, and they are worth far more to an attacker than a ransom demand suggests.

Here is the playbook, in the order I would work it. It assumes no security team, because most newsrooms of this size do not have one. If you do have a security team or a retainer with a response provider, hand them this document and let them run steps 1 through 4 while you focus on the reader-facing decisions.

What You Need

Most of what makes a newsroom ransomware response work has to exist before the attack. None of it takes long to set up, and all of it is far cheaper than the outage it prevents.

• A named incident lead and a backup for it. One person, by name, with authority to make calls without waiting for a board meeting. Write their mobile number on paper.
• An out-of-band communication channel. A group chat on a personal-device account plus a phone tree. If your identity provider is compromised, your company email is not a safe channel, and neither is a chat room hosted on the company tenant.
• An offline copy of the runbook. This document, your network diagram, your asset list, your backup restore procedures, your insurer’s claims line and your breach counsel’s number. Printed, in a drawer or a safe, not in the shared drive that just got encrypted.
• Verified backups, including one copy the attacker cannot reach. Three copies, two media types, one off-site or offline. “Immutable” or “air-gapped” means the credentials needed to delete backups are not stored in the same place as the backups.
• An access list that includes everything vendors touch. Your web host, your CMS provider, your CDN, your email provider, your ad tech, your analytics, your payroll, your donor platform. Most newsroom intrusions arrive through a supplier relationship, not through the building.
• Outside contacts on speed dial. Breach counsel, a DFIR or incident-response provider, your cyber insurer’s breach hotline, your hosting provider’s emergency line, and the FBI Internet Crime Complaint Center. Establish the relationship now; you do not want to be cold-calling a forensics firm at 2am.

For a small outlet, treat this list as the whole plan. There is no version of this that requires a SOC, and readers do not care whether your title is CISO or managing editor when the site is down.

Step-by-Step: What to Do If Your Newsroom Is Hit by Ransomware

1. What to do if your newsroom is hit by ransomware: contain the first hour

First, confirm what you are looking at. Mass file renaming, extensions with no familiar name, a ransom note in every directory, and a desktop wallpaper demanding payment all point one way. A slow site, a plugin failure and a compromised CMS can look alarming without being encryption, and you do not want to declare an incident over a hosting outage.

Then appoint the incident lead and start a written log. Someone should be writing down every action with a timestamp, because in the recovery phase you will not remember which machine you unplugged at 14:12 or who you called first.

Disconnect affected devices from the network. Pull the ethernet cable or disable the wireless adapter, but leave the machine powered on. A restart or a hard power-off wipes volatile memory, and that memory often holds the running process, the encryption key, the attacker’s address and the credentials they used. You will not get a second chance at it.

1. Pull infected laptops and desktops off wifi and ethernet.
2. Unplug shared storage and any NAS or file server showing encrypted file names.
3. Suspend the affected identities: disable accounts, revoke sessions and tokens, force a password reset on anything with admin rights.
4. Block the compromised mail account or identity at the provider if you can still reach admin controls from a clean device.
5. Stop staff from logging into email or the CMS from home networks that may carry the infection.
6. Do not open the ransom note on a machine that is still connected to anything.

You know containment worked when new encrypted files stop appearing on machines that were never connected to the infected one. Wait a full business day before you believe it.

2. Preserve evidence and identify the entry point

Before responders arrive, capture what you can without touching anything else. Take screenshots of the ransom note on every infected machine, including the file path and the timestamp on screen. Write down the affected device names, their IP addresses, the user accounts signed in, and the time the first ransom note appeared. Photograph the screen rather than moving files.

Keep logs where you safely can: identity provider sign-in logs, firewall and VPN logs, web server access logs, cloud storage audit trails. Copy them somewhere clean, not onto the encrypted share. If a log source is inside the compromised environment, leave it and write down that it exists.

Then think about the entry point, because restoring without closing it just hands the attacker a second visit. In a newsroom the usual candidates are a phished message that looked like an editor or a source, a stolen password reused on the CMS or the identity provider, an unpatched WordPress plugin or a theme, an exposed remote access tool, or a vendor who holds a support login. The Finalsite incident of January 2022 is the cleanest reminder of that last one: one vendor compromise landed on thousands of sites, and more than forty publications, including the front page of CNN, inside 24 hours. Your provider’s bad day is your outage.

Do not reinstall, wipe, reimage or patch anything yet, even if it feels productive. It destroys the trail your insurer and any law enforcement investigation will want.

3. Protect sources, credentials, and sensitive material

This is the step generic guides skip, and in a newsroom it is the one that can cause lasting harm. Your unpublished drafts, embargoed stories, source contact details and sensitive documents are the highest-value material in the estate. Assume anything on a compromised system has been copied, not just encrypted.

• Get the identity and file-sharing material you care about off compromised systems and onto encrypted storage your organization controls.
• Move active source-protection files to a separate account that does not share a password or MFA factor with newsroom systems.
• Assume every password typed on an infected machine is known to someone. Rotate credentials for newsroom systems, email, CMS admin, social accounts, the identity provider and any remote access tool, from a clean device.
• Revoke active sessions, refresh tokens, app passwords and API keys tied to those accounts.
• Re-register or re-enrol multi-factor authentication methods, because an attacker who had the account may have added their own device.
• Move any physical notebooks and devices holding unencrypted source material to a locked location.

Tell sources what they need to know. If a journalist’s work account was compromised, that reporter’s sources should hear it from the reporter or the editor, with the facts you actually know. Truncate the story: a source who learns their contact was exposed from a leak post rather than from you has learned you lost control of it.

4. Decide whether to pay, isolate, or bring in specialists

Paying is a legal, ethical and security decision, not a technical one, and it should not be made by whoever is most tired in the room. The weight of it sits with the incident lead, the owner or publisher, legal counsel and the board where one exists.

Reasons not to pay stack up fast. There is no guarantee of a working decryption key, and law enforcement agencies and incident-response researchers report cases where payment produced nothing usable. Paying funds the next campaign, and it can trigger a repeat visit from the same group, because a newsroom that paid once is a known payer. It can create sanctions exposure, since some groups are designated, which brings an OFAC problem and a reporting obligation into a story that was supposed to be an IT outage.

Reasons it comes up anyway: no usable backup, an outage that threatens the business, a life-safety angle, or an insurer and counsel both saying the decision sits with the company. Payment gets you a negotiator involved, which is at least useful. Decide it in writing, with the reasoning and the people who agreed, because that document is what your regulator, your board and your readers will eventually ask for.

Bring in specialists when any of these are true: you cannot determine how the attacker got in, the estate includes production and cloud infrastructure you do not fully understand, data exfiltration is likely, you are considering paying, your insurer requires a forensic vendor, or legal exposure is real. A DFIR retainer is not a luxury for a five-person outlet, but an insurer and a breach counsel number are cheap and both assume you have one.

Report it. The FBI Internet Crime Complaint Center takes ransomware reports, and the FBI has repeatedly said that reporting is what makes recovery and disruption possible. CISA’s StopRansomware Guide and the NIST ransomware preparation material are free, written for organizations exactly your size, and worth reading now rather than tonight.

5. Restore operations from known-good backups

Restoring is where most newsroom incidents become a second incident. The rule that saves you: understand and close the entry point before you return to service. A restore into the same infrastructure, with the same weakness, invites the attacker back during the recovery window, and crews have observed redeployment in exactly that gap.

Verify backups before you trust them. Check that a restore test has actually been run in the last 90 days, that the copy you need is outside the reach of any admin credentials stored in the environment, and that directory services and identity infrastructure are inside the backup scope. Find your last known good restore point, then rebuild forward from it rather than restoring to the moment just before the encryption started.

Rebuild in a clean, isolated environment: fresh infrastructure, patched, with multi-factor authentication on every admin path and no direct path back to the old estate. Rotate every credential from that environment before anything goes live, and confirm that there is no leftover persistence, scheduled task, remote access tool or rogue account before you reconnect anything.

For a publication, sequence by what readers need first. In most cases that order is the public site, then email, then the CMS, then the internal tools: assignment tracker, asset library, ad and subscription systems. Have the last known good copy of anything time-critical pulled manually in case the archive is also affected.

Keep a second, less comfortable continuity plan for the weeks when the archive cannot be trusted. RTV Noord, a regional broadcaster in the Netherlands, went down with suspected Rhysida ransomware in November 2025 during a wave of media-targeted attacks. A media organization can be the target, not the accidental neighbor of one.

6. Communicate responsibly and review the response

Internal updates first, on a fixed cadence: hourly early on, then as the picture changes. Everyone gets the same facts, the same time, on the same channel, including the parts nobody likes. Staff guessing is worse than staff knowing something bad.

Then the reader-facing call, and it is genuinely a decision. The case for telling readers: your site is their information channel, subscriber data may be involved, and regulators in many jurisdictions expect notification. The case for waiting: you may not yet know what was taken, and a vague disclosure followed by a correction is harder to walk back than a delayed one. Most outlets land on a short holding statement within 24 hours that states what is known, what is not, what services are down and when the next update will come, then updates on that schedule whether or not there is news.

Do not publish stolen source material or draft files to prove the attack happened. It confirms what the attacker got and hands them a distribution channel.

Check notification duties with counsel. If personal data was involved, breach notification laws in your jurisdictions may set hard deadlines, and the analysis is about what was exfiltrated and who it affects, not about reputational damage.

Then write it all down while people still remember. Who decided what, when, and on what evidence; what was known at each moment; what the recovery cost in time and money. Hold a blameless postmortem, update the runbook, and store the new version offline where it cannot be encrypted with everything else.

Common Mistakes

Powering off or restarting infected machines. It feels like containment and it destroys the volatile evidence you will want. Disconnect instead.

Paying because a countdown is running. A deadline is a pressure tactic, not a technical constraint. Slow the decision down and get counsel involved.

Restoring from backup immediately. If you have not closed the entry point, you rebuild the same weakness the attacker used and invite a return visit.

Trusting the backups because they exist. Backups destroyed by the attacker or unusable because of retention settings are the most common mid-incident discovery in this whole scenario. Test restores before the attack, not during it.

Using credentials typed on a compromised machine. Every one of them should be treated as public. Rotate from a clean device, revoke sessions and tokens, and re-check MFA enrolment.

Using the compromised systems to tell people what is going on. Your site and email are the outage. Set up an out-of-band channel before you need one.

Publishing unverified details of your own attack. Encryption without exfiltration is now the less common case. Do not claim no data was taken until someone has verified it, and do not name a threat actor without attributable sourcing.

Letting the whole incident sit with one vendor. Your hosting provider controls the platform but may not have seen your specific compromise, and a clean platform does not mean clean credentials.

Frequently Asked Questions

Conclusion: Start With Containment

If your newsroom is hit by ransomware, three things come first: disconnect affected devices without powering them off, move to a communication channel the attacker cannot reach, and write down the time you discovered it. Everything after that, the evidence, the ransom decision, the restore and the disclosure, depends on those three being done properly in the first hour.

Then treat your sources, your drafts and your backup credentials as part of the incident rather than an afterthought, and record the recovery decision in writing while memory is fresh. Spend an afternoon now printing this, listing your outside contacts and building a one-page fallback page. That hour is the cheapest part of a newsroom ransomware response plan, and the only one you get to do calmly.