Cybersecurity

Incident Responder

Take control of a compromise that is happening right now.

This is a senior destination, reached after several years in hands-on roles.

What you actually do

  • Establish what is actually happening while the situation is still moving
  • Decide what to isolate and what to leave running, knowing both choices cost something
  • Reconstruct the attacker’s route in, and find everywhere else they reached
  • Preserve evidence properly while still moving fast
  • Brief people who need a decision, not a technical explanation
  • Run the recovery, then write the honest account of what happened

Technologies you may touch

Nobody uses all of these. Which ones depends entirely on the employer.

  • EDR platforms Agents on every machine that record behaviour and can isolate a device the moment it looks compromised.
  • Splunk Collects logs from everything in one place and lets you search across all of it at once.
  • Wireshark Records and displays the actual conversation between two machines, packet by packet.
  • Active Directory The Microsoft system that holds every user, group and computer account in most organisations, and decides what each can open.
  • Linux The operating system most servers, network devices and cloud workloads run on, driven from a command line.
  • Windows Server The Microsoft server platform running file, directory, application and print services in most enterprises.
  • Python A general-purpose language used across automation, security tooling, data work and applications.

Concepts you will learn

These transfer between employers and outlast any particular product.

  • Containment, eradication, recovery
  • Chain of custody
  • Attacker persistence
  • Blast radius
  • Post-incident review

Where this work happens

Incident response consultancies Large enterprise security teams Government and defence Financial services

You may enjoy this if…

  • You get calmer rather than more scattered when things go badly
  • You like being the person who makes the call
  • You enjoy piecing a story together from evidence under time pressure

The honest downside

Incidents arrive at inconvenient times and last longer than anyone plans for. The work is genuinely stressful, and the consulting version involves travel at short notice. This is a role you grow into from SOC or systems work.

What it pays

Pay is the thing people most often get misled about, so here is where every number comes from — including the ones that are not really numbers.

Nearest official occupation

Median for the occupation

$124,910

Information Security Analysts (15-1212)

What you actually start on

Senior entry — grown into from SOC or systems work

Outlook

+29% — much faster than average, but heavily experience-gated at the entry end

There is no exact official occupation for this role. The figure comes from the closest one, which covers a somewhat different set of jobs.

Within Information Security Analysts (15-1212). Consultancy incident response often pays above the median but comes with short-notice travel and genuinely unsociable hours.

A median is the midpoint of everyone employed in that occupation, including people decades into their careers — so starting pay runs materially lower. Verify against the live BLS page before making a decision.

Source: U.S. Bureau of Labor Statistics · BLS OES, May 2024 release · figures are national and United States–specific; pay varies substantially by region and employer. Nothing here is adjusted for cost of living.

CertBlueprint earns affiliate commission on some study resources. It earns nothing from Incident Responder salaries, and no role is ranked, recommended or presented more favourably because of what it pays.

Where this leads

IT careers are a graph, not a ladder. These are the moves people actually make from here — each one reuses most of what you already know.

See where Incident Responder sits on the whole map →

Digital Forensics Analyst

The slower, deeper version of the same reconstruction.

Threat Hunter

Looking for the incident before it declares itself.

Security Architect

Seeing enough incidents tends to produce strong design opinions.

Often confused with

Titles overlap heavily in IT and tell you very little. Each of these puts Incident Responder beside another role on the same dimensions, with the practical differences underneath.

vs SOC Analyst vs Digital Forensics Analyst vs Threat Hunter vs Security Architect

Try it this weekend, before you spend anything

Reading about work and doing it are different. Each of these is free, runs on the machine you already have, and takes under an hour and a half. Finding out you dislike it is a genuinely useful result — and far cheaper here than after an exam voucher.

Try the work · 45–70 minutes

Follow a packet

Free

Find out where your own traffic actually goes on its way out of the building — and what it looks like when it stops arriving.

Nothing to install · no account · open the steps

Before you start

Everything here runs against your own machine and connections you already make. Do not trace, scan or probe networks you do not own or have written permission to test — in many countries that is a criminal offence, not a grey area.

