SOC Modernisation: Executive Briefing for Boards

Security operations budgets are being consumed by the cost of storing and searching log data, while boards are told that automation and AI will make the security operations centre (SOC) faster and cheaper without being shown how the results will be measured or controlled. This briefing is for board members, chief executives, finance directors and risk committees who approve SOC investment or a SOC transformation programme. It explains where SOC money actually goes, the decisions that drive data cost, how to judge automation and AI proposals, how to choose between in-house, outsourced and hybrid models, and the metrics and questions that tell directors whether the SOC is getting better. It is vendor neutral and stays at board level; the operating detail is in the SOC Guide.

The risk in one paragraph

A SOC exists to detect and respond to attacks that get past preventive controls and, in the UK NCSC's words, to limit the damage to the organisation. It depends on three things: the right data, people with the skills to use it, and processes that turn alerts into decisions quickly. Each is under strain. Most security information and event management (SIEM) products are priced on the volume of data ingested, so visibility and cost rise together. Skilled analysts are scarce and the work is stressful. Automation and AI promise relief, but badly configured automation can disrupt the business, and AI assistants bring new failure modes of their own. The board's job is to make sure modernisation buys measurable detection and response capability, not just new tools or lower bills, and that the risks of automating decisions are understood and controlled.

Why this is a board-level issue now

Data cost is now the biggest swing factor: executive guidance on SIEM and SOAR implementation published in 2025 by the Australian Signals Directorate's ACSC with CISA and partners notes that most SIEM pricing depends on ingested log volume, that teams add sources over time and costs rise, and that some products do not cap ingestion, so unmanaged ingestion can lead to very large costs.
Regulators and governments expect long log retention: US federal agencies, for example, must keep many log types for 12 months in active storage and 18 months in cold storage under OMB memorandum M-21-31 (27 August 2021). Retention requirements multiply storage costs and shape architecture choices.
AI is being sold into the SOC: suppliers now offer AI assistants for alert triage, investigation summaries and query writing, and increasingly AI agents that take actions. These can raise analyst productivity, but they also introduce risks the OWASP Top 10 for LLM Applications 2025 describes, such as prompt injection (LLM01) and excessive agency (LLM06).
Directors are expected to oversee resources and metrics: the UK Cyber Governance Code of Practice (8 April 2025) asks boards to confirm resources are allocated effectively (principle B) and to require formal reporting at least quarterly against agreed metrics and tolerances (principle E). SOC spend and performance are a natural fit.
The cost of not investing is real: the same executive guidance warns that missed detections can lead to outages, data loss and loss of public confidence. Cutting SOC data or staff to save money can quietly remove the capability that would have caught an intrusion.

Where SOC money goes

The 2025 executive guidance groups total cost into licensing and data use, specialist staff, training, and outsourced service fees. Directors should see the budget split the same way, with the main cost drivers named.

Cost area	What drives it	Levers to control it
Data ingestion and licensing	Volume of logs ingested, number of sources, pricing model and caps	Prioritise sources by threat value; filter and tier data; negotiate caps and predictable pricing
Storage and retention	How long data is kept and in which tier, driven by legal and regulatory needs	Keep recent data searchable and older data in cheaper archive tiers; set retention by data type
People	Hours of coverage (24/7 or business hours), skills mix, attrition	Right-size coverage to risk; automate repetitive triage; invest in retention and training
Training	Pace of change in tools and threats	Treat as recurring spend, not a one-off project cost
Outsourced services	Scope, hours, number of sources monitored, response actions included	Define scope and response authority clearly; measure provider outcomes, not activity
Detection engineering	Number and quality of detections, testing effort	Fund it explicitly; it is what turns data into findings

The data decisions that drive cost

The cheapest log is the one that is not collected, but the most expensive is the one that would have revealed an intrusion and was dropped. The board does not need to choose log sources. It needs to see that management chooses them by threat value rather than by price.

Prioritise by attack path: NCSC recommends using attack trees to decide which logs and information the SOC should receive. CISA and partners also publish practitioner guidance on priority logs for SIEM ingestion. Identity, endpoint, cloud control plane and email logs are usually among the highest value.
Separate storage from analysis: many organisations now keep raw security data in lower-cost storage, such as a security data lake, and send only high-value data to the SIEM for real-time detection. This lowers cost but adds engineering work and can slow investigations if older data is hard to search. See the Security Data Lake Guide.
Retention is a legal decision as well as a cost one: retention periods should come from legal, regulatory and investigation needs, then be met as cheaply as possible, not shortened to fit the budget. See the Log Management and Retention Guide.
Know the pricing model: the 2025 executive guidance recommends comparing products carefully for hidden costs, especially ingestion pricing and caps. A migration to another SIEM is a large undertaking in its own right. See the SIEM Migration Guide.

