The Autonomous Cyber Defence Maturity Model

Why a maturity model at all

'Modernising the SOC' means very different things to different budget-holders. A CFO hears 'reduce tooling spend.' A CISO hears 'reduce breach risk.' A SOC manager hears 'reduce analyst burnout and attrition.' Without a shared model, roadmap discussions collapse into feature lists and vendor claims that are impossible to compare.

This model describes five operational levels, each defined by who or what makes decisions, how fast those decisions are made, and what guardrails constrain them. It deliberately avoids vendor-specific capabilities so it can be applied to any stack, including one built entirely on Spharaka's Sphere™ platform or one assembled from point products.

The five levels are: L0 Manual SOC, L1 Assisted, L2 Augmented, L3 Autonomous within a policy envelope, and L4 Self-Directed and Adaptive. Most enterprise SOCs today sit between L1 and L2. Few have reached L3 in a defensible, auditable way. L4 remains a target state that requires governance maturity as much as technical maturity.

L0: Manual SOC

Alerts land in a queue and are picked up in arrival order. Analysts triage using SIEM search, endpoint console pivots, and tribal knowledge built up over years on shift. Playbooks exist mainly as documents in a wiki, if they exist at all. Response quality depends heavily on which analyst is on shift and how long they have worked at the organisation.

The analyst role at L0 is generalist and reactive. Every escalation is a fresh investigation, with little reuse of prior reasoning. Institutional knowledge lives in people's heads, so attrition directly erodes detection and response quality.

MTTI and MTTR are both dominated by human search time. Mean time to detect is commonly measured in hours to days, and mean time to respond in days. Tooling is typically a SIEM with limited correlation and no orchestration layer. The main risk is inconsistency: two identical incidents can produce two very different outcomes depending on who handled them, and there is no reliable way to demonstrate coverage to an auditor or regulator.

L1: Assisted (AI copilots on SIEM/SOAR)

The SOC has SOAR in place with standard playbooks for common alert types, and enrichment (threat intel lookups, asset context, user risk scores) is automated. AI copilots and chat assistants layer on top of the SIEM and SOAR to summarise alerts, draft investigation notes, and suggest next steps. Analysts still make every decision, but the mechanical work of gathering context has been delegated.

The analyst role shifts from data-gathering to interpretation. Analysts spend most of their time reading copilot summaries and enrichment output, then deciding what it means and what to do next. This is real progress over L0, but the decision bottleneck has simply moved one step downstream.

MTTI improves noticeably because enrichment is instant rather than manual. MTTR improves more modestly, because the analyst is still the rate-limiting step for judgment calls. Tooling implications include a SIEM, a SOAR platform, a threat intel feed, and a copilot layer, usually three to four separate vendor relationships. The main risk is copilot over-trust: analysts start accepting AI-generated summaries without verifying them, which quietly reintroduces the inconsistency problem from L0 in a new form.

L2: Augmented (AI-driven triage and investigation)

At L2, AI does more than summarise; it actively triages and investigates. Alerts are automatically correlated into candidate incidents, prioritised by likely impact, and pre-investigated with a draft narrative, supporting evidence, and a recommended disposition. Analysts review and approve rather than build the case from scratch.

The analyst role becomes reviewer and approver for the majority of volume, with deep manual investigation reserved for genuinely novel or high-stakes cases. This is the level where analyst headcount stops scaling linearly with alert volume, and where burnout from repetitive triage starts to decline measurably.

MTTI drops to minutes for well-understood incident types, since correlation and prioritisation happen continuously rather than in a human queue. MTTR drops correspondingly for the same population, though genuinely novel incidents still take as long as they did at L1. Tooling implications include a detection and response platform capable of automated correlation, an investigation engine that produces evidence-backed narratives, and case management that tracks approval rather than raw ticket status. The dominant risk at L2 is false confidence in AI-drafted narratives: if approval becomes rubber-stamping, the SOC has effectively moved decision-making to an unaudited system while still claiming human oversight.

• This is where Spharaka SAGE™ operates as the cybersecurity-native inference layer producing evidence-backed investigation narratives.
• AuraXP™ begins to take on triage and prioritisation reasoning above the raw detection layer.
• Human review remains mandatory for every disposition; nothing executes without approval.

L3: Autonomous within a policy envelope (Sphere target state)

L3 is where a defined class of incidents is handled end-to-end by an AI agent operating inside an explicit policy envelope, without a human approving each step. The envelope specifies which incident types, which actions, which blast-radius limits, and which conditions automatically escalate to a human. A confirmed commodity phishing case, for example, can be contained, credentials reset, and the case closed autonomously, with a human notified after the fact rather than gating the action.

The analyst role moves decisively toward policy design, oversight, and exception handling. Analysts spend their time defining and refining the envelope, reviewing a sample of autonomous closures for drift, and handling the cases the agent correctly escalates because they fall outside its authorised scope. This is a materially different job than triage, and it requires different hiring and training than L0 or L1 SOCs.

