Data Breach in Australia: Who Do You Need to Tell, and When?

By BCyber Security Team | CISSP, CISM Last updated: 9 October 2026

If you’ve had a data breach, the first question is not “how bad does this look?” but “is it a notifiable data breach under Australian law, and who must be told?” In practice, the answer depends on whether the incident is likely to cause serious harm, what information was involved, and whether containment happened quickly enough to remove the risk. Depending on the facts, you may need to notify the OAIC, affected individuals, your board or executive team, a sector regulator such as APRA, and sometimes contractual counterparties.

For Australian organisations, this is rarely just a privacy task. A breach response typically touches privacy, incident response, legal, communications, and governance simultaneously. That is why BCyber’s response methodology maps closely to the control environment inside GRACE Portal for unified visibility, Paradigm for compliance mapping, CyberTriage for rapid incident triage, and Profiler for behavioural analysis where insider activity or account abuse is suspected.

The reporting question is not “Did something go wrong?” It is “Has personal information been exposed in a way that is likely to cause serious harm, and has remediation actually reduced that risk?”

What counts as a reportable data breach?

A data breach is any event involving unauthorised access to, unauthorised disclosure of, or loss of personal information. That can include an email sent to the wrong recipient, a compromised mailbox, a stolen laptop, a ransomware event, a misconfigured cloud bucket, or an exposed API returning customer records. Under the Privacy Act 1988 and the Notifiable Data Breaches (NDB) scheme, not every breach is automatically reportable; the legal test turns on likelihood of serious harm.

In operational terms, that means your team has to answer three questions quickly:

1. Was there unauthorised access, disclosure, or loss of personal information?
2. Is the breach likely to result in serious harm?
3. Has reasonable remedial action reduced or removed that risk before notification is required?

That framework is consistent with the way security teams already investigate incidents under NIST CSF and ISO/IEC 27001: establish scope, determine impact, validate containment, and document decisions. It is also how many organisations run their breach workflow inside BCyber’s GRACE Portal, where compliance tracking, executive reporting, and cross-product analytics help ensure the legal decision is tied to evidence rather than intuition.

What the threshold usually turns on

• The type of information involved.
• Whether the data was merely exposed or actually accessed.
• Whether the data was encrypted, redacted, or otherwise protected.
• Who obtained the information and what they are likely to do with it.
• Whether containment happened fast enough to remove the risk.

Serious harm is broader than financial loss. It can include identity theft, fraud, humiliation, workplace harm, reputational damage, emotional distress, and in some cases physical safety concerns. For example, a breach involving a public newsletter list is not equivalent to one involving passport details, tax file numbers, My Health Record-related information, bank account credentials, or privileged internal government documents. Under ASD Essential Eight, strong application control, patching, MFA, and backups may reduce breach likelihood, but they do not automatically remove reporting obligations once personal information has been exposed.

A few real-world Australian scenarios

• Financial services / APRA-regulated entity: A superannuation fund detects credential stuffing against a member portal. If attackers accessed account balances, TFNs, or bank details, the incident may trigger both NDB analysis and APRA CPS 234 reporting obligations, depending on materiality and impact.
• Healthcare provider: A clinic accidentally exposes pathology results in a shared drive. Even if the data was only accessible for a short period, health information is highly sensitive, so the serious-harm assessment will usually be more conservative.
• Government or outsourced service provider: A contractor handling citizen records loses an unencrypted laptop. If the device contains identity data or case notes, the organisation may need to notify the OAIC, brief the agency customer, and follow contractual incident clauses.

BCyber’s Privacy in Depth approach is designed for this exact kind of multi-obligation decision-making, where privacy, cyber, and operational risk overlap.

What should you do first after discovering it?

The first hour matters because good containment and good evidence preservation often shape the notification decision later. The instinct to “fix it fast” is understandable, but changing too much too early can destroy the evidence needed to understand scope, root cause, and likely harm. Start by stabilising the environment, then move into assessment.

