5 Things We Learned About Optimizing SOC Onboarding

Earlier this week, TryHackMe content engineers Niels Deryckere and Gabriel Novaes sat down with Head of Content Engineering, Marta Strzelec to talk about one of the most overlooked problems in security operations: effective onboarding. We don't mean HR onboarding, we mean the kind that determines whether your analyst is actually making good decisions three months from now, rather than just closing tickets quickly.

Here's what came out of that conversation.

1. "Ready" is explaining decisions over closing tickets

There's a version of onboarding success that looks great on paper: an analyst  moves through the queue, keeps SLAs green, clears alerts. But that doesn't mean managers have insights into whether they're making good calls.

"Closing tickets, you can easily do that following playbooks. What takes more effort is actually being able to explain a decision." — Niels

The real signal of readiness is when an analyst can walk you through why they escalated, closed, or flagged something. That bar applies at every level.

"Being comfortable with investigating low and medium level alerts and explaining the decisions you're taking — that's a great signal that an analyst is ready to work independently." — Gabriel

If they can't explain it, you're potentially postponing discovery of a major gap, and won't know something went wrong until the next incident.

2. Documentation (or lack of it) can impact onboarding, but it's not a deal-breaker

If your processes live in people's heads, you're not ready effectively onboard a new joiner, whatever their seniority. But that doesn't mean you should wait until everything is documented before hiring.

At minimum: have a plan, know what you want the analyst to be able to do at 30 days, and don't rely entirely on a senior analyst's availability to carry the onboarding in the meantime.

Gabriel flagged another common trap worth naming: documentation that exists but is outdated. A plan that's wrong is sometimes worse than no plan at all, and takes longer to discover.

"The issue with onboarding usually isn't that it's really slow. It's that most organizations don't actually have an onboarding program — they have a 'sit next to someone and figure it out' program. That's not a speed issue. It's a structure issue." — Marta

3. You're hiring a mind, not hands to follow a playbook

This came up more than once, and is worth repeating: the analysts adding real value to a SOC are the ones who can correlate information, catch what the playbook doesn't cover, and make judgment calls under pressure.

"You're literally hiring a mind to think, not fingers to just type." — Gabriel

"If we're able to train AI using playbooks, why would we need analysts? We do need them, because it's their ability to correlate different pieces of information, to decide whether to escalate an alert or not, that matters." — Niels

Onboarding has to develop thinking, not just task completion. Exposing analysts to scenarios where they have to reason through an alert and justify their actionsbuilds that skill set, and increases value in within the team.

4. Practice beats training, simulated pressure beats static exercises

Training and practice are not the same. Reading playbooks is training, but actually applying that training by working through an alert under SLA pressure is practice. Both matter, but the latter validates readiness to get involved in real SOC work.

"Have they felt that SLA urgency? Have they really practiced those obtained skills?" — Niels

"I don't like static exercises for SOCs because they don't reflect real-world practice. Having a tool that exposes you to real-world logs, real attack chains, false positives — that's the right kind of exposure." — Gabriel

Gabriel made a strong case for getting analysts into realistic, simulated environments before ever touching a real alert, precisely because the cost of a mistake on a real alert is high, and it's often invisible until much later.

"There's a real balance to be struck between how realistic the training is versus how good it is at actually teaching the skill. Realistic logs don't always transfer the skill you want to build." — Marta

The speakers agreed that it's best to let new joiners fail safely first, in a controlled environment that mirrors the pressure of the real thing.

5. Optimizing soley for speed during onboarding is an expensive mistake

The instinct to measure onboarding success by how fast an analyst is closing alerts is understandable when those are the metrics the SOC runs on. But applying them too early creates exactly the wrong culture.

"If we optimize for speed for closing alerts, we'll already create that culture of not wanting to think further, and wanting to just close things." — Niels

"Prioritizing speed at the people level is wrong, speed can be boosted with automation and AI. Quality first, always." — Gabriel

Speed can be improved with automation, but judgment takes time to develop. If you measure speed during onboarding, you'll get analysts who are fast and unreliable and you probably won't find out for 30 to 60 days, or until something slips through, with extensive course correction required.

"If you optimize for speed first, you'll spend months correcting. Measure how your analysts think, not just how fast they move." — Marta

SOC onboarding isn't an HR task, it's an operational decision that affects your team's capability for months after someone joins. A clear plan, a roadmap with milestones, and a focus on how analysts think is what separates teams that onboard well from teams that discover problems later.

Want to know more about how TryHackMe can support effective, impactful onboarding? Read our case study with Huntress here.