LO
Get told when a verified record lands on this occupation →
Security analyst (SOC)
Watches an alert queue for the one event that matters, decides whether it is an incident, and is the person who says out loud that the company is under attack.
This is not a probability of losing your job. It combines how much of the role's task load is exposed to automation with how far adoption has actually gone — useful for comparing occupations on one consistent basis, and for nothing else.
Covers defensive security operations — monitoring, triage, incident response, threat hunting. It does not cover penetration testing, governance and compliance work, or security architecture, which are different jobs often sharing the word security. Whether your organisation runs its own operations centre or buys one as a service changes what the job contains more than any tool does.
The evidence base holds verified records for other occupations, but not one for this one yet. Until it does, the analysis below is reasoning about task structure and known technical capability — for this job in particular it is not backed by traceable sources, and we would rather say so than cite things we have not verified. An empty section here is a gap in our coverage, not a finding about the work.
What is actually changing#
The unit of analysis is the task, not the job title. A role is not replaced — its task mix shifts.
Is this your job? Say so and this page narrows to your share of it.
A job title is a bundle of tasks bought together, and no two people hold the same bundle. Nothing is sent anywhere — it stays in this browser.
Working the alert queue
Automating≈ Platform inferenceGoing through hundreds of alerts a shift and deciding which two are worth looking at.
This is the same task as a guard watching camera feeds and it fails for the same reason: sustained vigilance collapses in about twenty minutes and the base rate of true positives is brutal, so the human baseline is poor and software does not get bored. Correlation and enrichment are also machine-checkable in a way the rest of this job is not — the alert either matches a known pattern or it does not.
The alert queue is where this occupation hires, so automating it removes the training ground rather than the work — the judgement needed further up is currently built by grinding through the queue, and nobody has said what replaces that. Automating triage also does not reduce alerts; it moves the analyst from reading them to tuning what generates them, which is a different and less staffed job.
Deciding it is an incident
Still human-led≈ Platform inferenceCalling it: waking people up, pulling a system off the network, telling the business it has a problem — on incomplete information and before you can be sure.
The cost of the two errors is wildly asymmetric and both are expensive: pulling a production system on a false positive and missing a real intrusion are both career events, and the decision is made with authority rather than certainty. No system is given that authority anywhere we can verify, and the reason is accountability rather than accuracy.
The decision staying with a person does not mean the person is in your building: this is the task most commonly outsourced to a managed service, which moves it without automating it. Read the direction as being about what kind of thing it is, not as a guarantee that your employer will keep employing someone to do it.
Writing the detection
Being augmented≈ Platform inferenceTurning what you learned from one incident into a rule that catches the next one without drowning the queue.
Writing the query is now cheap and models do it well, because a detection rule is code with a testable output. Deciding what to detect is not: it requires knowing what normal looks like in this specific estate, which is knowledge held by people and written down almost nowhere.
Cheap rule-writing makes the false-positive problem worse rather than better, because the constraint was never the writing. A team that can now produce ten times the detections has to be ten times more disciplined about retiring them, and nobody staffs for that — which is how a tool that helps an individual degrades the queue everyone works.
Looking for what nothing alerted on
Still human-led≈ Platform inferenceStarting from a hypothesis rather than an alert — assuming something is already inside and going to look for it.
Hunting is defined by the absence of a trigger, which removes the input every detection tool needs. What replaces the trigger is a guess about an adversary's goal in this particular organisation, and that guess is made from knowing what the company has that is worth taking.
This is the first activity cut when the queue is loud, because it produces no ticket and no metric. A task can be entirely human and still disappear from a team's week without anybody deciding to remove it — and in this occupation that is the usual way it goes.
Which technologies matter here#
Four separate signals. They are deliberately not added together — a job exposed to two technologies is not twice as exposed.
How it got here#
The index is not a static number. This is where it would have sat at each capability checkpoint since ChatGPT — reconstructed, and labelled as such.
The rise is one task, and it is the same task that lifts the security-guard curve on this site: working an alert queue is sustained visual vigilance, which humans fail at within about twenty minutes while software does not get bored — and correlation is machine-checkable in a way the rest of this job is not. It flattens because calling an incident is made with authority rather than certainty, and no organisation we can verify has delegated that. Two things the curve cannot show, both of which matter more than its height: the alert queue is where this profession hires, so automating it removes the rung senior judgement was built on; and outsourcing to a managed service moves this work without automating any of it, and arrives faster than any tool.
A flat line is not a forecast of safety. It says which tasks automation has reached so far — the occupations that moved least here are the ones where the constraint is physical or regulatory, and both of those can change.
Recent changes#
No verified events recorded yet.
This section will fill from the monitoring pipeline as events are collected, de-duplicated, graded and linked to the tasks above. An empty list here means we have not verified anything — it does not mean nothing is happening.
"We found no news" is not the same as "you are safe."
What this means for you#
The entry rung in this field is the alert queue, and it is the rung with the clearest automation mechanism pointed at it. That is a genuine problem for the profession and not only for you: the judgement senior analysts have was built by grinding that queue, and nobody has designed a replacement for it. Get to incident work early, and treat any team that lets you sit in on a real incident as worth more than a pay rise.
Two numbers decide your team's future and both are yours to produce: the true-positive rate of your queue, and how many detections you retired last quarter. A team that cannot answer the second will find its tooling budget spent on generating more of what it already cannot read.
Your options#
Four directions, each with its real constraints and one thing you can test this week. Continuing as you are is a legitimate choice — it just has to be a chosen one.
Move up the queue, not along it
The people who survive triage automation are the ones who tune what generates the alerts rather than the ones who read them faster.
Detection engineering is a different skill set that most SOCs will not train you in on shift.
Measure the true-positive rate of the noisiest rule you have. If it is under one in fifty, you have found this quarter's project.
Be the person who knows this estate
Every tool needs a baseline for normal and no vendor can supply one for your company. That knowledge is the input nothing can buy and it is what hunting runs on.
It makes you valuable to this employer specifically, which is leverage in a negotiation and a weakness in a job search.
Try to write down what normal looks like for your busiest system in five sentences. If you cannot, that is the gap and it is yours to fill.
Common questions#
Triage is genuinely moving, and for a reason worth understanding: it is the same task as a guard watching camera feeds, and humans fail at it the same way — sustained vigilance collapses in about twenty minutes while software does not get bored. What is not moving is calling an incident, because that decision is made with authority rather than certainty and the cost of both errors is severe. The real risk to the profession is not replacement, it is that automating triage removes the rung where analysts' judgement was built.
No date. The signal is the true-positive rate of your own queue and what share of your shift goes to alerts a system could correlate without you. Both are measurable this week. The organisational signal to watch is different and more predictive: whether your employer is talking about a managed service, because outsourcing moves this work without automating any of it and it arrives much faster than any tool.
Writing the rule is the cheap half and models do it well, because a rule is code with a testable output. Deciding what to detect is the other half and it depends on knowing what normal looks like in your specific estate — knowledge held by people and written down almost nowhere. The caution is that cheap rule-writing makes the false-positive problem worse, because the constraint was never the writing: a team producing ten times the detections has to be ten times more disciplined about retiring them, and almost nobody staffs for that.
Protected from automation, yes — hunting is defined by the absence of a trigger, which removes the input every detection tool needs. But it is the first activity cut when the queue is loud, because it produces no ticket and no metric. That is the pattern worth internalising: a task can be entirely human and still vanish from a team's week without anyone deciding to remove it, and in this occupation that is the usual way it goes.
Method and sources#
- Assessment date
- 2026-09-14
- Basis of the task judgements
- 0 evidence-backed · 4 platform inference · 0 not enough evidence
- Verified events
- 0