UK Ransomware Payment Ban: What Is Proposed and How to Prepare

The UK government has decided to ban ransomware payments by the public sector and regulated critical national infrastructure, and to require victims to report attacks, but the rules are not yet law. This guide sets out exactly what the Home Office proposed in January 2025, what its government response of 22 July 2025 confirmed, what is still undecided, and what organisations can do now so they are not caught out when legislation arrives. It goes deeper on the UK regime than our Ransomware Payments and Sanctions Guide, which compares the UK with US sanctions and reporting rules. It is written for CISOs, legal and risk teams, and incident response leads in UK public bodies, CNI operators and their suppliers. Status was checked on 8 November 2026.

Key takeaways

• Three measures, one package. A targeted payment ban for public sector bodies and regulated CNI, a payment prevention regime for everyone else who intends to pay, and mandatory incident reporting.
• Still a proposal. The consultation closed on 8 April 2025 and the government response was published on 22 July 2025; the Home Office still describes legislation as proposed and has not named a bill on its consultation page.
• Reporting clock proposed at 72 hours and 28 days. An initial report within 72 hours of the attack and a fuller report within 28 days, with the threshold for who must report still to be set.
• Penalties are undecided. Respondents preferred civil over criminal penalties, and the government says it is still exploring proportionate options that do not revictimise victims.
• Prepare as if the ban applies. If you are in or supply the public sector or CNI, plan to recover without paying: tested immutable backups, protected recovery identities and a rehearsed decision process.

Scope: who and what is covered

The Home Office consultation "Ransomware: proposals to increase incident reporting and reduce payments to criminals" ran from 13 January 2025 to 8 April 2025. The government response records 273 responses (233 survey responses and 40 written responses) plus 36 engagement events. The three proposals reach different groups.

• Public sector: central government, local authorities, schools, the NHS and other publicly funded bodies are the obvious core. Expect the final legislation to define the list, so do not assume an arm's length body is outside it.
• CNI: the response ties the ban to CNI that is regulated or has a competent authority. That is the same population most likely to fall under the NIS Regulations and the UK Cyber Security and Resilience Bill.
• Suppliers: 62% of respondents to the relevant question said CNI and public sector supply chains should be included, 27% said no. The government has not decided; managed service providers and data centre operators should watch this closely.
• Everyone else: businesses, charities and individuals would not be banned from paying, but would fall under the prevention regime if they intend to pay, and possibly under reporting depending on the threshold.

Key obligations

Proposal 1: the targeted ban

In-scope bodies would be prohibited from paying a ransom. 72% of respondents agreed with the ban and 23% disagreed; 68% thought it would reduce criminal income and 60% thought it would deter attacks. Half of respondents wanted it widened (25%) or applied economy-wide (25%), while 37% saw no case for widening. The practical consequence is simple: an in-scope organisation must be able to recover from encryption and live with data publication without the option of paying.

Proposal 2: the payment prevention regime

A victim intending to pay would report that intention to the government. The response describes the process: the victim receives support and guidance, the government reviews the proposed payment, and it may block a payment that would go to criminals subject to sanctions designations or would breach terrorism finance legislation. If the payment is not blocked, whether to pay remains the victim's decision. The government is clear that it does not approve payments and does not advise paying. Compliant victims would receive proof of engagement to show to payment brokers or facilitators such as negotiators and insurers.

Proposal 3: mandatory reporting

Victims would submit an initial report within 72 hours of the attack and a more detailed report within 28 days. The economy-wide reporting option drew 63% net agreement, against 41% for keeping today's voluntary regime. On thresholds, respondents favoured annual UK turnover (63%), sector (53%), employee numbers (40%) and ransom amount (33%). The final threshold has not been published.

Timeline and current status

• 13 January 2025: consultation opens.
• 8 April 2025: consultation closes.
• 22 July 2025: government response published, confirming all three proposals will be developed further.
• 2 September 2025: Welsh translation of the response added.
• Status at 8 November 2026: the gov.uk consultation page still says the Home Office "proposes to introduce legislation" and names no bill. Our October 2026 review in the Ransomware Payments and Sanctions Guide reached the same view. Check the Parliament bills site before relying on this page.

The response commits the government to keep developing the proposals with industry, to publish guidance alongside any legislation, and to align the measures with the Cyber Security and Resilience Bill. Expect a gap between Royal Assent and commencement, with detail in secondary legislation and guidance, as is happening with that bill.

Enforcement and penalties

No penalty regime has been fixed. The consultation asked about non-compliance sanctions for both the prevention regime and reporting.

For the ban itself, views were mixed and the government says it will "continue to explore the most appropriate and proportionate penalties", noting concern about revictimising organisations that have already been attacked. Existing law already bites today: paying a person subject to UK financial sanctions is an offence regardless of these proposals, which is why the prevention regime screens payments against sanctions designations.

The new duties would also sit alongside obligations that already apply to a ransomware incident. A personal data breach can trigger notification to the ICO under UK GDPR Article 33, operators of essential services and relevant digital service providers report under the NIS Regulations, and sector regulators have their own rules. Penalties under those regimes are unchanged by these proposals, so an organisation that misses a ransomware report could also be in breach of a separate duty for the same incident.

