Security Incident Reporting Template

Standard Operating Procedure: Security Incident Reporting Protocol

Document Identifier: SOP-SEC-042
Classification: Restricted – Internal Operations Only

---

1. Document Control & Revision History

---

2. Executive Summary & Scope

2.1 Purpose

This Standard Operating Procedure (SOP) defines the mandatory lifecycle for identifying, classifying, documenting, and escalating security incidents across all enterprise environments. Compliance ensures institutional resilience, forensic preservation, and regulatory adherence.

2.2 Operational Boundaries

This procedure applies to all corporate networks, cloud infrastructure, endpoints, software-as-a-service (SaaS) deployments, and physical facilities owned, leased, or operated by the enterprise. It governs all internal personnel, contractors, and third-party vendors handling enterprise data assets.

2.3 Regulatory & Compliance Standards

Operations governed by this SOP must strictly align with:

• ISO/IEC 27001:2022 (Information Security Management Systems)
• NIST SP 800-61 Rev. 2 (Computer Security Incident Handling Guide)
• GDPR (Articles 33 & 34: Data Breach Notification Protocols)
• HIPAA / PCI-DSS v4.0 (Where applicable to distinct data verticals)

---

3. Prerequisites & Tool Requirements

Execution of this SOP requires verified access, specialized tooling, and designated clearances prior to incident intake.

3.1 Software & Infrastructure Access

• SIEM Platform: Enterprise Security Information and Event Management (e.g., Splunk Enterprise Security, Datadog Security) with administrative query access.
• EDR Solution: Endpoint Detection and Response console (e.g., CrowdStrike Falcon) configured for containment operations.
• Ticketing & ITSM: Enterprise ITSM platform (e.g., ServiceNow Security Operations) with elevated P1 incident creation rights.
• Secure Collaboration: Out-of-band communication bridge (e.g., encrypted internal Matrix/Element server or dedicated PagerDuty bridge).

3.2 Certifications & Clearances

• Personnel executing Phases 3 through 5 must hold active GIAC Certified Incident Handler (GCIH), CISSP, or internal equivalent tier-2/tier-3 SOC analyst certification.
• Background check and security clearance level 2 or higher required for access to the enterprise incident vault.

---

4. Roles & Responsibilities (RACI Matrix Table)

RACI Definitions: Responsible (The doer), Accountable (The owner), Consulted (In the loop / advisory), Informed (Kept updated).

---

5. Step-by-Step Operational Procedure

Phase 1: Detection and Triage

• 1.1 Ingest security alert from SIEM, EDR, or manual employee submission via security@enterprise.internal.
• 1.2 Open an emergency tracking ticket within the Enterprise ITSM platform using the SEC-INC-TEMPLATE.
• 1.3 Assign initial priority rating based on the CIA triad impact (Confidentiality, Integrity, Availability):
  • P1 (Critical): Active data exfiltration, ransomware deployment, or compromise of core identity providers.
  • P2 (High): Isolated malware infection, targeted phishing with credential harvesting, unauthorized privilege escalation.
  • P3 (Moderate/Low): Policy violations, non-exploited vulnerability scans, false positives.
• 1.4 Verify alert authenticity to rule out known administrative testing or scheduled maintenance windows.

Phase 2: Containment, Eradication, and Recovery

• 2.1 Convene the incident command bridge within 15 minutes for P1/P2 incidents.
• 2.2 Execute containment strategies based on asset classification:
  • Network Isolation: Issue API command via EDR to disconnect compromised endpoints from corporate networks while preserving volatile memory.
  • Credential Revocation: Force immediate session termination and password reset for compromised accounts via Identity and Access Management (IAM) console.
  • Traffic Filtering: Implement emergency firewall or WAF rules to block malicious IP ranges or ingress vectors.
• 2.3 Acquire volatile memory dumps and disk images from affected systems following strict chain-of-custody documentation procedures.
• 2.4 Eradicate the threat vector by removing malicious binaries, closing exploited vulnerabilities, and patching associated codebases.
• 2.5 Restore systems from verified, uncompromised backups and validate system integrity through baseline comparison tooling.

Phase 3: Documentation and Reporting

• 3.1 Complete all mandatory fields within the master security incident reporting template (Appendix A).
• 3.2 Document the precise timeline of events, including initial indicator of compromise (IoC), containment timestamp, and remediation verification.
• 3.3 Calculate final business impact metrics, including data volume affected, downtime duration, and estimated financial impact.
• 3.4 Submit the finalized incident report package to the CISO and Compliance Counsel within 24 hours of incident closure.

---

6. Quality Assurance & Verification Criteria

To ensure institutional rigor, all closed incidents must pass the following audit benchmarks before removal from active status:

• Audit Checklist:
  • Chain-of-custody logs cryptographically signed and stored in the secure evidence vault.
  • All IoCs (hashes, IPs, domains) successfully shared with threat intelligence sharing platforms (e.g., MISP).
  • Root cause analysis (RCA) completed and peer-reviewed by an independent security engineer.
• Tolerance Thresholds:
  • Time to Acknowledge (TTA): $\le 5$ minutes for P1; $\le 15$ minutes for P2.
  • Time to Contain (TTC): $\le 30$ minutes for P1 isolation actions.
• Acceptance Benchmarks: Zero residual backdoors identified via post-remediation vulnerability scans and behavioral monitoring over a 72-hour observation window.

---

7. Practical Troubleshooting Scenarios

Scenario A: EDR Isolation Command Fails Due to Host Disconnection

• Condition: An infected endpoint goes offline or loses heartbeat before the EDR remote isolation command can execute, leaving the system potentially active on a local subnet or external network.
• Immediate Corrective Action Protocol:
  1. Coordinate immediately with network operations to invoke port-level or VLAN-level shutdown on the upstream switch or access point servicing the asset.
  2. Issue a global revocation of the device's VPN and corporate Wi-Fi certificates via the RADIUS/IAM server to block lateral network access.
  3. Issue a remote wipe command via Mobile Device Management (MDM) if the asset is a mobile or roaming endpoint.
  4. Log the precise time of network-level severance in the incident report.

Scenario B: Evidence Contamination During Volatile Memory Acquisition

• Condition: An analyst improperly executes a live memory capture tool, modifying system file metadata and altering potential forensic artifacts on the target system.
• Immediate Corrective Action Protocol:
  1. Immediately halt the current acquisition script to prevent further alterations.
  2. Document the exact command executed, the timestamp, and the nature of the state modification in the incident ledger.
  3. Flag the affected system as "Compromised Forensic Integrity" and exclude its file metadata from legal admissibility standards.
  4. Pivot immediately to fallback evidentiary sources: network flow logs (NetFlow/IPFIX), centralized SIEM telemetry, and immutable cloud storage audit logs to reconstruct the event timeline.
  5. File an internal deviation memo to the Incident Commander detailing the procedural exception.