The CPS 234 72-Hour Notification Runbook on AWS

CPS 234 requires you to notify APRA no later than 72 hours after becoming aware of a material information-security incident. Most teams treat that as a policy paragraph. It isn't — it's an engineering problem: how does a real signal from your AWS environment reach a human who can make the materiality call, fast enough and reliably enough to prove it later?

Here's the runbook, built on AWS primitives and — critically — tested before you need it.

Practitioner guidance, not legal or audit advice. "Material" is a judgement your entity defines; this covers the technical path, not the legal threshold.

The path: signal → triage → decision → notify

GuardDuty / Security Hub finding
        │  (severity ≥ threshold)
        ▼
   EventBridge rule
        │
        ▼
   SNS topic  ──►  on-call (PagerDuty/Opsgenie/email/SMS)
        │
        ▼
   Incident Manager  ──►  triage + materiality call
        │
        ▼
   If material: notify APRA within 72h (documented)

1. Detect: route severity, not noise

You don't want every GuardDuty finding paging someone at 3am. Filter on severity in the EventBridge rule:

{
  "source": ["aws.guardduty"],
  "detail-type": ["GuardDuty Finding"],
  "detail": { "severity": [{ "numeric": [">=", 7] }] }
}

Do the same for Security Hub findings at CRITICAL/HIGH. Severity 7+ on GuardDuty is the usual "wake someone up" line — tune to your environment.

The rule targets an SNS topic that fans out to your on-call tool and a security distribution list. SNS delivery logs are also your evidence that the path fired — keep them.

3. Triage: a human makes the materiality call

Automation routes; it doesn't decide. Systems Manager Incident Manager gives you a structured response: a timeline, response plan, and the record of who decided what and when. That timeline is gold in an APRA review — it shows a disciplined response, not a scramble.

4. Notify: the documented step

If the incident is judged material, the 72-hour clock (from awareness) is running. The runbook should name: who notifies APRA, the channel, the template, and where the record is filed. This step is human and procedural — but it must be written down before the day you need it.

The part everyone skips: test it

An untested notification path is not evidence — it's a hope. Run a game-day:

Generate a sample GuardDuty finding (GuardDuty has a create-sample-findings API).
Confirm the EventBridge rule fires and SNS delivers to on-call.
Walk the Incident Manager response plan end to end.
File the test result — that is what you show an auditor.

aws guardduty create-sample-findings \
  --detector-id <detector-id> \
  --finding-types "UnauthorizedAccess:EC2/SSHBruteForce"

Where this fits in CPS 234

This is the operational end of the CPS 234 control mapping — clauses 23–26 (incident management) and 35–36 (APRA notification). The evidence an auditor asks for here is the runbook plus the EventBridge→SNS delivery logs proving the path works. Build it, test it, file the result.

Primary sources: APRA CPS 234 · GuardDuty sample findings