What Should a Board Expect from a Modern SOC Provider?

1. Introduction — Cyber Security Is Now a Board-Level Concern

There was a time when the board's involvement in cyber security extended no further than approving the annual IT budget and hoping the firewall was switched on. That era is over. The regulatory landscape — from the UK's NIS2 transposition and the FCA's operational resilience framework to the SEC's cyber disclosure rules in the United States — now places personal accountability on directors for the adequacy of their organisation's cyber defences. Insurers are tightening underwriting criteria, demanding evidence of continuous monitoring and incident response capability. Shareholders and clients are asking harder questions about breach preparedness. The message is clear: cyber security is no longer an IT problem. It is a fiduciary responsibility.

For the majority of organisations, maintaining an in-house Security Operations Centre (SOC) is neither practical nor cost-effective. The skills shortage alone makes it prohibitive — staffing a 24/7 SOC with qualified analysts, detection engineers, and threat hunters requires a minimum of ten to twelve specialists, with salary costs easily exceeding £1 million per year before tooling, licensing, and infrastructure. This reality has driven widespread adoption of managed SOC services, where a third-party provider delivers continuous monitoring, detection, and response on behalf of the organisation.

But outsourcing the SOC does not mean outsourcing the accountability. The board remains responsible for ensuring that the provider delivers meaningful security outcomes — not just dashboards and alerts, but genuine risk reduction. This article sets out the ten areas every board should scrutinise when evaluating, selecting, or reviewing a modern SOC provider.

2. Detection That Goes Beyond Signature Matching

The first and most fundamental question the board should ask is: what does your SOC provider actually detect? Many legacy managed security service providers (MSSPs) operate on a model that is little more than log aggregation and signature-based alerting. They ingest your logs, compare them against known indicators of compromise (IOCs), and raise an alert when something matches. This approach has been insufficient for years. Modern adversaries use fileless malware, living-off-the-land binaries (LOLBins), identity-based attacks, and legitimate credentials to move through environments without triggering traditional signatures.

A modern SOC provider should demonstrate detection engineering capabilities — the ability to write, test, tune, and maintain custom detection rules tailored to your specific environment, threat profile, and technology stack. Detection rules should be mapped to the MITRE ATT&CK framework to provide structured coverage visibility, and the provider should be able to show you, concretely, which tactics and techniques they detect across your estate and where gaps remain.

Beyond rule-based detection, the board should expect behavioural analytics and anomaly detection. This means the SOC platform is learning what normal looks like in your environment — normal authentication patterns, normal network flows, normal process execution — and flagging deviations that may indicate compromise. When combined with threat intelligence and adversary emulation insights from regular <a href="https://www.hedgehogsecurity.co.uk/penetration-testing">penetration testing</a>, these behavioural models become significantly more effective, because they are informed by real-world attack paths relevant to your organisation.

3. Proactive Threat Hunting, Not Passive Monitoring

There is a critical distinction between monitoring and hunting, and the board must understand it. Monitoring is reactive — the SOC waits for an alert and then investigates. Hunting is proactive — the SOC forms hypotheses about potential compromises and actively searches for evidence of adversary presence, even when no alert has fired. This distinction matters because the most dangerous intrusions are precisely the ones that evade automated detection. Advanced persistent threats (APTs), insider threats, and supply chain compromises routinely bypass signature-based and even behavioural detection for weeks or months.

The board should expect their SOC provider to conduct regular, structured threat hunts — not as an optional add-on sold at premium rates, but as an integral component of the service. Hunts should be intelligence-led, drawing on threat intelligence relevant to the organisation's sector and geography, and they should be documented with clear findings and recommendations. A provider that only monitors and never hunts is delivering an incomplete service.

Threat hunting should also feed back into detection engineering. Every hunt that identifies a previously undetected technique should result in a new or refined detection rule, creating a virtuous cycle where the SOC continuously improves its ability to catch threats automatically. This is the hallmark of a mature SOC operation.

4. Transparent, Board-Ready Reporting

Boards do not need — and should not tolerate — reporting that consists of raw alert volumes, pie charts of severity distribution, or tables of CVE identifiers. These metrics are operationally useful for the security team, but they tell the board nothing about actual risk posture. A modern SOC provider should deliver board-level reporting that translates security operations into business risk language.

