Short · Incident response · 4 min read

Should we pay the ransom, and who gets to decide?

Paying a ransom is a business decision, not a technical one, and it belongs with the board or whoever holds that level of authority in your organisation, acting on advice from counsel, the incident lead, and the insurer. The FBI's position is that it doesn't support paying, because payment funds further crime and doesn't guarantee you get your data back (Federal Bureau of Investigation, n.d.). The U.S. Treasury adds that paying a sanctioned party can bring civil penalties whether or not you knew who you were paying (Office of Foreign Assets Control, 2021). Most organisations that pay do so because recovery from backups turned out to be impossible or too slow to survive. So the real question is usually decided months earlier, by whether your backups work.

Who holds the decision

Three groups have a legitimate say, and they're not the same people.

The board, or the owner. Payment is a material use of company funds with legal, reputational, and possibly criminal consequences. It's the kind of decision directors are there for. If your bylaws or delegation of authority don't say who can approve an emergency payment of this kind, that's a gap to fix before you need it. Many organisations now pre-decide the conditions under which they would and wouldn't pay, so the incident call is about facts, not principles.

Counsel. Before any payment, someone has to check the sanctions position. OFAC's advisory says a licence application for a ransomware payment will be reviewed with a presumption of denial, and that a strong compliance programme, cyber hygiene, and prompt, full reporting to law enforcement are mitigating factors if a payment later turns out to involve a sanctioned party (Office of Foreign Assets Control, 2021). Counsel also handles the notification duties, which don't go away because you paid.

The insurer. If you expect the policy to fund the payment, the carrier will have conditions: approved negotiators, sanctions screening, documentation. Paying without them and then claiming is a good way to pay twice.

The incident lead and the technical team advise on one thing: whether recovery without paying is possible, and how long it would take. They shouldn't carry the decision, and they shouldn't be blamed for it.

What has to be true before paying is even on the table

  • Backups have been tested and have failed. Not "we think they're encrypted too." Someone has tried to restore the critical systems and reported the result. NIST's recovery guidance treats restoration from known-good state as the core of recovery, and the plan is worth little if it hasn't been exercised (Bartock et al., 2016).
  • Law enforcement has been contacted. CISA's response checklist points victims to CISA, the FBI, or the Secret Service, and specifically to ask about available decryptors before deciding anything (Cybersecurity and Infrastructure Security Agency, n.d.). For some strains, free decryption exists.
  • The data-theft question is answered separately. Most groups now steal data before encrypting. Paying for a decryptor doesn't un-steal it, and paying for a promise of deletion buys exactly that: a promise.
  • The sanctions screen is done. If the group is on a list, the decision is already made for you.
  • The business impact is quantified. Days of downtime, revenue at risk, safety consequences, contractual penalties. A number, not a feeling.

Why "we'll never pay" isn't quite a policy either

I understand the principle, and I'd push every organisation toward it. But a blanket refusal written on a quiet day meets reality when a hospital's systems are down or a manufacturer is losing a day's output per hour. The useful policy says what conditions would have to hold before payment was considered, who would decide, and what has to be done first. If those conditions are strict enough and your recovery works, you'll never pay. That's a better outcome than a policy you abandon under pressure.

The reporting clocks that follow a payment

Public companies may need to consider whether the incident is material and file within four business days of that determination (U.S. Securities and Exchange Commission, 2023). And under CIRCIA, once the final rule is in effect, covered critical infrastructure entities will have to report a ransom payment to CISA within 24 hours of making it; as of this writing the final rule has been sent for White House review and isn't yet in force (Cybersecurity and Infrastructure Security Agency, 2024). Counsel should be tracking that.

What I'd do next

Write down, this month, who in your organisation could authorise a ransom payment, what would have to be true first, and who checks the sanctions position. Then test a restore of your three most important systems and time it. If you want help running that conversation with your board before it's real, request a briefing. I've written about the first board conversation after a breach in The First Board Briefing After a Breach.

References