SOC Foundations and Operational Readiness

0.1 What operational readiness means

A SOC that processes alerts is not the same as a SOC that operates. Processing alerts means someone opens the incident, makes a judgment call, closes it, and moves to the next one. Operating means the judgment call follows a documented framework, the closure includes a classification that feeds quality metrics, the escalation path is defined for when the judgment call is uncertain, and the whole system is measured so leadership knows whether the SOC is effective.

The gap between processing and operating is the gap this module closes. Most SOCs have the tools — Sentinel, Defender XDR, a ticketing system. Most SOCs have the people — analysts who can triage and investigate. What most SOCs don't have is the operational infrastructure — the documented processes, defined roles, escalation frameworks, measurement systems, and improvement cadences that make the tools and people effective as a system rather than a collection of individual efforts.

At Northgate Engineering, the SOC had three analysts, a managed SOC partner, Sentinel with 23 analytics rules, and Defender XDR. The tools worked. The analysts were competent. But nobody had documented the operating model, the escalation criteria, the triage methodology, the handover procedure, or the metrics framework. When INC-NE-2026-0227-001 hit — an AiTM campaign during after-hours coverage — every undocumented gap failed simultaneously. The managed SOC followed a playbook that didn't cover AiTM. The escalation had no path for "I can't determine if this is malicious." The metrics measured speed but not quality. The incident ran for 21 days.

This module builds every operational document that NE was missing. You build them for NE as the worked example, then adapt them to your own environment. By the end of this module, you have a documented SOC operation — not a team running on habits.

0.2 What you will learn

Ten sections, each producing a deployable operational document.

Section 1.1 — SOC Operating Models. Internal, managed, and hybrid models analyzed by failure mode — not by vendor pitch. You document your operating model as an Architecture Decision Record with known gaps identified. INC-NE-2026-0227-001 as the handoff gap case study.

Section 1.2 — Analyst Tiers and Role Architecture. L1 triage, L2 investigation, L3 deep analysis defined as capability specializations with explicit scope boundaries. Time protection for L3 feedback loop. NE's 3-person rotation as worked example.

Section 1.3 — Shift Handover Design. What transfers between shifts, what doesn't, and how to ensure investigation continuity across shift changes and between internal and MSSP teams. The handover checklist.

Section 1.4 — Escalation Framework. Three escalation triggers for the ambiguous 30% of alerts that playbooks can't cover: capability trigger, pattern trigger, instinct trigger. Structured escalation format. INC-NE-2026-0342 as worked example. Escalation accuracy measurement.

Section 1.5 — The Triage Decision Framework. Structured classification methodology — criteria, enrichment steps, disposition categories including the undetermined problem. The L1 triage playbook template.

Section 1.6 — Operational Metrics. Speed metrics (MTTT, SLA, throughput) vs quality metrics (MTTD, FP rate, classification accuracy, external discovery rate). Why optimizing speed doesn't improve quality. NE before-and-after.

Section 1.7 — The SOC Charter. The single document that formalizes operating model, tiers, escalation, and metrics. Four questions every charter answers. NE's charter as worked example.

Section 1.8 — Tool Stack Integration. Sentinel, Defender XDR, and Entra ID mapped to SOC workflow. Which tool serves which function. Data flow from source through detection through investigation.

Section 1.9 — SOC Maturity Assessment. Five-level framework across eight capabilities. NE baseline assessment reveals every Level 1 gap that enabled the AiTM compromise. Constraint-first improvement roadmap. Level 1→2 as highest-impact, lowest-cost transition.

Section 1.10 — Incident Classification Framework. Severity definitions tied to business impact, not technical complexity. Classification criteria. SLA mapping per severity. NE's classification matrix.

0.3 Why the Microsoft stack is ideal for SOC operations

Sentinel and Defender XDR provide the complete operational infrastructure for the SOC discipline this module teaches.

Sentinel's incident management maps directly to the triage decision framework — every alert becomes a classifiable incident with severity, status, owner, and classification disposition. The classification field (True Positive, Benign Positive, False Positive, Undetermined) is the data source for the quality metrics in Section 1.6. Without systematic disposition, quality metrics are impossible.

Defender XDR's unified incident queue correlates alerts across identity, endpoint, email, and cloud — which means the investigation methodology from Section 1.5 operates against correlated incidents rather than individual alerts. An analyst investigating a credential compromise sees the sign-in anomaly, the inbox rule creation, and the email access in a single incident timeline rather than three separate alerts.

The analytics rule engine provides the detection coverage that the SOC's triage and investigation capabilities depend on. The 28 rules you build in Modules 2-6 directly improve the SOC's visibility layer — which is meaningless without the operational foundation this module creates.

0.4 How to get the best from this module

Work the sections in sequence. Each builds on the previous — the operating model (1.1) determines the tier structure (1.2), the tier structure determines the handover procedure (1.3), the handover and tiers determine the escalation framework (1.4), and the charter (1.7) assembles all of them into a single document.

Build the NE artifacts first, then adapt to your environment. Every section walks through the NE worked example — NE's operating model, NE's tier definitions, NE's escalation framework — and then asks you to build the equivalent for your own SOC. If you don't currently operate a SOC, the NE artifacts serve as templates you'll use when you do.

Spend time on Sections 1.4 (escalation) and 1.6 (metrics). These two sections contain the operational concepts that most SOCs lack entirely. The escalation framework's handling of ambiguity and the distinction between speed metrics and quality metrics are the insights that change how you think about SOC operations — not just what you do, but what you measure and why.

Estimated total time: 8 to 10 hours. Two to three sections per session produces consistent progress.

0.5 Module structure

• Section 1.1 — SOC Operating Models
• Section 1.2 — Analyst Tiers and Role Architecture
• Section 1.3 — Shift Handover Design
• Section 1.4 — Escalation Framework
• Section 1.5 — The Triage Decision Framework
• Section 1.6 — Operational Metrics — Speed vs Quality
• Section 1.7 — The SOC Charter
• Section 1.8 — Tool Stack Integration
• Section 1.9 — SOC Maturity Assessment
• Section 1.10 — Incident Classification Framework

Prerequisites

Complete Module 0 (What Security Operations Is). Lab environment configured. Basic familiarity with the Sentinel incident queue and Defender XDR portal.

Go to Section 1.1 — SOC Operating Models to begin.