Cómo el SOC como servicio respalda el cumplimiento de FCA, DORA y NIS2

1. La convergencia regulatoria que enfrentan las organizaciones del Reino Unido y la UE

Por primera vez, tres marcos regulatorios importantes están imponiendo simultáneamente requisitos específicos y medibles sobre cómo las organizaciones detectan, responden y reportan incidentes cibernéticos. La Declaración de Política PS21/3 de la Autoridad de Conducta Financiera (FCA), que se hizo plenamente exigible el 31 de marzo de 2025, requiere que las firmas reguladas por la FCA identifiquen sus servicios empresariales importantes, establezcan tolerancias de impacto y demuestren mediante pruebas de escenarios que pueden mantenerse dentro de esas tolerancias, incluso durante ciberataques. La Ley de Resiliencia Operativa Digital (DORA) de la UE, aplicable desde el 17 de enero de 2025, exige una gestión integral del riesgo TIC, la notificación de incidentes dentro de plazos estrictos, pruebas de resiliencia regulares que incluyen pruebas de penetración dirigidas por amenazas, y la supervisión de proveedores de servicios TIC de terceros para todas las entidades financieras que operan dentro de la UE. La Directiva NIS2, que los estados miembros de la UE debían transponer antes de octubre de 2024, extiende las obligaciones de ciberseguridad a dieciocho sectores críticos, y el propio proyecto de ley de Ciberseguridad y Resiliencia del Reino Unido — presentado al Parlamento en noviembre de 2025 — está preparado para reflejar muchos de estos requisitos para las organizaciones con sede en el Reino Unido.

Lo que conecta estos marcos es un reconocimiento compartido de que la seguridad reactiva es insuficiente. Cada uno exige monitorización continua, detección proactiva de amenazas, respuesta documentada a incidentes, informes transparentes y gobernanza del riesgo cibernético a nivel de junta directiva. Estas son precisamente las capacidades que un compromiso maduro de SOC como servicio está diseñado para ofrecer. La pregunta ya no es si las organizaciones necesitan un SOC, sino si su proveedor de SOC puede respaldar de forma demostrable el cumplimiento de los requisitos específicos de cada marco.

2. Comprendiendo los tres marcos regulatorios

Antes de examinar cómo un SOC respalda el cumplimiento, es importante comprender el enfoque distinto de cada marco, porque aunque se superponen significativamente, cada uno tiene requisitos específicos que el SOC debe abordar.

3. Monitorización continua — La base de los tres marcos

Cada uno de estos marcos requiere que las organizaciones mantengan visibilidad continua sobre su entorno TIC. La PS21/3 de la FCA requiere que las firmas monitoricen los recursos operativos que respaldan sus servicios empresariales importantes, incluyendo tecnología, dependencias de terceros y personas. DORA requiere que las entidades financieras implementen herramientas y procesos de monitorización de seguridad TIC capaces de detectar actividades anómalas, incluyendo ciberamenazas, de manera oportuna. NIS2 requiere medidas de gestión de riesgos que incluyan la monitorización continua de redes y sistemas de información para detectar incidentes que podrían afectar la prestación de servicios.

Un SOC gestionado ofrece esta capacidad como su función central. El SOC ingiere telemetría de todo el entorno de la organización — endpoints, servidores, infraestructura de red, plataformas en la nube, sistemas de identidad, correo electrónico y aplicaciones — y aplica reglas de detección, análisis de comportamiento e inteligencia de amenazas para identificar amenazas potenciales en tiempo real. Para las firmas reguladas por la FCA, esto significa que el SOC está monitorizando continuamente los sistemas que sustentan los servicios empresariales importantes. Para las entidades reguladas por DORA, el SOC sirve como la función de monitorización de seguridad TIC exigida por el Artículo 9. Para las entidades reguladas por NIS2, el SOC proporciona la monitorización continua de redes y sistemas de información que sustenta las obligaciones de gestión de riesgos de la directiva.

De manera crítica, la monitorización debe ser genuinamente continua — 24 horas al día, 365 días al año. Los marcos regulatorios no reconocen horarios comerciales, y los atacantes no los observan. Aquí es donde un SOC gestionado proporciona un valor particular para organizaciones que no pueden mantener cobertura interna las 24 horas, lo que en la práctica significa la abrumadora mayoría de las firmas por debajo de la escala empresarial.

4. Detección, clasificación y notificación de incidentes

