Seguir Las obligaciones de detección normativa son los resultados de seguridad que DORA, NIS2, PCI DSS v4.0.1, y las normas de divulgación de la SEC requieren que una organización logre y evidencie a través de la detección, monitoreo, registro y divulgación.
Ninguno de estos cuatro regímenes prescribe una herramienta de detección específica. Solo DORA nombra la detección como una obligación independiente. Cada marco requiere un resultado: detección oportuna, monitoreo continuo, registro estructurado o divulgación oportuna. La capacidad de detección es lo que implica la evidencia, no un control que cualquier regulador exija por nombre.
MITRE ATT&CK organiza esa evidencia en una estructura que un auditor puede consultar por categoría de comportamiento adversario. ATT&CK no es requerido por DORA, NIS2, PCI DSS, o las normas de la SEC.
DORA es lex specialis o una ley específica que prevalece sobre una ley general. DORA Artículo 1(2) lo convierte en un acto legal sectorial de la Unión para los propósitos del Artículo 4 de NIS2. Una entidad financiera en el ámbito de DORA aplica DORA para la gestión de riesgos de TIC y reporte de incidentes. NIS2 alcanza a la cadena de suministros no financieros de un banco, no al banco mismo.
¿Qué evidencia de detección respalda las obligaciones bajo PCI DSS 4.0 y DORA?
Ambos PCI DSS v4.0.1 y DORA tratan la detección como un medio para un fin probatorio. La regulación pregunta si las detecciones generan los registros que la obligación de monitoreo requiere, no si las detecciones existen.
Cinco clases de evidencia llevan esa prueba. Ambos regímenes las requieren en esencia.
| Clase de evidencia | PCI DSS v4.0.1 | DORA |
|---|---|---|
| Fuentes de registro recopiladas | Requisito 10: capturar registros de auditoría, retener historial | Artículo 9(1): monitorear y controlar continuamente la seguridad y el funcionamiento de los sistemas TIC; Artículo 10(3): monitorear la actividad de los usuarios, anomalías TIC e incidentes relacionados con TIC |
| Reglas desplegadas, con propietario | Requisito 11: detección/previsión de intrusiones, detección de cambios en su lugar | Artículo 10: múltiples capas de control, umbrales y criterios de alerta definidos |
| Prueba de activación | Requisito 10: revisar registros, detectar fallas en los sistemas de control | Artículo 10: alertas activadas y llegaron al personal responsable |
| Historial de cambios | Requisito 11: detección de cambios y manipulaciones | Artículo 17: proceso documentado de gestión de incidentes con seguimiento de causa raíz |
| Informe de cobertura con fecha | Requisito 10.5.1: historia de registros de auditoría retenida por al menos 12 meses, los últimos tres meses disponibles inmediatamente (biblioteca de documentos PCI SSC) | Artículo 10(1): mecanismos de detección probados regularmente de acuerdo con el Artículo 25 |
PCI DSS v4.0 se retiró el 31 de diciembre de 2024 y PCI DSS v4.0.1 es la única versión activa (PCI SSC, junio 2024). Los 51 requisitos con fecha futura se hicieron efectivos el 31 de marzo de 2025 (PCI SSC, agosto 2024). El H2 de arriba usa «PCI DSS 4.0» para coincidir con la consulta del buscador.
Una regla de detección que se despliega pero no genera ningún registro auditable es invisible para un evaluador.
¿Qué obligaciones de detección y monitoreo imponen realmente DORA, NIS2, PCI DSS 4.0 y las normas de divulgación de la SEC?
Cada régimen impone una obligación de resultado en lugar de un mandato de herramienta. La tabla a continuación mapea cada obligación a la evidencia de detección que implica.
| Régimen | Artículo o Requisito | Obligación | Evidencia de detección implicada |
|---|---|---|---|
| DORA | Art 9(1), Art 10(3) | Monitorear y controlar continuamente la seguridad y el funcionamiento de los sistemas TIC (Art 9(1)); monitorear la actividad de los usuarios, anomalías TIC e incidentes relacionados con TIC (Art 10(3)) | Inventario de fuentes de registro, registros de recolección continua |
| DORA | Art 10(1), (2) | Detectar actividades anómalas; múltiples capas de control con umbrales y criterios de alerta, incluidas alertas automáticas al personal encargado de la respuesta a incidentes; mecanismos de detección probados regularmente bajo el Artículo 25 | Inventario de reglas con propietarios, justificación del umbral, prueba de que las alertas llegaron a los respondedores, registros de pruebas |
| DORA | Art 17 | Detectar, gestionar y notificar incidentes relacionados con TIC con seguimiento de causa raíz | Documentación de procesos, registros de detección y manejo por incidente |
| DORA | Art 19 + Reglamento Delegado (UE) 2025/301 | Informar incidentes mayores a la autoridad competente | Registro de detección y clasificación con sello de tiempo (notificación inicial dentro de las 4 horas de clasificar el incidente como mayor y no más tarde de 24 horas después de tomar conciencia; informe intermedio dentro de las 72 horas de la notificación inicial; informe final dentro de un mes del informe intermedio) |
| NIS2 | Art 21(2) | Medidas de gestión de riesgos, incluyendo manejo de incidentes (punto (b)) y políticas para evaluar la efectividad de las medidas (punto (f)); los deberes de monitoreo y registro se sitúan en las reglas de implementación a continuación, no en el Artículo 21 mismo | Medidas documentadas, registros de detección |
| NIS2 | Art 23(4) | Notificación de incidentes significativos | Advertencia temprana dentro de las 24 horas de tomar conciencia, notificación de incidente dentro de las 72 horas, informe final no más tarde de un mes después de la notificación del incidente |
| NIS2 | Reglamento de Implementación (UE) 2024/2690 | Monitoreo y registro (Anexo sección 3.2) para los once tipos de entidades del Artículo 1(1), incluyendo proveedores de servicios de seguridad gestionada | Registros de registro explícitos para entidades cubiertas |
| PCI DSS v4.0.1 | Req 10 | Registrar y monitorear todo acceso a los componentes del sistema y datos del titular de la tarjeta | Registros de auditoría revisados al menos diariamente (10.4.1), revisión automática de registros (10.4.1.1), historia de registros retenida (10.5.1), fallos de sistemas de control de seguridad críticos detectados, informados y respondidos prontamente (10.7, 10.7.2); texto en el biblioteca de documentos PCI SSC |
| PCI DSS v4.0.1 | Req 11 | Probar la seguridad de los sistemas y redes regularmente | Registros de detección y prevención de intrusiones (11.5.1), alertas de detección de cambios (11.5.2), alertas de detección de cambios y manipulaciones en páginas de pago (11.6.1) |
| SEC | 8-K Ítem 1.05 | Divulgar incidentes materiales dentro de los cuatro días hábiles de la determinación de materialidad, la cual debe hacerse sin demora injustificada después del descubrimiento (Formulario 8-K, Ítem 1.05) | Proceso de determinación de materialidad, registros de detección de incidentes |
| SEC | S-K Ítem 106 | Describir los procesos para evaluar, identificar y gestionar los riesgos materiales de ciberseguridad en el 10-K anual (Ítem 1C) | Proceso documentado de identificación de riesgos incluyendo capacidad de detección |
DORA (Reglamento (UE) 2022/2554, en aplicación desde el 17 de enero de 2025) es aplicable directamente. Sus relojes de reporte están establecidos por Reglamento Delegado (UE) 2025/301: notificación inicial dentro de las 4 horas de clasificar un incidente como mayor y no más tarde de 24 horas después de tomar conciencia de él, un informe intermedio dentro de las 72 horas de la notificación inicial, y un informe final dentro de un mes del informe intermedio. Porque el primer reloj comienza en la detección y clasificación, la línea de tiempo del incidente en sí misma es una evidencia auditable.
NIS2 (Directiva (UE) 2022/2555) obliga a través de la ley de transposición de cada Estado Miembro, no directamente. La fecha límite de transposición fue el 17 de octubre de 2024 (Artículo 41). El 7 de mayo de 2025 la Comisión Europea envió opiniones justificadas a 19 Estados Miembros por no notificar la transposición completa, y el 8 de julio de 2026 refirió a Irlanda, España, Francia y los Países Bajos al Tribunal de Justicia. El 20 de enero de 2026 la Comisión propuso enmiendas proposed amendments a NIS2 (COM(2026) 13) que afectan el Artículo 21(5) y añaden párrafos sobre ransomware al Artículo 23, dejando sin cambios las medidas del Artículo 21(2) y los relojes de reporte del Artículo 23(4). La obligación que enfrenta un comprador depende de la ley de transposición de su Estado Miembro.
Reglamento de Implementación (UE) 2024/2690, publicado el 18 de octubre de 2024 y en vigor desde el 7 de noviembre de 2024, establece requisitos explícitos de monitoreo y registro (sección 3.2 del Anexo) para proveedores de servicios DNS, registros de nombres TLD, computación en la nube, centro de datos, red de entrega de contenido, servicios gestionados y proveedores de servicios de seguridad gestionada, mercados en línea, motores de búsqueda, plataformas de redes sociales y proveedores de servicios de confianza. Esto alcanza a los MSSP como entidades reguladas por derecho propio, distintas de las obligaciones de sus clientes.
PCI DSS v4.0.1 es la única versión activa. Los requisitos 10 y 11 llevan las obligaciones de detección y monitoreo.
SEC (regla final Publicación 33-11216, adoptada el 26 de julio de 2023) es una regla de divulgación y gobernanza, no un mandato de controles de detección. La detección es derivada: un registrante no puede determinar la materialidad sin la capacidad de detectar y evaluar incidentes. El cumplimiento con el Ítem 1.05 fue requerido desde el 18 de diciembre de 2023 para la mayoría de registrantes y desde el 15 de junio de 2024 para compañías de informes más pequeños.
¿Qué evidencia buscan típicamente los auditores para confirmar que nuestros sistemas de detección son efectivos?
Cinco clases de evidencia se repiten a través de estos regímenes. Un porcentaje de cobertura solo no es evidencia para ninguno de ellos.
| # | Clase de evidencia | Qué prueba |
|---|---|---|
| 1 | Fuentes de registro recopiladas | Qué telemetría se ingiere, de qué sistemas, y que la colección es continua. El auditor verifica si el monitoreo está funcionando, no si fue configurado una vez. |
| 2 | Reglas desplegadas | Reglas de detección en su lugar, cada una mapeada a la obligación que apoya y a su ATT&CK técnica donde aplicable, con un propietario. |
| 3 | Prueba de activación | Reglas activadas en eventos reales o emulados y alertas que llegaron a los respondedores. Una regla desplegada que nunca se ha activado no está probada desde el punto de vista del auditor. |
| 4 | Historial de cambios | Quién cambió una regla, cuándo y por qué: control de versiones, un rastro de revisión y una justificación documentada para cada cambio. |
| 5 | Informe de cobertura con fecha | Informe de punto en el tiempo con una fecha, para que la tendencia y la moneda sean demostrables. Un informe sin fecha no prueba nada sobre cuándo existía la cobertura. |
ATT&CK funciona como el cruce que hace que esta evidencia sea consultable por comportamiento de adversario. Un ID de técnica es un metadato adjunto a la evidencia ya existente (fuentes de datos, reglas desplegadas, registros de activación) para que la evidencia sea recuperable por categoría de comportamiento. ATT&CK no es requerido por ninguno de estos cuatro regímenes. Organiza la evidencia contra las obligaciones que imponen.
¿Puede mostrar a un auditor quién cambió una regla, cuándo y por qué?
La detección como código responde esto. Cada regla de detección es un artefacto versionado en el control de origen. El historial de cambios registra el autor, la marca de tiempo, la aprobación de revisión y la razón del cambio.
Este rastro mapea a obligaciones específicas:
- El Artículo 17 de DORA requiere un proceso documentado de gestión de incidentes con seguimiento de causa raíz.
- PCI DSS v4.0.1 El Requisito 11 incluye detección y prevención de manipulaciones.
- El Ítem 106 de la SEC espera que un registrante describa sus procesos de identificación de riesgos.
Cada marco pregunta si la organización gobierna las reglas de detección como artefactos controlados, no simplemente si las reglas existen.
La prueba operativa: dado una regla que se activó el último trimestre, ¿puede el equipo producir su linaje completo? Quién la escribió, quién la revisó, cuándo fue modificada por última vez, por qué, a qué obligación se mapea, y qué técnica aborda. Una plataforma de contenido de detección que gestiona las reglas como código versionado produce este rastro como un subproducto de las operaciones normales.
Donde las reglas se editan en una consola sin control de versiones, el auditor no tiene procedencia para el estado actual de la regla. El gobierno de detección como código elimina esa ambigüedad por construcción.
¿Cómo se convierte la cobertura de detección en un elemento de línea de cumplimiento?
La capacidad de detección tiende a estar dentro de los presupuestos de operaciones, visible para el gerente de SOC, invisible para el CFO. Tres hechos hacen de la cobertura una conversación en la junta directiva.
- Los relojes de reporte comienzan en la detección. El reloj de clasificación de 4 horas de DORA y el reloj de materialidad de cuatro días hábiles de la SEC comienzan cuando la organización detecta o se da cuenta. Una detección más rápida es el comienzo de la línea de tiempo de cumplimiento.
- La evidencia de detección es auditable. Las cinco clases de evidencia mencionadas son lo que un auditor revisa. Producirlas cuesta tiempo y personal, ya sea que el equipo construya sus propias reglas o suscriba a una fuente de contenido de detección.
- El tiempo para la cobertura es medible. La ventana entre que una técnica se hace pública y un disparo de detección validado en el propio entorno de la organización es rastreable.
Un equipo de ingeniería solicita capacidad de detección en términos de personal y herramientas. Un equipo de cumplimiento lo solicita en términos de producción de evidencia. El segundo encuadre ata el gasto en detección a una obligación regulatoria que la junta ya está rastreando.
Una auditoría de postura de SIEM produce el mapa de cobertura que los auditores piden: reglas mapeadas a MITRE ATT&CK, fuentes de registro mapeadas a la misma matriz, y las brechas listadas con un plan.
Donde esto no se sostiene
Se aplican varias limitaciones.
No todas las obligaciones mapean a detección. El Ítem 1.05 de la SEC requiere divulgación, no controles específicos. El Artículo 21 de NIS2 y DORA incluyen seguridad de la cadena de suministro, continuidad del negocio y gestión de accesos. Ninguno de estos se mapea a técnicas ATT&CK. ATT&CK organiza el subconjunto de detección y monitoreo, no la superficie de cumplimiento completa.
La transposición de NIS2 está incompleta. Donde la ley de transposición de un Estado Miembro no está en vigor, los Artículos 21 y 23 de NIS2 no son ejecutables localmente. Las enmiendas propuestas en enero de 2026 no renumeran los Artículos 21 o 23.
Las normas de la SEC están en disputa. The La petición de rescisión contra el Ítem 1.05, presentada el 22 de mayo de 2025 por cinco asociaciones comerciales de banca y valores (SEC Archivo No. 4-856), permanece sin resolver: a a partir del 21 de septiembre de 2026 la SEC no ha propuesto ninguna enmienda al Ítem 1.05, aunque los peticionarios renovaron la solicitud en una carta de comentario de abril de 2026 bajo la revisión del Reglamento S-K de la Comisión. Una declaración del 21 de mayo de 2024 por Erik Gerding, entonces Director de la División de Finanzas Corporativas, aclaró que el Ítem 1.05 está reservado para incidentes que un registrante ha determinado ser materiales y alentó la divulgación de otros incidentes bajo un ítem diferente, como el Ítem 8.01; la División siguió con Interpretaciones de Cumplimiento y Divulgación el 24 de junio de 2024.
Los números de sub-requisitos siguen v4.0.1. Los sub-requisitos de PCI DSS citados aquí (10.4.1, 10.4.1.1, 10.5.1, 10.7, 10.7.2, 11.5.1, 11.5.2, 11.6.1) utilizan la numeración v4.0.1; la norma en sí está en la biblioteca de documentos PCI SSC, y el Requisito 10.7.2 se aplica a todas las entidades desde el 31 de marzo de 2025.
ATT&CK es un cruce, no una obligación regulatoria. Mapear detecciones a técnicas ATT&CK organiza la evidencia. No descarga ninguna obligación regulatoria, y ningún marco examinado aquí lo requiere.
DORA es lex specialis para las entidades financieras. Un banco en el ámbito de DORA no aplica los Artículos 21 y 23 de NIS2 además para su propia gestión de riesgos de TIC e informe de incidentes. NIS2 alcanza la cadena de suministro no financiera de un banco, no las propias operaciones de TIC del banco.
LISTA DE VERIFICACIÓN DE EVIDENCIA DE AUDITORÍA: OBLIGACIONES DE DETECCIÓN
1. FUENTES DE REGISTRO RECOPILADAS
[ ] Inventario de fuentes de telemetría ingeridas
[ ] Evidencia de recolección continua (no punto en el tiempo)
[ ] Cada fuente mapeada a los sistemas, activos, y
obligaciones que cubre
2. REGLAS DESPLEGADAS
[ ] Inventario de reglas de detección con propietarios nombrados
[ ] Cada regla mapeada a la obligación regulatoria que apoya
[ ] Cada regla mapeada a la técnica ATT&CK donde sea aplicable
(cruce, no requerido por regulación)
[ ] Umbrales de alerta documentados con justificación
3. PRUEBA DE ACTIVACIÓN
[ ] Evidencia de que las reglas se activaron en eventos reales o emulados
[ ] Registros de que las alertas llegaron a los respondedores designados
[ ] Registros de prueba fechados para mecanismos de detección
(Artículo 10 de DORA)
4. HISTORIAL DE CAMBIOS
[ ] Control de versiones para cada regla de detección
(Detección como Código)
[ ] Autor, revisor, marca de tiempo, y justificación por cambio
[ ] Rastro de revisión y aprobación
[ ] Registros de detección de cambios y manipulaciones
5. INFORME DE COBERTURA FECHADO
[ ] Informe de cobertura de punto en el tiempo con una fecha
[ ] Cobertura medida contra el conjunto de técnicas priorizadas,
no en toda la matriz ATT&CK
[ ] Datos de tendencia que muestran cobertura a lo largo del tiempo
[ ] Informe por entorno (no un solo número agregado)
ELEMENTOS ESPECÍFICOS DE RÉGIMEN
[ ] DORA: umbrales de alerta documentados con justificación
(Artículo 10)
[ ] DORA: marcas de tiempo de incidentes en los relojes de reporte
(4h desde la clasificación / 24h desde el conocimiento,
72h intermedio, 1 mes final)
[ ] NIS2: evidencia mapeada a la ley nacional transpuesta,
no solo texto directivo
[ ] PCI DSS v4.0.1: retención de registros según sub-requisitos aplicables
[ ] SEC: proceso de determinación de materialidad documentado
(Ítem 1.05)
[ ] SEC: supervisión de la junta y rol de gestión descrito
(Ítem 106)
NOTAS
- ATT&CK es el cruce utilizado para organizar esta evidencia.
No es requerido por DORA, NIS2, PCI DSS, o normas de la SEC.
- DORA es lex specialis: un banco en el ámbito de DORA aplica DORA,
no los Artículos 21 y 23 de NIS2, para la gestión de riesgos TIC.
- PCI DSS v4.0.1 es la única versión activa
(v4.0 retirada el 31 de diciembre de 2024).
- Cada especificación regulatoria en este documento está validada
por el ciso-cto-sme antes de la publicación.
FAQ
¿Qué evidencia de detección respalda las obligaciones bajo PCI DSS 4.0 y DORA?
Ambos regímenes requieren evidencia de detección y monitoreo continuo, no solamente evidencia de que las herramientas de detección están desplegadas. Las cinco clases de evidencia son: fuentes de registro recopiladas, reglas de detección desplegadas con propietarios, prueba de que esas reglas se activan, historial de cambios con control de versiones, y un informe de cobertura con fecha. MITRE ATT&CK organiza esta evidencia por categoría de comportamiento del adversario. ATT&CK no es requerido por ninguno de los dos marcos.
¿Qué evidencia buscan los auditores para confirmar que los sistemas de detección son efectivos?
Los auditores buscan cinco clases de evidencia: qué fuentes de telemetría se recogen y que la recolección es continua, reglas de detección mapeadas a obligaciones y técnicas ATT&CK con propietarios nombrados, prueba de que esas reglas se activan en eventos reales o emulados, historial de cambios con control de versiones para cada regla, y un informe de cobertura de punto en el tiempo con fecha. Un porcentaje de cobertura solo, sin los registros de soporte debajo, no es evidencia.
¿Mapear las detecciones a MITRE ATT&CK satisface a un regulador?
ATT&CK es el cruce que organiza la evidencia de detección por comportamiento del adversario. Hace la evidencia consultable y reportable por técnica. No descarga por sí mismo ninguna obligación regulatoria. DORA, NIS2, PCI DSS y las normas de la SEC piden evidencia de operación: monitoreo, detección, registro y divulgación. ATT&CK organiza esa evidencia. Ningún marco examinado aquí lo requiere.
¿Cuáles son los plazos de reporte de incidentes bajo DORA y NIS2?
Bajo DORA, el Reglamento Delegado (UE) 2025/301 establece los relojes para incidentes mayores: notificación inicial dentro de las 4 horas de clasificar el incidente como mayor (no más tarde de 24 horas después del conocimiento), un informe intermedio dentro de las 72 horas de la notificación inicial, y un informe final dentro de un mes del informe intermedio. Bajo NIS2, los incidentes significativos requieren una advertencia temprana dentro de las 24 horas de tomar conciencia, una notificación de incidente dentro de las 72 horas, y un informe final no más tarde de un mes después de la notificación del incidente. Ambos plazos comienzan en la detección, haciendo que el sello de tiempo de la detección en sí sea un registro auditable.
La Ingeniería de Contenido Personalizado de SOC Prime implementa detecciones en su SIEM o EDR y proporciona documentación de alto nivel de su propósito, función y uso.
