What Is a SOC? Roles, Tiers and Daily Workflow

What is a SOC? A Security Operations Center is the team, the processes and the tools that watch an organization’s systems for signs of attack, decide which signals matter, and respond before a small problem becomes a breach. If you have spent your time on the offensive side, it is the other half of every attack path you have walked: the people who may or may not notice what you just did.

This is Part 1 of 30 in the Blue Team Learning Path on The Cyber Track. It stays practical. By the end you will know the roles inside a SOC, how an alert moves through the daily workflow, and how to triage one with a few lines of shell. If you are still choosing a direction, read the cybersecurity learning path first and then come back here.

Key takeaways

• A SOC is people, process and technology working together to detect and respond to attacks. It is a function, not a room full of monitors.
• A SOC watches for malicious activity, while a NOC keeps systems available.
• Every alert moves through the same stages: detect, triage, investigate, contain or escalate, document, tune.
• Good triage uses asset context and evidence, not only the alert title.
• Clear tickets and tuning noisy alerts matter as much as technical skill.

What Is a SOC? A Plain-English Definition

A SOC is a function, not a place. Some organizations run a physical operations floor with wall-sized dashboards. Many run a small team that works remotely and shares a ticket queue. What matters is that three things exist together:

• People: analysts, engineers and managers who own monitoring and response.
• Process: written playbooks that say what to do when a specific alert fires.
• Technology: the tools that collect logs, raise alerts and let analysts investigate. Part 2 of this path covers them in detail.

A SOC is often confused with a NOC. A Network Operations Center cares about availability: is the link up, is the service responding. A SOC cares about safety: is the service that is up being abused. The two teams share data and sometimes staff, but they ask different questions.

A SOC does not stop every attack. Its job is to detect and respond fast enough that an intruder has less time to reach what they came for. That is why defenders talk about how quickly they detect and respond, not only about blocking.

SOC Roles and Tiers

Titles vary between organizations, and some SOCs have dropped tiers in favor of specialist roles. The three-tier model is still the easiest way to learn who does what, so treat the table below as a map, not a rule.

Role	Main job	Typical skills
Tier 1: alert triage analyst	Watch the alert queue, confirm or dismiss alerts, escalate real ones	Log reading, SIEM searches, basic networking, clear ticket writing
Tier 2: incident analyst	Investigate escalated cases, scope the incident, recommend containment	Windows and Linux forensics basics, EDR use, timeline building
Tier 3: hunter or detection engineer	Hunt for threats that alerts missed, write and tune detections, analyze malware	Detection languages, scripting, ATT&CK, reverse engineering basics
SOC manager	Staffing, metrics, escalation paths, reporting to leadership	Risk communication, process design

Many teams also have a threat intelligence function and an incident response lead who is called in once something is confirmed. Parts 17, 21 and 24 of this path cover the Tier 3 and incident response work in depth.

The Daily SOC Workflow

Every alert, from a noisy brute-force attempt to a real intrusion, passes through roughly the same stages. Learn the stages and every later Part of this path will have a place to slot into.

1. Detect: a tool such as a SIEM or EDR raises an alert, or a user reports something suspicious.
2. Triage: decide quickly whether the alert is a false positive, benign activity or something worth investigating. Ask what fired, on which asset, for which user, and how important that asset is.
3. Investigate: pull the surrounding evidence, such as authentication logs, process creation events and network connections, and build a timeline.
4. Contain or escalate: if the activity is malicious, isolate the host, disable the account or hand the case to the incident response team, following the playbook.
5. Document: write down what you saw, what you checked and what you decided. A decision nobody can read later has to be made again.
6. Tune: feed the result back. A false positive that fired fifty times should become a detection change, not fifty tickets.

The last step is the one beginners skip. A SOC that never tunes drowns in its own alerts, which is why it appears again in the pitfalls below.

A Worked Example: Triaging One SSH Alert

Here is an illustrative case. The addresses and counts below are made up for teaching and are not output from a real incident. [SCREENSHOT: your lab terminal or SIEM showing the same alert once you reproduce it in a lab you own]

