Lab 13 Incident Scoping, Containment & Escalation

Mission Overview

Welcome to Lab 13 — Incident Scoping, Containment & Escalation.

In Lab 12, you reconstructed the incident timeline and established what the available evidence could prove.

Now the investigation must become actionable.

A SOC analyst needs to determine:

How far has the incident spread?
Which systems are actually affected?
Which systems were only exposed?
Which identities are involved?
What business assets are at risk?
What impact is confirmed?
What impact remains possible?
What should be contained first?
What evidence must be preserved?
Does the incident require escalation?
What does the next response team need?

This is the transition from investigation to incident response decision-making.

Mission Goal: Use the available evidence and reconstructed timeline to determine incident scope, assess impact and priority, identify containment requirements, preserve critical evidence, establish escalation thresholds, and prepare a professional SOC-to-Incident-Response handoff.

Mission Information

Item	Details
Difficulty	Intermediate
Estimated Time	120–150 minutes
Primary Skill	Incident Scoping
Secondary Skill	Containment & Escalation
Environment	GoHackersCloud SOC Analyst Lab
Input	Investigation evidence + Master Incident Timeline
Primary Outcome	Incident Scope & Escalation Register
Operational Mode	Document / Recommend / Simulate
Safety Level	Authorized Training Environment Only

Learning Objectives

By completing this lab, you will be able to:

determine confirmed incident scope
distinguish exposure from compromise
identify affected hosts
identify affected identities
determine IOC prevalence
establish incident boundaries
assess asset criticality
assess identity privilege
determine confirmed impact
document potential impact separately
prioritize response actions
identify containment options
evaluate containment side effects
preserve evidence before destructive actions
distinguish containment from eradication
determine escalation thresholds
create an escalation package
document incident ownership
prepare an incident-response handoff
communicate uncertainty professionally

Core Methodology

Use:

Evidence → Scope → Impact → Priority → Containment → Escalation

Expanded:

Validated Evidence
       │
       ▼
Determine Scope
       │
       ├── Hosts
       ├── Users
       ├── Accounts
       ├── Network
       ├── Files
       ├── IOCs
       └── Data
       │
       ▼
Assess Impact
       │
       ▼
Determine Priority
       │
       ▼
Preserve Evidence
       │
       ▼
Select Containment
       │
       ▼
Assess Business Impact
       │
       ▼
Escalate / Handoff
       │
       ▼
Continue Investigation

The core principle is:

Contain what the evidence justifies, preserve what the investigation still needs, and escalate with enough context for the next team to act.

Part 1 — Understand Incident Scoping

Incident scoping answers:

“What is actually part of this incident?”

Suppose the investigation identifies:

50 users received a phishing email
        ↓
8 users opened the message
        ↓
3 endpoints queried the domain
        ↓
2 users accessed the URL
        ↓
1 endpoint downloaded the file
        ↓
1 endpoint executed the file

Do not report:

50 compromised users

The evidence supports different exposure levels.

Part 2 — Understand Scope Expansion

An incident often begins with:

One Alert

Investigation may reveal:

One Alert
    ↓
One Host
    ↓
One User
    ↓
One Domain
    ↓
Related File
    ↓
Additional Hosts?
    ↓
Additional Users?

Scope should expand because of evidence—not because of assumptions.

Part 3 — Create the Investigation Workspace

Create:

SOC-Labs/
└── Lab-13/
    ├── 01-Scope/
    ├── 02-Timeline/
    ├── 03-Hosts/
    ├── 04-Identities/
    ├── 05-Network/
    ├── 06-IOCs/
    ├── 07-Data-Impact/
    ├── 08-Impact/
    ├── 09-Severity/
    ├── 10-Evidence-Preservation/
    ├── 11-Containment/
    │   ├── Endpoint/
    │   ├── Identity/
    │   ├── Network/
    │   └── Email/
    ├── 12-Escalation/
    ├── 13-Handoff/
    ├── 14-Evidence/
    ├── 15-Findings/
    └── 16-Report/

Create:

Lab-13-Incident-Scoping-Containment-Escalation.md

Part 4 — Open the Case

Example:

CASE ID:
GHC-SOC-2026-013

CASE TITLE:
Incident Scoping, Containment & Escalation

STATUS:
Active Investigation

PRIORITY:
P2

ANALYST:

DATE:

Part 5 — Import the Timeline

Use the Master Incident Timeline from Lab 12.

Example:

15:18
Phishing email delivered

15:21
Suspicious domain interaction

15:22
File downloaded

15:23
Execution confirmed

15:24
EDR alert

15:25
Outbound network communication

15:26
Process terminated

15:27
File quarantined

15:32
Unexpected authentication activity

The timeline becomes the foundation for scoping.

Part 6 — Establish Initial Known Scope