Built-in commands only. Nothing to install, no account, nothing to sign up for.

  1. Watch a name turn into an address

    Every connection starts by looking up a name. Run this against a site you use daily, then against a site in another country. Notice you get different addresses — sometimes several.

    Windows
    nslookup bbc.co.uk
    macOS
    dig bbc.co.uk +short
    Linux
    dig bbc.co.uk +short

  2. Trace the path out

    This lists every router your traffic passes through to reach that address. Read the hostnames down the left — you can usually see it leave your house, reach your provider, and cross into a backbone network.

    Windows
    tracert bbc.co.uk
    macOS
    traceroute bbc.co.uk
    Linux
    traceroute bbc.co.uk

  3. Find where the time goes

    Look at the millisecond figures. Somewhere there is a jump — 8ms to 90ms between two hops. That jump is usually the moment your traffic goes long-distance. Now trace somewhere far away and compare where the jump happens.

  4. Break it on purpose, then put it back

    Add a line to your hosts file pointing a site you use at 127.0.0.1, and try to load it. Watch how the failure looks from the browser — the error will not tell you what you just did. Then delete the line. This is the single most useful thing on this list: you have now seen a name-resolution fault from the user's side, which is what half of all "the internet is down" tickets actually are.

    Windows
    notepad C:\Windows\System32\drivers\etc\hosts   (run as Administrator)
    macOS
    sudo nano /etc/hosts
    Linux
    sudo nano /etc/hosts

  5. Optional — watch the actual conversation

    If you want to go further, install Wireshark, capture for ten seconds while loading one page, and filter for "http" or "dns". You will see the individual messages between your machine and the server. This is the one step that needs an install, which is why it is last.

This suits you if…

  • You kept going past step three without being told to
  • The latency jump made you want to know exactly where that hop was
  • You found the deliberate breakage satisfying rather than pointless
  • You wanted to know why a hop showed asterisks instead of a time

If you disliked it

If this felt like tedious bookkeeping, take that seriously. Networking and network security roles involve a great deal of exactly this — patient, methodical narrowing down, often at 2am. Finding it dull here is genuinely useful information, and it is much cheaper to learn it now than after a CCNA.

Try the work · 45–60 minutes

Read your own logs

Free

Reconstruct what your computer did last night, from the record it kept without anyone asking it to.

Nothing to install · no account · open the steps

Before you start

Your own personal machine only. Do not do this on an employer's systems, or any system you do not personally own, without written authorisation — reading logs you are not authorised to read is a disciplinary matter at best and an offence at worst. That rule does not relax because you are curious or well-intentioned.

Uses the log viewer already built into your operating system. Nothing to install.

  1. Open the record

    Your machine has been writing down what it does, continuously, for as long as you have owned it. Most people never look.

    Windows
    eventvwr.msc  →  Windows Logs  →  System
    macOS
    Console.app  →  select your Mac under Devices
    Linux
    journalctl -b --no-pager | less

  2. Find yourself in it

    Locate the moment you logged in this morning. Note the exact timestamp and the event id. You have just done the core move of every investigation: anchoring to one known event so everything else can be measured against it.

    Windows
    Security log → filter Event ID 4624 (successful logon)
    Linux
    journalctl -b | grep -i "session opened"

  3. Establish what normal looks like

    Scroll a full day. Find three things that happen every single day at roughly the same time — an update check, a backup, a scheduled task. Write them down. This is baselining, and it is the skill that separates people who spot a real intrusion from people who chase noise for a year.

  4. Find the one that only happened once

    Now look for something that appears exactly once in the last week. A driver failure, an unexpected shutdown, a service that crashed. Read the surrounding twenty entries either side. Can you tell a story about what happened, and what happened next as a consequence?

  5. Write the timeline

    Pick five events, put them in order with timestamps, and write three sentences explaining what occurred. Show it to someone non-technical. If they understand it, you have just done the part of security work that most people are worst at — the writing, which is what actually gets acted on.

This suits you if…

  • You lost more time to it than you meant to
  • Finding the once-only event felt like a small win
  • You wanted to search for one identifier across the whole log to see where else it appeared
  • Writing the timeline felt satisfying rather than like homework

