Incident Response Plans, Playbooks, and Data Breach Reporting: A Practical Guide

It is 2 AM. Your monitoring system fires an alert. An engineer clicks through and sees 50,000 customer records being exfiltrated to an unknown IP address.

What happens next depends entirely on whether you prepared for this moment or not.

Without a plan, the next six hours look like chaos. Engineers scramble in Slack. Nobody knows who makes the call to shut down access. Legal finds out from Twitter. The CEO is drafting a customer email at 4 AM with no facts. Regulators hear about it from the press before they hear from you.

With a plan, every person knows their role. Containment starts within minutes. Legal is briefed. Communications are drafted from a template. Regulators are notified within 72 hours. Evidence is preserved from the start.

Incidents are inevitable. The damage they cause is not. This guide covers how to build an incident response plan that works, create playbooks for common scenarios, and handle data breach reporting the right way.

What Is an Incident Response Plan?

An incident response plan (IRP) is a documented process that defines how your organization detects, responds to, contains, and recovers from security incidents.

It is not a binder that sits on a shelf. A good IRP is:

• Short enough to follow under pressure. If it takes 30 minutes to read, nobody will read it during an incident.
• Clear about roles. Every person involved knows what they are responsible for before an incident happens.
• Tested regularly. A plan that has never been exercised is a plan that will fail.
• Connected to your operations. Logging, monitoring, escalation paths, and communication channels must exist before you need them.

The goal of an IRP is coordination. When something goes wrong, the plan removes the question "what do we do now?" and replaces it with "here is what we do."

Why Incident Response Matters for SOC 2, ISO 27001, and GDPR

SOC 2

SOC 2 Trust Services Criteria CC7 covers system operations and incident management:

• CC7.3: The entity evaluates security events to determine whether they constitute security incidents
• CC7.4: The entity responds to identified security incidents by executing defined response activities
• CC7.5: The entity identifies, develops, and implements activities to recover from identified security incidents

Your auditor will ask for your incident response plan, evidence of incident logs, and proof that you followed the plan when incidents occurred.

ISO 27001

ISO 27001:2022 includes specific incident management controls:

• A.5.24: Information security incident management planning and preparation
• A.5.25: Assessment and decision on information security events
• A.5.26: Response to information security incidents
• A.5.27: Learning from information security incidents
• A.5.28: Collection of evidence

These controls require documented procedures, trained staff, and evidence of execution.

GDPR

GDPR Article 33 requires notification to the supervisory authority within 72 hours of becoming aware of a personal data breach. Article 34 requires notification to affected individuals if the breach is likely to result in a high risk to their rights and freedoms.

Failure to notify within 72 hours, or failure to have documented procedures for breach detection, can result in significant fines.

The Incident Response Lifecycle

Phase	Goal	Key Actions	Timeline
1. Preparation	Be ready before it happens	Define roles, set up logging, draft templates, run tabletop exercises	Ongoing
2. Identification	Detect and classify	Triage alerts, classify severity, assign incident commander	Minutes
3. Containment	Stop the bleeding	Isolate systems, revoke credentials, block threats, preserve evidence	Minutes to hours
4. Eradication	Remove the threat	Find root cause, remove malware/backdoors, patch vulnerabilities	Hours to days
5. Recovery	Restore operations	Restore from backups, monitor for reinfection, verify integrity	Hours to days
6. Lessons Learned	Improve for next time	Post-incident review, update playbooks, assign improvements	Within 5 days

---

1. Preparation

When: Before any incident occurs

Everything you do before an incident determines whether your response is coordinated or chaotic.

What to Prepare	Why It Matters
Roles and escalation paths	Everyone knows who does what
IRP documented and distributed	Accessible under pressure
Logging on all critical systems	Cannot investigate what you did not log
Alerting thresholds and on-call rotation	Someone is always watching
Communication channels (Slack, bridge call)	No scrambling for a meeting link
Pre-drafted notification templates	Regulator and customer comms ready to go
Tabletop exercises (twice a year)	Plans that are untested will fail

---

2. Identification

When: An alert fires or a user reports something suspicious

Determine whether an event is actually a security incident.

Severity	Description	Response
Informational	Anomaly with no confirmed impact	Log and monitor
Low	Minor policy violation, no data exposure	Investigate within 24 hours
Medium	Potential unauthorized access, limited scope	Investigate within 4 hours
High	Confirmed unauthorized access or data exposure	Immediate response, incident commander assigned
Critical	Active breach, data exfiltration, ransomware	All-hands response, executive notification

