In this section
SOC Maturity Assessment
Section 0.4 introduced the maturity spectrum and the five levels. This section turns that framework into a hands-on assessment you run against your own SOC. You'll assess each of the eight capability areas independently, identify the constraint that's limiting everything else, and build the improvement roadmap that maps gaps to specific course modules.
Assessment, not aspiration
Scenario
Rachel asks the SOC lead: 'Where are we on the maturity scale?' The lead answers: 'We're probably a Level 2 — we have processes and documentation.' Rachel asks: 'Is the escalation framework documented?' 'Well, the analysts know when to escalate.' 'Are quality metrics tracked?' 'We track MTTT and SLA.' 'Is there a monthly tuning cadence?' 'Not formally, but we tune when things get noisy.' Each answer reveals the gap between perceived maturity and actual maturity. The assessment's value is the specificity: not 'we're Level 2' but 'escalation is Level 1 (undocumented), metrics are Level 1 (speed only), documentation is Level 2, detection is Level 2.'
A maturity assessment is only useful if it's honest. Most self-assessments inflate by one level — the team assumes documented processes where habits exist, assumes measurement where counting exists, and assumes improvement cadences where reactive fixes exist. The assessment framework in this section uses specific evidence-based criteria at each level so the determination is based on what exists, not what's intended.
The assessment takes 2-3 hours for a small SOC. It produces a capability profile across eight areas, identifies the constraint (the lowest-level capability that limits everything else), and maps the improvement path to course modules that close each gap.
Estimated time: 45 minutes.
Figure 1.9 — Evidence-based maturity criteria. Each level has a specific test: can a new hire do this (L1 test), does a referenced document exist (L2 test), can you show metric trends (L3 test), is there a scheduled improvement cadence (L4 test). Self-assessment without these tests inflates by one level.
The eight capability areas — assessment questions
For each capability, ask the evidence-based questions below. The answers determine the level.
1. Detection and monitoring
Level 1: Detection rules exist (templates enabled during deployment). No inventory of what's covered. No measurement of coverage gaps. Level 2: Detection rules are documented with a rule registry listing each rule's purpose, data source, ATT&CK mapping, and last-tuned date. Level 3: ATT&CK coverage is measured against relevant techniques. Detection backlog exists with gap priorities. Level 4: Monthly tuning review. Quarterly coverage assessment. Detection-as-code pipeline.
Assessment question: "Can you produce a list of every active analytics rule, what technique each detects, and the date each was last modified?" If no → Level 1. If yes but no coverage measurement → Level 2. If yes with coverage measurement → Level 3.
2. Triage and investigation
Level 1: Analysts triage based on experience. No documented framework. Quality depends on who's on shift. Level 2: Documented triage decision framework with enrichment steps. Standard investigation template. Level 3: Classification accuracy measured through L2 review. Triage quality tracked by analyst and by alert type. Level 4: Framework refined monthly based on accuracy data.
Assessment question: "If I gave your newest L1 analyst an alert right now, would they follow a documented process or figure it out themselves?" If figure it out → Level 1.
3. Escalation
Level 1: Severity-based only. No path for ambiguous alerts. Escalation depends on analyst judgment and comfort level. Level 2: Three trigger types documented (capability, pattern, instinct). Structured escalation format used. Level 3: Escalation accuracy measured. Instinct trigger usage tracked (not penalized). Level 4: Escalation patterns analyzed monthly for triage framework refinement.
Assessment question: "What happens when an analyst can't determine if an alert is malicious or benign?" If "they use their best judgment" → Level 1.
4. Documentation
Level 1: Investigation notes in tickets only. No institutional memory system. No searchable investigation history. Level 2: Standard investigation template used consistently. Key procedures documented. SOC charter exists. Level 3: Investigation database searchable for similar incidents. Documentation completeness measured. Level 4: Documentation reviewed quarterly for currency.
5. Metrics
Level 1: Speed metrics only (MTTT, SLA, throughput). No quality metrics. Level 2: Quality metrics defined and tracked (MTTD, FP rate, external discovery rate). Level 3: Quality metrics drive decisions. Monthly reporting to CISO. Quarterly board report. Level 4: Metrics targets adjusted based on trend data. Metrics drive budget and staffing decisions.
6. Automation
Level 1: All manual. No enrichment automation. No automated notification. Level 2: Basic automation for common workflows (enrichment, notification). Level 3: SOAR playbooks for standard containment actions. Automation coverage measured. Level 4: Automation expanded based on analyst time studies.
7. Continuous improvement
Level 1: Reactive only. Improvement happens after incidents. Level 2: Monthly tuning review exists. Post-incident reviews produce recommendations. Level 3: Recommendations tracked to completion. Quarterly coverage assessment. Level 4: Annual program review reassesses operating model and tier structure.
8. People and training
Level 1: No competency framework. Training is ad hoc. Career path undefined. Level 2: Tier competencies defined. Some structured training aligned to role. Level 3: Training effectiveness measured through classification accuracy improvement. Career progression documented. Level 4: Training program revised annually based on performance data.
NE's baseline assessment — the worked example
NE's first formal assessment after INC-NE-2026-0227-001 produced this profile:
The profile reveals the pattern: the SOC's two strongest capabilities (Detection L2, People L2) sit on a foundation where six out of eight capabilities are at Level 1. The AiTM incident didn't fail because detection was bad — it failed because the supporting infrastructure (escalation, triage, metrics) couldn't handle what the detection rules missed.
Automation: Level 1. All manual. No enrichment playbooks. No automated notification for Severity 1. No containment automation.
Improvement: Level 1. Reactive only. No monthly tuning review. No quarterly coverage assessment. Improvement happened only after incidents — and even then, only for the specific technique that caused the incident.
People: Level 2. Some structured training — both analysts had completed the Microsoft SC-200 certification. But no competency framework tied to tier requirements. No defined career progression criteria.
Running the assessment
The assessment takes 2-3 hours and should involve the SOC lead plus at least one analyst — the analyst provides the ground-truth perspective on whether processes are actually followed versus nominally documented.
For each of the eight capabilities, work through the level criteria in order. Start at Level 1 — does the capability depend entirely on specific people being available? If yes, it's Level 1 regardless of what documentation exists. If no, check Level 2 — is the process documented in a form the team actively references? Not "does a document exist?" but "when was it last referenced by an analyst during operational work?" If the document exists but nobody opens it, the capability is functionally Level 1.
Continue through Level 3 (measured with quality metrics), Level 4 (scheduled improvement cadence), and Level 5 (innovation and experimentation). Most SOCs will find the majority of capabilities at Levels 1-2. That's normal and expected — the assessment's value is the specificity of the gap identification, not the score.
The assessment output
The assessment produces three deliverables. First, the capability profile — a one-page table showing each capability's current level with the evidence that supports the determination. Second, the constraint identification — which capability at the lowest level is limiting overall effectiveness. Third, the improvement roadmap — the prioritized sequence of gap closures with deliverables, effort estimates, and target dates.
NE's assessment output fits on two pages. Page one: the capability profile table. Page two: the constraint analysis and 90-day improvement plan. Rachel reviews it quarterly and presents the progression to the board as part of the security operations update.
Quarterly reassessment
The assessment is not a one-time exercise. The quarterly reassessment takes 1 hour (faster than the initial assessment because the framework is familiar) and answers three questions: Have any capabilities improved since the last assessment? (Evidence: new documents, new metrics, new cadences.) Have any capabilities degraded? (Risk: the monthly tuning review was skipped for two months because of queue pressure — improvement capability drops from Level 3 back to Level 2.) Has the constraint shifted? (The original constraint was escalation. After fixing it, the new constraint might be detection coverage or automation.)
The quarterly reassessment keeps the improvement roadmap current. Without it, the roadmap is based on the initial assessment and doesn't reflect changes — positive or negative — in the SOC's operational state.
The constraint
The assessment revealed that escalation at Level 1 was the binding constraint. When the AiTM alert arrived during BlueVoyant's coverage window, the severity-based escalation framework had no path for "MFA present but I can't determine if the authentication is legitimate." The alert was Medium severity. Medium stays at L1 per the severity framework. The analyst closed it. The constraint — no escalation path for ambiguity — enabled 21 days of attacker access.
The second constraint was triage at Level 1. Even if the escalation framework had existed, the triage process had no MFA method check that would have distinguished interactive MFA from token-claim MFA. The enrichment gap meant the data that could reveal AiTM was never examined.
Every capability rated one level higher than reality. "We have documentation" — but it's a strategy document from two years ago that nobody references. "We measure metrics" — but only MTTT and SLA, which are speed metrics, not quality metrics. "We have an improvement cadence" — but the monthly review hasn't happened in four months because queue pressure consumed the time. The evidence-based test at each level prevents inflation: not "do we have documentation?" but "does the team reference it during daily work?" Not "do we track metrics?" but "can you show me three months of trend data?"
The constraint-first improvement roadmap
The assessment produces a capability profile. The roadmap prioritizes the capability whose current level constrains everything else — the weakest link.
Identifying the constraint
The constraint is the capability that, if improved, would produce the largest impact on overall SOC effectiveness. It's not always the lowest-rated capability. NE's automation was Level 1, but automation at Level 1 didn't cause the AiTM failure — the escalation and triage gaps did. Automation at Level 2 would have helped (automated enrichment would have surfaced the MFA method data faster), but the root cause was operational, not technological.
The constraint identification question: "If one capability improved by one level overnight, which improvement would prevent the most harm?" At NE, the answer was escalation — because every other capability was limited by the inability to handle ambiguous alerts.
The improvement plan
Each gap in the assessment maps to specific deliverables with estimated effort:
Escalation Level 1 → Level 2: Document three trigger types, structured escalation format, instinct protection policy. Effort: 2 weeks, zero cost. Deliverable: escalation framework document (Section 1.4 of this module).
Triage Level 1 → Level 2: Document decision framework with enrichment steps per alert category. Effort: 3 weeks, zero cost. Deliverable: triage playbook (Section 1.5).
Documentation Level 1 → Level 2: Standard investigation template, handover checklist, charter. Effort: 2 weeks, zero cost. Deliverables: Sections 1.3, 1.7.
Metrics Level 1 → Level 2: Define quality metrics, build KQL queries for disposition analysis, establish reporting cadence. Effort: 1 week for queries, ongoing for classification discipline. Deliverable: metrics framework (Section 1.6).
All four Level 1 → Level 2 transitions require zero incremental cost. They require time — approximately 90 days total for the complete operational foundation. That time investment is the most cost-effective security improvement most organizations can make.
Beyond Level 2
After the Level 1 → Level 2 foundation, the roadmap targets Level 3 for the highest-impact capabilities. Detection Level 2 → Level 3 requires building the detection engineering methodology and measuring ATT&CK coverage — Modules 2-6 of this course. Metrics Level 2 → Level 3 requires systematic disposition classification on every closure and monthly quality reporting — an ongoing discipline that starts in Module 1 and matures through the course.
The Level 2 → Level 3 transition is harder than Level 1 → Level 2 because it requires sustained behavioral change. Level 2 requires writing documents (a one-time investment). Level 3 requires using those documents to generate data, analyzing the data, and acting on the analysis — an ongoing investment of time every week and every month. The SOC lead who writes the triage framework (Level 2) and then measures classification accuracy monthly, identifies the alert types with lowest accuracy, and refines the framework based on the data (Level 3) is operating at a entirely different level of operational maturity.
The investment scales appropriately. Level 1 → Level 2 costs 90 days and zero budget. Level 2 → Level 3 costs 6 months and a modest ongoing time investment (the 10 protected L3 hours per week from Section 1.2). Level 3 → Level 4 costs 12+ months and potentially some tooling investment (SOAR automation, detection-as-code pipeline). Each level builds on the infrastructure of the previous level — you can't measure quality metrics (Level 3) without documented processes (Level 2), and you can't run scheduled improvement cadences (Level 4) without quality metrics (Level 3) to tell you what to improve.
The roadmap is progressive: close the constraint, reassess, identify the new constraint, close it, reassess. NE's six-month progression went from 5 capabilities at Level 1 and 3 at Level 2 to 0 at Level 1, 4 at Level 2, and 4 at Level 3. Same team. Same budget. Structured improvement. The maturity assessment made the improvement visible and measurable — which is what made it possible to sustain the effort through the inevitable periods when queue pressure tempted the team to deprioritize L3 work.
SOC Operations Principle
A maturity assessment is only useful if it's honest. Evidence-based criteria prevent inflation: not "do we have this?" but "can we prove it with a specific artifact, a referenced document, or three months of metric data?" The constraint-first roadmap targets the weakest capability because that's where improvement produces the most impact. Every Level 1 → Level 2 transition costs zero budget and requires only time — making it the highest-ROI security investment most organizations can make.
Get weekly detection and investigation techniques
KQL queries, detection rules, and investigation methods — the same depth as this course, delivered every Tuesday.
No spam. Unsubscribe anytime. ~2,000 security practitioners.