Ransomware Payment Governance for NIS2 and DORA

It is 3:17 AM on a weekday in 2026. Maria, the CISO of a fast-growing fintech platform, is pulled into a crisis bridge by a message from her lead SOC analyst: widespread encryption confirmed, core services down, and a ransomware group claiming to have stolen 2TB of customer data.

The CEO joins the call first. Legal follows. Then privacy, finance, communications, the cyber insurer, a forensic provider, and the cloud operations team. A dark web portal shows a 48-hour countdown and a seven-figure demand in cryptocurrency.

The CEO asks the question every CISO dreads.

“Can we pay, and who is allowed to decide?”

The wrong answer is to treat this as a negotiation problem. The right answer is to treat it as a governance problem.

In 2026, ransomware payment decision governance is no longer a private, technical crisis choice. It can be scrutinized by regulators, auditors, insurers, customers, law enforcement, shareholders and the board. A payment decision intersects with sanctions exposure, personal data breach assessment, cyber insurance conditions, contractual duties, crisis communications, evidence preservation, NIS2 staged reporting, DORA incident classification, GDPR notification and post-incident improvement.

That is why Clarysec advises clients to build ransomware payment decision governance inside the ISMS before the incident. ISO/IEC 27001:2022 gives the management system structure. ISO/IEC 27002:2022 controls provide the operating model. Zenith Blueprint: An Auditor’s 30-Step Roadmap and Zenith Controls: The Cross-Compliance Guide help turn that structure into practical, auditable evidence.

A ransomware playbook that says “notify legal” is not enough. The organization must know who can authorize negotiation, how sanctions screening is performed, when the insurer must approve, how GDPR, NIS2 and DORA classification is documented, and how evidence is protected while recovery teams work under pressure.

Why ad hoc ransomware payment decisions fail

A ransomware payment decision is often described as binary: pay or do not pay. In reality, the decision has at least six layers:

1. Is the event confirmed, contained and classified correctly?
2. Is personal data, regulated data or critical service delivery affected?
3. Is the organization legally allowed to communicate or transact with the threat actor?
4. Does cyber insurance require prior notice, approved vendors, consent or specific evidence?
5. Would payment reduce business impact, or would it increase legal, financial and reputational risk?
6. Who has authority to decide, and how is that decision recorded?

During a live incident, disconnected teams often pull in different directions. The CFO may see the ransom as a business expense compared to mounting downtime. Legal sees sanctions, financial crime and regulatory exposure. The DPO is assessing whether encrypted or exfiltrated data creates a notifiable personal data breach. Compliance is watching NIS2 and DORA reporting clocks. The CISO is trying to preserve evidence while restoring services. The CEO wants a recommendation before the attacker’s timer expires.

Without a formal decision process, the loudest voice in the room can become the governance model. That is exactly the situation modern cybersecurity regulation is designed to prevent.

NIS2 makes cybersecurity a management responsibility. Article 20 addresses governance and accountability of management bodies, while Article 21 requires risk-management measures covering incident handling, business continuity, backup management, crisis management, supply chain security, access control, asset management, MFA and effectiveness assessment. Article 23 creates staged reporting for significant incidents, including early warning within 24 hours, notification within 72 hours and final reporting within one month where applicable.

For financial entities, DORA is the sector-specific operational resilience rulebook. Article 5 places responsibility on the management body for ICT risk management. Articles 17, 18 and 19 address ICT-related incident management, classification and reporting of major ICT-related incidents. DORA also requires response and recovery capabilities, backup and restoration, post-incident learning, testing and ICT third-party risk management.

GDPR adds a separate but overlapping assessment. If ransomware causes accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to personal data, the controller must assess whether a personal data breach occurred. If notification is required, the supervisory authority clock is generally 72 hours from awareness. If there is high risk to individuals, communication to affected individuals may also be required.

The conclusion is simple: the ransom question must not be asked for the first time inside the war room.

ISO 27001:2022 controls that anchor payment governance

An ISO/IEC 27001:2022 ISMS is not a checklist for auditors. It is a management system for making risk-based decisions. Ransomware payment governance belongs inside that system because it combines risk assessment, risk treatment, roles, legal obligations, incident response, continuity, supplier management and continual improvement.

