Plan de Respuesta a Incidentes

¿Que es un plan de respuesta a incidentes?

241 días. Ese es el tiempo medio que una organización tarda en identificar y contener una brecha, según la edición de 2025 del Cost of a Data Breach de IBM —se nombra la edición a propósito: la de 2026 ya está publicada, y decir «la más reciente» convierte la frase en algo que caduca sin que nadie la toque—. La cifra ha bajado desde los 287 días que el mismo informe daba en 2021, así que conviene no citar ediciones antiguas como si fueran actuales — y no confundirla con el dwell time de Mandiant, que mide solo hasta la detección y se cuenta en días, no en meses. Conviene no acompañar esa cifra con los ahorros que circulan atribuidos al mismo informe —«54 días menos», «2,66 millones de dólares»—: no están en el PDF de la edición de 2025, y citarlos con esa fuente es fácil de desmontar. Lo que sí sostiene el informe es el dato de partida, y para el resto vale el argumento sin cifra: quien tiene el plan probado y sabe a quién llamar contiene antes. En España, el INCIBE gestiónó 97.348 ciberincidentes en 2024 y 122.223 en 2025, un incremento del 26 %, lo que refleja un panorama de amenazas en crecimiento constante. Sobre cuántas pymes tienen un plan documentado circulan porcentajes atribuidos a ENISA —«menos del 30 %» es el más repetido— que no aparecen en sus informes; es la misma familia que el «60 % de las pymes atacadas cierra en seis meses», que este sitio ya retiró por lo mismo. El argumento no necesita la cifra: sin plan, la contención se retrasa y, sobre todo, se pierde la evidencia. La ausencia de este plan no solo retrasa la contención del ataque, sino que compromete la preservación de la evidencia digital necesaria para acciones legales, reclamaciones al seguro y notificaciones obligatorias a la AEPD.

Un plan de respuesta a incidentes (IRP, Incident Response Plan) es un documento estrategico y operativo que define, antes de que ocurra un ciberincidente, quien hace que, cuando, como y con que herramientas. Se basa en marcos reconocidos como NIST SP 800-61 (Computer Security Incident Handling Guide) y establece procedimientos claros para cada fase del incidente: desde la detección inicial hasta las lecciones aprendidas posteriores.

Marco NIST SP 800-61: las cuatro fases de la respuesta a incidentes (y su estado actual)

El National Institute of Standards and Technology (NIST) publicó la guía SP 800-61 Revisión 2, que definió las cuatro fases que siguen siendo la referencia práctica en respuesta a incidentes. Conviene saber su estado antes de citarla en un informe: el NIST la retiró el 3 de abril de 2025 y la sustituyó por la Revisión 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management, que reordena la materia como perfil del Marco de Ciberseguridad (CSF) 2.0 en lugar de como ciclo de cuatro fases.

Las cuatro fases se explican aquí porque son el vocabulario que usan los equipos y los pliegos, y porque la Rev. 2 sigue siendo consultable; pero si se cita como norma vigente en un dictamen, la referencia correcta es la Rev. 3. Las fases son:

Fase 1: Preparación

La preparación es todo lo que se hace antes de que ocurra un incidente. Es la fase más importante y la que más organizaciones descuidan.

Elementos clave de la preparación:

Fase 2: Detección y análisis

Esta fase abarca desde la primera alerta hasta la confirmación de que se trata de un incidente real, su clasificación y su priorizacion.

Fuentes de detección:

• SIEM (Security Information and Event Management): Correlación de logs de múltiples fuentes para detectar patrones anómalos.
• EDR (Endpoint Detection and Response): Detección de comportamiento malicioso en endpoints (ejecución sospechosa, movimiento lateral, escalada de privilegios).
• IDS/IPS: Detección de tráfico de red anómalo (firmas de malware, comunicaciones C2, exfiltración).
• Alertas de usuarios: Empleados que reportan correos sospechosos, comportamiento inusual del sistema, o archivos cifrados.
• Inteligencia de amenazas: feeds externos (INCIBE-CERT, MISP, Open Threat Exchange —el antiguo AlienVault OTX, hoy operado por LevelBlue en la misma URL—) que alertan sobre campañas activas contra el sector.

