Onboarding a SOC analyst: the first 90 days
Onboarding a SOC analyst: access, buddy system, procedures, a gradual path to autonomy and on-call. A practical 90-day plan for security teams.
A well-hired SOC analyst can spend weeks staring at a screen without knowing what to do with the alerts in front of them. That is not a skills problem: it is an onboarding problem. This guide sets out a practical 90-day plan so a new analyst becomes autonomous, useful to the team and confident in their choice.
Why SOC onboarding is a special case
In most jobs, a poor onboarding costs time. In a SOC, it also creates risk. An analyst who does not yet know the scope, the critical assets or the escalation procedures may close a real alert as benign, or escalate everything they see and swamp the higher tiers.
Three things make it harder than elsewhere:
- Context matters as much as tooling. An experienced analyst knows the SIEM and the EDR. They do not yet know your service accounts, your legitimate scheduled tasks or the business applications that generate noise.
- The work is often shift-based. Rotations, nights and weekends complicate support: the buddy is not always there when the new hire needs them.
- Access is sensitive. Granting full rights on day one raises security questions; granting nothing blocks learning.
These constraints are best prepared before the start date, ideally during hiring itself. If you are still defining the role, start with our guide to hiring a SOC analyst.
Before day one: prepare the ground
Good onboarding starts during the notice period. Our article on cybersecurity time to hire pointed out that staying in touch during that period prevents many last-minute withdrawals. It is also the time to prepare the arrival in practical terms.
Pre-arrival checklist
- Workstation configured, accounts created, MFA ready to enrol.
- Read access to the SIEM, EDR and ticketing tool requested, with a defined scope.
- Documentation gathered: map of the monitored scope, list of critical assets, escalation procedures, playbooks.
- Buddy appointed, with time genuinely freed up in their schedule.
- Schedule for the first weeks set, on day shifts.
- 30, 60 and 90-day objectives written and shared with the new hire on arrival.
The last item is often forgotten. Yet an analyst who knows what is expected at each stage organises themselves and asks better questions.
Days 1 to 30: understand before acting
The first month is about building context. The goal is not for the new hire to handle alerts alone, but to understand what the team protects and how it works.
Discover the environment
Set up short meetings with the teams the analyst will call on during an incident: infrastructure, network, service desk, application teams, and the CISO or equivalent. Knowing who to call, and how that person prefers to be contacted, saves precious time on the day of a real incident.
Walk them through the critical assets too. An alert on a domain controller or the payroll server is not handled like an alert on a test machine.
Shadow a buddy
During the first weeks, the new hire works alongside a seasoned analyst. They watch triage, then practise it with review. The buddy explains their reasoning out loud: why this alert is a known false positive, why that one deserves further searching.
Read the history
Closed tickets from recent months are a goldmine. Ask the new hire to read a selection, especially confirmed incidents and recurring false positives. They learn the team's vocabulary, the expected level of detail and the traps specific to your environment.
End-of-month goal: the new hire can explain the monitored scope, find a procedure, name the key contacts and triage the most common alerts under supervision.
Days 31 to 60: practise with a safety net
In the second month, the new hire takes on a real alert queue, first on a limited scope, then a wider one. Review is systematic at first, then occasional.
| Practice | What it brings |
|---|---|
| Autonomous triage on a narrow scope | Growing confidence, low-impact mistakes |
| Ticket review by the buddy | Alignment with the expected quality bar |
| Tabletop exercise on an incident scenario | Familiarity with procedures before they are needed |
| Observing a real incident | Understanding of coordination and communication |
| Proposing an improvement (rule, procedure, documentation) | A fresh eye valued, a first visible impact |
That last point deserves encouragement. A newcomer sees what the team no longer notices: an outdated procedure, a noisy rule, an incomplete playbook. Asking them to document it gives meaning to their work and improves the SOC.
This is also the right time to introduce on-call, if the role includes it. Start with a shadow slot alongside a senior analyst, then a solo slot with guaranteed backup. The conditions announced during hiring must be honoured to the letter: trust is lost quickly on this topic, as we explained in our article on remote work and on-call duty.
End-of-month goal: the new hire triages their scope autonomously, writes usable tickets without systematic review and knows when to escalate.
Days 61 to 90: towards autonomy
The third month consolidates autonomy and prepares what comes next. The new hire covers the full scope expected at their level, joins the rotations fully and starts contributing beyond triage.
Expectations depend on the level hired:
- Tier 1 analyst: autonomous handling of common alerts, rigorous use of procedures, well-argued escalation.
- Tier 2 analyst: full investigations of escalated incidents, containment proposals, informal mentoring of Tier 1.
- Tier 3 analyst: threat hunting, tuning or writing detection rules, improving playbooks.
These levels should match the job description. If you used our SOC analyst job description template, use it as your yardstick: it already sets out the expected duties.
End-of-month goal: the new hire is part of the rotations like any other team member and owns at least one concrete improvement.
The end-of-probation review
After three months, hold a formal two-way conversation. The company shares what it has observed; the new hire says what they discovered, what matches what they were told and what does not.
A few useful questions:
- What slowed you down most during these three months?
- Which part of the documentation was missing or misleading?
- Do the rotations and on-call match what was announced?
- What would you like to grow in over the next six months?
The answers serve twice: they improve onboarding for the next hire, and they lay the foundation for a development plan. It is one of the first levers to retain your cybersecurity team.
The most common mistakes
- Leaving the new hire waiting for access. A week without tools signals disorganisation, which lands particularly badly in a security team.
- Putting them alone on night shifts too early. Operational risk adds to stress and isolation.
- Confusing documentation with onboarding. A wiki does not replace an available buddy.
- Setting no objectives. Without milestones, the new hire cannot tell whether they are progressing, and neither can the manager.
- Not protecting the buddy's time. If they support the new hire on top of their usual load, support is the first thing to go.
- Ignoring the new hire's feedback. Their fresh eye is a resource; dismissing it discourages the next ones.
In short
Successful SOC onboarding follows a simple logic: prepare access and documentation before arrival, spend the first month on context, the second on supervised practice, the third on autonomy, then hold an honest review. The plan takes the team's time, but far less than repeating a hire after someone leaves during probation.
Preparing for a SOC analyst's arrival, or still looking for the right profile? At Cyber Recrut, a recruiter and a security practitioner work with you to define the real level of the role and its conditions. The candidates we present have proven their skills on hands-on labs, which also gives your team a clear starting point for their onboarding. See how we work or tell us about your hiring need.