It’s 6:12 a.m. on a Tuesday. Your operations lead can’t print pick tickets. Accounting can’t invoice. Nobody can open shared files. The helpdesk is getting slammed, and your MSP is on the phone saying the words nobody wants to hear:

“We think it’s ransomware.”

Ten minutes later, a ransom note appears with a timer. It demands payment, threatens to leak data, and points to a “support chat” for negotiations.

Here’s the uncomfortable truth: the most critical decisions in the next few hours are not technical. They’re governance decisions. And if you haven’t decided who decides ahead of time, the pressure will determine for you.

So let’s ask the question directly:

Who makes the “we won’t pay” call at your company?
And just as important: what conditions would force that answer to change?

This post lays out a practical way to define decision rights, set “no-pay” criteria tied to sanctions/legal risk and recovery capability, and connect ransomware response to business resilience—not panic.

Table of Contents
2
3

Two plain-English definitions you can actually use

Minimum Viable Operations (MVO)

Minimum Viable Operations is the smallest set of business functions you must restore to keep the company alive for the next 24–72 hours.
Not “all systems back.” Not “perfect.” Just enough to keep revenue moving, customers served, and risk contained.

Examples:

  • Create and ship orders (even if slower)
  • Send invoices and receive payments
  • Access customer contact info
  • Communicate internally and externally using known-safe channels

Minimum Viable Resilience (MVR)

Minimum Viable Resilience is your ability to survive an incident without resorting to desperate measures.
It’s the combination of people, plans, and recoverability that lets you operate through disruption and restore systems on your terms.

If MVO is “what must work,” MVR is “how we keep going when it doesn’t.”

That distinction matters because ransomware negotiations tend to happen when resilience is weak: no clean restores, unclear priorities, and no agreed decision-making structure.

Why negotiations are governance (even if IT is doing the work)

IT and your MSP will be deep in the technical response: isolating systems, collecting evidence, coordinating restores, and validating integrity. That’s necessary work.

But the decision to pay—or not pay—has implications that go beyond technology:

  • Legal and sanctions risk (including the possibility that the threat actor is tied to a sanctioned entity)
  • Regulatory exposure depends on the data involved
  • Financial risk (cost of downtime vs. uncertain outcomes)
  • Ethical and brand impact
  • Safety and continuity for customers, patients, or critical services

Those are executive-level considerations. Paying (or refusing) is a business decision that should be made by a defined group with authority—supported by IT facts, legal guidance, and operational priorities.

The goal isn’t to “be tough.” The goal is to avoid making a permanent, high-stakes decision in the middle of chaos.

(Micro-style and clarity principles in this post follow internal writing guidance .)

Predefine decision rights: who’s in the room, who owns the call

When a ransom demand hits, you want a small decision group with clear roles. A simple model:

Decision Owner (final call): CEO/President (or another named executive)
Required inputs: Legal counsel, Finance, IT/MSP incident lead, Operations lead, and (if applicable) HR/Comms

Why this structure works:

  • The CEO has the authority to accept enterprise risk
  • Legal evaluates sanctions/regulatory exposure (this is not DIY territory)
  • IT/MSP provides evidence on recoverability and scope
  • Ops translates technical downtime into business impact
  • Finance quantifies cash flow impact and decision constraints
  • Comms ensures customers/staff hear a consistent message

Important: This doesn’t mean everyone votes. It means the decision owner listens to the required inputs and makes the call in accordance with a pre-agreed policy.

Predefined “no-pay” criteria: your guardrails under pressure

A “no-pay” stance is easiest to hold when it’s based on objective criteria—not emotion. Here are practical criteria many organizations adopt (adapt to your environment with counsel):

1) Sanctions / prohibited-party risk is unknown or high

If you cannot reasonably rule out that the payment would go to a sanctioned entity, you may be stepping into severe risk. This is one of the biggest reasons negotiation cannot be treated as an IT-only action.

