Data breach readiness

When a breach lands, two clocks start. The first is the attacker's — how far the compromise spreads while you work out what happened. The second is the regulator's: under the Notifiable Data Breaches scheme, a suspected eligible breach must be assessed within thirty days, and notified to the OAIC and affected individuals as soon as practicable once it qualifies. Neither clock pauses while you locate the asset register, argue about who decides, or discover that the person who understood the logging left last year. Readiness is everything you do before the clocks start. 1. What the assessment clock assumes you already know To assess a breach quickly you must already be able to answer: what data was in the affected system, whose data it is, how sensitive it is, who and what could access it, and what the logs can prove about what actually happened. Every one of those answers is a readiness artefact — the data inventory, the classification, the access map, the logging coverage. An organisation that cannot answer them in days has not got a response problem; it has a posture problem wearing a response problem's clothes. 2. The runbook Write the sequence before you need it. Contain: isolate what is compromised without destroying the evidence. Assess: scope the data, the subjects, and the harm — the NDB test is whether serious harm is likely, and that judgement needs facts, not adrenaline. Notify: the OAIC statement, the affected individuals, and the sector obligations that stack on top — an APRA-regulated entity has material-incident notification duties on a much shorter fuse than thirty days. Name the decision-makers for each step, and their deputies, because breaches respect neither calendars nor leave. 3. Evidence, prepared cold The breach report writes itself if the platform was built to remember: what was accessed, from where, when, under which identity. It cannot be reconstructed if the logs were never kept, rotated away after a week, or scattered across systems nobody can correlate under pressure. Decide log coverage and retention for the crown-jewel systems as a readiness investment — the cost is modest, and the alternative is standing in front of a regulator saying we believe rather than we know. 4. Communications, drafted in peacetime The worst time to write a customer notification is the day you must send one. Draft the skeletons now: the OAIC statement, the customer notice in plain language, the executive brief, the media holding line. Legal reviews them once, calmly, in advance. On the day, you fill in facts instead of arguing about sentences — and the notice that reaches customers is clear about what happened and what they should do, which is the difference between a breach handled and a breach compounded. 5. The rehearsal A runbook that has never been run is a theory. Twice a year, take a plausible scenario — the compromised account with broad access, the misdirected extract, the third party that lost your data — and play the first 72 hours for real: the actual people, the actual tools, the actual draft notifications. Time the steps. The gaps you find — the number nobody had, the log that did not exist, the decision nobody would own — are the readiness backlog, discovered privately at rehearsal prices instead of publicly at incident ones. 6. The first 90 days Confirm the crown-jewel inventory and its access map — the assessment clock's first questions. Fix logging on the two systems where the evidence would currently be thinnest. Write the runbook and the communication skeletons. Then book the first rehearsal for day 60 and let its findings set the next quarter. None of this is exotic; all of it is the difference between thirty days that feel survivable and thirty days that feel like freefall. Breaches are not fully preventable. Being unprepared for one is.