NOTIFIABLE DATA BREACHES: A GUIDE FOR APP FOUNDERS | VIBEEVAL

The scheme in one paragraph

Since 22 February 2018, the Notifiable Data Breaches scheme (Part IIIC of the Privacy Act 1988) requires covered entities to notify the Office of the Australian Information Commissioner (OAIC) and affected individuals when an eligible data breach occurs. An eligible data breach has three elements: unauthorised access to, unauthorised disclosure of, or loss of personal information; a likelihood of serious harm to at least one individual as a result; and the absence of successful remedial action that removed that likelihood.

Every word of that definition matters for an app built fast with AI tooling, because the most common vibe-coding failures — exposed keys, missing RLS, public buckets — sit exactly on the line between “vulnerability” and “breach”.

Vulnerability or breach? The distinction that decides your week

A scanner finding is not automatically a notifiable breach. The progression looks like this:

Two operational consequences follow:

1. Logging is your alibi. The difference between “suspected” and “remediated” is usually whether you can show from access logs that the exposed path was not used. Database and storage access logs turn an unanswerable question into a closed incident.
2. Detection speed is a legal position. The remedial action exception rewards teams that find exposure in hours. A key that leaks on Monday and is found by continuous scanning on Monday is an incident report. The same key found by a security researcher in month three is a notification, a regulatory file, and a news story.

The 30-day assessment, honestly

When you become aware of reasonable grounds to suspect an eligible breach, you must assess “expeditiously”, within 30 days at most. In practice, the assessment for an app-layer incident is three questions:

1. What was exposed? Which tables, buckets, or endpoints; which fields; how many individuals.
2. Was it accessed? Pull every log you have: database logs, storage access logs, platform request logs, key-usage records.
3. Is serious harm likely? Weigh sensitivity (health, financial, identity documents at the top), protections (was the data encrypted with keys that stayed safe), and who plausibly had access.

If the answer to 3 is yes and remediation cannot unwind it, notify the OAIC and affected individuals as soon as practicable — waiting out the 30 days once you know is not an option the scheme offers.

What the OAIC’s own reporting says

The OAIC publishes periodic statistical reports on notifications received. Two patterns have held consistently across reporting periods: malicious or criminal attack is the largest source of notified breaches, and compromised or stolen credentials are among the leading attack vectors within that category. (Check the latest report on oaic.gov.au for current numbers — they update roughly half-yearly.)

Read those two findings against how AI-built apps actually fail. Credentials in a frontend bundle are compromised credentials that require no phishing. A service-role key in JavaScript shipped to every visitor is the leading breach vector, pre-packaged. The national statistics and the Token Leak Checker results are describing the same phenomenon from opposite ends.

The founder’s NDB playbook

Before anything happens:

1. Know what personal information you hold and where — you cannot assess a breach of data you have not inventoried
2. Turn on and retain access logs for database, storage, and auth (platform defaults are often too short)
3. Run detection continuously, not annually — the remedial exception is built for fast finders
4. Write the one-page response plan now: who assesses, who decides, where the OAIC form lives
5. Minimise holdings — data you deleted under APP 11.2 cannot breach

In the first hour of a suspected breach:

1. Close the path: rotate the key, enable RLS, privatise the bucket — containment before forensics
2. Preserve logs before they age out
3. Start the assessment note: what you knew, when, what you did — contemporaneous records are gold
4. Do not delete evidence of the incident itself; remediation and cover-up are different things

Notification, if it comes to that: a statement to the OAIC (there is an online form) and notice to affected individuals as soon as practicable, describing the breach, the information involved, and recommended steps. Notify honestly and completely once — a drip-fed breach disclosure is how a bad week becomes a bad year.

Related resources

• APP 11: Privacy Act Security for App Developers — the obligation whose failure lands you here
• AI Security Audit for Australian Startups — the AU-specific audit playbook
• Essential Eight for Vibe-Coded Apps — the ACSC baseline, honestly mapped
• Continuous Penetration Testing — the cadence the remedial exception rewards
• Token Leak Checker — find exposed credentials before someone else does
• Supabase RLS Checker — the most common unauthorised-access path, checked in seconds

Find it before it becomes reportable

The remedial action exception belongs to teams that detect fast. Paste your URL and know in 60 seconds whether there is an exposure with your name on it.