Accountability should sit with a coordinated incident command structure that includes executive leadership, legal, security, finance, and the impacted business owner. No single team should improvise payment decisions in isolation. A clear governance model is essential when attackers target one unit but demand enterprise scale money, because the response must align authority, risk appetite, and regulatory exposure.
Why cross-subsidiary ransomware payment decisions need explicit authority
Negotiability is not a technical judgment, it is a governance decision that sits at the intersection of law, finance, business continuity, and incident response. When a ransom hits one subsidiary but threatens shared services, the question becomes who can evaluate enterprise-wide exposure, not who is closest to the event. That authority needs to be pre-assigned before a crisis, or the decision becomes fragmented and inconsistent.
In practice, the accountable body must be able to weigh operational continuity against legal, ethical, regulatory, and reputational consequences. A subsidiary may be directly impacted, but the response can have consequences for the parent company, other business units, insurers, banks, and regulators. That is why the decision cannot be left to local management alone, even when the initial intrusion appears isolated.
The right model is usually a coordinated incident command structure with executive sponsorship and clear decision rights. The impacted business owner contributes operational context, security explains the compromise and likely blast radius, legal frames disclosure and sanctions concerns, finance addresses liquidity and fraud exposure, and leadership makes the final call within an agreed policy.
What makes a ransom demand “negotiable” across a group structure
Negotiability is less about whether a threat actor will talk and more about whether the organisation has a lawful, defensible, and strategically sound basis to engage. If a demand affects multiple legal entities, the analysis may differ by jurisdiction, contract, insurer expectations, and regulator reporting obligations. A payment that seems tolerable for one unit may be inappropriate when viewed against group-level exposure or precedent risk.
Subsidiary boundaries matter, but they do not automatically create separate decision islands. Common infrastructure, shared identity systems, central backups, and group treasury can turn a local incident into an enterprise event. The negotiability question should therefore be answered at the highest level that can see the full dependency chain and the likely downstream effects of paying, refusing, or delaying.
That is also why the decision should be documented as part of the incident record. The organisation needs to show who had authority, what facts were available, what options were considered, and why the final position was chosen. Without that record, later review becomes guesswork, and the enterprise can end up with inconsistent treatment of similar incidents.
How to structure accountability before a ransomware event
The cleanest model is a pre-approved decision matrix that distinguishes operational containment from payment authority. Security and incident response lead on evidence, containment, and recovery options. Legal reviews sanctions, reporting, and contract issues. Finance evaluates payment mechanics and business interruption exposure. Executive leadership or a delegated crisis committee owns the final decision, with the impacted business owner supplying the commercial impact assessment.
That structure works best when it is tested before an incident through tabletop exercises and escalation drills. If the first time people discuss negotiability is after encryption has already spread, the organisation will usually default to urgency rather than governance. The decision process should be explicit about thresholds, such as cross-entity impact, regulated data exposure, or loss of shared services, because those conditions change who must be involved.
Accountability also needs to survive organisational boundaries. A subsidiary may control local operations, but it should not independently commit the group to a payment strategy, communications position, or recovery path that affects other entities. The principle is simple: local teams can recommend, coordinate, and execute, but only the designated enterprise authority can decide whether the demand is negotiable.
Risk and Threat Considerations
Ransomware actors often exploit organisational fragmentation, especially when they see subsidiaries, regional units, or franchises with uneven control maturity. If each unit believes it can decide on its own, attackers gain leverage through speed, confusion, and inconsistent responses. A weak decision model also increases the chance of duplicate payments, poor legal review, or an escalation path that is too slow to protect shared services.
Failure mechanism: Authority is split across entities, so the incident becomes a series of local reactions instead of one controlled enterprise decision. That creates a gap where the wrong people may commit to payment, negotiate without context, or miss sanctions, insurance, and regulatory constraints.
Impact: The organisation can amplify cost, weaken bargaining position, undermine recovery strategy, and expose itself to governance failure after the incident. In a group structure, the damage is often not just the ransomware event itself, but the evidence that no one clearly owned the decision.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RR-01 — Roles, Responsibilities, and Authorities | Defines who owns incident decisions across the enterprise. |
| RS.CO-03 — Information Sharing | Supports coordinated response across subsidiaries and stakeholders. | |
| Recommendation — Assign ransomware negotiation authority to a documented incident command structure. Coordinate ransomware decision-making across legal, finance, security, and business leadership. | ||
| NIST SP 800-53 Rev 5 | IR-4 — Incident Handling | Requires defined incident handling processes and decision paths for major events. |
| IR-8 — Incident Response Plan | Requires preplanned response roles, escalation, and coordination. | |
| Recommendation — Use a formal incident handling process to govern ransom-related decisions. Predefine escalation and approval paths for ransom negotiation decisions. | ||
| ISO/IEC 27001:2022 | A.5.24 — Information security incident management planning and preparation | Calls for prepared incident response roles and decision structures. |
| A.5.26 — Response to information security incidents | Requires coordinated response to incidents across the organisation. | |
| Recommendation — Document who can authorize ransomware-related negotiations before an incident occurs. Route ransom response through a coordinated cross-functional incident process. | ||
Practitioner Guidance
What to prioritise: Define a named decision owner and an alternate before an incident, then specify when the decision escalates from subsidiary to group level. The trigger should be based on enterprise impact, not only on which business unit was encrypted.
What to verify: Confirm that legal, finance, security, and the impacted business owner all have a seat in the process, and that the final authority is explicitly recorded in the incident response plan. If the plan cannot answer who decides, it is not ready.
Decision rule: If the demand could affect multiple legal entities, shared infrastructure, or regulated obligations, treat negotiability as an enterprise question and require executive-level approval before any commitment is made.
Practitioner takeaway: The key control is not deciding faster, it is deciding through the right authority structure so that any negotiation reflects the full organisational risk, not just the pressure on one business unit.
Related resources from NHI Mgmt Group
- Who is accountable for protecting identity data when access is granted across partners and internal business units?
- Who should be accountable for deciding whether data can be used in a business process?
- What do teams get wrong about deciding whether to pay a ransomware demand?
- What breaks when eSignature channels differ across business units?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
