Agent Foskett Academy • SOC Analyst Academy • Module 7 • Lesson 67 • Incident Response: Containment, Evidence & Escalation

Lesson 67 — The Scope Kept Growing

The incident started with one user.

Then there was one compromised workstation.

Then a second device appeared.
Then another account.
Then a SharePoint site.
Then an OAuth application.

Every time the SOC answered one question, the evidence created two more.

Someone looked at the original incident ticket and said:

“But we already scoped this.”

Agent Foskett looked at the new timeline.

“We scoped what we knew then. Now we know more.”

Incident scope is a living conclusion. New evidence can expand — or reduce — what the SOC must investigate and contain.

Reassess the Scope Back to SOC Analyst Academy

Agent Foskett reassessing the expanding scope of a cyber security incident

Scope is not a one-time task.

Follow each material pivot, classify newly discovered entities and continuously update the boundary of the incident.

✓ Track confirmed entities

✓ Separate related from affected

✓ Follow material pivots

✓ Reassess containment

Case briefing

ORIGINAL SCOPE: USER: mia@contoso.com DEVICE: FIN-WS-044 NEW EVIDENCE: FIN-WS-061 ↓ Account: alex@contoso.com ↓ SharePoint site ↓ External file share ↓ OAuth application ↓ Additional cloud activity QUESTION: WHICH OF THESE ARE ACTUALLY PART OF THE INCIDENT?

Investigation objective

Continuously reassess incident scope as new users, devices, applications, resources and indicators appear, while distinguishing confirmed compromise from mere association.

Investigator's rule

Every pivot expands the investigation. It does not automatically expand the confirmed compromise.

Stage 1 — understand what scope really means

INCIDENT SCOPE IS NOT: "Everything returned by the query." INCIDENT SCOPE IS: Entities supported by evidence as affected, compromised, targeted or materially relevant to the incident. FOR EACH NEW ENTITY ASK: Why is it here? What connects it? What happened to it? What evidence supports inclusion? Does it require containment? Does it create another pivot?

Association is not compromise

A device appearing in the same query, a user accessing the same resource or an IP contacting several systems does not automatically prove compromise. Classify the relationship before changing incident scope.

Scope should be evidence-based

Record why an entity was added, what evidence supports its status and whether that status is confirmed, suspected, targeted, related or cleared.

Stage 2 — maintain an entity register

Entity	Status	Reason
mia@contoso.com	Confirmed affected	Suspicious identity and cloud activity.
FIN-WS-044	Confirmed compromised	Malicious execution and network evidence.
FIN-WS-061	Suspected compromised	Related identity and suspicious process activity.
alex@contoso.com	Under investigation	Observed on newly identified device.
Finance SharePoint site	Affected resource	Suspicious file-access activity.
OAuth application	Under investigation	Appeared in related cloud activity.

Status prevents overstatement

“Under investigation” is a valid state. It lets the SOC widen its search without prematurely telling stakeholders that every related entity is compromised.

Cleared entities still matter

If evidence later shows an entity was benign, record why it was cleared. That prevents another analyst from reopening the same branch without understanding the prior work.

Stage 3 — pivot from the newly affected endpoint

12345678

DeviceProcessEvents
| where Timestamp > ago(1d)
| where DeviceName =~ "FIN-WS-061"
| project Timestamp, DeviceName, AccountName,
          FileName, ProcessCommandLine,
          InitiatingProcessFileName
| order by Timestamp asc

New device, new questions

Which accounts used it? Did suspicious execution occur? What preceded that execution? Did the device connect elsewhere? Each answer can create a justified next pivot.

Do not jump straight to tenant-wide conclusions

A second affected device proves the original scope was incomplete. It does not prove every device is affected. Expand systematically using evidence.

Stage 4 — identify other devices touched by the account

12345678

DeviceLogonEvents
| where Timestamp > ago(1d)
| where AccountName =~ "mia"
| summarize FirstSeen=min(Timestamp),
            LastSeen=max(Timestamp),
            Events=count()
          by DeviceName, LogonType
| order by LastSeen desc

A pivot creates candidates, not verdicts

The query identifies devices requiring review. Compare timestamps, logon types and surrounding evidence before deciding whether each device belongs inside the affected scope.

Prioritise unusual or high-risk candidates

Review systems touched during the incident window, critical assets, privileged systems and devices showing additional suspicious evidence first.

Stage 5 — scope the cloud activity

123456789

CloudAppEvents
| where Timestamp > ago(1d)
| where AccountId =~ "mia@contoso.com"
| summarize FirstSeen=min(Timestamp),
            LastSeen=max(Timestamp),
            Events=count()
          by Application, ActionType
| order by LastSeen desc

Scope resources as well as identities

An identity incident can affect SharePoint sites, mailboxes, applications, files and other cloud resources. The scope register should represent what was accessed or changed, not only who signed in.

Ask whether the resource was merely touched or materially affected

A read event, permission change, download and external share have different implications. Preserve the action context before assigning impact.

Stage 6 — classify every expansion

NEW ENTITY FOUND ↓ WHY DID IT APPEAR? ↓ IS THE RELATIONSHIP MATERIAL? ↓ WHAT EVIDENCE EXISTS? ↓ CLASSIFY: CONFIRMED AFFECTED SUSPECTED AFFECTED TARGETED RELATED UNDER INVESTIGATION CLEARED ↓ DOES IT REQUIRE: Containment? Evidence preservation? Another pivot? Business notification?

Classification controls response

A confirmed compromised endpoint may require containment. A related but benign infrastructure component may require no action beyond documentation. Treating both identically wastes time and can create unnecessary disruption.

Update classifications as evidence changes

