Blue Team · 8 min read · Log Academy training team
Your first 90 days in a SOC: what's expected of an analyst
The first 90 days in a SOC usually fall into three phases: alert triage and shift discipline in month one, detection rule tuning in month two, and independent incident documentation in month three. Nobody expects a junior SOC analyst to know everything — only to explain their decisions, spot a weak rule, and write a clear incident report.
- Days 1–30: prioritize the alert queue, follow the runbook, and justify every decision in writing.
- Days 31–60: count recurring false positives, trace their source, and propose a rule fix.
- Days 61–90: document an incident from start to finish — timeline, affected hosts, actions taken, open items.
- Success isn't measured by how many tools you know but by how traceable your decisions are: a colleague should be able to pick up your notes and continue the investigation.
- Practicing these three habits in a lab before day one takes much of the pressure off the first month.
Why are the first 90 days in a SOC split into three phases?
When a new analyst joins a security operations center (SOC), they have to learn three things at once: the company's infrastructure, the team's processes, and how the tools are actually configured. That doesn't fit into a week. So many teams break onboarding into phases: observation and triage first, then working with rules, then independent investigations.
The plan below isn't any one company's internal playbook — it's a summary of logic that's common in Blue Team practice. The timing can stretch or shrink depending on the team. The order rarely changes, though: first you learn to read, then to fix, then to explain.
| Phase | Main focus | Expected outcome | Checkpoint |
|---|---|---|---|
| Days 1–30 | Alert triage, runbooks, shift handover | Close routine alerts on your own and escalate suspicious ones on time | A senior colleague can read your notes and retrace your decision |
| Days 31–60 | False positives and rule tuning | Identify the noisiest rules and propose a well-reasoned change | The proposed exception is narrow, documented, and tested |
| Days 61–90 | Incident documentation and reporting | Investigate a small incident end to end and write the report | The report reads without follow-up questions and next steps are clear |
What is expected of a SOC analyst in the first 30 days?
The core job of month one is triage — the initial assessment: sorting queued alerts by priority, grouping duplicates, and separating out the ones that might be a real incident. At this stage discipline matters more than tool knowledge. A new analyst usually works alongside a senior colleague and learns how they reason through decisions.
- Read the runbooks: know the agreed verification steps for each alert type.
- Learn the log sources: which system sends which log, which fields matter, and how to tell when a source has gone quiet.
- Understand the escalation boundary: what you close yourself and what you hand up immediately.
- Justify every decision in the ticketing system in a sentence or two: what you saw, what you checked, why you closed it.
- Hand over open work at shift change with a short, factual summary.
The biggest risk this month is rushing. Closing alerts quickly looks good, but an unjustified closure tends to become the most expensive time sink later. Asking questions isn't a weakness: in cybersecurity teams, staying quiet and making the wrong call costs far more.
How does rule tuning work in days 31–60?
Month two is usually about tuning detection rules. By now you can see which alerts fire every single day. The goal is to find the source of that noise and change the rule so that a real attack doesn't become invisible. This habit protects the whole team's attention from empty alerts.
- Count: which rule produces the most false positives — keep a weekly list.
- Find the source: is the noise coming from a scheduled scan, an admin script, a service account, or a new application?
- Write a hypothesis: which condition in the rule catches this legitimate activity, and how can it be narrowed?
- Propose the change in Sigma format: a Sigma rule is a platform-agnostic YAML file that can be converted into your SIEM's query language.
- Test it: reproduce both the legitimate activity and the matching MITRE ATT&CK technique in the lab; the rule should stay silent on the first and catch the second.
- Document it: what changed, why, and who approved it.
Narrow exceptions, not broad ones
The most dangerous fix is excluding an entire host, user, or process from a rule. Attackers live in exactly those blind spots. Keep exceptions as narrow as possible — a specific account, a specific command line, a specific time window — and record the reason in the rule's comments.
How do you write an incident report in days 61–90?
In month three, the new analyst documents small incidents on their own. Incident response guidance such as NIST SP 800-61 treats capturing lessons learned as an integral part of the process. In practice, a good report answers these questions:
- What happened: the first alert, its source, and a short summary.
- Timeline: the sequence of events with exact timestamps — from the first sign to containment.
- Scope: which hosts, accounts, and data were affected.
- Actions taken: who did what and when — for example, disabling an account or isolating a host.
- MITRE ATT&CK mapping: which tactics and techniques the observed behavior matches.
- Open items and recommendations: what still needs checking, and which rule or configuration should change.
A well-written report saves the team a lot of time on the next similar incident: the investigation starts from ready context rather than from zero. Writing it also tests the analyst's own reasoning. A conclusion that won't fit into clear prose is often not well enough supported.
Which mistakes should you avoid in your first 90 days?
- Closing an alert without context: "it's always been like this" is not a justification.
- Trying to solve everything alone: that's exactly what the escalation policy is for.
- Writing a broad exception just to make a rule go quiet.
- Leaving notes for later: by the end of the shift the details are gone.
- Missing a silent log source: no alerts doesn't always mean no problem.
None of these mistakes come from a lack of tool knowledge — they come from habits. That's why the most effective approach is to practice before the job, in an environment where a mistake has no real consequences.
How can you practice these three phases before starting the job?
For newcomers to cybersecurity, the most practical preparation is to work through this whole sequence once in a lab. Log Academy's Blue Team program lasts 6 months, takes you from beginner to intermediate level, and is designed for IT support specialists and network and system administrators.
How we do it in our lab
In our lab, students go through these three phases in order. Each student gets their own virtual machine in a vSphere-based lab, and that environment stays open 24/7, including after class. First comes a shift simulation on a ready-made SIEM (ELK or Wazuh): the student prioritizes alerts and justifies each decision in their notes. Next, they analyze a noisy rule, write their own Sigma rule, and verify it with a test scenario based on a MITRE ATT&CK technique. Finally, they carry out a full investigation of a simulated incident and write the final incident report.
Groups are 8–12 people, 70% of classes are hands-on, and every topic closes with a lab task. Formats: in person in Baku, live online, and corporate training. The career module includes CV and LinkedIn reviews, technical interview practice, and vacancy referrals. The first lesson is free.
Frequently asked questions
- Are the first 90 days in a SOC the same everywhere?
- No. Timing depends on team size, tooling, and the shift schedule. But the order is usually the same: triage first, then rule work, then independent documentation.
- Is a new SOC analyst expected to write rules from day one?
- Usually not. In the first month, following the runbook and justifying decisions is what matters. Rule tuning starts in month two, once you've seen the recurring alerts.
- What is Sigma and why learn it?
- Sigma is an open standard for writing detection rules in a platform-agnostic YAML format. A rule written once can be converted into the query languages of different SIEMs, which makes rules easier to share and review.
- What is the most important part of an incident report?
- The timeline and the actions taken. Another analyst should be able to understand from the report alone what happened, what was done, and what is still open.
- How long is the Blue Team program that prepares you for SOC work?
- At Log Academy the Blue Team program lasts 6 months. Shift simulation, writing Sigma rules, and a final incident report are all practiced in the lab. The first lesson is free.