A strong response aligns with incident response practices in NIST SP 800-61 and the investigation discipline expected under ISO 27001. In BCyber’s CyberTriage workflow, that means rapid triage first, then targeted containment, then forensic analysis and reporting.

Begin with immediate containment:

• Disable compromised accounts.
• Reset passwords and revoke tokens.
• Invalidate active sessions and refresh API keys where relevant.
• Isolate affected endpoints or servers.
• Block suspicious network paths or firewall rules where appropriate.
• Preserve mailbox state or cloud audit logs before aggressive remediation.

If the incident involves email, preserve headers, forwarding rules, inbox rules, and audit trails. If it involves cloud storage, capture sharing settings, access logs, and external link history. If it involves a lost device, determine whether full-disk encryption, MDM controls, and remote wipe were enabled. If you suspect insider activity, behavioural anomalies in login timing, download volume, or privilege escalation may be useful signals; that is where Profiler can support access pattern monitoring and risk scoring.

Preserve evidence as if a regulator, insurer, or court will later ask you to prove each decision. Keep:

• logs and timestamps,
• account and access records,
• email headers,
• screenshots,
• file hashes,
• incident notes,
• remediation steps,
• and the name of the person who approved each action.

BCyber’s platform inventory includes 9 processes and 23 policies, and those governance artefacts matter during a breach because they help prove that the organisation followed a documented response path rather than improvising under pressure.

A practical triage sequence

1. Contain the exposure or compromise.
2. Preserve logs, records, and timestamps.
3. Identify the data involved.
4. Assess the likelihood of serious harm.
5. Decide whether notification is required.
6. Document the rationale and next steps.

When do you need to notify the OAIC?

If the incident meets the threshold for a notifiable data breach, the OAIC must be notified under the NDB scheme. That notification is not optional once you have reasonable grounds to believe a breach is likely to result in serious harm and the risk has not been neutralised by remedial action.

The OAIC expects a notification that explains what happened, what kinds of personal information were involved, how the breach occurred, what steps you have taken, and what individuals can do to protect themselves. If the facts are still unfolding, you can still notify while continuing the investigation. The legal standard is as soon as practicable, not “after every last question has been answered.”

In practice, organisations often align this process through a compliance workflow. In Paradigm, for example, compliance mapping can help connect the incident to the applicable legal and regulatory obligations, while GRACE Portal gives executives visibility over the notification status, remediation progress, and evidence trail.

What the OAIC notification should cover

• A description of the incident.
• The kinds of information involved.
• The number or approximate number of affected people.
• The steps already taken to contain the breach.
• Recommendations for affected individuals.
• Contact details for follow-up.

Useful government resources:

• OAIC Notifiable Data Breaches scheme: https://www.oaic.gov.au/privacy/notifiable-data-breaches
• Privacy Act 1988 (Cth): https://www.legislation.gov.au/Series/C2004A03712
• OAIC Guide to Securing Personal Information: https://www.oaic.gov.au/privacy/guidance-and-advice/guide-to-securing-personal-information

Do you have to tell affected individuals?

In many cases, yes. If the breach is likely to result in serious harm to one or more individuals, those individuals generally need to be told directly if practicable. The notice should help them protect themselves, not just satisfy a regulatory requirement.

Direct notification can happen by email, letter, SMS, phone, or another method that is reasonably effective for the situation. The method should reflect the urgency, the contact details you have, and the sensitivity of the data. If the affected population is small and contactable, direct notice is usually the cleanest path. If people cannot be contacted directly, the law allows alternative notification in some cases, including public notice combined with OAIC notification.

A practical example: in a healthcare setting, a clinic might need to notify patients whose referral letters or diagnostic results were exposed. In a financial services setting, a bank may need to tell customers if account access details, card data, or identity credentials were involved. In government, the impact may be broader because exposed records can create downstream fraud or impersonation risk.

