Risk, resilience and compliance · Incident response · Regulatory notification
A detection and response design that starts the right notification clocks from one incident record: materiality assessment against tolerance levels, pre-drafted regulator forms, approvals, evidence capture and a post-incident review that feeds back into the risk register.
A reference architecture from EITSAA, not a named client system. Service limits, prices and product features change, so confirm current details before you commit to a design.
Cloud audit logs, endpoint sensors and identity events stream to a SIEM. Detections are enriched with asset criticality, so an alert on a system behind a critical operation ranks above the same alert elsewhere.
A correlated detection opens a single incident record with the time the organisation became aware. That timestamp matters, because several obligations run from awareness.
Service-level probes report when a critical operation moves outside its tolerance. This is an incident trigger even when no security alert exists, such as an outage caused by a provider.
The on-call responder triages, contains the incident and records actions in the same record. Responders do not work in side channels that later have to be reconstructed.
A structured materiality assessment asks the questions that decide which obligations apply: Did a critical operation exceed its tolerance? Was personal information accessed? Did it involve a critical infrastructure asset? Was a payment made to an extorting party? Is a service provider involved?
The result starts the relevant clocks. The workflow shows the earliest deadline and who owns each one, because several notifications can apply to the same event.
Pre-drafted notification content is generated from the record: what happened, when it was found, impact, actions taken and expected recovery. It reduces time spent writing and keeps facts consistent across regulators.
An executive approver and legal adviser review the drafts. The decision, time and reasoning are stored. Where facts are incomplete, an initial notification is made and updated rather than waiting.
Notifications go to APRA through its published forms where the entity is APRA-regulated. APRA has stated that a single notification is sufficient where an incident is notifiable under both CPS 230 and CPS 234, with the earliest timeframe applying.
Where the entity is responsible for a critical infrastructure asset, cyber incidents are reported to ASD's Australian Cyber Security Centre. A ransomware or cyber extortion payment is reported within 72 hours if the entity is in scope.
Where the incident is an eligible data breach, the entity notifies the OAIC and affected individuals as soon as practicable, and communications are coordinated with customers and the media team.
| Component | What it does | Why this choice |
|---|---|---|
| SIEM with asset criticality | Correlates events and prioritises by the criticality of what is affected. | Notification obligations depend on impact on critical operations and information assets. |
| Service-level probes | Detect operations outside tolerance regardless of cause. | A tolerance breach is notifiable even if the root cause is not a cyber attack. |
| Incident record | Timeline, decisions, evidence and links. | One record prevents inconsistent statements to different regulators. |
| Materiality assessment form | Decision aid for which obligations apply. | Consistent, reviewable decisions made in stress. |
| Notification clock | Computes deadlines for each obligation from awareness times. | Several clocks run at once with different start points and units, including hours and business days. |
| Pre-drafted templates | Prefilled content for each recipient. | Time saved in the first hours, with facts tied to the record. |
| Approval workflow | Sign-off and legal review with audit trail. | Accountability stays with a named executive. |
Who decides materiality
Why. Decisions made under pressure need a repeatable method and clear authority.
Trade-off. A conservative rubric produces some notifications that later prove unnecessary. That cost is usually lower than a missed deadline.
When the clock starts
Why. Regulators' wording differs, for example awareness, determination or suspicion.
Trade-off. Recording the time creates a visible date, but hiding it creates a bigger risk.
Initial notification with updates
Why. Waiting for full certainty often misses deadlines.
Trade-off. Early notices can be incomplete and need careful wording.
Single tool or several
Why. Avoids copy and paste across systems and conflicting timelines.
Trade-off. Requires integration work and discipline to use it.
Rehearsal
Why. The first time you fill in a form should not be during a real incident.
Trade-off. Time to prepare scenarios and brief executives.
The incident record and drafts are access-controlled, because they hold sensitive facts. Responders use dedicated, monitored accounts, and out-of-band communications are available if email is compromised.
The workflow runs outside the environment it monitors, with an offline copy of runbooks, contacts and forms.
Automation targets the first hour: enrichment, record creation, clock calculation and template population.
Tune detections to cut noise, keep retention aligned to what investigations need and use managed detection where in-house cover is thin.
Roster on-call, drill quarterly, keep contacts and regulator details current and review each incident for process gaps.
Retain detailed telemetry for the periods required, then tier or delete.
Detection sources send logs over private paths to a security account. The incident workflow and its runbooks have an independent access path, so responders can work while the primary network or identity provider is degraded.
Responders use privileged roles with just-in-time elevation. A separate, tested emergency channel exists. Executives who approve notifications are named, with deputies, and are reachable out of hours.
Incident records contain personal and security information. Restrict access, retain according to legal and records obligations and be careful about what is copied into email or chat. Preserve forensic evidence with chain of custody.
| Control | How this design addresses it |
|---|---|
| Operational risk incident notification | Notify APRA as soon as possible and not later than 72 hours after becoming aware of an incident determined to be likely to have a material financial impact or a material impact on critical operations. CPS 230. |
| Tolerance breach notification | Notify APRA as soon as possible and not later than 24 hours after a disruption to a critical operation outside tolerance. CPS 230. |
| Information security incident and weakness notification | Notify within 72 hours of becoming aware of a material incident, and within 10 business days of a material control weakness not expected to be remediated in a timely way. CPS 234. |
| Critical infrastructure cyber incidents | Report critical incidents within 12 hours and other incidents within 72 hours of becoming aware, with written follow-up after oral reports. SOCI Act. |
| Ransomware payment reporting | Report a ransomware or cyber extortion payment within 72 hours where the entity is in scope. Cyber Security Act 2024. |
| Eligible data breaches | Assess suspected breaches promptly (within 30 days), and notify the OAIC and affected individuals as soon as practicable once an eligible breach is confirmed. Privacy Act NDB scheme. |
Mappings show how the design supports each control. They are not certifications, and EITSAA does not claim IRAP assessment or compliance for any reference architecture.
| Failure mode | Mitigation |
|---|---|
| Awareness time disputed or unclear | Record it in the incident record at creation, with source evidence, and review with legal. |
| The tool you use to report is down | Offline copies of runbooks, contacts and form content, and an out-of-band channel. |
| Different facts sent to different regulators | One incident record generates all notifications and edits are tracked. |
| Third-party incident not passed on | Contracts require prompt notification from service providers, and probes catch impact even without a notice. |
| Overlooked obligation | The materiality form asks about every regime in scope, reviewed annually. |
| Approval bottleneck | Delegated authority with deputies, and pre-agreed wording for early notifications. |
SIEM ingestion, detection engineering, on-call, exercises and legal review.
API security · Tokenisation · Zero trust
A controlled edge for partners, fintech suppliers and SaaS platforms that need regulated data. Each partner is authenticated, authorised per scope, rate limited and logged, sensitive fields are tokenised, and everything is encrypted with keys you hold.
AWS · CPS 230 · Resilience
A technical design that traces each critical operation to the services behind it, sets recovery capability from tolerance levels, replicates to a second region, and proves the result through game days and continuous service-level monitoring.
Multi-cloud · Exit planning · CPS 230
How to depend on cloud, SaaS and AI providers without being trapped by them: a provider register tied to critical operations, a portability layer you own, tested data export and a second-provider path for the services that matter most.
Tell us your systems, constraints and timeline. We reply within one business day, and the initial conversation is free.