What it means for AI agents and non-human identities

Ransomware crews rarely need a zero day. They use credentials, and many of the most useful ones are non-human: service accounts with domain rights, backup system credentials, hypervisor management accounts, remote management agents and cloud access keys. A payment ban removes the option of buying your way out, so the strength of recovery depends on whether those identities survive the attack.

• Backup and recovery identities: attackers target backup consoles to delete or encrypt restore points before detonating (ATT&CK T1490 Inhibit System Recovery). Backup admin accounts and API keys must sit outside the production directory. See the Backup Identity Isolation Guide.
• Service accounts and secrets: rotating every machine credential after an intrusion is often the longest part of recovery. Inventory them now, with owners, so rotation is a runbook, not a discovery exercise. See the IAM and PAM Recovery After Ransomware Guide.
• Automation that can pay or report: if AI agents or scripts handle incident ticketing or regulator portals, they must not be able to submit or approve anything on their own. Reports and payment intentions are legal acts by named people.
• Evidence for the 28 day report: logs of which identities were used, when and from where are the core of any detailed report. Keep authentication and privileged session logs outside the blast radius.

Compliance steps

1. Decide whether you are likely in scope. Map your organisation against public sector, regulated CNI and CNI supplier categories. Record the reasoning so it can be revisited when the bill is published.
2. Adopt a no-payment recovery assumption. For in-scope bodies, take payment off the table in the incident plan now. For others, make payment a board-level decision with legal, sanctions and law enforcement input.
3. Prove you can restore. Immutable or offline backups, tested restores of tier 1 systems with measured times, and a clean build path for identity infrastructure. See the Backup Security and Immutable Backup Guide.
4. Build a 72 hour reporting runbook. Name who submits, who approves, what minimum facts are needed and where the drafts live offline. Reuse the structure you use for NIS and UK GDPR Article 33 reports so one incident does not produce three inconsistent accounts.
5. Prepare for a data leak, not just encryption. A ban does not stop extortion by publication. Plan customer and regulator communications for a leak-site listing. See the Ransomware Leak Sites Guide.
6. Review contracts and insurance. Check incident response retainers, negotiation services and cyber insurance wording for assumptions about payment, and for how proof of engagement would be handled.
7. Exercise it. Run a tabletop where payment is not allowed and the 72 hour report is due during the worst day of the incident. Fix what breaks.

Decision guidance by organisation type

Large organisations should expect their legal, sanctions and insurance teams to be part of any payment discussion, with a documented record of why a payment was or was not considered. Smaller organisations will rarely have that support; for them the cheapest form of compliance is never needing to consider payment, which means backups that the attacker cannot reach and an account recovery path for email and banking that does not depend on the encrypted machines.

Measuring readiness

• Restore time: measured time to restore identity services and the top three business systems from immutable backup, against the target.
• Backup isolation: percentage of backup administrative identities that are separate from the production directory and protected by phishing-resistant MFA.
• Machine credential coverage: percentage of service accounts and keys with a named owner and a tested rotation procedure.
• Reporting rehearsal: time taken in the last exercise to produce an initial report with the minimum facts, against the 72 hour target.
• Supplier assurance: percentage of critical suppliers that have provided a ransomware recovery and notification statement.

Framework mapping

Common failure patterns

• Treating the ban as already in force or as dead. Both are wrong. Plan for it, and keep checking the bill status rather than relying on press coverage from July 2025.
• Backups reachable with domain admin. If the same identity can manage production and delete backups, a no-payment policy becomes a no-recovery policy.
• No owner for the reporting clock. A 72 hour window disappears quickly when the people who would write the report are rebuilding servers.
• Ignoring suppliers. A council or hospital trust whose IT provider is hit is still the victim the public sees. Ask suppliers how they would recover without paying.
• Forgetting extortion without encryption. Data theft and leak threats continue whatever the payment rules say.

Practitioner checklist

• Record a scope assessment against the three proposals and review it when a bill is published.
• State in the incident response plan who can and cannot authorise any payment.
• Test restore of identity infrastructure, backups and one tier 1 application, and record times.
• Move backup admin accounts and keys out of the production directory, with phishing-resistant MFA.
• Draft a 72 hour initial report template and a 28 day detailed report template, stored offline.
• Map how a ransomware report would align with NIS, UK GDPR and sector reporting.
• Ask key suppliers for their ransomware recovery plan and reporting contacts.
• Run a no-payment tabletop at least once a year.
• Check the bill status every quarter and update this process.

Standards and references

• UK Home Office: Ransomware, proposals to increase incident reporting and reduce payments to criminals
• UK Home Office: Government response to ransomware legislative proposals
• NIST: Cybersecurity Framework 2.0
• NIST: SP 800-53 Rev. 5
• MITRE ATT&CK: Data Encrypted for Impact
• MITRE ATT&CK: Inhibit System Recovery

Related NHI Mgmt Group resources: Ransomware Payments and Sanctions Guide · UK Cyber Security and Resilience Bill · Ransomware Response and Recovery Guide · Ransomware Negotiation Guide. This guide summarises the UK ransomware payment and reporting proposals as checked on 8 November 2026 and is not legal advice.