Most security operations centres can list their tools and headcount, but few can show with evidence how mature their detection and response actually is, or which gap to close next. A SOC with a well-funded SIEM can still miss an attacker who signs in with stolen cloud credentials, because nobody onboarded the identity provider logs or wrote a rule for them. This five-level model, using the same Ad hoc to Optimised scale as the NHI Mgmt Group NHI Governance Maturity Model, scores a SOC across ten dimensions covering people, process, technology and measurement, and shows how the levels relate to SOC-CMM, MITRE's 11 Strategies and the NIST CSF 2.0 Tiers. It is for SOC managers, detection leads and CISOs who need an honest baseline, a realistic target and a roadmap, whether the SOC is in-house, outsourced or hybrid.
Key takeaways
- Score ten dimensions separately: visibility and log coverage, detection engineering, triage and case management, incident response, threat intelligence, threat hunting, automation, people and skills, metrics, and identity and cloud coverage.
- Evidence decides the level. A runbook nobody has exercised, or a rule that has never fired in a test, is Level 2 at best, whatever the documentation says.
- Level 3 (Defined) is the right first target for most SOCs: priority log sources onboarded, detections in version control with an owner, consistent triage and tested response playbooks.
- Identity and cloud coverage is a frequent blind spot. Sign-in, audit and service principal activity from the identity provider and cloud control plane belong in the first wave of data sources, not the last.
- Measure outcomes, not activity. MITRE warns that choosing and monitoring the wrong measures "can lead to wasted time or worse, a focus on harmful practices". Track tested detection coverage and time to contain, not tickets closed.
The five levels
| Level | Name | Description |
|---|---|---|
| 1 | Ad hoc | Monitoring depends on vendor default alerts and individual effort. Log sources are whatever was easy to connect, there are no written playbooks, and incidents are often found by third parties or users. |
| 2 | Developing | A SIEM or managed service is in place and alerts are triaged, but coverage is patchy. Some detections are customised, playbooks exist for common incidents, and metrics are counted manually. |
| 3 | Defined | The SOC has a documented service catalogue, priority log sources are onboarded and health-checked, detections follow a lifecycle in version control, triage uses consistent disposition codes, and response playbooks are exercised. |
| 4 | Managed | Performance is measured and drives decisions. Detection coverage is mapped to prioritised ATT&CK techniques and validated by testing, routine enrichment and containment are automated with approval gates, and hunting is a scheduled function. |
| 5 | Optimised | Purple team results, hunt findings and post-incident reviews feed new detections within days, data is tiered by value, and AI or automation is evaluated for accuracy before its autonomy is extended. |
The ten dimensions
Levels 2 and 4 sit between the descriptions shown; the roadmap below lists what moves you from each level to the next.
| Dimension | Level 1 Ad hoc | Level 3 Defined | Level 5 Optimised |
|---|---|---|---|
| Visibility and log coverage | Unknown which systems send logs; gaps found during incidents | Priority sources (EDR, network devices, domain controllers, identity provider, cloud platform) onboarded; source health alerting when a feed stops | Coverage tracked against the asset inventory; data tiered by value so low-value logs are kept cheaply outside the SIEM |
| Detection engineering | Vendor default rules only | Detections as code with an owner, test case and lifecycle; tuning driven by triage feedback | Every prioritised technique has a tested detection; rules retired or rewritten when tests or false positive rates show decay |
| Triage and case management | Alerts in email or a shared inbox; no consistent outcome | Case management with severity, disposition codes and escalation criteria; analysts record actions | Enrichment pre-populated; closed alerts sampled monthly for quality; escalation accuracy tracked |
| Incident response | Improvised; no authority to contain | Playbooks for top incident types, agreed containment authority, exercised at least yearly | Lessons learned feed detections and controls; recovery criteria and third-party coordination rehearsed |
| Threat intelligence | Raw indicator feeds, unreviewed | Intelligence requirements set by business risk; relevant actors and techniques prioritised | Intelligence drives detection backlog and hunts; feedback loop measures which sources were useful |
| Threat hunting | None | Hypothesis-driven hunts run periodically, with documented findings | Scheduled hunt programme; every hunt produces a detection, a data gap fix or a documented negative result |
| Automation | Manual copy and paste between tools | Enrichment and ticketing automated; containment actions scripted but human-approved | Low-risk containment automated with rollback; automation and AI accuracy evaluated before autonomy is widened |
| People and skills | One or two people on best effort; no cover | Defined roles, shift and on-call model, training plan, knowledge captured in runbooks | Career paths and rotation into engineering and hunting; attrition and time to competence tracked |
| Metrics | Alert counts only | Time to triage and contain by severity, true positive rate per rule, reported monthly | Outcome metrics (tested coverage, time to contain) drive investment and are reported to leadership |
| Identity and cloud coverage | No identity provider, SaaS or cloud audit logs | IdP sign-in and audit logs, cloud control plane and key SaaS audit logs onboarded; detections for valid account abuse | Non-human identity behaviour baselined; automated revocation of tokens and keys on high-confidence detections |
How the levels relate to SOC-CMM, MITRE and NIST CSF
SOC-CMM describes itself as "a capability maturity model and self-assessment tool for Security Operations Centers (SOCs)". Its model "consists of 5 domains and 27 aspects": Business, People and Process are scored for maturity only, while Technology and Services are scored for both maturity and capability. Maturity runs from 0 Non-existent to 5 Optimizing; capability uses the levels Incomplete, Performed, Managed and Defined. Its output sheets also show how the SOC contributes to NIST CSF scoring.
Watch the names: SOC-CMM's "Managed" is maturity level 2 ("documented and delivered consistently"), whereas Managed is level 4 in this model. NIST CSF 2.0 Tiers (Partial, Risk Informed, Repeatable, Adaptive) describe the rigour of organisation-wide risk governance, not SOC capability, and NIST says Tiers "should complement an organization's cybersecurity risk management methodology rather than replace it". Treat the mapping below as a sense check, not an equivalence.
| This model | SOC-CMM maturity (loose fit) | NIST CSF 2.0 Tier (loose fit) | Evidence that marks the level |
|---|---|---|---|
| 1 Ad hoc | 0 Non-existent to 1 Initial | Tier 1 Partial | No log source list; alerts handled by whoever sees them |
| 2 Developing | 1 Initial to 2 Managed | Tier 2 Risk Informed | SIEM or MDR live; some playbooks; manual metrics |
| 3 Defined | 2 Managed to 3 Defined | Tier 3 Repeatable | Service catalogue, detection lifecycle, exercised playbooks |
| 4 Managed | 4 Quantitatively Managed | Tier 3 to 4 | Coverage validated by testing; metrics drive decisions |
| 5 Optimised | 5 Optimizing | Tier 4 Adaptive | Continuous improvement loop from tests, hunts and incidents |
Dimension to framework mapping
The mapping below is our judgement of where each dimension sits; CSF IDs and strategy names are quoted from NIST CSWP 29 and MITRE.
| Dimension | NIST CSF 2.0 subcategories | MITRE 11 Strategies |
|---|---|---|
| Visibility and log coverage | PR.PS-04, DE.CM-01, DE.CM-09 | 7 Select and Collect the Right Data |
| Detection engineering | DE.AE-02, DE.AE-03 | 7, 8 Leverage Tools to Support Analyst Workflow |
| Triage and case management | RS.MA-02, RS.MA-03, RS.MA-04, DE.AE-08 | 8 |
| Incident response | RS.MA-01, RS.AN-03, RS.MI-01, RS.MI-02, RS.CO-02 | 5 Prioritize Incident Response; 2 Give the SOC the Authority to Do Its Job |
| Threat intelligence | ID.RA-02, DE.AE-07 | 6 Illuminate Adversaries with Cyber Threat Intelligence |
| Threat hunting | DE.AE-02, ID.IM-01 | 11 Turn up the Volume by Expanding SOC Functionality |
| Automation | DE.AE-06, RS.MI-01 | 8 |
| People and skills | GV.RR-03 | 4 Hire AND Grow Quality Staff |
| Metrics | ID.IM-01, ID.IM-03 | 10 Measure Performance to Improve Performance |
| Identity and cloud coverage | DE.CM-03, DE.CM-06, ID.AM-02 | 1 Know What You Are Protecting and Why; 7 |
Self-assessment questions
Score each dimension from 1 to 5 using evidence from tooling and case records. Your overall level is the lowest score among the dimensions that protect your most critical systems, not the average.
- Visibility: if your domain controller or identity provider feed stopped at 2am, how long before someone noticed?
- Detection engineering: what share of your custom rules has a test that ran in the last quarter, and who owns each one?
- Triage: could you show, for last month, the true positive rate of your ten noisiest rules?
- Incident response: who can isolate a production server or disable an executive's account without waiting for approval, and is that written down?
- Threat intelligence: which three threat actors or techniques are you prioritising this quarter, and why those?
- Hunting: what did your last hunt find, and what detection or data source changed as a result?
- Automation: which response actions run without a human, and how would you roll one back if it disrupted a business service?
- People: how long does a new analyst take to work a shift alone, and what happens when your most experienced engineer leaves?
- Metrics: are your metrics produced by tooling or assembled by hand each month?
- Identity and cloud: would you see a service principal or API key being used from a new country, or a new OAuth application granted mailbox access?
Where identity fits
An attacker signing in with valid credentials looks like normal use unless the SOC has identity telemetry and context. ATT&CK T1078.004 (Valid Accounts: Cloud Accounts) notes that such credentials "may also be used to bypass security controls such as multi-factor authentication". The joint ASD-led guidance on priority logs for SIEM ingestion lists domain controller and Active Directory security logs near the top and treats Entra ID sign-in and Unified Audit logs as sources to collect in full. Logging tier matters too: in the Storm-0558 key breach, the US State Department detected forged-token mail access through a custom alert on premium audit logs; organisations without that logging tier could not see the same activity.
- Non-human identities: service accounts, service principals, API keys and OAuth apps need baselines and response runbooks (rotate, revoke, disable without breaking production). See the ITDR Guide and the Leaked Credential Response Playbook.
- The SOC's own credentials: SIEM connectors, EDR API keys and SOAR service accounts can read all telemetry and act across the estate. Vault and scope them, and alert on use from unexpected hosts.
Moving up a level
From Ad hoc to Developing
- Write down the SOC's mission, scope and authority, and get it signed by the CISO (MITRE Strategies 1 and 2). See the SOC Guide.
- Decide in-house, MDR or hybrid. Small teams without 24x7 staff usually start with a managed service and keep incident ownership in-house. See the MDR Guide.
- Onboard EDR, network devices and domain controllers first, the top of the joint priority logs guidance's ranking, add your identity provider's sign-in and audit logs, and alert when any feed stops.
- Introduce a case management tool and a short list of disposition codes.
From Developing to Defined
- Move detections into version control with an owner, a test and a review date; the NCSC advises a use-case lifecycle "to ensure that the use-case remains valid throughout its use". See the Detection Engineering Guide.
- Build a triage feedback loop so analysts flag noisy rules, and set escalation criteria by severity.
- Write and exercise playbooks for your top five incident types, including credential compromise and ransomware. See the Incident Response Guide.
- Onboard cloud control plane and key SaaS audit logs, and set intelligence requirements from business risk. See the Threat Intelligence Guide.
From Defined to Managed
- Map detections to prioritised ATT&CK techniques and validate them with purple team or attack simulation; record pass or fail per technique. See the Breach and Attack Simulation (BAS) Guide.
- Automate enrichment and ticketing, then script containment with human approval and a tested rollback. The joint SIEM and SOAR guidance advises: "Properly implement a SIEM before you consider implementing a SOAR." See the SOAR and Security Automation Guide.
- Start a scheduled, hypothesis-driven hunt programme.
From Managed to Optimised
- Close the loop: every hunt, test and post-incident review produces a detection, a data fix or a documented decision.
- Tier data by value and move low-value logs to cheaper storage. See the Log Management and Retention Guide.
- Evaluate AI triage and agent tooling against a labelled set of past alerts before widening its autonomy. See the AI SOC Guide.
- Report outcome metrics to leadership and tie them to investment decisions.
Metrics that show maturity
- Tested detection coverage: prioritised ATT&CK techniques with a detection that passed a test this quarter, as a percentage.
- Log source health: priority sources reporting within their expected interval (target 100%), and minutes to notice a silent feed.
- Time to triage and time to contain: medians and 90th percentiles by severity, measured from event time where possible.
- True positive rate per rule: with the bottom ten reviewed monthly.
- Identity coverage: share of identity providers, cloud tenants and critical SaaS applications with audit logs in the SOC.
- Analyst retention and time to competence: leavers per year and months to independent shift work.
Common failure patterns
- Buying maturity: a new SIEM or SOAR does not move a level if detections, playbooks and ownership stay the same.
- Collect everything: ingesting all logs into the SIEM drives cost without adding coverage. The authoring agencies of the joint guidance "strongly discourage using a SIEM as the central repository for all logs."
- Scoring the average: a strong EDR score hides a Level 1 identity score, which is where cloud intrusions start, as in the Snowflake breach.
- Automation before accuracy: automating containment on noisy detections disrupts the business and erodes trust in the SOC.
Practitioner checklist
- Score all ten dimensions with evidence and record the source of each score.
- Set Level 3 as the 12-month target, with Level 4 for identity and cloud coverage if you run critical cloud workloads.
- Baseline the six metrics now and produce them from tooling, not spreadsheets.
- Translate SOC-CMM or CSF Tier results into this model's names carefully: their "Managed" and "Defined" sit at different levels.
- Reassess every six to twelve months and after a major incident or platform change. See the SIEM Guide.
Standards and references
- NIST: The NIST Cybersecurity Framework (CSF) 2.0
- NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
- MITRE: 11 Strategies of a World-Class Cybersecurity Operations Center
- SOC-CMM: The SOC-CMM model
- NCSC: Detection practices
- CISA: Guidance for SIEM and SOAR Implementation
- ASD's ACSC: Priority Logs for SIEM Ingestion, Practitioner Guidance
- MITRE ATT&CK: T1078.004 Valid Accounts: Cloud Accounts
Related NHI Mgmt Group resources: SOC Guide · Detection Engineering Guide · Identity Security Maturity Model · AI SOC Guide