Record:

PRIMARY HOST:
WIN-FIN-02

PRIMARY USER:
finance-user

DOMAIN:
account-update.example.test

FILE:
InvoiceViewer.exe

EXECUTION:
Confirmed

NETWORK COMMUNICATION:
Observed

IDENTITY ANOMALY:
Observed

ADDITIONAL HOSTS:
Under Investigation

Part 7 — Create the Scope Register

Entity Type	Entity	Status	Evidence	Confidence
Host	WIN-FIN-02	Confirmed affected	Execution	High
User	finance-user	Confirmed involved	Email/web/endpoint	High
Domain	account-update…	Incident related	Multiple sources	High
IP	203.0.113.50	Related	Network evidence	Medium
File	InvoiceViewer.exe	Executed	EDR	High

Part 8 — Define Scope Categories

Use consistent categories.

Confirmed Affected

Direct evidence establishes security impact.

Potentially Affected

Evidence suggests possible impact but requires validation.

Exposed

The entity encountered the threat but no impact has been established.

The entity is associated with the investigation but not necessarily affected.

Cleared

Investigation found sufficient evidence that the entity does not require further incident treatment for the current case.

Unknown

Insufficient evidence exists.

Part 9 — Build the Host Scope Matrix

Example:

Host	Email/DNS	Web	File	Execution	Impact	Status
WIN-FIN-02	Yes	Yes	Yes	Yes	Confirmed	Affected
WIN-HR-04	Yes	Blocked	No	No	None observed	Exposed
WIN-SALES-03	DNS	Unknown	Unknown	Unknown	Unknown	Investigate

Part 10 — Investigate the Primary Host

For WIN-FIN-02, determine:

File Present:
Yes

Execution:
Yes

Security Alert:
Yes

Network Activity:
Yes

Persistence:
Not Established

Credential Exposure:
Potential

Containment:
Partial

Do not stop because EDR quarantined one file.

Determine what occurred before quarantine.

Part 11 — Search for Additional Hosts

Search indicators such as:

domain
URL
destination IP
file hash
filename
endpoint detection
relevant process
email campaign

The objective is:

Known IOC
   ↓
Search Environment
   ↓
Additional Hosts?

Part 12 — Avoid Scoping by Filename Alone

Suppose:

InvoiceViewer.exe

appears on three systems.

That does not automatically mean the same malicious file exists on all three.

Compare:

cryptographic hash
path
timestamps
source
process telemetry

Same Filename ≠ Same File

Part 13 — Build the Host Investigation Register

HOST:

IP:

User:

Criticality:

Indicator Match:

File:

Hash:

Execution:

Network Activity:

Identity Activity:

Security Alerts:

Containment:

Scope Classification:

Confidence:

Evidence:

Part 14 — Determine Identity Scope

Investigate:

Primary user

Related accounts

Privileged accounts

Service accounts

Recent authentication sources

MFA activity

Active sessions

Create:

Identity	Role	Privilege	Evidence	Status
finance-user	Finance	Standard	Web + endpoint	Affected
admin-user	Administrator	Privileged	None	Not established

Part 15 — Distinguish User Exposure from Account Compromise

These are different:

User Received Email
       ≠
User Interacted

User Interacted
       ≠
Credentials Exposed

Credentials Exposed
       ≠
Account Used

Suspicious Login
       ≠
Confirmed Account Compromise

Part 16 — Investigate the Authentication Anomaly

From Lab 12:

15:32
Unexpected authentication

Ask:

Which identity?
Source IP?
Destination?
MFA?
Successful or failed?
Expected device?
New session?
Privileged activity afterward?
Related to normal user activity?

Create:

IDENTITY SCOPE RECORD

Identity:

Privilege:

Authentication Time:

Source:

Destination:

MFA:

Expected Source:

Session Created:

Related Activity:

Assessment:

Confidence:

Part 17 — Determine Privilege Exposure

Prioritize identities such as:

administrators
cloud administrators
domain administrators
security administrators
service accounts
application identities
finance-sensitive accounts

A standard workstation and privileged administrative account can require very different response priorities.

Part 18 — Build the Identity Risk Matrix

Identity	Privilege	Exposure	Evidence	Priority
finance-user	Standard	Potential credential exposure	Web + auth	P2
admin-user	High	None established	None	Monitor

Part 19 — Determine Network Scope

Investigate:

Source Hosts

Destination IPs

Domains

Ports

Protocols

Internal Connections

External Connections

Allowed / Blocked

First Seen

Last Seen

Part 20 — Build the Network Scope Register

Source	Destination	Port	Action	Process	Assessment
WIN-FIN-02	203.0.113.50	443	Allowed	InvoiceViewer.exe	Related

Part 21 — Investigate Internal Connections

