Ransomware response, CPS 230, and the 24-hour decision

If your organisation has a ransomware playbook, it almost certainly covers the technical response — the isolation, the forensic capture, the containment. What it probably doesn’t cover well, in our experience reviewing playbooks across mid-market financial services, is the decision architecture — who decides what, on what evidence, in what time window, when the incident is in progress.

The technical work is the easier half. The harder half is what the executive will be asked at hour 6 and hour 24, with a partial picture, with adversaries actively negotiating, with operations degrading, with media interest building. If your organisation hasn’t actually decided how to make those decisions before the incident, it will make them badly during.

This post is the decision architecture, mapped to CPS 230 obligations for APRA-regulated entities. It is operationally focused; the technical playbook is a separate document.

The decisions your executive will face

In approximate chronological order during a ransomware event:

Hour 0–2: contain or operate. Initial detection. Some systems are clearly compromised; others may be. The decision is whether to broadly isolate (containing the spread, but losing operational capability) or to selectively isolate (preserving operations, accepting potential further spread). The default in most playbooks is broad isolation. The actual right answer depends on the operational tolerance and the spread vector — an answer that needs to be considered before the incident, not during.

Hour 2–6: notify. Internal notification protocols, regulatory notification timing (CPS 234 paragraph 35 within 72 hours of becoming aware; OAIC for personal data within 30 days but real-time pressure is much shorter; ASIC, ASX where applicable), customer notification position. The default for most organisations is delay until we understand the scope. The strategic right answer often involves earlier notification, accepting incomplete information, to preserve credibility. This is a choice the playbook should help structure.

Hour 6–24: communicate. Public position. Customer communication. Staff communication. Vendor communication. Each constituency has different needs and timing. The decision is on tone, content, and channel. Pre-positioned templates help; the strategic positioning does not template well.

Hour 24–72: pay or not. Ransom decision. The marketing answer is never pay. The actual decision is more complex — depends on the integrity of backups, the operational urgency, the legal exposure (sanctions, anti-money-laundering), the insurance position. The right answer involves the CEO, the board, legal, the insurer, and increasingly law enforcement (AFP and ACSC engagement). The decision needs structure beforehand: who decides, on what evidence, with what authorisation.

Hour 72+: recover. Restoration sequence, validation that restored systems are clean, return to normal operations, lessons captured. This is closer to a project than a crisis.

CPS 230 obligations during the event

For APRA-regulated entities, CPS 230 imposes specific obligations during operational incidents:

• Critical operations: incidents affecting critical operations require notification per the framework. The threshold is material impact; ransomware almost always meets it.
• Service provider arrangements: where the incident affects material service providers (or originated through them), the service provider notification clauses are triggered.
• Tolerance breach: incidents that exceed the documented tolerance for disruption are themselves reportable as governance events.
• Regulator notification: APRA notification timing is 72 hours from awareness for material operational risk events. The clock starts when you become aware, not when you confirm.

The CPS 230 specifics are usually well-covered in playbooks. The CPS 234 paragraph 35 obligation (information security incidents within 72 hours) is the one most often confused — it’s a separate notification with a different threshold, and ransomware typically triggers both.

The decision architecture

The structure that converts the chaos into navigable decisions:

1. Pre-defined incident roles

Named individuals with documented authority for the duration of the incident:

• Incident Commander: makes operational decisions during the response. Typically the CISO or a senior incident response lead. Has authority to direct technical response, declare incident severity, request resources.
• Executive Sponsor: holds strategic authority. CEO or COO. Makes payment/non-payment decisions, public communications decisions, decisions involving material business impact.
• Communications Lead: owns external messaging. Senior communications role.
• Legal Lead: privilege management, regulatory notification, contract analysis.
• Customer Lead: customer communication and remediation.
• Technical Lead: forensic and recovery work.
• Risk Lead: regulatory engagement, internal governance reporting, board liaison.

Each role has a deputy. The deputies are also named, also briefed, also have documented authority.

2. Decision triggers

Pre-decided triggers that escalate decisions to the appropriate role:

• Isolation of a critical operation → Incident Commander notifies Executive Sponsor.
• Loss of more than X hours of operations → Executive Sponsor convenes Crisis Committee.
• Confirmed customer data exposure → Privacy Officer + Legal + Communications.
• Ransom demand received → Crisis Committee + Legal + Insurer.
• Ransom payment under consideration → Crisis Committee + Board Chair + AFP/ACSC engagement + Legal opinion on sanctions.
• Public disclosure decision → Communications + Legal + Executive Sponsor + Board Chair if material.

The triggers are pre-defined so that during the incident, the question is what trigger applies rather than who do I escalate to.

3. Pre-committed positions

Some decisions can be made before the incident. The pre-commitments documented in the playbook:

• Backup posture and isolation: backups are isolated such that ransomware that encrypts production cannot reach them. This is a technical control documented in the playbook.
• Communication-with-attackers position: do we engage with attacker negotiation? In what circumstances? With what authorisation?
• Insurance notification timing: insurer is notified within X hours of incident declaration, not at the end.
• Legal counsel engagement: external counsel is engaged at incident declaration; privilege is established.
• Law enforcement engagement: AFP via the ACSC ReportCyber pathway is engaged within X hours; this does not commit to involving them in the response, but ensures the option is available.
• Public disclosure default: in the absence of a specific contrary decision, the default is timely disclosure once the scope is reasonably understood.

These pre-commitments turn 24-hour decisions into 1-hour decisions during the actual incident.

4. Crisis Committee composition and cadence

For incidents above a defined severity:

• A Crisis Committee is convened.
• Composition is pre-defined: Executive Sponsor, Incident Commander, Legal, Communications, Customer, Risk, plus optional roles.
• Cadence is every 2 hours during the first 24 hours, then 4 hours, then daily.
• Each meeting has a structured agenda: status, decisions required, actions, risks.
• Minutes are kept (privileged and confidential).

The Crisis Committee is the room where the decisions get made. Without it, decisions get made in disjointed conversations across multiple channels and the audit trail of the response is fragmented.

Tabletop exercise priorities

If your organisation conducts tabletop exercises and they cover only the technical response, they’re under-using the format. The exercises that improve real-world readiness exercise the decision architecture:

• The Incident Commander encounters a decision that is above their authority — what do they do? Do they reach the Executive Sponsor? In what time? With what evidence?
• The Executive Sponsor is presented with a payment-or-not decision at hour 36, with backups partially restored, with insurance position uncertain, with operational pressure high. How is the decision actually made? Who is in the room? What evidence is available?
• A media inquiry arrives at hour 4. The Communications Lead is on annual leave. What happens? Does the deputy know they’re the deputy?

These exercises are uncomfortable because they reveal gaps. That’s the point.

A practical first move

If your organisation has a ransomware playbook that focuses on technical response, the next addition is the decision architecture. Document the named roles, the deputies, the decision triggers, the pre-committed positions, the Crisis Committee composition. Run one tabletop that exercises the decision flow rather than the technical flow.

For organisations that need this work done as part of broader CPS 230 readiness, the Security Posture Assessment covers incident response architecture; engagements that specifically uplift the playbook and run tabletops are scoped under the Fractional Officer or as standalone advisory work.