Incident Response Plan (IRP)¶

1. Purpose and Scope¶

This plan describes how the company identifies, handles, escalates, and recovers from IT security incidents. It applies to all systems, data, and employees within the organization.

Types of incidents covered by this plan:

• Data breaches and unauthorized access
• Ransomware and malware attacks
• DDoS attacks and service outages
• Phishing and compromised accounts
• Loss or leakage of sensitive data (including GDPR-relevant incidents)
• Insider threats

2. Roles and Responsibilities¶

All employees are responsible for reporting suspicious activity to the Incident Commander immediately.

3. Incident Classification¶

4. The Incident Response Process (PICERL)¶

Phase 1 – Preparation (ongoing, not during an incident)¶

• Maintain this plan and the contact list (see Appendix A)
• Ensure all systems have up-to-date backups and test them quarterly
• Enforce MFA on all accounts (email, cloud services, VPN)
• Conduct at least one simulated phishing exercise and IRP walkthrough annually
• Maintain an offline list of critical systems, vendors, and credentials

Phase 2 – Identification¶

Goal: Confirm an incident has occurred and determine its scope and severity.

1. Receive report from employee, system alert, or external source
2. Incident Commander assesses and classifies the incident (P1–P4)
3. Document time of discovery, reporting party, and initial symptoms in the incident log (see Appendix B)
4. Activate relevant team members based on classification:
   • P1/P2: Assemble the full IRT team
   • P3: Incident Commander + Technical Lead
   • P4: Technical Lead handles independently

• What has been compromised? (systems, data, accounts)
• When did the incident occur - and is it still active?
• Does it involve personal data? (GDPR obligation)

Phase 3 – Containment¶

Goal: Stop the spread and limit the scope of damage.

Short-term containment (within hours):

• Isolate compromised devices from the network (unplug cable / disable WiFi)
• Disable compromised user accounts immediately
• Block suspicious IP addresses or domains in firewall/DNS
• Take screenshots and note observations before shutting down systems

Long-term containment (before recovery):

• Implement temporary workarounds to maintain business operations
• Monitor intensively for further activity
• Do not delete logs or modify systems that may serve as evidence

Never delete logs or compromised files before they have been preserved as evidence.

Phase 4 – Eradication¶

Goal: Fully remove the root cause of the incident.

• Identify and remove malware, backdoors, or malicious code
• Reset all passwords for affected accounts (and related accounts as needed)
• Patch or update vulnerable systems
• Review access permissions and remove unnecessary privileges
• Confirm the attack vector has been closed

Phase 5 – Recovery¶

Goal: Restore normal operations safely and in a controlled manner.

• Restore from verified, clean backups
• Bring systems online gradually and monitor intensively for a minimum of 72 hours
• Verify system integrity before full reinstatement
• Document when normal operations have resumed

Recovery priority:

1. Critical business systems (email, payment systems, customer data)
2. Internal productivity tools
3. Non-critical systems

Phase 6 – Lessons Learned¶

Goal: Improve future response and prevent recurrence.

Hold a post-mortem meeting within 5 business days of the incident:

• What happened, and when?
• What worked well in our response?
• What could we have done better?
• What specific actions must be implemented? (with owner and deadline)

Update this plan based on the findings.

5. Communication¶

Internal Communication¶

• The Incident Commander is the single point of contact - do not communicate broadly internally until the situation has been assessed
• Use an out-of-band communication channel if email is suspected to be compromised (e.g. Signal, phone)
• Brief leadership immediately for P1 and P2 incidents

External Communication¶

Personal data breaches must be reported to your national Data Protection Authority within 72 hours of discovery, unless the breach is unlikely to result in risk to individuals. Always document the decision to report or not to report.

Template: Internal Alert (P1/P2)¶

To: [IRT team]
Subject: 🚨 SECURITY INCIDENT – [Brief description] – [Date/time]

We have identified a potential security incident.

Type: [Ransomware / Data breach / Compromised account / Other]
Status: [Active / Under investigation / Contained]
Affected systems: [Systems/data]
Incident Commander: [Name]

Next update: [Time]
Contact: [Phone / Signal]

6. Evidence Preservation¶

The following must be documented and preserved as quickly as possible:

• Screenshots of error messages, suspicious activity, or attack indicators
• System and application logs (copy to a secure location)
• Network logs from firewall/router
• Timeline of observed events
• Communications related to the incident (emails, messages)

Store evidence in an isolated and secure location. Consider legal chain of custody if criminal activity is suspected.

Appendix A - Contact List¶

Also maintain an offline copy (printed).

Appendix B - Incident Log Template¶

INCIDENT LOG
============
Incident ID:      INC-[YYYY-MM-DD-XX]
Detected:         [Date and time]
Reported by:      [Name]
Classification:   P1 / P2 / P3 / P4

DESCRIPTION
-----------
[Brief description of what was observed]

TIMELINE
--------
[Date/time] – [Observation/action]
[Date/time] – [Observation/action]

AFFECTED SYSTEMS / DATA
-----------------------
[List of affected systems, data, users]

ACTIONS TAKEN
-------------
[Date/time] – [Who] – [What]

STATUS
------
[ ] Identification
[ ] Containment
[ ] Eradication
[ ] Recovery
[ ] Lessons Learned

GDPR RELEVANT: Yes / No
Reported to Data Protection Authority: Yes / No / Not required

9. Maintenance and Testing¶

This document is confidential and should not be distributed outside the organization without authorization.