- › A large share of extortion now involves no encryption, which makes backups and restore plans irrelevant to the decision.
- › Systems keep running, so nothing forces the organization into incident mode and the clock starts quietly.
- › Paying buys a promise of deletion from somebody who has already demonstrated what their word is worth.
- › The disclosure obligation is triggered by the copy, not by the publication, and it does not wait for the negotiation.
- › Decide who owns this scenario before it happens, because it does not arrive through the door your incident plan watches.
Most of what a security program builds against ransomware is about getting back. Backups, restore ordering, recovery time targets, tabletop exercises that begin with a screen full of ransom text and a business unit offline.
My colleague Chris wrote about how much sits unexamined inside the phrase “restore from backup,” and that piece is right about everything it covers. All of it assumes the same opening scene.
Now take the encryption away. The data was copied and nothing was locked, every system is running normally, and no alert fired that anybody understood at the time. The first indication is a message, sometimes sent to a board member’s personal address rather than to a security inbox, describing what was taken and what happens on a date.
Your backups are perfect, and they are completely beside the point. Nothing in the recovery plan touches any part of what happens next.
Why This Is a Different Event
The recovery playbook answers a question nobody is asking. There is nothing to restore, no outage to manage, no system to rebuild. The technical work is forensic instead of operational, and the actual decisions are legal and reputational.
That sounds as though it should make the event easier to handle. In practice it makes it considerably harder, for three reasons worth separating, because the absence of an outage removes the thing that normally organizes everybody.
Nothing forces you into incident mode. An encryption event announces itself. Operations stop, people cannot work, and the organization mobilizes because it has no alternative. A copy leaves no trace anybody notices, and the first days after the message are spent arguing about whether the claim is even real while the sender’s timeline runs.
The decision is not recoverable. A bad restore can be redone. A decision to pay, or not to pay, cannot be revisited once the deadline passes. You get one attempt at a judgment with incomplete information about what was actually taken.
You cannot verify the central claim. The attacker says they hold your data. They will provide a sample. The sample proves they have something and proves nothing about the rest, and the difference between a partial and a complete copy is the difference between two very different disclosures.
The Question Everyone Asks First
The first question in the room is always whether to pay, and it usually arrives within about ninety seconds of the message being read aloud. It is the right question and it is rarely the one that decides how this goes.
I want to be careful answering it, because the honest version contains something people do not want to hear and something they do. What payment buys in an encryption event is a decryption key, which is a testable artifact. It either works or it does not, and you find out quickly.
What payment buys in a data extortion event is a promise to delete. There is no artifact, no test, and no way to verify performance now or ever. You are purchasing an assurance from somebody whose entire position rests on having already taken your data without permission, and the only evidence you will ever have that they kept their word is the absence of a future event you would not be able to attribute anyway.
None of that is a moral argument. It is an observation about the nature of the thing being sold.
The reason the question is genuinely hard is that the alternative has real costs, and people who say paying is never justified are usually not the ones who will explain to a patient population why their records are on a leak site. Both paths are bad. Only one of them involves a transaction that cannot be verified.
Whatever you decide, the decision should be made by people who agreed on the criteria before the message arrived, and the decision itself is usually not the part that determines the outcome.
What Actually Determines the Outcome
The clock started before you knew
The disclosure obligation attaches to the unauthorized acquisition, not to the publication. The attacker’s deadline and your regulatory deadline are separate clocks, and the second one has been running since the copy happened.
A negotiation that takes three weeks does not pause anything. I wrote recently about the materiality determination that starts the four-day disclosure clock, and this is the scenario where that determination gets made under the most pressure and the least information, because the facts you need are held by the person threatening you.
Waiting for certainty is itself a decision
Organizations in this position tend to wait, because more information is coming and each day promises a clearer picture. The picture rarely gets clearer. What arrives instead is another message with a shortened deadline.
Set a date at the start for when you will decide with whatever you have. A decision made on incomplete facts at a time you chose reads very differently afterward from the same decision made at the last possible moment.
The notification population is the real number
Everything expensive about this event scales with how many people have to be told. That number comes from forensics establishing what was accessible, which takes longer than anybody expects and is frequently the constraint on every other decision.
Start that work on day one, in parallel with everything else, rather than after the negotiation resolves. The organizations that handle this badly are almost always the ones that sequenced it.
Who says what, to whom, and when
Customers, staff, regulators, partners, and press each need something different, and the versions have to be consistent because they will be compared. This is ordinary crisis communications work and it is invariably done under time pressure by people improvising, because nobody wrote it down in advance for a scenario nobody rehearsed.
What the Sample Actually Tells You
The attacker will send a sample, and how your team reads it in the first hour shapes everything after. This is the most commonly mishandled artifact in the whole event.
A sample proves possession of what is in the sample. It says nothing about volume, nothing about what else was reachable, and nothing about whether a second party already has a copy. Attackers select samples to maximize alarm, which means the most sensitive record they hold arrives first and creates an impression of depth that may or may not be accurate.
The useful work is comparing the sample against your own systems to establish where it came from. A record that could only have been pulled from one database narrows the investigation enormously. A record that exists in four places tells you almost nothing and should not be allowed to anchor anybody’s estimate.
Do that comparison before anybody characterizes the scope out loud, internally or externally, because the first number spoken in a crisis has a way of becoming the number everybody works from.
What to Do Before It Happens
Three things, none of which requires budget, and all of which are considerably easier in a quarter when nothing is happening than in the week when something is.
Run the tabletop with no encryption in it. Take your existing ransomware exercise and remove the outage. Everything still works. You have a message and a sample. Now run it. The exercise will expose that half your playbook does not apply and that nobody is sure who owns the decision, which is the finding.
Name the decision-maker for this specific scenario. It is frequently not the person who owns the encryption scenario, because these questions are legal and reputational where those were operational. Write the name down, and write down who deputizes for them.
Know what leaving would cost. Before any of this happens, have a rough answer to what your most sensitive dataset appearing publicly would mean, in regulatory exposure, contractual breach, and customer impact. An organization that has thought about that for an hour in a calm quarter negotiates from a different position than one working it out during the call.
The Part Worth Saying Plainly
The category has shifted because the attackers noticed something we should have noticed first. Encryption is expensive to build, noisy, and increasingly survivable for any organization with functioning backups. Copying data is quiet, cheap, and defeats every recovery control on the market.
We got better at the recoverable version, so the market moved to the version that cannot be recovered from. Our defenses did not fail here so much as succeed narrowly, well enough to make the workaround obvious to anybody paying attention.
If your ransomware planning still assumes the day begins with systems going down, the scenario you are prepared for is the one the people attacking you have largely stopped running.
Jeff Welch is CEO of Grab The Axe.
A PhD candidate in Health Psychology and former Corrections Officer, Jeff founded GTA to dismantle passive security models. He focuses on the 'Human Zero-Day', mitigating executive burnout and decision fatigue before they become security breaches.
View Author Page →
