Does every AI privacy incident require OAIC notification?

Notification turns on the NDB test. The event must involve unauthorised access, unauthorised disclosure, or loss of personal information held by the entity; serious harm must be likely; and remedial action must have failed to remove that likelihood. Record the reasoning even when the incident closes below the notification threshold.

When does the 30-day period begin?

The OAIC describes the period as 30 calendar days after the entity becomes aware of the grounds or information that caused it to suspect an eligible breach. Capture that awareness event in the incident chronology. Teams should assess quickly and treat the period as a ceiling for reasonable steps, rather than a waiting period.

Can a provider deletion confirmation resolve the incident?

It may support remediation if it shows that likely serious harm has been prevented. The confirmation needs to cover the exact request, retained copies, logs, subprocessors, and effective deletion time. Other exposure paths may remain, including a response viewed by another user or a local copy created before the provider acted.

Australia Privacy AI Incident Reporting: Evidence for the NDB Decision

An employee places a customer file into an external LLM and receives an answer. The employee then closes the browser. The incident team now has to establish if the entity held the personal information, meaning it had possession or control of the relevant record, which provider received it, and what unauthorized access, disclosure, or loss occurred. A generic web log rarely carries those facts.

I want the NDB decision written against the actual AI transaction. A meeting where five people point at separate dashboards is delay disguised as incident response.

TL;DR

Australia's NDB scheme covers AI incidents involving loss of personal information or unauthorised access to or disclosure of it where serious harm is likely and remediation has failed to remove that likelihood.
A suspected eligible breach must be assessed through reasonable steps within 30 calendar days, while confirmed eligible breaches require notification as soon as practicable.
Preserve the originating identity, prompt and response classification, model destination, policy outcome and timestamps, plus remedial actions.
Request-boundary evidence supports the NDB assessment. Legal and privacy teams still own adjacent facts, alongside provider, identity and endpoint teams.

The NDB trigger starts with the data event

The OAIC's reporting guidance defines an eligible data breach through three elements. Personal information held by the entity was subject to unauthorised access, unauthorised disclosure, or loss. Serious harm to one or more individuals is likely. Remedial action has failed to prevent that likely risk.

An AI incident can satisfy the first element through several paths. A prompt sends personal information to an unapproved external provider. A model response exposes one customer's record to another authenticated user. A prompt log becomes accessible to an unauthorised administrator. The facts depend on possession or control of the relevant record and the actual access, disclosure, or loss, rather than the team's label for the tool.

Start the incident record with the data class, affected individuals, request route and destination, plus the access path. Attach the governing purpose and authorization. This keeps the analysis focused on what happened to personal information instead of debating the word "AI."

Containment must preserve the request trail

The OAIC's 2026 quick reference guide sets out four response steps: contain and assess, followed by notification and review. AI containment may require disabling a model route, revoking a connector, removing an exposed response, rotating an application credential, or pausing a workflow that keeps sending the same data.

Containment can erase evidence if the team starts by deleting prompt history or reconfiguring every route. Preserve the transaction identifier, user or agent identity, prompt and response, model endpoint, connector path and policy version, plus the decision outcome before altering the affected system where that collection is lawful. Take a timestamped configuration snapshot. Record every later change.

The AI incident response plan covers the wider operating model. For an Australian privacy event, the additional discipline is tying each technical fact to the NDB elements and the population of individuals whose information was involved.

Assessment needs a defensible serious-harm record

The OAIC says serious harm can include serious physical, psychological, emotional, financial, or reputational harm. Likelihood uses the perspective of a properly informed reasonable person in the entity's position and considers the full set of relevant circumstances. The test concerns harm that is more probable than not, rather than a remote possibility.

For an LLM event, record the kind and sensitivity of information, the number and circumstances of affected individuals, the provider and route, the duration of exposure, encryption or access controls, known downloads or further disclosure, and the nature of any generated output. Identify uncertainty explicitly. A provider's contractual retention statement may reduce one risk while leaving onward access or copied output unresolved.

A single screenshot with the prompt blurred out is weak evidence. The assessment file should let a reviewer trace each conclusion back to a source record while protecting the personal information inside the investigation itself. AI audit-log chain of custody explains that evidentiary handling in detail.

Remedial action changes the notification analysis

The NDB scheme recognizes remediation that prevents the likely risk of serious harm. That makes the remedy and its timing part of the legal analysis. A provider confirms deletion before access occurred. An exposed response is recalled before another user opens it. A lost encrypted device remains protected by controls that prevent access. Each conclusion needs supporting evidence.

For an AI disclosure, preserve the provider ticket, deletion confirmation, access record and credential-revocation event, plus any downstream purge result. Match those artifacts to the exact request and affected dataset. If remediation protects only part of the affected group, the OAIC guidance says notification may still apply to the individuals whose likely harm remains.

I would treat an unsupported "the vendor deleted it" statement as an open action. The incident register needs the vendor's confirmation and its scope, including the time it took effect. That evidence can change the eligible-breach decision.

The assessment clock and notification package

Where an entity suspects an eligible data breach, the OAIC guide says it must take all reasonable steps to complete the assessment within 30 calendar days after becoming aware of the grounds for suspicion. Once reasonable grounds establish an eligible breach, the entity must notify affected individuals and provide a statement to the OAIC as soon as practicable, unless an exception applies.

The statutory structure appears in Part IIIC of the Privacy Act 1988, including the eligible-breach test, remedial-action exception, assessment duty, and notification provisions. The notification file should identify the entity, describe the breach, state the kinds of information involved, and recommend steps individuals should take. Privacy counsel should map the final wording to the current Act and OAIC form.

Build the chronology as events occur. A whiteboard photographed on day 29 leaves the entity defending both the breach and the quality of its assessment.

Ownership across the AI incident

The application team owns the initiating identity and business workflow. The AI platform team owns the selected model route and connector configuration. Privacy owns the NDB analysis. Legal confirms statutory interpretation, while the provider supplies retention, access, and deletion facts. Identity and endpoint teams contribute evidence where account misuse or local copying occurred.

Assign one incident lead and one correlation key. The lead should maintain a fact ledger with source, owner, timestamp, confidence, and impact on the NDB test. This avoids treating an assumption in a chat channel as settled evidence.

The existing Australia Privacy Act audit evidence guide defines routine artifacts. Incident reporting narrows the question to one event and one chronology, with remedial action and likely harm informing the decision to notify or close.

DeepInspect

DeepInspect can preserve evidence for the part of an AI incident that crosses deliberately routed HTTP traffic between an authenticated user or agent and an LLM. It evaluates application-supplied identity, route, data classification and model authorization against organizational policy before forwarding the request.

A blocked request provides a per-decision record of the attempted destination and policy result. A permitted request retains the same decision context for later assessment. Provider systems, local endpoints, identity compromise, legal analysis, harm assessment, and OAIC notification remain with their respective owners.

Book a technical deep dive at deepinspect.ai.