SOC analyst roadmap: from zero to entry level

The shortest honest SOC analyst roadmap is this: learn how networks and operating systems behave normally, learn to read the logs they produce, practise triaging alerts in a home lab, then prove it with one foundation certification and a portfolio of written investigations. Hiring managers for entry-level SOC roles are mostly checking one thing: can this person look at an alert, work out what actually happened, and write it up clearly enough that someone else can act on it?

Everything below is ordered so that each stage makes the next one easier. You can move faster or slower, but resist skipping stage one. People who jump straight to SIEM tools without understanding what a normal Windows logon looks like end up memorising queries they can’t interpret.

What does a SOC analyst actually do all day?

A Security Operations Centre (SOC) watches an organisation’s systems for signs of attack and responds when something looks wrong. At entry level (often called Tier 1 or L1), the day is a queue of alerts from a SIEM (Security Information and Event Management platform), an EDR (Endpoint Detection and Response) console, email security tools and user reports.

For each alert you answer four questions:

1. Is it real? Many alerts are false positives: a backup job that looks like data exfiltration, an admin running PowerShell for a legitimate reason.
2. What is the scope? One machine, one user, or many?
3. How bad is it? Does it match a known attack technique, and how far along is it?
4. What happens next? Close it with a note, escalate to Tier 2, or start containment according to the playbook.

The written ticket matters as much as the technical work. A good L1 note says what fired, what you checked, what you found, and why you closed or escalated it. If you want to compare this with the more policy-driven side of security, our post on GRC analyst vs SOC analyst sets the two roles side by side.

The SOC analyst roadmap at a glance

Stage 1: Foundations (networking, Windows, Linux)

You can’t spot abnormal traffic if you don’t know what normal traffic looks like. Cover these until they feel boring:

• Networking: the TCP/IP model, IP addressing and subnets, TCP vs UDP, common ports (22 SSH, 53 DNS, 80/443 HTTP/HTTPS, 445 SMB, 3389 RDP), DNS resolution, DHCP, NAT, and what a firewall rule actually allows.
• Windows: users and groups, Active Directory basics (domains, domain controllers, Kerberos at a high level), services, scheduled tasks, the registry, and Event Viewer.
• Linux: navigating the shell, file permissions, processes, systemd services, and where logs live (/var/log/auth.log on Debian/Ubuntu, journalctl).

A good test of Linux readiness is whether you can read this and explain it:

$ sudo grep “Failed password” /var/log/auth.log | tail -3
Oct  9 21:14:02 lab-web sshd[2231]: Failed password for invalid user admin from 192.168.56.20 port 51544 ssh2
Oct  9 21:14:04 lab-web sshd[2233]: Failed password for invalid user oracle from 192.168.56.20 port 51552 ssh2
Oct  9 21:14:06 lab-web sshd[2235]: Failed password for root from 192.168.56.20 port 51560 ssh2

Three failures, two seconds apart, cycling through common usernames from one source: that’s the shape of an automated SSH password-guessing attempt (in this case, from an attacker VM in a lab). Being able to say that, and then asking “did any attempt succeed?”, is the SOC mindset in miniature.

If you’re starting from nothing, how to get into cybersecurity with no experience covers the very first steps before this stage.

Stage 2: Logs, event IDs and SIEM searching

This is the heart of the job. Learn which log sources exist and what each can tell you:

Windows event IDs worth memorising

• 4624: successful logon (check the Logon Type: 2 is interactive, 3 is network, 10 is RemoteInteractive/RDP)
• 4625: failed logon
• 4688: a new process was created (needs process-creation auditing enabled)
• 4720: a user account was created
• 4728 / 4732: a member was added to a security-enabled global / local group
• 7045: a new service was installed (System log)
• 1102: the audit log was cleared, which deserves attention almost every time

With Sysmon installed, Event ID 1 (process creation with full command line and parent process) and Event ID 3 (network connection) are the two you’ll lean on most.

Your first useful SIEM search

Splunk and Elastic are both common, and both have free options you can run at home. Here’s a Splunk search for a password-guessing pattern followed by a success from the same source:

index=wineventlog (EventCode=4625 OR EventCode=4624)
| stats count(eval(EventCode=4625)) AS failures,
        count(eval(EventCode=4624)) AS successes
        BY src_ip, user
| where failures > 10 AND successes > 0

Plausible output in a lab:

src_ip          user        failures  successes
192.168.56.20   j.okafor    37        1

The threshold of 10 is a starting point, not a rule. Part of the job is tuning thresholds so the alert fires on attacks and not on someone who forgot their password after a holiday.

Stage 3: Threats, frameworks and attack chains

