Ransomware Negotiation Guide: Decisions, Legal Limits and Process

When a ransomware group makes contact, the organisation has hours to make decisions that it should have prepared for months earlier. Engaging with an extortion demand is not the same as paying it, and both carry legal, regulatory and ethical limits that differ by country. This guide is for incident leads, CISOs, legal counsel and executives who may sit on a ransomware decision group. It covers who decides, what evidence the decision needs, the legal and sanctions constraints in the UK and US, how to handle attacker communications safely, and how to record everything for regulators and insurers. It is defensive guidance, not legal advice, and it deliberately does not describe how to make or route a payment.

Key takeaways

• Not paying is the default position of governments. The NCSC, UK law enforcement, the FBI and the US Treasury all discourage payment, and the UK is moving towards a ban for the public sector and critical national infrastructure.
• Decide the decision process before the incident. Name the decision group, the legal advisers, the insurer contact and the thresholds in advance, so the first call is not spent arguing about who is in charge.
• Engagement buys information, not safety. Contact with the attacker can confirm what was taken and buy time for recovery, but it can also leak information and does not make deletion promises trustworthy.
• Sanctions and regulatory exposure stay with the victim. A payment to a sanctioned person can be unlawful, and the ICO has said it will not treat a payment as a mitigating factor.
• Record every decision offline. NCSC guidance asks victims to keep records of decisions, actions and data, held on systems the attacker cannot reach.

What ransomware negotiation actually is

"Negotiation" covers any structured contact between a victim (or its adviser) and an extortion group after an attack. In modern ransomware it usually serves one of four purposes, and only one of them involves money:

• Verification: asking for proof of what data was stolen (file trees, samples) so that legal and data protection teams can scope notification. NCSC guidance says to verify attacker claims about stolen data where possible.
• Time: slowing the attacker's deadline while backups are tested and systems rebuilt. Attackers use countdown timers and leak-site threats deliberately; NCSC's first consideration is "don't panic".
• Intelligence: learning the group's identity, wallet addresses and tooling, which law enforcement and sanctions screening both need.
• Settlement: agreeing a price for a decryptor or a promise not to publish. This is the option governments discourage and that may be prohibited for some organisations.

Most incidents now combine encryption (MITRE ATT&CK T1486 Data Encrypted for Impact) with theft of data (for example T1567 Exfiltration Over Web Service) and deletion of recovery points (T1490 Inhibit System Recovery). Double extortion changes the calculation: a working backup solves the encryption problem but not the publication threat. For incidents with no encryption at all, see the Data Extortion Without Encryption Guide.

The legal and regulatory position

Paying a ransom is not in itself illegal in the UK or US for most private organisations, but several regimes constrain it. The table summarises the positions confirmed from official sources at the time of writing. Laws in this area are changing, so check the primary source before relying on any row.

Two further points matter. First, US sanctions liability is generally strict: a person can be liable for dealing with a sanctioned party even without knowing it, which is why OFAC stresses mitigation through reporting and cooperation. Second, multinational organisations need local advice in each jurisdiction where the paying entity, the insurer and the affected data sit. NCSC guidance makes the same point about considering local laws. For the detail of payment law, see the Ransomware Payments and Sanctions Guide (UK Payment Ban Proposals, OFAC).

Who decides: the decision group

A ransom decision is a board-level business decision informed by technical facts. It should never be taken by the person who happens to be talking to the attacker. Define the group in the incident response plan, with deputies.

Smaller organisations will combine roles, but should still separate the communicator from the decision owner and should agree in advance which external adviser (often an insurer panel firm or an NCSC-assured Cyber Incident Response provider in the UK) will fill gaps. Large groups should decide which legal entity would make any decision and in which jurisdiction, before an incident. See the Crisis Management Guide.

Building the evidence for the decision

NCSC guidance warns against presenting options too early and asks for a strong evidence base. A useful discipline is to require written answers to a fixed set of questions before the decision group meets:

1. Recovery without payment: Are backups intact, isolated and tested? How long will a full restore take for the systems that matter most? Has anyone asked law enforcement whether a free decryptor exists, as both CISA and NCSC guidance suggest? See the Backup Security and Immutable Backup Guide.
2. Operational tolerance: How long can manual workarounds run? NCSC frames this as business operations impact.
3. Data impact: What was taken, how sensitive is it, and does it put anyone at risk of harm, including vulnerable people? Has the theft been verified from logs rather than from the attacker's claims?
4. Root cause: How did the attacker get in, and is that path closed? NCSC is explicit that paying without fixing the entry point leaves the organisation exposed to a repeat attack.
5. Attribution and sanctions: Which group is this, according to the incident responders and threat intelligence, and is there any link to a sanctioned person or jurisdiction? See the Ransomware Groups Guide.
6. Financial comparison: Cost of each option, including disruption, overtime, legal and regulatory costs. NCSC notes that ransom amounts are usually negotiable, which is why price is never the first question.
7. Legal duties: Notification clocks (for example the UK GDPR 72-hour personal data breach notification to the ICO under Article 33), sector rules, contractual notice to customers, and any proposed or enacted payment rules that apply.

The answers to questions 1, 3 and 4 should come from the investigation, not from the attacker. Many decision groups find that once recovery time is known with confidence, the remaining question is about stolen data, and a payment does not reliably solve that.

Handling attacker communications safely

If the group decides to engage (for verification, time or intelligence), set boundaries in writing first. The communicator works to a mandate, not to their own judgement.