Effective board reporting from a SOC provider should address several key questions. What is our current mean time to detect (MTTD) and mean time to respond (MTTR), and how do these compare to the previous quarter and to industry benchmarks? What are the most significant threats we have faced in the reporting period, and how were they handled? Are there any gaps in our detection coverage, and what is the plan to close them? Has there been any change to our threat landscape — new adversary groups targeting our sector, new vulnerabilities in our technology stack, or new regulatory requirements? What is the provider's assessment of our overall security posture, and what are their top three recommendations for improvement?

The board should insist on regular reporting cadences — monthly operational summaries, quarterly strategic reviews, and ad hoc incident briefings — and should have a named point of contact at the SOC provider who can attend board meetings or audit committee sessions when required. If a provider is reluctant to present to the board, that tells you something important about their confidence in their own service.

5. Measurable Outcomes and Service Level Commitments

The SOC market is plagued by vague promises — "24/7 monitoring," "advanced threat detection," "rapid response" — that sound reassuring but mean nothing without measurable commitments behind them. The board should demand concrete, contractually binding service level agreements (SLAs) that define exactly what the provider commits to deliver.

At a minimum, the board should expect SLAs covering the following: time to initial triage (how quickly a new alert is acknowledged and assessed by an analyst), time to escalation (how quickly a confirmed incident is communicated to your internal team), time to containment action (how quickly the SOC can execute a containment measure such as isolating a host or disabling an account), coverage hours and analyst-to-client ratios, uptime guarantees for the SIEM platform and associated tooling, and defined breach notification timescales that align with regulatory obligations under GDPR, NIS2, or sector-specific frameworks.

Critically, these SLAs should be backed by transparent measurement. The provider should be able to demonstrate, at any time, their performance against these commitments — not through self-reported metrics, but through auditable platform data that the client can independently verify. A provider who hides behind opaque reporting is a provider the board should question.

6. Integration with Your Security Ecosystem

No SOC provider operates in isolation. The value of a managed SOC is amplified when it integrates seamlessly with the organisation's broader security ecosystem — endpoint detection and response (EDR), identity and access management (IAM), cloud security posture management (CSPM), email security, network detection and response (NDR), and vulnerability management. The board should understand how the SOC provider ingests telemetry from these sources, how it correlates events across them, and what happens when the SOC identifies a threat that requires action in a system it does not directly manage.

A modern SOC should provide broad visibility across endpoint, network, identity, and cloud — not just whichever data source happens to be easiest to ingest. The provider should be technology-agnostic, capable of working with the tools your organisation already uses rather than mandating a wholesale replacement of your security stack. This is particularly important for organisations with hybrid or multi-cloud environments, operational technology (OT) estates, or legacy systems that generate non-standard log formats.

The board should also ask about the relationship between the SOC provider and the organisation's offensive security programme. Insights from <a href="https://www.hedgehogsecurity.co.uk/penetration-testing">penetration testing</a> engagements — whether external infrastructure assessments, web application tests, or red team exercises — should feed directly into SOC detection tuning. If your penetration testers identified a path from an exposed VPN to domain admin, the SOC should have detections in place for every step of that kill chain. The best SOC providers actively consume offensive security findings to improve their defensive posture.

7. Threat Intelligence That Is Relevant and Actionable

Threat intelligence is one of the most misunderstood and misused capabilities in managed security. Many providers claim to deliver "threat intelligence" when what they actually provide is a raw feed of indicators — IP addresses, domain names, file hashes — ingested into the SIEM with no context, no prioritisation, and no relevance to the client's specific threat profile. This is not intelligence; it is noise.

The board should expect threat intelligence that is tailored to the organisation's sector, geography, technology stack, and threat profile. If you are a UK financial services firm, you need intelligence on threat actors targeting UK financial services — not a generic global feed dominated by commodity malware campaigns against unrelated sectors. The intelligence should be delivered at three levels: strategic (trends and threat landscape assessments for the board), operational (campaign-level analysis for the security team), and tactical (specific indicators and detection signatures for the SOC platform).

Intelligence should also be integrated into every aspect of the SOC workflow — informing detection rules, guiding threat hunts, enriching alert triage, and shaping incident response priorities. A SOC provider that treats threat intelligence as a separate product rather than an embedded capability is falling short of modern expectations.

8. Incident Response Readiness and Coordination

