The average enterprise SOC now consumes between £3m and £8m per year in staff, tooling, and managed service fees. In most cases, it delivers alert volumes no human team can meaningfully process, coverage gaps that wouldn't survive a serious audit, and a board report that describes busyness rather than security posture.

This isn't a people problem. It's an engineering problem.

The real drivers of SOC cost

SOC budgets balloon for a predictable set of reasons. Tool sprawl — where each threat category has its own platform, its own console, its own alert queue — creates integration debt that consumes analyst time just to manage. SIEM licensing scales with data volume, which means every new data source is another cost centre. And the headcount model — hiring analysts to review alerts — is a treadmill: more alerts means more analysts, which means more cost, with no ceiling in sight.

The result is a function that is both expensive and fragile. Remove three analysts and detection capability drops significantly. That is not a mature operating model.

The automation gap

The most underutilised lever in most SOC environments is automation. SOAR platforms have existed for years, but implementation tends to be shallow — a handful of enrichment playbooks and some basic ticketing integration, rather than genuine reduction in analyst workload. The reason is almost always the same: automation was bolted on after the fact, rather than engineered in from the start.

A well-engineered SOAR deployment can automate 40–70% of tier-1 alert handling. Not by replacing analyst judgement on complex incidents, but by eliminating the repetitive enrichment, triage and false-positive suppression work that consumes the majority of analyst time. The analysts that remain work on harder problems, stay engaged longer, and cost less to retain.

Detection as code

Most organisations manage their detection logic the same way they managed infrastructure in 2012 — manually, inconsistently, and with no version control. Detection rules are created by individuals, stored in SIEM UIs, and drift over time as the environment changes. There is no peer review. There is no testing. There is no audit trail.

Detection as code — managing SIEM rules, correlation logic and response playbooks in a version-controlled repository with CI/CD pipelines, automated testing and change approval gates — transforms the detection engineering function. It enables teams to ship more detection, retire stale rules confidently, and evidence coverage to auditors without manual effort.

The economics are significant. Teams that have implemented detection as code consistently report 30–50% reductions in the time spent managing detection logic, with measurably better coverage quality.

AI-assisted triage: where it actually helps

Large language models are beginning to deliver genuine value in tier-1 triage — not as autonomous decision-makers, but as enrichment engines. An LLM-assisted triage workflow can summarise alert context, pull relevant threat intelligence, cross-reference recent incidents, and produce a prioritised recommendation in seconds. The analyst reviews and decides; the model does the legwork.

This is not the same as vendor AI features that promise to "automatically resolve" alerts. Those claims should be treated with deep scepticism. The value of LLMs in the SOC today is in accelerating human decision-making, not replacing it.

What a leaner SOC actually looks like

The pattern that works is: consolidate data into a well-governed SIEM or XDR platform; engineer automation for the high-volume, low-complexity alert categories; implement detection as code so that coverage is managed with the same rigour as infrastructure; and deploy AI-assisted enrichment to accelerate the analyst workflows that cannot be automated.

The result, typically, is a smaller team doing substantially better work — with measurable coverage, evidenced detection, and a cost trajectory that doesn't automatically increase as the threat landscape evolves.

Security functions that operate as gatekeepers — the team that says no, the team that slows releases, the team that sends compliance questionnaires and then disappears — are eroding their own influence. They are technically present in the organisation but strategically irrelevant. Business units route around them.

The Security Front Door is a model for changing that. It reframes the security function not as a checkpoint but as a structured service — one that the business can consume, understand, and hold to account.

What's actually broken

The symptoms are familiar. Engineering teams embed security as an afterthought because engaging the security function takes too long and produces inconsistent results. Product teams launch without a security review because the review process is opaque and the timeline unpredictable. The board receives a status update that tells them nothing about actual risk.

These aren't attitude problems. They're structural problems. The security function hasn't defined how it wants to be engaged. It hasn't published what it offers, at what SLA, for what types of request. It operates reactively, on a queue that nobody manages, with no visibility into demand.

The Front Door model

The Security Front Door is a single structured channel through which all demand enters the security function. It provides three things that most security functions lack: a defined intake process, risk-based triage against published SLAs, and a service catalogue that the rest of the organisation can actually read.

Intake means that every request — whether it's a third-party risk assessment, a new cloud workload, a product security review, or an incident — enters through the same channel, gets logged, gets categorised, and gets a response within a defined timeframe. No more ad hoc Slack messages to the CISO. No more requests that fall through the gap between two team members.

Triage means that high-risk requests get prioritised over low-risk ones. Not based on who shouted loudest, but based on a consistent framework that everyone understands. A new payment processing system gets a faster security review than an internal wiki page. That should be obvious — but in most organisations it isn't.

The service catalogue means that the business knows what to ask for. Instead of "we need security to look at this", teams can say "we need a threat model for this API" or "we need a third-party security review for this vendor" — because those services are defined, scoped, and priced in terms of time and resource.

SLAs as accountability infrastructure

