A customer email lands in the wrong inbox: your first 72 hours, hour by hour

It's 4:50pm on a Friday. You've just sent your monthly newsletter — 1,800 customers, a new product line, a discount code. Then the first reply arrives: "You've put everyone's email address in the To: field."

No hacker. No ransomware. No hooded figure in a stock photo. Just a tired thumb and the wrong send button — and now 1,800 people can see each other's addresses, and a handful of them are asking what you're going to do about it.

This is what most small-business data breaches actually look like. A misdirected email. A laptop left on a train. A former staff member whose login still works. A supplier who got phished. And the difference between a bad afternoon and a genuinely damaging month is almost entirely decided in the first 72 hours — which happens to be one of the tightest deadlines regulators anywhere give you.

Here's the clock, hour by hour.

First: is this actually a breach?

A personal data breach is not only data being stolen. Under the GDPR and most modern privacy laws it's any incident where personal data is accidentally or unlawfully destroyed, lost, altered, disclosed, or accessed. Three flavors:

• Confidentiality — someone saw data they should not have (the newsletter To: field, the misdirected invoice).
• Integrity — data was altered without authorization.
• Availability — data was lost or made inaccessible (the stolen laptop with the only copy, the ransomware-locked drive).

If personal data was involved and one of those happened, treat it as a breach and start the clock. You can always stand down later; you cannot get the hours back.

Hour 0–1: stop the bleeding, start the log

Two jobs, in parallel.

One thing not to do in hour one: do not email all your customers yet. A premature, vague announcement ("we may have had an incident, details to follow") creates panic without giving anyone anything to act on. Notification comes — but it comes after assessment.

Hour 1–12: work out what actually happened

Now the questions that determine everything downstream:

• What data? Email addresses only? Names and orders? Payment details, passwords, ID documents, health information? The sensitivity of the data drives the risk assessment.
• Whose data, and how many? Customers, staff, suppliers? Ten people or ten thousand? Which countries are they in? (This decides which regulators and which deadlines apply.)
• How did it happen, and is it still happening?
• Was the data protected? A lost laptop with full-disk encryption and a strong password is a very different incident from an unencrypted one.

This is where businesses with their records in order pull ahead. If you already have a record of processing activities — what data you hold, where it lives, which systems and vendors touch it — scoping takes an hour. If you do not, this step burns your whole weekend, and you'll be guessing in your regulator notification.

Hour 12–24: assess the risk, decide who must be told

Notification is not automatic. The test, in most regimes, is risk to the people affected.

• No real risk? (Encrypted laptop, strong key, remotely wiped.) You may not need to notify anyone — but you must still record the breach and your reasoning internally. Under the GDPR this internal register is itself a legal requirement (Article 33(5)).
• A risk? Notify your regulator.
• A high risk? (Passwords, financial data, sensitive categories, fraud potential.) Notify the affected people too.

Be honest in this assessment, and write it down. "We decided not to notify, and here is our reasoning, recorded at the time" is a defensible position. Silence with no record is not.

Hour 24–72: the regulator clock

If notification is required, the deadlines are tight and they vary by regime. The headline numbers:

• EU (GDPR) and UK (UK GDPR): without undue delay and within 72 hours of becoming aware, to your supervisory authority (the ICO in the UK). If you miss 72 hours, you must explain the delay.
• Singapore (PDPA): assess quickly; once a breach is notifiable, inform the PDPC within 3 calendar days.
• Malaysia (PDPA): the 2024 Amendment Act has required breach notification since 1 June 2025. The Act itself says notify the Commissioner "as soon as practicable" and leaves the manner and form to the Commissioner; the Commissioner's Data Breach Notification Guideline is where the numbers live — 72 hours to the Commissioner where the breach risks significant harm or affects more than 1,000 people, and affected individuals within 7 days of that notification where the harm threshold is met. Note the starting point: the Malaysian window is measured from when the breach happened, not from when you found out. If you discover on Wednesday something that happened on Sunday, you are already inside it.
• South Korea (PIPA): tell affected people within 72 hours of becoming aware; notify the PIPC within 72 hours as well where 1,000 or more people are affected, sensitive data is involved, or the cause was unauthorized external access. From 11 September 2026 the duty also bites before you have the full picture: if you have confirmed unauthorized access but cannot yet say who is affected, you notify anyway — and ransomware counts even if nothing left the building. We've written a separate guide to what changed in Korea on 11 September.
• Australia (Notifiable Data Breaches scheme): notify the OAIC and affected individuals as soon as practicable once you have reasonable grounds; the assessment itself must be completed within 30 days.
• United States: no single federal clock — state laws set the pace, and sector rules (health, finance) can be far stricter. "Without unreasonable delay" is the common thread, but several states set a fixed outer limit: Washington, for example, requires notice to affected residents within 30 days of discovery.