If evidence shows the affected host communicating with internal systems, determine whether this is:

normal business traffic
administrative activity
application traffic
suspicious follow-on activity

Do not label every internal connection as lateral movement.

Internal Connection ≠ Lateral Movement

Part 22 — Determine IOC Scope

Search:

Domain

URL

IP

Hash

Sender

Filename

across available telemetry.

Create:

IOC	Hosts	Users
Domain	3	2
Hash	1	1
IP	1	1

Part 23 — Separate IOC Scope from Incident Scope

Suppose:

Domain seen:
10 hosts

Malicious hash:
1 host

Execution:
1 host

Then:

10 IOC matches ≠ 10 compromised endpoints

Part 24 — Determine Email Campaign Scope

If the incident originated from phishing, record:

Messages Sent:

Messages Delivered:

Messages Blocked:

Users Opening:

Users Accessing URL:

Users Downloading Content:

Potential Credential Exposure:

Confirmed Endpoint Impact:

This helps separate campaign reach from actual security impact.

Part 25 — Build the Exposure Funnel

Example:

50 Emails Delivered
       │
       ▼
8 Messages Opened
       │
       ▼
3 Domain Queries
       │
       ▼
2 Web Interactions
       │
       ▼
1 File Download
       │
       ▼
1 Execution
       │
       ▼
1 Confirmed Affected Endpoint

Part 26 — Determine Data Scope

Ask whether evidence shows access to:

business files
sensitive records
customer information
credentials
financial information
source code
secrets
regulated data

Do not assume data access simply because malware executed.

Part 27 — Build the Data Impact Register

Data Type	Access Evidence	Transfer Evidence	Status
Finance files	Not established	Not established	Unknown
Credentials	Potential	Not established	Investigate

Part 28 — Separate Access from Exfiltration

Always distinguish:

File Access
    ≠
Data Collection

Data Collection
    ≠
Data Exfiltration

Outbound Traffic
    ≠
Data Exfiltration

Part 29 — Establish Incident Boundaries

Determine:

Earliest Relevant Event

Latest Relevant Event

Confirmed Hosts

Potential Hosts

Confirmed Users

Potential Users

Network Destinations

Related IOCs

Known Impact

Create:

INCIDENT BOUNDARY

First Seen:

Last Seen:

Confirmed Hosts:

Potential Hosts:

Exposed Hosts:

Confirmed Identities:

Potential Identities:

Domains:

IPs:

Files:

Data Impact:

Confidence:

Part 30 — Determine Asset Criticality

Create:

Asset	Business Role	Criticality
WIN-FIN-02	Finance workstation	Medium
FIN-SRV-01	Finance application server	Critical

An event involving a critical production server may require faster escalation than the same event on an isolated training endpoint.

Part 31 — Assess Business Context

Consider:

production vs development
user workstation vs server
privileged vs standard account
regulated data
customer-facing system
revenue-generating system
safety/operational dependency

Technical severity alone is not enough.

Part 32 — Determine Confirmed Impact

Create:

CONFIRMED IMPACT

Phishing Delivery:
Yes

Web Interaction:
Yes

File Download:
Yes

Execution:
Yes

Network Communication:
Yes

Persistence:
Not Established

Credential Misuse:
Not Established

Additional Host Compromise:
Not Established

Data Exfiltration:
Not Established

Part 33 — Determine Potential Impact

Separately record:

POTENTIAL IMPACT

Credential Exposure:
Possible

Persistence:
Requires further validation

Additional Hosts:
Under investigation

Sensitive Data Access:
Unknown

Never merge confirmed and potential impact.

Part 34 — Build the Impact Matrix

Impact Area	Confirmed	Potential	Evidence
Endpoint execution	Yes	—	EDR
Credential exposure	No	Yes	Web + auth
Persistence	No	Yes	Incomplete telemetry
Data exfiltration	No	Unknown	No supporting evidence

Part 35 — Determine Incident Severity

Consider:

Confirmed Impact
+
Asset Criticality
+
Identity Privilege
+
Scope
+
Persistence
+
Data Sensitivity
+
Control Effectiveness
+
Business Impact

Part 36 — Example Severity Model

Low

Limited event with little or no security impact.

Medium

Suspicious or limited confirmed impact requiring investigation.

High

Confirmed compromise or significant security impact requiring coordinated response.

Critical

Major business, privileged, widespread, destructive, or sensitive-data impact requiring immediate incident-response leadership.

Part 37 — Keep Severity and Confidence Separate

Example:

SEVERITY:
High

CONFIDENCE:
Medium

Meaning:

The potential consequences justify a high response priority, but some evidence remains incomplete.

Part 38 — Create the Severity Assessment

SEVERITY ASSESSMENT

Confirmed Impact:

Potential Impact:

Affected Assets:

Critical Assets:

Privileged Identities:

Affected Users:

Persistence:

Data Exposure:

Business Impact:

Security Control Outcome:

Severity:

Confidence:

Rationale:

Part 39 — Understand Containment

Containment attempts to:

Limit further security impact while preserving the organization’s ability to investigate and operate.

Containment is not the same as:

Eradication

or:

Recovery

Part 40 — Distinguish Response Stages

Detection
   ↓
Investigation
   ↓
Containment
   ↓
Eradication
   ↓
Recovery
   ↓
Lessons Learned

This lab focuses primarily on containment and escalation.

Part 41 — Preserve Evidence Before Containment

Where operationally practical:

Preserve Evidence
       ↓
Contain
       ↓
Continue Investigation

Possible evidence includes:

EDR timeline
active processes
network connections
logged-in users
authentication sessions
relevant logs
file metadata
file hash
memory evidence when required
disk evidence when required

Part 42 — Understand the Exception

Evidence preservation must not become an excuse to allow serious ongoing harm.

If immediate containment is required:

Contain Immediately
       ↓
Document What Was Changed
       ↓
Preserve Remaining Evidence

Document the tradeoff.

Part 43 — Build the Evidence Preservation Checklist

relevant SIEM events exported
endpoint timeline preserved
process evidence preserved
file metadata/hash preserved
network evidence preserved
authentication evidence preserved
email evidence preserved
DNS/proxy evidence preserved
screenshots/reference artifacts preserved where useful
evidence IDs assigned
timestamps preserved
analyst actions documented

Part 44 — Determine Endpoint Containment

Potential recommendations include:

Isolate endpoint

Quarantine confirmed malicious file

Terminate confirmed malicious process

Restrict endpoint network access

Preserve forensic evidence

Increase endpoint monitoring

In this lab, document the decision rather than disrupting a real system.

Part 45 — Build the Endpoint Containment Matrix

Host	Action	Priority	Reason	Operational Impact
WIN-FIN-02	Isolate	High	Confirmed execution	User unavailable
WIN-HR-04	Monitor	Medium	Exposure only	Minimal

Part 46 — Determine Identity Containment

Possible recommendations:

revoke active sessions
require credential reset
require MFA reauthentication
temporarily disable affected test account
review privileged sessions
monitor authentication
restrict risky access

Actions must be evidence-based and authorized.

Part 47 — Build the Identity Containment Matrix

Identity	Action	Reason	Priority
finance-user	Revoke sessions	Potential credential exposure	High
admin-user	Monitor	No compromise evidence	Low

Part 48 — Determine Network Containment

Possible recommendations:

block confirmed malicious domain
block specific URL where supported
block confirmed malicious destination
restrict affected host
monitor related destinations
increase network logging

Avoid indiscriminate blocking of shared infrastructure.

Part 49 — Build the Network Containment Matrix

Indicator	Action	Confidence	Business Risk
Malicious domain	Block	High	Low
Shared hosting IP	Review/Monitor	Medium	Potentially High

Part 50 — Determine Email Containment

For phishing:

quarantine related messages
remove delivered copies where authorized
block high-confidence sender/domain indicators
notify affected users
preserve original message
search campaign variants

Part 51 — Build the Email Containment Matrix

Item	Action	Scope	Evidence
Campaign messages	Quarantine/remove	50 recipients	Email telemetry
Domain	Block	Organization	High-confidence IOC

Part 52 — Prioritize Containment

A useful order might be:

1. Stop active harmful activity

2. Protect privileged / affected identities

3. Isolate confirmed affected endpoints

4. Prevent additional threat delivery

5. Block high-confidence indicators

6. Preserve investigation visibility

7. Continue scoping

Actual order depends on incident circumstances.

Part 53 — Build the Containment Priority Register

Priority	Entity	Action	Reason
1	WIN-FIN-02	Isolate	Confirmed execution
2	finance-user	Protect identity	Credential concern
3	Domain	Block	Prevent further interaction
4	Email campaign	Remove	Reduce exposure

Part 54 — Assess Containment Side Effects

Containment can create operational impact.

Examples:

Isolating server
→ Application outage

Disabling account
→ User cannot work

Blocking shared IP
→ Legitimate cloud application unavailable

Terminating process
→ Evidence lost

A good containment recommendation considers both security and operations.

Part 55 — Build the Containment Impact Matrix

Action	Security Benefit	Business Impact	Evidence Impact
Isolate workstation	High	Medium	Low/Medium
Disable privileged account	High	Potentially High	Low
Block shared IP	Medium	Potentially High	Low

Part 56 — Identify Actions Requiring Approval

Examples may include:

isolating production server
disabling executive account
blocking business-critical domain
shutting down workload
removing email organization-wide

