The 30-Day Clock in the NDB Scheme
Almost everyone who has heard of Australia’s notifiable data breach scheme knows there is a 30-day rule. Almost everyone has it slightly wrong, in the same three ways, and each one costs time at the point where time is the scarce thing.
Here is what the scheme actually says.
It is an assessment window, not a response window
The 30 days is the period in which you must carry out a reasonable and expeditious assessment of whether a suspected breach is an eligible data breach. It is not a deadline by which you must have sorted everything out, and it is not a grace period before anyone needs to know.
The wording matters: the assessment must be completed within 30 calendar days after the day you became aware of the grounds that caused you to suspect an eligible data breach.
So the output of that 30 days is a decision, not a resolution. You are deciding one thing: is this a breach that is likely to result in serious harm.
The clock starts at suspicion, not at confirmation
This is the part that costs businesses the most, and it is worth being precise.
The trigger is not “you confirmed a breach”. It is becoming aware of the grounds or information that caused you to suspect one.
Which means the clock is already running during the phase most businesses think of as “looking into it”. The suspicious login someone noticed on Tuesday, the laptop that has not turned up, the client who says they received an email you did not send — if a reasonable, properly informed person would suspect an eligible breach on that information, day one was Tuesday. Not the day the investigation concluded.
The scheme draws a clean line between two states:
| State | What it triggers |
|---|---|
| You suspect there may have been an eligible breach | Assessment required, 30-day clock running |
| You believe there has been one | Notification required |
Moving from the first to the second is what the assessment is for.
★ Insight ─────────────────────────────────────
The practical consequence is that “when did we become aware?” is a question you will have to answer later, from records, under pressure. The single cheapest preparation available is to write down the date and time whenever something odd is reported — even the ones that turn out to be nothing. A dated note costs nothing on the day and is the only evidence that establishes when the clock started. Reconstructing it afterwards from memory and email timestamps is both unpleasant and unconvincing.
─────────────────────────────────────────────────
Thirty days is a ceiling, not a target
The Commissioner’s stated expectation is that entities treat 30 days as a maximum time limit and endeavour to complete the assessment in a much shorter timeframe.
That is not a technicality. If you take 29 days over something that could reasonably have been assessed in four, the elapsed time is itself a fact about your handling of the incident, and it will be visible to the regulator and to the affected individuals. “We used the time available” is a weaker position than it sounds.
The practical planning number is closer to a week for most small-business incidents, because most small-business incidents are not forensically complex — the question is usually what was in the mailbox, not what an attacker did across a fleet.
Once you believe it is notifiable, there is no second 30 days
The third misunderstanding. Having decided that a breach is eligible, the obligation is to prepare a statement for the Commissioner and notify affected individuals as soon as practicable.
Not within another 30 days. As soon as practicable.
So the shape of the timeline is a window that narrows:
- Suspicion → assessment begins, 30 calendar days maximum, shorter expected.
- Belief that it is eligible → notify as soon as practicable.
A business planning around “we have a month” is planning around the first leg only, and the second leg has no cushion in it at all.
What the notification has to contain
Worth knowing in advance, because it determines what your assessment needs to find out.
The statement must include your identity and contact details, a description of the breach, the kinds of information involved, and recommendations about the steps individuals should take in response.
That last requirement is the one that quietly shapes the whole exercise. You cannot tell someone what to do about a breach until you know which information was exposed — and “we are not sure exactly what was in there” is not an answer that survives contact with that obligation. The assessment has to establish scope, not just occurrence.
What to put in place before anything happens
Four things, none of which require a security programme.
1. One named person who starts the clock. Whoever is told first, tells them. Their job on day one is to record the date, the time and what was reported. That is the whole role.
2. A list of where personal information lives. Which systems hold data about customers, staff or patients, and roughly what kinds. An assessment that begins with “where would that even be?” has already spent days it did not have.
3. Access to the logs you will need. Mailbox access logs, sign-in logs, file access history. Most of these are available by default and retained for a limited window — often shorter than 30 days on lower-tier plans. Find out your retention period before you need it, because a breach suspected on day 25 of a 30-day log window is a breach you may not be able to scope.
4. The decision written down. Whatever the assessment concludes, record it and the reasoning, including for incidents assessed as not notifiable. That record is what demonstrates a reasonable and expeditious assessment actually took place.
Where the 30 days actually goes
For a typical small-business incident, the assessment is not 30 days of investigation. It is a handful of steps with waiting in between, and the waiting is what consumes the calendar.
| Step | Realistic elapsed |
|---|---|
| Someone reports something odd; it reaches the right person | Hours to days |
| Establishing what was accessed, from logs | 1–3 days, if the logs exist |
| Working out whose information was involved | 1–2 days |
| Deciding whether serious harm is likely | A conversation, plus advice if unclear |
| Preparing the statement and the notifications | 1–2 days |
Almost none of that is technical work. The step that reliably blows out is the second one, and it blows out for a single reason: the logs were not retained, or nobody has the access to read them.
Which makes the preparation list below less about security and more about record-keeping. That is the honest shape of this obligation — it is an evidence exercise with a deadline attached.
The one-sentence version
You have 30 days to decide, the clock starts when you first have reason to suspect, the regulator expects you to take much less, and after you decide there is no further window at all.
If your incident plan says “notify within 30 days”, it is describing a scheme that does not exist.
Source: OAIC, Part 4: Notifiable Data Breach (NDB) Scheme. General information, not legal advice.
Cloud Geeks provides cybersecurity and managed IT for Australian small businesses. Websites come from Cosmos Web Tech, apps from Awesome Apps, and the group is Ganda Tech Services.