SLAs are not just a service management tool. They are the mechanism through which the security function becomes accountable to the business rather than merely present in it. When a team submits a security review request and receives a response within the published SLA, they learn that engaging security is predictable. When they see that SLA performance is reported to leadership, they understand that security takes it seriously.

Start with realistic SLAs — it is better to consistently meet a 10-day SLA than to miss a 5-day one. Track adherence visibly. Report breaches honestly. Over time, tighten the SLAs as the function matures.

Business partnering as a forcing function

The highest-maturity version of the Security Front Door includes dedicated business partners — security leads who are embedded in or closely aligned with major business units. Their role is not to do security work for those units, but to surface demand early, translate business risk into security requirements, and ensure that the security function understands the commercial context it is operating in.

Business partnering changes the dynamic from reactive to proactive. Instead of being called in when something has already gone wrong, the security function has advance visibility of what is being planned — and can influence it before it becomes a problem.

Measuring the function

A security function that cannot measure itself cannot improve itself. The metrics that matter for the Front Door model are: SLA adherence by request type; demand volume and trend by business unit; time to close by category; and the ratio of proactive to reactive work. These metrics tell you whether the function is growing in maturity or just keeping up with demand.

Board reporting should translate these operational metrics into risk language: coverage, posture trend, key risks accepted and managed. The board does not need to understand detection logic. They do need to understand whether the organisation's security risk is moving in the right direction.

Shift left has been the dominant principle in application security for the better part of a decade. The idea is correct: finding security problems early in the development lifecycle is cheaper and faster than finding them in production. The problem is that most organisations have implemented the slogan without the substance.

They have added a SAST scanner to the CI pipeline. They have run an OWASP training module for developers. They have a "security champion" programme with a Slack channel and occasional lunch-and-learns. And then they are surprised when a penetration test reveals that the application still has critical vulnerabilities, the scanner findings are being suppressed to meet release deadlines, and the development team cannot articulate what a threat model is.

The difference between "shift left" and engineering security in

Shift left as typically implemented is additive. You take the existing development process and add security checks at earlier stages. The process itself does not change. Security is still something that happens to the code, rather than something that is part of how the code is written.

Engineering security into the SDLC is structural. It means that security requirements are defined before a line of code is written, as part of the same process that defines functional requirements. It means that threat models are a standard part of design review, not an optional extra. It means that security controls — input validation, authentication, authorisation, cryptography — are implemented as reusable, tested library components rather than bespoke code written differently in every service.

The distinction matters because it determines whether security scales with the engineering organisation or becomes a bottleneck as the organisation grows.

Policy as code: the enforcement layer

The most powerful mechanism for embedding security in the SDLC at scale is policy as code — expressing security requirements as machine-enforceable rules that run automatically in the CI/CD pipeline.

Using frameworks like Open Policy Agent (OPA) with Rego, or HashiCorp Sentinel for infrastructure, organisations can encode rules such as "no container image may be deployed that has a critical CVE with a public exploit", or "all public-facing APIs must have authentication configured", or "production secrets may not be stored in environment variables". These rules are checked automatically on every code commit. A developer cannot accidentally bypass them by forgetting to run a manual check.

The organisational benefit goes beyond prevention. Policy as code creates an auditable record of what was checked, when, against what standard, and what the result was. For regulated organisations — financial services, healthcare, telecoms — this evidence is directly relevant to compliance obligations.

Threat modelling as engineering practice

Threat modelling is frequently treated as a heavyweight, compliance-driven activity: a workshop that happens once, produces a document, and is then forgotten. This is a waste of everyone's time. It produces documents that are outdated within weeks and creates the impression that security has been "done" for a given system.

Threat modelling as an engineering practice is lightweight, continuous, and integrated into design review. It asks three questions for every significant change: what are we building, what can go wrong, and what are we doing about it. This doesn't require a full-day workshop. It can be a 30-minute review of a design document with a security engineer in the room.

The output is not a lengthy report — it is a set of security requirements for the feature being built, captured in the same ticket system as functional requirements, addressed in the same sprint, and verified in the same test cycle.

Secure by default: the architectural principle

The most durable security improvement an engineering organisation can make is to design its systems so that the secure behaviour is the default behaviour — and the insecure behaviour requires deliberate effort to achieve.

This means providing a centralised authentication library that developers use rather than implementing authentication themselves. It means providing a secrets management platform (Vault, AWS Secrets Manager) so that storing a secret in code requires active extra steps. It means designing your default container configuration to run as non-root, with a read-only filesystem, with network policies in place — so that a developer who wants to run as root has to explicitly override the default.

Secure by default shifts the burden from "developers must remember to do the secure thing" to "the secure thing is what happens unless a developer actively chooses otherwise". That is a fundamental improvement in the security properties of the system, at any scale.

Measuring SDLC security maturity

The OWASP Software Assurance Maturity Model (SAMM) provides a structured framework for assessing and improving SDLC security across five business functions: governance, design, implementation, verification, and operations. A SAMM assessment gives you a baseline — not to compare yourself to a benchmark, but to identify the areas where engineering effort will have the most security impact.