Document approval requirements.

Part 57 — Create the Approval Register

Action	Owner	Approval Required	Status
Endpoint isolation	IR Lead	Yes	Pending
Account reset	IAM	Yes	Pending
Domain block	Network/Security	Yes	Pending

Part 58 — Understand Containment Status

Use:

Not Contained

Partially Contained

Contained

Containment Unconfirmed

Do not use “contained” merely because one security control acted.

Part 59 — Example Partial Containment

File:
Quarantined

Process:
Terminated

Endpoint:
Still connected

Identity:
Still active

Domain:
Not blocked

Assessment:

Partially Contained

Part 60 — Build the Containment Status Register

Area	Status	Evidence
Endpoint	Partial	Process terminated
Identity	Open	Session active
Network	Open	Destination not blocked
Email	Partial	Some messages delivered

Part 61 — Understand Escalation

Escalation means transferring or expanding responsibility because the incident requires:

deeper expertise
greater authority
coordinated containment
broader business involvement
forensic investigation
legal/privacy review
leadership awareness

Part 62 — Identify Technical Escalation Criteria

Escalate for evidence such as:

confirmed malicious execution
persistence
suspicious post-execution communication
multiple affected hosts
privileged identity involvement
suspicious internal movement
security-control failure
destructive activity
evidence of data access/exfiltration

Part 63 — Identify Business Escalation Criteria

Consider:

critical production system
sensitive information
customer impact
regulatory obligations
business interruption
executive accounts
financial systems
widespread campaign

Part 64 — Build the Escalation Decision Matrix

Condition	Present	Escalation
Confirmed execution	Yes	IR Team
Privileged account	No	—
Multiple hosts	Unknown	Continue scoping
Sensitive data	Unknown	Review
Containment required	Yes	IR + Endpoint
Phishing campaign	Yes	Email Security

Part 65 — Determine Escalation Destination

Depending on the incident:

Tier 2 SOC

Incident Response

DFIR

Endpoint Security

Identity / IAM

Network Security

Email Security

Cloud Security

Threat Intelligence

Legal / Privacy

Management

Escalate only to teams relevant to the case.

Part 66 — Build the Escalation Routing Register

Team	Reason	Priority
Incident Response	Confirmed execution	Immediate
IAM	Potential identity exposure	High
Email Security	Campaign containment	High
Endpoint Security	Endpoint isolation	Immediate

Part 67 — Prepare the Escalation Package

The next analyst should not need to restart the investigation.

Include:

Case ID

Incident Summary

Severity

Confidence

First Seen

Last Seen

Primary Host

Primary User

Affected Hosts

Potential Hosts

Affected Identities

Related IOCs

Confirmed Impact

Potential Impact

Master Timeline

Containment Status

Recommended Actions

Telemetry Gaps

Evidence References

Outstanding Questions

Part 68 — Example Escalation Summary

CASE:
GHC-SOC-2026-013

SEVERITY:
High

CONFIDENCE:
High

PRIMARY HOST:
WIN-FIN-02

PRIMARY USER:
finance-user

FIRST SEEN:
15:18 UTC

LAST SEEN:
15:32 UTC

CONFIRMED ACTIVITY:
Phishing delivery
Web interaction
File download
File execution
Outbound network communication

CONFIRMED AFFECTED ENDPOINTS:
1

EXPOSED ENDPOINTS:
2 additional endpoints require validation

IDENTITY CONCERN:
Unexpected authentication after endpoint activity

CONTAINMENT:
Partial

EDR terminated the suspicious process and quarantined the file.

RECOMMENDATION:
Escalate to Incident Response and IAM for endpoint isolation,
identity protection, continued scoping, and evidence preservation.

Part 69 — Build the SOC-to-IR Handoff

Create:

SOC → INCIDENT RESPONSE HANDOFF

Case ID:

SOC Analyst:

IR Owner:

Transfer Time:

Severity:

Confidence:

Incident Status:

First Seen:

Last Seen:

Confirmed Hosts:

Potential Hosts:

Confirmed Identities:

Potential Identities:

Confirmed Impact:

Potential Impact:

Containment Completed:

Containment Pending:

Evidence Preserved:

Telemetry Gaps:

Outstanding Questions:

Next Recommended Action:

Part 70 — Document Ownership

Every action should have an owner.

Example:

Action	Owner	Status
Endpoint isolation	Endpoint/IR	Pending
Session revocation	IAM	Pending
Domain block	Network Security	Pending
Email removal	Email Security	In Progress

Part 71 — Track Response Actions

Create:

RESPONSE ACTION REGISTER

Action ID:

Time:

Action:

Target:

Requested By:

Performed By:

Approval:

Result:

Evidence Impact:

Business Impact:

Status:

Part 72 — Preserve the Investigation Audit Trail

