Guides

What Is a SOC? What Does a SOC Analyst Do?

By Ravindra Bagale, Cyber Security trainer · LinkedIn · Published: 29 September 2026 · Last updated: 30 September 2026

A Security Operations Centre (SOC) is the team and process that watch for cyber threats, triage alerts, contain damage and document decisions — often 24×7 in larger orgs. A SOC analyst investigates alerts from SIEM, EDR, email and cloud tools, follows playbooks, escalates when needed and writes clear notes. Tools matter; calm process and ownership matter more.

Telemetry → Queue → Triage → Investigate → Contain / Close → Notes → Improve detection
No notes = tribal knowledge that vanishes on shift change

What do I need before this guide?

• Optional: What is SIEM?.
• Optional: Analyse a phishing email like a SOC analyst.
• Optional: IR first 24 hours.

What is a SOC?

A SOC is not only a dark room with screens. It is:

1. Mission — detect and respond to threats affecting the organisation.
2. People — analysts, detection engineers, IR leads, managers.
3. Process — playbooks, severity definitions, escalation paths, SLAs.
4. Technology — SIEM, EDR, SOAR, threat intel, ticketing.
5. Metrics — mean time to detect / respond, false-positive rate, coverage gaps (honest ones).

Small companies may run a “virtual SOC” with two people and Microsoft 365 + EDR alerts — the role pattern is the same.

What does a SOC analyst do day to day?

Vertical L1 day:

1. Join shift; read handoff notes from the previous analyst.
2. Work the alert queue oldest-critical first.
3. Open an alert; pull related events (same user, host, IP).
4. Check change tickets / admin calendars for expected activity.
5. Mark false positive with a real reason — or open an incident ticket.
6. Run approved containment steps; page L2 when unsure.
7. Write five-line notes: time (IST), asset, hypothesis, action, next check.

SOC tiers (simple)

1. L1 — triage, known playbooks, quality notes.
2. L2 — deeper investigation, malware / identity pivots, tuning suggestions.
3. L3 / hunt / IR — major incidents, detection engineering, forensics liaison.

Fresher openings are often L1 — employers hire calm documentation as much as tool logos.

Real incident lesson: Target (2013) — alerts without effective response

Public reporting on the Target 2013 breach described security tools generating alerts that did not translate into effective containment in time. The lasting SOC lesson is organisational, not tool-brand:

1. Signals without owners fail.
2. Escalation paths must be practised, not only written.
3. After-hours coverage and clear severity matter.
4. Care-take — every critical alert class needs a named playbook and a human who can act.
5. Care-take — tune noisy rules so analysts trust the queue.

Red Team vs Blue Team (SOC view)

Red Team — what attackers try (high level)

• Blend into normal admin activity.
• Move slowly to avoid threshold alerts.
• Disable or evade logging after a foothold.

Blue Team — how SOC responds

• Baseline “normal” for VIP users and crown-jewel hosts.
• Correlate identity + endpoint + email + cloud.
• Preserve evidence while containing.
• Feed lessons into better detections (Sigma / SIEM rules — see related guides).

How do I think like a beginner SOC analyst?

Step 1 — Learn the queue language

1. Severity, priority, asset criticality, confidence.
2. True positive vs false positive vs benign true positive.
3. IOC (indicator) vs IOA (behaviour) — high-level awareness.
4. SLA: how fast criticals must be touched.

Step 2 — Build a repeatable note template

1. Alert name and time (IST + UTC if the ticket asks).
2. User / host / source IP.
3. What you checked (three pivots minimum).
4. Decision and why.
5. Actions taken and who you notified.

Step 3 — Practise on safe material

1. Phishing sample triage (phishing SOC guide).
2. Lab SIEM alerts you generate yourself (Wazuh-style labs in the SIEM guide).
3. Never “practise” by attacking random internet hosts.

Step 4 — Know when to escalate

1. Domain admin / global admin identity risk.
2. Ransomware notes or mass encryption signals.
3. Customer data exfiltration themes.
4. Uncertainty after playbook steps — escalate early, not after hoping.

Step 5 — Soft skills companies actually hire

1. Clear writing under time pressure.
2. Asking for help without ego.
3. Ethics: no peeking at data outside ticket need-to-know.
4. Shift handoffs that spare the next analyst from rework.

Quick vocabulary

1. Playbook — step-by-step response for a known alert type.
2. False positive — alert that fired but was not malicious.
3. Containment — limit blast radius without destroying evidence.
4. Handoff — shift notes so the next analyst continues cleanly.
5. Detection debt — known gaps or noisy rules waiting for engineering time.

Sample L1 note (copy and adapt)

Time (IST): 2026-09-29 21:10
Alert: Impossible travel / rare country IdP login
User: a.shaikh@learnfast.example
Checks: MFA success? device new? VPN ticket? mailbox rules?
Decision: Escalate L2 — MFA success from new ASN + new inbox rule
Actions: Disabled session; ticket INC-1042; pages on-call
Next: L2 identity deep dive by 22:00 IST

Care-take — SOC hygiene

1. Never close criticals with “looks fine” and zero notes.
2. Do not delete evidence to “clean the disk” mid-incident.
3. Follow privacy rules — analysts see sensitive data.
4. Keep playbooks versioned; update after every major miss.
5. Sleep and shift limits — exhausted analysts miss slow attacks.
6. Detection debt backlog visible to management.

How do I fix common SOC beginner mistakes?

Ghabru naka 😅 — these are the usual ones: