Un ciberataque, un correo enviado al destinatario equivocado, un portátil robado o un fallo en la copia de seguridad: cualquiera de estas situaciones puede convertirse en una brecha de seguridad de datos personales con consecuencias legales, reputacionales y operativas. La diferencia entre gestionar el incidente con daño mínimo o sufrir un impacto grave suele residir en una sola cosa: disponer de un protocolo de gestión de incidentes de seguridad activado, documentado y ensayado antes de que el problema ocurra.
El Reglamento (UE) 2016/679 (RGPD) y la Ley Orgánica 3/2018 (LOPDGDD) no exigen un formato concreto de protocolo, pero sí obligan a los responsables del tratamiento a adoptar medidas técnicas y organizativas apropiadas para responder ante incidentes, a notificar las brechas a la AEPD en 72 horas cuando sea necesario y a documentar todo el proceso. Este artículo describe las seis fases de un plan de respuesta ante brechas de seguridad que las empresas pueden adaptar a su tamaño y sector.
¿Qué es un protocolo de gestión de incidentes de seguridad?
Un protocolo de gestión de incidentes de seguridad (o plan de respuesta a incidentes) es el conjunto de procedimientos, roles y decisiones predefinidos que una organización activa cuando se detecta o sospecha que se ha producido un incidente que afecta a la confidencialidad, integridad o disponibilidad de sus sistemas o datos. En el ámbito del RGPD, el foco se sitúa en los datos personales, pero un buen protocolo abarca también activos corporativos, sistemas operativos y continuidad del negocio.
Disponer de este documento no es solo una buena práctica de ciberseguridad: el artículo 32 del RGPD exige que el responsable adopte medidas técnicas y organizativas apropiadas, y el artículo 33.5 obliga a documentar todas las violaciones de seguridad, se notifiquen o no. La ausencia de procedimientos documentados agrava la valoración de la AEPD en caso de inspección o denuncia.
Fase 1 — Detección e identificación del incidente
La primera fase del procedimiento de brecha de seguridad consiste en detectar que algo ha ocurrido y clasificarlo correctamente. No todos los eventos de seguridad son incidentes, y no todos los incidentes son brechas de datos personales. La distinción importa porque activa plazos legales.
Fuentes habituales de detección
- Alertas de sistemas SIEM (Security Information and Event Management) o EDR (Endpoint Detection and Response).
- Notificación interna de un empleado (un correo recibido por error, un dispositivo extraviado).
- Comunicación de un proveedor o encargado del tratamiento que gestiona datos por cuenta de la empresa.
- Aviso de un cliente o usuario sobre un acceso no autorizado a su cuenta.
- Detección de malware o ransomware por parte del equipo técnico.
- Notificación del INCIBE-CERT (Instituto Nacional de Ciberseguridad) ante incidentes de escala sectorial.
Activación del equipo de respuesta
En cuanto se detecta un posible incidente, el protocolo debe activar un equipo de respuesta con roles definidos: un responsable de coordinar la respuesta técnica, el delegado de protección de datos (DPO) o el responsable de cumplimiento, la dirección de la empresa y, si procede, el departamento legal y de comunicación. La cadena de notificación interna debe estar escrita en el protocolo para que no haya dudas sobre a quién avisar en primer lugar.
El plazo de 72 horas del artículo 33 del RGPD empieza a contar desde el momento en que el responsable tiene constancia de la brecha. Por eso es crítico registrar la fecha y la hora exactas en que se detectó el incidente. Cada minuto de retraso en activar el protocolo es un minuto que se descuenta de ese plazo.
Fase 2 — Contención del incidente
Una vez identificado el incidente, la prioridad es detener la hemorragia: evitar que el daño se extienda a más sistemas o afecte a más datos. La contención se divide en dos niveles.
Contención inmediata
Las medidas de contención inmediata tienen como objetivo aislar el problema lo antes posible, aunque sean provisionales:
- Desconectar de la red los sistemas comprometidos sin apagarlos (para preservar evidencias forenses).
- Revocar credenciales comprometidas o sospechosas de ser comprometidas.
- Bloquear el acceso al recurso afectado (carpeta compartida, base de datos, buzón de correo).
- Suspender temporalmente el proceso de tratamiento que originó el incidente.
Contención a largo plazo
Una vez estabilizado el entorno, se aplican medidas más definitivas: parchear la vulnerabilidad explotada, reforzar la segmentación de red, restaurar sistemas desde copias de seguridad limpias y validar que no quedan puertas traseras activas. Esta fase puede durar días o semanas y debe realizarse de forma paralela al resto del protocolo.
Fase 3 — Evaluación del riesgo para los derechos y libertades de los afectados
La evaluación del riesgo es la fase que determina las obligaciones legales que se activan. El artículo 33.1 del RGPD exige notificar a la autoridad de control salvo que sea improbable que la brecha suponga un riesgo para los derechos y libertades de las personas físicas. El artículo 34.1 exige comunicar a los propios afectados cuando ese riesgo es alto.
La siguiente tabla resume los tres umbrales y las obligaciones asociadas:
| Nivel de riesgo | Criterios orientativos | Obligación RGPD |
|---|---|---|
| Sin riesgo relevante | Datos cifrados con clave no accesible; incidente sin acceso externo; número mínimo de afectados; datos no sensibles | Solo registro interno (art. 33.5) |
| Riesgo probable | Datos personales accesibles; posibilidad de daño económico, reputacional o discriminatorio; número relevante de afectados | Notificación a la AEPD en 72 h (art. 33) |
| Riesgo alto | Categorías especiales (salud, ideología, condenas penales); datos bancarios; perfil completo de personas; posibilidad de fraude o suplantación a gran escala | Notificación a la AEPD + comunicación a los afectados (arts. 33 y 34) |
La AEPD ha publicado una herramienta orientativa de valoración de riesgo que ayuda a encuadrar el incidente en uno de estos niveles. No tiene carácter vinculante, pero documenta el razonamiento de la organización y reduce la exposición en caso de inspección posterior.
Fase 4 — Notificación según los artículos 33 y 34 del RGPD
Si la evaluación determina que existe riesgo relevante, se activan las obligaciones de notificación reguladas en el RGPD. Es conveniente coordinar esta fase con asesoramiento especializado: desde Summum Consultoría acompañamos a las organizaciones en la gestión y notificación de brechas de seguridad, con protocolos adaptados al sector y tamaño de cada empresa.
Notificación a la AEPD (artículo 33 del RGPD)
El responsable del tratamiento debe notificar la brecha a la AEPD sin dilación indebida y, de ser posible, en el plazo de 72 horas desde que tuvo constancia del incidente. Si no es posible cumplir ese plazo, la notificación debe acompañarse de una justificación de la demora.
El contenido mínimo de la notificación, según el artículo 33.3 del RGPD, incluye:
- Naturaleza de la violación: tipo (confidencialidad, integridad, disponibilidad), categorías de datos afectados y número aproximado de registros e interesados.
- Datos de contacto del DPO o del punto de contacto designado.
- Consecuencias probables de la violación.
- Medidas adoptadas o propuestas para remediar la brecha y mitigar sus efectos.
El artículo 33.4 permite facilitar la información de manera gradual cuando no está disponible toda en el momento de la notificación. Es preferible notificar en plazo con información parcial y completarla después que esperar a tener todos los datos y superar el plazo de 72 horas.
Para ampliar el detalle sobre el procedimiento de notificación a la AEPD, puede consultar nuestro artículo Cómo notificar una brecha de seguridad a la AEPD en 72 horas.
Comunicación a los afectados (artículo 34 del RGPD)
Cuando la evaluación concluye que la brecha entraña un riesgo alto para los derechos y libertades de las personas, el responsable debe comunicarla también a los propios afectados, sin dilación indebida. Esta comunicación debe redactarse en lenguaje claro y sencillo y describir:
- La naturaleza de la violación de seguridad.
- Los posibles efectos sobre los afectados.
- Las medidas adoptadas o recomendadas para mitigar el daño (por ejemplo, cambiar contraseñas, activar el doble factor de autenticación o bloquear tarjetas).
- Los datos de contacto del DPO o del responsable de atención a afectados.
No es necesario comunicar a los afectados si los datos estaban cifrados con clave no accesible para el atacante, si las medidas aplicadas eliminan el riesgo alto, o si la comunicación individual exigiría un esfuerzo desproporcionado, en cuyo caso puede sustituirse por una comunicación pública (art. 34.3 RGPD).
Fase 5 — Registro interno de brechas
Con independencia de si la brecha se notifica o no a la AEPD, el artículo 33.5 del RGPD obliga al responsable a documentar todas las violaciones de seguridad en un registro interno. Este registro es el principal elemento de prueba de que la organización actuó con diligencia y debe conservarse durante el tiempo suficiente para que la AEPD pueda verificarlo en una eventual inspección.
El registro interno de brechas debe incluir, como mínimo:
- Fecha y hora de detección y de inicio de la contención.
- Descripción de los hechos: qué ocurrió, qué sistemas estaban implicados y cómo se detectó.
- Tipo de brecha (confidencialidad, integridad, disponibilidad) y datos afectados.
- Número aproximado de interesados afectados y categorías de datos comprometidos.
- Evaluación del nivel de riesgo, con la justificación del razonamiento.
- Decisión sobre notificación a la AEPD (con fecha de envío o justificación de no notificar).
- Decisión sobre comunicación a los afectados (con fecha o justificación de la excepción aplicada).
- Medidas de contención, recuperación y mejora adoptadas.
- Persona responsable de la gestión del incidente.
El registro no tiene un formato oficial, pero la AEPD recomienda mantenerlo actualizado y estructurado. Muchas organizaciones lo integran en su sistema de gestión de seguridad de la información (SGSI), especialmente si tienen implantado el esquema de la norma ISO/IEC 27001.
Fase 6 — Lecciones aprendidas y mejora continua
Una vez resuelto el incidente, la última fase del protocolo de gestión de incidentes de seguridad consiste en analizar qué ocurrió, por qué y cómo evitar que se repita. Esta revisión debe realizarse con todos los implicados: equipo técnico, DPO, dirección y, en su caso, el proveedor o encargado del tratamiento que participó en el incidente.
Las preguntas clave del análisis post-mortem son:
- ¿Cuál fue el vector de entrada o la causa raíz del incidente?
- ¿El protocolo funcionó como estaba diseñado o hubo cuellos de botella?
- ¿Los plazos de detección y notificación fueron adecuados o hubo retrasos evitables?
- ¿Las medidas técnicas existentes (cifrado, control de accesos, copias de seguridad) resultaron suficientes?
- ¿Qué mejoras deben incorporarse al protocolo, a la formación del personal o a la infraestructura técnica?
Las conclusiones del análisis deben trasladarse a un plan de acción con responsables y plazos, y las mejoras más relevantes deben incorporarse a la siguiente revisión del protocolo. Este ciclo de mejora continua es, precisamente, el espíritu del artículo 32 del RGPD: las medidas técnicas y organizativas no son estáticas, deben revisarse periódicamente.
El nexo entre ciberseguridad y protección de datos
Un protocolo de gestión de incidentes eficaz no puede vivir solo en el departamento legal o de cumplimiento normativo: necesita estar integrado con las medidas de ciberseguridad de la organización. La mayoría de las brechas de seguridad que afectan a datos personales tienen un origen técnico (vulnerabilidades no parcheadas, contraseñas débiles, phishing, ransomware) que el equipo de sistemas debe abordar.
En el plano normativo, el Esquema Nacional de Seguridad (ENS) —obligatorio para entidades del sector público y sus proveedores— recoge en su Anexo II un catálogo de medidas de seguridad que incluyen la gestión de incidentes como categoría propia. Para las empresas privadas, la norma ISO/IEC 27001 establece controles equivalentes en su Anexo A. Ambos marcos son compatibles con los requisitos del RGPD y permiten construir un sistema de gestión de seguridad de la información que responda simultáneamente a las exigencias legales de protección de datos y a las buenas prácticas de ciberseguridad.
Las ayudas del Kit Digital (programa de digitalización de pymes) incluyen la solución de Ciberseguridad, que puede financiar la implantación de herramientas de detección y respuesta ante incidentes. Las organizaciones que acceden a estas ayudas deben acreditar que las herramientas instaladas cumplen con los requisitos del RGPD en cuanto al tratamiento de datos personales que generan (registros de actividad, alertas, accesos de los usuarios).
El equipo de Sistemas de Summum Consultoría trabaja de forma coordinada con el equipo de consultoría jurídica para ofrecer una visión integrada: no solo la herramienta técnica, sino también el protocolo de respuesta y la documentación que exige el RGPD. Si quieres revisar tu plan de respuesta ante brechas o necesitas acompañamiento en la gestión de un incidente activo, el equipo especializado de Summum Consultoría está disponible para organizaciones en Castilla y León (Valladolid, Burgos, Palencia, Aranda de Duero) y Canarias (Las Palmas). Puedes conocer nuestro servicio de gestión y notificación de brechas de seguridad o consultar qué dice exactamente el RGPD sobre la definición de brecha en nuestro artículo sobre qué es una brecha de seguridad según el RGPD.
Preguntas frecuentes
¿Qué diferencia hay entre un incidente de seguridad y una brecha de seguridad?
Un incidente de seguridad es cualquier evento que compromete la confidencialidad, integridad o disponibilidad de un sistema o activo. Una brecha de seguridad, en el sentido del artículo 4.12 del RGPD, es un incidente que afecta específicamente a datos personales: su destrucción, pérdida, alteración, comunicación o acceso no autorizados. Todo incidente que afecta a datos personales puede ser una brecha, pero no todo incidente informático lo es si no hay datos personales implicados.
¿Debe tener el protocolo de gestión de incidentes un formato oficial?
No existe un modelo normalizado de obligado cumplimiento impuesto por el RGPD ni por la LOPDGDD para el protocolo de gestión de incidentes. La normativa exige disponer de medidas técnicas y organizativas apropiadas (art. 32 RGPD) y documentar todas las violaciones de seguridad (art. 33.5 RGPD), pero deja libertad de formato. Lo relevante es que el protocolo esté escrito, sea conocido por las personas implicadas, haya sido probado al menos una vez y se actualice periódicamente. La ausencia total de documentación es el escenario que más pesa en una resolución sancionadora.
¿Cuánto tiempo hay que conservar el registro interno de brechas?
El RGPD no fija un plazo de conservación específico para el registro de brechas; el responsable debe definirlo en función de la responsabilidad proactiva (artículo 5.2 del RGPD). Como referencia orientativa, conviene conservarlo mientras la AEPD pueda requerirlo en una investigación. Los plazos de prescripción de las infracciones se regulan en el artículo 78 de la LOPDGDD: 3 años para las muy graves, 2 años para las graves y 1 año para las leves.
¿Qué ocurre si el responsable del tratamiento no tiene DPO y sufre una brecha?
La obligación de notificar a la AEPD y de comunicar a los afectados recae sobre el responsable del tratamiento con independencia de si tiene o no delegado de protección de datos. Si la organización no está obligada a designar DPO por el artículo 37 del RGPD, debe igualmente gestionar la brecha y, si procede, notificarla. En ese caso, el punto de contacto con la AEPD puede ser la dirección o la persona responsable de cumplimiento. Lo que no cambia es el plazo (72 horas) ni el contenido mínimo de la notificación. Tener un protocolo documentado y un responsable interno designado —aunque no sea DPO formal— reduce significativamente el riesgo de incumplimiento.