Data Breach Response Plan: A 72-Hour Checklist for SMBs

The Nintendo data breach statement from June 2026 is worth studying, not because Nintendo got hit, but because of how cleanly it responded. A threat group claimed it stole 859MB of employee data, demanded $2 million, and Nintendo answered within days: systems intact, no customer data, no payment. That calm is not luck. It is a rehearsed plan.

Here is the uncomfortable part for small and mid-sized businesses. Nintendo could say "our systems were not compromised" because the breach came through a vendor, not their core network. Most SMBs cannot say that with confidence, and the clock on notifying regulators starts the moment you become aware.

That gap is why the same rigor you bring to choosing the AI systems that run your business operations belongs in your breach planning too.

What the Nintendo data breach statement actually teaches SMBs

In mid-June 2026, Nintendo of America confirmed an issue involving TinyPulse, a third-party tool it used for internal employee surveys. The statement was deliberate: Nintendo's systems were not compromised, no customer or financial data was accessed, and the exposed content was limited internal survey material, much of it years old.

The attackers, a group calling itself SHADOWBYT3$, said they never breached Nintendo directly. They hit TinyPulse, a WebMD Health Services HR product, and pulled employee data from there. When Nintendo refused the $2 million ransom, the group turned its extortion toward TinyPulse instead, extending its deadline to June 16, 2026.

The lesson is not "Nintendo was careless." It is that a supply-chain exposure can drag your name into headlines even when your own network is clean. For an SMB, the same scenario is far harder to survive, because you rarely have the visibility to prove a negative quickly.

A breach you did not cause is still a breach you have to answer for in 72 hours.

Why your vendor is now your weakest link

The Nintendo case is the clearest 2026 proof that the highest risk for SMBs lives outside your walls. Your payroll provider, your CRM, your HR survey tool, your cloud storage: each holds sensitive data and each is a target. A vendor compromise exposes you without ever touching your servers.

This is why vendor due diligence and contract clauses are a first line of defense, not paperwork. Before you sign with any SaaS provider, you want answers to a few hard questions.

• How fast must they notify you of a breach, in writing?
• What data do they hold, and where is it stored?
• Do they carry a recognized security certification?
• What happens to your data when the contract ends?

If a vendor cannot commit to notifying you within 24 to 48 hours, that is your problem to solve before an incident, not during one. Apply that scrutiny to every tool, even the ones that feel low-risk, like the video production platforms your marketing team relies on, because they store assets and account data too.

The 72-hour data breach response checklist

The first three days decide whether an incident becomes a controlled event or a public crisis. Work this sequence in order, and assign owners before anything happens.

Notice that documentation runs through every window. Regulators want a record of what you knew, when you knew it, and what you did. A clean log is often the difference between a warning and a fine.

Contain first, investigate second

The instinct to understand exactly what happened can cost you. Isolate the affected systems and revoke access immediately, then investigate. A live attacker inside your network during your forensics is a worst-case scenario you can avoid in the first hour.

One coordinator, one log

Breaches fail on coordination, not technology. Name a single person to own the response and keep a timestamped record. When the regulator or your lawyer asks what happened at 02:00, you want one source of truth, not five conflicting memories.

The 72-hour clock starts at awareness, not certainty

This is the rule SMBs misread most often. Under GDPR Article 33, the 72-hour window begins when you have a reasonable degree of certainty that a breach occurred, not when your investigation wraps up. Waiting for full forensic clarity is how organizations miss the deadline.

If you do not have every detail in time, you are allowed to notify in stages. File what you know, flag that the picture is incomplete, and supplement as you learn more. A phased notification with a clear justification beats silence.

Regulators have already enforced this. National data authorities have fined companies specifically for failing to notify within 72 hours, confirming that the clock runs from awareness. An Article 33 failure sits in the lower fine tier, up to €10 million or 2% of global annual turnover, whichever is higher.

One principle to internalize: no confirmed proof of access is not the same as proof of no access. If personal data might have been exposed, treat it as if it was, and document why you reached that view.

Watch the double obligation: GDPR and NIS2

If your SMB operates in a sector covered by NIS2, one incident can trigger two separate notification duties to two different authorities. That catches teams off guard, because the deadlines and thresholds do not match.

• GDPR Article 33: one notification to your supervisory authority (DPA) within 72 hours of awareness, with phased follow-ups allowed.
• NIS2 Article 23: a 24-hour early warning to your national CSIRT, a 72-hour incident notification, and a one-month final report.

The 24-hour NIS2 early warning is the tightest deadline, and it is the one most SMBs are not built for. Note the recipients differ: NIS2 reports go to the CSIRT, GDPR notifications to the data protection authority, with separate forms and content.

The practical answer is to design one response process that can satisfy the fastest clock while preparing the data-focused GDPR notification in parallel. Build for 24 hours and the 72-hour duty takes care of itself.

Write the customer notification before you need it

When you have to tell customers or employees, clarity wins. The template should cover what happened, which data was involved, the possible impact, the steps people can take to protect themselves, and what your company is doing about it. Plain language, no jargon, no premature minimizing.

Nintendo could honestly say the exposure was limited and old only because its core systems were untouched. Do not borrow that framing unless it is true for you. Downplaying a breach you have not fully scoped destroys trust faster than the breach itself, and it is exactly the move regulators punish.

If you draft these messages with help from AI content workflows, keep a human reviewer on the legal claims. Good drafting speeds you up; only a person can confirm the facts are true on the day you send.

Preparation is the real differentiator

Everything above is easier when it is written down in advance. A response plan that lives in someone's head is not a plan. The teams that handle breaches well share four habits.

• A written incident response plan that names roles and steps.
• 24/7 coverage, because breaches ignore weekends and holidays.
• Pre-approved notification templates for the DPA and for individuals.
• Tabletop exercises that rehearse the Article 33 and NIS2 timelines specifically.

Run one simulation a year. Walk a fake breach through the full 72 hours and watch where your team stalls. Treat that rehearsal like any other operational investment, the same way you would vet a new creative tool before rolling it out, and it will pay for itself the first time something real happens.

Related guides

Frequently asked questions

Why is a vendor the biggest data breach risk for SMBs today?

Because a vendor compromise exposes your sensitive data even without a direct breach of your systems, exactly as the Nintendo case showed. Their HR survey platform was hit, not Nintendo's network, yet employee data still leaked. Due diligence on suppliers and contractual breach-notification clauses are your first line of defense, since you depend on the vendor to tell you fast when something goes wrong.

What are the first actionable steps in the first 72 hours of a breach?

Six steps, in order: (1) contain and isolate affected systems and revoke access immediately; (2) appoint one coordinator who logs every action; (3) assess risk by what could have been accessed, not only what is confirmed; (4) notify your supervisory authority; (5) notify affected individuals if the risk is high; and (6) document everything, even when you have no legal duty to notify.

When does the GDPR 72-hour clock actually start?

It starts at the moment of awareness with a reasonable degree of certainty, not when forensics finish. If you do not have full information in time, you are permitted to notify in stages: file what you know, justify the delay, and supplement later. Phased notification is allowed and is far safer than missing the deadline while waiting for certainty.

Can one incident require notifying two different authorities?

Yes. SMBs in sectors covered by NIS2 may have to notify two separate authorities for the same incident: the data protection authority under GDPR and the national CSIRT under NIS2. The thresholds and deadlines differ, with NIS2 demanding a 24-hour early warning on top of the GDPR 72-hour rule, so build one process that satisfies the tightest clock.