Detection without response is merely expensive observation. The board must understand what happens after the SOC detects a genuine threat. Does the provider have the authority and the technical capability to take containment actions — isolating endpoints, blocking malicious IP addresses, disabling compromised accounts — or does it simply raise a ticket and wait for your internal team to act? The answer to this question has a direct impact on how quickly a breach is contained and how much damage is sustained.

A modern SOC provider should offer a tiered response model. For clearly malicious, high-confidence detections — such as confirmed ransomware execution or active credential theft — the provider should have pre-authorised response playbooks that allow immediate containment without waiting for client approval. For ambiguous or lower-confidence detections, the provider should have clear escalation procedures with defined timescales, ensuring that no alert sits uninvestigated during critical windows.

The board should also confirm that the SOC provider's incident response capabilities extend beyond the initial containment. Can the provider support forensic investigation? Can it coordinate with legal counsel, regulatory bodies, and law enforcement if required? Does it conduct post-incident reviews and implement lessons learned? Organisations that maintain baseline security hygiene — ideally verified through <a href="https://www.hedgehogsecurity.co.uk/cyber-essentials">Cyber Essentials</a> or <a href="https://www.hedgehogsecurity.co.uk/cyber-essentials">Cyber Essentials Plus</a> certification — are significantly better positioned to benefit from SOC response actions, because the foundational controls are already in place.

9. Compliance Alignment and Regulatory Support

Boards operate within a compliance context, and the SOC provider must understand and support that context. Whether the organisation is subject to GDPR, PCI DSS, FCA regulations, NIS2, DORA, the UK Government's Cyber Assessment Framework, or sector-specific requirements such as the IASME Cyber Assurance standard, the SOC provider should be able to demonstrate how its service maps to the relevant control requirements.

This goes beyond simply claiming compliance. The provider should be able to produce evidence — log retention policies that meet regulatory timescales, detection coverage mapped to mandated security controls, incident response procedures aligned with breach notification requirements, and audit-ready reports that satisfy assessors. For organisations pursuing or maintaining <a href="https://www.hedgehogsecurity.co.uk/cyber-essentials">Cyber Essentials</a> certification, the SOC should complement and reinforce the baseline controls by monitoring for precisely the threats those controls are designed to mitigate — malware, phishing, unauthorised access, and misconfiguration exploitation.

The board should also ask about the SOC provider's own compliance posture. Is the provider itself ISO 27001 certified? Does it hold SOC 2 Type II attestation? Is it CREST-accredited for its testing and response capabilities? These credentials provide assurance that the provider operates to the same standards it is helping you achieve.

10. The Role of Automation and Artificial Intelligence

Artificial intelligence and automation are now central to effective SOC operations, but the board should approach vendor claims with healthy scepticism. The phrase "AI-powered" has become so ubiquitous in security marketing that it has lost almost all meaning. The board should ask specific questions: what exactly does the AI do? Does it assist with alert triage, reducing the volume of false positives that analysts must review? Does it perform behavioural baselining to detect anomalies? Does it automate response actions for high-confidence detections? Or is "AI" simply a marketing label applied to basic log correlation rules?

Effective AI in a SOC environment should demonstrably reduce mean time to detection, improve alert fidelity, and allow human analysts to focus on the complex investigations that require human judgement — threat hunting, adversary analysis, and strategic decision-making. The best implementations use multiple AI models working collaboratively, each specialised in a different domain — endpoint behaviour, network traffic patterns, identity anomalies, and cloud activity — to cross-validate findings and reduce false positives.

Critically, the board should understand that AI augments human analysts; it does not replace them. An AI-only SOC with no human oversight is a recipe for missed detections and automated mistakes. The board should ask about the provider's analyst-to-client ratio, the qualifications and experience of the human team, and the governance framework that ensures human review of AI-driven decisions before critical actions are taken.

11. Visibility, Access, and Trust

One of the most common frustrations boards express with managed SOC providers is a lack of visibility. The organisation is paying significant fees for a service it cannot see, cannot audit, and cannot independently verify. This creates a trust deficit that is corrosive to the relationship and dangerous to the organisation's security posture.

The board should expect full transparency from the SOC provider. This means access to the SIEM platform and dashboards — not a sanitised, read-only portal, but genuine visibility into what the SOC is seeing, how alerts are being triaged, and what actions are being taken. It means access to detection rule logic, so your internal security team can understand what is being detected and what is not. It means access to raw log data, so you retain ownership of your own telemetry and are not locked in to a provider who holds your data hostage.