Clasificación y priorizacion:

Documentación inicial del incidente:

FORMULARIO DE REPORTE DE INCIDENTE
===================================
ID Incidente: [identificador interno del expediente]
Fecha/Hora deteccion: 2026-02-10 08:15 UTC
Detectado por: SIEM (regla: multiple-failed-logins-admin)
Tipo sospechado: Compromiso de credenciales / Acceso no autorizado
Sistemas afectados: DC01.empresa.local, VPN Gateway
Severidad inicial: P2 (Alta)
Asignado a: [nombre y apellidos del responsable de respuesta]
Estado: En investigacion

Fase 3: Contención, erradicacion y recuperación

Esta es la fase operativa central donde se contiene el daño, se elimina la amenaza y se restauran los sistemas.

Contención a corto plazo (primeras horas):

Contención a largo plazo:

• Redirigir tráfico a traves de infraestructura limpia.
• Aplicar parches de emergencia a vulnerabilidades explotadas.
• Reforzar controles de acceso (MFA, rotación de credenciales).
• Desplegar agentes EDR adicionales para monitorización ampliada.

Erradicación:

• Eliminar malware de todos los sistemas afectados.
• Cerrar puertas traseras (backdoors) instaladas por el atacante.
• Identificar y remediar el vector de entrada original.
• Verificar que no existen mecanismos de persistencia (tareas programadas, servicios maliciosos, claves de registro).

Recuperación:

• Restaurar sistemas desde backups verificados (no comprometidos).
• Reconstruir sistemas comprometidos desde cero si es necesario.
• Monitorizar intensivamente durante 30-90 días post-recuperacion.
• Validar integridad de datos restaurados mediante hashes.

Fase 4: Actividad post-incidente (lecciones aprendidas)

Reunion post-mortem (realizar dentro de las 2 semanas posteriores al incidente):

Entregables post-incidente:

• Informe ejecutivo para dirección (resumen no técnico).
• Informe técnico detallado (timeline, IoCs, acciones tomadas).
• Informe pericial forense (si hay acciones legales o notificación AEPD).
• Plan de mejora con acciones correctivas priorizadas.

Roles del equipo de respuesta a incidentes

Estructura del equipo IR (CSIRT)

Playbooks: procedimientos por tipo de incidente

Un playbook es un documento operativo que detalla paso a paso las acciones a realizar ante un tipo específico de incidente. Cada organización debe adaptar sus playbooks a su infraestructura, pero la estructura general es común.

Playbook ransomware

PLAYBOOK: RANSOMWARE
=====================
Trigger: Deteccion de cifrado masivo de archivos, nota de rescate
Severidad: P1 (Critica)
Tiempo objetivo contencion: menos de 2 horas

PASO 1 - CONTENCION INMEDIATA (0-30 min)
  [ ] Aislar sistemas afectados de la red (NO apagar)
  [ ] Desactivar shares de red (SMB, NFS)
  [ ] Bloquear conexiones salientes sospechosas (C2)
  [ ] Capturar dump de memoria RAM de equipos cifrados
  [ ] Tomar snapshots de VMs afectadas
  [ ] Notificar IR Lead y perito forense

PASO 2 - EVALUACION ALCANCE (30 min - 2h)
  [ ] ¿Hay datos personales afectados? Si puede haberlos, ACTIVAR el
      analisis de brecha. Cuidado con el reloj: el art. 33.1 RGPD
      no corre desde la sospecha, sino desde que el responsable
      TIENE CONSTANCIA de una violacion de seguridad. Y no toda
      brecha se notifica: se exceptua cuando sea improbable que
      entrane un riesgo para los derechos y libertades
  [ ] Identificar variante ransomware (nota rescate, extension archivos)
  [ ] Determinar vector de entrada (phishing, RDP, vulnerabilidad)
  [ ] Mapear todos los sistemas afectados
  [ ] Verificar integridad de backups (no cifrados)
  [ ] Consultar No More Ransom (herramientas descifrado gratuitas)

