# Incident Response Playbook Template

## Purpose

This playbook provides a structured approach to detecting, responding to, and recovering from information security incidents. Essential for E-ITS, ISO 27001, SOC 2, GDPR breach notifications, and effective cybersecurity operations.

## When to Use

- Security incident occurs (confirmed or suspected)
- Data breach detected
- System compromise or unauthorized access
- Ransomware or malware infection
- DDoS attack
- GDPR breach notification required
- Compliance audit preparation (demonstrate incident capability)

## How to Use

1. **Detect**: Identify and verify the incident
2. **Contain**: Isolate affected systems to prevent spread
3. **Investigate**: Analyze scope, cause, and impact
4. **Eradicate**: Remove threat and restore secure state
5. **Recover**: Return to normal operations
6. **Learn**: Document lessons and improve defenses

## Official References

- **ISO 27001:2022**: Annex A 5.24-5.28 (Incident management)
- **E-ITS**: § 15 Intsidentide käsitlemise kord
- **GDPR**: Article 33 (Breach notification to authority within 72h)
- **NIST SP 800-61**: Computer Security Incident Handling Guide

---

## Incident Severity Classification

| **Severity** | **Description** | **Response Time** | **Escalation** |
|--------------|-----------------|-------------------|----------------|
| **P1 - Critical** | Major data breach, ransomware, critical system down | < 15 minutes | CEO, Board, Authorities |
| **P2 - High** | Significant unauthorized access, major malware, key system degraded | < 1 hour | CISO, Senior Management |
| **P3 - Medium** | Minor breach attempt, localized infection, non-critical system impact | < 4 hours | IT Manager, Department Head |
| **P4 - Low** | Failed attack attempt, policy violation, informational finding | < 24 hours | Security Team, Ticket System |

---

## Incident Response Team (IRT)

### Roles & Responsibilities

| **Role** | **Responsible** | **Primary Duties** |
|----------|----------------|-------------------|
| **Incident Commander** | CISO / IT Manager | Overall coordination, decision authority, communication |
| **Technical Lead** | Senior IT Engineer | Technical analysis, containment, system recovery |
| **Communications Lead** | PR / Legal | Internal/external communications, media, stakeholders |
| **Legal Counsel** | Legal Advisor | Legal implications, regulatory requirements, liability |
| **Data Protection Officer** | DPO | GDPR compliance, breach notifications, data subject rights |
| **Business Continuity** | BCP Coordinator | Service continuity, failover, alternative processes |
| **Documentation Lead** | Designated recorder | Incident log, timeline, evidence chain of custody |

### Contact Information

| **Role** | **Name** | **Phone** | **Email** | **Backup** |
|----------|----------|-----------|-----------|------------|
| Incident Commander | _________ | _________ | _________ | _________ |
| Technical Lead | _________ | _________ | _________ | _________ |
| Communications Lead | _________ | _________ | _________ | _________ |
| Legal Counsel | _________ | _________ | _________ | _________ |
| DPO | _________ | _________ | _________ | _________ |

---

## Phase 1: DETECTION & INITIAL RESPONSE

### 1.1 Incident Detection Sources

- [ ] Security monitoring/SIEM alerts
- [ ] Antivirus/EDR detections
- [ ] IDS/IPS notifications
- [ ] User reports (suspicious emails, system behavior)
- [ ] Third-party notifications (vendor, CERT, customer)
- [ ] Audit log anomalies
- [ ] Performance degradation
- [ ] Media/public disclosure

### 1.2 Initial Assessment (< 15 minutes)

**Date/Time Detected**: ________________
**Reported By**: ________________
**Initial Severity**: ☐ P1  ☐ P2  ☐ P3  ☐ P4

**Initial Observations**:
- What happened? _________________________________
- Which systems/data affected? _________________________________
- Any immediate risks? _________________________________
- Estimated user impact? _________________________________

### 1.3 Activate Incident Response

- [ ] Log incident in tracking system (Incident ID: ________)
- [ ] Notify Incident Commander
- [ ] Assemble IRT (based on severity)
- [ ] Establish communication channel (war room, Slack channel)
- [ ] Start incident timeline documentation
- [ ] Begin evidence preservation

---

## Phase 2: CONTAINMENT

### 2.1 Short-Term Containment (Stop the Bleeding)

**Objective**: Prevent incident from spreading while preserving evidence

**Actions**:
- [ ] Isolate affected systems (network segmentation, disconnect)
- [ ] Disable compromised user accounts
- [ ] Block malicious IPs/domains at firewall/WAF
- [ ] Quarantine infected devices
- [ ] Snapshot affected systems for forensics
- [ ] Change passwords for potentially compromised accounts
- [ ] Enable enhanced monitoring on related systems
- [ ] Implement access restrictions to affected data

