A security operations center (SOC) is the team that watches for security events, decides which ones matter, and runs the first response. Typical roles are alert analyst, incident responder, threat hunter, detection engineer, threat intelligence analyst and SOC manager. Names and tiers vary by company; the duties below are what matter.
Is there an official list of SOC roles?
No. NIST lists the Security Operations Center as a defined term across several publications, including SP 800-53 Rev. 5 and SP 800-61 Rev. 3, but it does not prescribe job titles. The tier model (Tier 1, Tier 2, Tier 3) is common industry practice, not a standard. Treat the list here as a way to check that every duty has an owner, not as an org chart to copy.
Small teams combine roles. One person in a ten-person security group may triage alerts in the morning and tune detections in the afternoon. That is fine, as long as nothing in the duty list below is left unowned.
What does each role do?
Alert analyst (often called Tier 1). Reads the alert queue, checks whether an alert is real, enriches it with context such as asset owner and recent logins, and either closes it with a note or escalates. The skill that matters most is consistent judgement and clear write-ups, because everything downstream depends on the ticket.
Incident responder (Tier 2). Takes escalated cases, scopes them, and acts: isolating a host, disabling an account, collecting evidence, coordinating with IT. NIST SP 800-61 Rev. 3 now frames incident response inside the Cybersecurity Framework 2.0, which means responders also feed lessons back into preparation and detection.
Threat hunter. Looks for activity that no alert caught. A hunt starts from a hypothesis, such as "an attacker with stolen credentials would sign in from an unusual country and then list storage buckets," and ends with either a finding or a new detection.
Detection engineer. Writes, tests and retires detection rules, and measures how noisy each one is. A rule that fires 400 times a day and is closed every time is a defect, and this role owns it.
Threat intelligence analyst. Turns outside reporting into things the SOC can use: which techniques are being used against your sector, which indicators are worth blocking, which advisories apply to your software.
Security platform engineer. Keeps the log pipeline, the SIEM and the response tooling running. When a log source silently stops, this person notices.
SOC manager. Owns staffing, metrics, escalation paths and the relationship with the rest of the business, including who may approve an emergency change at 3 a.m.
What does a handoff look like in practice?
Here is a constructed example. An analyst sees an alert for a login from a new country on a finance mailbox. They check the user's calendar and travel record, find nothing, and see a new mail forwarding rule created two minutes after the login. They escalate with those three facts in the ticket.
The responder disables the session, removes the rule, and asks IT to reset credentials. The hunter then searches for the same rule creation pattern across all mailboxes. The detection engineer turns that search into a standing alert. The manager reports the case, and the time from alert to containment, at the weekly review.
Notice that each person's output is the next person's input. Where SOCs fail, it is usually at these joins: a ticket with no context, a hunt finding that never becomes a rule, a log source nobody monitors.
How to check or apply this
- List every duty above and write a named owner next to each, even if one person holds several.
- Write down the escalation criteria between analyst and responder in plain sentences, and test them on five past alerts.
- Define who can isolate a host or disable an account without asking, and who must be called first.
- Track how many hunt findings became detections in the last quarter. Zero means the loop is broken.
- Check that a stopped log source raises an alert to the platform owner within a day.
- Review the roles when you add cloud or SaaS logging, because new log sources need new detection work, not just new storage.
Quick check
Do we need a 24/7 SOC to have these roles?
No. The duties exist whether or not you staff round the clock. Smaller organizations often cover after-hours alerts with an on-call rotation or an outside provider. What matters is that someone is named for each duty and escalation is written down.
Is a SOC the same as incident response?
Not quite. The SOC detects and triages, and usually runs first response. Incident response is the wider process, including legal, communications and recovery, which NIST SP 800-61 Rev. 3 describes in the context of the Cybersecurity Framework 2.0.
Sources
- NIST CSRC glossary: Security Operations Center
- NIST SP 800-61 Rev. 3, Incident Response Recommendations and Considerations
- CISA, Best Practices for Event Logging and Threat Detection
Last reviewed: 18 October 2026.