Automation: what to automate and what to keep human

Security orchestration, automation and response (SOAR) tools run predefined playbooks, such as isolating an affected device. The 2025 executive guidance lists the benefits (faster response, staff freed for complex work) and the risk: a poorly configured SOAR may act against normal activity or obstruct human responders, disrupting services. It also stresses that SOAR depends on a well-functioning SIEM, so an accurate alerting SIEM should come first. See the SOAR and Security Automation Guide.

Automation level	Typical examples	Board-level control expected
Enrich and summarise (no action)	Gathering context on an alert, drafting a case summary	Low risk; measure accuracy and time saved
Recommend, human approves	Proposed containment steps that an analyst confirms	Approval recorded; measure how often recommendations are overridden
Act automatically on low-impact cases	Blocking a known malicious address, resetting a single user's session	Defined scope, tested playbooks, monitoring for false positives, quick rollback
Act automatically on high-impact cases	Isolating servers, disabling accounts at scale	Explicit risk acceptance by the business owner, strict limits and change control

AI in security operations: value and new risks

AI assistants can help analysts write queries, summarise investigations and triage alerts faster. AI agents go further and take actions with tools and credentials. Boards should support experimentation while asking for the same evidence they would expect of any control.

Measured value: pilots should compare triage time, accuracy and analyst workload against a baseline, not rely on supplier claims.
Manipulated inputs: logs, emails and tickets can contain attacker-written text. OWASP describes prompt injection (LLM01) as inputs that alter a model's behaviour in unintended ways, so an AI that reads attacker-controlled data must not be trusted to act on it without checks. See the Prompt Injection Guide.
Excessive agency: OWASP's LLM06 describes damage from an AI system given too much functionality, permission or autonomy. An AI agent with broad response rights should be governed like a highly privileged account. See the Agentic AI in the SOC Guide.
Data handling: security data is sensitive. Contracts should state where data is processed, whether it is used to train models and how long it is retained.
Governance: the NIST AI Risk Management Framework gives a common structure (Govern, Map, Measure, Manage) for assessing AI use, including in security tools. See the AI SOC Guide.

In-house, outsourced or hybrid

Model	Strengths	Watch for
In-house SOC	Deep knowledge of the business and network; can act directly on unusual behaviour	Cost and difficulty of hiring and retaining skilled staff; 24/7 coverage needs several full-time people
Outsourced (managed detection and response or managed SOC)	Access to skills and round-the-clock coverage at predictable cost	Visibility gaps, duplicated work, communication problems; data location and liability terms
Hybrid	In-house team owns context and decisions; provider covers out-of-hours monitoring and scale	Clear split of responsibilities and response authority; avoid gaps at the hand-off

The 2025 executive guidance notes that organisations handling sensitive information or providing critical services may need to keep it in house, and, where outsourcing, advises assessing the provider's 24/7 monitoring and response, security posture and data storage locations, with contracts covering how effectiveness and compliance are verified, the provider's skills, visibility and responsibility for incidents. See the MDR Guide.

Where identity fits

Stolen or misused credentials are a common route into organisations, and many credentials belong to service accounts, API keys and cloud workloads rather than people. A modern SOC needs identity telemetry, including non-human identity activity, among its highest-priority data. The SOC's own tooling is also a target: SIEM, SOAR and AI agents run with powerful integration credentials that should be inventoried, scoped and monitored. See the NHI Detection Engineering Guide.

Five questions for the board to ask

What does our SOC actually detect? Show coverage of the attack techniques that matter most to us, and the results of the last test of detection and response.
What drives our data cost? Show the pricing model, the top data sources by volume and by value, and the retention requirements we must meet.
What have we automated, and who approved it? List automated response actions, their scope, how they were tested and how quickly they can be reversed.
How are we using AI, and how do we know it works? Show the baseline, the measured results and the controls on what AI tools can see and do.
Who does what when an alert fires at 3am? Describe the hand-offs between staff, any provider and business owners, and the authority each has to act.

