Where the Seventy-Two Hours Actually Go, Hour by Hour

An alert lands on an organisation's desk on a Monday morning: unusual access has been detected on a server. From that moment, the seventy-two-hour clock starts running.

Seventy-two hours sounds like a lot of time. What follows is an hour-by-hour account of where it actually goes, because without seeing that breakdown it's hard to understand why breach preparation has to happen months before a breach, not during one.

The first eight hours: is this actually a breach

The first task is working out whether the alert is real. It could be a false positive, a maintenance operation, or a misconfigured permission.

At this stage, the technical team goes through logs. If the logs aren't good enough — and in most organisations they aren't — this drags on. Without knowing which account accessed which table from which address, no further step can be taken.

The first critical point is this: if you don't keep logs, the clock starts running out here, and that time is never recovered.

The next twenty-four hours: which data was affected

Once it's established that this is a breach, one question follows: what personal data was on that server?

An organisation with an up-to-date inventory answers this in ten minutes. One without tries to work it out by examining the database schema — checking table names, pulling sample records, asking developers. That alone can easily take a full day.

The second half of the question is harder. What's in the backups? Is there a copy that was exported for a report? Was a sample loaded into a test environment? If the answers aren't written down anywhere, they end up being guessed — and a notification based on guesswork ends up needing to be corrected later.

The next twelve hours: how many people are affected

Once scope is established, a number has to be produced: how many data subjects, which categories of data, which geographies.

A common mistake here is rounding the figure. Saying "approximately ten thousand people" won't get a notification rejected, but a materially different real figure turning up later damages the credibility of the organisation's account. If a precise figure can't be produced, it's better to say so, and say why, than to guess.

The remaining time: preparing and submitting the notification

The notification to the Board needs to cover when and how the breach occurred, which categories of data were affected, its likely consequences, and the measures taken and planned.

Writing that from a blank page uses up whatever time is left. An organisation with a ready template fills it in within half an hour. Who is authorised to sign it also needs to be settled in advance — if that argument starts at this stage, there isn't time for it.

Notifying the individuals affected is a separate task. It's done as soon as reasonably possible once the affected people have been identified; where direct contact isn't possible, another suitable method is used. The language matters here. A message buried in technical detail stops the person understanding what they actually need to do.

What the plan actually needs to contain

The lesson from the timeline above is this: an incident response plan is only as good as what it has already thought through before the incident happens.

It needs a clear allocation of roles: who scopes the incident, who decides it's a breach, who signs the notification. A plan that depends on one person collapses the day that person is on leave.

It needs a defined threshold: what counts as a breach has to be written down in advance, otherwise that argument happens inside the seventy-two hours.

It needs an evidence-preservation rule. The first instinct is often to wipe the affected systems, which makes proper investigation impossible. The plan should say explicitly that logs are preserved untouched.

It needs communication templates ready to go, for both the Board and the affected individuals.

Nothing ends when the notification is sent

Notification isn't the end of the obligation. The Board assesses whether the technical and organisational measures taken were adequate.

A repeat breach at the same organisation reads as evidence that those measures weren't good enough. That's why the corrective action taken after a breach needs to be recorded and its effect measured. The sentence "necessary measures have been taken" is not, on its own, evidence of anything.

The one thing worth doing today

The single highest-value thing you can do before a breach happens is build the inventory with physical location attached: which database, which table, which field, which backup holds which data.

If that table exists, roughly the first thirty hours of the seventy-two are effectively recovered. If it doesn't, no matter how well the plan is written, the time won't be enough.