The content should explain what happened, what information was involved, what the organisation has done, and what the person should do next. If the incident involves banking or identity documents, advice might include monitoring statements, changing passwords, contacting their bank, or watching for phishing attempts. If health information was involved, the communication needs to be careful and plain-language, because the impact can include distress as well as privacy exposure.

If the affected person cannot understand the notice, they cannot use it to protect themselves. Clarity is part of the response, not a cosmetic extra.

Good individual notices usually answer four questions

• What happened?
• What information was involved?
• What should I do now?
• What has the organisation already done?

Could another regulator or contract also require notification?

Yes. This is where many organisations underestimate the problem.

The OAIC is only one possible notification pathway. Sector regulation and contracts can add their own reporting duties. For example:

• APRA CPS 234 requires APRA-regulated entities to maintain information security capability and notify APRA of material information security incidents in line with prudential expectations.
• ASD Essential Eight does not create a reporting obligation by itself, but it is often used as the security baseline that organisations are expected to operationalise.
• Critical infrastructure, health, education, telecommunications, and government supply chains may have separate contractual or regulatory notification requirements.

One breach can therefore create multiple clocks, not just one. If you only check privacy law, you may miss a prudential, contractual, or government reporting deadline. BCyber’s GRACE Portal is designed to centralise that visibility with executive reporting and compliance tracking so legal, security, and operations teams can work from the same timeline.

Common reporting streams to check

• OAIC notification under the NDB scheme.
• APRA reporting for regulated entities.
• Contractual notice to customers, suppliers, or government agencies.
• Internal board or risk committee escalation.
• Cyber insurance notice requirements.
• Law enforcement notification where criminal activity is suspected.

How do you judge serious harm without guessing?

The serious-harm test is contextual, which means you should evaluate the facts rather than search for a universal shortcut. Start with the information itself. Some data is low risk if exposed briefly, while other data can become dangerous quickly even if only a small amount was involved. Personal details, authentication credentials, financial records, and health information carry different levels of exposure risk.

Then examine who accessed or could access the information. A misdirected internal email may be contained differently from a credential theft case where an external actor logged in repeatedly from unusual locations. A lost device that remained encrypted may be less risky than unencrypted files copied to removable media. If a threat actor exfiltrated information, the risk may remain even after systems are patched.

Mitigating steps can reduce or eliminate the need to notify, but only if they genuinely reduce the likelihood of serious harm. Strong encryption, rapid revocation of access, remote wipe, password resets, log-based confirmation that files were not opened, and evidence that data was already obsolete can all matter. But the evidence has to be solid. Unsupported optimism is not a defensible control.

This is where professional judgment matters. In practice, many organisations use a combination of privacy counsel, forensic investigators, and incident response leads to test the threshold. BCyber clients often pair this with Paradigm for policy-to-control mapping and CyberTriage for incident investigation, then use GRACE Portal to brief executives and track remediation against compliance obligations.

Questions to ask your team or provider

• What data was actually exposed or accessed?
• Who had access, and for how long?
• Was the information encrypted or otherwise protected?
• What remedial action reduced the risk?
• Which other reporting rules might apply?

What should the notification process look like in practice?

A useful response process is simple enough to run under pressure but disciplined enough to stand up later. Detect the incident, contain it, assess the facts, decide whether it is notifiable, notify the relevant parties, and then remediate. That sequence sounds basic, but many teams lose time because they start with messaging before they have the facts.

A good breach program should already be documented in policy and tested through exercises. BCyber’s public platform inventory includes 23 policies, 9 processes, 50 courses, 975 published articles, 563 knowledge hub entries, 11 clients, and 14 fact-find assessments. Those figures are provided for platform context and should be verified with BCyber before use in external reporting or procurement materials.

The most effective teams also train against real scenarios. BCyber’s course ecosystem and scenario intelligence tools are useful here:

• Perfect Storm can simulate compound events such as ransomware plus data exfiltration.
• CyberTriage supports the 4-minute triage workflow for containment and forensic escalation.
• Privacy in Depth supports end-to-end privacy management where Australian Privacy Act obligations and operational response need to stay aligned.
• GRACE Portal aligns well to executive reporting and compliance tracking during the incident lifecycle.

A practical breach workflow

1. Detect the incident.
2. Contain and preserve evidence.
3. Assess the serious-harm threshold.
4. Check privacy, sector, and contract obligations.
5. Notify the required parties.
6. Remediate and record lessons learned.

What do mature organisations do differently?

Mature organisations do not treat breach notification as a one-off legal memo. They treat it as a controlled business process. That means:

• documented decision ownership,
• clear escalation criteria,
• predefined notification templates,
• contact lists for OAIC, APRA, insurers, and counsel,
• board-ready reporting,
• and evidence preservation standards.

They also align policy with control. For example, if a policy says MFA is mandatory, the incident response team should be able to prove whether MFA was bypassed, misconfigured, or absent. If a policy says log retention is 180 days, the team should know whether the relevant identity, email, and endpoint logs still exist. If a policy says privileged access is reviewed monthly, the team should be able to show the last review. This is the kind of governance detail that BCyber’s Policy Automation, Compliance Mapping, and Cross-product Analytics capabilities are designed to support.

BCyber is also recognised in the market, including:

• 2025 Finalist Cybersecurity Professional Of The Year — Karen Stephens, Co-Founder & CEO
• 2025 GRC Provider of the Year — Finalist
• 2025 AI Innovator - Cyber Security — Finalist

Those recognitions do not change the law, but they are relevant to readers evaluating whether the guidance comes from a team with current market and compliance experience.

Conclusion

If you have had a data breach in Australia, do not start with guesswork. Start with the legal threshold: is it a notifiable data breach under the Privacy Act 1988 and the NDB scheme? If the answer is yes, you may need to notify the OAIC, affected individuals, and possibly a sector regulator or contractual counterparty. If the answer is not yet clear, contain the incident, preserve evidence, and document the serious-harm analysis before the facts disappear.

The most useful discipline is to treat notification as part of incident response, not as an afterthought. Triage quickly, map the obligations, and keep the assessment tied to evidence. If the incident is complex, cross-sector, or time-sensitive, get privacy, legal, and forensic support early. And if you cannot confidently explain why the breach is or is not notifiable, that uncertainty itself is a signal to escalate.

Key Takeaways

• A data breach is only reportable under the NDB scheme if it is likely to cause serious harm and remedial action has not removed that risk.
• The OAIC must be notified when the breach meets the notifiable threshold, and affected individuals may also need direct notice.
• Sector regulators, internal governance bodies, insurers, and contracts can create additional reporting duties beyond privacy law.
• The best first response is to contain, preserve evidence, assess, document, and then notify.
• When the facts are complex or uncertain, professional advice is part of a defensible response, not a luxury.

Sources and verification

Authoritative references used in this article:

• OAIC Notifiable Data Breaches scheme: https://www.oaic.gov.au/privacy/notifiable-data-breaches
• Privacy Act 1988 (Cth): https://www.legislation.gov.au/Series/C2004A03712
• OAIC Guide to Securing Personal Information: https://www.oaic.gov.au/privacy/guidance-and-advice/guide-to-securing-personal-information
• APRA CPS 234 Information Security: https://www.apra.gov.au/cps-234-information-security
• ASD Essential Eight Maturity Model: https://www.cyber.gov.au/resources-business-and-government/essential-cyber-security/essential-eight
• NIST SP 800-61 Rev. 2 Computer Security Incident Handling Guide: https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final
• ISO/IEC 27001 Information Security Management Systems overview: https://www.iso.org/isoiec-27001-information-security.html

Verification note: BCyber platform counts and awards referenced above are based on BCyber REAL PLATFORM DATA provided for this article and should be independently verified before use in procurement, tender responses, or external reporting.