The most relevant ISO 27001:2022 Annex A controls form a connected control chain.

In Zenith Controls, the section for A.5.24, Information security incident management planning and preparation, classifies the control as corrective, tied to confidentiality, integrity and availability, and aligned to Respond and Recover concepts. It also links A.5.24 to A.5.25 event assessment, A.5.27 learning from incidents, A.8.15 logging, A.8.16 monitoring, A.5.29 security during disruption, continuity and contact with authorities.

This matters because ransomware payment governance is a chain. If you cannot detect and classify the event, you cannot decide. If you cannot preserve evidence, you cannot defend the decision. If legal obligations are not mapped, negotiation or payment may be unlawful. If recovery options are untested, executives may be pressured into a decision based on fear rather than fact.

Zenith Controls states the relationship between preparation and decision-making plainly:

“5.25 is the decision point that determines when an event crosses the threshold into a security incident, triggering the actions outlined in 5.26. Timely and accurate event assessment ensures that incident response is neither delayed nor misdirected.”

The same guide ties A.5.31, Legal, statutory, regulatory and contractual requirements, to privacy, records retention, independent review and compliance with internal policies. For ransomware, A.5.31 is where sanctions screening, insurance obligations, law enforcement engagement, customer contracts, data protection duties and sector regulatory reporting are captured in one compliance register.

The Clarysec five-gate ransomware payment governance model

Clarysec’s model separates ransomware payment decision governance into five gates. The purpose is not to make paying easier. It is to make any decision, including refusal to pay, evidence-based, legally reviewed, authorized and auditable.

This model uses ISO 27001 risk treatment logic. A ransomware payment is not a security control. It is, at most, a crisis option considered within a risk treatment and recovery context. Before an incident, the organization should already have decided how ransomware risks are treated: mitigate through controls, transfer part of financial exposure through insurance, avoid unacceptable legacy dependencies, or explicitly accept residual risk where justified.

In the Risk Management phase, Step 13, Risk Treatment Planning and Statement of Applicability, Zenith Blueprint instructs organizations to determine treatment options for each risk and document them in the Risk Register. It cautions that transfer, such as cyber insurance, does not remove the need for controls because transfer often addresses financial impact rather than likelihood. It also states:

“Acceptance must be explicit and approved by management, especially for any Medium risks. High risks are seldom accepted unless truly unavoidable and agreed at top level.”

That line is directly relevant to ransomware payment governance. If the board is being asked to accept the residual risk of refusing payment, or the legal and reputational risk of approving negotiation, acceptance must be explicit, recorded and approved by the right authority.

Clarysec’s Risk Management Policy reinforces the same point:

“Risk treatment decisions shall align with the predefined options”
From clause 5.5.

A ransom decision is therefore not a shortcut around risk management. It must be handled as a formal, documented risk treatment decision under defined authority.

Policy authority: who can decide under pressure?

Many ransomware failures are governance failures disguised as technical failures. Someone contacts the attacker outside the approved channel. Someone promises payment before insurer approval. Someone restores systems and overwrites forensic evidence. Someone tells customers too early, too late, or with inaccurate facts.

Clarysec policies are designed to remove that ambiguity.

For SMEs, the Governance Roles and Responsibilities Policy-sme gives a simple rule:

“All significant security decisions, exceptions, and escalations must be recorded and traceable.”
From section “Governance Requirements”, policy clause 5.5.

The SME Incident Response Policy-sme assigns escalation authority:

“The General Manager (GM) is accountable for authorizing all incident escalation decisions, regulatory notifications, and external communications.”
From section “Governance Requirements”, policy clause 5.1.1.

It also connects customer data incidents with regulatory obligations:

“Where customer data is involved, the General Manager must assess legal notification obligations based on the applicability of GDPR, NIS2, or DORA.”
From section “Risk Treatment and Exceptions”, policy clause 7.4.1.

For larger organizations, the enterprise Governance Roles and Responsibilities Policy requires immediate escalation where legal exposure or reportable data breaches may exist:

“Legal/Regulatory Escalation: Incidents involving potential legal exposure or reportable data breaches shall be escalated immediately to the Legal and Compliance Officer and Executive Management.”
From section “Policy Implementation Requirements”, policy clause 6.4.3.

