Incident and breach registers: capturing, escalating and closing compliance events

One register, not five

Keep a single incident and breach register with a category field, rather than separate registers for safety, privacy, financial services and complaints. The reason is not tidiness. It is that most compliance events cross categories, and separate registers systematically lose the ones that do.

A stolen laptop is a security incident, a potential eligible data breach, and possibly a work health and safety matter if it happened during a break-in. A payroll error is a wage compliance issue, a superannuation issue and a record-keeping issue. Logged in one register with multiple category tags, the event has one clock owner and one closure. Logged in three registers, it has three partial records and no owner.

The register also serves as the population listing for testing event-driven controls, which is why the monitoring and assurance plan reads from it directly.

The fields every incident record needs

The register earns its keep through the timestamp fields. Most notification obligations run from awareness, and awareness is a fact that must be recorded at the time — reconstructing it later is unpersuasive.

The notification assessment field is the one auditors read first. Recording a reasoned decision not to notify is far stronger than a blank field, and it is the difference between a considered judgement and an oversight.

The clocks that start when an event is logged

Several Australian regimes attach timeframes that run from awareness or suspicion. The register should calculate the due date at logging, not at triage.

Two design rules follow. First, the clock owner must be a named individual with a deputy, because clocks run over weekends and leave periods. Second, the register must be able to record a clock that was missed, with the reason. A register that cannot represent failure will be quietly edited when failure occurs.

For cross-regime events, the cyber incident notification tree maps which notification duties a single security incident can trigger simultaneously.

Triage and escalation thresholds

Triage assigns a severity within a defined window — commonly one business day of logging for standard events and immediately for anything with a running clock. Severity drives escalation, and the thresholds should be written into the compliance policy rather than decided case by case.

Near misses belong in the register. They are the cheapest available source of control intelligence, and organisations that log only realised breaches lose the leading indicator entirely.

Escalation should be recorded in the register itself with a date and recipient, so the board reporting record and the incident record agree.

Root cause, remediation and closure

Closure is the weakest part of most registers. Three disciplines fix it.

Root cause must be a cause, not a restatement. "Staff member did not follow the procedure" is an observation. The cause is why: the procedure was ambiguous, training was not refreshed after a change, the system permitted the action, the workload made the control impractical, or accountability was unclear. Categorising root causes consistently is what makes trend analysis possible.

Remediation must have an owner senior enough to deliver it. Assigning a systemic fix to the person who made the error guarantees a documentation-level response to a design-level problem.

Closure requires verification and a second approver. Verification is evidence the fix worked — a re-test, a sample after the change, a system configuration screenshot retained on file. The approver should not be the person who performed the remediation. Without those two steps, "closed" means "we stopped talking about it".

Where remediation involves customer remediation or repayment, keep that as a separate tracked workstream with its own completeness evidence. Partial remediation that was recorded as complete is a recurring finding in Australian enforcement outcomes.

Retention: how long records must be kept

Retention runs from the record type, not from the incident date, and the longest applicable period governs.

• Work health and safety. Under section 38(7) of the model WHS Act, a person required to notify must keep a record of each notifiable incident for at least five years from the date notice is given to the regulator; failure to do so is an offence (checked August 2026). See Safe Work Australia's incident notification guidance and the model WHS Act. State and territory implementations should be confirmed individually.
• Privacy. The Privacy Act 1988 does not set a single retention period for breach records, but retaining the assessment reasoning is what evidences compliance with the assessment obligation. OAIC's data breach preparation and response guidance sets out the expected response steps.
• Corporate and financial records. A seven-year retention expectation applies to many Australian corporate and tax records; see /obligations/records-retention-7-years.
• Sector schemes. Aged care, NDIS, financial services and education schemes each carry retention requirements attaching to incident documentation.

Set the register's own retention to the longest applicable period across the categories it holds, and never delete a record while related remediation, litigation or regulator engagement remains open.

Reading the register for trends

A register that is only ever read one row at a time is a filing cabinet. Quarterly, run five analyses and put the results in the board pack:

1. Volume by category over time. A falling count is as likely to mean under-reporting as improvement; read it alongside the ratio of near misses to realised breaches.
2. Time from discovery to logging. The clearest single measure of whether the reporting culture works.
3. Time from logging to assessment decision. Where notification clocks are being consumed.
4. Root cause distribution. Concentrations point at design problems rather than individual error.
5. Repeat events against the same obligation ID. The strongest argument for control redesign, and the metric regulators most often ask about.

Where the same obligation ID appears repeatedly, the correct response is a design test of the control rather than another round of retraining — see compliance monitoring and assurance plans.