Breach Notification Clock

Credentials for a support tool turn up in a public repository. Under Article 33 of the GDPR, the organisation has 72 hours from becoming aware to notify the supervisory authority, including the categories and approximate number of data subjects affected.

That is a question about scope, not about detection, and 72 hours is too short to answer it by investigation. The answer has to come from two systems joined together: a record of which categories of personal data each store holds, and access logs for those stores at a granularity that distinguishes a dashboard view from a bulk export.

Why it matters

Each half is independently useless. Logs without an inventory produce a list of table names, which is not a notification. An inventory without logs produces the worst case, which forces notification as if everything was taken — honest, expensive, and the answer most organisations end up giving.

The clock also starts on awareness, not on confirmation, so an organisation that plans to investigate before notifying is planning to be late. The architectural consequence is that the join must exist before the incident, because 72 hours is not enough time to build it and nobody is in a position to prioritise it during a live breach.

Implementation patterns

• Classify personal data per store, not per application, and keep the classification where engineers change the schema so it rots slowly. A field-level annotation checked in CI beats a document.
• Log access at the datastore, not only in the application. A compromised credential often reaches data through a path that bypasses the application, and that path must still be visible.
• Make the log distinguish volume. "Read the customer table" and "exported 400,000 rows" produce very different notifications, so row counts or response sizes belong in the record.
• Keep an authorisation model you can query: given this credential, what could it reach. This answers the worst case in minutes and bounds the investigation.
• Rehearse the query, not the process. A notification exercise that produces a timeline is theatre; one that produces the actual category-and-count answer for a hypothetical credential tests the capability.
• Hold a notification template with a phased structure, since Article 33 permits information in phases, and the first submission is routinely provisional.

Industry example

Published incident disclosures show the capability gap plainly: organisations that can state affected categories and counts within days are generally those with per-store classification and access logging, and the ones whose disclosures say "we are unable to determine which records were accessed" are describing an architecture rather than an investigation failure. The regime has applied since May 2018, and supervisory authorities have been consistently more tolerant of a provisional notification refined later than of a late one — which is itself a design input, because it means the maximum-plausible-scope answer is an acceptable fallback and the late perfect answer is not.

Failure scenarios

• Application logs only, so an incident on a direct database path leaves no usable record.
• Logs retained for 7 days, when the compromise window turns out to be three months.
• Classification held in a spreadsheet last updated before two schema migrations, so the categories reported are wrong.
• No row counts, so "approximate number of data subjects" cannot be stated and the notification over-reports to be safe.
• A cross-system identifier mismatch, where the store's logs record internal ids that nobody can map to data subjects within the window.
• Awareness itself undated, because the first report arrived in a channel nobody timestamps, which makes the clock's start arguable in the worst direction.

Trade-offs

Store-level audit logging costs write overhead, commonly in the range of a few to fifteen per cent depending on the engine and configuration, plus a retention bill that scales with the log's granularity. Field-level classification costs a pass across every team and a permanent CI check. What it buys is the difference between a precise notification and notifying every customer, which is a commercial and reputational cost that dwarfs the engineering one, and the ability to close an incident rather than leave it open-ended.

When not to use it

A system holding no personal data does not need any of it, and the honest first step is therefore the classification rather than the logging. Where a store holds a single category for a small population, the worst-case notification is cheap and precise enough on its own, so the logging granularity can stay coarse. Do not build per-row access attribution across an entire estate; build it where the categories are sensitive or the populations large, which is usually a small number of stores.

Interview question

Q: You are told that credentials with read access to a customer-facing database were exposed, and you have 72 hours. Walk me through the first six hours, what you would be able to say, and what you would change afterwards so the next one is easier.

What a strong answer covers: establishing and dating the moment of awareness, because the clock depends on it · bounding the worst case from the authorisation model immediately, in parallel with the forensic work · joining store access logs to a data classification to narrow categories and counts, and naming which of the two is missing · deciding explicitly to notify provisionally on maximum plausible scope rather than waiting · the retention and granularity gaps that limited the answer · and a prioritised remediation that starts with classification, since logging without it produces table names.

Quick check

Quiz: Why does encryption at rest rarely reduce a breach notification obligation? — Because a credential with application-level access reads decrypted data by design; encryption addresses media loss, not an authorised path used by the wrong person.

Flashcard: Which two artefacts must be joinable to answer a 72-hour notification? — A per-store record of the personal data categories held, and datastore access logs granular enough to distinguish a view from a bulk export.