The Ransom Decision Is Now a Disclosure Decision
How NIS2 amendments reframe every ransomware payment as a regulatory event — and why your incident response playbook hasn't caught up.
Your incident response playbook was built to manage a crisis. Containment, eradication, recovery, communication. It was optimised around one question: how do we get the organisation back online?
It was not built to function as a regulatory disclosure document.
That distinction mattered less before. Under the January 2026 proposed amendments to NIS2, it matters a great deal.
What the Amendments Actually Require
The proposed amendments introduce a two-tier ransomware disclosure framework for significant incidents affecting NIS2-covered entities.
The first tier is mandatory for all covered entities: standard incident notification timelines remain (24-hour early warning, 72-hour incident report, one-month final report), but the reporting scope now explicitly includes attack vector, detection timeline, and mitigation measures implemented. Ransomware incidents are named as a specific notification category.
The second tier is triggered on request from competent authorities: organisations that paid a ransom must be able to disclose the ransom demand, the amount paid, the payment method, and the recipient — including crypto-wallet details.
The practical implication is this: while the on-request nature of payment disclosure may appear to limit exposure, it does not. Any significant ransomware incident creates the predicate for a payment inquiry. The boundary between "did this happen" and "what did you pay" is now a regulatory decision, not yours.
The Scale of the Problem
According to Sophos's 2025 State of Ransomware report, 37% of organisations affected by ransomware paid the ransom. Verizon's 2025 DBIR corroborates this range. Chainalysis estimates global ransomware payments at approximately $820 million in 2024, with GuidePoint Security noting a 58% increase in victim organisations listed on leak sites.
That 37% figure means a substantial proportion of NIS2-covered entities are making payment decisions that will now sit inside a regulator-accessible disclosure architecture — regardless of whether the payment was successful, partial, or made under legal advice.
The payment decision has always been consequential. Under NIS2, it is also a disclosure event.
The Governance Gap in Your Playbook
Most incident response playbooks address the technical sequence: isolate, assess, recover, report. They often include a legal review step and an insurance notification step. Very few address the following:
Who owns the regulatory disclosure of payment details? This is not a technical question. It requires legal, compliance, and executive alignment — in real time, under pressure.
How does legal privilege interact with NIS2 disclosure obligations? Legal advice obtained during the payment decision process may not be privileged in all disclosure contexts. This requires explicit pre-incident legal mapping, not ad hoc analysis during a live incident.
What is the protocol when a competent authority requests crypto-wallet transaction history? If the payment was made via a third-party negotiator or broker, does the organisation have access to the transaction details? Who retains this data, and for how long?
How does payment disclosure interact with your cyber insurance policy? Some policies restrict or complicate disclosure of payment details. Others require notification before payment. These obligations need to be sequenced, not discovered post-incident.
Has the board been briefed on the regulatory consequences of a payment decision? Under NIS2, management bodies bear explicit responsibility. A board that authorises payment without understanding the disclosure implications is not acting with adequate oversight.
The UK government's parallel legislative thread — the ransomware notification and licensing regime proposed in the Cyber Security and Resilience Bill — adds a further dimension for organisations with UK operations. While still in development, the direction of travel across both EU and UK frameworks is consistent: payment decisions are becoming regulated acts, not private operational choices.
The Core Reframe: A Payment Is Now a Disclosure Event
The traditional framing of the payment decision is: weigh business continuity against ethical and strategic concerns, consult legal counsel, decide.
The NIS2 framework adds a third axis: whatever you decide, that decision — and its financial details — may be subject to regulatory disclosure.
This does not make payment illegal. It does not create a blanket prohibition. What it does is remove the discretion that previously existed around the decision. The confidentiality of the payment — the amount, the method, the recipient — is no longer assured simply because you manage it internally.
Organisations most exposed are those that: operate across multiple NIS2 member states with inconsistent playbooks; use third-party incident response firms without clear contractual data retention obligations; have not mapped the intersection of insurance policy terms and regulatory disclosure requirements; or have boards that treat the payment decision as purely an operational matter rather than a governance one.
Five Operational Actions Your Playbook Needs Now
1. Map payment decisions into your decision authority framework. The payment decision should have a defined owner, a defined escalation path, and a defined documentation standard — before an incident occurs. This is not a gap-fill; it is a governance requirement under NIS2's management accountability provisions.
2. Redesign decision authority for the disclosure context. The individual authorising payment and the individual responsible for regulatory disclosure may not be the same person. Both roles need to be defined, with clear handoff protocols and documentation obligations.
3. Establish legal privilege frameworks pre-incident. Work with legal counsel now to understand which communications during a ransomware incident are potentially disclosable and which may attract privilege. This analysis cannot be done effectively at 2am on day one of an incident.
4. Map your insurance policy against your disclosure obligations. Identify any conflicts between policy notification requirements and NIS2 disclosure timelines. Identify what payment-related data your insurer will require, and ensure you can produce it without conflicting with regulatory obligations.
5. Brief the board — specifically on the regulatory consequences of a payment decision. The NIS2 management liability provisions are explicit. Board members who approve a ransom payment without understanding the disclosure framework are exposed. This briefing should be documented.
The Practical Reality
There are no blanket payment prohibitions in the NIS2 amendments as currently proposed. The debate about whether to prohibit ransomware payments entirely — actively argued in some EU policy circles — has not yet produced legislation. What has emerged is a disclosure framework that fundamentally alters the risk calculus.
The ransom decision is no longer a private operational choice made under pressure with confidentiality largely assured. It is a regulatory event, with documentation requirements, disclosure obligations, and management accountability implications that attach regardless of the outcome.
Your playbook was built for the old model. The amendments describe the new one.
The gap between the two is exactly where your governance exposure lives.
Angelos Varthalitis is the founder of AVSec Advisory. This analysis is for informational purposes and does not constitute legal advice. The NIS2 amendments discussed reflect the January 2026 proposed framework and remain subject to legislative process.