Ransomware response: should we pay, and what to verify first

TL;DR — Paying a ransom is usually a last-resort business decision, not a technical fix. Before you even discuss payment, answer four things in order: what was actually affected, whether you can restore from clean backups, whether payment would be illegal or unsafe, and whether the attacker still has access. Reading time: ~7 min

What it is and where it sits

A ransom decision happens inside incident response (the coordinated process for handling a security event), not inside IT operations alone. The question is not just "can we decrypt files?" It is "what happened, what can we recover without the attacker, what are the legal and business consequences, and will paying improve the outcome enough to justify the risk?"

In a typical ransomware event, the attacker may have done one or more of these things:

• encrypted servers, laptops, or cloud storage
• stolen data for extortion
• disabled backups or admin accounts
• left remote access behind for later reuse

That means the ransom decision sits between several teams and systems:

• your affected systems: laptops, servers, cloud storage, databases
• your recovery systems: backups, snapshots, disaster recovery copies
• your identity systems: Microsoft 365, Google Workspace, VPN, single sign-on (SSO, central login)
• your advisors: legal counsel, cyber insurer, incident-response firm, law enforcement
• your business owners: leadership deciding downtime tolerance and customer impact

What it replaces: nothing, ideally. A good response process should replace the instinctive "just pay and move on" reaction with a structured go/no-go decision.

Where it lives in the flow: after detection, before irreversible actions like paying, rebuilding everything, or publicly claiming what happened.

[Monitoring/User Report] ---- 1. suspicious encryption ----> [IR Team]
[IR Team] ---- 2. isolate systems ----> [Affected Systems]
[IR Team] ---- 3. check restore options ----> [Backups/Snapshots]
[IR Team] ---- 4. check legal/insurance ----> [Counsel/Insurer]
[IR Team] ---- 5. confirm attacker access ----> [Identity/Network Logs]
[Leadership] <---- 6. facts and options ---- [IR Team]
[Leadership] ---- 7. decide: restore / negotiate / not pay ----> [Response Plan]

The important architecture point: paying does not remove malware, close stolen passwords, or prove the attacker deleted stolen data. It only attempts to buy one thing: attacker cooperation. That is a weak dependency to build your recovery around.

How it actually works

Here is one realistic end-to-end example.

A 60-person company finds that its shared drive and two Windows servers now have files ending in a strange extension, and a note says to contact the attacker within 72 hours. Staff also report they cannot log in to VPN.

Step 1: Stabilize first, not decide first

The first action is to stop the damage spreading and preserve evidence.

Concrete actions:

• In your endpoint or device-management dashboard, isolate infected devices. In common tools this is usually under a device page with an action like Isolate device.
• In your cloud provider or virtualization dashboard, power off only clearly affected non-critical servers if encryption is still actively spreading. If the server hosts logs or critical evidence, disconnect network access instead of shutting down if possible.
• In your identity provider dashboard, force password resets for privileged accounts and revoke active sessions. In many providers this is under Users → [user] → Revoke sessions or Security → Reset password.

Do not contact the attacker yet. You need facts first.

Step 2: Answer the four decision questions

1) What exactly is affected?

You need a scope list, not a guess.

Ask your responders to produce a simple table:

• system name
• business function
• encrypted yes/no
• suspected data stolen yes/no
• last known good backup date
• owner

Examples:

• file server: encrypted, backup from last night available
• finance database: unavailable, snapshot from 4 hours before attack available
• Microsoft 365 mailboxes: no encryption seen, suspicious logins present

If only a subset is affected and core systems are restorable, the pressure to pay drops sharply.

2) Can we restore from clean backups or snapshots?

This is usually the most important question.

Check in your backup console or cloud dashboard:

• whether backups exist from before the intrusion
• whether they are immutable (cannot be altered) or offline
• whether test restores actually work
• how long a restore will take for the systems that matter most

A backup that exists but has never been tested is not yet a recovery option.

3) Would paying create legal, insurance, or regulatory problems?

Before any payment discussion, contact:

• your legal counsel
• your cyber insurer, if you have one
• law enforcement or your national cyber reporting body, if advised by counsel

Reasons:

• some payments may be restricted if the recipient is sanctioned
• your insurer may require approved vendors and specific evidence handling
• breach-notification duties may apply if data was stolen, whether or not you pay

4) Is the attacker still inside?

This is the question many teams underweight. If the attacker still has admin access, paying may simply buy a decryptor while they remain able to re-encrypt or extort again.

Check:

• admin accounts created recently
• MFA (multi-factor authentication, extra login proof) disabled anywhere
• suspicious VPN or remote desktop logins
• mailbox forwarding rules
• new scheduled tasks, startup items, or remote tools on servers

Step 3: Build options with time and cost

Now turn facts into options leadership can compare.