**Containment Strategy**:
☐ Full isolation (air-gap affected systems)
☐ Partial isolation (restrict network access)
☐ No isolation (monitor only - forensic preservation)

**Rationale**: _________________________________

### 2.2 Evidence Preservation

- [ ] Capture memory dumps (volatile data)
- [ ] Clone disk images
- [ ] Preserve log files (before rotation)
- [ ] Screenshot error messages/alerts
- [ ] Document network connections
- [ ] Save email headers/phishing samples
- [ ] Maintain chain of custody log

**Evidence Location**: _________________________________
**Custodian**: _________________________________

### 2.3 Long-Term Containment (Sustained Operations)

**Objective**: Maintain business operations while incident is resolved

- [ ] Implement temporary patches/workarounds
- [ ] Failover to backup systems
- [ ] Deploy emergency access controls
- [ ] Activate business continuity plan (if needed)
- [ ] Set up secure alternative communication channels

---

## Phase 3: INVESTIGATION & ANALYSIS

### 3.1 Scope Determination

**Affected Assets**:
- Systems: _________________________________
- Data: _________________________________
- Users: _________________________________
- Third parties: _________________________________

**Timeline**:
- First malicious activity: _________________________________
- Detection time: _________________________________
- Response initiated: _________________________________
- Dwell time (compromise to detection): _________________________________

### 3.2 Root Cause Analysis

**Attack Vector**:
☐ Phishing email
☐ Malware/ransomware
☐ Exploited vulnerability (CVE: _______)
☐ Weak/stolen credentials
☐ Insider threat
☐ Supply chain compromise
☐ Misconfiguration
☐ Physical security breach
☐ Other: _________________________________

**Attacker Profile** (if identifiable):
- Sophistication: ☐ Low  ☐ Medium  ☐ High  ☐ Advanced Persistent Threat (APT)
- Motivation: ☐ Financial  ☐ Espionage  ☐ Disruption  ☐ Opportunistic
- Indicators of Compromise (IoCs): _________________________________

### 3.3 Impact Assessment

**Data Affected**:
- Type: ☐ Personal Data (GDPR)  ☐ Financial  ☐ Health  ☐ Trade Secrets  ☐ Confidential
- Volume: _________ records
- Sensitivity: ☐ Public  ☐ Internal  ☐ Confidential  ☐ Restricted
- GDPR breach? ☐ Yes  ☐ No

**Business Impact**:
- Financial loss: € _________
- Downtime: _________ hours
- Customers affected: _________
- Reputational damage: ☐ Low  ☐ Medium  ☐ High  ☐ Severe

**Legal/Regulatory Impact**:
- GDPR notification required? ☐ Yes  ☐ No
- Other regulatory notifications: _________________________________
- Potential fines/penalties: € _________

---

## Phase 4: ERADICATION

### 4.1 Threat Removal

- [ ] Remove malware/backdoors
- [ ] Patch exploited vulnerabilities
- [ ] Rebuild compromised systems from clean backups
- [ ] Delete unauthorized accounts/access
- [ ] Revoke compromised certificates/keys
- [ ] Update firewall/IDS rules
- [ ] Reset all potentially compromised passwords

### 4.2 Verification

- [ ] Scan all systems for residual infection
- [ ] Verify no backdoors remain
- [ ] Confirm patches applied successfully
- [ ] Test restored functionality
- [ ] Run integrity checks on data/systems
- [ ] Confirm IoCs no longer present

---

## Phase 5: RECOVERY

### 5.1 Service Restoration

- [ ] Restore systems from clean backups
- [ ] Bring systems back online incrementally
- [ ] Monitor closely for re-infection
- [ ] Verify data integrity
- [ ] Test business critical functions
- [ ] Communicate restoration to stakeholders

**Restoration Timeline**:
| **System** | **Priority** | **Start Time** | **Completion** | **Status** |
|------------|--------------|----------------|----------------|------------|
| _______  | P1 | _______ | _______ | ☐ Done |
| _______  | P2 | _______ | _______ | ☐ Done |

### 5.2 Enhanced Monitoring

**Period**: 30 days post-recovery

- [ ] Increase log retention
- [ ] Daily review of security alerts
- [ ] Monitor for IoCs
- [ ] User activity audits
- [ ] Network traffic analysis

---

## Phase 6: LESSONS LEARNED & IMPROVEMENT

### 6.1 Post-Incident Review Meeting

**Date**: _____________
**Attendees**: _________________________________