Record:

15:40
SOC recommended endpoint isolation.

15:42
IR approved isolation.

15:43
Endpoint isolated.

15:45
IAM revoked active user sessions.

Response actions become part of the incident timeline.

Part 73 — Update Scope After Containment

Containment does not end scoping.

After containment ask:

Did other hosts contact the domain?
Does the same hash exist elsewhere?
Did the account authenticate elsewhere?
Are additional campaign messages present?
Did suspicious activity continue?

Containment and scoping can occur in parallel.

Part 74 — Revalidate First and Last Seen

New evidence may move:

First Seen

earlier or:

Last Seen

later.

Update the incident boundaries when evidence changes.

Part 75 — Reassess Severity

Incident severity can change.

Example:

Initial:
Medium

After confirmed execution:

High

After privileged account compromise and multiple critical systems:

Critical

Document why severity changed.

Part 76 — Create the Severity Change Register

Time	Previous	New	Reason
15:24	Medium	High	Execution confirmed

Part 77 — Reassess Confidence

Confidence can also change as evidence improves.

Example:

Initial Confidence:
Low

After endpoint correlation:
Medium

After hash + process + network correlation:
High

Part 78 — Identify Telemetry Gaps Affecting Scope

Examples:

EDR unavailable on one endpoint

Proxy logs missing

Authentication retention incomplete

No process-to-network mapping

Email click telemetry unavailable

Cloud authentication logs unavailable

Part 79 — Build the Scope Gap Register

Gap	Scope Impact	Priority
No EDR on WIN-SALES-03	Cannot validate execution	High
Missing proxy logs	Web interaction uncertain	Medium

Part 80 — Determine Final Incident Classification

Use a professional classification such as:

Security Event

Potential Security Incident

Confirmed Security Incident

Confirmed Security Incident — Contained

Confirmed Security Incident — Active

Inconclusive

Part 81 — Example Final Assessment

FINAL CLASSIFICATION:
Confirmed Security Incident — Partially Contained

SEVERITY:
High

CONFIDENCE:
High

CONFIRMED AFFECTED HOSTS:
1

EXPOSED / INVESTIGATION HOSTS:
2

CONFIRMED AFFECTED USERS:
1

PRIVILEGED ACCOUNTS:
No confirmed involvement

CONFIRMED IMPACT:
Malicious file execution and outbound network communication.

PERSISTENCE:
Not established.

CREDENTIAL COMPROMISE:
Potential; requires identity investigation.

DATA EXFILTRATION:
Not established.

CONTAINMENT:
EDR terminated the process and quarantined the file.
Endpoint and identity containment remain pending.

ESCALATION:
Incident Response + IAM + Email Security.

STATUS:
Active investigation.

Part 82 — Mission Challenge

Complete:

LAB INFORMATION

Lab:
Incident Scoping, Containment & Escalation

Case ID:

Analyst:

Date:


INCIDENT BOUNDARY

First Seen:

Last Seen:

Primary Host:

Primary User:

Initial Alert:


HOST SCOPE

Confirmed Affected Hosts:

Potentially Affected Hosts:

Exposed Hosts:

Cleared Hosts:

Unknown Hosts:


IDENTITY SCOPE

Confirmed Affected Identities:

Potential Identities:

Privileged Identities:

Service Accounts:

Active Sessions:


NETWORK SCOPE

Domains:

URLs:

IPs:

Internal Destinations:

External Destinations:

Allowed Connections:

Blocked Connections:


IOC SCOPE

Domain Hits:

URL Hits:

Hash Hits:

IP Hits:

Sender Hits:


EMAIL SCOPE

Messages Sent:

Delivered:

Blocked:

Users Interacting:

Downloads:

Confirmed Endpoint Impact:


DATA SCOPE

Sensitive Data:

Access Evidence:

Collection Evidence:

Transfer Evidence:

Data Exfiltration:


CONFIRMED IMPACT

Endpoint Execution:

Network Communication:

Persistence:

Credential Misuse:

Additional Hosts:

Data Exposure:


POTENTIAL IMPACT

Credential Exposure:

Persistence:

Additional Hosts:

Sensitive Data:


ASSET CRITICALITY

Critical Assets:

High-Value Identities:

Business Services:

Operational Impact:


SEVERITY

Severity:

Confidence:

Rationale:


EVIDENCE PRESERVATION

SIEM Evidence:

Endpoint Evidence:

Network Evidence:

Identity Evidence:

Email Evidence:

Timeline:

Evidence Complete:
Yes / No


ENDPOINT CONTAINMENT

Host:

Recommended Action:

Priority:

Operational Impact:

Approval:


IDENTITY CONTAINMENT

Identity:

Recommended Action:

Priority:

Operational Impact:

Approval:


NETWORK CONTAINMENT

IOC:

Recommended Action:

Business Risk:

Approval:


EMAIL CONTAINMENT

Campaign:

Recommended Action:

Scope:


CONTAINMENT STATUS

Endpoint:

Identity:

Network:

Email:

Overall:
Not Contained / Partial / Contained / Unknown


ESCALATION

Required:
Yes / No

Teams:

Reason:

Priority:


HANDOFF

IR Owner:

Transfer Time:

Evidence Package:

Outstanding Questions:

Next Action:


FINAL CLASSIFICATION

Classification:

Severity:

Confidence:

Known Impact:

Potential Impact:

Current Scope:

Containment Status:

Escalation Status:

Ready for SOC Case Reporting:
Yes / No

Part 83 — What Not to Do

Do not:

Call every exposed system compromised

Treat IOC matches as confirmed compromise

Assume every phishing recipient interacted

Assume suspicious login means account compromise

Assume outbound traffic means exfiltration

Assume internal traffic means lateral movement

Assume quarantine equals full containment

Assume endpoint containment protects the identity

Assume account reset contains the endpoint

Disable accounts without authorization

Isolate production systems without considering business impact

Block shared infrastructure blindly

Destroy evidence unnecessarily

Delay urgent containment solely to collect perfect evidence

Declare the incident closed immediately after containment

Stop scoping after finding the first affected host

Hide unknowns

Mix confirmed impact with potential impact

Escalate without evidence and context

Hand off a case without a usable timeline

The professional rule is:

Scope first, contain based on evidence, and communicate exactly what is known, suspected, and still unknown.

Evidence Requirements

Capture:

Evidence 01

Master Incident Timeline.

Evidence 02

Initial Known Scope.

Evidence 03

Scope Register.

Evidence 04

Host Scope Matrix.

Evidence 05

Primary Host Investigation.

Evidence 06

Additional Host Search.

Evidence 07

Host Investigation Register.

Evidence 08

Identity Scope.

Evidence 09

Identity Scope Record.

Evidence 10

Identity Risk Matrix.

Evidence 11

Network Scope Register.

Evidence 12

IOC Scope Register.

Evidence 13

Email Campaign Scope.

Evidence 14

Exposure Funnel.

Evidence 15

Data Impact Register.

Evidence 16

Incident Boundary.

Evidence 17

Asset Criticality Register.

Evidence 18

Confirmed Impact.

Evidence 19

Potential Impact.

Evidence 20

Impact Matrix.

Evidence 21

Severity Assessment.

Evidence 22

Evidence Preservation Checklist.

Evidence 23

Endpoint Containment Matrix.

Evidence 24

Identity Containment Matrix.

Evidence 25

Network Containment Matrix.

Evidence 26

Email Containment Matrix.

Evidence 27

Containment Priority Register.

Evidence 28

Containment Impact Matrix.

Evidence 29

Approval Register.

Evidence 30

Containment Status Register.

Evidence 31

Escalation Decision Matrix.

Evidence 32

Escalation Routing Register.

Evidence 33

Escalation Package.

Evidence 34

SOC-to-IR Handoff.

Evidence 35

Response Action Register.

Evidence 36

Severity Change Register.

Evidence 37

Scope Gap Register.

Evidence 38

Final Incident Assessment.

Evidence 39

Mission Challenge worksheet.

Mission Deliverables

Complete:

Master Incident Timeline reviewed
initial scope established
scope categories applied consistently
confirmed affected hosts identified
potentially affected hosts identified
exposed hosts distinguished from compromised hosts
additional hosts searched
primary identity assessed
related identities assessed
privileged identities evaluated
network scope determined
internal traffic evaluated
IOC scope determined
IOC scope separated from compromise scope
email campaign scope determined
exposure funnel built
data scope evaluated
data access separated from exfiltration
incident boundaries established
asset criticality assessed
business context considered
confirmed impact documented
potential impact documented separately
severity assigned
confidence assigned separately
evidence preservation requirements identified
endpoint containment recommendations created
identity containment recommendations created
network containment recommendations created
email containment recommendations created
containment priorities assigned
operational side effects evaluated
approval requirements documented
containment status determined
technical escalation criteria evaluated
business escalation criteria evaluated
escalation destination identified
escalation package created
SOC-to-IR handoff prepared
response ownership documented
response actions tracked
scope revalidated after containment
severity changes documented
telemetry gaps documented
final incident classification assigned

Lab Report Template

# Lab 13 — Incident Scoping, Containment & Escalation

## Executive Summary

## Mission Objective

## Case Information

## Master Incident Timeline

## Initial Scope

## Incident Boundaries

## Host Scope

## Identity Scope

## Privilege Exposure

## Network Scope

## IOC Scope

