Cybersecurity Incident Response Plan
Playbooks, technical procedures and checklists for the Response Team
1. Purpose and Document Structure
This Incident Response Plan (IRP) contains detailed technical and organisational procedures for the Response Team. It supplements DOC-005 (policy) and DOC-006 (reporting procedures). It covers:
- General response procedure (6 PICERL phases),
- Playbooks for the most common incident scenarios,
- Operational checklists,
- Crisis communication procedures.
ℹ️
The plan must be available offline – keep a printed copy in a secure location accessible without IT system access (systems may be unavailable during an incident).
▸ Organisation completes – offline copy location
Offline copy stored at: ▸ [e.g. CISO safe, main reception, each administrator has a printout]
Date of last offline copy update: ▸ DD/MM/YYYY
2. General Response Procedure – 6 PICERL Phases
| Phase | Name | Key actions | Responsible |
|---|---|---|---|
| P | Preparation | Maintain tools, training, plans; tests; CSIRT contacts up to date | ▸ CISO (ongoing) |
| I | Identification | Alert detection, initial analysis, P1–P4 classification, internal report | ▸ CISO / IT Admin |
| C | Containment | Short-term (isolation) + long-term (patch, hardening) | ▸ IT Admin / CISO |
| E | Eradication | Remove malware, close attack vector, verify | ▸ IT Admin |
| R | Recovery | Restore systems, verify, post-recovery monitoring | ▸ IT Admin / System Owner |
| L | Lessons Learned | PIR, update documentation, CSIRT report, Board communication | ▸ CISO |
3. Playbooks – Incident Scenarios
Playbooks for the most frequent and most serious incident types. The organisation may add sector-specific scenarios.
PB-001
Ransomware / System Encryption
Category: MAL | Priority: P1 | Response time: immediate
PHASE: Identification
- File encryption or ransom demand confirmed?
- Affected systems identified (IP list / names)?
- Estimated infection time established (when were last good files)?
- Is backup available and unaffected?
PHASE: Containment (perform IMMEDIATELY)
1
Disconnect infected systems from network (unplug cable/disable Wi-Fi) – DO NOT cut power without CISO approval
2
Block outbound traffic on ports 445, 139, 3389 at firewall (lateral movement)
3
Disable VPN connections and remote access for external suppliers
4
Notify CISO (tel. ▸ [number]) – initiate IRP Phase 2
5
Take RAM dump from infected systems (if possible – tool: ▸ [e.g. Magnet RAM Capture, WinPmem])
6
Preserve system logs, SIEM events, network traffic (PCAP from last 24–72h)
PHASE: Eradication
7
Identify ransomware variant (www.nomoreransom.org, VirusTotal)
8
Check if decryptor exists (nomoreransom.org) – DO NOT pay ransom without consulting Board and Legal
9
Format and reinstall infected systems (do not repair – reinstall)
10
Close infection vector (patch vulnerability, reset passwords, remove attacker account)
PHASE: Recovery
11
Restore from backup prior to infection (procedure DOC-012) – verify backup is clean
12
Verify integrity of restored data before returning to production
13
Monitor for min. ▸ [72h] after recovery for signs of re-infection
Reporting
🕐
Early warning to CSIRT: 24h | Notification: 72h (procedure in DOC-006)
▸ Organisation completes – specialist contacts
External IR (forensics): ▸ [company name, telephone]
Cyber insurer: ▸ [policy number, telephone]
PB-002
Account Takeover / Unauthorised Access
Category: ACC | Priority: P1 (privileged account) / P2 (regular account)
PHASE: Identification
- What triggered the alert – SIEM, MFA alert, user report, anomaly detection?
- Which account was compromised (privileged / standard)?
- What resources did it have access to?
- Is the account still active?
PHASE: Containment
1
Immediately block account in Active Directory / IAM:
Disable-ADAccount -Identity [user]2
Revoke all active sessions and tokens (e.g. in Azure AD: Revoke-AzureADUserAllRefreshToken)
3
Change passwords for service accounts accessible to the compromised account
4
Collect login logs from the last ▸ [30 days] (Active Directory, VPN, applications)
PHASE: Eradication and investigation
5
Log analysis – where did login originate, what actions were taken, was data exfiltrated
6
Check if attacker created backdoor accounts or modified other accounts' permissions
7
Password reset for user + enforce MFA before re-granting access
8
Assess whether personal data was breached → DPA notification obligation within 72h
PB-003
Data Breach / Exfiltration
Category: DAT | Priority: P1 (personal data / confidential) / P2 (internal data)
Special attention: GDPR
⚠️
Personal data breach → DPA notification within 72h (GDPR Art. 33).
If the breach may result in high risk to individuals' rights → notify the affected persons (GDPR Art. 34).
If the breach may result in high risk to individuals' rights → notify the affected persons (GDPR Art. 34).
- What data was leaked (category, number of records, personal data?)?
- Which individuals are affected?
- Where did the breach originate (source system)?
- Did data reach an unauthorised party?
- Is the data encrypted / pseudonymised?
PHASE: Containment
1
Block access to the system from which the breach occurred
2
Identify and block the exfiltration channel (email, FTP, cloud storage, USB)
3
Preserve evidence (DLP logs, database logs, network traffic)
PHASE: Legal assessment and reporting
4
Inform DPO / Legal Counsel – assess DPA notification obligation
5
DPA notification within 72h of confirmation of breach
6
Assess need to notify affected individuals (GDPR Art. 34)
7
Keep accurate documentation of decisions and steps taken (required by DPA)
PB-004
DDoS Attack – Service Unavailability
Category: NET | Priority: P1 (key services) / P2 (others)
- Which service / system is unavailable?
- What type of DDoS attack (volumetric, protocol, application layer)?
- Has the telecom operator been contacted?
- Is anti-DDoS protection available from the supplier?
Actions
1
Activate anti-DDoS protection at ISP / CDN (if available): ▸ [ISP contact details, contract number]
2
Implement rate limiting and geo-blocking at firewall/WAF level
3
Activate failover plan / backup link: ▸ [alternative ISP details]
4
Monitor traffic log – collect IoCs (source IPs, attack patterns)
5
If key service affected → early warning to CSIRT within 24h
▸ Organisation completes
Anti-DDoS provider: ▸ [name, 24/7 contact number]
Telecom operators (for upstream blocking): ▸ [name, telephone]
▸ Organisation adds sector-specific playbooks
Example additional playbooks to prepare:
PB-005: Phishing / Business Email Compromise (BEC)
PB-006: OT/SCADA system attack (if applicable)
PB-007: Supply chain system compromise
PB-008: Unauthorised physical access to IT infrastructure
4. Crisis Communications
📢
No external communication (media, clients, partners) without Board and Legal Counsel approval. CISO coordinates internal communications. Press Officer coordinates external.
4.1 Internal communications
| Recipient | Message content | Deadline | Channel |
|---|---|---|---|
| IR Team | Full technical information | Immediately | ▸ [e.g. Teams / Signal / telephone] |
| Board | Summary: what happened, impact, actions | Within 2h (P1) | ▸ [e.g. encrypted email / telephone] |
| Employees (if relevant) | Instructions: what to do / what not to do | As soon as possible | ▸ [e.g. group email / internal announcement] |
4.2 External communications
⚠ Critical – Board and Legal Counsel approval required before sending
| Recipient | Content | Responsible |
|---|---|---|
| CSIRT | Notification form (DOC-006 Annex B/C) | ▸ CISO |
| DPA (if personal data breach) | DPA notification form within 72h | ▸ CISO / DPO |
| Clients / users (if required by GDPR) | ▸ [notification template to be prepared] | ▸ Board / Legal |
| Media | Official press statement | ▸ Board / Press Officer |
| Suppliers affected by incident | Information on incident (if applicable) | ▸ CISO / Board |
5. IR Team Equipment and Tools
▸ Organisation completes – available tools
| Category | Tool (organisation fills in) | Location / access |
|---|---|---|
| SIEM | ▸ [e.g. Splunk / Microsoft Sentinel / OSSIM] | ▸ |
| EDR / Antivirus | ▸ [e.g. CrowdStrike / Defender / Sophos] | ▸ |
| Forensics – disk imaging | ▸ [e.g. FTK Imager / DD] | ▸ |
| Forensics – memory analysis | ▸ [e.g. Volatility / Magnet RAM] | ▸ |
| Network traffic analysis | ▸ [e.g. Wireshark / NetworkMiner] | ▸ |
| Incident management | ▸ [e.g. TheHive / Jira / ServiceNow] | ▸ |
| Emergency communication (out-of-band) | ▸ [e.g. mobile phones, Signal] | ▸ |
| Secure evidence storage | ▸ [e.g. dedicated offline drive in safe] | ▸ [location] |
6. Change History and Plan Tests
| Version | Date | Author | Description | Approved by |
|---|---|---|---|---|
| ▸ 1.0 | ▸ DD/MM/YYYY | ▸ | ▸ Initial release | ▸ Board |
Plan test history
| Test date | Test type | Scenario | Result | Corrective actions |
|---|---|---|---|---|
| ▸ DD/MM/YYYY | ▸ [Tabletop / Live drill] | ▸ [e.g. Ransomware P1] | ▸ [Pass / Partial / Unsatisfactory] | ▸ |
DOC-007 Incident Response Plan | v1.0 | NIS2/ISMS