**Discussion Topics**:
1. What happened and why?
2. What worked well in our response?
3. What could be improved?
4. Were resources adequate?
5. Were procedures followed?
6. What preventative measures can we implement?

### 6.2 Root Cause & Corrective Actions

| **Finding** | **Root Cause** | **Corrective Action** | **Owner** | **Due Date** | **Status** |
|-------------|---------------|----------------------|-----------|------------|----------|
| _______ | _______ | _______ | _______ | _______ | ☐ Done |

### 6.3 Documentation & Closure

- [ ] Complete incident report
- [ ] Update risk register
- [ ] Update security controls (ISO 27001 Annex A)
- [ ] Revise policies/procedures based on findings
- [ ] Conduct follow-up training (if needed)
- [ ] Share anonymized learnings with team
- [ ] Archive evidence (retention: 7 years)
- [ ] Close incident ticket

---

## GDPR Breach Notification Requirements

### Notification to Supervisory Authority (AKI in Estonia)

**Deadline**: 72 hours from becoming aware of breach

**Required Information**:
- [ ] Nature of breach
- [ ] Categories and approximate number of data subjects
- [ ] Categories and approximate number of records
- [ ] Contact point (DPO)
- [ ] Likely consequences
- [ ] Measures taken or proposed

**Notification Method**: https://www.aki.ee/en/personal-data-breaches

### Notification to Data Subjects

**Required if**: High risk to rights and freedoms of individuals

**Communication**:
- [ ] Clear and plain language
- [ ] Describe nature of breach
- [ ] Contact point (DPO)
- [ ] Likely consequences
- [ ] Measures taken/recommended

**Exceptions**: Encrypted data (if keys not compromised), subsequent measures make risk unlikely

---

## Communication Templates

### Internal Notification (Staff)

**Subject**: [URGENT] Security Incident - Action Required

We are currently managing a security incident affecting [systems/data].

**What you need to know**:
- [Brief description]
- [Impact on your work]
- [What we're doing]

**What you should do**:
- [Specific actions]
- [Who to contact]

**Do not**:
- Discuss publicly or on social media
- Forward this message externally

More updates: [timeframe]
Questions: [contact]

### External Notification (Customers - GDPR)

**Subject**: Important Security Notification

We are writing to inform you of a data security incident that may have affected your personal information.

**What happened**: [Clear description]
**What data**: [Specific data types]
**What we're doing**: [Response actions]
**What you should do**: [Recommendations - change password, monitor accounts]
**Contact us**: [DPO contact]

We sincerely apologize for any concern this may cause.

---

## Incident Classification Examples

### P1 - Critical Incidents

- Ransomware encryption of production systems
- Confirmed data breach with >1,000 affected individuals
- Active external attack with root/admin access
- Critical infrastructure takedown (power, SCADA)
- Regulatory notification required

### P2 - High Incidents

- Malware infection across multiple systems
- Unauthorized access to confidential data
- DDoS attack causing service degradation
- Lost/stolen device with unencrypted sensitive data
- Insider threat investigation

### P3 - Medium Incidents

- Isolated malware on single workstation
- Failed intrusion attempt (blocked by controls)
- Phishing email bypassing filters (no clicks)
- Minor data leakage (non-sensitive)
- Policy violations

### P4 - Low Incidents

- Suspicious but unconfirmed activity
- Informational findings from scans
- User-reported potential incidents (false alarms)
- Minor policy violations with no data impact

---

## Additional Resources

### External Contacts

| **Organization** | **Purpose** | **Contact** |
|------------------|-------------|-------------|
| **CERT-EE** | National CERT Estonia | +372 663 0298, cert@cert.ee |
| **AKI** | Data Protection Authority | +372 627 4135, info@aki.ee |
| **Police** | Criminal investigation | 112 (emergency), local station |
| **Cyber Insurance** | Claims | [Your policy contact] |
| **Forensics Provider** | External investigation | [Retained firm contact] |

### Tools & Platforms

- Incident tracking: [Your ticketing system]
- Communication: [Secure chat/war room]
- Forensics: [Tools available]
- Backup/Recovery: [Backup system]
- Monitoring: [SIEM/SOC]

---

## Metrics & KPIs

Track incident response effectiveness:

- **Mean Time to Detect (MTTD)**: Time from incident occurrence to detection
- **Mean Time to Respond (MTTR)**: Time from detection to containment
- **Mean Time to Recover (MTTR)**: Time from incident to full service restoration
- **Incident Count**: Number of incidents by severity
- **False Positive Rate**: Alerts that were not actual incidents

---

**Template Version**: 1.0
**Last Updated**: 2024-01-04
**Source**: InfoPol - Free InfoSec Resources