SOC analyst tiers: What L1, L2 and L3 do

SOC analyst tiers describe how a security operations center divides its work. In a common three-tier model, L1 analysts triage alerts, L2 analysts investigate incidents in more depth, and L3 analysts handle advanced analysis and specialist improvement work. You'll also see these written as Tier 1, Tier 2 and Tier 3.

The boundaries overlap. Two employers can advertise the same level while expecting different decisions from the person they hire. When you're comparing roles, look for the work you'd own, the evidence you'd produce and the help available when a case goes beyond your experience.

L1 vs L2 vs L3 at a glance

This is a guide to a common division of responsibilities, not a qualification system. SANS describes the three-tier model, including investigation and improvement work that can cross tier boundaries.

A job may combine these responsibilities. NIST's explanation of jobs and work roles makes a useful distinction: a job can contain several work roles, and a work role isn't the same as a job title. Use that distinction when reading a vacancy with a long list of duties.

A tier number also isn't an incident's severity. An L1 analyst can be the first person to notice an urgent threat. That doesn't mean the threat waits in an L1 queue until someone completes a routine checklist. The team's escalation and incident-response procedures determine who needs to be involved and how quickly.

What each SOC analyst level does

L1: Review the signal and make the first decision

L1 work starts with a question about an alert: what does the available evidence support? You might establish which asset and account are involved, check the activity around the alert and compare it with the relevant procedure.

Your output should let someone understand why you closed or escalated the case. A label such as “false positive” without supporting notes gives the next shift little to work with. Clear evidence and a justified decision matter even when the investigation is short.

L2: Build a fuller account of the incident

An L2 analyst connects evidence across sources and works through questions the initial review couldn't answer. The work can include investigating other affected assets, explaining the sequence of events and coordinating the response with colleagues.

Tools are part of that work, but independent reasoning matters too. Microsoft's incident investigation documentation shows why analysts look across alerts, devices, users and evidence within a case. A single alert rarely answers every question about its scope.

L3: Bring specialist depth and improve the operation

L3 work can include advanced analysis, threat hunting, detection improvements and mentoring. SANS's SOC role guidance notes that this tier may not exist in every organization. It also describes open-ended work such as hunting, detection engineering and automation at L2, so those activities aren't reserved exclusively for L3.

Read the specialty in the description. A position centered on endpoint forensics may require different evidence from one centered on cloud detections. The tier number alone doesn't tell you which preparation will be useful.

For the wider route into this work, including skills and evaluating credentials, use our SOC analyst career guide.

A worked example: One alert, several kinds of work

The following case is fictional. The organization, asset, timestamps and findings are teaching examples. This illustrates responsibilities and communication; your employer's procedures determine the response to a real incident.

Imagine that an endpoint security tool flags an unfamiliar executable launching from a temporary folder on a finance laptop. The alert arrives at 09:20 UTC. The laptop is called FIN-LT-27, and a user reported opening an attachment shortly beforehand.

The starting evidence supports investigation. It doesn't yet establish that the executable is malicious, that data was stolen or that other devices are affected.

The L1 contribution: Establish what is known

The analyst checks the alert details and records the device, account, process path and event time. They inspect the available parent-process information and look for relevant alerts on the same device. They also check whether the activity matches an approved software deployment documented in the sources they can access.

For this example, the deployment records don't explain the executable. That is an unresolved finding, not proof that no legitimate deployment exists. The analyst records the sources checked and the missing explanation.

The endpoint timeline also shows a network connection after the process launched. The analyst records the destination and timestamp without claiming that the connection proves data theft. They escalate the case because the activity is unexplained and needs broader investigation.

A useful first decision is therefore: “We have enough evidence to investigate further, and these are the questions still open.” The L1 analyst doesn't have to solve the whole case to contribute valuable work.

The L2 contribution: Test the scope and response options

The next analyst reviews the existing notes before searching more widely. They check whether the same file or related behavior appears elsewhere, examine relevant identity and email events, and build a timeline that distinguishes the user's report from events recorded by tools.

Suppose this search finds similar activity on a second laptop. One device has incomplete telemetry during the relevant period. The case now has a broader scope and a specific evidence gap. The analyst records both rather than treating the missing events as proof that nothing happened.

The analyst also works through the response with the appropriate owner. Is there a reason to isolate an endpoint? Who can authorize that action, and who can perform it? What business activity would be affected? The case record should distinguish a recommended action from an action that has been completed and verified.

A title doesn't grant technical permissions. For example, Microsoft's device-isolation API documentation describes remediation permissions and device access requirements. An employer's approval process is a further question to resolve, even when a tool permits an action.

The specialist contribution: Resolve the difficult question

In our example, the remaining question is whether the unfamiliar executable created a persistence mechanism on the device with incomplete telemetry. A specialist can examine the authorized evidence available for that question, document the limits of the investigation and explain how much confidence the findings support.

That specialist might be an L3 analyst, a separate forensic responder or someone outside the team's tier structure. Their contribution is the expertise needed for the question, not simply being the third person to open the ticket.

After the incident, the team also has an improvement to consider: why was part of the device's activity unavailable? An owner can investigate the collection gap, test a correction and record how to detect a recurrence. Any proposed new detection needs review against relevant benign activity as well as the suspicious behavior.