Scope is dynamic. A suspected device may become confirmed compromised, while another may be cleared. The incident record should show those changes and the evidence behind them.

Stage 7 — avoid uncontrolled pivoting

BAD SCOPING: IP ↓ 100 devices ↓ Every user on those devices ↓ Every file those users opened ↓ Thousands of entities ↓ NO PRIORITY NO DECISION NO END BETTER SCOPING: Material indicator ↓ Relevant entities ↓ Incident-window evidence ↓ Classify relationship ↓ Prioritise risk ↓ Follow justified pivots

Not every possible relationship deserves immediate investigation

Use time boundaries, known behaviours, high-confidence indicators, criticality and incident hypotheses to keep the investigation focused.

Broad hunting and incident scoping are related but different

Threat hunting may deliberately explore weak signals across a large environment. Incident scoping must also support immediate decisions about containment, impact and recovery.

Stage 8 — let new scope change containment

ORIGINAL PLAN: Isolate FIN-WS-044 Contain mia@contoso.com NEW EVIDENCE: FIN-WS-061 suspicious alex@contoso.com under investigation OAuth app relevant External share discovered REASSESS: Do we isolate another device? Do we contain another identity? Do we revoke app access? Do we remove external sharing? Do we preserve more evidence? Do we notify another business owner? NEW SCOPE CAN REQUIRE NEW CONTAINMENT.

Containment plans are not fixed

When scope expands, revisit the original containment assumptions. Controls that were sufficient for one device and one identity may no longer address the incident.

Coordinate before broad actions

Expanding scope does not automatically justify mass account disablement or widespread device isolation. Use evidence, authority, criticality and approved response procedures.

Stage 9 — know when scope is stabilising

SCOPE MAY BE STABILISING WHEN: Repeated pivots stop finding materially affected entities. Known indicators have been scoped. Affected identities are understood. Affected devices are understood. Relevant cloud resources are understood. Persistence paths are reviewed. Containment verification shows no renewed malicious activity. IMPORTANT: "WE STOPPED LOOKING" IS NOT THE SAME AS "THE SCOPE IS STABLE."

Absence of expansion needs evidence

Document what was searched, which pivots were followed, what time window was reviewed and why the remaining uncertainty is acceptable under the incident procedure.

Residual uncertainty is normal

Most investigations cannot prove a universal negative. The goal is a defensible scope conclusion supported by sufficient evidence, not mathematical certainty.

Stage 10 — keep the scope statement current

SCOPE UPDATE — 16:10 CONFIRMED AFFECTED: mia@contoso.com FIN-WS-044 FIN-WS-061 Finance SharePoint site SUSPECTED / INVESTIGATING: alex@contoso.com OAuth application CLEARED: FIN-WS-073 No suspicious activity found during incident window. NEW SINCE LAST UPDATE: External file share identified. OAuth relationship added for review. CONTAINMENT IMPACT: FIN-WS-061 isolated. External sharing restricted under approved procedure. OPEN: Determine whether alex account activity is malicious. Determine OAuth application's role. NEXT: Complete identity and application pivots. Reassess scope again after results.

A scope statement should have a timestamp

“Current scope” means current at a particular point in the investigation. Timestamped updates make it clear what the team knew when decisions were made.

Scope belongs in every major incident update

Stakeholders need to know not only what the SOC is doing, but whether the number and type of affected entities are changing.

Lesson 67 key takeaways

Incident scope is a living conclusion, not a one-time checklist.
Every pivot expands the investigation but does not automatically prove compromise.
Separate confirmed, suspected, targeted, related, investigating and cleared entities.
Record why each entity entered the incident scope.
Scope users, devices, applications and cloud resources — not only alerts.
Use material pivots and incident-window evidence to avoid uncontrolled expansion.
New scope can require new containment actions.
Do not use expanding scope as justification for indiscriminate disruption.
Cleared entities should be documented as well as affected entities.
Scope stabilisation requires evidence that meaningful pivots are no longer finding new affected entities.
Residual uncertainty should be explicit.
Timestamp scope statements so later reviewers know what was understood at each decision point.

Module 7 — Incident Response: Containment, Evidence & Escalation

Lesson 67 showed how incident scope changes as new evidence appears. Lesson 68 asks the next difficult question: after all the containment actions, scoping and verification, what evidence is enough to say the incident is actually contained?

Next: Lesson 68 — When Do We Call It Contained?

Continue your SOC Analyst training

Module 3 focuses on identity incidents, authentication, MFA, privilege, sessions and application access.

SOC Analyst Academy KQL Academy Microsoft Sentinel Academy Defender for Endpoint Academy Microsoft Entra Security Academy Security Copilot Academy Agent Foskett Academy

🔎 SOC Analyst Academy — Module 7: Incident Response: Containment, Evidence & Escalation

Move from investigation into coordinated containment, evidence preservation, scoping, escalation and recovery.

← Previous lesson

Lesson 66 — The Incident Crossed Multiple Teams Coordinate identity, endpoint, messaging, cloud and business stakeholders.

✅ Current lesson

Lesson 67 — The Scope Kept Growing Reassess affected entities as evidence expands.

Next lesson →

Lesson 68 — When Do We Call It Contained? Define evidence-based containment.

How do SOC analysts determine the scope of a security incident?

Lesson 67 of the Agent Foskett SOC Analyst Academy teaches analysts how to reassess affected users, devices, applications and cloud resources as new evidence expands an incident.

Incident scoping with Microsoft Defender XDR

Learn how to follow material pivots, classify confirmed and suspected entities, maintain an incident scope register, avoid uncontrolled expansion and update containment decisions as evidence changes.