If you disliked it

If the volume felt overwhelming and the payoff too thin, that is worth knowing before committing to security operations. A SOC analyst does this all day, mostly finding nothing, and the tolerance for that is either there or it is not. It is a completely reasonable thing not to have.

Try the work · 60–90 minutes

Write a detection

Free

Define what normal looks like, write a rule that catches an exception to it, then find out how often your rule is wrong — which is the part nobody tells you about.

Nothing to install · no account · open the steps

Before you start

Your own personal machine only, exactly as with the log-reading trial. Do not run detections across systems you do not own or are not authorised to monitor.

Your own machine’s logs and a command line. Nothing to install, no account.

  1. Pick something that should be rare

    Choose one event that ought to happen occasionally but not constantly on your own machine: a failed login, a service crashing, a scheduled task failing, a USB device connecting. Rare-but-real is the sweet spot — common events make useless alerts and impossible events make rules you can never test.

  2. Count it over thirty days

    Before writing any rule, find out how often it actually happened. This number is your baseline, and skipping this step is the single most common reason real detections get switched off within a fortnight for being too noisy.

    Windows
    Get-WinEvent -FilterHashtable @{LogName="Security"; Id=4625; StartTime=(Get-Date).AddDays(-30)} -ErrorAction SilentlyContinue | Measure-Object | Select-Object Count
    Linux
    journalctl --since "30 days ago" | grep -ci "authentication failure"
    macOS
    log show --last 30d --predicate 'eventMessage CONTAINS "Failed"' | wc -l

  3. Write the rule

    Express your detection as something runnable — a filter, a grep, a query. Not pseudocode. It needs to actually execute so it can actually be wrong, which is the only way you will learn anything from it.

    Windows
    Get-WinEvent -FilterHashtable @{LogName="Security"; Id=4625; StartTime=(Get-Date).AddHours(-24)} -ErrorAction SilentlyContinue | Group-Object -Property @{e={$_.Properties[5].Value}} | Where-Object Count -ge 3
    Linux
    journalctl --since "24 hours ago" | grep -i "authentication failure" | awk '{print $NF}' | sort | uniq -c | sort -rn | awk '$1>=3'

  4. Deliberately set it off

    Trigger the thing yourself — mistype your own password four times, plug in a USB stick. Does the rule fire? A detection you have never seen fire is not a detection; it is a hypothesis. Astonishing numbers of production rules have never been tested this way.

  5. Now find out how wrong it is

    Run it across the full thirty days. Every hit that was not really an attack is a false positive — and every one of those, in a real SOC, costs a human being fifteen minutes. Calculate your rate. If it is above roughly one a day for one machine, imagine that multiplied by five thousand machines and ask whether anyone would keep it switched on.

  6. Tune it once, and record what you gave up

    Narrow the rule to cut the noise — raise the threshold, exclude a known-good source. Re-run it. Then write down what you can no longer catch as a result. Every tuning decision trades coverage for signal, and being unable to state what you traded away is how organisations end up blind in ways nobody has documented.

This suits you if…

  • Watching your own rule fire was satisfying
  • The false-positive count made you want to fix the rule rather than abandon it
  • You enjoyed the trade-off in the last step rather than finding it frustrating
  • You started wondering what else you could baseline

If you disliked it

If the tuning loop felt like an endless treadmill with no clean answer, that is an accurate preview — detection engineering never reaches a finished state, and tolerance for permanent, incremental, never-quite-right work is what the role requires. Enjoying the investigation but not the rule-writing points toward analysis, hunting or response instead.

Certifications that fit this path

These come last for a reason. A certification is evidence for a direction you have already chosen — it is not the direction itself.

Foundation CompTIA Security+ The baseline. Core CompTIA CySA+ Covers the analysis and response cycle directly. Advanced ISC2 CISSP Breadth credential for senior response and leadership roles.

Not sure whether this is actually you?

Reading about a role and enjoying the work are different things. The scenarios show you the problems instead of describing them, and tell you which ones you keep reaching for.

Try the scenarios →