Security·12 min read

The Security Operations Maturity Model: From First Security Hire to Intelligence-Led Detection

The five levels of security operations maturity, from naming a first security owner to intelligence-led detection, with timelines and milestones for each.

Vladimir Sofroniev

October 28, 2026

In this article

Organizations often invest in detection tooling before they build detection capability. This is often done through the deployment of agents, trialing a SIEM and signing with an MSSP. Then the first real incident reveals that the response lacks true ownership, logs and events were never ingested and there are gaps in coverage.

This guide sets a high level roadmap of how to improve the maturity of your security operations function. Starting with assigning an accountable owner, creating a written view of the threats that affect your organization, assigning a 24/7 provider to improve alerting, documenting and testing a response plan, identifying the logs and events left behind by relevant threats, and building detections to alert and respond.

What is security operations maturity?

Security operations maturity measures how well a team detects, investigates and responds to threats, not how many tools it owns, and a SOC maturity model maps that progress in five levels.

What matters is whether the right alerts reach the right people, detections fire on the threats that matter, and a named owner has the authority to respond.

Each capability depends on the others. You can’t choose which logs matter without knowing your threats, an MDR provider can’t escalate without an owner who can act, and detections won’t fire on logs you never collected. But trying to finish each layer across your whole environment before starting the next is how teams end up with an expensive SIEM and few working detections. It works better to build a few threats end to end, then repeat.

What are the five levels of security operations maturity?

Most organizations sit at Level 1 or 2, and Level 4 is a realistic target for most mid-market businesses.

Level	Name	Defining capability	Who owns detection	What you can credibly claim
1	Unowned	Default tool settings, alerts are not ingested effectively	None. Engineering reacts when something breaks	“We’re most likely to learn of a breach from a customer, a regulator or an extortion email.”
2	Owned and Monitored	A named security lead, a threat profile, and a 24/7 MDR or MSSP	Security lead, with the provider triaging	“Alerts are investigated, following the sun, and ownership contains the necessary authority to perform.”
3	Instrumented	Each priority scenario's telemetry reaches the SOC parsed, protected and monitored	Security lead and provider	“We would see the activity behind our priority scenarios.”
4	Threat Focused	Tested detections and playbooks for every priority scenario, maintained as code	Detection engineering, in-house or co-managed	“We would likely detect our threat profile's intrusion paths within hours. We have tested it.”
5	Intelligence Led	Continuous threat profile refresh, hunting, and findings that feed guardrails	A detection and response function	“Our coverage keeps pace with relevant adversaries.”

Detection maturity shortens the time to find and contain an intrusion. Without prevention and a smaller attack surface, it does not independently lower risk. Aim for the level that matches your threat profile, regulatory and customer obligations and expectations.

For a mid-market estate, reaching Level 4 typically takes two to three years: about 6 to 9 months to Level 2, a further 6 to 12 months to Level 3, and 9 to 12 months more to Level 4. Level 5 is ongoing. Recruiting a strong lead can take months on its own, and log onboarding often stalls on access approvals.

Working in Threat-Scenario Layers

A threat scenario is a plain-language story of how an adversary would attempt to target your organization. Deliver five from your threat profile end to end, with the telemetry, detections, response playbook, and a tabletop or emulation exercise that proves they work together. Then record what you can reliably claim and start the next five, typically one layer per quarter.

Example first slice for a mid-market SMB

Scenario	Telemetry needed	Detections	Response playbook
Stolen CI/CD token used against production	Source control and CI/CD audit logs, cloud control plane	Pipeline credential used from outside the CI runners, workflow or deploy key changed without code review	Revoke and rotate the token, review recent deployments and IAM changes
Engineer’s credentials stolen by an infostealer	Identity provider sign-ins, EDR on engineer laptops, cloud control plane	Infostealer alert on a laptop, sign-in from a new device followed by privileged cloud role use	Isolate the laptop, revoke sessions, rotate every credential stored on it
Compromised third-party integration token	Corporate SaaS audit logs, OAuth grant and API events	Integration running bulk queries or exports far above its normal volume, or from new IPs	Revoke the integration’s tokens, scope the data, search it for secrets and rotate them
Customer account takeover in your product	Product authentication and account-change logs, WAF	Credential stuffing, MFA or email change followed by an export or new API key	Lock the account, revoke sessions and keys, notify the customer
Support staff viewing customer data without a ticket	Support and admin tool audit logs, ticketing system	Customer data opened with no linked ticket, views across many tenants	Suspend the access, review what was viewed, involve legal

Stage 1: Hiring Your First Security Lead and Creating the Threat Profile

The first maturity step is a person, not a product. Without a named owner, MDR alerts will not be triaged, log sources could fail silently, and threat prioritisation is poor or missing.

The security lead owns the roadmap, is your provider's single escalation point, and owns containment decisions such as disabling an executive's account. Hire at a level that carries that authority, with a direct line to leadership on material risk.

Look for someone who has built a program, not only run one, with:

Hands-on incident response experience, to judge a provider's work and lead real incidents.
Experience holding security providers to SLAs.
The ability to explain technical risk in business terms.

Full-time, fractional or virtual? A fractional or virtual CISO can cover strategy and governance, but only if someone internal owns day-to-day escalations. A leader available two days a week cannot be your 2 a.m. contact.

In the first 90 days, the lead, in collaboration with your fractional/vCISO, should create a brief document detailing organization relevant threats, drawing on NCSC and CISA advisories, sector ISAC reporting, your MDR provider's reports and incidents in your industry. It should answer:

Which threat actors target your sector, region and technology stack, and how are they getting in?
Which of your internet-facing systems and SaaS integrations are being exploited elsewhere?
What would a serious incident look like for you: data theft, extortion, fraud or outage?

Turn the answers into five priority scenarios and acquire leadership buy in, with an escalation path and a funded roadmap of quarterly deliverables.

Milestone: this stage is complete when a named person with authority to act owns detection and response, has written a threat profile, and reports to leadership regularly.

Stage 2: Selecting and Integrating an MDR or MSSP

For most organizations below enterprise scale, an MDR or MSSP is the fastest route to 24/7 coverage. Staffing one analyst seat around the clock takes roughly five full-time people. Providers use the labels loosely, so judge the service, not the name.

	MDR	MSSP
Core focus	Threat detection, investigation and active response	Broad management of security tools and devices
Typical telemetry	Endpoint first, often extending to identity, email and cloud	Firewalls, SIEM, vulnerability scanning and other managed tools
Response	Takes containment actions, such as isolating hosts or disabling accounts	Often alerts and escalates, leaving response to you

Ask every shortlisted provider to demonstrate:

Scenario coverage: which of your priority scenarios they detect, demonstrated rather than assumed, and whether they will build custom detections.
Telemetry scope: which sources they ingest, and the cost of adding identity, email, cloud and SaaS.
Response authority: what they contain alone, what needs your approval, and how fast they can respond.
Data ownership and protection: who owns the logs and how you get them back. As a subprocessor of personal data, the provider needs a data processing agreement and due diligence, which can add months.
Automation and AI: how much triage is automated or AI-assisted, and how you can audit it.

Many MDR disappointments trace back to accelerated onboarding. You should look to budget weeks for a context handover (crown-jewel systems, privileged accounts, approved admin tools), a clear and tested escalation matrix, pre-approved actions so the provider can isolate a laptop at 3 a.m., and a baselining period to tune out noise. Write down who owns what between you and the provider, so neither assumes the other is handling it.

Milestone: you reach Level 2 when a provider watches around the clock, can contain threats within agreed limits, and escalates to a named owner through a tested path.

Stage 3: Building Response Readiness

The hardest parts during a high severity incident are rarely technical: deciding fast, preserving evidence and communicating to the right people on time. You should look to build this stage alongside MDR onboarding, not after it.

Name an incident commander and a deputy, plus owners for technical response, legal and communications, and keep the plan short. Agree an incident response retainer before you need it, confirm whether your MDR service stops at containment, and check what your cyber insurer requires.

Decide in advance what evidence you will need: retention long enough to reconstruct an intrusion, an immutable copy, synchronized clocks, and a way to capture memory and disk images. Cloud instances can be terminated quickly, so automate evidence capture at the moment of detection.

Map notification deadlines before an incident starts them. Under UK and EU GDPR, a reportable personal data breach must reach the regulator within 72 hours. NIS2 requires in-scope organizations to send an early warning within 24 hours, and customer contracts are often shorter still. Pre-approve holding statements, and agree to an out-of-band channel in case email or chat is compromised.

Run tabletop exercises for your priority scenarios at least once a year, with legal and communications in the room, and time how long the notification decision takes.

Milestone: this stage is complete when you have a tested plan with named roles, an IR retainer, retrievable evidence, pre-approved communications and mapped notification deadlines.

Stage 4: Building a Log Ingestion Pipeline

Your MDR provider and detections only see what you send them, and many attacks never touch an endpoint, abusing stolen credentials, cloud environments and SaaS applications instead. Onboard the events each scenario needs first, and leave the rest until an identified scenario calls for it.

Typical log source priorities for a corporate IT estate

Priority	Log sources	What they reveal
1	Identity provider sign-ins and admin actions, cloud control plane, organization-wide, delivered to a separate locked-down log account, source control and CI/CD audit logs, EDR on engineer and admin laptops, your product’s authentication, admin and support-tool logs	Stolen engineer and pipeline credentials, privilege escalation, unauthorized infrastructure changes, customer account takeover, insider access to customer data
2	Kubernetes audit and container runtime, secrets manager and key management access, access events on customer data stores, corporate SaaS audit logs and OAuth grants; email	Compromised workloads, secret theft, bulk access to customer data, malicious integrations, phishing
3	VPC flow logs, DNS, WAF and CDN	Exfiltration paths, command-and-control traffic, API abuse at the edge

