RoleMath

Free training - skill primer

Learn Incident response for free

A free, source-cited path to learning defensive incident response, practiced only on systems, accounts, and logs you own or generate yourself — this is a learning path, not a certification and not a job guarantee. Incident response is learned by rehearsing how to detect and recover, never by attacking anyone else's systems.

What it is

Incident response is the defensive discipline of handling a security incident through its whole lifecycle: preparing before anything happens, detecting and analyzing that something is wrong, containing it so it cannot spread, eradicating the cause, recovering the affected systems, and documenting what was learned so the next incident goes better. It is deliberately a defender's skill — the goal is to protect and restore, not to attack. Because every organization that runs systems will eventually face incidents, the skill is broadly transferable: the same detect-contain-eradicate-recover discipline underpins SOC-analyst, incident-responder, security-analyst, and system-administration work across industries and platforms. The widely-taught version of this lifecycle comes from NIST's long-standing Computer Security Incident Handling Guide (SP 800-61 Rev. 2); note that NIST's 2025 revision (Rev. 3) reframes incident response within the CSF 2.0 functions — Govern, Identify, Protect, Detect, Respond, and Recover — for risk-management alignment, so you will see both the classic four-phase model and the newer CSF-aligned framing in the field.

The skill breaks into a few durable parts. Preparation: knowing your environment, having a runbook, and defining who does what before the pressure hits. Detection and analysis: reading alerts and logs to separate a real incident from noise, and scoping how far it reaches. Containment: limiting the blast radius — for example isolating an affected account or host — while preserving the evidence you will need. Eradication and recovery: removing the cause, restoring from known-good backups, and confirming the system is clean before it goes back into service. And the part beginners most often skip: documentation and lessons learned, the post-incident review that turns one painful event into a stronger defense. Running through these phases on paper and rehearsing them against logs you generate yourself builds the reflexes without ever touching a system you do not control.

The most important discipline in learning incident response is ethical and stays strictly defensive: you build the skill by preparing, detecting, and recovering on systems and accounts you own, and by studying real frameworks, not by probing or attacking anyone. This primer sequences free, official-first resources — including the authoritative NIST handling guide and free defensive labs that run against their own provided sandboxes — and gives you a first hands-on exercise where you write a runbook and rehearse the lifecycle against a local test account and logs you create. Nothing here involves attacking, scanning, or accessing any system you do not own.

Why it matters

Incident response is the shared baseline beneath SOC-analyst, incident-responder, security-analyst, and system-administration roles, because every organization eventually has to detect, contain, and recover from a security event. The lifecycle and the habits transfer across employers, tools, and platforms rather than tying you to one vendor's product, so the foundation compounds.

The free path, in order

  1. Learn the incident lifecycle from the authoritative guide. Read the phases in NIST's Computer Security Incident Handling Guide (SP 800-61 Rev. 2): preparation, detection and analysis, containment, eradication and recovery, and post-incident activity. This is the free, government-authored source of the classic lifecycle vocabulary; NIST's newer Rev. 3 (2025) reframes the same work within the CSF 2.0 functions, so knowing both framings is useful.
  2. Understand detection: logs, alerts, and noise. Learn what security-relevant events look like in system logs and how analysts separate a real incident from routine noise. Practice reading logs on your own machine so 'detection' is concrete rather than abstract.
  3. Study containment and evidence preservation. Learn how responders limit a blast radius — isolating an affected account or host — while preserving the evidence needed to understand what happened. Frame each action by which lifecycle phase it belongs to.
  4. Rehearse eradication and recovery. Learn to remove a cause, restore from a known-good backup, and verify a system is clean before returning it to service. Practice the mindset of 'trust nothing until verified' on a test system you own.
  5. Practice on free defensive labs. Work through free blue-team and incident-response rooms on a platform like TryHackMe, which run entirely inside their own provided sandbox — a safe, legal place to apply the lifecycle against realistic data you never have to attack anyone to see.
  6. Write and rehearse your own runbook. Turn the lifecycle into a one-page runbook for a specific scenario and rehearse it end to end against a local test account and logs you generate. Close with a short post-incident write-up — the lessons-learned step real teams live by.

Best free resources

Every resource is free and dated. Official sources are labeled; vetted community resources are labeled separately. Verify a resource is still free on its own page before relying on it.

Try it (free, safe, hands-on)

Write an IR runbook and rehearse detect to recover

Turn the incident-response lifecycle into a usable runbook and rehearse it — write a one-page plan for a scenario, then practice detect, contain, and recover against a local test account and logs you generate yourself. Entirely defensive, entirely on systems you own.

You will need: Your own computer or a VM you created (snapshot it first if it is a VM); A text file or notebook for your runbook and post-incident notes; Your machine's own logs and a throwaway local test account you create yourself

  1. Pick a concrete scenario you can reason about on a machine you own — for example, 'a local test account shows repeated failed logins.' Write it at the top of your runbook.
  2. Draft the runbook in five sections matching the NIST lifecycle: preparation (what you would have ready), detection and analysis (which log you would read and what you would look for), containment (what you would isolate), eradication and recovery (how you would clean and restore), and lessons learned.
  3. Detect: create a throwaway local test account on your own machine, deliberately mistype its password a few times to generate failed-login entries, then open your own machine's security/event log and find those entries. You are reading only your own device's logs.
  4. Contain and recover on your own test account: disable or lock the test account (containment), then reset its password and re-enable it (recovery), noting each action against the runbook phase it satisfies.
  5. Verify and document: confirm the account works as intended again, then write a short post-incident note — what you saw, what you did, and one improvement to the runbook. Delete the test account or revert your snapshot when done.
  6. Optionally, apply the same lifecycle inside a free TryHackMe incident-response room, which runs in its own sandbox, to see the phases against richer data without touching any real system.

What you should see: A one-page incident-response runbook mapped to the NIST lifecycle, real failed-login entries you generated and found in your own machine's logs, a test account you contained and recovered, and a short lessons-learned note — all defensive and all on systems and accounts you own.

Safety: This exercise is strictly defensive and stays entirely on systems, accounts, and logs you own or generate yourself. Never scan, probe, attack, or 'test' any system, account, or network you do not control; use TryHackMe only inside its own provided sandbox. Understanding incidents in order to detect and recover is the goal; performing attacks on others is not.

Where this skill gets used

Certifications that test it: isc2-sscp-systems-security-certified-practitioner, comptia-cysa-plus, comptia-security-plus, isc2-cc-certified-in-cybersecurity, comptia-pentest-plus.

Roles that need it: SOC analyst, Incident responder, Security analyst, Systems administrator.

Sources

Every resource is free and dated; official-first, community clearly labeled. A skill primer is a free learning path, not a certification, not professional experience, and not a job or salary guarantee. This primer is strictly defensive; labs run only on systems and accounts you own or the resources' own sandboxes. Born draft, pending human review.

All skill primers