The board should also understand data sovereignty and retention. Where is your data stored? Who has access to it? How long is it retained? Can you export it if you change provider? These are not merely technical questions — they have regulatory, legal, and commercial implications that the board must govern. A SOC provider that operates as a black box, providing alerts but withholding the underlying data and logic, is not a partner. It is a vendor, and a risky one at that.

12. Offensive Security Integration — Closing the Loop

The most effective security programmes treat offensive and defensive security as two halves of the same whole. Penetration testing reveals vulnerabilities and attack paths; the SOC monitors for exploitation of those same vulnerabilities and paths. Red team exercises test whether the SOC can detect and respond to realistic adversary behaviour; the results drive improvements to detection rules and response playbooks. This feedback loop is essential, and the board should expect their SOC provider to actively participate in it.

Organisations that invest in regular <a href="https://www.hedgehogsecurity.co.uk/penetration-testing">penetration testing</a> — covering external infrastructure, internal networks, web applications, cloud configurations, and social engineering — generate a wealth of intelligence about their own weaknesses. A modern SOC provider should consume these findings, update its detections accordingly, and validate that the remediated vulnerabilities are no longer exploitable. This creates a measurable, demonstrable improvement cycle that the board can track over time.

Similarly, the insights generated by the SOC — the most commonly observed attack techniques, the most frequently targeted assets, the most persistent threat actors — should inform the scope and focus of future penetration tests. When offensive and defensive functions operate in silos, both are less effective. When they are integrated, the organisation's security posture improves with every engagement.

13. Cost, Value, and the Business Case

The board is responsible for ensuring that the organisation receives value from its security investments. A managed SOC is a significant recurring cost, and the board should understand exactly what it is paying for and what outcomes it can expect. Pricing models vary widely across the market — some providers charge per device, per user, per gigabyte of ingested data, or per alert; others offer flat-rate pricing that simplifies budgeting and eliminates the perverse incentive to ingest less data (and therefore see less) in order to control costs.

The board should favour pricing models that are transparent, predictable, and aligned with security outcomes rather than data volumes. A flat-rate or tiered model that encourages comprehensive data ingestion is inherently safer than a per-gigabyte model that penalises visibility. The board should also consider the total cost of ownership — not just the SOC provider's fees, but the internal staff time required to manage the relationship, the cost of tooling that feeds the SOC, and the opportunity cost of gaps in coverage.

Fundamentally, the business case for a managed SOC rests on a simple proposition: the cost of the service is a fraction of the cost of a breach. The average UK data breach now costs in excess of £3 million when factoring in direct incident costs, regulatory fines, legal fees, lost business, and reputational damage. A well-run SOC that detects and contains a breach in hours rather than months can reduce that cost by 70% or more. This is the value the board should measure — not the number of alerts processed, but the risk reduced and the damage avoided.

14. Ten Questions Every Board Should Ask Their SOC Provider

15. Conclusion — Governance, Not Abdication

Outsourcing the SOC is a sound strategic decision for most organisations. The economics of scale, the access to specialist talent, and the benefit of shared threat intelligence across a broad client base all favour the managed model. But outsourcing the operation does not outsource the governance. The board retains responsibility for ensuring that the provider delivers genuine security outcomes — detection that catches real threats, response that contains real incidents, intelligence that informs real decisions, and reporting that enables real oversight.

The questions in this article are not designed to catch providers out. They are designed to elevate the conversation from technical feature lists to strategic security outcomes. A strong SOC provider will welcome these questions, because they demonstrate that the board understands the value of what is being delivered and is engaged in the governance process. A provider that deflects, obfuscates, or struggles to answer should prompt serious reflection on whether the organisation's security is in the right hands.

Organisations that combine a modern, intelligence-led SOC with a robust baseline security posture — validated through programmes such as <a href="https://www.hedgehogsecurity.co.uk/cyber-essentials">Cyber Essentials</a> — and an ongoing offensive security programme of regular <a href="https://www.hedgehogsecurity.co.uk/penetration-testing">penetration testing</a> are best positioned to detect, contain, and recover from cyber attacks. The board's role is to ensure these elements are in place, that they are integrated, and that they are delivering measurable results. That is not abdication. That is governance.

Author: Peter Bassill, Founder — Hedgehog Security & UK Cyber Defence Ltd. Published 17 February 2026.