SOC Maturity Model: Assessing Where Your Security Operations Center Stands and Building the Roadmap to the Next Level

SOC maturity models vary by framework (Gartner, CISA C2M2, SANS), but the underlying progression is consistent. The five-level model below maps the characteristics most relevant to practical assessment.

Most commercial organizations with a functioning SOC operate between Level 2 and Level 3. The transition from Level 2 to Level 3 is where the largest measurable improvements in detection and response time occur and where most investment should be focused. Level 5 is aspirational for all but the largest and most security-mature organizations.

The three assessment dimensions: Each level should be assessed across three dimensions independently, as organizations are often asymmetric -- mature in technology but immature in process, or vice versa.

• People: Analyst headcount, skill levels, shift coverage, career development, retention
• Process: Documented runbooks, escalation paths, SLAs, post-incident reviews, detection engineering workflow
• Technology: SIEM, SOAR, EDR, NDR, threat intelligence feeds, case management, log coverage

Level 1 characteristics (what you see in Level 1 organizations):

• Security events are investigated reactively, after a user reports a problem or a tool generates an alert
• No centralized log aggregation -- analysts must log in to individual systems to investigate
• Alert handling is undocumented; different analysts follow different processes for the same alert type
• There is no defined escalation path for high-severity incidents
• Mean time to detect is measured in days or weeks because active monitoring is absent
• Institutional knowledge lives in specific individuals, not documented processes

The highest-impact investments to reach Level 2:

The foundational Level 2 capability is centralized log collection and correlation in a SIEM. This single investment closes the largest MTTD gap: moving from investigating alerts in isolation on individual systems to correlating events across the environment. The SIEM platform choice matters less than getting the right log sources in. Priority log sources in order of detection value:

1. Windows Security Event Logs (4624, 4625, 4648, 4768, 4769, 4776, 4720, 4728, 4732)
2. Endpoint Detection and Response (EDR) telemetry
3. Firewall and network perimeter logs
4. DNS query logs
5. Cloud platform logs (CloudTrail, Entra ID Sign-In Logs, GCP Audit Logs)
6. Email gateway logs

Document 10-15 runbooks for the most common alert types before moving on. An analyst who handles a phishing alert 20 times a week using an undocumented process introduces inconsistency and errors that a runbook eliminates.

Level 2 characteristics (the starting point for this transition):

• SIEM deployed with core log sources ingested
• Analysts respond to SIEM alerts using documented runbooks
• Escalation paths defined for Priority 1 incidents
• Basic metrics collected: alert volume, MTTR, escalation rate
• No proactive threat hunting -- analysts only respond to tool-generated alerts
• SOAR is either absent or minimally used
• Detection rules are SIEM vendor defaults, not tuned to the environment

The capability gaps that define the Level 2 to Level 3 transition:

Detection engineering: At Level 2, the detection library is the vendor default rule set. The transition to Level 3 requires building a detection engineering practice: analysts (or a dedicated detection engineer) write custom detection rules in response to threat intelligence, incident findings, and TTPs relevant to the organization's threat profile. Sigma rules provide a platform-agnostic detection format that can be maintained in version control and converted to platform-specific query languages.

SOAR for tier-1 automation: The highest-value SOAR automation at Level 3 is not sophisticated -- it is automating the mechanical steps tier-1 analysts perform on every alert: enriching an IP address with VirusTotal and Shodan, looking up a hash in MalwareBazaar, checking whether a user has had previous incidents, and creating a case ticket. These 5-10 minute manual steps per alert, automated, free analyst capacity for investigation rather than enrichment.

Threat hunting: Level 3 SOCs run structured threat hunts: hypothesis-driven searches for attacker TTPs that have not generated alerts. Start with hypotheses derived from MITRE ATT&CK -- pick the top-5 techniques used by threat actors relevant to your industry and build hunts to test whether evidence of those techniques exists in your log data. A hunt that finds nothing is still valuable: it confirms you have visibility into that technique.

The defining characteristic of Level 4: The SOC produces and consumes threat intelligence, uses it to drive detection rule development, and continuously measures detection coverage against the MITRE ATT&CK framework.

Cyber threat intelligence integration: At Level 3, threat intel consumption is passive -- analysts read reports and occasionally add IOC feeds to the SIEM. At Level 4, CTI is integrated into the detection engineering workflow. Intelligence analysts (or analysts wearing both hats) translate finished intelligence reports into detection rule requirements: "APT41 is using this specific Cobalt Strike configuration; we need a detection rule for this beacon pattern." The TIP (Threat Intelligence Platform) feeds IOCs directly into SIEM watchlists and SOAR enrichment playbooks.

ATT&CK coverage measurement: Use the MITRE ATT&CK Navigator to map your current detection rules against ATT&CK techniques. This visualization immediately reveals coverage gaps -- techniques for which you have no detection -- and guides prioritization of new rule development. A Level 4 SOC reviews this coverage map monthly and sets quarterly targets for coverage improvement.

Metrics that signal Level 4 maturity:

• Detection rule coverage rate by ATT&CK tactic (measure and improve monthly)
• False positive rate per rule (tune rules with FP rate above 5%)
• MTTD for confirmed incidents by severity tier
• Hunt-to-detection conversion rate (percentage of threat hunts that produce a new detection rule)
• Mean time from threat intelligence publication to detection rule deployment

Post-incident review (PIR) as a continuous improvement driver: Every significant incident should produce a PIR within 5 business days. The PIR must answer: how was the attacker present before detection? What log source or rule would have detected them earlier? What changes to detection coverage or process would have reduced MTTD? These findings feed directly back into the detection rule backlog.

Use this assessment to identify your current maturity level across the three dimensions.

People dimension:

• Do you have 24x7 shift coverage, or are there gaps in monitoring coverage (nights, weekends)?
• Is there a defined career path for SOC analysts (Tier 1 to Tier 2 to Tier 3)?
• Do analysts have documented role-specific training plans?
• What is your analyst-to-alert ratio? (More than 20 alerts per analyst per shift at Tier 1 is a signal of alert fatigue)
• Is institutional knowledge documented in runbooks, or does it reside in specific individuals?

Process dimension:

• Do you have documented runbooks for your top-20 alert types?
• Is there a defined SLA for P1, P2, P3 incident response (target: P1 15 min initial response, P2 2 hours, P3 8 hours)?
• Do you run post-incident reviews after every major incident?
• Is there a formal process for promoting a hunt finding into a permanent detection rule?
• Do you track detection coverage against a framework (ATT&CK or equivalent)?

Technology dimension:

• Which log sources are ingested into your SIEM? (Score by coverage against the priority list)
• Do you have EDR deployed on what percentage of endpoints? (Target: 95%+)
• Do you have SOAR, and what percentage of tier-1 alert handling is automated?
• Do you have NDR or network-layer visibility?
• Do you have a threat intelligence platform (TIP) with feeds integrated into SIEM watchlists?

Scoring: Score each question 0-2 (0 = not in place, 1 = partially in place, 2 = fully in place). Total scores by dimension and by maturity level grouping to identify your weakest areas and highest-priority improvements.