Start your lesson
Study the required lesson for each block, then take its short check. Guided exercises are optional. Required case practice within the blocks counts toward the readiness checklist, not lesson completion.
Your notesPrivate to you
Block 1 of 5Incident triage · Incident declaration · Incident severity · Incident communication plan
Practice savedNext · 15 min
Incident triage · Incident declaration · Incident severity · Incident communication plan
Practice savedNo provider lesson is assigned to this block. Study the ITForMe lesson below, then take the required check.
Required ITForMe lesson
Concept notes
Incident triage
Validates an alert, estimates scope and impact, preserves time-sensitive evidence, and identifies the next decision or collection step.
Incident declaration
Activates defined coordination, ownership, communication, and recordkeeping when evidence meets an organization's documented incident threshold.
Incident severity
Applies defined scope, privilege, safety, data, and business-impact criteria and changes when material evidence changes.
Incident communication plan
Defines recipients, channels, update cadence, sensitive-data handling, and decision authority during a coordinated response.
Required block check · Block 1
Required for course progress · Pass with 3 of 4 correct
Block 2 of 5Containment · Eradication · Recovery · Lessons-learned review
Practice saved15 min
Containment · Eradication · Recovery · Lessons-learned review
Practice savedNo provider lesson is assigned to this block. Study the ITForMe lesson below, then take the required check.
Required ITForMe lesson
Concept notes
Containment
Limits continuing harm or spread while balancing evidence preservation, business function, and later removal of the incident's underlying cause.
Eradication
Removes malicious artifacts, compromised credentials, vulnerable paths, and other causes that could allow the incident to recur.
Recovery
Restores required service from a trusted state and monitors for recurrence before returning to ordinary operations.
Lessons-learned review
Uses incident evidence and participant experience to identify effective controls, response gaps, and owned improvements without assigning blame.
Required block check · Block 2
Required for course progress · Pass with 3 of 4 correct
Block 3 of 5Triage and declare incidents with explicit criteria
Practice saved8 min
Triage and declare incidents with explicit criteria
Practice savedNo provider lesson is assigned to this block. Study the ITForMe lesson below, then take the required check.
Required ITForMe lesson
Triage and declare incidents with explicit criteria
By the end, you can
- Analyze supplied evidence for incident declaration threshold.
- Analyze supplied evidence for known-and-unknown triage record.
Incident response begins before certainty. Triage validates the alert, estimates scope and impact, preserves volatile evidence, and assigns severity using defined criteria. Declaration creates coordination, ownership, communication, and recordkeeping; it should follow the organization's threshold rather than an analyst's confidence alone.
Severity can change as facts change. Record what is known, unknown, assumed, and time-sensitive. An affected critical service, privileged identity, regulated data, or active spread can raise severity, while a safely contained test event may lower it. Reassess after each material finding and keep the earlier decision traceable.
Worked example
Endpoint telemetry reports credential dumping on one workstation, followed by use of the same administrator account on two file servers.
- 14:02 workstation: protected-process access by unsigned dump64.exe
- 14:09 file01: admin-ops remote logon from workstation
- 14:11 file02: admin-ops remote logon from workstation; severity criteria: low = one host, malware contained; high = suspected privileged-credential compromise used on another system; critical = confirmed regulated-data loss or organization-wide outage
The correlated privileged-account activity crosses the stated high-severity threshold even though full impact and data access remain unknown.
Declare a high-severity incident, preserve the three records, assign an incident lead, and validate or contain the account through the approved identity procedure.
Reasoning self-check
Endpoint telemetry reports credential dumping on one workstation, followed by use of the same administrator account on two file servers.
- 14:02 workstation: protected-process access by unsigned dump64.exe
- 14:09 file01: admin-ops remote logon from workstation
- 14:11 file02: admin-ops remote logon from workstation; severity criteria: low = one host, malware contained; high = suspected privileged-credential compromise used on another system; critical = confirmed regulated-data loss or organization-wide outage
- Record a timestamped fact table from the supplied evidence.
- Test the two most plausible explanations against every observation.
- Choose a bounded defensive action and state the result that would confirm it worked.
Compare your reasoning
Expected answers
- Declare a high-severity incident, preserve the three records, assign an incident lead, and validate or contain the account through the approved identity procedure.
- The conclusion cites at least two supplied observations and names one remaining uncertainty.
If you got stuck
- If the evidence conflicts, preserve both records and check clock, scope, and collection gaps before deciding.
- If no conclusion is supportable, request one specific log, capture, inventory fact, or controlled retest.
Compare your reasoning with the revealed answers if helpful. The block check below is required for course progress.
Required block check · Block 3
Required for course progress · Pass with 2 of 2 correct
Block 4 of 5Sequence containment, eradication, and recovery
Practice saved18 min
Sequence containment, eradication, and recovery
Practice savedRequired provider lesson
Study the lesson below before taking this block's check.
For this block: Read Table 3's RS.MI and RC.RP recommendations on printed pages 32–35. Focus on limiting spread, removing persistence and entry points, trusted backups, service verification, and recovery completion. About 15 minutes. If you have already studied this lesson, you can go to the check.
Read Table 3's RS.MI and RC.RP recommendations on printed pages 32–35. Focus on limiting spread, removing persistence and entry points, trusted backups, service verification, and recovery completion. About 15 minutes.
Provider links open in a new tab. Confirm what you studied when you return. Time on external sites is not recorded automatically.
ITForMe support and readiness practice
Sequence containment, eradication, and recovery
By the end, you can
- Analyze supplied evidence for response-phase purpose.
- Analyze supplied evidence for recovery verification.
Containment limits ongoing harm while preserving the ability to investigate and operate. Options include account restriction, host isolation, blocking a path, or disabling a vulnerable function. Choose actions based on urgency and business effect, record approvals when required, and verify that the harmful path stopped.
Eradication removes the cause, such as malicious persistence, exposed credentials, or vulnerable software. Recovery restores service from a trusted state and increases monitoring for recurrence. A rebuilt host returned with the same compromised credential is not recovered; pair host, identity, network, and application actions and define observation criteria before closure.
Worked example
A compromised web server is isolated after an attacker used a stolen deployment token and added a startup service.
- Isolation log: inbound and outbound denied except forensic collector
- Host image: service WebCache starts C:\Temp\cache.exe
- Identity audit: deployment-token-7 used from the server and has not been revoked
Isolation contains network activity, but persistence and the active token remain. Reconnecting after deleting only the file would leave a reusable access path.
Revoke and replace the token, rebuild from a trusted image, restore validated content, then reconnect under enhanced monitoring and verify no old-token use or WebCache service appears.
Reasoning self-check
A compromised web server is isolated after an attacker used a stolen deployment token and added a startup service.
- Isolation log: inbound and outbound denied except forensic collector
- Host image: service WebCache starts C:\Temp\cache.exe
- Identity audit: deployment-token-7 used from the server and has not been revoked
- Record a timestamped fact table from the supplied evidence.
- Test the two most plausible explanations against every observation.
- Choose a bounded defensive action and state the result that would confirm it worked.
Compare your reasoning
Expected answers
- Revoke and replace the token, rebuild from a trusted image, restore validated content, then reconnect under enhanced monitoring and verify no old-token use or WebCache service appears.
- The conclusion cites at least two supplied observations and names one remaining uncertainty.
If you got stuck
- If the evidence conflicts, preserve both records and check clock, scope, and collection gaps before deciding.
- If no conclusion is supportable, request one specific log, capture, inventory fact, or controlled retest.
Compare your reasoning with the revealed answers if helpful. The block check below is required for course progress.
Work through the scenario
Use the case evidence to complete the tasks, then check objectives.
Guided: Coordinate a suspected account takeover
A privileged account shows impossible travel and a new mailbox forwarding rule.
- Incident commanderactor
- Identity and mailbox timelinecontrol
- Privileged mailboxresource
- analystinterpretsevidence
- evidencedescribesasset
Objectives
- Interpret the supplied evidence without overclaimingpending
- Choose the bounded evidence-supported actionpending
- Select evidence that verifies security and operational outcomepending
Evidence 1
Identity risk marks two sign-ins 12 minutes apart across continents.
Evidence 2
Mailbox audit records an external forwarding rule after the second sign-in.
Evidence 3
Playbook authorizes session revocation and forwarding-rule removal with incident commander approval.
Fictional, disposable SOC evidence. No production system or external service is contacted.
Report an issue with this exercise
Required case practice
Required for the readiness checklist · Pass at 100%
Escalate a supplier compromise
A signed software update from a supplier launches an unexpected network client across several hosts.
- Incident commanderactor
- Cross-host incident timelinecontrol
- Managed endpointsresource
- analystinterpretsevidence
- evidencedescribesasset
Objectives
- Interpret the supplied evidence without overclaimingpending
- Choose the bounded evidence-supported actionpending
- Select evidence that verifies security and operational outcomepending
Evidence 1
Four hosts install the same signed update within 20 minutes.
Evidence 2
Each launches updater-helper and connects to an unlisted domain.
Evidence 3
Supplier status page acknowledges investigation but gives no containment advice.
Fictional, disposable SOC evidence. No production system or external service is contacted.
Report an issue with this exercise
Required block check · Block 4
Required for course progress · Pass with 2 of 2 correct
Block 5 of 5Use incident phases as decision states
Practice saved6 min
Use incident phases as decision states
Practice savedRequired provider lesson
Study the lesson below before taking this block's check.
For this block: Read Section 2 on printed pages 4–9, then Table 3's DE.AE-08, RS.MA-05, RS.MI-01/02, and RC.RP-06, plus Table 2's ID.IM-03. These selected entries cover declaration, response/recovery criteria, and continuous lessons. About 25 minutes; skip other table entries. If you have already studied this lesson, you can go to the check.
Read only Section 2.1 on printed pages 4–6, including Figures 1–2 and Table 1; stop before Section 2.2. Then read DE.AE-04/08 on page 26; RS.MA-05 on page 28; RS.MI N1 and RS.MI-01 N1 on page 32; RS.MI-02 N1/R1 on page 33; RC.RP-01 R1, RC.RP-05, and RC.RP-06 on page 34; and ID.IM-03 on pages 19–20. Skip all other sections and table entries. About 15 minutes.
Provider links open in a new tab. Confirm what you studied when you return. Time on external sites is not recorded automatically.
Optional ITForMe notes and practice
Use incident phases as decision states
By the end, you can
- Explain and apply incident-response decision state.
Preparation establishes authority, contacts, tooling, evidence handling, and exercises. Detection produces a signal; analysis validates it and estimates scope, impact, and confidence. Containment limits harm, eradication removes causes and persistence, recovery restores trustworthy service, and post-incident work turns evidence into owned improvements.
The phases are not a one-way checklist. New evidence during recovery can return the team to analysis or containment. Define entry and exit evidence, decision authority, safety constraints, communications, and remaining uncertainty for each transition.
Worked example
A rebuilt web service passes health checks, but a newly recovered log reveals an unreviewed persistence path on a peer.
- Containment blocked the original command channel
- Eradication removed one account and web shell
- Recovery validation omitted peer persistence review
Service health does not close the incident; new persistence evidence reopens analysis and containment for the peer while preserving the rebuilt service evidence.
Hold closure, scope the peer, contain the supported path, then repeat eradication and recovery exit checks.
Reasoning self-check
Recovery begins after one persistence mechanism is removed, but a peer host shows the same mechanism.
- Preparation contacts and custody process active
- Original host contained and eradication check passed
- Peer detection arrives during recovery
- Build a short evidence table that separates observations, supported conclusions, and remaining unknowns.
- Choose the authorized action that tests the leading conclusion with the least operational impact.
- Compare your decision and reopen condition with the expected results before continuing.
Compare your reasoning
Expected answers
- Return to analysis and containment for the peer, update scope, revalidate eradication and recovery, then carry the finding into post-incident corrective work.
- Reopen recovery if any peer retains persistence or if restored service lacks required monitoring and security controls.
If you got stuck
- If the answer depends on a product name alone, return to the actual evidence it produced.
- If no option can be falsified, name the missing record before choosing.
Compare your reasoning with the revealed answers if helpful. The block check below is required for course progress.
Required block check · Block 5
Required for course progress · Pass with 1 of 1 correct
Review this lesson
Use only this lesson's worked example and key concepts for a quick self-check.
- Restate the worked example in your own words.
- Name the lesson concepts that explain the result.
- Explain why the closest alternative does not fit.
Check the whole objective
This unlocks objective 3.2 for recall. The latest checkpoint needs 70% or higher; a lower result puts the lesson back near the front of your timeline.