La obligación de notificar en 24 horas del CRA se aplica desde el 11 de septiembre de 2026. Compruebe si le afecta

ISO 27001

ISO 27001 · el plan de respuesta a incidentes

El plan de respuesta a incidentes, redactado a partir de unas pocas respuestas

Un incidente se gestiona bien o mal en la primera hora, y el plan es lo que la primera hora lee, así que esta página lo redacta antes de que haga falta: quién dirige y quién suple, cómo cualquiera notifica un evento, cómo se juzga bajo, medio o alto, los cinco pasos de la respuesta, qué relojes regulatorios empiezan con el conocimiento, qué evidencia se conserva, qué se revisa después y con qué frecuencia se ejercita el plan.

Gratis, sin cuenta.

Qué reglamentos se aplican

Cada uno añade su reloj de notificación al plan, leído del paquete y nunca tecleado aquí.

Ejercicios al año

El plan

Cada parte que piden los controles, en el orden en que transcurre un incidente; una entrada vacía se redacta como un hueco por completar, no se omite.

# Plan de respuesta a incidentes de seguridad de la información: [empresa]

Responsable del incidente: [el responsable del incidente] · Suplente: [el suplente] · Aprobado por: [la dirección]

Redactado el [fecha de hoy] con la página gratuita de getstandardos.com frente a los controles del anexo A sobre gestión de incidentes de ISO/IEC 27001:2022. La redacción es de StandardOS; los relojes regulatorios se leen del paquete que también alimenta las páginas de relojes del RGPD, NIS2 y CRA.

## 1. Objeto y alcance

Este plan dice qué hace [empresa] desde el momento en que se advierte un evento de seguridad de la información hasta que el incidente se cierra y sus lecciones se aplican. Cubre cada sistema, servicio y ubicación dentro del alcance del sistema de gestión, a cada persona que trabaja bajo el control de la empresa, y a los proveedores cuyos incidentes alcanzan los datos o los clientes de la empresa.

## 2. Roles

- [el responsable del incidente] dirige cada incidente: lo declara, fija la gravedad, conduce la respuesta, decide las notificaciones, cierra el incidente y es responsable de la revisión posterior.
- [el suplente] suple cuando el responsable no está disponible, con la misma autoridad, y los dos nunca están ilocalizables el mismo día.
- Todo el mundo notifica: cualquier persona que advierta un evento lo notifica de inmediato por el canal de abajo, y nadie necesita permiso para notificar.
- Solo [el responsable del incidente] o la dirección hablan con clientes, autoridades o prensa sobre un incidente; nadie más confirma ni niega uno.

## 3. Notificar un evento

Un evento se notifica a través de [por completar], a cualquier hora. Una notificación nunca es errónea por temprana ni por resultar en nada; el evento visto y no notificado es el fallo.

Una notificación dice qué se vio, dónde, cuándo, quién lo vio y qué se ha hecho ya; no espera a conocer la causa ni el impacto.

## 4. Evaluación y gravedad

[el responsable del incidente] decide en la hora siguiente si el evento es un incidente y fija uno de tres niveles de gravedad, revisado a medida que cambia el cuadro:

- Baja: un sistema o una persona afectados, sin exposición de datos personales ni de clientes, ningún servicio caído; gestionado por el equipo en horario de oficina, revisado en la siguiente reunión semanal.
- Media: datos de clientes o un servicio de cara al cliente afectados, contenido dentro del día; el responsable lo conduce, se informa a los clientes cuyos datos o servicio se ven afectados, se comprueban los relojes regulatorios.
- Alta: exposición confirmada de datos personales, un servicio caído para los clientes, ransomware o un atacante con acceso; todos a bordo, la dirección informada en la hora siguiente, los relojes regulatorios empiezan, ayuda externa contratada donde el equipo no pueda contener por sí solo.

## 5. La respuesta

1. Contener: detener primero la propagación, aislar el sistema, revocar la credencial, bloquear la dirección, poner el servicio fuera de línea si hace falta; contención antes que comprensión.
2. Evaluar: establecer qué ocurrió, qué está afectado, si hay datos personales o de clientes implicados y desde cuándo; anotarlo a medida que se conoce, con la hora de cada hallazgo.
3. Erradicar: eliminar la causa, el malware, la cuenta, la vulnerabilidad, la configuración errónea, y confirmar que ha desaparecido antes de restaurar nada.
4. Recuperar: restaurar desde copias de seguridad conocidas como buenas o reconstruir, verificar el servicio, vigilarlo de cerca los días siguientes y levantar las medidas de contención en orden.
5. Comunicar: mantener abierto un registro del incidente desde el primer minuto, informar a las personas de la empresa que deben actuar, e informar a clientes, autoridades y socios según exigen el plan y los relojes de abajo, en ese orden.

Herramientas: [por completar].

## 6. Notificaciones y relojes regulatorios

Cada reloj de abajo corre desde el momento del conocimiento, no desde el momento en que se encuentra la causa; el responsable anota ese momento en el registro cuando se declara el incidente.

[No se seleccionó ningún reglamento. Si la empresa trata datos personales, es una entidad esencial o importante, fabrica un producto con elementos digitales o presta servicio a entidades financieras, el reloj correspondiente va aquí.]

Fuera de la empresa informamos a: [por completar].

## 7. Evidencia

Desde el primer minuto el responsable conserva lo que una investigación posterior, una aseguradora, una autoridad o un tribunal pueden necesitar: el registro del incidente con horas, los registros y alertas como copias exportadas, imágenes de disco y memoria donde hubo un atacante, los mensajes enviados y recibidos, y las decisiones con quién las tomó; los originales se mantienen sin cambios, se trabaja sobre copias, y se anota la cadena de quién custodió qué.

## 8. Aprender del incidente

En los 10 días siguientes al cierre de un incidente de gravedad media o alta, [el responsable del incidente] celebra una revisión con las personas implicadas: qué ocurrió, qué funcionó, qué no, y qué control, procedimiento o formación lo permitió. Cada causa se convierte en una acción correctiva con un responsable y una fecha, y el incidente y sus acciones son una entrada de la siguiente revisión por la dirección.

## 9. Ejercicios

El plan se ejercita una vez al año como simulacro de mesa sobre un escenario escrito, con el responsable, el suplente y las personas que actuarían, y el plan se cambia donde el ejercicio lo muestre equivocado.

## 10. Registros

Cada evento notificado, se convirtiera en incidente o no, se registra con su fecha, su evaluación y su resultado; el registro del incidente, las notificaciones enviadas y la revisión se conservan como información documentada del sistema de gestión, a disposición de la entidad de certificación, y se cuentan en la revisión por la dirección.

Aprobado por [la dirección] el [fecha]. Revisado tras cada incidente de gravedad alta, tras cada ejercicio y al menos una vez al año.

Este plan se redacta a partir de las respuestas dadas. No es asesoramiento de certificación ni jurídico; la entidad de certificación lee el plan por los roles, el procedimiento, los registros y la evidencia de que se sigue, y los relojes regulatorios se leen frente a los propios reglamentos.

En StandardOS el expediente del incidente hace correr los relojes

Un incidente abierto en StandardOS lleva la hora del conocimiento, la gravedad, el registro y la evidencia, arranca los relojes del RGPD, NIS2 y CRA que se aplican a la empresa, redacta las notificaciones, abre las acciones correctivas de la revisión y cuenta el incidente en la siguiente revisión por la dirección.

El reloj de brechas del RGPDEl reloj de incidentes NIS2Los plazos de notificación del CRAEl registro de acción correctiva

Esta página en:EnglishDeutschFrançaisNederlandsDansk