How to Write a Cyber Incident Report for Regulators and Insurers

After a cyber incident, the organisation faces at minimum two reporting obligations that sit outside the internal debrief: a report to the regulator and a report to the insurer. These are often treated as similar documents with the same content, which leads to problems. A regulator and an insurer are different audiences with different interests, different legal frameworks, and different questions. A report that works for one does not automatically work for the other. Understanding what each audience needs before you start writing saves significant time and avoids the risk of making statements to one audience that create problems with the other.

The internal post-incident review is a separate document again. It is written for the organisation's own learning: what went wrong, what worked, what needs to change. It can be candid in ways that external reports cannot. The internal review may be legally privileged if conducted under legal advice, which is worth considering before you begin. Conflating the internal review with the regulatory or insurance report creates documents that serve none of their purposes well and may inadvertently disclose information that should remain protected.

What a Regulatory Report Needs

Regulatory incident reports in Australia are primarily governed by the Notifiable Data Breaches scheme under the Privacy Act for personal information incidents, and by sector-specific frameworks for entities regulated by APRA, ASIC, or the Australian Signals Directorate. Each framework has its own content requirements, but the common elements are: a description of what happened, the date the incident occurred and when it was discovered, what personal or sensitive data was involved, who was or may have been affected, what steps have been taken to contain the incident and prevent recurrence, and contact details for follow-up inquiries.

Regulators are not primarily interested in your technical investigation findings. They are interested in whether you know what happened, whether affected individuals or entities need to be notified, and whether your response was adequate. The report should be factual, specific about dates and data types, and honest about uncertainty where it exists. "We have not yet determined the full extent of data accessed" is an acceptable statement if it is accurate and accompanied by a description of your ongoing investigation and a timeline for further reporting. Stating facts that are later contradicted by investigation findings creates a compliance problem on top of an incident.

What an Insurance Report Needs

Your insurer's requirements will be specified in your policy and may include a specific notification form. Read the policy before you write anything for the insurer. The key elements typically required are: the date and nature of the incident, the systems and data involved, the business impact including system downtime and financial losses, the response actions taken, and the costs incurred to date. The insurer uses this information to assess coverage, engage approved vendors if required, and begin the claims process.

Insurance reports benefit from precise quantification. Downtime hours, affected system counts, data volumes, staff hours spent on response, vendor costs. These numbers support the claim. Vague descriptions of "significant impact" without supporting data create disputes at the claims stage. If you cannot yet quantify elements of the impact because the investigation is not complete, note that explicitly and provide an updated report when the numbers are available. Insurers also want to see evidence that you took reasonable steps to contain and remediate the incident, because some policies have requirements around reasonable response measures.

Structuring a Report That Satisfies Both Audiences

Given the different requirements, the practical approach is to produce a master incident timeline and factual summary that serves as the source document for both reports, then tailor each report for its specific audience. The master document records: the chronological sequence of events, the systems and data confirmed affected, the response actions taken with dates and responsible parties, the evidence collected and investigation findings, and the remediation steps completed or in progress. This document is the factual record of the incident. It does not include speculation, mitigation strategy debates, or legal advice.

From that master document, the regulatory report draws the facts required by the relevant framework, framed in the language and structure the regulator expects. The insurance report draws the quantifiable impact data and response cost information the insurer needs. Legal counsel should review both reports before submission, because statements in regulatory reports may be used in enforcement proceedings, and statements in insurance reports are representations that affect coverage. The coordination between your DFIR firm, your legal team, and your insurance broker in the reporting phase is as important as the response itself.

Common Mistakes in Incident Reporting

The most common mistakes we see in incident reports are: overstating certainty about what happened before the investigation is complete, understating the scope of affected data because early estimates turn out to be too conservative, using vague language that creates ambiguity about whether notification obligations are triggered, and including internal deliberations or blame that have no place in an external report. Each of these creates a problem down the track. Regulatory reports that overstate certainty must be corrected, and corrections require explanation. Insurance reports with underestimated scope leave money on the table or create coverage disputes.

The other common mistake is late reporting. The NDB scheme requires notification within 72 hours of becoming aware of an eligible data breach. Many organisations are aware of the breach long before they have completed their investigation, and they delay reporting because they want to be certain about the scope before they notify. The obligation to notify is triggered by awareness, not by certainty. You can notify with the information you have and supplement that notification as your investigation progresses. Waiting for certainty before notifying is a compliance risk.

We support organisations through the reporting phase of incident response, including providing investigation findings in formats suitable for regulatory and insurance reporting and coordinating with legal counsel on report content. Contact us at info@cyberlinx.com.au for post-incident reporting support.