SOC analyst

A SOC analyst (Security Operations Center analyst) monitors security events in an organisation’s information systems. They analyse alerts, look for signs of an incident and assess its severity. They document their findings so that response teams can act. Monitoring may happen in real time or after reports and logs are received. The role turns technical signals into situations that can be understood and prioritised.

The analyst examines system and application logs, network traffic and alerts from detection tools. They distinguish expected activity from an event that calls for investigation. Depending on the organisation, they report an incident, recommend an immediate measure or support investigation teams. They do not automatically take responsibility for every fix: the teams responsible for remediation retain that role.

The scope varies between a SOC within the IT department and a service provided to clients. Apec distinguishes N1 roles focused on spotting events, N2 roles involving deeper analysis and N3 roles covering complex cases and specific use cases. These levels are guides that depend on the post, rather than a mandatory progression for every company. Specify which decisions the person can make independently and which they must escalate.

SOC analyst, penetration tester and head of information security: who does what?

• SOC analyst: monitors, qualifies and documents events to help with incident response.
• Penetration tester: carries out penetration tests and technical assessments to identify vulnerabilities.
• Head of information security (RSSI): defines and implements the information systems security policy.

These professionals may exchange information. Their main responsibilities serve different needs: handling alerts, testing technical security or directing security policy.

A useful alert loses value if no one can qualify it, assess its severity or pass it on with enough context. The purpose of this hire is to provide analysis that helps the relevant teams decide what to do next. A usable incident report describes what was observed, the reasoning behind the assessment and what remains uncertain. Up-to-date dashboards and documentation also make the SOC’s work easier to understand.

The need varies with the monitoring workload and the division of responsibilities. A post focused on initial triage calls for someone who can recognise signals that merit investigation and follow escalation paths. If the person must investigate further or adjust detection rules, look for broader technical autonomy. The job title alone does not establish who decides whether an incident is confirmed, who contacts technical teams or who follows up on fixes.

Hypothetical example: several alerts concern the same machine within a few minutes. An analyst should consider them together rather than pass each on separately without context. They examine the available logs and traffic, explain the evidence that supports or weakens the incident hypothesis, then pass on a prioritised case in line with SOC procedures. This illustrates an approach, not a universal procedure.

A poorly defined remit can blur neighbouring roles. Hiring a penetration tester to handle routine monitoring, or expecting a SOC analyst to define security policy alone, makes assessment misleading. Working conditions also matter: on-call duties are possible, but whether they exist and how often they occur depends on the post. Specify them before comparing candidates. Identify the teams that will receive escalations and those that will carry out remediation, so the future analyst knows the limits of their authority.

• Monitor logs, network traffic and alerts to spot suspicious activity.
• Analyse and qualify security events using the available evidence.
• Assess an incident’s severity and prioritise its handling.
• Report incidents and escalate cases beyond their decision-making remit.
• Document investigations and write reports that response teams can use.
• Pass recommendations to the teams responsible for remediation, depending on the post.
• Update activity dashboards and keep operational documentation current.
• Help collect logs and adjust correlation rules, according to their level of autonomy.

Several routes can prepare someone for the role. ANSSI cites a French Bac +3 qualification specialising in cybersecurity or initial experience in network and systems engineering. Apec mentions French Bac +3 courses in computing and Bac +5 courses specialising in cybersecurity. These routes help identify what a candidate may have learned. On their own, they do not establish whether the person can qualify an incident in the SOC you run.

Start by examining what the candidate can do with real or reconstructed records. Can they read a log, interpret network traffic and connect events without mistaking coincidence for proof? Do they understand systems, protocols and attack techniques well enough to form a testable hypothesis? Relevant training can provide this foundation, but experience in networks and systems can also build it.

Assess experience through responsibilities the candidate has actually held. For an initial triage post, look for situations in which they identified an anomaly, justified their assessment and passed on the right information. If the post includes deeper analysis, ask how they assessed an incident’s severity and documented uncertainties. If the remit includes improving detection, examine their contribution to correlation rules, log collection and procedure updates.

Finally, assess their ability to work with the teams responsible for remediation. A technical analysis may be hard to use if the facts, priority and escalation recipient are unclear. The quality of an incident report or dashboard can make this skill visible, whatever the candidate’s original route into the role.

In its recruitment method, GetPro uses a set of prioritised criteria. It distinguishes criteria that can be checked against a candidate’s background from those to explore in interview, particularly through open questions and concrete examples. With the candidate’s prior consent, references can shed light on skills that remain uncertain.

To assess a SOC analyst, start with the alerts they will handle, the decisions they can make and the teams to which they will pass their conclusions. The steps below are advice tailored to this role.

1. Set the criteria for the post

Describe the sources your SOC uses, the expected level of analysis and the escalation rules. Distinguish initial triage, deeper investigation and contribution to detection rules. Someone responsible for initial triage must recognise signals worth examining and pass on a clear case file. A more autonomous post calls for someone who can connect several pieces of evidence, justify a priority and explain the limits of their analysis. Prepare a short set of criteria: quality of qualification, technical reasoning, escalation decisions, documentation and collaboration. A confident answer without verifiable evidence is a warning sign.

2. Examine past work

Ask the candidate to describe an alert they analysed, omitting confidential information. Have them specify the logs or network traffic they consulted, the hypotheses they ruled out, the severity they assigned and who received their report. A good answer separates observed facts from deductions and explains what information was missing. For a post that includes improving detection, ask which rule they adjusted and what finding prompted the change. An account limited to naming a tool says little about analytical ability.

3. Offer a practical exercise close to the post

Present a few alerts and log extracts consistent with your environment, then ask for an assessment and a handover note. Hypothetical example: two alerts and an extract of network traffic appear to concern the same device. Ask which connections would be useful to explore, which event warrants investigation and what remains uncertain. Observe the candidate’s approach, questions and reasons for prioritising. The output could be a short report distinguishing evidence, hypotheses, severity and the next action. Do not reward certainty that the case data cannot support.

4. Check communication and limits of authority

Ask the candidate to restate their conclusion for a systems or incident response team. They should say what they would pass on, to whom, and which decision belongs to the recipient. Ask about a disagreement over priority: what facts would they offer to support their assessment? If they have already defined procedures or worked in a team, ask how they made these exchanges repeatable. A positive sign is precise wording that lets the recipient act without assigning the analyst responsibility for every fix.

5. Cross-check references and expertise

With the candidate’s consent, ask a professional referee what types of alerts they handled and when they escalated them. Seek a description of their actual responsibilities, rather than just an N1, N2 or N3 level. If your company has no expert able to assess the technical exercise, involve someone qualified in monitoring or incident response. Use the same set of criteria to compare candidates and flag separately anything no one could verify.