The metrics that matter are: mean time from vulnerability discovery to remediation, by severity; percentage of services with a current threat model; SAST finding suppression rate (high suppression rates indicate scanner fatigue, not good security); and percentage of deployments that pass all policy gates on the first attempt. These tell you whether the programme is working, or just running.

Every security vendor in 2026 has an AI narrative. The press releases are identical: autonomous threat detection, AI-powered response, machine learning that catches what humans miss. Some of these claims are real. Most are not. This article is an attempt to be precise about which is which — and to give security leaders a practical framework for evaluating and deploying AI capabilities in their operations centre.

A taxonomy of AI in security

There are three meaningfully distinct categories of AI being deployed in security operations today, and conflating them leads to both missed opportunities and avoidable risks.

The first is classical machine learning: anomaly detection, user and entity behaviour analytics (UEBA), network traffic analysis. This technology is mature, well-understood, and genuinely useful when properly tuned. It has been in production in enterprise environments for a decade. The marketing has recently been refreshed with AI branding, but the underlying technology is not new.

The second is large language models applied to security tasks: alert summarisation, threat intelligence synthesis, detection engineering assistance, incident report drafting. This is genuinely new, genuinely useful in specific contexts, and significantly over-claimed in others. We will spend most of this article here.

The third is agentic AI: systems that can take sequences of actions autonomously in response to detected threats. This is early-stage, high-risk in production environments, and not something most organisations should be deploying unsupervised in 2026. We will explain why.

Where LLMs actually help

The use cases where large language models provide genuine, measurable value in security operations today are narrower than the vendor literature suggests — but they are real.

Alert enrichment and summarisation is the strongest use case. An LLM can ingest a SIEM alert, pull context from threat intelligence feeds, review recent related alerts, check asset criticality, and produce a concise summary with a confidence-rated priority recommendation — in seconds. The analyst reviews and decides. The LLM does the legwork. In high-volume SOCs, this can reduce tier-1 triage time by 40–60% per alert without reducing analyst oversight of decisions.

Detection engineering assistance is the second strong use case. LLMs are remarkably capable at helping analysts write, review, and improve detection logic — translating a threat intelligence report into a set of candidate SIEM rules, explaining what a complex query does, identifying gaps in coverage. This accelerates skilled work rather than replacing it.

Incident report drafting is lower-stakes but genuinely time-saving. Incident documentation is high-value and chronically under-resourced. An LLM that can draft a structured incident report from a timeline of analyst notes — which a human then reviews and refines — meaningfully reduces the administrative burden on senior responders.

Where LLMs don't help (yet)

Autonomous threat detection is frequently marketed as an LLM capability. In practice, LLMs are poor at the statistical pattern recognition that effective anomaly detection requires. Classical ML approaches — properly trained on your specific environment — significantly outperform LLMs at identifying anomalous behaviour in log and network data. Do not replace a well-tuned UEBA with an LLM.

Autonomous response — where the AI takes action on your network without human approval — is genuinely dangerous in most enterprise environments. The failure mode is not just false positives (which are bad enough when the response is isolating a production server). The failure mode is an attacker who has understood your AI's decision logic and can trigger specific responses to assist their objectives. Human-in-the-loop should be non-negotiable for any action that modifies your environment.

The AI governance question you're not asking

Most security leaders evaluating AI tools are asking: "does this work?" They are not asking: "what data is this model trained on, who has access to the data I'm sending to it, what happens when the model is wrong in a way that creates liability, and how do I evidence that I have appropriate human oversight of automated decisions?"

These are not theoretical questions. They are becoming regulatory requirements. The EU AI Act classifies certain AI systems used in critical infrastructure — including security — as high-risk, with specific obligations around transparency, human oversight, and incident reporting. The UK's AI regulatory framework is evolving in the same direction. Organisations that deploy AI in their SOC without governance frameworks will find themselves facing compliance questions they are not prepared to answer.

AI governance for SOC deployments should address: data classification and handling for data sent to AI systems; human oversight requirements by action type; audit logging of AI-assisted decisions; model performance monitoring and drift detection; and a process for reviewing and challenging AI recommendations.

A practical deployment roadmap

For organisations that want to deploy AI in their SOC in 2026, the sequence that works is: start with LLM-assisted alert enrichment on a defined subset of alert types, with full analyst visibility into what the model recommended and why; measure the impact on triage time and false positive rate; establish your AI governance framework before expanding scope; then move to detection engineering assistance once the team is comfortable with the model's capabilities and limitations.

Agentic response should come last, if at all — and only for low-risk, well-defined, reversible actions with full audit logging and a human review process for anything that has gone to automated response more than N times.

The organisations that will get the most value from AI in the SOC are not those who deploy it fastest. They are those who deploy it most deliberately — with clear use cases, measurable outcomes, and governance frameworks that protect them when things go wrong.