Not every alert is an incident. Your plan should define clear criteria for escalation.

---

3. Containment

When: Incident confirmed. Stop the damage.

Short-term Containment	Long-term Containment
Isolate affected systems from the network	Apply temporary patches or configurations
Revoke compromised credentials	Redirect traffic away from compromised services
Block malicious IPs or domains	Set up enhanced monitoring on affected systems
Disable compromised accounts	Preserve forensic evidence before making changes

The priority is preventing further damage. Do not destroy evidence in the rush to contain.

---

4. Eradication

When: Bleeding stopped. Now remove the threat.

• Identify the root cause
• Remove malware, backdoors, or unauthorized access
• Patch the vulnerability that was exploited
• Verify the threat actor no longer has access
• Scan for indicators of compromise across other systems

---

5. Recovery

When: Threat removed. Restore operations.

Step	Verification
Restore systems from clean backups	Confirm backup integrity before restoring
Bring services back online gradually	Monitor for signs of reinfection
Verify data integrity	Compare against known-good states
Confirm with stakeholders	Operations formally restored

---

6. Lessons Learned

When: Within 5 business days of resolution

This is the step most teams skip. It is also the most valuable.

Question	Purpose
What happened?	Establish the facts
How was it detected?	Evaluate detection capabilities
How fast was the response?	Measure response time against targets
What worked well?	Reinforce effective practices
What failed or was slow?	Identify improvement areas
What changes are needed?	Assign actions and deadlines

A security program that does not learn from incidents is a program that repeats them.

Incident Response Roles and Responsibilities

Role	Responsibility
Incident Commander	Owns the response. Makes escalation and containment decisions. Coordinates all teams.
Security Lead / CISO	Technical leadership. Oversees investigation, containment, and eradication. Advises on risk.
Engineering	Executes containment and recovery actions. Provides system access and technical context.
Legal	Advises on regulatory notification obligations. Reviews external communications.
Communications / PR	Manages external messaging. Drafts customer notifications. Handles media inquiries.
Executive Leadership	Informed on business impact. Approves major decisions (full shutdown, public disclosure).
HR	Involved when incidents involve employee misconduct or insider threats.

Every person on this list should know their role before an incident occurs. Assign alternates for every critical role.

What Is an Incident Response Playbook?

An incident response plan defines the overall process. A playbook defines the specific steps for a specific type of incident.

	Incident Response Plan	Incident Response Playbook
Scope	All incidents	One specific scenario
Detail level	Process and roles	Step-by-step actions
Example	"We will follow NIST phases"	"If phishing is confirmed, do steps 1-8"
Audience	All responders	Team handling that scenario

You need one IRP. You need multiple playbooks.

Example Incident Response Playbooks

---

Playbook: Phishing Attack

Step	Action	Who
1	User reports suspicious email or click	Any employee
2	Security team triages the report	Security lead
3	Check if credentials were entered on the phishing site	Security lead
4	If yes: immediately reset password and revoke all sessions	IT / Security
5	Review authentication logs for the compromised account	Security lead
6	Check if the attacker accessed any systems or data	Engineering
7	Block the phishing domain across email gateway and DNS	IT
8	Notify affected users, require password resets for anyone who clicked	Security lead
9	Report to management if data exposure occurred	Incident commander
10	Update email filtering rules, conduct targeted awareness training	Security lead

---

Playbook: Credential Compromise

Step	Action	Who
1	Identify compromised account(s) and scope of access	Security lead
2	Immediately revoke all sessions and reset credentials	IT / Security
3	Enable MFA if not already in place	IT
4	Review access logs for unauthorized actions during compromise window	Security lead
5	Check for lateral movement to other systems	Engineering
6	Determine how credentials were compromised (phishing, reuse, leak)	Security lead
7	Scan for other accounts using the same password	IT
8	Notify affected data owners if data was accessed	Incident commander
9	Document timeline and evidence	Security lead

---

Playbook: Ransomware

Step	Action	Who
1	Immediately isolate affected systems from the network	Engineering
2	Do NOT pay ransom without executive and legal approval	Executive + Legal
3	Identify the ransomware variant if possible	Security lead
4	Determine scope: which systems, which data	Engineering
5	Check backup integrity. Verify backups are not compromised	Engineering
6	Engage external incident response support if needed	CISO
7	Notify law enforcement and legal counsel	Legal
8	Restore from clean backups once threat is eradicated	Engineering
9	Reset all credentials for affected systems	IT
10	Conduct full post-incident review	Incident commander

---

Playbook: Data Breach (Personal Data Exposed)

Step	Action	Timeline
1	Confirm the breach: what data, how many records, what categories	Immediate
2	Contain the source of the breach	Immediate
3	Preserve all evidence and logs	Immediate
4	Notify legal counsel	Within 1 hour
5	Assess whether GDPR notification is required	Within 4 hours
6	Notify supervisory authority (if required)	Within 72 hours
7	Notify affected data subjects (if high risk)	Without undue delay
8	Document everything: timeline, actions, decisions, evidence	Ongoing
9	Prepare internal incident report	Within 5 days
10	Post-incident review, update DPAs if vendor-related	Within 5 days

---

Playbook: Cloud Misconfiguration

Step	Action	Who
1	Identify misconfiguration (public bucket, exposed DB, open security group)	Security / Engineering
2	Determine what data was exposed and for how long	Security lead
3	Fix the configuration immediately	Engineering
4	Review access logs for unauthorized access during exposure window	Security lead
5	Assess whether personal data was involved	Security lead + Legal
6	If personal data involved: follow data breach playbook	Incident commander
7	Scan all environments for similar misconfigurations	Engineering
8	Implement preventive controls (IaC, config scanning)	Engineering
9	Document findings and update security baseline	Security lead

Data Breach Response and Reporting

What Qualifies as a Data Breach

Under GDPR, a personal data breach is any security incident that leads to:

• Unauthorized access to personal data
• Unauthorized disclosure of personal data
• Loss of personal data (including accidental deletion without backup)
• Alteration of personal data without authorization

A breach does not require a malicious actor. Accidentally emailing customer data to the wrong person is a breach.

GDPR 72-Hour Notification Requirement

When a personal data breach occurs, GDPR requires:

Notification to supervisory authority (Article 33):

• Within 72 hours of becoming aware of the breach
• If you cannot notify within 72 hours, provide reasons for the delay
• Must include: nature of the breach, categories and approximate number of data subjects, contact details of the DPO, likely consequences, measures taken

Notification to data subjects (Article 34):

• Required when the breach is likely to result in a high risk to individuals
• Must be in clear, plain language
• Must describe the nature of the breach and recommended protective actions

What to Include in a Breach Report

Element	Details
Description	Nature of the breach, how it occurred
Timeline	When discovered, when contained, when reported
Data affected	Types of personal data, categories of data subjects
Scope	Number of records and individuals affected
Consequences	Likely impact on affected individuals
Measures taken	Containment, remediation, and mitigation actions
Contact	DPO or security lead contact information
Preventive actions	Steps to prevent recurrence

Incident Response Checklist

Phase	Timeline	Actions
Immediate	First 30 minutes	Alert triaged. Incident commander assigned. Severity classified. Incident channel opened. Initial containment started. Evidence preservation begun.
Short-term	First 4 hours	Scope of impact determined. Affected systems and data identified. Legal notified (if personal data). Executive leadership briefed. Communication hold in place. Root cause investigation underway.
Medium-term	24 to 72 hours	Full containment confirmed. Eradication complete. GDPR notification assessment done. Supervisory authority notified (if required). Customer notification drafted. Documentation updated.
Post-incident	Within 5 business days	Post-incident review conducted. Root cause documented. IRP and playbooks updated. Improvements assigned with deadlines. Final incident report filed.

Common Mistakes Companies Make

No clear roles assigned

Everyone assumes someone else is handling it. Without a named incident commander and clear role assignments, the first hour is wasted figuring out who does what.

No playbooks for common scenarios

The IRP says "respond to incidents." But when a phishing email compromises a credential, nobody knows the specific steps. Generic plans produce generic responses. Playbooks produce fast, effective ones.

No logging or evidence

You cannot investigate what you did not log. If your systems do not have audit logging enabled, you will not know what the attacker accessed, when they got in, or whether they are still inside.

Delayed regulatory reporting

Some teams wait until the investigation is complete before notifying regulators. Under GDPR, the 72-hour clock starts when you become aware of the breach, not when the investigation concludes. Delayed notification is itself a violation.

No post-incident review

The incident is resolved. Everyone moves on. Nobody documents what happened or what should change. The same type of incident occurs six months later with the same response failures.

How to Operationalize Incident Response

Logging and monitoring

Enable audit logging on every critical system: cloud infrastructure, application, database, identity provider, email. If it is not logged, it is invisible during an incident.

