Incident Response Plan Template Cyber Security

Standard Operating Procedure: Cyber Security Incident Response Plan (CSIRP)

1. Executive Summary & Purpose

This document establishes the institutional framework for detecting, containing, eradicating, and recovering from cyber security incidents at Template Registry. The purpose is to minimize system downtime, protect data integrity, and ensure regulatory compliance by standardizing the response lifecycle.

2. Scope & Prerequisites

• Scope: All digital assets, cloud infrastructure, on-premise hardware, and personnel endpoints managed by Template Registry.
• Required Tools:
  • SIEM/SOAR: (e.g., Splunk, Sentinel).
  • Communication: Out-of-band (OOB) channel (e.g., Signal, encrypted Slack workspace).
  • Forensics: Volatility, FTK Imager, Wireshark.
  • Ticketing: Jira Service Management (Restricted project access).

3. Roles & Responsibilities (RACI Matrix)

4. Step-by-Step Procedure

Phase I: Detection & Analysis

• Verify alert triggers via SIEM correlation logs.
• Determine incident classification (Low/Medium/High/Critical).
• Establish initial timeline of events.
• Notify Incident Lead and relevant stakeholders if classification is Medium+.

Phase II: Containment

• Short-term: Isolate affected endpoints (VLAN isolation or host-level network blocking).
• Short-term: Rotate credentials for compromised service accounts.
• Long-term: Patch vulnerabilities or apply firewall rules to block lateral movement.
• Capture forensic images/memory dumps before rebooting systems.

Phase III: Eradication

• Remove malware artifacts, malicious persistence mechanisms, and unauthorized accounts.
• Validate integrity of system backups.
• Conduct vulnerability scans on affected segments to ensure threat clearance.

Phase IV: Recovery

• Restore services from "Known Good" configurations.
• Implement enhanced monitoring (24/7 SIEM alert threshold) on restored assets.
• Document system restoration time and final state validation.

Phase V: Post-Incident Activity (Post-Mortem)

• Schedule a "Lessons Learned" meeting within 72 hours of closure.
• Update IR playbooks based on identified procedural gaps.
• Submit final incident report to the Compliance/Legal department.

5. Quality Assurance & Pro-Tips

• Pro-Tip 1: Never trust logs on a compromised host; use an external, immutable log repository (SIEM).
• Pro-Tip 2: Use Out-of-Band (OOB) communication. Attackers frequently monitor internal email/Slack if a credential has been leaked.
• Metric Threshold: Time to Containment (TTC) should not exceed 4 hours for Critical threats.
• Pitfall: Avoid "Analysis Paralysis." Execute containment steps based on heuristic probability rather than absolute certainty if data exfiltration is ongoing.

6. Frequently Asked Questions (FAQ)

Q: At what point do we contact law enforcement or regulators? A: Consult with Legal/General Counsel immediately upon confirming data exfiltration involving PII or regulated financial data. Do not delay if statutory reporting windows (e.g., GDPR 72-hour rule) are at risk.

Q: Should I reboot the machine to stop the attack? A: Absolutely not. Rebooting flushes volatile memory (RAM) where active malware processes and encryption keys reside. Perform a forensic capture first, then contain via network isolation.

Q: How do we handle internal leaks during an active incident? A: Strict "Need to Know" policy applies. Communication should only occur on pre-approved, encrypted channels. External status updates are handled exclusively by Corporate Communications.