Once you can read logs, learn what attackers do so you know what to look for. The MITRE ATT&CK framework is the shared vocabulary: it catalogues adversary tactics (the why, such as Initial Access or Persistence) and techniques (the how, such as Phishing, T1566). SOC tools, detection rules and threat reports all reference ATT&CK IDs, so get comfortable navigating it.

Study a handful of attack chains end to end rather than trying to memorise the whole matrix:

1. Phishing to credential theft: email with a link → fake login page → attacker signs in from a new location. Our walkthrough of phishing email examples and what SOC analysts look for covers this one in detail.
2. Malicious attachment to execution: Office document or archive → script launches → PowerShell downloads a payload.
3. Brute force to lateral movement: guessed password → RDP or SMB to other hosts → new admin account created.
4. Persistence: scheduled task, new service, or a Run registry key that survives a reboot.

For each chain, write down which log source would show each step and which event ID or field you’d check. That table becomes your personal detection cheat sheet.

The UK’s NCSC guidance on logging and monitoring is a useful, vendor-neutral read on why organisations collect these logs in the first place.

Stage 4: Hands-on triage in a home lab

Reading about alerts is not the same as triaging one. Build a small lab: a Windows VM, a Linux VM, an attacker VM, and a free SIEM or a ready-made monitoring distribution such as Security Onion or Wazuh. Our guide to building a cybersecurity home lab walks through free and low-cost setups.

Then generate your own incidents and investigate them as if someone else had caused them:

• Run a password-guessing attack from the attacker VM against the Linux SSH service and find it in the logs.
• Create a new local admin account on the Windows VM and find events 4720 and 4732.
• Run an encoded PowerShell command and find it in Sysmon Event ID 1.
• Install a dummy service and find event 7045.

Only attack machines you own or have written permission to test. Your own lab VMs are the right target.

A worked triage, the way you’d write it up

Here’s what a good Tier 1 note looks like for a lab incident:

Alert: Multiple failed logons followed by success, user j.okafor, source 192.168.56.20. Checked: 37 × 4625 then 1 × 4624 (Logon Type 3) within 4 minutes. Source IP is not a known workstation or VPN range. Searched 4688 and Sysmon EID 1 on the target after the successful logon: net user svc_backup /add at 21:19, followed by 4732 adding svc_backup to local Administrators. Assessment: Likely successful password guessing (ATT&CK T1110) followed by account creation for persistence (T1136.001). True positive. Action: Escalated to Tier 2 per playbook PB-03; recommended disabling j.okafor and svc_backup and isolating the host.

Notice that it states facts, links them in time, names the technique, and gives a clear next step. Write ten of these from your lab and you have a portfolio.

Stage 5: Certifications, CV and the entry-level job search

Which certification first?

Certifications don’t replace hands-on skill, but they help a CV get past screening. A sensible order for a SOC path:

• CompTIA Security+ (SY0-701): the broad foundation. Its largest domain, Security Operations, carries 28% of the exam weighting, which lines up well with SOC work. It’s up to 90 questions in 90 minutes, with a passing score of 750 on a 100–900 scale. CompTIA says a new version, Security+ V8, is expected to launch on or around 17 November 2026, and SY0-701 is still available for now, so check CompTIA’s Security+ page for current versions and price.
• CompTIA CySA+: the analyst-focused follow-on, built around detecting, analysing and responding to threats. CompTIA has released a new version (V4), and the English CS0-003 exam retires on 22 December 2026, so check the current exam code and objectives on CompTIA’s CySA+ page. Many people take it after some time in the role rather than before.

Some learners take Network+ (N10-009) first if networking is a weak spot. Remember that a course certificate shows you finished a course; a certification is an exam-based credential from a certifying body like CompTIA. Employers check them differently.

Writing a CV with no SOC experience

Lead with evidence, not adjectives. Instead of “passionate about cybersecurity”, write "Built a home SOC lab (Splunk, Sysmon, Windows Server AD) and documented 10 simulated investigations mapped to MITRE ATT&CK", with a link to the write-ups. Transferable experience counts too: IT support, help desk, network admin, and even customer service roles that involved working a ticket queue under time pressure.

Getting a SOC internship or first role

Entry-level SOC roles go by several names: SOC Analyst I, Security Analyst (Tier 1), Cyber Defence Analyst, Security Monitoring Analyst. Search for all of them. Managed security service providers (MSSPs) often run 24/7 SOCs and take on junior staff, and internships with security consultancies or large organisations' internal SOCs are another way in. Shift work is common, so be honest with yourself about nights and weekends.

In interviews, expect a scenario: “You see a 4625 spike on a domain controller. What do you do?” Talk through it the same way you’d write a ticket: what you’d check, in what order, and when you’d escalate.