Incident Response Execution SOP¶
Sub-procedure of incident-response-sop.md
Overview¶
Detailed procedures for executing incident response during active security incidents, including triage protocols, investigation procedures, containment strategies, and recovery validation. This sub-procedure covers the Active IR and IR Retainer service offerings.
Scope¶
Parent SOP: Incident Response Pillar: Protect (Security & Compliance) Service Area: Active Incident Response
Prerequisites¶
- Parent SOP requirements met
- IR retainer in place OR emergency engagement authorized
- Initial incident notification received
- Client point of contact identified
- Remote access or on-site access arranged
- Legal privilege considerations addressed
Procedure¶
Step 1: Initial Notification and Triage¶
Objective: Rapidly assess incident and determine response level
Notification Receipt Checklist:
| Information Needed | Purpose | Source |
|---|---|---|
| Incident description | Understand situation | Client contact |
| Discovery time | Establish timeline | Client contact |
| Current business impact | Assess severity | Client contact |
| Actions already taken | Avoid duplication/conflicts | Client contact |
| Affected systems | Scope determination | Client IT |
| Key contacts | Communication | Client contact |
| Environment access | Response capability | Client IT |
Initial Triage Questions:
| Question | Why It Matters |
|---|---|
| Is the incident ongoing or contained? | Determines immediate priority |
| What systems/data are affected? | Scopes the response |
| Is there evidence of data exfiltration? | Triggers notification assessment |
| Has business operations been impacted? | Determines urgency |
| Have law enforcement or regulators been contacted? | Coordination requirements |
| What is the client's primary concern? | Aligns response priorities |
Severity Determination:
| Severity | Criteria | Response Time | SBK Resources |
|---|---|---|---|
| Critical | Active breach, ransomware, confirmed data loss, major business impact | Immediate | Senior IR Lead + Team |
| High | Compromised systems, potential data exposure, significant business impact | 2-4 hours | IR Lead + Support |
| Medium | Contained malware, suspicious activity, limited business impact | 8-24 hours | IR Analyst |
| Low | Policy violation, minor event, no confirmed compromise | Next business day | IR Analyst |
Triage Output:
| Output | Content | Recipient |
|---|---|---|
| Severity Classification | Critical/High/Medium/Low | SBK Team, Client |
| Response Recommendation | Immediate actions, resource needs | Client |
| Engagement Scope | Estimated effort, team assignment | SBK Leadership |
| Initial Guidance | Preserve evidence, don't reboot, etc. | Client IT |
Step 2: Mobilization and Setup¶
Objective: Establish response capability and secure access
Response Team Mobilization:
| Role | Responsibilities | When Engaged |
|---|---|---|
| IR Lead | Overall coordination, client communication | All incidents |
| Technical Lead | Investigation, technical analysis | All incidents |
| Forensic Analyst | Evidence collection, analysis | High/Critical |
| Threat Intelligence | IOC analysis, threat actor research | As needed |
| Legal Liaison | Privilege, regulatory guidance | High/Critical |
Access and Environment Setup:
| Access Type | Purpose | Setup Requirements |
|---|---|---|
| VPN/Remote Access | Secure remote investigation | Client-provided credentials |
| SIEM Access | Log analysis, timeline development | Read access to security logs |
| Endpoint Access | Forensic collection, containment | EDR console, admin credentials |
| Cloud Console | Cloud investigation, containment | AWS/Azure/GCP read access |
| Network Access | Traffic analysis, containment | Firewall/NDR access |
| Communication Channel | Secure team communication | Encrypted chat/call setup |
Legal Privilege Establishment:
| Privilege Type | When to Use | Documentation |
|---|---|---|
| Attorney-Client | Legal exposure anticipated | Engagement through counsel |
| Work Product | Litigation anticipated | Investigation under counsel direction |
| None | Routine incident | Standard engagement letter |
Evidence Preservation Directive:
| Directive | Reason |
|---|---|
| Do not reboot affected systems | Preserves volatile memory evidence |
| Do not delete files or logs | Evidence preservation |
| Do not run antivirus scans | May destroy evidence |
| Document all actions taken | Chain of custody |
| Preserve network traffic if possible | Network evidence |
| Secure physical access | Prevent evidence tampering |
Step 3: Investigation¶
Objective: Determine incident scope, timeline, and root cause
Investigation Framework:
| Phase | Objective | Key Questions |
|---|---|---|
| Scoping | Determine affected systems/data | What systems are compromised? What data is at risk? |
| Timeline | Establish sequence of events | When did it start? What happened in what order? |
| Attribution | Understand attacker methods | How did they get in? What techniques were used? |
| Impact | Assess business and data impact | What data was accessed/stolen? What is the business impact? |
Evidence Collection:
| Evidence Type | Collection Method | Priority |
|---|---|---|
| Memory Images | Live memory capture (volatility) | High - collect before reboot |
| Disk Images | Forensic disk imaging | High - before modifications |
| Log Files | SIEM export, local log collection | High - time-sensitive |
| Network Traffic | PCAP, NetFlow, firewall logs | Medium - if available |
| Cloud Logs | CloudTrail, Azure Activity, GCP Audit | High - may expire |
| Endpoint Telemetry | EDR timeline, process execution | High - critical for investigation |
Timeline Development:
| Timeline Element | Sources | Documentation |
|---|---|---|
| Initial Access | Logs, email analysis, web logs | Entry point and method |
| Lateral Movement | Authentication logs, network traffic | Path through environment |
| Privilege Escalation | Endpoint logs, security events | How access was elevated |
| Data Access | File access logs, database logs | What was accessed |
| Data Exfiltration | Network logs, DLP alerts | What was taken |
| Persistence | Endpoint analysis, scheduled tasks | How attacker maintained access |
Indicator of Compromise (IOC) Development:
| IOC Type | Examples | Use |
|---|---|---|
| IP Addresses | C2 servers, external connections | Network blocking, log search |
| Domains | Malicious domains, phishing sites | DNS blocking, log search |
| File Hashes | Malware, tools | Endpoint scanning |
| File Names | Dropped files, scripts | Endpoint scanning |
| Registry Keys | Persistence mechanisms | Endpoint scanning |
| User Accounts | Compromised or created accounts | Account review |
Step 4: Containment¶
Objective: Stop incident spread and limit damage
Containment Strategy Selection:
| Strategy | When to Use | Trade-offs |
|---|---|---|
| Network Isolation | Active C2, lateral movement | May impact business operations |
| Account Disable | Compromised credentials | May lock out legitimate users |
| Endpoint Isolation | Actively infected systems | Endpoint inaccessible |
| Network Block | Known malicious IPs/domains | May block legitimate traffic |
| Service Shutdown | Compromised application | Business impact |
Containment Actions by Incident Type:
| Incident Type | Primary Containment | Secondary Actions |
|---|---|---|
| Ransomware | Isolate affected systems, disable shares | Block C2, disable compromised accounts |
| Data Breach | Isolate affected systems, block exfil paths | Disable compromised accounts, preserve evidence |
| BEC | Disable compromised account, hold transfers | Review email rules, notify financial institutions |
| Malware | Isolate infected endpoints | Block IOCs, scan for spread |
| Insider Threat | Disable account, preserve evidence | HR coordination, legal engagement |
Containment Documentation:
| Element | Documentation Required |
|---|---|
| Action Taken | Specific containment action |
| Timestamp | When action was executed |
| Executed By | Who performed the action |
| Systems Affected | What systems were impacted |
| Business Impact | Effect on operations |
| Evidence Preserved | Evidence before containment |
Step 5: Eradication¶
Objective: Remove threat from environment
Eradication Activities:
| Activity | Purpose | Validation |
|---|---|---|
| Malware Removal | Eliminate malicious software | Clean scan results |
| Credential Reset | Eliminate compromised credentials | No unauthorized access |
| Backdoor Removal | Eliminate persistence mechanisms | No suspicious scheduled tasks, services |
| Vulnerability Remediation | Close attack vector | Patched systems, configuration changes |
| Account Cleanup | Remove unauthorized accounts | Account audit complete |
Eradication Validation:
| Validation Method | What It Confirms |
|---|---|
| Full AV/EDR Scan | No remaining malware |
| IOC Sweep | No indicators of compromise |
| Log Review | No ongoing malicious activity |
| Network Monitoring | No C2 communication |
| Account Audit | No unauthorized accounts |
| Configuration Review | Proper security configuration |
Credential Reset Scope:
| Credential Type | When to Reset | Method |
|---|---|---|
| Affected User Accounts | Confirmed compromise | Immediate reset, MFA re-enrollment |
| Admin Accounts | Any privileged access concern | Immediate reset, review access |
| Service Accounts | Lateral movement detected | Coordinate with application owners |
| All Accounts | Extensive compromise | Phased reset with communication |
Step 6: Recovery¶
Objective: Restore normal operations safely
Recovery Prioritization:
| Priority | Criteria | Timeline |
|---|---|---|
| Critical | Core business operations, revenue-generating | Immediate |
| High | Important business functions | 24-48 hours |
| Medium | Supporting functions | 48-72 hours |
| Low | Non-essential functions | As resources allow |
Recovery Methods:
| Method | When to Use | Considerations |
|---|---|---|
| Clean and Restore | Malware can be removed | Faster, preserves data |
| Reimage | Deep infection, rootkit | Complete clean, requires rebuild |
| Restore from Backup | Data loss, ransomware | Verify backup integrity |
| Rebuild | Extensive compromise | Most thorough, most time-consuming |
Recovery Validation:
| Validation | Purpose | Method |
|---|---|---|
| System Integrity | Confirm clean state | Scan, IOC sweep |
| Data Integrity | Confirm data accuracy | Comparison, testing |
| Functionality | Confirm systems work | Application testing |
| Security | Confirm secure configuration | Security scan |
| Monitoring | Confirm detection capability | Verify logging, alerting |
Enhanced Monitoring Post-Recovery:
| Monitoring Focus | Duration | Purpose |
|---|---|---|
| Affected Systems | 30 days | Detect any recurrence |
| Network Traffic | 30 days | Identify missed IOCs |
| User Accounts | 30 days | Detect credential misuse |
| Similar Attack Vectors | 90 days | Prevent repeat attack |
Step 7: Post-Incident Activities¶
Objective: Document incident and identify improvements
Incident Documentation:
| Document | Content | Timeline |
|---|---|---|
| Incident Timeline | Chronological event sequence | During investigation |
| Technical Report | Detailed technical findings | Within 5 days |
| Executive Summary | High-level incident summary | Within 3 days |
| Lessons Learned | Improvement opportunities | Within 10 days |
| Regulatory Assessment | Notification determination | With legal, within 72 hours |
Notification Assessment:
| Assessment Element | Evaluation |
|---|---|
| Data types exposed | PII, PHI, PCI, etc. |
| Number of individuals | Scope of exposure |
| Applicable regulations | HIPAA, state laws, GDPR, etc. |
| Notification thresholds | Per regulation requirements |
| Notification timelines | Per regulation requirements |
| Notification content | Required elements |
Lessons Learned Meeting:
| Topic | Questions |
|---|---|
| Detection | How was it detected? Could it have been detected earlier? |
| Response | What worked well? What didn't? |
| Containment | Was containment effective? What would improve it? |
| Recovery | Were recovery procedures adequate? |
| Prevention | How can we prevent recurrence? |
| Preparation | What changes should we make to the IR plan? |
Deliverables¶
| Deliverable | Format | Owner |
|---|---|---|
| Initial Triage Report | Email/Document | IR Lead |
| Investigation Status Updates | IR Lead | |
| Incident Timeline | Excel/PDF | Technical Lead |
| Technical Investigation Report | Technical Lead | |
| Executive Summary | IR Lead | |
| Lessons Learned Report | IR Lead | |
| IOC Report | CSV/JSON | Technical Lead |
| Remediation Recommendations | IR Lead |
Quality Gates¶
- Initial triage completed within SLA
- Evidence preserved before containment
- Investigation scope fully documented
- Timeline developed with supporting evidence
- Containment actions documented
- Eradication validated through scanning
- Recovery validated through testing
- Notification assessment completed with legal
- Lessons learned documented
- Client sign-off on incident closure
Related Documents¶
Last Updated: February 2026 Parent SOP: incident-response-sop.md