Hiring a SOC analyst: the complete guide

Hiring a SOC analyst looks simple on paper: a SIEM, a stream of alerts, a team on rotation. In practice, it is one of the roles where the gap between a good CV and a good analyst is widest. This guide gives you a concrete method, from defining the level you need to making the offer, so you hire someone who can actually triage, investigate and escalate.

Start with the right level: L1, L2 or L3

The first mistake happens before the job ad goes live: looking for "a SOC analyst" without stating the level. The three levels call for different skills, different profiles and a different outreach message.

Level	Main role	What makes the difference
L1	Monitor, qualify alerts, follow runbooks, escalate	Rigour, method, ticket quality, knowing when to say "I don't know"
L2	Investigate escalated incidents, correlate sources, propose containment	Close reading of Windows and Active Directory logs, EDR fluency, investigative reasoning
L3	Handle complex incidents, threat hunting, improve detection rules	Knowledge of attacker techniques, detection engineering, ability to coach junior analysts

Three questions settle it. Who handles the 3 a.m. alert? Who writes new detection rules? Who talks to the business during an incident? If the answer is "the same person", you are probably not hiring an L1. Our article on the pentester job description applies the same scoping logic to another role.

Describe the context too: in-house SOC or MSSP, scope (endpoints, cloud, OT), tools in place, and a qualitative sense of alert volume ("noisy, tuning in progress" is useful information for a candidate).

The skills worth verifying

SOC job ads often list a dozen tools. Yet a good analyst learns a new SIEM in a few weeks. What takes longer to learn is reasoning. Focus your assessment on these points.

Technical skills

SIEM: writing a search, filtering, aggregating, pivoting from one indicator to the next. The query language (SPL, KQL or another) matters less than the logic.
EDR: reading a process tree, spotting a suspicious command line, understanding what isolating a host means for the user.
Windows and Active Directory logs: knowing the authentication, process creation, account and privileged group change events, and what they do not show.
Network: DNS, proxy, unusual outbound traffic, telling noise from signal.
Attacker techniques: phishing, credential theft, lateral movement, persistence. A framework such as MITRE ATT&CK helps structure the conversation.

Triage skills

Triage is the heart of the job. A good analyst can tell a false positive from an incident in minutes, documents why, and knows when to escalate without certainty. An analyst who escalates everything costs as much as one who escalates nothing.

Writing and communication

A poorly written ticket costs the whole team time, especially across shifts. Check that the candidate can summarise an incident in a few clear lines: what happened, what was checked, what remains. For L2 and L3, add the ability to explain an incident to a non-technical audience.

Where to find candidates

SOC analysts are plentiful on job boards, but the best spend little time there. Diversify your sources:

The technical community: CTF platforms, forums, security events and student associations. You meet people who practise, not just people who apply.
Career changers: system administrators, support technicians and network engineers often have the foundations for an L1 or L2 role. Our guide to hiring career changers explains how to assess them.
MSSPs and integrators: analysts there gain broad exposure and sometimes look for a steadier or deeper environment.
Referrals: your current analysts know their former colleagues. A good referral programme is often your most reliable source.

Craft the outreach message: state the level, the tools, how on-call works and where the analyst sits in the team. A generic message goes unanswered. For the job ad itself, our SOC analyst job description template walks through every section, from the title to on-call.

Assess in practice, not on claims

An interview alone will not tell you whether someone can investigate. The best method is still a short, realistic practical exercise matched to the level.

The log investigation exercise

Provide an anonymised or synthetic log set (Windows events, EDR extracts, proxy logs) built around a simple scenario: a host compromised through phishing, a suspicious sign-in on an admin account, lateral movement. Ask the candidate to:

qualify the alert (false positive, incident, needs more digging);
reconstruct a timeline;
identify indicators to search for elsewhere in the estate;
write a short escalation ticket.

Keep it to a reasonable duration and use fictional data. Never ask a candidate to work your real alerts. Our article on assessing cybersecurity skills explains how to design a fair exercise and score it with a rubric.

The hands-on lab

For L2 and L3, a lab in a controlled environment lets you go further: investigate an intrusion on a test Active Directory domain, find a persistence mechanism, propose a detection rule. This is what our shortlisted candidates do: they prove their skills on hands-on labs built around the role.

Structure the interview

An effective SOC interview usually has four parts:

Background and motivation: why the SOC, what kind of environment, how they feel about on-call and shift work.
Exercise debrief: ask the candidate to walk through their reasoning. The hypotheses they ruled out often say more than the conclusion.
Spoken scenario: "A user reports a strange email, the EDR flags an encoded PowerShell process. What do you do in the first fifteen minutes?" Our list of incident response interview questions gives you more scenarios.
The candidate's questions: their quality is a good indicator of maturity.

Have a security practitioner in the technical interview. An HR manager alone cannot judge whether an answer about a process tree holds up.

Build an offer that fits SOC work

A SOC analyst's offer is not just about salary. Candidates mainly compare working conditions.

On-call: frequency, compensation, expected response time, whether it can be declined or spread out.
Shift work: nights and weekends, rotation pattern, premiums set by the applicable collective agreement.
Remote work: possible or not, given the SOC's security constraints.
Progression: moving from L1 to L2, access to threat hunting or detection engineering, training and certification budget. Our article on certifications in hiring helps put them in context.
Tooling and workload: a SOC drowning in false positives burns out its analysts. Be honest about where you stand and what you plan.

Pay varies widely with level, sector, region and the weight of on-call duties. Set a realistic range at the brief stage so you do not lose a good candidate at offer time.

Mistakes to avoid

Hiring on a tool list: a candidate who knows your SIEM but cannot reason is less useful than one who reasons well on another tool.
Overrating certifications: they show learning effort, not investigative ability.
Hiding on-call duties: the candidate will find out, and you will lose them during the probation period.
Ignoring writing: in a SOC, ticket quality is handover quality.
A process that drags: good analysts get several approaches. A clear process with few steps and quick feedback makes the difference.
Hiring an L3 to do L1 work: they will leave quickly. Match the level to the real work.

In short

Hiring a SOC analyst means choosing the right level first, then verifying reasoning rather than keywords: triage, log reading, investigation and writing. A short practical exercise, a structured interview with a practitioner and an offer that is transparent about on-call will prevent most bad hires.

Opening a SOC analyst role? Share your hiring need: a recruiter and a security practitioner run the search together, and every shortlisted candidate proves their skills on a hands-on lab. See how we work.