A security operations center matures from reading alerts when someone has time, to a measured service that detects, responds and improves. This five level model is our own self assessment rubric, not a standard. Use the checks under each level to find where you are and what to do next.
Level 0: Ad hoc
Logs exist in separate places. Someone checks them after an incident. There is no on call, no written process and no list of what is monitored.
Check: if a laptop is stolen tonight, who finds out and when?
Next step: pick a log destination, list critical systems, and name one person responsible for security alerts.
Level 1: Collecting
Key logs flow to one place. NIST SP 800-92 describes the base work: planning log generation, storage and review. A few alerts exist for obvious events like repeated failed logins. Reviews happen on a schedule, but only in business hours.
Check: can you list which systems send logs, and which do not?
Next step: write a source inventory, set retention by purpose, and add alerts for the five events you fear most.
Level 2: Responding
Alerts have owners and a written response rule. Analysts can isolate a host or disable an account. Incidents are logged with a timeline. Coverage hours match risk, even if that is business hours plus an on call phone.
Check: time a test alert from firing to action. Do you know the number?
Next step: practice, record times, and write short playbooks for the top five incident types. NIST SP 800-61 Rev. 3 is a good outline for what response work involves.
Level 3: Managed
Detections are tuned on a schedule. Rules have owners, tests and retirement dates. Alert volume per analyst is tracked. Threat information feeds detections, using sources like CISA's Known Exploited Vulnerabilities catalog for patching and hunting priorities. The SOC and vulnerability management teams share asset data.
Check: can you show which detection rules fired in the last quarter and which never did?
Next step: retire dead rules, measure false positives, and run a tabletop exercise each quarter.
Level 4: Measured and proactive
The SOC hunts for threats using hypotheses, not only alerts. Metrics are reported to leadership: time to detect, time to contain, coverage of critical assets, share of alerts that were real. Lessons from incidents change controls outside the SOC, such as pipeline policies and access rules. Routine response steps are automated with approvals for risky ones.
Check: did the last incident produce a change in prevention, not only a closed ticket?
Next step: pick two measures to improve each quarter and test automation in safe areas first.
Level 5: Adaptive
Detection engineering works like software engineering: code review, tests, versioning and continuous delivery of rules. The SOC and engineering teams share a backlog, and fixes flow in both directions. Exercises include attacks that cross cloud, identity, endpoint and application layers.
Check: how long from a new technique being reported to a tested detection in production?
Next step: invest in people development and keep the program honest with outside testing.
How do you use it?
Score six areas separately: log coverage, detection quality, response speed, people and shifts, tooling and data, and learning. Most teams are uneven. A team with strong tooling and no response rule is Level 1 in the area that matters.
Beware of skipping levels. Buying advanced tools at Level 1 produces alerts nobody can act on.
Where does application security feed the SOC?
Prevention reduces alert load. Safeguard focuses on the application and software supply chain side, with policies and gates at build, CI and release and reachability analysis for findings. It does not replace SOC tooling or staff.
What do people get wrong when using a maturity model?
They chase the level instead of the outcome. A level is only a label for a set of habits, and the habits matter because they shorten the time between an attacker's first move and your action. If a level 3 practice does not improve that time for your business, skip it for now. They also self score generously. Ask someone outside the team to check each score against evidence such as tickets, logs and test results. An honest Level 1 with a plan beats a claimed Level 3 that fails its first test.
What to do
- Score the six areas from 0 to 5 with evidence.
- Pick the lowest area and one change for 30 days.
- Time a test alert and record it.
- Write playbooks for the top five incident types.
- Review detection rules quarterly and retire dead ones.
- Re-score every six months.
Quick check
Is this model a standard?
No. It is our own rubric for self assessment, so adjust levels and checks to your organization.
What is the most useful single measure?
Time from alert to action on a test event. It exposes gaps in ownership, access and process in one number.
Sources
- NIST SP 800-92, Guide to Computer Security Log Management
- NIST SP 800-61 Rev. 3
- CISA Known Exploited Vulnerabilities Catalog
Last reviewed: 18 October 2026.