PASO 3 - ERRADICACION (2h - 24h)
  [ ] Notificacion a la AEPD si hay datos personales afectados
      (art. 33 RGPD, dentro de las 72 h; si no se tiene aun todo el
       detalle se notifica igual y se completa despues)
  [ ] Valorar la comunicacion a los afectados (art. 34 RGPD) si hay
      alto riesgo para sus derechos
  [ ] Identificar y cerrar vector de entrada
  [ ] Eliminar malware de todos los sistemas afectados
  [ ] Verificar ausencia de persistencia (scheduled tasks, services)
  [ ] Rotar TODAS las credenciales del dominio
  [ ] Aplicar parches a vulnerabilidades explotadas

PASO 4 - RECUPERACION (24h - 7 dias)
  [ ] Restaurar desde backups verificados
  [ ] Reconstruir sistemas comprometidos si backups no disponibles
  [ ] Monitorizar 24/7 durante 30 dias post-recuperacion
  [ ] Validar integridad datos restaurados

PASO 5 - POST-INCIDENTE (7 - 14 dias)
  [ ] Informe pericial forense completo
  [ ] Denuncia ante Policia Nacional / Guardia Civil
  [ ] Reclamacion seguro cyber
  [ ] Reunion lecciones aprendidas
  [ ] Actualizar este playbook con mejoras

Playbook phishing/BEC

PLAYBOOK: PHISHING / BEC (Business Email Compromise)
=====================================================
Trigger: Empleado reporta email sospechoso o transferencia fraudulenta
Severidad: P2-P3 (depende de si hubo click/transferencia)

PASO 1 - TRIAJE (0-15 min)
  [ ] Confirmar si el usuario hizo click en enlace o abrio adjunto
  [ ] Si transfirió dinero: escalar a P1 y contactar banco inmediatamente
  [ ] Obtener headers del email (evidencia)
  [ ] Bloquear remitente en gateway de correo

PASO 2 - CONTENCION (15 min - 1h)
  [ ] Si click en enlace: resetear credenciales del usuario
  [ ] Si adjunto abierto: aislar equipo y escanear con EDR
  [ ] Buscar otros destinatarios del mismo email (IoC en logs)
  [ ] Bloquear dominio/IP del phishing en firewall y proxy

PASO 3 - INVESTIGACION (1h - 4h)
  [ ] Analizar headers email (origen real, SPF/DKIM/DMARC)
  [ ] Analizar URL/adjunto en sandbox
  [ ] Verificar si hubo movimiento lateral post-compromiso
  [ ] Documentar toda la evidencia preservando cadena de custodia

Forensic readiness: preparación forense proactiva

La forensic readiness (preparación forense) es la capacidad de una organización de maximizar la recopilación de evidencia digital útil mientras minimiza el coste de la investigación forense. Se implementa como parte de la fase de preparación del plan de respuesta a incidentes.

Configuraciones esenciales:

Sincronización de relojes (NTP): Todos los sistemas deben estar sincronizados con la misma fuente de tiempo NTP. Sin sincronización precisa, la correlación de eventos entre diferentes sistemas durante la investigación forense se vuelve imprecisa o imposible.

Caso práctico: respuesta a incidente ransomware en pyme española

Contexto: Una pyme de 45 empleados del sector logístico en España sufre un ataque de ransomware un viernes a las 19:30 (fuera de horario laboral). Los atacantes cifran 3 servidores de producción y exigen 2.5 BTC (aproximadamente 160.000 euros).

Cronología del incidente y respuesta:

Viernes 19:30 - Compromiso inicial
  Vector: Credenciales RDP expuestas a internet (puerto 3389)
  Atacante: IP 185.220.xxx.xxx (nodo Tor de salida)
  Accion: Login como Administrador via RDP sin MFA

Viernes 19:30-21:00 - Movimiento lateral
  Atacante enumera red interna (Nmap, ADRecon)
  Desactiva Windows Defender via GPO
  Obtiene hash NTLM del Domain Admin (Mimikatz)
  Accede a 3 servidores criticos: DC01, FILE01, ERP01