Los requisitos de notificación de incidentes en estos tres marcos se encuentran entre las obligaciones operativamente más exigentes que cualquier organización enfrenta. Bajo DORA, los incidentes graves relacionados con TIC deben ser reportados a la autoridad competente con una notificación inicial dentro de las cuatro horas posteriores a la clasificación, un informe intermedio dentro de las 72 horas y un informe final dentro de un mes. Bajo NIS2, se debe proporcionar una alerta temprana dentro de las 24 horas posteriores al conocimiento de un incidente significativo, una notificación del incidente dentro de las 72 horas y un informe final dentro de un mes. Bajo PS21/3, la FCA y la PRA han consultado sobre un marco que requiere la notificación de incidentes operativos que cumplan umbrales definidos.

Cumplir con estos plazos requiere dos cosas que la mayoría de las organizaciones carecen: la capacidad de detectar incidentes rápidamente y los procesos estructurados para clasificarlos y reportarlos dentro de las ventanas exigidas. Un SOC gestionado aborda ambos. En el lado de la detección, las capacidades de monitorización continua, ingeniería de detección y caza de amenazas del SOC reducen el tiempo medio de detección (MTTD), asegurando que los incidentes se identifiquen en minutos u horas en lugar de días o semanas. En el lado de la notificación, un proveedor de SOC maduro debe tener procedimientos de clasificación de incidentes documentados que se alineen con las taxonomías específicas requeridas por cada marco.

El SOC también debe producir los artefactos probatorios necesarios para la notificación regulatoria — reconstrucciones de líneas de tiempo, análisis de causa raíz, indicadores de compromiso, evaluaciones de alcance y evidencia de contención. Sin un SOC generando estos artefactos en tiempo real durante un incidente, las organizaciones tendrán dificultades para producir las notificaciones detalladas que los tres marcos requieren dentro de los plazos exigidos.

5. Pruebas de resiliencia y el ciclo de retroalimentación ofensivo-defensivo

Los tres marcos exigen pruebas regulares de la capacidad de una organización para resistir y recuperarse de interrupciones cibernéticas. DORA es el más prescriptivo, requiriendo pruebas básicas al menos anualmente y pruebas avanzadas de penetración dirigidas por amenazas (TLPT) cada tres años para entidades que realizan funciones críticas. NIS2 requiere que las organizaciones evalúen la efectividad de sus medidas de gestión de riesgos mediante pruebas regulares. PS21/3 requiere pruebas de escenarios bajo condiciones severas pero plausibles.

Un SOC gestionado respalda esta obligación de dos maneras complementarias. Primero, el SOC proporciona pruebas continuas e implícitas a través de sus operaciones diarias de detección y respuesta. Segundo, y más importante, el SOC debe integrarse activamente con el programa formal de pruebas de la organización. Esto significa consumir los hallazgos de los compromisos de <a href="https://www.hedgehogsecurity.co.uk/penetration-testing">pruebas de penetración</a> y usarlos para crear o refinar reglas de detección. Si los testers de penetración identifican que un atacante podría moverse desde una aplicación web comprometida a bases de datos internas, el SOC debería tener detecciones para cada paso de esa ruta.

Para los requisitos de TLPT de DORA específicamente, el proveedor de SOC juega un papel dual. Durante la prueba, el SOC debe operar normalmente — la prueba está diseñada para evaluar si el SOC detecta y responde a un escenario de ataque realista. Después de la prueba, el SOC debe ser el consumidor principal de los hallazgos. Las organizaciones que encargan <a href="https://www.hedgehogsecurity.co.uk/penetration-testing">pruebas de penetración</a> regulares a través de proveedores acreditados por CREST y alimentan esos resultados directamente a su SOC crean el ciclo de mejora continua que los tres marcos esperan ver.

6. Riesgo de terceros y el proveedor de SOC como proveedor TIC

Los tres marcos imponen obligaciones sobre la gestión de riesgos de terceros, y esto crea una dualidad importante: el proveedor de SOC ayuda a la organización a gestionar el riesgo de terceros, pero el proveedor de SOC es en sí mismo un proveedor de servicios TIC de terceros sujeto a supervisión.

Bajo DORA, las entidades financieras deben mantener un registro de todos los acuerdos contractuales con proveedores de servicios TIC de terceros, y el proveedor de SOC debe estar incluido. El contrato debe abordar los requisitos de seguridad, las obligaciones de notificación de incidentes, los derechos de acceso y recuperación de datos, los derechos de auditoría y las estrategias de salida. Bajo NIS2, las entidades deben implementar medidas de seguridad adaptadas a las vulnerabilidades de sus proveedores directos. Bajo PS21/3, la FCA establece explícitamente que es responsabilidad de la firma mantenerse dentro de sus tolerancias de impacto, incluyendo cuando un proveedor externo respalda o entrega los servicios empresariales importantes relevantes.