The alert reads: many failed SSH logins on a Linux server, followed by one success from the same address. A Tier 1 analyst’s first question is whether that success belongs to a real user or to an attacker who guessed a password. On Debian and Ubuntu, SSH authentication events are written to /var/log/auth.log (on Red Hat-family systems the file is /var/log/secure), so triage starts there:

grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head

That counts failed attempts per source address. In the illustrative output below, one address stands out:

  412 203.0.113.50
    3 198.51.100.7
    1 192.0.2.44

All three addresses come from the ranges reserved for documentation, so none of them point at a real host. Next, check whether the busy address ever got in:

grep "Accepted" /var/log/auth.log | grep 203.0.113.50

If this returns a line such as Accepted password for deploy from 203.0.113.50, the guessing worked and you are no longer triaging a nuisance. It is an incident: contain the account, preserve the logs and escalate to Tier 2. If it returns nothing, the attacker is still guessing, and the right response is to block or rate-limit the source and tune the alert. Either way, the analyst finishes by writing the ticket:

Alert:    Multiple failed SSH logins, then success
Asset:    web-01 (internet-facing, production)
Evidence: 412 failures from 203.0.113.50, one Accepted line for user deploy
Verdict:  True positive, account compromise suspected
Action:   Account locked, source blocked, escalated to Tier 2

Password guessing like this maps to T1110.001, Password Guessing in the MITRE ATT&CK knowledge base. Naming the technique in the ticket gives the next analyst a shared vocabulary, and Part 6 on how to use MITRE ATT&CK shows how to use the matrix properly. Part 5 goes much deeper into Linux log analysis.

The Tools Behind the Workflow

Each stage leans on a different tool. Alerts come from a SIEM or an EDR, evidence comes from endpoint and network logs, and tickets live in a case management or ticketing system. You do not need all of them to learn. Part 2 breaks down SOC analyst tools by job, and Part 10 builds a free home lab so you can practice on your own data. For Windows evidence, start with Windows Event Logs 101, which explains the log channels most SOC alerts are built on.

Common Pitfalls for New SOC Analysts

• Treating every alert as an incident. Most alerts are benign. Triage exists so you spend your time on the few that are not.
• Ignoring asset context. The same failed-login pattern means something different on a test VM than on a domain controller. Always ask what the asset is and who owns it.
• Chasing indicators without behavior. A blocked IP address is easy for an attacker to replace. Look at what the activity did, not only where it came from.
• Writing poor notes. If a ticket only says “false positive”, the next analyst has to redo your work. Record the evidence, not just the verdict.
• Never tuning. Repeated false positives cause alert fatigue, and fatigue is how real alerts get missed.
• Escalating too late. Follow the playbook, and when the playbook is silent, ask. Asking costs far less than a missed compromise.

How to Start Practicing Today

You do not need a job in a SOC to learn the workflow. Read the logs from machines you own, reproduce the alert above in a lab you control, and write the ticket as if someone else will pick it up. The rest of this path moves from log analysis in Parts 3 to 5, through SIEM tooling and detection engineering, to incident response at the end. Pair it with the incident handling guidance in NIST SP 800-61 so your tickets and playbooks follow a recognized structure. Only test against systems you own or are explicitly authorized to use.

What Is a SOC? A Short Recap

So, what is a SOC in practice? It is a team that turns raw logs into decisions. People watch alerts from their tools, follow written playbooks to triage and investigate them, escalate the real ones, and feed what they learn back into better detections. Everything else in this path, from Windows event IDs to Sigma rules, is a closer look at one stage of that loop.

If an interviewer asks what is a SOC, answer with the workflow instead of a list of products: detect, triage, investigate, contain or escalate, document and tune. Then give one concrete example, such as the SSH alert above, and name the evidence you checked and the decision you made. That shows you understand the job, not just the vocabulary.

Up next is Part 2, which sorts the SOC analyst tools by the question each one answers.

Frequently Asked Questions