Almost every ransomware product on the market is sold against one problem. There are two, and they fail in opposite directions.
Problem one is availability. Your files are encrypted and the business cannot run. This is the problem everyone plans for, and it is genuinely solvable — good backups solve it.
Problem two is disclosure. Your data has already left the building, and the attacker will publish it whether or not you decrypt anything. Backups do not touch this problem. Nothing does, after the fact.
An organisation that has solved only the first problem will restore in a day, congratulate itself, and then watch its customer list appear on a leak site three weeks later. That is not a hypothetical failure mode. It is the standard one.
Why the second problem became the main one
Encryption-only ransomware was a straightforward extortion: pay, get the key, move on. Backups broke that business model, so the model changed. CISA’s #StopRansomware Guide describes the result — “double extortion”, where attackers both encrypt files and steal data, then threaten public release to coerce payment even where decryption has already happened. The guide also notes that some actors now skip the encryption entirely and use the threat of disclosure alone.
Think about what that means for your controls. If the adversary never encrypts anything, every detection built around mass file modification is silent. There is no ransom note on the screen. The first indication is an email naming files you recognise.
What each problem actually requires
Availability: backups that survive the attacker
The failure is almost never “we had no backups”. It is “the backups were reachable from the network the attacker owned”. Ransomware operators look for backups specifically and destroy them before triggering encryption, because a restorable victim does not pay.
CISA’s guidance is direct: maintain offline, encrypted backups of critical data and test their integrity regularly. Keep them disconnected, because anything mounted is a target. Hold golden images so systems can be rebuilt rather than cleaned. Immutable storage is worth considering, with the caveat that it brings its own misconfiguration risk.
The test that matters is not “do backups exist” but “restore a representative system from cold storage, end to end, and time it”. Most organisations have never done this and discover during an incident that the restore takes four days, that a dependency was never backed up, or that nobody holds the credentials needed to start.
Disclosure: the only defence is before
Once data is out, the options are legal and reputational, not technical. The controls that matter are all preventive and all boring.
- Know what you hold and where. You cannot protect data you have not inventoried, and you cannot assess an incident’s severity without knowing what was in the share the attacker reached.
- Delete what you do not need. The cheapest reduction in breach severity is holding less. Most organisations retain years of data with no business reason and no legal obligation.
- Segment. A flat network means one compromised workstation reaches everything. Segmentation is what turns a catastrophe into an incident.
- Watch egress, not just ingress. Large outbound transfers to unfamiliar destinations, at unusual hours, are the signal. Most monitoring is pointed at what comes in.
- Constrain administrative accounts. Exfiltration at scale needs broad read access. Standing domain-wide admin rights are what provide it.
The doors they come through
CISA identifies six primary initial access vectors: internet-facing vulnerabilities and misconfigurations, compromised credentials, phishing, precursor malware infections, advanced social engineering, and compromise through third parties and managed service providers.
That last one deserves attention because it is the one organisations do not control directly. Your IT provider’s remote management tool is, from an attacker’s perspective, a pre-installed route into every one of their clients at once. If you outsource IT, your ransomware exposure includes their security posture, and almost nobody audits it.
Note also what is absent from that list: exotic zero-days. The common routes are an unpatched edge device, a credential that should have been rotated, and a person who clicked something. Sophistication is in the operation, not the entry.
The first hour
CISA’s response checklist runs in a fixed order: detection and analysis, then reporting and notification, then containment and eradication, then recovery and post-incident activity. Two points inside it are routinely got wrong under pressure.
Isolate, do not wipe. The instinct is to rebuild fast. Rebuilding destroys the evidence needed to answer the only question that matters afterwards — what did they take? Without that, you cannot scope the notification obligation, and you end up either over-notifying or making statements you cannot support.
Collect forensics before eradication. Memory, logs and disk images have a short shelf life. Logs roll. Cloud audit trails expire. An organisation that skips this in hour one is guessing about disclosure for the rest of the incident.
The honest assessment
Ask two questions of whatever you have in place. First: if everything encrypts tonight, how long until we are trading again, and who has actually timed that? Second: if nothing encrypts but forty gigabytes left the network last Tuesday, would we know, and could we say what was in it?
Most organisations have a defensible answer to the first and no answer at all to the second. That gap is where the real loss sits.
Honeybadger Solutions works both halves — preparation and the question of what actually left. Determining scope after an incident is a forensic exercise, covered under digital forensics, and where an intrusion needs to be traced rather than merely cleaned up, that falls under cyber investigations. The human vector that opens most of these doors is addressed through security awareness training.
The negotiation question, and why it is not really about money
Organisations facing an extortion demand tend to frame the decision as a cost comparison: the demand against the cost of rebuilding. That framing misses most of what matters.
Payment does not reliably restore operations. Decryption tools supplied by attackers are frequently slow, partial or defective, and restoring from a working backup is often faster than decrypting even when the key works. Payment also does not undo disclosure — data already copied out stays copied out, and the only thing purchased is a promise not to publish it from a party whose business model is breaking promises selectively.
There are also legal dimensions. Payments to entities or individuals under sanctions carry regulatory exposure regardless of intent, which is why a payment decision belongs to counsel and the board rather than to whoever is closest to the keyboard at 2am. Insurers typically require notification before any payment, and paying without that notification can jeopardise coverage.
The decision, in practice, comes down to whether you have a recovery path. Organisations with tested, isolated backups rarely pay. Organisations without them frequently do, and discover that paying was the beginning of the problem rather than the end.
What “tested backup” actually means
Almost every organisation says it has backups. Very few have restore capability, and the gap between the two is where ransomware does its damage.
A backup that meets the standard has four properties. It is isolated — not reachable from the production network with production credentials, because modern ransomware operators specifically hunt and destroy backups before triggering encryption. It is immutable or offline for a defined retention window, so it cannot be altered even by an administrator account. It is complete — covering not only file shares but databases, virtual machine configurations, cloud-hosted data, and the systems needed to rebuild identity and networking. And it is tested by an actual restore, performed recently, with the elapsed time recorded.
That last point deserves emphasis. The number your board needs is not “we back up nightly” but “we restored the primary application from backup in March and it took eleven hours.” Without a measured restore time, your recovery plan is a hypothesis.
Legal and regulatory obligations start earlier than people expect
The disclosure problem is not only reputational. Depending on the data involved, notification obligations may attach and they run on clocks that begin before you have finished understanding what happened.
Arizona has a data breach notification statute with its own definitions and timelines. Healthcare data brings HIPAA obligations. Payment card data brings contractual obligations to card brands and acquirers. Organisations with customers in other states face those states’ laws, and organisations with European data face a regime with a much shorter clock. Publicly traded companies face disclosure requirements of their own.
This is why counsel is engaged in the first hours rather than after the technical work concludes. It is also why forensic work is often directed by counsel — it structures the investigation so that legal privilege is preserved where it applies, and it ensures the technical findings answer the questions the notification analysis will need.
What insurers now expect, and what that means for you
Cyber insurance applications have become technical audits, and the answers are warranties. Attesting to a control you do not have can void coverage at the moment you need it.
The recurring list is short and consistent: multifactor authentication on email, remote access and privileged accounts; endpoint detection and response deployed across the whole estate rather than part of it; offline or immutable backups with a documented restore test; privileged accounts separated from daily-use accounts; and a written incident response plan.
Two traps are worth naming. Sub-limits mean a policy’s headline figure may not apply to ransomware, extortion payments or business interruption. And business interruption coverage usually carries a waiting period — a seventy-two hour waiting period against a four-day outage covers almost nothing. Read the ransomware endorsement specifically.
The controls that change the probability, in priority order
- Multifactor authentication everywhere it can be applied, starting with email and remote access. This single control removes the most common initial access path.
- Eliminate internet-exposed remote access. Forwarded remote desktop ports and unpatched VPN appliances are the two doors that appear most often in incident reports.
- Isolated, tested backups, as described above. This does not prevent the incident; it determines whether it is survivable.
- Endpoint detection and response with someone actually watching the alerts. Tooling with no monitoring is a licence fee.
- Network segmentation, so that an infected workstation cannot reach the file server, the backup server or the camera network.
- Privileged access separation. Administrators should not browse email from an account that can encrypt the domain.
- Patching on a cadence, prioritising internet-facing systems.
Tabletop exercises are the cheapest thing on this page
Spend two hours with the leadership team walking a scenario: it is Friday evening, the file servers are encrypted, the phone system runs on the same infrastructure, and a message has appeared claiming twelve gigabytes were copied out. Who is called first? Who can authorise engaging an outside firm? Where is the insurance policy number when the network is down? How do you contact staff when email is unavailable? Who speaks to customers, and what do they say before the facts are known?
Every organisation that does this finds at least three broken assumptions, and finding them on a Tuesday afternoon costs nothing.
Arizona context and data
- Arizona Cybercrime Index — Reported cybercrime, fraud and loss figures for Arizona, kept current as new data is published.
Browse by topic
Security guard services · Private investigations · Cybersecurity · Digital forensics · Financial fraud investigation · Executive protection · All articles