For our example company, the response team reports:

• file server restorable from last night in 6 hours
• finance database restorable from cloud snapshot in 2 hours plus 1 hour validation
• 8 laptops need rebuilds
• evidence suggests 40 GB of files were exfiltrated (copied out)
• attacker still had one dormant admin account in Microsoft 365, now disabled

That leads to three realistic options:

1. Do not pay; restore and rebuild. Downtime: 1 business day for core systems, 2-3 days for all users.
2. Negotiate but do not commit. Used to gather proof of decryption capability or buy time while restoring.
3. Pay. Only if counsel, insurer, and leadership agree the business impact of not paying is worse and no viable clean restore exists.

Step 4: Decide on evidence, not hope

In this example, the company should probably not pay because:

• backups and snapshots exist
• restore time is acceptable compared with payment uncertainty
• attacker access was not fully removed until after discovery, so trust is low
• payment would not undo data theft risk

That is how the mechanism works in practice: the ransom decision is the output of a recovery-and-risk assessment, not the starting point.

When to use it (and when not to)

Use this decision framework whenever an attacker demands money for decryption, data deletion, or non-disclosure.

You probably do not need to consider payment seriously if:

• your backups are clean and tested
• only a small number of endpoints are affected
• the encrypted data is non-critical or reproducible
• the demand is low-pressure but your restore path is faster than negotiation

You may need an urgent executive decision if:

• patient care, manufacturing, payroll, or regulated operations are stopped
• there is no clean restore path
• the attacker has both encrypted and stolen high-impact data

Trade-offs

Every benefit has a cost.

The biggest hidden cost of paying is false closure. A paid ransom can create the impression that the incident is over when the real work — credential resets, persistence hunting, legal notifications, and recovery validation — has barely started.

In practice

Below are two practical artifacts you can adapt today: a decision worksheet and a recovery checklist. These are not vendor-specific.

⚠️ If you restore systems before checking whether the attacker still has admin access, you can reintroduce the same compromise into freshly restored systems and lose more time.

{
  "incident_id": "IR-2026-04-017",
  "ransom_event": true,
  "decision_owner": "CEO",
  "technical_lead": "IT Manager",
  "legal_contacted": true,
  "insurer_contacted": true,
  "law_enforcement_contacted": false,
  "affected_assets": [
    {"name": "fileserver-01", "criticality": "high", "encrypted": true, "exfiltration_suspected": true, "last_good_backup": "2026-04-17T01:00:00Z", "restore_tested": true},
    {"name": "finance-db", "criticality": "high", "encrypted": false, "exfiltration_suspected": false, "last_good_backup": "2026-04-17T09:00:00Z", "restore_tested": true}
  ],
  "attacker_access_removed": false,
  "sanctions_check_complete": false,
  "estimated_restore_hours": 9,
  "estimated_business_loss_usd": 45000,
  "initial_recommendation": "Do not pay until attacker access is removed and restore path fails"
}

This is a simple decision record you can keep in your ticketing system or shared incident folder. The gotcha: do not let this become a form-filling exercise; every field should drive a real action or decision.

containment_checklist:
  - disable_newly_created_admin_accounts
  - revoke_active_sessions_for_privileged_users
  - reset_passwords_for_admin_vpn_and_backup_accounts
  - isolate_infected_endpoints_in_edr
  - block_known_malicious_ips_and_domains_in_firewall_dns_email
recovery_checklist:
  - verify_last_good_backup_date_before_first_encryption_event
  - perform_test_restore_to_isolated_environment
  - validate_line_of_business_app_starts_and_data_integrity
  - rebuild_compromised_endpoints_from_gold_image
  - re-enable_user_access_in_phases
communications_checklist:
  - notify_legal_and_insurer
  - prepare_customer_staff_holding_statement
  - log_all_decisions_timestamps_and_approvals

This YAML checklist can be pasted into a runbook, ticket, or incident document. The gotcha: "last good backup" must be before the attacker gained access, not just before encryption was noticed.

If you do have shell access and your responders ask for a quick indicator of recently created local accounts on a Linux server, use a read-only command like this after preserving evidence plans are agreed:

awk -F: '$3 >= 1000 {print $1, $3, $6}' /etc/passwd

This lists regular local users by username, UID, and home directory. The gotcha: it does not show when the account was created, only what exists now, so pair it with other logs.

Further reading

• NIST Computer Security Incident Handling Guide (SP 800-61)
• CISA StopRansomware Guide
• The "Data Backup" and "Incident Response" sections of the CIS Critical Security Controls
• The "Ransomware" guidance from your national cyber security agency
• The "Security Incident Response" chapter of the Microsoft and Google Workspace admin documentation

This article was written by an AI system and published pending human review. Verify anything you intend to act on.