Hiring a ready-made L2 analyst on the open market means competing for a narrow pool of people that other organizations are chasing just as hard. A more sustainable strategy is to grow an L2 from an L1 inside your own SOC, because that specialist already knows your infrastructure, your products, and your escalation processes — not just the general theory of incident response.
The problem is that "growth from L1 to L2" is rarely described as an actual program — more often it's an informal "gains experience on shift," with no clear set of stages and no criterion a SOC manager can use to say: this analyst is ready for the next level. This article describes such a program: what separates L1 from L2, what to teach in what order, and how to check readiness instead of relying on tenure.
How L1 Differs from L2 and Where the Line Falls
An L1 analyst works with a stream of routine alerts: they pick up an alert, check it against known scenarios, close false positives by a clear criterion, and escalate anything that falls outside the routine case. Their strength is speed and procedural discipline: they don't need to invent a solution from scratch for every case — they need to confidently apply an existing playbook and know exactly where that playbook stops working.
An L2 analyst's work starts exactly where the L1 playbook runs out. Their job is to make sense of a non-routine case: correlate signals from multiple sources, reconstruct the chain of events, tell a coincidence apart from a pattern, and make a decision that no existing instruction covers. L2 also writes or refines the very playbooks that L1 relies on — turning a one-off investigation into a repeatable procedure for the team.
The line between the levels isn't about tenure — it's about two specific skills. The first is the ability to follow a playbook when one exists, without deviating from it without reason. The second, harder skill, is recognizing that the current case isn't covered by any playbook and shifting into investigation mode instead of either forcing the case into a template or closing it without analysis. An analyst who confuses these two modes either escalates too early, burning L2's time on routine cases, or too late, missing a non-routine incident disguised as routine.
What a Candidate Needs to Know Before Their First Shift
Before putting a new hire on a real L1 shift, make sure a baseline set of skills is already covered — otherwise the first shift turns into trial-and-error learning on a live stream of incidents, which is costly both for the organization and for the analyst's own confidence.
The minimum viable set for starting a shift:
- Understanding what EDR is and what telemetry it collects — endpoints are most often the first source of signal.
- Basic orientation in the product console: where to find the list of detections, how to read an alert card, where to look at related events.
- Understanding the difference between a false positive and a real incident based on specific indicators, not intuition.
- Knowledge of the escalation procedure: who to hand a case off to, in what format, and with what data, when it exceeds the analyst's own authority.
- Basic communication discipline: logging actions and conclusions as the investigation unfolds, rather than reconstructing them from memory at the end of the shift.
None of these items requires the candidate to already be an expert — they require the candidate not to spend their first real shift figuring out where a given button lives in the interface. It's better to build this starting level in advance, on an isolated lab environment where a mistake costs nothing, rather than during a real shift.
The L1-to-L2 Growth Program: Stages, Not Timelines
It's more useful to describe growth through stages and through what the analyst can already do independently than through calendar timelines: the pace of growth depends heavily on the candidate's starting level, the intensity of the incident stream in a given SOC, and how much attention a mentor devotes to them. What follows is a sequence of stages, not a table of weeks.
Stage 1. Confident work with an existing playbook. The analyst closes routine detections independently, without constant questions to a mentor, and correctly identifies the moment a case needs to be escalated.
Stage 2. Joining L2 in non-routine case reviews. The analyst joins the investigation of a complex incident as a second pair of hands: observing L2's reasoning, asking questions, proposing hypotheses — but the final call isn't theirs yet.
Stage 3. Independently handling a non-routine case under review. The analyst leads a non-routine incident on their own for the first time, while L2 or the SOC manager checks the decision after the fact — before it's officially closed.
Stage 4. Independent work without mandatory review, plus proactive contribution. The analyst not only investigates whatever lands on their desk but also proposes improvements to detection rules, takes part in proactive threat hunting, and can onboard a new L1.
Moving between stages should be backed by a specific, observable result — for example, a resolved case that held up under review — not by a call of "they're probably ready by now." A growth program where stage transitions aren't backed by evidence turns, in practice, into plain tenure with fancier stage names.
What to Teach and in What Order
The order in which topics are taught matters: trying to teach complex incident investigation to someone who isn't yet confident with basic telemetry produces worse results than a sequential build-up of layers, each resting on the one before it.
Telemetry and Console Work
The first layer is technical fluency with the tool itself: what the EDR console shows, how to read an endpoint's event timeline, how to filter and search by attributes. Without this layer, everything that follows turns into a conversation about theory detached from what the analyst will actually see on screen during a shift.
Handling Routine Detections
The second layer is applying existing playbooks to the alert stream: telling templated false positives apart from cases that need attention, closing clear-cut cases quickly without losing speed on the queue. This is L1's core working skill, and it's where their day-to-day effectiveness is most often measured.
Network and Email as Sources
The third layer extends the view beyond the endpoint: network anomalies and email as one of the primary vectors of initial access. The analyst learns to correlate an endpoint signal with network context or with signs of phishing — the articles "What Is Mail Security" and "Protection Against Phishing and BEC" provide a baseline understanding of this class of threats, useful to keep in mind when reviewing incidents where email is the likely entry point.
Escalation and Communication
The fourth layer isn't technical but procedural: how to phrase an escalation so L2 doesn't waste time reconstructing context, how to communicate with the owners of affected systems, how to record incident status in a way adjacent teams can understand. This skill is often undervalued, even though it determines how fast the team closes an incident as a whole, not just its technical part.
Investigating the Incident as a Whole
The fifth layer is the shift from reacting to a single alert to investigating an incident as a coherent story: reconstructing the attacker's sequence of actions, identifying the initial point of entry, and determining the scope of impact. The article "Incident Investigation in EDR" and the broader treatment in "Incident Investigation: The DFIR Approach" provide the methodological foundation for this layer — it's important that the analyst goes through this material not as theory alone, but with follow-up practice on specific cases.
Proactive Threat Hunting
The sixth and most advanced layer is the shift from waiting for alerts to actively hunting for signs of compromise that haven't triggered an alert yet. The article "Where to Start with Proactive Threat Hunting" covers how to build the first cycle of this work, and it fits logically right at this stage of growth, once the underlying layers are already in place.
How to Measure Readiness, Not Course Completion
Formally completing a course is a necessary but not sufficient condition for readiness. Runbooks and slides show that the analyst has reviewed the material, but they don't show whether the analyst can apply it under the real load of a shift. Readiness checks should rely on observable behavior, not on attendance at training.
A shift walkthrough on a lab stand. The most reliable way to check readiness is to have the analyst work through a realistic scenario on an isolated lab environment and evaluate not just the correctness of the final conclusion, but the sequence of actions: where they started, what data they checked first, where they caught a meaningful signal, and where they missed one.
Post-hoc decision reviews. Regularly reviewing several of the analyst's closed cases together with a mentor — not to punish mistakes, but to walk through the reasoning out loud and see where it was a lucky coincidence versus a solid method.
Consistency. A ready L2 analyst arrives at comparable decisions on similar cases regardless of mood or how busy the shift is. If decisions swing wildly from incident to incident without objective reasons, that's a sign the method hasn't taken hold yet, even if individual decisions happened to be correct.
Mentorship and Shift Rotation
Growth from L1 to L2 almost never happens alone — it's accelerated by mentorship and by deliberately designed shift rotation.
Shared shifts with a more experienced analyst. In the early stages, it helps for L1 to work alongside L2 or a lead analyst in a real, not formal, capacity — with the ability to ask a question in the moment, not only after the fact during a review.
Rotation across source types. If the SOC's structure allows it, it helps to rotate a junior analyst across different telemetry sources — endpoints, network, email — so their outlook forms broadly, not around a single product.
Feedback after every significant shift, not only at the end of a quarter. Timely feedback on a specific case is absorbed better than a generic comment a month later, once the case details have already been forgotten.
Gradual handover of responsibility, rather than a sharp jump from "works under supervision" to "handles complex cases alone." A gradual approach reduces the risk that the analyst encounters a non-routine incident before they're ready to make an independent decision.
Common Mistakes When Growing Analysts
A newcomer goes straight onto live shifts with no onboarding stage. Skimping on preparation means the first real incidents get handled slowly and with mistakes, and the new hire's confidence drops faster than their competence grows.
Training happens with no feedback on the cases worked. The analyst completes the course, but no one checks how they apply that knowledge in practice — so gaps go unnoticed until they surface on a serious incident.
L1 is treated as a dead-end role instead of the first stage of growth. If the organization has no visible path from L1 to L2, the best candidates either lose motivation or leave for somewhere that has one — and the SOC keeps hiring newcomers instead of growing them.
The analyst lacks access to the data needed for a full investigation. Limited access to telemetry or to the context of adjacent systems forces the analyst to guess instead of testing a hypothesis — and that slows growth even for a motivated specialist.
Growth is measured by tenure, not by results. "They've been on shift for a year now — probably ready for L2" is an unreliable criterion: tenure without feedback and without working through non-routine cases doesn't guarantee the analyst has actually crossed the line between levels described above.
How to Retain an Analyst Who Has Grown into L2
Growing an L2 is only half the task; the other half is not losing them right after the investment in training has paid off. A specialist who grew up inside the team is especially valuable precisely because they know your infrastructure and your processes — and the job market understands that just as well as you do.
A visible path forward past L2 — into proactive threat hunting, mentoring new L1s, contributing to better detection rules — retains a specialist better than an unchanging role with growing tenure. If the only prospect for a grown L2 is staying in the same spot with no new challenges, motivation to develop within the team drops, and the specialist starts looking for growth elsewhere.
The economic logic here matches staff training economics in general: a trained specialist who leaves due to lack of prospects takes the training investment with them and leaves the organization back at square one. For more on how to calculate the cost of training and retention in terms leadership can act on, see "Why Training Staff Is Cheaper Than Cleaning Up After the Fact".
Lab Practice That Closes the Gap Between the Course and the Shift
None of the six learning layers described above sticks from reviewing materials alone, without hands-on practice in the real interface. The course "Deploying and Administering BI.ZONE EDR" on isolated BI.ZONE Cybersecurity Labs lab stands gives exactly that kind of practice: telemetry analysis, console work, and investigation scenarios that can be repeated as many times as needed, without risking production infrastructure.
For a quick start for a junior L1 analyst, the more hands-on course "Working with BI.ZONE EDR" is a good fit — it covers the first two layers from the program above and gives a solid base before the first real shift. Further development follows the L1-to-L2 growth program described in this article, with a gradual shift from ready-made playbooks to independent investigation and proactive threat hunting.