Red flags in management answers

Savings come from dropping log sources, with no analysis of what attacks would then go unseen.
Success is reported as alert counts or tickets closed, not detection coverage or response time.
AI benefits are quoted from supplier material, with no internal pilot results.
Automated actions can disable accounts or isolate systems with no business owner sign-off.
Nobody can say how long logs are kept or whether that meets legal and regulatory needs.
The outsourced provider's contract measures activity rather than outcomes.

What good looks like

Threat-led design: the SOC's scope, data and detections follow from the organisation's threats, assets and resources, as NCSC recommends.
Data managed as an asset: every major data source has a stated purpose, owner, cost and retention period.
Tested capability: detection and response are exercised regularly, and results drive improvements.
Bounded automation and AI: clear tiers of what runs automatically, what needs approval, and evidence that it works.
Outcome metrics: the board sees time to detect, time to respond and coverage trends at least quarterly.

Where to invest first

Data prioritisation: a review of log sources by threat value and cost, with retention set from legal needs.
Detection engineering: people and time to build, test and maintain high-quality detections. See the Detection Engineering Guide.
Accurate alerting before automation: tune the SIEM so alerts are trustworthy, then automate the well-understood, low-impact responses.
A controlled AI pilot: one or two use cases, a measured baseline, data handling terms and limits on actions.
People: sustained training and retention, which the 2025 executive guidance identifies as an ongoing cost to budget for.

Metrics to track

Metric	What it shows
Mean time to detect and mean time to respond, for confirmed incidents	Whether the SOC is getting faster where it matters
Detection coverage of priority attack techniques, tested	Whether data and detections match the threat
Cost per unit of data ingested and share of spend on top sources	Whether data cost is controlled and justified
Proportion of alerts that are true positives	Alert quality and analyst workload
Automated actions reversed or overridden (percentage)	Whether automation is accurate and safe
Analyst attrition and training hours	Whether the people side is sustainable

For benchmarks and definitions, see the SOC and Alert Statistics and the SOC Maturity Model.

A 90-day plan

Days 1 to 30: obtain a cost breakdown by data, people, training and services; list log sources by volume and value; confirm retention requirements with legal; record what the SOC is expected to detect.
Days 31 to 60: test detection and response against priority attack techniques; agree an automation policy with tiers and approval rules; select one or two AI use cases for a measured pilot with data handling terms.
Days 61 to 90: approve a modernisation roadmap that links each investment to a metric; renegotiate pricing or retention tiers where justified; set quarterly board reporting on the metrics above.

Common failure patterns

Cutting data to cut cost: high-value sources are dropped to meet a budget, and the next intrusion goes unseen.
Automating noise: SOAR is added on top of an untuned SIEM, so automated actions fire on false positives and disrupt the business.
Buying AI before defining the problem: AI features are licensed without a baseline, so nobody can tell whether they help.
Outsourcing accountability: a provider is hired but nobody internally owns decisions, context or the hand-off.
Treating the SOC as a project: the 2025 executive guidance is clear that SIEM and SOAR are not set-and-forget tools; programmes that stop funding tuning and training decay quickly.
Measuring activity: boards see ticket counts rather than detection and response outcomes, and problems surface only after an incident.

Practitioner checklist

Break SOC spend into data, people, training and services, and report it annually to the board.
Rank log sources by threat value and cost; document why each high-volume source is kept.
Set retention by data type from legal and regulatory requirements, using cheaper tiers for older data.
Tune SIEM alerting before adding automated response; test playbooks and rollback.
Adopt a written automation policy with tiers and business owner approval for high-impact actions.
Run AI pilots against a measured baseline and limit what AI tools can access and do.
Inventory and scope the integration credentials used by SIEM, SOAR and AI tools.
Test detection and response regularly and report outcome metrics at least quarterly.

Standards and references

How NHI Mgmt Group can help

We provide independent identity and non-human identity assessments and board briefings, including which identity and machine credential signals a SOC should prioritise and how to govern the credentials used by security automation and AI agents. Our NHI Foundation Level Training Course includes a section on agentic AI. Contact us to arrange a briefing.

Related NHI Mgmt Group resources: SOC Guide · SIEM Guide · AI SOC Guide · Security Tool Consolidation Executive Briefing

SOC Modernisation Executive Briefing: Data Costs, Automation and AI in Security Operations