Job adverts describe SOC analysts as "cyber defenders on the front line". The reality is quieter, more procedural, and — if you are the right kind of person — genuinely satisfying. Here is what a shift actually looks like, without the recruitment-brochure gloss.
08:00 — handover and the queue
SOCs run around the clock, so your day starts with someone else's night. The handover briefing covers what the previous shift left open: an investigation still in progress, a noisy rule that has been firing all night, a change window that explains why the server subnet lit up at 02:00.
Then you open the queue. A typical morning inherits somewhere between ten and forty alerts, sorted by severity. Before touching anything, a good analyst skims the whole list — because the medium-severity alert on the domain controller may matter more than the critical on an isolated test box, and priority is a judgment call, not just a sort order.
The morning: triage, mostly
The bulk of any shift is working the queue, alert by alert. In a normal week you will see the same families over and over:
- Phishing reports — the most common by volume. A user forwarded a suspicious email; you check the headers, the link, whether anyone clicked.
- Failed logon storms — brute force attempts against anything internet-facing, plus password sprays across cloud accounts. Most are blocked noise; the correlation you never skip is a success following the failures.
- Endpoint detections — the antivirus quarantined something. The real question is always whether it executed before the quarantine.
- Traffic anomalies — beaconing patterns, unusual data volumes, connections to newly registered domains.
- False positives — the vulnerability scanner, the backup job, the admin doing admin things. A large fraction of the queue, every single day.
Most alerts take two to ten minutes. A few take an hour. The discipline is knowing which is which before you have spent the hour.
The part nobody talks about: tickets
Every alert you touch produces documentation, and the documentation is not optional. Each decision gets a note: what the alert claimed, what evidence you checked, what you concluded, what you did. It feels bureaucratic until the first time a closed alert becomes relevant three weeks later and your note is the only record of why it was closed.
Honest estimate: a third of your shift is writing. Analysts who write clearly get trusted with more; analysts whose tickets say "checked, looks fine" stay at L1 longer than they should.
When something is real: escalation
A few times a week, an alert survives your attempts to explain it away. This is the moment the job exists for. As an L1, you do not run the incident — you package it for L2: a timeline of what happened, the evidence with sources, what you checked and ruled out, what you already contained, and a concrete recommendation.
The quality of that handover decides how the next hour goes. "Confirmed RDP brute force with a successful service-account logon from the attacking IP — recommend immediate isolation and account disable, evidence attached" lets L2 act in minutes. A vague escalation makes them redo your work while the attacker keeps moving.
The afternoon: the queue, again — plus the slow burn
Afternoons look like mornings, with the addition of the slower work: following up monitored alerts from earlier in the week, suggesting tuning for the rule that false-positived forty times ("the backup server trips the volume rule every night — can we baseline it?"), and, in good SOCs, a little structured learning time.
Then, at shift end, you write the handover you received that morning — open items, current state, next steps — for whoever inherits your queue.
What separates good from great
Everyone in the SOC can close obvious false positives. The analysts who stand out share habits, not secrets:
- They read evidence before forming a verdict, so the alert title never does their thinking.
- They know normal for their environment — the scanner schedules, the backup windows, the admin habits — because anomaly detection is impossible without a baseline.
- They document like it will be read in an audit, because occasionally it is.
- They treat every false positive as tuning input, so their queue gets quieter over time instead of louder.
- They stay calm at 02:00 when the ransomware-precursor alert fires, because they have rehearsed the decision before it was real.
That last point is the honest pitch for deliberate practice. You do not want your first C2 beacon or your first shadow-copy-deletion alert to be a live one. SOCentre exists so the rehearsal happens before the job — a realistic queue, real log evidence, and scoring on the same metrics (accuracy, false positive rate, MTTR) that a real SOC will measure you on. The free tier is a reasonable way to find out whether you would enjoy the work at all — which, before committing to a career, is worth knowing.