SOC Structure and the Tier Model

The tier model exists because security operations generate work at very different levels of complexity and volume. A mature SOC may receive tens of thousands of SIEM alerts per day; the vast majority are false positives or low-severity events that require only a brief check and a closure decision. A much smaller number are genuine incidents requiring hours of investigation. Routing all of this to the same pool of analysts is inefficient: senior analysts spend their shift triaging noise, and complex incidents wait. The tier model separates the work.

Tier 1 is the monitoring and triage layer. Analysts at this tier watch the SIEM console, acknowledge alerts, apply the relevant playbook, and make a binary decision: close the alert as a false positive, or escalate it to Tier 2 with an initial assessment. Tier 1 is typically the largest headcount in the SOC and operates on rotating shifts to maintain 24/7 coverage. The skill requirement is breadth rather than depth: Tier 1 analysts need to recognise the signatures of common attack types, know when something is outside their playbook, and document their findings clearly before handing off.

Tier 2 is the investigation and response layer. When a Tier 1 escalation arrives, Tier 2 analysts take ownership of the incident. They conduct deeper forensic analysis, correlate events across multiple data sources, determine the scope of the compromise, and execute containment and eradication steps. Tier 2 analysts also handle cases that Tier 1 cannot close confidently because they fall outside existing playbooks. In many SOCs, Tier 2 analysts are the primary authors of the incident report that feeds the post-incident review.

Tier 3 is the advanced analysis and strategic improvement layer. Tier 3 analysts handle the incidents that Tier 2 cannot resolve, particularly those involving sophisticated or novel attack techniques. They also conduct proactive threat hunting, build and refine SIEM detection rules, maintain and update the playbook library, and translate threat intelligence reports into actionable detection improvements. In smaller SOCs, one or two senior analysts fulfil Tier 3 functions alongside Tier 2 responsibilities.

The Tier 1 analyst's primary tool is the SIEM. Modern SIEMs ingest logs from endpoints, network devices, cloud services, identity providers, and applications, apply correlation rules, and surface alerts ranked by severity. A Tier 1 shift typically begins with a review of any open alerts from the previous shift, followed by ongoing monitoring of the live alert queue.

When an alert fires, the Tier 1 analyst follows the relevant playbook. The playbook specifies which data sources to check, what constitutes a confirmed positive, and what information to record. For a brute-force login alert, the playbook might instruct the analyst to: check whether the source IP appears on a known-bad list, verify whether any login attempts succeeded, check whether the targeted account has MFA enabled, and then decide whether to escalate or close. This structured decision process is what allows analysts with relatively limited experience to handle high alert volumes consistently.

The quality of a Tier 1 escalation matters as much as the decision to escalate. A good escalation includes: the alert details and timestamp, the data sources checked and their outputs, the analyst's assessment of why this is a genuine incident, and any immediate containment steps already taken (such as blocking a source IP). A poor escalation hands Tier 2 a raw alert with no context, forcing them to restart the investigation from the beginning.

Tier 2 investigation begins where Tier 1 triage ends. The analyst receives the escalation, reviews the Tier 1 notes, and begins building a timeline of the incident. This typically involves pulling additional log sources that Tier 1 did not examine, querying endpoint detection and response (EDR) tools for process and file activity on affected hosts, and correlating network traffic logs to understand lateral movement.

Containment is a central Tier 2 responsibility. Depending on the incident type and the organisation's IR plan, containment actions may include isolating an affected host from the network, disabling a compromised user account, blocking a malicious domain or IP at the firewall, or revoking active sessions. Every containment action must be documented: what was done, when, and by whom. This documentation is part of the incident's evidence record and feeds directly into the post-incident review.

Tier 2 analysts also manage communication during an active incident. They maintain the incident ticket, update stakeholders on status, and coordinate with system owners when containment requires taking a production system offline. In organisations that follow the SANS PICERL model, the Tier 2 analyst is typically the incident handler who owns the case from the Identification phase through Lessons Learned.

Tier 3 analysts spend only a portion of their time on active incident response. The remainder goes to proactive work that improves the SOC's future detection capability. Threat hunting is the most visible of these activities: the analyst starts with a hypothesis derived from threat intelligence (for example, that a specific threat actor group is targeting organisations in the same sector using a particular technique) and then searches the environment's logs and endpoint telemetry for evidence that this activity has already occurred undetected.

When a hunt finds evidence of a technique that existing rules did not detect, the outcome is a new SIEM detection rule. When the hunt finds nothing, the outcome is confidence that the environment does not currently show indicators of that technique, plus documentation of what was searched. Both outcomes have operational value: the first improves the detection layer, and the second provides a baseline for future comparison.

Tier 3 also maintains the playbook library. After each significant incident, the relevant playbook is reviewed: did it guide the analyst to the right conclusion efficiently? Were there steps missing? Did the analyst have to improvise, and if so, should the improvisation be standardised? This feedback loop between incident response and playbook maintenance is what allows the SOC to improve over time rather than repeating the same investigative steps at the same speed indefinitely.

Every organisation with a SOC sits somewhere on a spectrum from fully internal to fully outsourced. The choice affects cost, control, speed, and the sensitivity of data that must leave the organisation's boundary. No model is universally correct; the right choice depends on headcount, budget, data classification requirements, and the maturity of the internal security team.

The co-managed model has grown in adoption because it solves the staffing problem that most mid-size organisations face: maintaining three eight-hour shifts of qualified analysts is expensive and difficult in markets where experienced security staff are in short supply. By outsourcing 24/7 Tier 1 coverage to an MSSP while retaining Tier 2 and Tier 3 capability internally, organisations keep control of investigation and response decisions while offloading monitoring. The contractual challenge is defining escalation thresholds clearly: the MSSP must know exactly when to call the internal team, and the internal team must be reachable at any hour.

A SOC without metrics cannot improve. The core operational metrics track the speed and quality of the detection-to-response pipeline. Mean Time to Detect (MTTD) measures how long it takes from the moment a malicious event occurs until the SOC generates an alert. Mean Time to Respond (MTTR) measures from alert generation to the first containment action. Both are lagging indicators: they reflect how the SOC performed on past incidents rather than predicting future ones.

False-positive rate and alert-to-escalation ratio are leading indicators of Tier 1 health. A rising false-positive rate signals that detection rules need tuning. A falling alert-to-escalation ratio can mean either that Tier 1 is correctly filtering noise or that analysts have begun to suppress alerts without proper investigation. Distinguishing between these explanations requires periodic audit of closed-without-escalation tickets.

SOC maturity models, including the SOC-CMM developed by Rob van Os and adopted by national cybersecurity agencies in several countries, provide a structured framework for assessing a SOC against dimensions such as people, process, technology, and business alignment. Organisations use these models to identify gaps and prioritise investment. The UK National Cyber Security Centre and Australia's Australian Signals Directorate both publish guidance on SOC maturity that aligns with the SOC-CMM structure. These frameworks do not prescribe the tier model specifically, but the tier structure is implicit in every maturity dimension that addresses escalation, specialisation, and proactive capability.