• Mandate: what may and may not be said, what may be asked for (proof of data, list of files), and that no commitment of any kind is made without written approval from the decision owner.
• Channel hygiene: use a clean device and an account with no link to the corporate identity, not a compromised endpoint or the corporate email the attacker may be reading. Assume the attacker still has access to email, chat and file shares until containment is confirmed.
• Information discipline: do not reveal insurance cover, backup status, internal deadlines, revenue or who is on the decision group. Attackers read stolen documents, including insurance policies, to set demands.
• Evidence: capture every message with timestamps, the portal address and any wallet addresses or identifiers, and share them with law enforcement. These are evidence and intelligence.
• Pressure: expect deadlines, threats to contact customers or regulators, and staged leaks. These are tactics; NCSC advises slowing down.
• Consistency: everything said to the attacker should be consistent with what the organisation is saying publicly and to regulators, because the conversation itself may be published.

Leaked negotiation transcripts are a real risk: some groups publish chat logs to embarrass victims or to signal to future victims what they "should" pay. Write every message assuming it will appear on a leak site.

Option comparison

Paid settlements have a mixed record. In the Caesars Entertainment breach, a reported payment of around half the initial demand did not remove the need to disclose loyalty-programme data theft. In the Colonial Pipeline attack, the company's chief executive described the decryptor as helpful but "not perfect", and the US Justice Department later seized part of the payment, a reminder that early law enforcement involvement matters whatever the decision.

Implementing a negotiation readiness process

1. Write the policy position: the board agrees and minutes the organisation's stance (for example, "we will not pay except in the circumstances below, and only after legal and sanctions review"). Public bodies and CNI operators should assume a no-payment position.
2. Name the decision group and deputies in the incident response plan, with out-of-hours contacts held offline. See the Incident Response Plan Template.
3. Pre-arrange external help: breach counsel, an incident response firm (check insurer panel requirements in the policy), and law enforcement contacts. See the Cyber Insurance Guide.
4. Prepare the evidence template: the seven questions above, as a form the incident lead fills in for the decision meeting.
5. Prepare the record: a decision log template held on an out-of-band system, with fields for time, attendees, evidence considered, options, decision and reasons.
6. Test it: run a tabletop where the attacker makes contact and threatens publication, with the real executives. See the Tabletop Exercise Guide.
7. Review and roll back: after every exercise or incident, update the mandate and contacts. If a rehearsal shows the decision group cannot assemble within the target time, change the delegation rather than letting the communicator decide by default.

Where identity fits

Ransomware decision-making depends on knowing whether the attacker is still inside, and that is mostly an identity question. Contain compromised accounts, reset privileged and service account credentials, revoke tokens and keys, and confirm that backup administration identities were not used. Negotiating while the attacker still holds valid credentials hands them a view of every decision. See the Identity Incident Response Playbook and the Backup Identity Isolation Guide.

Detection and measurement

During an incident, monitor for continued attacker activity on the accounts and channels used for decision-making, new data appearing on the group's leak site, and contact attempts with staff, customers or the media. Between incidents, track readiness:

• Time to assemble the decision group in the last exercise, against the target in the plan.
• Restore time evidence: measured time to restore the top critical services from isolated backups in the last test.
• Contact currency: percentage of decision group, counsel, insurer and law enforcement contacts verified in the last quarter.
• Exercise coverage: number of executive tabletop exercises per year that include an extortion contact and data publication threat.
• Reporting timeliness: in real incidents, time from detection to report to law enforcement and, where required, to the regulator.

Framework mapping

Common failure patterns

• The communicator becomes the decision maker: a technical lead or adviser drifts from verification into commitments because no mandate was written.
• Deciding on attacker claims: the group accepts the attacker's description of what was stolen and how they got in, instead of verifying it from logs.
• Negotiating on compromised channels: decisions are discussed on corporate email or chat the attacker still reads.
• Treating payment as the end of the incident: root cause is left unfixed, notification duties are missed, and the organisation is attacked again.
• Late law enforcement contact: reporting is delayed until a decision is made, losing the chance of a decryptor or intelligence and weakening the position with OFAC or the ICO.
• Undocumented reasoning: no contemporaneous record exists to show regulators, insurers or courts why a decision was taken.

Practitioner checklist

• Board-approved policy position on ransom payments, reviewed annually and aligned with any UK or local payment rules.
• Named decision group with deputies and offline contact details.
• Written mandate template for any attacker communication.
• Pre-agreed breach counsel, incident response provider and insurer notification route.
• Sanctions screening step owned by legal before any settlement discussion.
• Report to law enforcement (police via gov.uk/report-cyber routes in the UK, FBI field office or IC3 in the US) and the NCSC or CISA as early as possible.
• Out-of-band decision log with time, evidence, options, decision and reasons.
• Annual executive tabletop including extortion contact and leak threat.

Standards and references

• NCSC: Guidance for organisations considering payment in ransomware incidents
• Home Office: Ransomware proposals to increase incident reporting and reduce payments to criminals
• UK Government: UK to lead crackdown on cyber criminals with ransomware measures
• US Treasury: Updated advisory on potential sanctions risks for facilitating ransomware payments
• ICO: ICO and NCSC stand together against ransomware payments being made
• CISA: #StopRansomware Guide
• NCSC: Ransomware: what is it and what to do
• FBI: Ransomware

Related NHI Mgmt Group resources: Ransomware Response and Recovery Guide · Ransomware Playbook Template · Incident Response Guide · Ransomware Prevention Guide. This guide summarises official positions on ransomware payments and is not legal advice.