Esto significa que la junta debería hacer preguntas exigentes sobre la postura de seguridad del proveedor de SOC, sus certificaciones y su posición de cumplimiento. ¿Está el proveedor certificado en ISO 27001? ¿Tiene la certificación SOC 2 Tipo II? ¿Está acreditado por CREST? ¿Puede producir evidencia de sus propias capacidades de continuidad empresarial y recuperación ante desastres? Un proveedor de SOC que no puede responder a estas preguntas es un riesgo regulatorio, no un habilitador de cumplimiento.

7. Gobernanza a nivel de junta directiva e informes regulatorios

Cada marco coloca responsabilidad explícita en la alta dirección y los órganos de gobierno. Bajo DORA, el órgano de dirección debe aprobar y supervisar activamente el marco de gestión de riesgos TIC. Bajo NIS2, la alta dirección debe supervisar y aprobar las medidas de gestión de riesgos de ciberseguridad, recibir formación en ciberseguridad y puede ser considerada personalmente responsable — incluyendo prohibiciones temporales de roles directivos — por fallos en la implementación de medidas adecuadas. Bajo PS21/3, la junta debe recibir autoevaluaciones de la resiliencia operativa de la firma.

Un SOC gestionado respalda este requisito de gobernanza proporcionando informes estructurados y preparados para la junta que traducen las operaciones de seguridad al lenguaje del cumplimiento regulatorio y el riesgo empresarial. Los informes mensuales deben detallar la cobertura de detección, los volúmenes y clasificaciones de incidentes, los tiempos medios de detección y respuesta, los cambios en el panorama de amenazas relevantes para el sector de la organización, y los hallazgos específicos de las actividades de caza de amenazas.

Para las firmas reguladas por la FCA, los informes del SOC deben mapearse específicamente a los servicios empresariales importantes, mostrando a la junta qué servicios están siendo monitorizados, qué amenazas se han detectado contra ellos y si algún incidente se ha acercado o ha superado las tolerancias de impacto. Para las entidades reguladas por DORA, el SOC debe contribuir a los informes de riesgos TIC del órgano de dirección. Para las entidades reguladas por NIS2, los informes del SOC deben respaldar las obligaciones de supervisión de la alta dirección proporcionando la base de evidencia para la toma de decisiones informadas.

8. Retención de registros, preservación de evidencia y preparación para auditorías

El cumplimiento regulatorio es fundamentalmente sobre evidencia. No es suficiente detectar amenazas y responder a incidentes — la organización debe ser capaz de demostrar a los reguladores, después del hecho, que lo hizo de manera efectiva, dentro de los plazos requeridos y de acuerdo con los procedimientos documentados. Esto impone requisitos específicos sobre las prácticas de gestión de datos del SOC.

Bajo DORA, las entidades financieras deben mantener registros de incidentes relacionados con TIC incluyendo líneas de tiempo, decisiones de clasificación, acciones de respuesta y análisis de causa raíz. Bajo NIS2, los informes de incidentes deben incluir descripciones detalladas del incidente, su severidad e impacto, indicadores de compromiso y una descripción de las contramedidas aplicadas. Bajo PS21/3, las firmas deben mantener registros de sus pruebas de escenarios, incluyendo resultados y acciones de remediación.

Un SOC gestionado debe proporcionar retención de registros a largo plazo que cumpla o supere los mínimos regulatorios — típicamente un mínimo de doce meses de datos en línea y buscables, con retención de archivo extendiéndose más según lo requerido por el marco específico. La plataforma SOC debe producir registros de auditoría inmutables que muestren cuándo se generaron las alertas, cuándo se reconocieron, qué pasos de investigación se tomaron, qué acciones de respuesta se ejecutaron y por quién. Estos artefactos no son extras opcionales — son la evidencia que los reguladores solicitarán durante las revisiones supervisoras.

9. Mapeando las capacidades del SOC a requisitos regulatorios específicos

El siguiente mapeo ilustra cómo las capacidades centrales del SOC se alinean con requisitos específicos en los tres marcos. Las juntas directivas y los equipos de cumplimiento pueden usar esto como referencia al evaluar si su proveedor de SOC ofrece la cobertura que cada marco exige.

10. La base fundamental — Por qué Cyber Essentials importa para el cumplimiento

Si bien los tres marcos discutidos en este artículo imponen requisitos avanzados, el cumplimiento no comienza en el SOC. Comienza con controles de seguridad básicos que previenen la mayoría de los ataques genéricos y reducen el volumen de incidentes que el SOC debe manejar. Las organizaciones que no han asegurado sus fundamentos abrumarán a su SOC con alertas prevenibles y se encontrarán incapaces de cumplir las expectativas de resiliencia de cualquier marco regulatorio.