The work doesn't always move in a straight line. An urgent case can bring the necessary responders together immediately. An L1 analyst can keep gathering useful context while another colleague handles a specialist question.

A copyable SOC escalation note

A good handoff makes the next action clear and preserves the work already done. The template below is our suggested practice structure, not a required industry format. Adapt it to your team's case system, handling rules and escalation policy.

For the fictional case, a short handoff could read:

Case and time: Training case SOC-042, updated 09:32 UTC.

Reason for escalation: Unexplained executable activity on FIN-LT-27 following a reported attachment opening. Needs broader scope review and a response decision.

Observed evidence: Endpoint alert at 09:20 UTC; unfamiliar executable in a temporary folder; subsequent network connection recorded in the device timeline. Relevant event references attached to the training case.

Checks completed: Reviewed available process ancestry, related device alerts and accessible approved-deployment records. No matching deployment found in those records.

Uncertainties: File intent, other affected assets and business impact aren't established. The reported attachment opening hasn't yet been matched to email evidence.

Actions taken: Evidence references preserved in the case. No device isolation performed. On-duty escalation contact notified through the team's approved channel.

Request and ownership: Please review scope and determine the required response. Record the accepting owner and next update time in the case.

The final line matters. Sending a message doesn't establish that someone accepted responsibility. In a practice exercise, include the receiving analyst's acknowledgment and the next agreed action so you can see where ownership passes.

You can use the same structure for a closure note by replacing the escalation request with the closure reasoning. Include what would cause the case to be reopened. Keep confidential evidence in the approved system rather than copying it into a public portfolio.

How to compare jobs with different tier labels

Choose two or three SOC analyst vacancies and compare their responsibilities side by side. Write down what each description says, then leave unanswered questions visible.

These questions help you understand the advertised level:

1. What would I own independently after onboarding? Ask for an example of a case you'd be expected to close and one you'd escalate.
2. Who is available when I need help? Check the arrangements on the shift you'd work, including nights and weekends where relevant.
3. Which response actions can I perform? Separate tool access, approval requirements and responsibility for checking the outcome.
4. How is investigation work divided? Find out whether analysts retain a case, pass it between teams or collaborate with a separate incident-response service.
5. What improvement work is part of the job? Ask whether detection changes, automation or hunting have allocated time and review support.
6. How is progression assessed? Request examples of work that demonstrate readiness for more responsibility.

For example, one fictional “Analyst II” job might mainly review escalations against established procedures with a senior responder available. Another might require independently coordinating multi-system incidents during an overnight shift. The shared title doesn't make the support or responsibility equivalent.

Compare pay in the same way: use the range for the actual role and location, then check base versus variable pay, hours and on-call expectations. A global salary table by tier would hide those differences.

Build evidence for the next kind of work

Choose a practice task that exposes a gap in your current work. Completing a longer list of courses isn't the same as showing that you can make a more difficult decision.

For initial triage, take a permitted training dataset and write a short case note. Explain the alert, which evidence you checked, what remains uncertain and why you would close or escalate it. Ask a reviewer whether they could follow your decision without repeating every step.

For broader investigation, connect several events into a timeline. Separate observations from your explanation, include a plausible alternative explanation and describe what further evidence would help resolve it. If a data source is missing, show how that limits your conclusion.

For specialist or improvement work, pick one bounded question. You could propose a detection for a documented training behavior, explain the required telemetry and test it against both relevant and benign examples. Record what it misses and what review would be needed before anyone used it in production.

These are suggestions for learning and demonstrating your reasoning, not a promotion checklist. Within a job, agree on appropriate opportunities with your manager and respect the access and change controls that apply to the work.

When you describe a lab on a resume, label it as a lab. Our cybersecurity resume examples show how to present project evidence without claiming experience you haven't had. For interview practice, use the SOC analyst questions and sample answers to rehearse explaining your decisions aloud.

Common questions about SOC analyst tiers

Is L1 a job for someone with no experience?

It can be an entry route, but the label doesn't establish the employer's requirements. Read the required experience and responsibilities in the specific posting. Check whether the position offers supervised onboarding or expects you to handle the queue independently from the start.

How long does it take to move from L1 to L2?

Use the employer's expectations for the next role rather than a fixed number of months. Ask which investigations, decisions and communication skills you need to demonstrate, how you'll get opportunities to practice, and who will review the work. Readiness and the availability of a position are separate questions.

Is L3 the same as SOC manager?

Don't assume so. Specialist technical work and people management have different responsibilities. Read whether the vacancy includes direct reports, scheduling, hiring and performance reviews, or whether it focuses on technical investigations and mentoring.

Does each level require a specific certification?

The tier labels don't prescribe a universal credential. Start with the requirements of roles you're considering. If a certification appears repeatedly, inspect its syllabus and assessment before deciding whether it addresses the skills you need. A credential doesn't replace an employer's other requirements.

Will AI remove the L1 role?

A vendor's claim about automating triage doesn't tell you whether a particular employer will remove a position. Ask what tools the team uses, which outputs analysts review and who owns decisions when the evidence is uncertain. Prepare to explain how you would check an automated finding against its supporting evidence.

Do I need to pass through every tier?

Use the work and entry requirements of the position you want. Someone bringing relevant engineering or investigation experience may have a different route from someone starting their first technical job. If you're deciding between operations and building security systems, our SOC analyst versus security engineer comparison can help you compare the day-to-day work.