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

Lesson 68 — When Do We Call It Contained?

Both compromised devices were isolated.

The affected account had been contained.
Sessions had been revoked.
The malicious mailbox rule was gone.
The suspicious OAuth access had been addressed.

The incident channel became noticeably quieter.

Someone typed:

“Great. Incident contained.”

Agent Foskett looked at the timeline.

“What evidence proves that?”

Containment is not a list of actions completed. It is an evidence-supported conclusion that the attacker’s known ability to continue causing harm has been sufficiently reduced.

Verify Containment Back to SOC Analyst Academy

Agent Foskett verifying containment during a cyber security incident

Actions are not proof.

Verify the result of containment across every relevant access path before changing the incident status.

✓ Define containment criteria

✓ Verify actions succeeded

✓ Check for renewed activity

✓ Record residual risk

Case briefing

RESPONSE ACTIONS COMPLETE: FIN-WS-044 isolated FIN-WS-061 isolated mia@contoso.com contained Sessions revoked Mailbox persistence removed Cloud access addressed QUESTION: IS THE INCIDENT CONTAINED? OR HAVE WE ONLY COMPLETED THE CONTAINMENT ACTIONS?

Investigation objective

Define measurable containment criteria, verify the effect of response actions and make a defensible incident-level containment decision.

Investigator's rule

Containment is a verified state, not a completed task list.

Stage 1 — define containment before declaring it

A DEFENSIBLE CONTAINMENT DECISION ASKS: Are known malicious processes stopped? Are affected devices controlled? Are known compromised identities controlled? Are malicious sessions addressed? Are persistence mechanisms addressed? Are malicious application grants or access paths addressed? Has suspicious cloud / mailbox activity stopped? Has incident scope stabilised enough for the current decision? Are remaining risks understood? CAN THE ATTACKER STILL USE A KNOWN PATH TO CONTINUE?

Containment is incident-specific

The criteria for a compromised workstation differ from those for an identity takeover, malicious OAuth consent or cloud data incident. Define what must be true for this incident, not what was true in the last one.

Known capability is the focus

The SOC rarely proves that an attacker has absolutely no possible path anywhere. The practical question is whether known and reasonably suspected paths have been addressed sufficiently under the organisation's incident procedures.

Stage 2 — distinguish action from outcome

Action recorded	Outcome that needs verification
Device isolation requested	The device is actually isolated and no longer providing the relevant network access.
Sessions revoked	Known malicious session activity no longer continues.
Password reset	The identity's known compromised authentication path has been addressed.
Mailbox rule removed	The malicious rule is gone and equivalent persistence has not been identified.
OAuth access revoked	The application no longer retains the relevant malicious access.
Indicator blocked	Relevant malicious communication has stopped or is being prevented as expected.

“Requested” is not “completed”

A ticket, command or portal action shows intent. Verify the resulting state. Failed, delayed or partially applied controls can leave the attacker active.

“Completed” is not always “effective”

An action can succeed technically and still fail to contain the incident if another access path remains. That is why containment must be evaluated across the whole incident.

Stage 3 — verify endpoint activity after containment

12345678

DeviceProcessEvents
| where Timestamp > ago(2h)
| where DeviceName in~ ("FIN-WS-044", "FIN-WS-061")
| project Timestamp, DeviceName, AccountName,
          FileName, ProcessCommandLine,
          InitiatingProcessFileName
| order by Timestamp asc

Use the containment timestamp

Compare activity before and after the recorded response action. The question is not merely whether suspicious events exist, but whether relevant malicious activity continued after containment should have taken effect.

Remember defender actions affect telemetry

Isolation and remediation change what you can observe. Record those changes so an absence of events is interpreted in the context of the response action.

Stage 4 — verify relevant network activity

12345678

DeviceNetworkEvents
| where Timestamp > ago(2h)
| where DeviceName in~ ("FIN-WS-044", "FIN-WS-061")
| project Timestamp, DeviceName,
          InitiatingProcessFileName,
          RemoteIP, RemotePort, RemoteUrl
| order by Timestamp asc

Look for activity after the control point

If a known malicious connection continues after the expected containment time, the response state needs investigation. Confirm timestamps and control behaviour before assuming the action failed.

Silence is supporting evidence, not absolute proof

No new suspicious network events can support containment when combined with successful controls and stable scope. By itself, silence cannot prove the attacker has no remaining capability.

Stage 5 — verify cloud activity

1234567

CloudAppEvents
| where Timestamp > ago(2h)
| where AccountId =~ "mia@contoso.com"
| project Timestamp, AccountId, Application,
          ActionType, IPAddress, UserAgent
| order by Timestamp asc

Endpoint containment does not contain cloud access

An isolated workstation does not automatically invalidate an existing cloud session or application permission. Verify each relevant control plane separately.

Watch for renewed activity

Activity reappearing after containment may indicate another session, credential, application grant, device, persistence mechanism or access path that was not included in the original plan.

Stage 6 — use a containment matrix

Control plane	Containment criterion	Status
Endpoint	Known affected devices isolated; no continuing known malicious execution observed.	Verified
Identity	Known compromised identity access paths addressed; malicious activity stopped.	Verified
Messaging	Known malicious mailbox persistence removed and related scope reviewed.	Verified
Cloud / SaaS	Known malicious access or permission path addressed; suspicious activity stopped.	Verification in progress
Scope	Material pivots no longer identifying new affected entities.	Stabilising