Policy example:
“We will not authorize payment if legal counsel cannot clear sanctions/prohibited-party risk.”

2) You have verified recovery capability within your tolerance

If you can restore systems from clean backups and meet your minimum viable operations within an acceptable window, the “need” to pay drops dramatically.

Policy example:
“We will not pay if we can restore MVO within X hours and full operations within Y days.”

3) The attacker’s claims aren’t verifiable

Threat actors may claim they have exfiltrated data or can decrypt everything, but proof is often lacking. Paying does not guarantee:

  • A working decryptor
  • No reinfection
  • Data deletion
  • No future targeting

Policy example:
“We will not pay based solely on claims. Decisions must be based on evidence and counsel guidance.”

4) The demand conflicts with fiduciary or governance constraints

Some boards and owners simply decide: we don’t fund criminals. That is a legitimate governance stance—if it’s made in advance and paired with recovery investment.

Policy example:
“We do not pay ransoms as a matter of policy, and we fund resilience accordingly.”

5) Payment would meaningfully increase future targeting risk

If you operate in an industry or region where “payer lists” circulate, payments can increase the likelihood of repeat attacks. This isn’t fearmongering—it’s a practical risk factor.

Policy example:
“We treat payment as a last resort because it may increase future likelihood of attack.”

Notice what’s missing: bravado. “No-pay” isn’t a slogan. It’s a decision backed by recoverability and governance.

A short vignette: what it looked like for a typical customer

A 70-person services firm got hit overnight. File shares and several endpoints were encrypted. The attackers demanded payment within 48 hours and threatened to leak data.

The MSP did three things fast:

  1. Contained spread and preserved evidence
  2. Verified the last known-good backups and started a restore plan
  3. Produced a plain-English status update: “Here’s what’s impacted, here’s what we know, here’s what we can restore, here’s the timeline risk.”

Meanwhile, the customer’s leadership team did something even more critical: they followed the decision rights they had already agreed on.

  • The CEO was the decision owner
  • Legal counsel evaluated sanctions and notification implications
  • Ops identified the minimum viable operations: invoicing and customer scheduling
  • Finance estimated the cash impact per day of downtime
  • IT/MSP confirmed restore capability for critical functions within 24–36 hours

The result: they didn’t pay. Not because they “got lucky,” but because they had enough resilience to avoid a desperate choice—and a governance process that prevented decision-by-panic.

Framework: Minimum Viable Resilience you can run before an incident

Identify critical business functions (not just systems)

Start with functions, not servers.

Ask:

  • How do we make money this week?
  • What must happen daily to avoid cascading damage?
  • What do customers notice first?
  • What breaks compliance or contracts fastest?

Then map each function to:

  • People (who perform it)
  • Dependencies (apps, data, devices, vendors)
  • Workarounds (manual process, alternate tools)

Output: a one-page “MVO map” your leadership team can understand in five minutes.

Set realistic RTO/RPO targets

Two terms that matter when the pressure is on:

  • RTO (Recovery Time Objective): how fast something must be back
  • RPO (Recovery Point Objective): how much data you can afford to lose (time-based)

Make them realistic by anchoring them to business functions:

  • “We need invoicing back within 24 hours” (RTO)
  • “We can only lose 4 hours of order data” (RPO)

If you haven’t defined these, your ransomware negotiation becomes a substitute for planning—and that’s an expensive way to “set requirements.”

Layered backup + recovery (SaaS + endpoints + servers)

Resilience depends on clean, testable restores across the places your business actually runs:

  • SaaS data (email, files, collaboration): retention isn’t the same as backup
  • Endpoints (laptops/desktops): they’re often ground zero
  • Servers/VMs (on-prem or cloud): core apps and shared data

Layering means:

  • Multiple restore options (not one fragile path)
  • Separation (so the attacker can’t delete backups easily)
  • Credentials protected (MFA and least privilege)
  • Clear restore order tied to MVO

