SOC analyst job description: template and advice

Most SOC analyst job ads look alike: a list of tools, "security incident management", "team player". Candidates who have options skim them and move on. This guide gives you a structure, an annotated template and the wording to avoid, so your SOC analyst job description attracts the right people at the right level.

What a SOC analyst looks for in a job ad

A SOC analyst reads a job ad with one simple question in mind: what will my week look like? They want concrete answers on four points.

• The real level of the role: triaging alerts against runbooks, investigating escalated incidents, or writing detection rules and hunting threats.
• The rhythm: office hours, shift work, nights, weekends, on-call. This is often what decides whether they apply.
• The environment: in-house SOC or managed security service provider (MSSP), monitored scope, tooling in place, detection maturity.
• Progression: a path to the next level, access to threat hunting or detection engineering, training budget.

A job description that answers these four questions clearly already stands out from most ads. If you have not settled these points internally yet, start with our guide to hiring a SOC analyst, which covers scoping before writing.

Pick the level before writing a single line

The most common mistake is a job description that describes an L1 in the responsibilities, asks for an L3 in the requirements and offers L1 pay. The level must be consistent from the title to the last line.

If your SOC does not work in tiers, describe the expected autonomy directly: "you handle an incident end to end on your own" says more than any title.

The annotated template

Here is a framework to adapt. Each block comes with a note on what it should contain.

1. The title

• Example: "SOC Analyst L2, in-house SOC, Lyon, hybrid".
• Note: level, type of SOC and location are enough. Avoid internal or inflated titles nobody searches for.

2. The context

• What you do in two sentences, the size of the SOC team, who it reports to (CISO, CTO, operations).
• Why the role is open: building the SOC, moving to 24/7 coverage, growth, a replacement.
• Note: candidates want to know whether they are joining a structured team with established runbooks or a SOC being built, where they will have more latitude. Both appeal to different people, as long as you say which it is.

3. Responsibilities

For an L2, for example:

• Investigate alerts escalated by L1 analysts and qualify incidents.
• Correlate available sources (SIEM, EDR, Active Directory logs, proxy) to rebuild a timeline.
• Propose and follow up containment actions with operations teams.
• Write clear tickets and incident reports.
• Flag recurring false positives and help tune detection rules.

Note: list four to six real responsibilities, ordered by how much time they take. If a large part of the job is handling noise, say so honestly and explain what is planned to reduce it.

4. The technical environment

• SIEM, EDR, ticketing tool, any orchestration tooling.
• Monitored scope: endpoints, servers, cloud, email, industrial environments.
• Note: present tools as context, not as requirements. A good analyst picks up a new SIEM in a few weeks.

5. The profile

Keep two short, clearly separated lists.

Required (for an L2):

• Take an investigation from an alert to a reasoned conclusion.
• Read and interpret Windows and Active Directory logs, and a process tree in an EDR.
• Write search queries in a SIEM, whatever the query language.
• Write an escalation ticket a colleague can pick up without asking questions.

Nice to have:

• Familiarity with a framework such as MITRE ATT&CK to structure analysis.
• Scripting to automate repetitive tasks.
• Experience with a cloud environment.
• Regular practice on defensive training platforms or CTFs.

Note: phrase skills as observable actions. "Can rebuild the timeline of a compromised endpoint" says far more than "incident management expertise".

6. Conditions

• Working hours, shift pattern, on-call frequency and compensation.
• Remote work policy, given the SOC's own constraints.
• Salary range.
• Training, funded certifications, time for keeping up to date.
• Note: this is the most read section. Pay varies widely with level, region, sector and on-call load, which is why a realistic range beats leaving candidates to guess.

7. The hiring process

• Number of stages, approximate duration and the type of technical assessment.
• Note: see the dedicated section below.

Be upfront about on-call and shift work

Working rhythm is the most sensitive topic in a SOC job description, and the one most often dodged. A candidate who discovers unannounced nights or weekends at interview withdraws, and one who discovers them after joining leaves during the probation period.

At a minimum, state:

• whether the SOC runs office hours, extended hours or 24/7;
• how shifts are organised and how often they rotate;
• how on-call and unsocial hours are compensated, under the applicable collective agreement;
• whether the rhythm changes with level (an L3 is sometimes taken off night shifts).

This filters out, early on, candidates for whom the rhythm does not work, and reassures those who accept it knowingly.

Wording mistakes that drive candidates away

• A tool list as a profile: ten product names do not describe an analyst. They screen out solid people trained on other tools.
• Years of experience as the only bar: "three years minimum" says nothing about real ability. Describe the expected autonomy. For an L1, many system administrators and support technicians already have the basics, as our article on hiring career changers explains.
• Certifications required by default: a certification shows learning effort, not investigative ability. Our look at certifications in hiring helps you list them as nice to have rather than required.
• Mixing jobs: a role combining SOC, network administration, compliance and user support attracts nobody good at any of them.
• Empty buzzwords: "passionate", "dynamic", "exciting environment". Candidates would rather know what they will do on Monday morning.
• No salary range: many approached candidates will not bother replying to an ad without any indication of pay.

Describe the assessment process

A SOC analyst knows an interview alone cannot judge investigative reasoning. A job description that announces a short, realistic practical assessment shows the team knows what it is looking for. A typical process:

1. A first conversation about background, expectations and working rhythm.
2. A short practical exercise on fictional logs: qualify an alert, rebuild a timeline, write a ticket.
3. A technical interview with an analyst from the team, focused on debriefing the exercise.
4. A final conversation with the SOC manager.

State how long the exercise takes and that it uses fictional data. Our guide to assessing cybersecurity skills explains how to design a fair exercise and score it with a rubric. The same approach works for other roles, as our pentester job description shows.

Checklist before publishing

• The level is the same in the title, responsibilities, profile and pay.
• Responsibilities are real, ordered by weight, four to six of them.
• Required skills fit in four or five lines, phrased as actions.
• Hours, shifts and on-call are described without ambiguity.
• A salary range is shown.
• The hiring process is described, including the practical exercise.
• The whole thing reads in a minute.

In short

A good SOC analyst job description sets a clear level, describes real responsibilities, separates required from nice to have, tells the truth about working rhythm and announces a practical assessment. That is what lets the right candidate recognise themselves and reply.

Opening a SOC analyst role and want help scoping it? At Cyber Recrut, a recruiter and a security practitioner build the job description with you, then our shortlisted candidates prove their skills on hands-on labs close to your environment. See how we work or share your hiring need.