## Email Campaign Scope

## Exposure Funnel

## Data Scope

## Asset Criticality

## Business Context

## Confirmed Impact

## Potential Impact

## Severity Assessment

## Confidence Assessment

## Evidence Preservation

## Endpoint Containment

## Identity Containment

## Network Containment

## Email Containment

## Containment Priorities

## Containment Business Impact

## Approval Requirements

## Containment Status

## Escalation Criteria

## Escalation Routing

## SOC-to-IR Handoff

## Response Action Register

## Scope Gaps

## Outstanding Questions

## Final Incident Classification

## Evidence Register

## Limitations

## Conclusion

Knowledge Check

Question 1 — Does an IOC match mean the system is compromised?

No.

It identifies something that requires investigation.

Question 2 — Why distinguish exposed from affected systems?

Because exposure does not prove successful security impact.

Question 3 — Does malicious file execution automatically mean the entire network is compromised?

No.

Scope must be established from evidence.

Question 4 — Is containment the same as eradication?

No.

Containment limits further impact. Eradication removes the cause or artifacts of the incident.

Question 5 — Should evidence always be preserved before containment?

Where operationally practical, yes. However, preventing serious ongoing harm can require immediate containment.

Question 6 — Does process quarantine mean the incident is fully contained?

No.

Identity, network, email, additional endpoints, or other aspects may remain exposed.

Question 7 — Why evaluate business impact before containment?

A technically useful action may create significant operational consequences.

Question 8 — Why separate confirmed impact from potential impact?

It prevents uncertainty from being presented as fact.

Question 9 — Should scoping stop after the first affected host is contained?

No.

Additional affected systems or identities may still exist.

Question 10 — What is the central question?

“How far does the incident actually extend, what must be contained first, and what evidence does the next response team need in order to act safely and decisively?”

Skills Achieved

After completing this lab, you should understand:

incident scoping
host scoping
identity scoping
network scoping
IOC scoping
campaign vs compromise scope
data-impact assessment
asset criticality
business-impact assessment
confirmed vs potential impact
severity determination
confidence assessment
evidence-preservation planning
endpoint containment
identity containment
network containment
email containment
containment prioritization
operational-impact analysis
escalation criteria
escalation routing
SOC-to-IR handoff
response-action tracking
incident ownership
professional incident communication

Professional Takeaway

A weak response looks like:

Malware Alert
     ↓
Compromised
     ↓
Isolate Everything
     ↓
Block Everything
     ↓
Close Incident

A professional response looks like:

Validated Evidence
       ↓
Determine Incident Boundary
       ↓
Scope Hosts
       ↓
Scope Identities
       ↓
Scope Network
       ↓
Scope IOCs
       ↓
Assess Data Impact
       ↓
Separate Exposure / Impact
       ↓
Assess Asset Criticality
       ↓
Determine Severity
       ↓
Preserve Evidence
       ↓
Prioritize Containment
       ↓
Assess Operational Impact
       ↓
Obtain Required Approval
       ↓
Contain
       ↓
Escalate
       ↓
Continue Scoping
       ↓
Reassess

Always distinguish:

Exposure
   ≠
Compromise

IOC Match
   ≠
Security Impact

Same Filename
   ≠
Same File

Suspicious Login
   ≠
Account Compromise

Internal Connection
   ≠
Lateral Movement

Outbound Connection
   ≠
Data Exfiltration

File Access
   ≠
Data Exfiltration

Process Terminated
   ≠
Incident Contained

Containment
   ≠
Eradication

High Severity
   ≠
High Confidence

One Affected Host
   ≠
Entire Environment Compromised

The strongest SOC analyst does not simply say:

“We found malware. Isolate the machine.”

They can explain:

“This is what the evidence confirms, this is the current incident boundary, these systems and identities are affected or exposed, this is the confirmed and potential impact, these containment actions should be prioritized, these actions carry these operational consequences, and this is exactly what the next response team needs to continue the incident safely.”

What’s Next?

➡️ Lab 14 — SOC Investigation Reporting & Case Documentation

In the next lab, you will convert the complete investigation into a professional SOC case record that another analyst, incident responder, security manager, auditor, or stakeholder can understand.

You will work with:

case metadata
executive summaries
alert details
investigation scope
affected assets
affected identities
evidence registers
IOC registers
Master Incident Timeline
findings
severity
confidence
confirmed vs potential impact
containment actions
escalation decisions
remediation recommendations
investigation limitations
outstanding questions
case closure criteria
analyst handoff notes

The methodology becomes:

Evidence → Findings → Timeline → Scope → Impact → Actions → Conclusion → Case Record

And the central question will be:

“Can another analyst understand exactly what happened, what you investigated, what evidence supports your conclusion, what remains unknown, and what the organization should do next?”