A single “open” can matter

If one unresolved control plane still provides a credible attacker path, the incident may not yet meet its containment criteria even though most actions are complete.

Make criteria observable

“Identity contained” is too vague. “Known malicious sessions revoked and no renewed suspicious activity observed during the defined verification period” is a more useful operational statement.

Stage 7 — separate containment from eradication and recovery

CONTAINMENT: Reduce attacker ability to continue harm. ERADICATION: Remove malicious artefacts, persistence and root causes as required by the response plan. RECOVERY: Return systems and services to an acceptable operational state and monitor for recurrence. THESE PHASES CAN OVERLAP. BUT: "CONTAINED" DOES NOT MEAN "EVERYTHING IS FINISHED."

Do not close the incident at containment

Containment is a major response milestone, not necessarily the end of the incident. Evidence review, eradication, recovery, monitoring, impact assessment and lessons learned may remain.

Use your organisation's response model

Incident-response phases and status names vary. Follow the approved playbook, authority model and terminology used by your organisation.

Stage 8 — record residual risk and unknowns

CONTAINMENT DECISION KNOWN PATHS: Addressed KNOWN MALICIOUS ACTIVITY: Stopped SCOPE: Stable enough for current decision OPEN QUESTIONS: Initial access root cause still under review Full data-impact assessment incomplete RESIDUAL RISK: Low-confidence possibility of additional undiscovered access path DECISION: Incident may move to contained / eradication-recovery phase under approved procedure. IMPORTANT: UNKNOWN DOES NOT MEAN SAFE. UNKNOWN ALSO DOES NOT MEAN THE INCIDENT CAN NEVER BE CALLED CONTAINED.

Unknowns should influence confidence

Record what remains uncertain and whether it materially affects the containment decision. Some unknowns block containment; others can be investigated safely during later response phases.

Residual risk needs an owner

If risk remains after the containment milestone, record who owns it, what monitoring or follow-up is required and what condition would trigger renewed response.

Stage 9 — require a containment statement

CONTAINMENT STATEMENT — 17:05 CONFIRMED SCOPE: 2 endpoints 1 identity 1 mailbox 1 SharePoint resource 1 malicious application path ACTIONS VERIFIED: Affected endpoints isolated Known malicious sessions addressed Mailbox persistence removed Application access revoked OBSERVATION: No renewed known malicious activity observed after verified controls during the defined review period. SCOPE: No new materially affected entities identified through current pivots. OPEN: Root cause and full impact review continue. DECISION: Containment criteria met. NEXT: Proceed with eradication, recovery and continued monitoring under incident procedure.

The statement should explain why

A status label without evidence is weak. A containment statement records scope, verified controls, observation, open issues and the rationale for moving to the next response state.

Record who made the decision

For significant incidents, capture the authorised decision-maker or incident lead according to organisational procedure, along with the decision time.

Stage 10 — know what would reopen containment

AFTER CONTAINMENT: IF YOU SEE: Renewed malicious execution New suspicious identity activity A previously unknown session Another compromised device A surviving persistence mechanism New malicious application access Unexpected data activity THEN: REASSESS SCOPE REASSESS CONTAINMENT REOPEN ACTIVE RESPONSE IF REQUIRED CONTAINMENT IS A DEFENSIBLE CONCLUSION. IT IS NOT A PROMISE THAT NOTHING CAN EVER CHANGE.

Monitoring continues

Recovery should include appropriate monitoring for recurrence or evidence that the containment conclusion was incomplete. Define the monitoring expectations in the incident plan.

Be willing to change the status

If new evidence invalidates the containment assumptions, update the incident. A defensible SOC changes its conclusion when the evidence changes.

Lesson 68 key takeaways

Containment is a verified incident state, not a list of completed actions.
Define incident-specific containment criteria.
Verify the outcome of actions rather than assuming requests succeeded.
Evaluate endpoint, identity, messaging, cloud and other relevant control planes separately.
An isolated endpoint does not automatically contain cloud access.
Absence of new malicious activity supports containment but does not prove universal safety.
Use observable containment criteria and record their status.
Containment, eradication and recovery are related but different response concepts.
Record residual risk, unknowns and owners.
A containment statement should document scope, verified actions, observations and rationale.
Continue appropriate monitoring after containment.
If new evidence appears, reassess the containment conclusion.

Module 7 — Incident Response: Containment, Evidence & Escalation

Lesson 68 established an evidence-based containment decision. Lesson 69 turns to the next operational challenge: handing the incident to another analyst or team without losing the timeline, decisions, risks and unanswered questions.

Next: Lesson 69 — Writing the Incident Handover

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 67 — The Scope Kept Growing Reassess affected entities as evidence expands.

✅ Current lesson

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

Next lesson →

Lesson 69 — Writing the Incident Handover Transfer status, evidence, actions and unanswered questions.

When should a SOC declare a security incident contained?

Lesson 68 of the Agent Foskett SOC Analyst Academy teaches analysts how to define evidence-based containment criteria and verify that response actions have actually reduced the attacker's known ability to continue causing harm.

Verifying cyber security incident containment

Learn how to distinguish containment actions from outcomes, verify endpoint and cloud activity, record residual risk, document a containment statement and recognise when new evidence requires containment to be reassessed.