The 72-Hour Clock: What to Do When Customer Data May Have Been Exposed

Your website has been compromised, and the attacker had access to a database containing customer names, addresses and order history. Beyond cleaning up, you now have legal obligations with a deadline attached.

Data breach notification rules are stricter and faster than most small business owners expect. This is a practical overview, not legal advice — for a real incident, take proper counsel.

When the clock starts

This is the detail that catches people out.

Under GDPR, you generally have 72 hours to notify the regulator — and that window starts when you become aware of the breach, not when you finish investigating it.

Awareness does not mean certainty. It means having a reasonable degree of confidence that a breach has occurred. You do not get to pause the clock while you establish exactly what happened.

If you find evidence of a compromise on Friday evening and spend the weekend investigating, you have already used most of your window.

Similar principles apply under PDPL in the UAE and Saudi Arabia, with their own timelines. The practical implication is the same everywhere: this is measured in hours.

What counts as a breach

Broader than "someone stole the database". A personal data breach is any security incident leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data.

That includes an attacker gaining database access even if you cannot prove data was copied, a backup left publicly accessible, ransomware encrypting your data, a laptop with customer records being lost, and email sent to the wrong recipients.

Note the important one: unauthorised access counts. You do not need proof of exfiltration. If someone had access to the data, treat it as a breach until you can demonstrate otherwise.

Who you tell, and when

The regulator — within 72 hours

Unless the breach is unlikely to result in risk to individuals. That exemption is narrower than people hope, and the assessment should be documented.

If you cannot supply full details within 72 hours, notify anyway with what you have and follow up. A partial notification on time is far better than a complete one that is late.

The affected individuals — without undue delay

Required when the breach is likely to result in high risk to their rights and freedoms. Financial data, credentials, and sensitive categories generally meet that bar. A list of email addresses alone may not.

This is a judgement call worth taking advice on, and worth erring toward telling people. The reputational cost of customers discovering it elsewhere is greater than the cost of telling them.

Others, depending on circumstances

Your payment processor immediately if card data may be involved. Your insurer, if you have cyber cover — most policies require prompt notification. Your bank if financial details were exposed.

What the notification contains

Regulators expect a consistent set of facts:

• What happened, and when it occurred and was discovered
• The categories and approximate number of individuals affected
• The categories and approximate volume of records
• Likely consequences
• Measures taken or proposed, including mitigation
• Contact details for your data protection contact

Notifications to individuals should be in plain language, explaining what happened, what it means for them, and what they should do — change a password, watch their bank statements.

The document nobody has

Even where notification is not required, you must record the breach internally: what happened, its effects, and the remedial action. Regulators can ask to see this.

Deciding a breach did not need reporting is a defensible position if you documented the reasoning at the time. It is a much weaker one if the record was written months later during an enquiry.

The gap most businesses have

Here is the uncomfortable arithmetic.

The regulatory framework assumes you will notice a breach and report within days. The typical website compromise runs undetected for weeks, and is usually discovered by a customer, by Google, or by a hosting suspension.

If your site was compromised six weeks ago and you learn about it today from a customer, you have not simply missed a deadline. You have to explain to a regulator that nothing in your organisation was capable of noticing.

"We did not know" is not a defence when the reason you did not know is that nothing was watching. Both GDPR and PDPL require appropriate technical measures, and detection capability is reasonably read as part of that.

This is why our security monitoring service is a compliance control, not just a technical one. It is the mechanism that makes the notification timeline achievable at all.

The first hours, in order

1. Contain it — stop the ongoing access, but preserve evidence before deleting anything
2. Start the clock consciously. Note the date and time you became aware
3. Establish scope — what data, how many people, what period
4. Take legal advice if there is any doubt about obligations
5. Notify the regulator within the window, even if details are incomplete
6. Notify individuals if the risk threshold is met
7. Document everything, including decisions not to notify and why
8. Fix the underlying cause, because a repeat incident is treated far more harshly

Our guide to what to do in the first hour covers the technical containment, and step one is where evidence preservation matters most.

Being early and honest works

Regulators consistently treat organisations better when they report promptly, cooperate, and take remediation seriously. The cases that attract real penalties tend to involve concealment, delay, or an obvious failure to take basic precautions.

The instinct to wait until you fully understand the situation is understandable and usually counterproductive.

Preparing before you need it

Three things worth having in advance: knowing where personal data actually lives across your systems, knowing who assesses and signs off a notification, and having detection capable of telling you within hours rather than weeks.

Our guide to writing an incident response plan covers the first two on a single page.

For the third — get in touch. If nothing is currently watching your site, the notification deadline is one you would miss by default.