1. The Regulatory Convergence Facing UK and EU Organisations
For the first time, three major regulatory frameworks are simultaneously imposing specific, measurable requirements on how organisations detect, respond to, and report cyber incidents. The Financial Conduct Authority's Policy Statement PS21/3, which became fully enforceable on 31 March 2025, requires FCA-regulated firms to identify their important business services, set impact tolerances, and demonstrate through scenario testing that they can remain within those tolerances — including during cyber attacks. The EU's Digital Operational Resilience Act (DORA), applicable since 17 January 2025, mandates comprehensive ICT risk management, incident reporting within strict timescales, regular resilience testing including threat-led penetration testing, and oversight of third-party ICT service providers for all financial entities operating within the EU. The NIS2 Directive, which EU member states were required to transpose by October 2024, extends cybersecurity obligations across eighteen critical sectors, with the UK's own Cyber Security and Resilience Bill — introduced to Parliament in November 2025 — set to mirror many of these requirements for UK-based organisations.
What connects these frameworks is a shared recognition that reactive security is insufficient. Each demands continuous monitoring, proactive threat detection, documented incident response, transparent reporting, and board-level governance of cyber risk. These are precisely the capabilities that a mature SOC as a Service engagement is designed to deliver. The question is no longer whether organisations need a SOC, but whether their SOC provider can demonstrably support compliance with each framework's specific requirements.
2. Understanding the Three Frameworks
Before examining how a SOC supports compliance, it is important to understand the distinct focus of each framework, because while they overlap significantly, each has specific requirements that the SOC must address.
- FCA PS21/3 — Operational Resilience: Applies to banks, building societies, insurers, payment institutions, electronic money institutions, enhanced scope SM&CR firms, and recognised investment exchanges. Requires identification of important business services (IBS), setting of impact tolerances for maximum tolerable disruption, mapping of resources and dependencies that support each IBS, scenario testing under severe but plausible conditions, remediation of vulnerabilities, and ongoing self-assessment reported to the governing body. The FCA expects operational resilience to be embedded in firm culture, not treated as a compliance exercise.
- DORA — Digital Operational Resilience Act: Applies to over twenty categories of EU financial entities including credit institutions, investment firms, insurance undertakings, payment institutions, and their critical ICT third-party service providers. Mandates an ICT risk management framework approved by the management body, incident classification and reporting (initial notification within four hours for major incidents, with intermediate and final reports), digital operational resilience testing including advanced threat-led penetration testing (TLPT) every three years for critical entities, a register of all ICT third-party arrangements, and information-sharing between entities.
- NIS2 — Network and Information Systems Directive 2: Applies to essential and important entities across eighteen sectors including energy, transport, health, digital infrastructure, financial market infrastructure, and managed service providers. Requires risk management measures covering incident handling, supply chain security, network security, access control, and encryption. Mandates incident reporting to the relevant CSIRT within 24 hours (early warning), 72 hours (incident notification with initial assessment), and a final report within one month. Imposes personal liability on senior management for cybersecurity failures, with fines of up to €10 million or 2% of global turnover for essential entities.
3. Continuous Monitoring — The Foundation of All Three Frameworks
Every one of these frameworks requires organisations to maintain continuous visibility over their ICT environment. The FCA's PS21/3 requires firms to monitor the operational resources that support their important business services, including technology, third-party dependencies, and people. DORA requires financial entities to implement ICT security monitoring tools and processes capable of detecting anomalous activities, including cyber threats, in a timely manner. NIS2 requires risk management measures that include continuous monitoring of network and information systems to detect incidents that could affect service delivery.
A managed SOC delivers this capability as its core function. The SOC ingests telemetry from across the organisation's environment — endpoints, servers, network infrastructure, cloud platforms, identity systems, email, and applications — and applies detection rules, behavioural analytics, and threat intelligence to identify potential threats in real time. For FCA-regulated firms, this means the SOC is continuously monitoring the systems that underpin important business services, providing the visibility needed to detect disruptions before they breach impact tolerances. For DORA-regulated entities, the SOC serves as the ICT security monitoring function mandated by Article 9, delivering the anomaly detection and threat identification that the framework requires. For NIS2-regulated entities, the SOC provides the continuous network and information system monitoring that underpins the directive's risk management obligations.
Critically, the monitoring must be genuinely continuous — 24 hours a day, 365 days a year. Regulatory frameworks do not acknowledge business hours, and attackers do not observe them. This is where a managed SOC provides particular value for organisations that cannot sustain round-the-clock internal coverage, which in practice means the overwhelming majority of firms below enterprise scale.
4. Incident Detection, Classification, and Reporting
The incident reporting requirements across these three frameworks are among the most operationally demanding obligations any organisation faces. Under DORA, major ICT-related incidents must be reported to the competent authority with an initial notification within four hours of classification, an intermediate report within 72 hours, and a final report within one month. Under NIS2, an early warning must be provided within 24 hours of becoming aware of a significant incident, an incident notification within 72 hours, and a final report within one month. Under PS21/3, the FCA and PRA have consulted on a framework (CP24/28 and CP17/24) requiring operational incident reporting for incidents meeting defined thresholds, including those that disrupt important business services.
Meeting these timescales requires two things that most organisations lack: the ability to detect incidents rapidly, and the structured processes to classify and report them within the mandated windows. A managed SOC addresses both. On the detection side, the SOC's continuous monitoring, detection engineering, and threat hunting capabilities reduce mean time to detection (MTTD), ensuring that incidents are identified in minutes or hours rather than days or weeks. On the reporting side, a mature SOC provider should have documented incident classification procedures that align with the specific taxonomies required by each framework — DORA's classification criteria (impact on clients, duration, geographical spread, data losses, criticality of services affected), NIS2's significance thresholds (severe operational disruption or considerable material damage), and the FCA's impact tolerance breach criteria.
The SOC should also produce the evidential artefacts needed for regulatory reporting — timeline reconstructions, root cause analysis, indicators of compromise, scope assessments, and containment evidence. Without a SOC generating these artefacts in real time during an incident, organisations will struggle to produce the detailed incident notifications that all three frameworks require within the mandated timescales.
5. Resilience Testing and the Offensive-Defensive Feedback Loop
All three frameworks mandate regular testing of an organisation's ability to withstand and recover from cyber disruptions. DORA is the most prescriptive, requiring basic testing at least annually (including vulnerability assessments, network security assessments, and scenario-based testing) and advanced threat-led penetration testing (TLPT) every three years for entities performing critical functions. NIS2 requires organisations to evaluate the effectiveness of their cybersecurity risk management measures through regular testing. PS21/3 requires scenario testing under severe but plausible conditions to demonstrate that firms can remain within impact tolerances for their important business services.
A managed SOC supports this obligation in two complementary ways. First, the SOC itself provides continuous, implicit testing through its daily detection and response operations — every alert investigated, every threat hunted, and every incident contained is a real-world test of the organisation's resilience posture. Second, and more importantly, the SOC should actively integrate with the organisation's formal testing programme. This means consuming findings from <a href="https://www.hedgehogsecurity.co.uk/penetration-testing">penetration testing</a> engagements and using them to create or refine detection rules. If penetration testers identify that an attacker could move from a compromised web application to internal databases via SQL injection and lateral movement, the SOC should have detections for every step of that path. If a red team exercise reveals that the SOC failed to detect a particular technique, that failure should drive immediate detection engineering improvements.
For DORA's TLPT requirements specifically, the SOC provider plays a dual role. During the test itself, the SOC should be operating normally — the test is designed to assess whether the SOC detects and responds to a realistic attack scenario. After the test, the SOC should be a primary consumer of the findings, incorporating every missed detection into its engineering backlog. Organisations that commission regular <a href="https://www.hedgehogsecurity.co.uk/penetration-testing">penetration testing</a> through CREST-accredited providers and feed those results directly into their SOC create the continuous improvement cycle that all three frameworks expect to see.
6. Third-Party Risk and the SOC Provider as an ICT Supplier
All three frameworks impose obligations around third-party risk management, and this creates an important duality: the SOC provider helps the organisation manage third-party risk (by monitoring for supply chain attacks, compromised credentials from third-party services, and anomalous third-party access), but the SOC provider is itself a third-party ICT service provider subject to oversight.
Under DORA, financial entities must maintain a register of all contractual arrangements with ICT third-party service providers, and the SOC provider must be included. The contract must address security requirements, incident reporting obligations, data access and recovery rights, audit rights, and exit strategies. The SOC provider may also be subject to the ESA's oversight framework if designated as a critical ICT third-party provider (CTPP), with potential fines of up to €5 million for non-compliance. Under NIS2, entities must implement security measures tailored to the vulnerabilities of their direct suppliers and assess the overall security posture of their supply chain — which includes their SOC provider. Under PS21/3, the FCA explicitly states that it is the firm's responsibility to remain within its impact tolerances, including where a third-party provider supports or delivers the relevant important business services.
This means the board should ask demanding questions about the SOC provider's own security posture, certifications, and compliance stance. Is the provider ISO 27001 certified? Does it hold SOC 2 Type II attestation? Is it CREST-accredited? Does it support audit access to its platform, processes, and controls? Can it produce evidence of its own business continuity and disaster recovery capabilities? A SOC provider that cannot answer these questions is a regulatory risk, not a compliance enabler.
7. Board-Level Governance and Regulatory Reporting
Each framework places explicit responsibility on senior leadership and governing bodies. Under DORA, the management body must approve and actively oversee the ICT risk management framework, including staying informed of ICT incidents and response activities. Under NIS2, senior management must oversee and approve cybersecurity risk management measures, undergo cybersecurity training, and can be held personally liable — including temporary bans from management roles — for failures to implement adequate measures. Under PS21/3, the board must receive self-assessments of the firm's operational resilience, including an overview of vulnerabilities found, scenarios tested, remediation plans, and the overall strategy for remaining within impact tolerances.
A managed SOC supports this governance requirement by providing structured, board-ready reporting that translates security operations into the language of regulatory compliance and business risk. Monthly reports should detail detection coverage, incident volumes and classifications, mean time to detect and respond, threat landscape changes relevant to the organisation's sector, and specific findings from threat hunting activities. Quarterly strategic reports should address MITRE ATT&CK coverage gaps, progress against remediation plans, third-party risk observations, and the SOC's assessment of the organisation's overall resilience posture.
For FCA-regulated firms, the SOC's reporting should specifically map to important business services, showing the board which services are being monitored, what threats have been detected against them, and whether any incidents have approached or breached impact tolerances. For DORA-regulated entities, the SOC should contribute to the management body's ICT risk reporting, including assessments of detection effectiveness and incident response performance. For NIS2-regulated entities, the SOC's reporting should support the senior management's oversight obligations by providing the evidence base for informed decision-making on cybersecurity investments and risk acceptance.
8. Log Retention, Evidence Preservation, and Audit Readiness
Regulatory compliance is fundamentally about evidence. It is not sufficient to detect threats and respond to incidents — the organisation must be able to demonstrate to regulators, after the fact, that it did so effectively, within the required timescales, and in accordance with documented procedures. This places specific requirements on the SOC's data management practices.
Under DORA, financial entities must maintain records of ICT-related incidents including timelines, classification decisions, response actions, and root cause analyses. Under NIS2, incident reports must include detailed descriptions of the incident, its severity and impact, indicators of compromise, and a description of countermeasures applied. Under PS21/3, firms must maintain records of their scenario testing, including outcomes and remediation actions, and be able to evidence their ongoing ability to remain within impact tolerances.
A managed SOC should provide long-term log retention that meets or exceeds the regulatory minimums — typically a minimum of twelve months of online, searchable data, with archival retention extending further as required by the specific framework. The SOC platform should produce immutable audit trails showing when alerts were generated, when they were acknowledged, what investigation steps were taken, what response actions were executed, and by whom. These artefacts are not optional extras — they are the evidence that regulators will request during supervisory reviews, and their absence is a compliance failure in its own right.
9. Mapping SOC Capabilities to Specific Regulatory Requirements
The following mapping illustrates how core SOC capabilities align with specific requirements across the three frameworks. Boards and compliance teams can use this as a reference when assessing whether their SOC provider delivers the coverage each framework demands.
10. The Baseline Foundation — Why Cyber Essentials Matters for Compliance
While the three frameworks discussed in this article impose advanced requirements, compliance does not begin at the SOC. It begins with baseline security controls that prevent the majority of commodity attacks and reduce the volume of incidents the SOC must handle. Organisations that have not secured their foundations will overwhelm their SOC with preventable alerts, degrade detection effectiveness through noise, and find themselves unable to meet the resilience expectations of any regulatory framework.
<a href="https://www.hedgehogsecurity.co.uk/cyber-essentials">Cyber Essentials</a> certification provides this foundation. The scheme's five technical controls — firewalls, secure configuration, user access control, malware protection, and patch management — directly address the attack vectors most commonly exploited by the threat actors that all three frameworks are designed to defend against. For FCA-regulated firms, Cyber Essentials provides evidence that baseline controls are in place to support the operational resilience of important business services. For DORA-regulated entities, the controls map directly to the ICT risk management framework requirements. For NIS2-regulated entities, they address several of the minimum baseline security measures mandated by Article 21.
<a href="https://www.hedgehogsecurity.co.uk/cyber-essentials">Cyber Essentials Plus</a> goes further, adding hands-on technical verification through testing conducted by an accredited assessor. This independent validation of baseline controls provides the evidence that regulators and auditors expect to see. When combined with a managed SOC for continuous monitoring and advanced threat detection, and regular <a href="https://www.hedgehogsecurity.co.uk/penetration-testing">penetration testing</a> for proactive vulnerability identification, the three layers create a comprehensive, auditable security programme that addresses the requirements of all three frameworks simultaneously.
11. Common Pitfalls — Where Organisations Fall Short
Having worked with organisations across financial services, critical infrastructure, and professional services sectors, several recurring compliance gaps stand out. Understanding these pitfalls can help boards and compliance teams focus their efforts where they matter most.
- Treating the SOC as a black box: Organisations that simply outsource monitoring without understanding what the SOC detects, how it classifies incidents, and how it reports findings will struggle to demonstrate the governance and oversight that all three frameworks require. The board must be able to articulate how the SOC supports their compliance obligations.
- Disconnected testing and monitoring: Organisations that commission penetration tests but do not feed the results into their SOC's detection engineering are wasting half the value of both investments. DORA's TLPT requirements explicitly expect that test findings drive improvements to detection and response capabilities.
- Inadequate incident classification: Using a single, generic severity scale for all incidents rather than mapping to framework-specific classification criteria (DORA's major incident thresholds, NIS2's significance criteria, PS21/3's impact tolerance breaches) creates reporting delays and regulatory exposure.
- Missing log retention: Organisations that discover, during a regulatory review, that their logs were only retained for 30 or 90 days face an irrecoverable evidence gap. Retention policies must be defined before an incident, not after.
- No exit strategy: DORA explicitly requires exit strategies for ICT third-party arrangements. If the SOC provider holds all detection rules, log data, and institutional knowledge, the organisation has created a concentration risk that the regulator will challenge.
12. What the Board Should Demand from Their SOC Provider
Bringing the requirements of all three frameworks together, the board should expect the following from a managed SOC provider that genuinely supports regulatory compliance.
- Documented regulatory mapping — the provider should demonstrate, in writing, how its service maps to the specific articles and requirements of each applicable framework.
- Incident classification aligned to regulatory thresholds — not generic severity ratings, but classification procedures that identify when an incident meets the reporting criteria under DORA, NIS2, or PS21/3.
- Reporting templates for regulatory notifications — pre-built templates aligned to each framework's reporting format, populated in real time during incidents, enabling the organisation to meet the 4-hour (DORA), 24-hour (NIS2), or PS21/3 notification windows.
- Board-level reporting aligned to governance obligations — structured reports that the board can use to demonstrate oversight of ICT risk (DORA), approval of cybersecurity measures (NIS2), and self-assessment of operational resilience (PS21/3).
- Integration with offensive security findings — a documented process for consuming penetration test findings and translating them into detection rules, with tracking to demonstrate continuous improvement.
- Transparent log retention and data ownership — clear contractual terms on retention periods, data export rights, and audit access that satisfy DORA's third-party oversight requirements and NIS2's evidence obligations.
- Own-security assurance — ISO 27001 certification, SOC 2 Type II attestation, CREST accreditation, and the willingness to be audited as a third-party ICT provider under DORA's oversight framework.
- Contractual exit provisions — documented exit strategies including data portability, knowledge transfer, and transition support that satisfy DORA's third-party management requirements.
13. The UK Cyber Security and Resilience Bill — What Is Coming Next
While this article focuses on the three frameworks currently in force, UK organisations should be preparing for the Cyber Security and Resilience Bill, which was introduced to Parliament in November 2025 and is expected to receive Royal Assent in 2026 with phased implementation through 2026-2027. The Bill brings the UK's NIS regulations closer to NIS2, expanding the scope to include managed service providers, introducing 24-hour early warning and 72-hour incident notification requirements that mirror NIS2's timescales, and granting regulators enhanced enforcement powers including the ability to issue emergency directions during national security threats.
For UK organisations that are not currently subject to NIS2 directly, the CS&R Bill will introduce many of the same obligations. Organisations that already have a managed SOC aligned to the NIS2 framework will be well positioned to meet the new UK requirements when they come into force. Those that wait will face an implementation challenge under time pressure. The prudent approach is to align SOC capabilities to the most demanding of the three current frameworks now, which provides both current compliance and future readiness.
14. Conclusion — Compliance as an Outcome, Not an Objective
The regulatory frameworks discussed in this article are not arbitrary bureaucratic impositions. They are codifications of what effective cyber security practice already looks like: continuous monitoring, rapid detection, structured response, transparent reporting, proactive testing, and informed governance. An organisation that genuinely practises these disciplines will find compliance a natural outcome rather than a separate burden.
A managed SOC, properly integrated with the organisation's security programme, delivers the operational backbone that all three frameworks demand. But the SOC alone is not sufficient. It must be complemented by baseline controls — validated through <a href="https://www.hedgehogsecurity.co.uk/cyber-essentials">Cyber Essentials</a> certification — that reduce the attack surface and prevent commodity threats from reaching the SOC. It must be informed by regular <a href="https://www.hedgehogsecurity.co.uk/penetration-testing">penetration testing</a> that identifies the real-world attack paths the SOC should detect. And it must be governed by a board that understands its regulatory obligations and holds both the internal security team and the SOC provider accountable for measurable outcomes.
The convergence of FCA PS21/3, DORA, and NIS2 represents the most significant uplift in regulatory expectations for cyber security in a generation. Organisations that treat this as a compliance problem will struggle. Organisations that treat it as an opportunity to build genuine operational resilience — with a modern SOC at the centre — will not only meet the regulatory bar, but will be genuinely harder to breach. And in the end, that is the outcome that matters.
Author: Peter Bassill, Founder — Hedgehog Security & UK Cyber Defence Ltd. Published 12 February 2026.