Two practical notes. You notify where your affected people are, not just where you are — the Melbourne store selling to customers in Germany and France may owe those countries' regulators a notification too. And partial notification is allowed almost everywhere: if you do not have all the answers at hour 60, notify with what you know and supplement later. Waiting for perfect information past the deadline is the worse mistake.

Is the EU's 72 hours about to become 96? There is a proposal on the table — the Commission's Digital Omnibus on data and GDPR rules, published in November 2025 — to extend the GDPR deadline to 96 hours and let you file through one portal instead of several. It is a proposal. It has not been agreed by the Council or the Parliament, and nothing has changed yet. (It is a separate instrument from the Digital Omnibus on AI, which is already law.) Plan for 72.

Telling your customers like a human

If you do have to notify the people affected, remember they will judge you on this email more than on the breach itself. The pattern that works:

• Say what happened, plainly. "On Friday we sent an email that made recipients' addresses visible to each other."
• Say what it means for them. What data, what someone could do with it, what to watch for.
• Say what you've done and what they should do. Password reset, watch for phishing, here's who to contact.
• Do not minimize, do not grovel, do not bury it in legalese.

Publishing the same information on your public privacy page — so people who hear second-hand can check the facts — does more for trust than any apology paragraph.

After the dust settles

The week after, while it's fresh: fix the root cause, not just the symptom (the newsletter tool gets a proper mailing-list mode; the offboarding checklist gets a "revoke access" line). Review the vendor if one was involved. Update your breach log with the closure. And keep the register — a documented history of small incidents handled well is evidence of a functioning privacy operation, not a rap sheet.

The part nobody does in advance

Everything above is ten times easier if two things exist before the bad Friday: a current record of what data you hold and where, and a written who-does-what for incidents — even if "who" is just you and your co-founder.

This is unglamorous work, which is why Dxtra automates it. The platform maintains your processing activity log and data mapping continuously, manages your vendors and processors, and its breach & incident reporting workflows walk you through exactly the sequence in this article — containment log, risk assessment, regulator deadlines by region, and customer notification — instead of leaving you to reconstruct it from a blog post at 5pm on a Friday. Your Transparency Center gives you the public page for honest customer communication when it matters. Plans start at $10/month, with a 14-day money-back guarantee on the START plan.

If you'd like to know how exposed you are before an incident finds out for you, the free privacy scan reads your site the way a regulator would and returns a risk band with cited findings — including where your data-handling evidence has gaps. No website? The 30-second quiz covers you too.

Sources

Current as of 10 September 2026. Deadlines, thresholds and guidance move; check the linked source before you rely on any of them.

• GDPR (Regulation (EU) 2016/679) — EUR-Lex — Articles 4(12), 33 and 34: the breach definition, the 72-hour clock, the internal breach register (Article 33(5)), and notifying individuals
• ICO — personal data breaches — UK GDPR reporting and the 72-hour deadline
• The Digital Omnibus Regulation proposal — European Parliament Legislative Train — proposed 19 November 2025; tabled, no Council general approach or trilogue as of the tracker's last update
• PDPC Singapore — report a data breach — notification within 3 calendar days once a breach is assessed as notifiable
• Donovan & Ho — Guideline on Data Breach Notification 2025 (Malaysia) — the Guideline's 72 hours "from the occurrence of the breach", the more-than-1,000-data-subjects scale trigger, and 7 days to individuals after the Commissioner notification
• HHQ — Malaysia's mandatory breach-notification obligations under the PDPA — section 12B's "as soon as practicable" wording versus the Guideline's 72 hours, and the occurrence start point
• DLA Piper — Malaysia breach and DPO guidelines — the 2024 Amendment Act (Act A1727), duty in force 1 June 2025, and the significant-harm thresholds
• 개인정보 보호법 — 국가법령정보센터 (Korea) — amending Act No. 21445, in force 11 September 2026
• Data protection laws of the world: South Korea — DLA Piper — 72-hour notification to individuals and to the PIPC (1,000+ people, sensitive data, or unauthorized external access), and the expansion to the "possibility" of a breach
• OAIC — notifiable data breaches — the Australian NDB scheme and the 30-day assessment
• NCSL — security breach notification laws — the US state-by-state patchwork
• Washington State Attorney General — data breach notification laws — notice to affected residents within 30 days of discovery (RCW 19.255)

This article is general information, not legal advice. Notification duties vary by jurisdiction and circumstance; confirm anything that matters with your regulator — the ICO, PDPC, Malaysia's Personal Data Protection Commissioner, Korea's PIPC, the OAIC, or your national authority — or a qualified adviser before you rely on it. For a live incident, get advice now, not after the deadline.

Ready to be the business with the log?

Nobody plans to have a breach. The good ones plan for the 72 hours after. Get started with Dxtra from $10/month, or take the product tour to see the breach and incident workflows.