Viernes 21:00-23:00 - Despliegue ransomware
  Ransomware: LockBit 3.0 (builder filtrado)
  Cifrado: AES para el contenido; el keygen del builder filtrado genera RSA-1024, no 2048
  Archivos cifrados: 480 GB (146.000 archivos)
  Nota de rescate: "README.txt" en cada carpeta

Sabado 07:15 - Deteccion
  Empleado de guardia detecta que no puede acceder al ERP
  Notifica al responsable de TI via telefono

Sabado 07:30 - Activacion del plan de respuesta
  TI contacta a perito informatico forense (contrato retainer)
  Perito llega en 2 horas (09:30)

Respuesta del perito forense:

Sabado 09:30-11:00 - Preservacion de evidencia
  1. Dump memoria RAM de DC01 (32 GB) via WinPmem
  2. Dump memoria RAM de FILE01 y ERP01
  3. Captura de logs de Windows Event Log (Security, System)
  4. Copia forense del disco de DC01 (imagen bit-a-bit con FTK Imager)
  5. Exportacion logs de firewall (ultimos 7 dias)
  6. Documentacion fotografica de las notas de rescate

Sabado 11:00-14:00 - Analisis inicial
  1. Identificacion variante: LockBit 3.0
  2. Vector entrada: RDP expuesto + credenciales debiles
  3. Timeline del ataque: viernes 19:30 a 23:00
  4. Herramientas del atacante: Mimikatz, Nmap, ADRecon, PsExec
  5. Exfiltracion: NO detectada (no habia EDR para confirmarlo)

Sabado 14:00 - Evaluacion de backups
  Backup en NAS local: CIFRADO (atacante accedio via red)
  Backup cloud (Azure): INTACTO (ultimo backup viernes 18:00)
  Datos perdidos: 1.5 horas de transacciones (18:00-19:30)

Sabado 14:30 - Decision: NO pagar rescate
  Razon: Backups cloud disponibles, perdida de datos minima

Recuperación:

Sabado-Domingo: Reconstruccion
  1. Servidores reconstruidos desde cero (no restaurar sobre comprometidos)
  2. Datos restaurados desde backup Azure
  3. RDP cerrado a internet (acceso solo via VPN con MFA)
  4. Credenciales de TODOS los usuarios rotadas
  5. EDR desplegado en todos los endpoints (CrowdStrike Falcon)

Lunes 08:00: Negocio operativo
  Tiempo total de inactividad: 60 horas (viernes 19:30 - lunes 08:00)
  Datos perdidos: 1.5 horas de transacciones
  Coste estimado: 35.000 EUR (tiempo inactividad + perito + mejoras)
  Coste evitado (no pagar rescate): 160.000 EUR

Acciones post-incidente:

• Informe pericial forense presentado ante Policía Nacional (denuncia).
• Notificación a AEPD dentro de las 72 horas (datos personales en FILE01).
• Reclamación al seguro cyber: 28.000 EUR cubiertos, el 80 % del coste estimado.
• Plan de mejora: MFA obligatorio, EDR, backup 3-2-1, VPN para acceso remoto.

Marco legal en España

Directiva NIS2 (UE 2022/2555)

La Directiva NIS2 amplía las obligaciones de gestión de ciberincidentes. Sobre su situación en España conviene ser exacto y no hablar de una transposición «futura»: el plazo europeo venció el 17 de octubre de 2024, y el 8 de julio de 2026 la Comisión remitió a España al Tribunal de Justicia por no haber notificado la transposición completa. Lo exigible hoy en España sigue siendo, por tanto, el marco de NIS1 —Real Decreto-ley 12/2018 y Real Decreto 43/2021—, no NIS2 directamente.