A mature pipeline keeps five steps separate, so each can change independently. Consider collecting logs with agents, syslog and API connectors. To allow for consistent logging and alerting, normalize them into one schema, such as OCSF or ECS. To increase the value of your log events, look to enrich them with asset, user and threat intelligence context. To reduce the cost of storage and volume costs, high-value events should be routed to real-time detection and bulk data to cheaper storage. Retain each source as long as investigations and regulations require.

There are several scenarios you should consider beyond the basics:

An expired API token or a changed service account password can blind you for weeks. Alert on volume drops, parsing errors and ingestion delays.
Attackers disable cloud audit logging (MITRE ATT&CK T1562.008), so keep an immutable copy in a separate, locked-down account.
Decide per source whether it needs real-time detection, searchable history or a cold archive, and filter noise before it reaches expensive storage. At cloud scale, consider a security data lake you own.

Milestone: you reach Level 3 when every priority scenario's telemetry arrives parsed and enriched, an immutable copy exists, and health monitoring flags any gap.

Stage 5: Creating Threat Detection Use Cases

A detection use case answers one question: how would we know this specific threat is happening here, and what would we do? Vendor defaults are written for everyone, so they miss what matters to you and trigger behavior that is normal for you.

Document every use case the same way, adapting a structure such as Palantir's ADS framework or MaGMa:

Field	Example
Name and threat	UC-014: forwarding to an external domain (business email compromise)
ATT&CK mapping	T1114.003 Email Forwarding Rule
Data and logic	Microsoft 365 audit log: new inbox rule forwarding outside approved domains
Known false positives	Approved forwarding to an outsourced finance provider
Severity and response	High: confirm with the user, remove the rule, reset credentials
Test and owner	Scripted rule creation in a test tenant; security lead, quarterly

Treat detections like software: identify the threat, confirm the data exists, build the rule as code, test it with a purple team exercise, then deploy, tune and eventually sunset it.

Start from your priority scenarios, such as novel sign-ins to privileged accounts, new forwarding rules, privilege escalation, disabled security tools and bulk SaaS downloads, and build where your MDR provider's coverage is thin. If you sell software, some key detections live inside your own product, and only your team can build them.

Twenty tested rules beat a hundred noisy ones, and ATT&CK heatmaps are easily gamed: one detection for T1078 (Valid Accounts) does not cover all its procedures. Report which named scenarios you can detect end to end.

Milestone: you reach Level 4 when every priority scenario has tested, owned detections and playbooks, managed as code and reviewed on schedule.

Stage 6: Running Intelligence-Led Operations

This stage turns the threat profile into a continuous capability, revisited every quarter as threat actors and the business change.

Indicators such as IP addresses and file hashes go stale fast, while techniques are hard for attackers to change. Use indicators for enrichment, and spend engineering effort on detecting behaviors.

Turn intelligence into detections:

Refresh the profile from your MDR provider, ISACs, government advisories and ATT&CK group pages.
Map priority actors' TTPs to ATT&CK, starting with the techniques several actors share.
Compare them with your tested detections. Each gap is missing logging, a missing detection or a missing guardrail.
Where a policy can block a behavior outright, block it and alert on denied attempts.
Close the remaining gaps through the pipeline and the use case lifecycle.
Record which intelligence produced which detection.

Base hunts on intelligence-driven hypotheses. A hunt that finds malicious activity becomes an incident, and one that finds a reliable pattern becomes a use case. Hunting can sit in-house, with your provider or be co-managed, as long as the owner is clear. Rather than only detecting someone disabling cloud audit logging, deny it across the organization and alert on the attempt. For every finding, ask whether it should become a detection, or whether a control could prevent it.

Milestone: you reach Level 5 when every new detection or guardrail traces back to intelligence, an incident or a test, and hunting regularly produces new detections.

How do you measure security operations maturity?

The right metrics change as you climb: early levels measure speed of response, and later levels measure the quality of detection.

Metric	What it shows	Relevant from
Median and p90 time to detect and contain	How fast threats were found and stopped, p90 exposes the long tail	Level 2
Escalation acknowledgement time	How fast your owner responds to provider escalations	Level 2
Scenario telemetry coverage	Share of priority scenarios whose logs are ingested and healthy	Level 3
Log source outages	How often, and for how long, sources go silent	Level 3
Tested scenario coverage	Share of priority scenarios detected end to end in tests	Level 4
Detection latency in exercises	Time from an emulated attack to an alert	Level 4

Time to detect only measures the incidents you found, so pair it with detection latency from exercises, where you know what should have fired. Report on a fixed schedule, and avoid vanity metrics such as alert volume or rule count.

Conclusion

Security operations maturity is built around the threats you face and delivered in slices. Appoint an owner, write the threat profile, deliver five scenarios end to end, record what you can credibly claim, and repeat. If you want an objective baseline, a structured security operations maturity assessment is the practical place to begin.

In this article