Why the first weeks matter
A new SOC analyst usually arrives knowing the theory: attack techniques, log sources, how a SIEM works. What they do not know is your company: which servers matter, what normal looks like on your network, which alerts are always noise and why, and who to call. The first weeks should teach that in a deliberate order, rather than leaving a new person to pick it up from a live queue. The plan below works for a team of any size.
Two things make the biggest difference: reading real past investigations, and taking on responsibility in clear stages with a check at each one. Everything else supports those two.
Getting this right pays back for years. The habits a new analyst forms in the first month, how carefully they read a process chain, whether they write down what they ruled out, whether they ask before closing something they do not understand, tend to stay. So do the bad ones. A rushed start produces an analyst who is fast and shallow, and that is hard to undo later.
Week one: access, context and shadowing
The first week is for access and orientation, not for closing alerts. A new person who spends it fighting account requests learns mostly that the team is disorganised.
Shadowing works best when the experienced analyst talks aloud: why they opened this alert first, why that search, why they closed it. That narration is most of what the new person is there to learn, and it is the part that never appears in a manual.
Ask the new analyst to keep a notebook of questions through the week and go through it with their buddy each afternoon. Questions that come up again and again are a sign that something should be written down for the next person who joins.
- Day one: accounts and access to the SIEM, the ticketing system and the chat channels, tested, with read-only rights where possible.
- A short tour of the business: what the company does, its main systems, its busiest times of year.
- The crown-jewel list and the escalation paths, read with a lead who explains why each entry is there.
- Shadowing: sit with an experienced analyst for at least two shifts, including part of a night if the team runs nights. Watch and ask; do not drive.
- One named buddy who is not the line manager, for the questions a new person feels silly asking.
Reading real investigations
The fastest way to learn how a team thinks is to read its past work. Pick twenty or thirty closed investigations from the last few months: a mix of real attacks, suspicious findings, harmless alerts and authorised activity. Ask the new analyst to read each one, then explain to their buddy what was checked, why, and whether they would have reached the same conclusion.
This only works if the investigations are written down properly. A case closed with “FP” teaches nothing. A case that records the questions asked, the evidence found, the decision and the reason teaches a great deal: what normal looks like for this company, which checks settle which alert types, and where the team draws its lines.
Include the corrections. A case where the first verdict was wrong and a later review changed it is worth several where everything went smoothly, because it shows exactly where the easy answer misleads.
Learning the business’s systems
Security knowledge transfers between employers. Knowledge of the business does not, and it is what separates a good triage call from a guess. Make these explicit rather than hoping they are absorbed:
A good exercise: give the new analyst ten machine names and ask them to find out what each does and who owns it, using your asset records and by asking people. The gaps they hit are gaps in your records too, so the exercise improves the documentation as well as the analyst.
- The backup jobs, deployment tools and admin scripts that cause known alerts, and when they run.
- The service accounts that log on to many machines, and why.
- Month-end, quarter-end and other busy periods when behaviour changes.
- Which teams own which systems, and how to reach them.
- Approved exceptions, where they are recorded and who approved them.
Graded responsibility
Move the new analyst through clear stages, and say out loud when they move. Clear stages help the new person as much as the team: they know what they are allowed to do, what they are being judged on and what comes next, which removes a lot of quiet worry. Illustrative stages for a typical triage role:
Each stage has an exit check: a review of their recent work, not a date in the calendar. Some people move in a fortnight, some take longer, and both are fine. What matters is that nobody is put on a night shift alone before they can handle a real high-severity alert.
Feedback at each stage should be specific. “Good work” teaches nothing. “You closed this as harmless without checking the parent process; here is why that matters for this alert type” teaches a lot, and it is the kind of feedback people remember.
- Stage one: work low-severity alerts, with a buddy reviewing each closure before it is final.
- Stage two: close low and medium alerts alone, with a sample reviewed each week.
- Stage three: handle high-severity alerts, escalating through the normal path, with the lead available.
- Stage four: take a shift without a buddy, including nights if the team runs them.
- Stage five: hunting, rule tuning and runbook writing.
Common onboarding mistakes
Most of these come from the same root: the team is busy and onboarding feels like a cost. It is cheaper than a new analyst making a wrong call alone, or leaving after three months because nobody had time for them.
A simple safeguard is to write the onboarding plan down once, with the stages, the reading list of past investigations and the names of the buddy and the lead, and reuse it for each new person. Ask each person who goes through it to improve one part of it before they finish. After a few hires the plan is better than anything one lead could have written alone.
- Putting a new person straight onto the live queue to “learn by doing”. They learn, but they learn the shortcuts first.
- Training on tools but not on the business.
- No written runbooks, so everything depends on who they happen to shadow.
- Night shifts too early, with no lead who answers the phone.
- No feedback on closed alerts, so the same mistakes repeat for months.
Where armor360 fits
armor360 writes down each investigation as it works: the questions it asked, the records it collected and cited, the verdict with its confidence, and what a person decided when reviewing it. The investigation map shows the path from alert to verdict. That record is the kind of material a new analyst can read to learn how alerts in your company are worked.
Because each record shows the questions as well as the answer, a new analyst can compare their own reasoning with the agent’s on the same alert and ask a lead about any step where the two differ. Corrections people make are remembered for later investigations about the same company. People review the verdicts and decide what to do; armor360 takes no response actions.