• Entidades esenciales e importantes: el art. 21 exige medidas de gestión de riesgos adecuadas y proporcionadas que cubran, entre otros ámbitos, la gestión de incidentes. No prescribe un documento con un nombre concreto.
• Notificación de incidentes significativos —ese es el presupuesto, no cualquier incidente—: alerta temprana en 24 horas, notificación del incidente con evaluación inicial de gravedad e impacto en 72 horas, e informe final en un mes. El informe intermedio no tiene plazo automático: se emite si lo pide el CSIRT o la autoridad.
• Sanciones: la Directiva no fija una multa española «hasta» una cifra: obliga a que el máximo nacional sea al menos 10 millones de euros o el 2 % de la facturación mundial —el que sea mayor— para las entidades esenciales, y al menos 7 millones o el 1,4 % para las importantes.
• Responsabilidad de la dirección: el art. 20 exige que el órgano de dirección apruebe las medidas del art. 21, supervise su aplicación y responda del incumplimiento de la entidad, además de formarse. No convierte cualquier incidente en responsabilidad personal de sus miembros, ni establece por sí mismo una sanción individual.

Real Decreto-ley 12/2018 (Directiva NIS)

Actualmente en vigor, transpone la primera Directiva NIS y establece obligaciones para operadores de servicios esenciales y proveedores de servicios digitales, incluyendo la obligación de gestionar y notificar incidentes al CSIRT de referencia (INCIBE-CERT para empresas privadas, CCN-CERT para sector público).

RGPD (Reglamento UE 2016/679)

• Artículo 33: Notificación de brechas de datos personales a la autoridad de control (AEPD) en un plazo máximo de 72 horas desde su conocimiento.
• Artículo 34: comunicación a los afectados sin dilación indebida —no en 72 horas: ese plazo es solo del art. 33— y únicamente cuando sea probable un alto riesgo para sus derechos y libertades, con las excepciones que el propio precepto contempla.
• Sanciones: los arts. 33 y 34 pertenecen al grupo de los arts. 25 a 39, cuya infracción entra en el art. 83.4: hasta 10 millones de euros o el 2 % de la facturación mundial, el que sea mayor. Los 20 millones o el 4 % son el art. 83.5, que cubre otras infracciones.

En la practica, cumplir con el plazo de 72 horas del RGPD requiere tener un plan de respuesta a incidentes operativo. Sin el, la organización difcilmente podra evaluar el alcance de la brecha y preparar la notificación en tiempo.

Código Penal y denuncia

El plan de respuesta a incidentes debe contemplar la denuncia ante las Fuerzas y Cuerpos de Seguridad del Estado:

• Policía Nacional: Unidad Central de Ciberdelincuencia, creada en 2023 y estructurada en tres brigadas. La antigua Brigada Central de Investigación Tecnológica (BCIT) ya no es la denominación vigente.
• Guardia Civil: la unidad especializada en ciberdelincuencia, encuadrada en la Unidad Central Operativa. Se la conoce como Departamento Contra el Cibercrimen (antes GDT); la denuncia puede presentarse en cualquier puesto; el trámite telemático está acotado a un conjunto tasado de supuestos —daños, hurtos, pérdida o localización de documentación, sustracción de vehículo y poco más— y no cubre la mayoría de los ciberincidentes empresariales (canal telemático, y en el escrito basta con dirigirla a la Guardia Civil sin depender del nombre de la unidad.
• El informe pericial forense elaborado durante la respuesta al incidente es fundamental para respaldar la denuncia y la investigación policial.

Herramientas relacionadas

Herramientas de detección y monitorización

Herramientas de preservación de evidencia

Frameworks y playbooks

Relación con otros conceptos

• Ransomware: El ransomware es uno de los incidentes más críticos que un plan de respuesta debe contemplar. El playbook de ransomware es frecuentemente el primero que las organizaciones desarrollan, dado el impacto devastador que este tipo de ataque puede tener en la operativa del negocio.

• ISO 27037: Esta norma internacional establece las directrices para la recopilación y preservación de evidencia digital. El plan de respuesta a incidentes debe incorporar los procedimientos de la ISO 27037 para garantizar que la evidencia recopilada durante la respuesta sea admisible judicialmente.

• Evidencia Digital: La preservación de evidencia digital es un objetivo transversal a todas las fases de la respuesta a incidentes. Cada acción tomada durante la respuesta debe documentarse y cada artefacto forense debe preservarse siguiendo la cadena de custodia.

• Cadena de Custodia: La cadena de custodia documenta quien tuvo acceso a la evidencia digital, cuando y que acciones realizo. Un plan de respuesta a incidentes robusto integra procedimientos de cadena de custodia desde la fase de contención, garantizando que cada imagen forense, dump de memoria y log exportado mantiene su integridad probatoria.

FAQ

P: ¿Que diferencia hay entre un plan de respuesta a incidentes y un plan de continuidad de negocio? R: El plan de respuesta a incidentes (IRP) se centra en detectar, contener y erradicar la amenaza, así como en preservar la evidencia. El plan de continuidad de negocio (BCP) se centra en mantener las operaciones críticas durante y después del incidente. Ambos son complementarios: el IRP gestiona la amenaza técnica mientras el BCP gestiona el impacto en el negocio.

P: ¿Con que frecuencia debe probarse el plan de respuesta a incidentes? R: Mínimo una vez al año mediante un ejercicio tabletop (simulación en mesa) y, idealmente, un simulacro técnico completo. Además, el plan debe revisarse y actualizarse tras cada incidente real y cuando haya cambios significativos en la infraestructura.

P: ¿Una pyme de 10 empleados necesita un plan de respuesta a incidentes? R: Si. Aunque el plan sera más sencillo que el de una gran empresa, incluso una pyme necesita saber a quien llamar, que NO hacer (no apagar equipos, no borrar nada) y como preservar la evidencia básica. Un plan de 2-3 páginas con contactos del perito forense, pasos iniciales y protocolo de comunicación ya marca una diferencia critica.

P: ¿Cuánto cuesta implementar un plan de respuesta a incidentes? R: Depende del tamaño de la organización. Para una pyme, un perito informático puede elaborar un plan básico con playbooks por 2.000-5.000 euros. Para empresas medianas, con formación y simulacros incluidos, entre 8.000-20.000 euros. No se da aquí una cifra de coste medio de un ataque en España: ni IBM lo desglosa por país ni el INCIBE lo publica, y este mismo corpus ya la retiró de otro artículo por eso. El coste de un ataque de ransomware en España supera los 100.000 euros, lo que convierte al plan en una inversión con retorno claro.

Referencias y Fuentes

1. NIST (2025). SP 800-61 Rev. 3 — Incident Response Recommendations and Considerations for Cybersecurity Risk Management, que sustituye a la Rev. 2 Computer Security Incident Handling Guide (2012) y reordena la materia como perfil del CSF 2.0: el ciclo clásico de cuatro fases que suele atribuírsele es el que la propia Rev. 3 presenta como modelo previo, no como su propuesta. retirada el 3 de abril de 2025. nist.gov — Guía de referencia mundial para la gestión de incidentes de seguridad informática. Define las 4 fases: preparación, detección/análisis, contención/erradicacion/recuperación, y post-incidente.

2. IBM Security — Cost of a Data Breach Report. ⚠️ Esa URL no lleva año y sirve siempre la última edición —su <title> dice hoy «Cost of a Data Breach Report 2026»—, así que el año se comprueba abriéndola. ⚠️ Este apunte atribuía a la edición de 2024 un tiempo medio de identificación y contención de 287 días. Son los de 2021, como explica el cuerpo de este mismo artículo 441 líneas más arriba: la cifra vigente son 241 días. El propio párrafo avisaba de que «conviene no citar ediciones antiguas como si fueran actuales» — y su bibliografía hacía exactamente eso.

3. INCIBE — Balance de ciberseguridad 2025: 122.223 ciberincidentes gestionados en España en 2025, un 26 % más que en 2024, de los que 55.411 fueron malware y 45.445 fraude online. (La cifra es de 2025, no de 2024: el Balance de 2024 dio 97.348 incidentes. Son dos documentos distintos y conviene no cruzarlos.)

4. ENISA. NIS Investments 2024 (22 nov 2024). enisa.europa.eu — la muestra son 1.350 entidades del ámbito NIS2 de 27 Estados miembros —la figura 97 del PDF la reparte en 80 % grandes empresas y 20 % pymes; el 83/17 que circula no aparece en el documento—, no las pymes europeas en general, y el informe no mide planes de respuesta documentados. Lo que sí recoge: autoevaluación de capacidad de detección y respuesta ante ataques sofisticados 6,9/10 (banca 8,1 · salud 7,6 · energía 7,2 y transporte 7,1 —el informe los agrupa primero y los separa después— · aguas residuales 4,4), y que un 34 % de pymes no podrá financiar el cumplimiento de NIS2.

5. ENISA — SME CRA Survey Report (junio de 2026), la encuesta que sí mide planes de respuesta documentados en pymes europeas, sobre 194 respuestas. ⚠️ Las cifras que suelen citarse son cuatro de las seis filas de la pregunta 8.1, de modo que no forman un reparto completo: faltan un 4,64 % y un 0,52 %. Las cuatro publicadas: 19,07 % no tiene ningún plan, 29,90 % tiene uno básico e informal, 29,38 % lo tiene documentado y solo 6,70 % lo prueba, revisa y mejora. Entre las microempresas, 36 % carece de plan; entre las medianas, 43 % lo tiene documentado y 21 % lo prueba o lo integra en su gobernanza. La pregunta se refiere a incidentes relativos a sus productos, en el marco del Reglamento de Ciberresiliencia: conviene decirlo al citarla.

6. Parlamento Europeo. (2022). “Directiva (UE) 2022/2555 relativa a medidas para un elevado nivel común de ciberseguridad (NIS2)”. texto en EUR-Lex ⚠️ (la URL con ?uri=CELEX: devuelve una carcasa de WAF, no el instrumento; se usa la forma ELI) — Obligaciones ampliadas de gestión y notificación de incidentes para entidades esenciales e importantes.

7. RGPD. (2016). “Reglamento (UE) 2016/679 relativo a la protección de datos personales”. texto en EUR-Lex ⚠️ (la forma ?uri=CELEX: devuelve una carcasa de WAF) — Artículo 33: notificación a la autoridad de control en 72 horas desde que se tiene constancia. Artículo 34: comunicación a los afectados sin dilación indebida y solo si es probable un alto riesgo — **no contiene el plazo de 72 horas.

8. Kral, Patrick / SANS Institute (aceptado en diciembre de 2011, publicado en febrero de 2012). Incident Handler’s Handbook — describe seis fases (PICERL), no las cuatro del NIST. sans.org — Manual práctico con templates, checklists y mejores prácticas para equipos de respuesta a incidentes.

9. MITRE ATT&CK® — base de conocimiento de tácticas y técnicas de adversarios (matriz Enterprise, versionado continuo; no publica ediciones anuales). Referencia para documentar las TTP. Esencial para documentar las TTPs utilizadas en un incidente.

10. Real Decreto-ley 12/2018. Transposición de la Directiva NIS al ordenamiento jurídico español. boe.es — Obligaciones de gestión y notificación de incidentes para operadores de servicios esenciales.

11. CCN-CERT. CCN-STIC-817 — Esquema Nacional de Seguridad. Gestión de Ciberincidentes (abril 2020). ccn-cert.cni.es — 36 tipos de ciberincidente, 5 niveles de peligrosidad y la metodología de notificación al CCN-CERT mediante la herramienta LUCIA.

12. Código Penal español. Arts. 197 (revelación de secretos), 264 (daños informáticos), 264 bis (obstaculización de sistemas). boe.es

13. AEPD (junio de 2021). Guía para la notificación de brechas de datos personales —ése es su título y su versión; el PDF que sirve esa URL no es de 2024—. aepd.es — Guía practica de la Agencia Española de Protección de Datos para la gestión y notificación de brechas.

Última actualización: 10 Febrero 2026 Categoría: Seguridad (PRI-001) Nivel técnico: Intermedio-Avanzado Relevancia forense: MUY ALTA (plan necesario para preservar evidencia desde el primer momento)