The enterprise Incident Response Policy defines executive authority during severe incidents. Clause 4.6.1 states that the Executive Management Team’s role is to:

“Make strategic decisions during high-severity incidents, including approval of notifications and public communications.”

In a ransomware context, Clarysec treats payment discussion, negotiation authorization, customer notice, regulatory statement and public communication as strategic decisions, not technical actions.

A practical governance rule follows: the CISO may recommend, the incident team may assess, legal may advise, finance may validate payment mechanics, the insurer may consent or refuse coverage, but executive management or the board must own the decision according to pre-defined authority.

Sanctions-safe escalation before any negotiation

A sanctions-safe ransomware process starts with a prohibition: no employee, contractor, supplier, broker, negotiator or incident responder may negotiate, promise, facilitate or transfer value to a threat actor without approved legal review.

The legal checkpoint must happen before any active engagement with the attacker, not after a wallet address appears. The process should include:

• Legal counsel engaged before any communication beyond passive evidence capture.
• Threat actor identification using forensic, intelligence and law enforcement inputs where available.
• Sanctions and restricted-party screening for group names, aliases, wallet addresses, infrastructure, intermediaries and payment channels.
• Law enforcement consultation considered and recorded.
• Cyber insurer notified according to policy terms before appointing vendors or entering negotiations.
• DPO or privacy lead engaged if personal data may be involved.
• CFO or finance lead confirms payment controls, segregation of duties, anti-fraud checks and board approval requirements.
• Executive decision recorded with alternatives considered, including restoration, containment, service suspension, customer communication and refusal to pay.
• Evidence preserved for attacker communications, indicators, wallet details, decision meetings, approvals and external advice.

For ransomware, the legal register should include at least the following obligation sources.

Organizations should also define who can stop the payment decision. Legal, compliance, the DPO, sanctions counsel or the board should have explicit authority to pause negotiation or payment if screening is incomplete, evidence is unreliable, insurer conditions are unmet, or the action may breach law or contract.

Evidence preservation: do not destroy proof while restoring service

Ransomware teams naturally rush to restore operations. But if restoration destroys logs, snapshots, ransom notes, malware samples, memory images or attacker messages, the organization may lose the ability to prove what happened.

In the Controls in Action phase, Step 23, Organizational controls, Zenith Blueprint tells organizations to validate and test incident management capabilities by defining reportable security events, documenting decision-making and preserving forensic evidence. It instructs teams to:

“Capture and log all decisions, roles, and communications (5.26), and update the plan with lessons learned (5.27). Confirm that procedures are in place to preserve forensic evidence (5.28), including log snapshots, backups, and secure isolation of impacted systems.”

The same step explains A.5.28 in language every board should understand:

“what you can prove matters just as much as what actually happened”

Clarysec’s enterprise Evidence Collection and Forensics Policy reinforces that evidence must remain traceable:

“A chain-of-custody log shall accompany all physical or digital evidence from the time of acquisition through archival or transfer and shall document:”
From section “Governance Requirements”, policy clause 5.6.

For SMEs, the Evidence Collection and Forensics Policy-sme is deliberately practical:

“A forensic copy or export must always be created; the original evidence must never be edited directly.”
From section “Policy Implementation Requirements”, policy clause 6.1.1.

It also requires legal consultation where HR, legal or customer impact may exist:

“If the incident involves potential Human Resources (HR), legal, or customer impact, the GM must consult legal counsel before proceeding with enforcement or escalation.”
From section “Governance Requirements”, policy clause 5.4.2.

A practical evidence pack should be opened during Gate 2. Create a restricted incident evidence folder. Export SIEM timelines, EDR detections, cloud audit logs, identity provider sign-in logs, backup job status, ransom notes, screenshots, attacker messages, wallet addresses, file samples, legal advice references, insurer correspondence and meeting decisions. Assign a custodian. Record hash values where appropriate. Do not let administrators clean up impacted systems before forensic acquisition unless life safety, critical service protection or executive-approved containment requires it.

One classification worksheet for NIS2, DORA and GDPR

A ransomware incident can trigger multiple clocks. The challenge is not only knowing the deadlines. It is knowing when the organization became aware, what it knew at that time and how classification decisions were made.