MTTI and MTTR for in-envelope incident types drop to the minutes-or-less range, limited mainly by the time needed for containment actions to take effect rather than by decision latency. Tooling implications are significant: this level requires a governance layer that can enforce, log, and prove the boundaries of the envelope, not just a more capable model. This is the role Spharaka's AirWatch™ plays, constraining what agents are authorised to do and producing an auditable record of every autonomous action. The primary risk at L3 is envelope scope creep: expanding autonomous authority faster than the evidence justifies, or without updating the governance controls to match.

L4: Self-Directed and Adaptive (governed continuous learning)

L4 extends L3 with continuous, evidence-driven learning: the system adjusts its own detection logic, prioritisation, and response playbooks based on observed outcomes, still within governance guardrails that are themselves subject to review and approval. Where L3 executes a fixed envelope well, L4 proposes changes to the envelope itself, backed by evidence, for human ratification.

The analyst role at L4 is closer to a model risk and governance function than a traditional SOC role. Analysts, alongside detection engineers and risk owners, review proposed policy changes, validate that learning has not introduced drift or bias, and retain authority to freeze or roll back adaptive behaviour. Nothing at L4 should be able to expand its own authority without that authority being explicitly granted through a governed change process.

MTTI and MTTR at L4 continue to improve over time for known incident classes, and importantly, the envelope of what counts as a 'known' incident class also expands over time as the system learns from adjudicated cases. Tooling implications include model monitoring, drift detection, and a formal change-approval workflow for policy updates, in addition to everything required at L3. The dominant risk at L4 is governance debt: an organisation claims adaptive autonomy without having built the oversight processes to safely allow it. Very few organisations should attempt L4 before they have run L3 stably, with a clean audit trail, for a meaningful period.

Measuring maturity in practice

Rate your SOC across five dimensions independently rather than assigning a single overall level, because most organisations are uneven. Detection, triage, investigation, response, and learning each progress at different rates, and the model is more useful as a diagnostic than as a scoreboard.

For each dimension, track leading indicators rather than just outcome metrics. Outcome metrics like MTTI and MTTR tell you what happened; leading indicators tell you why. Useful leading indicators include the percentage of incident volume handled without human intervention, the percentage of autonomous dispositions sampled and validated as correct, the rate of envelope escalations that were correctly triggered versus missed, and the age of the most recently reviewed policy envelope.

• Detection: signature-based → behaviour-based → agent-driven hunting
• Triage: manual queue → enriched queue → AI-prioritised → autonomous disposition
• Investigation: analyst-led → copilot-assisted → AI-drafted with review → agent-led with sampled audit
• Response: ticketed → playbook-driven → agent-orchestrated within envelope → self-adjusting envelope
• Learning: post-incident review only → detection engineering backlog → continuous evidence-driven refinement under governance

Common anti-patterns

The most common failure mode is skipping levels. Deploying an autonomous reasoning layer without solid playbook infrastructure underneath it produces confident reasoning with nothing reliable to execute against. Deploying more playbooks without a reasoning layer above them produces content debt: dozens of narrow automations that nobody maintains and that miss anything slightly novel.

A second anti-pattern is measuring automation coverage instead of outcome quality. A SOC that automates 70 percent of case volume but has never sampled those closures for correctness has a false sense of maturity. Maturity is not how much is automated; it is how confidently you can prove that automation is correct.

A third anti-pattern is treating governance as a one-time gate rather than a continuous control. Organisations that write a policy envelope once and never revisit it accumulate risk silently as the environment changes around a static set of rules. Governance at L3 and L4 has to be reviewed on the same cadence as the threat landscape it is meant to constrain.

Where Sphere, SAGE, AuraXP, and AirWatch map to this model

Spharaka's platform components are built to move an organisation from L1 through L4 without a rip-and-replace at each step. SAGE™ is the cybersecurity-native inference layer that powers evidence-backed investigation at L2, producing the narratives and correlated evidence that let analysts move from data-gathering to review. AuraXP™ is the reasoning layer that sits above SAGE, handling prioritisation and decisioning at L2 and executing autonomously within a defined scope at L3.

AirWatch™ is the governance layer that makes L3 and L4 defensible rather than reckless. It enforces the policy envelope, logs every autonomous action with the evidence that justified it, and provides the audit trail that lets a CISO demonstrate to a board or regulator exactly what the system was authorised to do and why it did it. Sphere™ is the platform that brings these components together as a coherent target state, designed specifically for organisations planning a deliberate move from L2 toward governed L3 and, eventually, L4 operation.

Organisations evaluating this model against their own environment should start by rating each of the five dimensions honestly, then identify the single dimension with the largest gap between current state and business need. That gap, not a generic 'go autonomous' mandate, is where the next investment should go.