If your only plan is “rebuild everything,” negotiations start to look like a shortcut. Layered recovery takes that shortcut off the table.

Incident response basics (roles, comms, decision tree)

Keep it simple and executable:

Roles

  • Incident Commander (often MSP + internal IT lead)
  • Decision Owner (executive)
  • Legal point of contact
  • Operations lead
  • Communications owner

Comms

  • Prewritten internal update template
  • Customer-facing holding statement (not over-sharing)
  • A non-corporate channel if email is down (predefined)

Decision tree

  • Can we contain?
  • Do we have clean restores?
  • Can we meet MVO in time?
  • What’s the legal/sanctions posture?
  • What’s the business impact curve by day?

This is where “who decides” becomes real. If you don’t have a decision tree, the loudest voice wins.

Test and prove (tabletops + restore tests)

Two tests matter:

  1. Tabletop exercises (leadership + IT/MSP)
    Run the scenario: ransomware note arrives, what happens in the first 2 hours? Who calls whom? What do we say to staff? Who has authority?
  2. Restore tests (technical proof)
    Don’t just verify backups exist. Prove you can restore:
  • The right data
  • In the right order
  • Within the target time
  • Without reinfecting

If you can’t prove recovery, your “no-pay” policy is a wish.

Common mistakes we see

  • Treating ransom payment as an IT decision instead of a governance decision
  • No predefined decision owner—so the decision gets made by fatigue
  • Assuming SaaS retention equals backup (and learning the hard way)
  • Not knowing your real RTO/RPO until after the incident
  • Backups that can’t be restored quickly (or cleanly) under pressure
  • No communication plan, leading to rumor-driven chaos
  • No tabletop practice (TTX)—so the first “drill” is the real event

Copy/paste: Ransomware negotiation governance checklist

Decision Rights

[  ] Decision Owner named (role + backup person)

[  ] Required inputs defined: Legal, Finance, Ops, IT/MSP

[  ] MSP/IT has the authority to contain/isolate immediately (no approvals needed)

No-Pay Criteria (examples—validate with counsel)

[  ] If sanctions/prohibited-party risk cannot be cleared → do not pay

[  ] If MVO can be restored within ___ hours → do not pay

[  ] If attacker claims aren’t verifiable → do not pay

[  ] If payment conflicts with board/owner policy → do not pay

Recovery Readiness

[  ] MVO map completed (functions → dependencies → workarounds)

[  ] RTO/RPO set for top 5–10 functions

[  ] Backups cover SaaS + endpoints + servers

[  ] Backups are isolated/protected; restore path documented

[  ] Restore order list exists (what comes back first, second, third)

Incident Response Basics

[  ] Incident roles assigned (Commander, Comms, Legal, Ops, Finance)

[  ] Out-of-band communication method ready

[  ] Decision tree documented (contain → assess → restore → decide)

Proof

[  ] Tabletop exercise completed in the last 6–12 months

[  ] Restore tests completed in the last 90 days for critical systems

[  ] Lessons learned captured and plan updated

A soft next step: Minimum Viable Resilience Assessment

If you want a “we won’t pay” stance that’s based on capability—not hope—start with an assessment designed for real-world constraints.

Book a Minimum Viable Resilience Assessment, and you’ll get:

  • A risk map: top failure scenarios (ransomware, SaaS outage, accidental deletion, vendor compromise) and what breaks first
  • A gaps report: decision rights, recovery gaps, and operational choke points
  • A practical roadmap: prioritized actions tied to MVO, RTO/RPO, and testable recovery

No hype. No promises of perfect security. Just a plan you can execute when it counts.

Bottom Line

  • Ransomware negotiations are a governance issue: define decision rights before the timer starts.
  • “No-pay” works when it’s tied to legal clearance and proven recovery capability.
  • Minimum viable resilience is what keeps you from making permanent decisions in chaos.

Bookmark this page for leadership insights into the MSP business: MSP Weekly Insights