La certificación <a href="https://www.hedgehogsecurity.co.uk/cyber-essentials">Cyber Essentials</a> proporciona esta base. Los cinco controles técnicos del esquema — cortafuegos, configuración segura, control de acceso de usuarios, protección contra malware y gestión de parches — abordan directamente los vectores de ataque más comúnmente explotados por los actores de amenazas contra los que los tres marcos están diseñados para defender. Para las firmas reguladas por la FCA, Cyber Essentials proporciona evidencia de que los controles básicos están en su lugar. Para las entidades reguladas por DORA, los controles se mapean directamente a los requisitos del marco de gestión de riesgos TIC. Para las entidades reguladas por NIS2, abordan varias de las medidas de seguridad básicas mínimas exigidas por el Artículo 21.

<a href="https://www.hedgehogsecurity.co.uk/cyber-essentials">Cyber Essentials Plus</a> va más allá, añadiendo verificación técnica práctica mediante pruebas realizadas por un evaluador acreditado. Cuando se combina con un SOC gestionado para monitorización continua y detección avanzada de amenazas, y <a href="https://www.hedgehogsecurity.co.uk/penetration-testing">pruebas de penetración</a> regulares para la identificación proactiva de vulnerabilidades, las tres capas crean un programa de seguridad integral y auditable que aborda los requisitos de los tres marcos simultáneamente.

11. Errores comunes — Donde las organizaciones se quedan cortas

12. Qué debería exigir la junta a su proveedor de SOC

13. El proyecto de ley de Ciberseguridad y Resiliencia del Reino Unido — Lo que viene

Si bien este artículo se centra en los tres marcos actualmente en vigor, las organizaciones del Reino Unido deberían estar preparándose para el proyecto de ley de Ciberseguridad y Resiliencia, que fue presentado al Parlamento en noviembre de 2025 y se espera que reciba la Sanción Real en 2026 con implementación escalonada hasta 2026-2027. El proyecto de ley acerca las regulaciones NIS del Reino Unido a NIS2, ampliando el alcance para incluir proveedores de servicios gestionados, introduciendo requisitos de alerta temprana de 24 horas y notificación de incidentes de 72 horas que reflejan los plazos de NIS2, y otorgando a los reguladores poderes de aplicación mejorados.

Para las organizaciones del Reino Unido que no están actualmente sujetas a NIS2 directamente, el proyecto de ley CS&R introducirá muchas de las mismas obligaciones. Las organizaciones que ya tienen un SOC gestionado alineado con el marco NIS2 estarán bien posicionadas para cumplir con los nuevos requisitos del Reino Unido cuando entren en vigor. El enfoque prudente es alinear las capacidades del SOC con el más exigente de los tres marcos actuales ahora, lo que proporciona tanto cumplimiento actual como preparación futura.

14. Conclusión — El cumplimiento como resultado, no como objetivo

Los marcos regulatorios discutidos en este artículo no son imposiciones burocráticas arbitrarias. Son codificaciones de lo que la práctica efectiva de ciberseguridad ya parece: monitorización continua, detección rápida, respuesta estructurada, informes transparentes, pruebas proactivas y gobernanza informada. Una organización que practica genuinamente estas disciplinas encontrará el cumplimiento como un resultado natural en lugar de una carga separada.

Un SOC gestionado, adecuadamente integrado con el programa de seguridad de la organización, proporciona la columna vertebral operativa que los tres marcos exigen. Pero el SOC solo no es suficiente. Debe complementarse con controles básicos — validados a través de la certificación <a href="https://www.hedgehogsecurity.co.uk/cyber-essentials">Cyber Essentials</a> — que reducen la superficie de ataque y previenen que las amenazas genéricas lleguen al SOC. Debe estar informado por <a href="https://www.hedgehogsecurity.co.uk/penetration-testing">pruebas de penetración</a> regulares que identifiquen las rutas de ataque del mundo real que el SOC debería detectar. Y debe estar gobernado por una junta que comprenda sus obligaciones regulatorias y exija tanto al equipo interno de seguridad como al proveedor de SOC resultados medibles.

La convergencia de FCA PS21/3, DORA y NIS2 representa el aumento más significativo en las expectativas regulatorias para la ciberseguridad en una generación. Las organizaciones que traten esto como un problema de cumplimiento tendrán dificultades. Las organizaciones que lo traten como una oportunidad para construir resiliencia operativa genuina — con un SOC moderno en el centro — no solo cumplirán el estándar regulatorio, sino que serán genuinamente más difíciles de vulnerar. Y al final, ese es el resultado que importa.

Autor: Peter Bassill, Fundador — Hedgehog Security & UK Cyber Defence Ltd. Publicado el 12 de febrero de 2026.