Requisitos de respuesta a incidentes comparados entre marcos
La respuesta a incidentes es uno de los cinco temas que exige cualquier marco. Los planes se parecen; los plazos de notificación no. Así se comparan.
Esta entrada cubre los 11 marcos que ControlMapping había asignado cuando se redactó. Desde entonces, se añadieron DORA, CPS 234, Cyber Essentials el 2026-10-27; sus páginas y la matriz de cobertura ya los incluyen.
La respuesta a incidentes forma parte del núcleo común: todos los marcos que correlacionamos la exigen. El requisito básico es el mismo en todas partes: un plan, personas que conozcan sus funciones y una forma de detectar, contener, recuperar y aprender. Las diferencias están en las pruebas y, sobre todo, en a quién debe informar y con qué rapidez.
Quién exige qué
| Marco | Respuesta a incidentes | Vínculo |
|---|---|---|
| NIST CSF 2.0 | RS.MA-01RS.MA-02RS.MA-03RS.MA-04ID.IM-04 | Definición del tema |
| ISO 27001 | A.5.24A.5.25A.5.26 | Correspondencia |
| CIS v8.1 | CIS 17.1CIS 17.4CIS 17.5CIS 17.7CIS 17.9 | Correspondencia |
| SOC 2 | CC7.4CC7.3 | Editorial |
| PCI DSS | 12.10.112.10.312.10.212.10.4 | Correspondencia |
| CMMC | IR.L2-3.6.1IR.L2-3.6.3 | Correspondencia |
| 800-53 | IR-4IR-8IR-2IR-3 | Correspondencia |
| HIPAA | §164.308(a)(6)§164.308(a)(6)(ii) | Correspondencia |
| GDPR | Art.33(1)Art.33(5) | Editorial |
| NIS2 | 3.13.5 | Correspondencia |
| Essential Eight | ISM-1819 | Editorial |
Detalle completo y motivo de cada vínculo: Respuesta a incidentes en todos los marcos →
El plan
Todos los marcos esperan una capacidad documentada de respuesta a incidentes: los controles de planificación, evaluación y respuesta de gestión de incidentes de ISO 27001 (A.5.24 a A.5.26), la evaluación de incidentes y la respuesta a ellos de SOC 2 (CC7.3, CC7.4), el plan de respuesta a incidentes de PCI DSS (12.10.1), la gestión de incidentes de CMMC (IR.L2-3.6.1), los procedimientos de incidentes de seguridad de HIPAA (§164.308(a)(6)) y la política de gestión y respuesta a incidentes de NIS2 (puntos 3.1 y 3.5). El contenido es coherente: funciones, niveles de gravedad, escalado, contención, erradicación, recuperación y lecciones aprendidas.
Pruebas
PCI DSS es el único que fija una frecuencia: revisar y probar el plan al menos una vez al año (12.10.2) y formar a las personas que lo ejecutan (12.10.4). CMMC y SP 800-53 exigen probar la capacidad (IR.L2-3.6.3, IR-3) con la frecuencia que usted defina. CIS pide ejercicios periódicos (17.7). ISO 27001 y SOC 2 esperan evidencias de que el plan funciona, sin fijar un calendario; un ejercicio de mesa anual es la respuesta habitual.
Plazos de notificación
Aquí es donde los marcos realmente difieren:
| Marco | A quién informa | Plazo |
|---|---|---|
| NIS2 | CSIRT o autoridad competente | Alerta temprana en un plazo de 24 horas; notificación en un plazo de 72 horas; informe final en el plazo de un mes |
| RGPD [GDPR] | Autoridad de control (violaciones de datos personales) | En un plazo de 72 horas desde que se tiene conocimiento (artículo 33) |
| RGPD | Personas afectadas, cuando el riesgo para ellas es alto | Sin dilación indebida (artículo 34) |
| CMMC / DFARS | Departamento de Defensa de EE. UU. | En un plazo de 72 horas, según la cláusula DFARS 252.204-7012 |
| HIPAA | Personas afectadas (regla de notificación de violaciones) | Sin demoras injustificadas y, en cualquier caso, en un plazo máximo de 60 días |
| PCI DSS | Marcas de pago y adquirente | Según los procedimientos de cada marca (12.10.1) |
| ISO 27001, SOC 2 | Sin plazo regulatorio | Lo deciden su plan y sus contratos |
Un único incidente puede activar varios plazos a la vez. Un ataque de ransomware contra un proveedor de nube de la UE que almacena datos personales y procesa pagos con tarjeta podría iniciar en la misma hora los procesos de NIS2, RGPD y de las marcas de pago.
Conclusiones clave
- Todos los marcos exigen un plan de respuesta a incidentes; el contenido es coherente.
- Los plazos de notificación difieren notablemente, desde las 24 horas de NIS2 hasta los 60 días de HIPAA.
- Un incidente puede iniciar varios plazos; un único coordinador debería gestionarlos todos.
Qué hacer
- Redacte un solo plan que cumpla los requisitos de contenido más estrictos y enumere cada obligación de notificación que le sea aplicable, con su plazo, destinatario y responsable.
- Decida quién valora la relevancia. El plazo de 24 horas de NIS2 comienza cuando se tiene conocimiento de un incidente significativo; esa decisión no puede esperar al lunes.
- Pruébelo al menos una vez al año (la regla de PCI es un buen punto de partida), incluido un escenario fuera del horario laboral.
- Conserve registros de cada incidente y violación, estén o no notificados: el RGPD lo exige (artículo 33, apartado 5) y cualquier auditor lo pedirá.
La página del tema Respuesta a incidentes enumera cada requisito con su fuente; el tema Notificación trata la notificación. Nuestra guía de NIS2 detalla con más profundidad el procedimiento de notificación.
Preguntas
¿Cuáles son los plazos de notificación de incidentes en NIS2?
Una alerta temprana en un plazo de 24 horas desde que se tiene conocimiento de un incidente significativo, una notificación del incidente en un plazo de 72 horas y un informe final en el plazo de un mes.
¿Con qué frecuencia debe probarse un plan de respuesta a incidentes?
PCI DSS exige revisar y probar el plan al menos una vez al año (12.10.2). CMMC y SP 800-53 exigen probar la capacidad de respuesta a incidentes (IR.L2-3.6.3, IR-3). ISO 27001 y SOC 2 esperan pruebas, pero dejan la frecuencia a su criterio.
¿ISO 27001 establece un plazo para notificar incidentes?
No. ISO 27001 exige la gestión de incidentes, incluida la notificación interna de eventos y la respuesta, pero no un plazo de notificación regulatoria. Los plazos proceden de la ley (NIS2, RGPD), de los contratos y de las normas sectoriales.
Datos a fecha de 2026-10-27: las cifras de esta entrada se calculan a partir de la correspondencia vigente y se actualizan cuando esta cambia. Correspondencia una tabla de correspondencias publicada (NIST, ENISA, CIS, PCI SSC) establece la relación · Editorial Criterio editorial de ControlMapping cuando no existe crosswalk; se muestra el motivo · solo comparte un resultado de CSF 2.0: conviene revisarlo, no es una asignación · Sin correspondencia en nuestros datos no hay nada asignado en nuestros datos; a menudo es trabajo nuevo, pero revisa las notas de cobertura. No es asesoramiento de cumplimiento.
Artículos relacionados
Análisis · 2026-10-27APRA CPS 234 y ISO 27001: qué cubre su SGSI y qué añade APRAUn SGSI conforme a ISO 27001 cubre casi todos los párrafos de la CPS 234 de APRA, pero APRA añade obligaciones del consejo de administración, garantías de terceros y plazos estrictos de notificación.
Análisis · 2026-10-27Cyber Essentials frente a Essential Eight: dos referencias nacionales comparadasEl Cyber Essentials del Reino Unido y el Essential Eight de Australia persiguen ambos los ataques más comunes, pero cubren terrenos distintos. Qué se solapa, qué no y por qué.
Análisis · 2026-10-27DORA frente a NIS2: qué cubre ya un programa NIS2DORA y NIS2 comparten casi todo su contenido de seguridad; DORA añade registro, cláusulas y pruebas basadas en amenazas. Qué se traslada, artículo por artículo.