In early 2023, a mid-sized e-commerce company discovered that a misconfigured S3 bucket had been publicly accessible for eleven days. Over 40,000 order records — names, addresses, partial payment data — had been indexed by at least one data harvesting service. The breach itself was bad. What made it significantly worse was that the company had no documented plan: the first three hours were spent in a group call with founders, legal counsel and the CTO, all asking the same questions simultaneously — who do we tell, when do we tell them, and what do we say? That confusion cost them time they did not have and compounded the regulatory exposure considerably.
This is a practical data breach incident response plan template for SMBs — something you can adapt before you ever need it, because the time to write an incident response plan is definitively not during an incident.
Phase 1 — Detection and Initial Triage (0–2 Hours)
The first two hours after a suspected breach are the most chaotic and, in many ways, the most consequential. The goal in this window is not to fix anything — it is to understand what you are actually dealing with before taking actions that cannot be undone.
Immediate steps
- Do not panic-delete logs or rotate all credentials immediately. Your first instinct may be to "clean up," but logs are forensic evidence. Premature credential rotation can also tip off an attacker who still has access, causing them to accelerate their activity.
- Activate your incident response team. This should be a pre-defined group: at minimum, one technical lead, one business/legal decision-maker, and one communications owner. If you do not have these roles documented before an incident, establish them now.
- Assess the scope, not the cause. What systems are affected? What data may have been accessed? Is the breach ongoing or was it a historical misconfiguration? Who could have accessed what, and for how long?
- Open an incident log. A shared document where every action taken, every finding and every decision is timestamped. This becomes your evidence record for regulators, insurers and your own post-mortem.
Phase 2 — Containment (Hours 2–6)
Once you have enough information to act without making things worse, move to containment. The goal is to stop the bleeding — limit further data access or exfiltration without destroying the evidence trail.
- Isolate affected systems: If a server or database is compromised, take it offline or segment it from the rest of your network. Do not wipe it.
- Revoke compromised credentials: Now that you have scoped the breach, rotate API keys, database passwords and user credentials that were exposed or may have been accessed. Do this systematically, not in a panic.
- Preserve evidence: Take disk snapshots of affected systems before any remediation. Export relevant logs and store them somewhere the attacker cannot reach. For cloud environments, AWS CloudTrail, GCP Audit Logs, and Azure Activity Logs are your forensic record — ensure they are preserved.
- Block the attack vector: If you know how the breach occurred (exposed S3 bucket, SQL injection, stolen credential), fix that specific vector. Do not attempt a full security overhaul during containment — do the minimum necessary to stop ongoing exposure.
- Verify containment: How do you know it is contained? What is your monitoring signal that access has stopped? Document this answer, because regulators will ask it.
Phase 3 — Assessment and Notification (Hours 6–72)
This is where legal obligations kick in. GDPR requires notification to the relevant supervisory authority within 72 hours of becoming aware of a personal data breach, if the breach is likely to result in a risk to individuals' rights and freedoms. HIPAA requires notification within 60 days. US state laws (CCPA, New York SHIELD Act, etc.) have varying timelines. Know which laws apply to your data before an incident — not during one.
Notification decision matrix
| Scenario | Regulatory notification likely required? | Individual notification likely required? |
|---|---|---|
| Encrypted data accessed, encryption key not compromised | Likely no (low risk to individuals) | Likely no |
| Internal staff data exposed to another internal staff member | Assess risk; often no | Case by case |
| Customer PII (names, emails, addresses) accessed externally | Yes — GDPR 72h, state laws vary | Yes, if high risk to individuals |
| Payment card data exposed | Yes — PCI DSS + applicable law | Yes — and notify card brands / acquirer |
| Health data (HIPAA-covered) exposed | Yes — 60 days (HHS and affected individuals) | Yes |
When notifying individuals, the communication should: clearly state what happened (without minimising), specify what data was involved, explain what you have done to contain it, state what you recommend they do (change passwords, monitor for phishing), and provide a contact channel for questions. Do not write a notification that protects the company first and the affected users second. Regulators and courts read that distinction clearly.
Phase 4 — Eradication and Recovery
After the acute phase, the goal shifts from stopping the bleeding to cleaning the wound and rebuilding on a secure foundation.
- Root cause analysis: How did this happen? Not just the immediate technical cause, but the underlying process failure. Was it a missing access control? An unreviewed configuration change? A credential stored insecurely? The root cause drives your remediation plan.
- Full system rebuild where warranted: If a server was compromised, rebuilding from a known-good image is safer than attempting to clean a potentially backdoored system. Attackers often leave persistence mechanisms that are difficult to detect.
- Credential hygiene sweep: Audit all access keys, service accounts and credentials across your environment. This is a good time to implement a secrets management tool if you do not have one.
- Third-party notifications: If your breach affected data you process on behalf of clients (common in B2B SaaS), notify them according to your contractual obligations. They may have their own downstream notification duties.
Phase 5 — Post-Incident Review
A breach you do not learn from is just expensive. Within two to four weeks of closing the incident, run a structured post-mortem:
- Timeline reconstruction: when did the breach start, when was it detected, how long did each response phase take?
- What did your existing controls catch (or fail to catch)?
- Where did the incident response plan work? Where did it fall short?
- What three specific controls or process changes would have prevented this or reduced its impact?
- What monitoring or alerting would have detected it sooner?
The output of this review should feed directly into your security roadmap. If you had an incident response retainer with a security firm, debrief with them as part of this process.
Building the Plan Before You Need It
A plan that exists only in someone's head is not a plan. Your incident response documentation should include:
- Contact list for your incident response team (including out-of-hours numbers)
- Contact details for your legal counsel, cyber insurance broker, and relevant regulators
- Inventory of your critical systems and data stores with owners named
- Pre-drafted notification templates (regulatory and individual) that your legal team has approved — not for use verbatim, but as a starting framework under pressure
- Access credentials to your forensic tooling and log archives (stored securely, separately from your main systems)
- A tabletop exercise schedule — at minimum annually, walk your team through a simulated breach scenario and test the plan
Companies working with security partners like Mexilet Technologies on product security typically receive incident response plan templates as part of their security engagement, adapted to their specific stack and regulatory exposure — because a generic template is a starting point, not a substitute for one built around your actual systems.
Frequently Asked Questions
Do we need to notify users if the breached data was encrypted?
Encryption is a significant mitigating factor, and many breach notification laws include an exemption when data was appropriately encrypted and the encryption keys were not compromised. Under GDPR, if the data was rendered unintelligible through encryption and no risk to individuals is likely, you may not need to notify data subjects (though you may still need to notify the supervisory authority). Document your encryption implementation carefully — regulators will scrutinise whether it meets applicable standards.
What is the 72-hour GDPR notification requirement exactly?
The 72-hour clock starts when your organisation becomes "aware" of a personal data breach — which GDPR defines as having a reasonable degree of certainty that an incident has occurred that has led to the compromise of personal data. It does not start when you confirm every detail; it starts when you reasonably know a breach has happened. If you cannot complete the notification within 72 hours, you must provide a partial notification with the information available and indicate that further details will follow. Provide those follow-up details "without undue delay."
Should we engage a specialist cybersecurity firm during an active incident?
For anything beyond a clearly contained, low-impact incident, yes. A firm with incident response capability brings forensic tooling, experience reading attacker behaviour, and established relationships with relevant authorities. More practically: if there is any chance of litigation or regulatory action, having a qualified third party conduct the investigation protects your findings under attorney-client privilege (when the firm is engaged through legal counsel). The cost of a professional IR engagement is almost always lower than the compounded cost of a poorly managed breach.
How do we know if our business is actually covered by cyber insurance?
Read your policy before an incident. Specifically check: the definition of a covered incident (some policies exclude certain attack types), notification requirements (many policies require you to notify the insurer within a defined period after discovery), approved vendor lists (some insurers require you to use their approved IR firms), and sub-limits for regulatory fines, breach notification costs and business interruption. Cyber insurance policies vary significantly; what you think is covered may not be.
This is the kind of work our team handles every day — learn more about our cybersecurity services and secure cloud & DevOps.
If you want to assess your current security posture and get a head start on incident response planning, the cybersecurity team at Mexilet Technologies can help — from reviewing your architecture and controls through to documenting a tailored incident response playbook. Get in touch and describe where you are starting from, and we will put together a realistic plan to close the gaps before an incident forces the issue.