NIS2 Article 23 requires essential and important entities to notify the CSIRT or competent authority without undue delay of significant incidents. Significance is linked to severe operational disruption, financial loss, or considerable material or non-material damage to others. The staged model includes early warning within 24 hours, notification within 72 hours, intermediate updates if requested and a final report within one month of the incident notification where applicable.

DORA requires financial entities to define and implement ICT-related incident management, record incidents and significant cyber threats, classify incidents using criteria such as affected clients, duration, geographic spread, data loss, criticality and economic impact, and report major ICT-related incidents to competent authorities through initial, intermediate and final reports.

GDPR asks a different but overlapping question: did the incident cause a personal data breach? If so, is it likely to result in a risk to individuals? If the notification threshold is met, supervisory authority notification must be assessed against the 72-hour clock. If high risk exists, communication to individuals may also be needed.

Clarysec recommends operating a single ransomware classification worksheet with separate sections for each regime.

This approach fits ISO 27001 clauses on risk assessment, risk treatment and documented information. It also aligns with NIST CSF 2.0. The NIST CSF 2.0 GOVERN function expects organizations to understand stakeholders, legal and regulatory obligations, risk appetite, roles, policy, oversight and third-party risk. Its detection, response and recovery outcomes support incident declaration, analysis, response coordination, stakeholder notification, recovery execution and restoration validation.

For financial entities, DORA may operate as the sector-specific cybersecurity regime for overlapping NIS2 obligations, but that does not remove the need to understand NIS2 applicability for group entities, ICT providers, managed services or cloud dependencies. The practical answer is not to maintain separate playbooks. It is to run one ISMS evidence model mapped to all relevant obligations.

Cyber insurance and supplier coordination are governance controls

Cyber insurance can be valuable, but it is not a ransomware strategy. It is a risk transfer mechanism with conditions. During a ransomware event, the insurer may require immediate notification, use of panel firms, prior approval for negotiation, preservation of evidence, proof of backup failure, proof of reasonable controls and legal review before any payment consideration.

DORA makes ICT third-party risk a first-class compliance domain. NIS2 Article 21 also requires supply chain security and consideration of supplier vulnerabilities and cybersecurity practices. ISO 27001 supports the same logic through supplier and cloud controls such as A.5.19 to A.5.23, plus incident, continuity and legal controls.

Zenith Controls links incident preparation to external partners, including forensic firms, legal, PR and contact with authorities. From an audit perspective, absence of pre-identified external partners may be viewed as a readiness gap because it can delay response during a real incident.

For ransomware payment governance, Clarysec recommends pre-negotiating:

• Forensic retainer or rapid response terms.
• Outside counsel availability for breach, sanctions and privilege strategy.
• Cyber insurer notification path and approved vendor list.
• Cloud provider escalation route for snapshots, logs, isolation and recovery.
• MSSP or MDR incident collaboration procedures.
• PR and crisis communications review process.
• Banking or finance approval controls for any extraordinary payment.
• Law enforcement contact protocol.

This maps well to NIST CSF 2.0 supply chain outcomes, including supplier roles and responsibilities, due diligence, contractual cybersecurity requirements, supplier incident coordination and post-termination activities.

A practical ransomware payment escalation playbook

The five gates can be translated into an operational playbook. Every step should be documented, owned and rehearsed.

The goal is not to guarantee a comfortable decision. There may be no comfortable decision. The goal is to ensure the decision is authorized, evidence-based, legally informed and defensible.

The 90-minute tabletop that proves readiness

The simplest way to test ransomware payment governance is not a technical red team. It is a decision tabletop.

Use Zenith Blueprint, Controls in Action phase, Step 23, to validate incident management capability. Select a ransomware scenario and run a timed exercise. The objective is not to decide in advance that the organization would pay or never pay. The objective is to prove that the organization can reach a governed decision.

Scenario: a cloud-hosted customer database is encrypted, the attacker claims exfiltration, backups exist but have not yet been integrity-tested, the insurer has not been notified, and the attacker provides a wallet address with a 48-hour deadline.

Exercise checklist:

• Declare the incident and assign the Incident Commander.
• Open the ransomware decision log.
• Classify the event using A.5.25 criteria.
• Identify affected assets and business services.
• Determine whether personal data is involved.
• Trigger GDPR, NIS2, DORA and contractual assessment workflows.
• Notify legal, DPO, executive management, insurer and forensic provider.
• Preserve evidence before destructive recovery actions.
• Check backup integrity and restoration options.
• Conduct sanctions screening before any negotiation.
• Record whether law enforcement consultation is required.
• Draft customer and regulator holding statements.
• Present decision options to the executive authority.
• Record decision, rationale, dissent, approvals and next actions.
• Schedule post-incident review and control improvement actions.

The output should be a complete evidence bundle: attendance list, timeline, classification worksheet, decision log, communications drafts, legal action items, insurer action items, backup findings and lessons learned. That bundle is audit gold because it shows governance operating before a real crisis.

How auditors and regulators will test the process

Auditors from different backgrounds will examine the same ransomware process through different lenses.

Zenith Controls provides detailed audit methodology for A.5.24, A.5.25 and A.5.31. For A.5.24, auditors examine the incident response plan, severity classifications, roles, contact lists, regulatory reporting instructions, exercises and external partner arrangements. For A.5.25, they review whether event classification criteria exist, whether alert handling records show investigation and escalation decisions, whether SIEM and threat intelligence are used, and whether DPO or legal teams are involved when personal data may be affected. For A.5.31, auditors look for legal registers, compliance mapping, evidence of review, internal audit coverage and senior management reporting.

The audit risk is not only that an organization paid or refused to pay. The audit risk is that nobody can prove how the decision was made.

From extortion to control improvement

Ransomware governance does not end when systems are restored. ISO 27001 expects continual improvement. A.5.27 learning from information security incidents is central to that expectation. DORA requires root-cause analysis and additional controls. NIS2 final reporting expects mitigation measures and likely root cause where applicable. GDPR accountability expects documentation of decisions and safeguards.

Every ransomware post-incident review should answer:

• Were reporting clocks identified correctly?
• Did the decision authority work as designed?
• Was legal and sanctions review early enough?
• Did insurer coordination help or delay the response?
• Were backups complete, segregated, restorable and tested?
• Were logs sufficient to assess access and exfiltration?
• Were suppliers responsive under contract?
• Were customer communications accurate and timely?
• Did executives receive the right information at the right time?
• Which controls, policies, contracts or training must change?

Those answers should update the risk register, Statement of Applicability, incident response plan, backup strategy, supplier contracts, communication plan and training program.

In the ISMS Foundation and Leadership phase, Step 5, Zenith Blueprint emphasizes external communication planning, including identifying customers, regulators, partners and the public, determining what and when to communicate, and defining who communicates. For ransomware, that step becomes the bridge between technical response and trust preservation.

Build the decision record before the ransom note

The best time to govern a ransom decision is before the attacker sets the deadline.

If your ransomware playbook does not define decision authority, legal review, sanctions screening, insurer approval, evidence preservation, NIS2 and DORA classification, GDPR breach assessment and board-level documentation, the organization has a governance gap waiting for a crisis.

Clarysec helps organizations build this capability into the ISMS using:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap for phased ISO 27001 implementation, risk treatment, communication planning and incident capability validation.
• Zenith Controls: The Cross-Compliance Guide for mapping ISO 27001 controls to NIS2, DORA, GDPR, NIST CSF, COBIT 2019, ISO/IEC 27035, ISO/IEC 27701, ISO/IEC 27005 and audit evidence.
• Clarysec enterprise and SME policies, including Incident Response Policy, Incident Response Policy - SME, Evidence Collection and Forensics Policy, Evidence Collection and Forensics Policy - SME, Governance Roles and Responsibilities Policy, Governance Roles and Responsibilities Policy - SME and Risk Management Policy.
• Practical ransomware tabletop templates, decision logs, legal escalation matrices, evidence packs and cross-compliance reporting worksheets.

Do not wait for the 3 AM call to discover who can decide. Review your incident response plan against Clarysec’s five gates, run a 90-minute ransomware payment tabletop, and build a sanctions-safe, audit-ready decision record that can stand up to regulators, insurers and your own board.