Alerting and on-call

Configure meaningful alerts. An alert that fires 50 times a day gets ignored. An alert tied to a specific threat indicator gets attention. Establish an on-call rotation so someone is always watching.

Tabletop exercises

Run a simulated incident with your team at least twice a year. Walk through a scenario step by step. Identify gaps in your plan, your tooling, and your team's readiness. This is the single most effective way to improve incident response.

Documentation

Keep your IRP, playbooks, escalation contacts, and communication templates in a location that is accessible during a crisis. If your IRP is in a wiki that requires VPN access, and the VPN is compromised, your plan is useless.

Continuous improvement

After every incident and every tabletop exercise, update your plan. Incident response is not a static document. It is an evolving practice.

Tools and Automation

Effective incident response depends on having the right infrastructure in place before incidents occur:

• Logging and SIEM: Centralized log collection and correlation for detection and investigation
• Alerting: Configured thresholds with on-call routing
• Ticketing: Dedicated incident tracking with timeline, assignments, and status
• Communication: Pre-configured channels and templates

Security operations platforms like Aertous integrate incident management with your broader security program. Incidents are tracked with severity, assignment, and comments. Every incident feeds into your compliance evidence automatically, so when the SOC 2 auditor asks for your incident log, the evidence is already there. No retroactive scramble.

The goal is simple: when an incident occurs, your team responds from a playbook. When the auditor asks about it, the evidence already exists.

Conclusion

Every company will face a security incident. The question is whether you will respond from a plan or make it up as you go.

Build the plan now. Write playbooks for the five scenarios most likely to hit your organization. Assign roles. Test it. Then do it again.

The companies that handle incidents well are not the ones that never get breached. They are the ones that detect fast, contain fast, communicate clearly, and learn from every event. That discipline is what separates a security program from a compliance checkbox.

Incidents are inevitable. The damage they cause is not.

Frequently Asked Questions

What is an incident response plan?

An incident response plan (IRP) is a documented set of procedures that defines how an organization detects, responds to, contains, and recovers from security incidents. It includes roles and responsibilities, escalation paths, communication procedures, and coordination with legal and regulatory requirements.

What are the steps of incident response?

The standard incident response lifecycle includes six phases: preparation, identification, containment, eradication, recovery, and lessons learned. Preparation happens before incidents occur. The remaining five phases are executed during and after each incident.

What is an incident response playbook?

A playbook is a detailed, scenario-specific guide that defines the exact steps to take for a particular type of incident. While an IRP covers the overall process, a playbook covers actions for specific scenarios like phishing attacks, ransomware, credential compromise, or data breaches.

How do you respond to a data breach?

Confirm the breach and assess scope. Contain the source immediately. Preserve evidence. Notify legal counsel. Determine whether regulatory notification is required. If GDPR applies, notify the supervisory authority within 72 hours. Notify affected individuals if there is high risk. Document everything and conduct a post-incident review.

What is the GDPR breach notification timeline?

GDPR requires notification to the supervisory authority within 72 hours of becoming aware of a personal data breach. If notification cannot be made within 72 hours, reasons for the delay must be provided. Notification to affected individuals must be made "without undue delay" if the breach poses high risk.

What should be included in an incident report?

An incident report should include: description of the incident, timeline of events, data and systems affected, scope (records and individuals impacted), root cause, containment and remediation actions taken, regulatory notifications made, and recommendations for preventing recurrence.

Who is responsible for incident response?

The incident commander leads the response. The security lead or CISO provides technical direction. Engineering executes containment and recovery. Legal advises on regulatory obligations. Communications manages external messaging. Executive leadership approves major decisions. All roles should be assigned before an incident occurs.

How often should incident response plans be tested?

Incident response plans should be tested through tabletop exercises at least twice a year. Plans should also be reviewed and updated after every real incident, after significant organizational changes, and when new threat scenarios emerge. Testing is the only way to discover whether the plan actually works under pressure.

What is the difference between an incident and a breach?

A security incident is any event that threatens the confidentiality, integrity, or availability of information. A data breach is a specific type of incident where personal or sensitive data is actually accessed, disclosed, or lost without authorization. All breaches are incidents, but not all incidents are breaches.

Do startups need an incident response plan?

Yes. SOC 2 and ISO 27001 both require documented incident response procedures. GDPR requires breach notification capabilities. Beyond compliance, having a plan prevents chaos during real incidents. A startup with a 2-page IRP and tested playbooks is better prepared than an enterprise with an unread 50-page document.