Playbook de 72 horas para CISO ante violaciones de datos personales bajo GDPR
Son las 2:13 de la madrugada de un martes cuando salta la alerta.
Maria, CISO de una plataforma SaaS FinTech en rápido crecimiento, se despierta por un escalado del SOC: se están realizando consultas anómalas a la base de datos desde una cuenta de desarrollador. La cuenta ha accedido a tablas que contienen nombres de clientes, correos electrónicos, historiales de transacciones y números nacionales de identificación. En cuestión de minutos, el equipo confirma que las credenciales del desarrollador fueron robadas mediante un ataque de phishing. La ventana de exposición no está clara. La intención del atacante es desconocida. El alcance del impacto todavía se está calculando.
El reloj empieza ahora.
Para el GDPR, Maria puede disponer de 72 horas para notificar a una autoridad de control si es probable que el incidente entrañe un riesgo para las personas. Para NIS2, si la empresa es una entidad esencial o importante y el incidente es significativo, puede exigirse una alerta temprana en un plazo de 24 horas y una notificación formal en un plazo de 72 horas. Para DORA, también pueden activarse la notificación de incidentes de TIC en el sector financiero y las obligaciones de resiliencia operativa. Clientes, aseguradoras, asesores jurídicos, alta dirección y auditores querrán respuestas.
Este es el momento en que un plan genérico de respuesta a incidentes suele fallar. Un procedimiento operativo contra malware puede explicar el aislamiento de hosts. Un procedimiento del SOC puede explicar la conservación de registros. Pero un proceso de gestión de violaciones de datos personales conforme a ISO/IEC 27701:2025 debe responder bajo presión a preguntas más difíciles:
- ¿Se han expuesto, alterado, perdido, destruido o accedido sin autorización datos personales?
- ¿La organización actúa como responsable del tratamiento, encargado del tratamiento, corresponsable del tratamiento o subencargado?
- ¿Cuándo se tuvo conocimiento del hecho y qué evidencias lo prueban?
- ¿Es obligatoria la notificación regulatoria conforme al GDPR Article 33?
- ¿Las personas afectadas están expuestas a un alto riesgo conforme al GDPR Article 34?
- Si se actúa como encargado del tratamiento, ¿con qué rapidez debe notificarse al responsable del tratamiento?
- ¿Qué evidencias probarán la decisión seis meses después durante una auditoría?
La diferencia entre el caos y el control no está en el número de herramientas de seguridad del entorno. Está en si la organización ha construido un Sistema de Gestión de la Información de Privacidad, o PIMS, disciplinado, que conecte la respuesta a incidentes, la gobernanza de privacidad, la gestión de evidencias, el escalado de proveedores y la notificación regulatoria en un único ciclo de vida defendible.
La gestión de violaciones empieza antes de que alguien diga “violación de datos”
El primer error operativo es asumir que la gestión de violaciones de datos personales empieza solo después de que Legal confirme una violación de datos personales. En realidad, el proceso empieza cuando una persona, sistema, proveedor o cliente detecta algo que podría implicar datos personales.
Zenith Blueprint: hoja de ruta de 30 pasos para auditores de Clarysec Zenith Blueprint sitúa este desencadenante humano en la fase Controles en acción, paso 16: Controles sobre las personas II. La guía indica:
“Un sistema eficaz de respuesta a incidentes no empieza con herramientas, sino con personas. Control 6.8 subraya la importancia de garantizar que cada empleado, contratista o parte interesada sepa cómo reconocer y notificar un posible incidente de seguridad, y se sienta seguro y facultado para hacerlo.”
Esto importa porque muchos incidentes de privacidad no se detectan primero mediante un SIEM. Empiezan con un agente de soporte que ve el adjunto de otro cliente, un empleado de nóminas que detecta una hoja de cálculo enviada por error, un cliente que informa de la factura de otro usuario o un proveedor que comunica la pérdida de un portátil.
La Política de protección de datos y privacidad para pymes Política de protección de datos y privacidad para pymes, sección Aplicación y cumplimiento, cláusula 8.3.1, convierte esto en una obligación inmediata:
“Todas las violaciones de datos personales o incidentes sospechosos deben notificarse inmediatamente al Coordinador de Privacidad”
Para programas empresariales, la Política de protección de datos y privacidad Política de protección de datos y privacidad, sección Aplicación y cumplimiento, cláusula 8.3.2, asigna el liderazgo:
“El Delegado de Protección de Datos (DPO) deberá dirigir la contención, el análisis y el escalado de violaciones conforme a ISO/IEC 27035 y los GDPR Articles 33 y 34.”
Ese es el cambio de “TI lo está revisando” a “se ha activado el ciclo de vida de violaciones del PIMS”.
El primer punto de presión: evento, incidente de seguridad, incidente de privacidad o violación de datos personales
A las 2:13, el equipo de Maria tiene una alerta. Todavía no tiene una violación notificable confirmada. La primera decisión crítica es la clasificación.
Zenith Blueprint, fase Controles en acción, paso 23: Controles organizativos, explica el control 5.25 de ISO/IEC 27002:2022, Evaluación y decisión sobre eventos de seguridad de la información:
“No toda anomalía es un desastre. No toda alerta indica compromiso. En el mundo real, los equipos de seguridad y las unidades de negocio están inundados de ruido: intentos de inicio de sesión, anomalías en registros, incumplimientos menores de políticas, actividad de TI en la sombra. El verdadero reto no está solo en la detección, sino en distinguir lo inocuo de lo dañino y saber qué exige escalado.”
Un ciclo de vida de violaciones de privacidad debe hacer que esa distinción sea repetible. No debe depender de quién esté de guardia, de qué abogado se incorpore primero o de si el CISO se siente cómodo con la incertidumbre.
Un modelo práctico de clasificación de Clarysec separa cuatro etapas:
| Etapa de clasificación | Pregunta | Propietario típico | Evidencia requerida |
|---|---|---|---|
| Evento | ¿Ha ocurrido algo inusual? | Mesa de ayuda, SOC, propietario de negocio | Ticket, informe, alerta, correo electrónico, extracto de registro |
| Incidente de seguridad | ¿El evento amenazó o comprometió la seguridad de la información? | Coordinador de Respuesta a Incidentes | Ticket de incidente, notas de triaje, sistemas afectados |
| Incidente de privacidad | ¿Podría el evento implicar datos personales u obligaciones de privacidad? | Responsable de Privacidad o DPO | Categorías de datos personales, interesados, rol de tratamiento |
| Violación de datos personales confirmada o sospechada | ¿Los datos personales fueron expuestos, perdidos, alterados, destruidos o accedidos de forma ilícita o accidental? | DPO, Responsable de Privacidad, Legal, propietario de negocio | Evaluación de riesgos, decisión de notificación, registro de evidencias |
La palabra “sospechada” es esencial. Clarysec no recomienda esperar a una certeza perfecta antes de abrir el flujo de trabajo de violaciones de privacidad. El registro de violaciones debe abrirse cuando se sospeche razonablemente una violación de datos personales y actualizarse a medida que maduren los hechos.
La Política de gestión de incidentes y violaciones de datos personales Política de gestión de incidentes y violaciones de datos personales, sección Clasificación y evaluación de violaciones, cláusula 4.2.3, exige a los responsables del tratamiento documentar la decisión antes de cualquier actuación externa:
“[Responsable del tratamiento] El Delegado de Protección de Datos / asesor de privacidad DEBE evaluar el riesgo para los interesados afectados en cada violación de datos personales confirmada o razonablemente sospechada, y registrar la recomendación de notificación, la justificación del riesgo y el asesoramiento en REG10 antes de adoptar la decisión de notificación externa.”
Esa cláusula es el núcleo operativo de una respuesta a violaciones de datos personales bajo el GDPR preparada para auditorías: evaluar el riesgo, registrar la justificación, capturar el asesoramiento, decidir y conservar las evidencias en REG10.
El plazo de 72 horas es un problema de evidencias, no un recordatorio de calendario
Muchos equipos tratan el requisito de notificación de 72 horas del GDPR como una fecha límite en un plan de proyecto. En un incidente real, lo difícil es probar cuándo se tuvo conocimiento, qué se sabía en ese momento, con qué rapidez actuó la organización y por qué la decisión de notificación fue razonable.
La Política de respuesta a incidentes para pymes Política de respuesta a incidentes para pymes, sección Propósito, cláusula 1.2, enmarca el objetivo:
“Esta política permite a la organización minimizar el daño, proteger los datos de clientes y cumplir obligaciones regulatorias como el requisito de notificación de violaciones de datos personales en 72 horas del GDPR.”
La Política de protección de datos y privacidad para pymes, sección Aplicación y cumplimiento, cláusula 8.3.3, establece:
“Cuando sea obligatorio, la notificación a las autoridades y a las personas afectadas debe producirse en un plazo de 72 horas”
Para programas empresariales, la Política de protección de datos y privacidad, sección Aplicación y cumplimiento, cláusula 8.3.3, establece:
“Las violaciones que alcancen el umbral legal de notificación deberán notificarse a las autoridades de control en un plazo de 72 horas.”
El objetivo no es notificar toda anomalía. El objetivo es tomar una decisión defendible con la rapidez suficiente para que la notificación obligatoria se realice a tiempo. Por ello, un PIMS maduro utiliza plazos internos más cortos que los plazos legales externos.
| Tiempo desde el conocimiento | Acción del PIMS | Evidencias que deben capturarse en REG10 |
|---|---|---|
| 0 a 4 horas | Abrir el registro de incidente de datos personales, asignar propietario, preservar evidencias iniciales e identificar el rol de tratamiento | Informe de recepción, marca temporal del conocimiento, roles asignados, sistemas y datos iniciales implicados |
| 4 a 12 horas | Contener la exposición, identificar categorías de datos personales y determinar obligaciones como responsable o encargado del tratamiento | Acciones de contención, tipos de datos afectados, evaluación del rol, dependencias de proveedores o clientes |
| 12 a 24 horas | Realizar una evaluación preliminar de riesgos y decidir si es probable la notificación a la autoridad de control | Justificación del riesgo, impacto probable, incertidumbre, asesoramiento del DPO, aportación legal |
| 24 a 48 horas | Preparar la notificación o la justificación de no notificación, y coordinar comunicaciones con clientes o responsables del tratamiento | Borrador de aviso, registro de decisiones, aprobaciones, notificaciones a clientes, referencias de evidencias |
| 48 a 72 horas | Presentar la notificación obligatoria, documentar la justificación de cualquier retraso si procede y preparar la comunicación individual si existe alto riesgo | Evidencia de presentación, referencia del regulador, decisión final, plan de comunicación |
| Después de 72 horas | Continuar la investigación, actualizar al regulador si procede, notificar a las personas cuando sea obligatorio y completar las lecciones aprendidas | Informes de seguimiento, acciones correctivas, aprobación de cierre, cartera de mejoras |
La Política de gestión de incidentes y violaciones de datos personales, sección Notificación y comunicaciones, cláusula 4.4.1, hace explícito el requisito de documentación:
“[Responsable del tratamiento] El Responsable de Privacidad / Responsable del PIMS DEBE preparar una decisión documentada de notificación regulatoria para cada violación de datos personales confirmada, sin dilación indebida y dentro de un plazo interno que respalde los plazos externos de notificación aplicables, y DEBE conservar en REG10 la notificación, la justificación de no notificación o la justificación del retraso.”
Un regulador puede impugnar una decisión. Un auditor puede comprobar si se siguió el proceso. Pero si la organización puede mostrar evidencias oportunas, criterios estructurados, asesoramiento del DPO y una justificación documentada, estará en una posición mucho más sólida que un equipo que diga: “Lo comentamos en una llamada”.
Responsables y encargados del tratamiento necesitan rutas de violación distintas
Las empresas SaaS modernas suelen operar en más de un rol de privacidad. La plataforma FinTech de Maria puede ser responsable del tratamiento respecto de sus suscriptores directos y encargado del tratamiento respecto de clientes empresariales. En otro escenario, un portal de soporte B2B puede ser encargado del tratamiento para los adjuntos de tickets de clientes, pero responsable del tratamiento para sus propios metadatos internos de soporte.
Esa distinción cambia la ruta de notificación.
| Obligación | Rol de responsable del tratamiento de datos personales | Rol de encargado del tratamiento de datos personales |
|---|---|---|
| Obligación principal | Frente a la autoridad de control y las personas afectadas cuando se alcancen los umbrales | Frente al responsable del tratamiento o cliente afectado |
| Destinatario de la notificación | Autoridad de control pertinente y, si existe alto riesgo, personas afectadas | Cliente o responsable del tratamiento identificado en el contrato |
| Desencadenante de la notificación | Riesgo para los derechos y libertades de las personas | Conocimiento de una violación que afecte a datos personales de clientes |
| Plazo | Sin dilación indebida y, cuando sea viable, en un plazo de 72 horas desde el conocimiento | Sin dilación indebida y dentro de los plazos contractuales, a menudo 24 o 48 horas |
| Evaluación de riesgos | Debe evaluar el riesgo para las personas y decidir sobre la notificación de los Article 33 y 34 | Aporta hechos para que el responsable del tratamiento pueda evaluar el riesgo |
Para los encargados del tratamiento, la Política de gestión de incidentes y violaciones de datos personales, sección Notificación y comunicaciones, cláusula 4.4.4, establece:
“[Encargado del tratamiento] El Responsable de Privacidad / Responsable del PIMS DEBE notificar al responsable del tratamiento o cliente afectado sin dilación indebida y dentro de cualquier plazo contractual aplicable tras tener conocimiento de una violación de datos personales que afecte a datos personales de clientes, y DEBE registrar las notificaciones iniciales y de seguimiento en REG08 y REG10.”
Un encargado del tratamiento no debe esperar a completar el análisis de riesgos del responsable del tratamiento bajo el GDPR. Debe notificar al responsable del tratamiento con los hechos disponibles y proporcionar actualizaciones a medida que avance la investigación. Después, el responsable del tratamiento decide sobre la notificación a la autoridad de control y la comunicación a las personas afectadas respecto de su tratamiento.
Para impactos de alto riesgo sobre las personas, el responsable del tratamiento también debe evaluar la comunicación directa. La Política de gestión de incidentes y violaciones de datos personales, cláusula 4.4.3, establece:
“[Responsable del tratamiento] El Responsable de Privacidad / Responsable del PIMS DEBE coordinar la comunicación a los interesados afectados cuando la evaluación de la violación identifique un alto riesgo o un desencadenante de comunicación equivalente, y DEBE registrar en REG10 el contenido de la comunicación, la audiencia, el momento, el método de entrega y las evidencias de aprobación.”
La Política de protección de datos y privacidad empresarial, sección Aplicación y cumplimiento, cláusula 8.3.4, refuerza esto:
“Si se identifica un alto riesgo para las personas, los interesados afectados deberán ser notificados sin dilación indebida salvo que aplique una excepción, por ejemplo, que exista cifrado robusto.”
Esa excepción debe basarse en evidencias. Decir “los datos estaban cifrados” no basta. La organización debe probar que los datos expuestos eran ilegibles para partes no autorizadas y que las claves pertinentes no se vieron comprometidas.
Los proveedores pueden determinar el éxito o el fracaso de las primeras 24 horas
Los terceros suelen conservar los hechos necesarios para la clasificación y la notificación. Un proveedor de servicios en la nube puede conservar registros de acceso. Un encargado de nóminas puede saber qué empleados se vieron afectados. Un proveedor de servicios gestionados puede haber realizado el cambio de configuración. Un subencargado puede conservar telemetría forense.
Por tanto, las cláusulas de violación con proveedores deben diseñarse antes del incidente.
La Política de seguridad de terceros y proveedores Política de seguridad de terceros y proveedores, sección Requisitos de gobernanza, cláusula 5.3.3, incluye gobernanza contractual sobre:
“Plazos de notificación de violaciones, por ejemplo, dentro de 24 o 72 horas, según la criticidad y los requisitos regulatorios”
Para organizaciones más pequeñas, la Política de seguridad de terceros y proveedores para pymes Política de seguridad de terceros y proveedores para pymes también respalda los plazos de notificación de violaciones en la gobernanza de proveedores.
Clarysec recomienda que los contratos con proveedores y los contratos de encargo de tratamiento definan:
- Qué constituye una violación de datos personales sospechada
- A quién debe notificarse y a través de qué canal
- Plazo de notificación inicial, a menudo más corto que el plazo regulatorio del responsable del tratamiento
- Hechos mínimos requeridos en la primera notificación
- Frecuencia de actualización durante la investigación
- Obligaciones de conservación de evidencias
- Traslado contractual del flujo de notificación de subencargados
- Soporte para comunicaciones con reguladores e interesados
- Obligaciones de acciones correctivas posteriores al incidente
Si los acuerdos con proveedores utilizan expresiones vagas como “tan pronto como sea posible”, el reloj del GDPR del responsable del tratamiento puede depender del debate interno de otra organización. Ese no es un modelo operativo defendible.
Las evidencias convierten la respuesta en cumplimiento defendible
Durante el incidente de Maria, el equipo necesita registros de autenticación, registros de consultas a bases de datos, evidencias de phishing, cambios de control de acceso, listas de clientes afectados, acciones de contención, asesoramiento del DPO y borradores de comunicación. En el escenario del portal SaaS B2B, el equipo podría necesitar capturas de pantalla, permisos de almacenamiento de objetos, identificadores de tickets de soporte, cambios de IAM y registros de acceso entre entornos de cliente.
Las evidencias deben conservarse correctamente. Las capturas sueltas, las exportaciones de chat y las carpetas personales no son suficientes.
Zenith Blueprint, fase Controles en acción, paso 23, trata el control 5.28 de ISO/IEC 27002:2022, Recopilación de evidencias:
“Cuando se produce un incidente de seguridad de la información, uno de los elementos más críticos, y a menudo ignorados, de la respuesta es la evidencia. No registros, no capturas de pantalla, no relatos sueltos, sino evidencias correctamente preservadas, respetuosas con la cadena de custodia y resistentes a la manipulación.”
La Política de recopilación de evidencias y análisis forense Política de recopilación de evidencias y análisis forense, sección Requisitos de gobernanza, cláusula 5.5, establece:
“Todas las evidencias recopiladas deberán identificarse de forma única, etiquetarse y almacenarse en un repositorio seguro con:”
La Política de gestión de incidentes y violaciones de datos personales, sección Evidencias, conservación de registros y confidencialidad, cláusula 4.5.1, conecta esas evidencias con el registro del PIMS:
“[Ambos] El Coordinador de Respuesta a Incidentes DEBE mantener un registro REG10 completo para cada incidente de datos personales sospechado o confirmado desde la recepción hasta el cierre, incluidos hechos, tiempos, clasificación, evaluación, acciones, decisiones, notificaciones, referencias de evidencias y estado de cierre.”
REG10 se convierte en la fuente única de verdad del incidente. REG08 captura las notificaciones a clientes o responsables del tratamiento cuando corresponda. Juntos, permiten que los equipos de seguridad, privacidad, legal y auditoría trabajen desde una única base probatoria.
| Campo de REG10 | Ejemplo de entrada |
|---|---|
| ID de incidente | PII-2026-034 |
| Marca temporal del conocimiento | 2026-06-23 02:13 UTC, alerta del SOC confirmada |
| Rol de tratamiento | Responsable del tratamiento para suscriptores directos, encargado del tratamiento para conjuntos de datos de clientes empresariales |
| Datos personales implicados | Nombres, correos electrónicos profesionales, historiales de transacciones, números nacionales de identificación |
| Clasificación inicial | Incidente de seguridad confirmado con violación de datos personales sospechada |
| Contención | Credenciales del desarrollador revocadas, sesiones terminadas, acceso a la base de datos afectada restringido |
| Evaluación de riesgos | Se accedió a identificadores no públicos; no puede descartarse riesgo de fraude de identidad |
| Decisión de notificación | Notificación a la autoridad de control aprobada para datos del responsable del tratamiento; clientes empresariales notificados como responsables del tratamiento |
| Referencias de evidencias | Registro de autenticación E-034-01, exportación de consultas E-034-02, artefacto de phishing E-034-03 |
| Cierre | Causa raíz corregida, controles de MFA reforzados, formación en phishing actualizada, seguimiento con clientes completado |
El propósito no es la burocracia. Es evitar que la organización tenga que reconstruir la memoria a partir de mensajes dispersos de Slack cuando llame el regulador.
Mapeo de la respuesta del PIMS bajo ISO 27701 con ISO 27001 e ISO 27002
Un proceso maduro de gestión de violaciones de datos personales se sitúa en la intersección entre la gobernanza de privacidad y la gestión de la seguridad de la información.
Las cláusulas 4.1 a 4.4 de ISO/IEC 27001:2022 exigen a las organizaciones comprender el contexto, las partes interesadas, el alcance del SGSI y los procesos del sistema de gestión. Para la gestión de violaciones de datos personales, esto significa que el proceso debe reflejar obligaciones regulatorias, contratos con clientes, roles de tratamiento, dependencias de proveedores y obligaciones sectoriales antes de que se produzca un incidente.
Zenith Controls: guía de correspondencia de cumplimiento Zenith Controls ayuda a mapear los controles de incidentes en un modelo de aseguramiento más amplio. Los controles más relevantes de ISO/IEC 27002:2022 son:
| Control de ISO/IEC 27002:2022 | Tratamiento en Zenith Controls | Por qué importa para la gestión de violaciones de datos personales |
|---|---|---|
| 5.24 Planificación y preparación de la gestión de incidentes de seguridad de la información | Control correctivo, Responder y recuperar, gobernanza y gestión de eventos de seguridad de la información | Define planes, roles, vías de escalado, plantillas de comunicación y preparación ante violaciones de privacidad |
| 5.25 Evaluación y decisión sobre eventos de seguridad de la información | Control detectivo, Detectar y responder, gestión de eventos de seguridad de la información | Crea el punto de decisión estructurado para clasificar incidentes de privacidad y violaciones de datos personales sospechadas |
| 5.26 Respuesta a incidentes de seguridad de la información | Control correctivo, Responder y recuperar, gestión de eventos de seguridad de la información | Activa la contención, la coordinación, el soporte a la notificación, la recuperación y la comunicación con partes interesadas |
| 5.28 Recopilación de evidencias | Conservación de evidencias y fiabilidad investigativa durante el ciclo de vida del incidente | Respalda la responsabilidad proactiva bajo el GDPR, la calidad forense, las preguntas del regulador y la defensa en auditoría |
| 6.8 Notificación de eventos de seguridad de la información | Canal de notificación impulsado por las personas y formación de concienciación | Garantiza que empleados, contratistas y partes interesadas notifiquen rápidamente incidentes de datos personales sospechados |
ISO/IEC 27035 respalda la gestión estructurada de incidentes. ISO/IEC 27037 respalda la gestión de evidencias digitales. ISO/IEC 29134 puede respaldar la lógica de evaluación de impacto en la privacidad cuando la remediación de una violación revela la necesidad de una revisión de EIPD más profunda. ISO/IEC 27701:2025 aporta después al sistema de gestión el contexto de roles de privacidad, el impacto sobre los interesados, las obligaciones de responsables y encargados del tratamiento, y los requisitos de evidencias del PIMS.
Un incidente, muchas perspectivas regulatorias
El incidente de Maria no es solo una cuestión de GDPR. Dado que la empresa presta servicios en la nube a clientes del sector financiero, NIS2 y DORA también pueden aplicar. Los contratos con clientes pueden imponer notificaciones en 24 horas. El seguro cibernético puede exigir una notificación rápida. La gobernanza interna puede exigir informar al consejo.
Crear narrativas separadas para cada marco genera riesgo de contradicción. El método de Clarysec consiste en mantener una única base probatoria y generar a partir de ella salidas específicas por marco.
| Marco o regulación | Perspectiva del incidente | Salida de la base probatoria de Clarysec |
|---|---|---|
| GDPR | Violación de datos personales, riesgo para las personas, notificación a la autoridad de control, comunicación a personas afectadas | Registro de decisiones REG10, asesoramiento del DPO, justificación de los Article 33 y 34, evidencias de comunicación |
| ISO/IEC 27701:2025 | Gobernanza del PIMS, obligaciones de responsables y encargados del tratamiento, riesgo para interesados, evidencias de privacidad | Clasificación del incidente de datos personales, evaluación del rol, REG08 y REG10, acciones correctivas |
| ISO/IEC 27001:2022 | Contexto del SGSI, partes interesadas, proceso de respuesta a incidentes, mejora continua | Registro de incidente, actualizaciones de tratamiento de riesgos, entrada para revisión por la dirección, evidencias de eficacia del control |
| NIS2 | Gestión de incidentes significativos, notificación por fases, medidas de seguridad frente a todo tipo de riesgos | Evidencia de alerta temprana de 24 horas, paquete de notificación de incidente de 72 horas, soporte para informe final de un mes |
| DORA | Gestión de incidentes relacionados con las TIC para entidades financieras y resiliencia operativa digital | Hechos de impacto en TIC, dependencias de terceros, retroalimentación de pruebas de resiliencia, soporte a la notificación de incidentes |
| NIST CSF 2.0 | Perfil Actual y Perfil Objetivo, plan de acción priorizado, comunicación del riesgo | Actualizaciones de violaciones, mejoras objetivo, narrativa de riesgo para el consejo |
| COBIT 2019 | Gobierno, objetivos de gestión, responsabilidad proactiva, desempeño del control | RACI, registros de decisiones, métricas de proceso, seguimiento de acciones correctivas |
NIS2 Article 21 establece medidas de gestión de riesgos de ciberseguridad, incluidas la gestión de incidentes, la continuidad del negocio, la seguridad de la cadena de suministro, la evaluación de la eficacia, la higiene cibernética, la criptografía, el control de acceso, la gestión de activos, MFA y las comunicaciones seguras. NIS2 Article 23 crea una notificación por fases para incidentes significativos, incluida una alerta temprana en un plazo de 24 horas, una notificación de incidente en un plazo de 72 horas, actualizaciones cuando se soliciten y un informe final como máximo un mes después de la notificación del incidente.
DORA aplica desde el 17 de enero de 2025 y establece requisitos uniformes para la gestión del riesgo de las TIC, la notificación de incidentes relacionados con las TIC, las pruebas de resiliencia operativa digital, el intercambio de información y la gestión del riesgo de terceros de TIC para entidades financieras. Para un proveedor FinTech, un único incidente puede ser, por tanto, una violación bajo el GDPR, un incidente significativo bajo NIS2, un evento de TIC relevante para DORA respecto de clientes y un evento de notificación contractual.
Cómo probarán los auditores el ciclo de vida
Los auditores rara vez se detienen en “muéstreme su política de respuesta a incidentes”. Prueban si el ciclo de vida funciona bajo presión probatoria.
Un auditor de ISO/IEC 27701:2025 o ISO/IEC 27001:2022 preguntará cómo entran los incidentes de privacidad en el SGSI y el PIMS, quién clasifica los eventos, cómo difieren las obligaciones de responsables y encargados del tratamiento, y cómo los incidentes impulsan acciones correctivas.
Un auditor de GDPR o una autoridad de control se centrará en el momento de conocimiento, el riesgo para las personas, la intervención del DPO, la justificación de notificación, la comunicación a personas afectadas y la responsabilidad proactiva. Puede muestrear incidentes que no fueron notificados para comprobar si la justificación de no notificación fue documentada.
Una revisión de NIS2 o DORA examinará los umbrales de incidentes significativos, la notificación por fases, el impacto en TIC, las dependencias de terceros, las implicaciones de resiliencia y si la notificación se alineó con los requisitos de la autoridad competente o del cliente pertinente.
Un evaluador de NIST CSF 2.0 preguntará si el incidente cambió el Perfil Actual y el Perfil Objetivo de la organización. Un revisor de COBIT 2019 se centrará en el gobierno, la responsabilidad proactiva, la propiedad del proceso, las métricas y el seguimiento de acciones correctivas.
Un paquete de evidencias de auditoría sólido debe incluir:
| Elemento de evidencia | Por qué lo solicitan los auditores |
|---|---|
| Registro de incidente REG10 | Prueba la recepción, tiempos, clasificación, evaluación, decisiones, notificaciones y cierre |
| Registro REG08 de notificación a cliente o responsable del tratamiento | Prueba las comunicaciones del encargado del tratamiento y el historial de actualizaciones al cliente |
| Informe o alerta original | Establece cómo se detectó el incidente y cuándo empezó el conocimiento |
| Cronología de acciones clave | Muestra contención, evaluación, aprobaciones y decisiones de notificación |
| Evaluación del rol de tratamiento | Demuestra la separación de obligaciones entre responsable y encargado del tratamiento |
| Categorías de datos personales e interesados afectados | Respalda la evaluación de riesgos y el alcance de la notificación |
| Recomendación del DPO o asesor de privacidad | Prueba el asesoramiento de privacidad responsable antes de la decisión externa |
| Justificación de notificación o de no notificación | Respalda la responsabilidad proactiva conforme al GDPR Article 33 y Article 34 |
| Índice del repositorio de evidencias | Demuestra la integridad de las evidencias y la disciplina de cadena de custodia |
| Causa raíz y plan de acciones correctivas | Muestra mejora continua y revisión de la eficacia del control |
Aquí es donde Zenith Controls aporta valor comercial y operativo. Ayuda a mapear las mismas evidencias con los controles de incidentes de ISO/IEC 27002:2022, la responsabilidad proactiva de GDPR, la gestión de incidentes de NIS2, las expectativas de resiliencia de DORA, la comunicación de NIST CSF y la gobernanza de COBIT sin reconstruir la historia de auditoría cada vez.
Una cadencia operativa para las primeras 24 horas
Un playbook realista de violaciones de datos personales debe ser práctico, no teórico. Considere una exposición SaaS entre entornos de cliente notificada por un cliente a las 08:12.
A las 08:12, el equipo de éxito del cliente recibe el informe y sigue la conducta de notificación de Zenith Blueprint paso 16. El ticket se etiqueta como incidente de datos personales sospechado.
A las 08:25, el Coordinador de Respuesta a Incidentes abre REG10. El registro incluye la marca temporal del conocimiento, el notificante, el sistema, los tipos de datos sospechados y el propietario.
A las 09:02, ingeniería revierte el cambio de permisos. Los registros se exportan antes de la rotación. El custodio de evidencias etiqueta el informe del cliente, el cambio de IAM, la exportación de registros de acceso y la confirmación de contención en el repositorio seguro.
A las 10:30, el Responsable de Privacidad determina que la organización actúa como encargado del tratamiento para los adjuntos de soporte de clientes. Conforme a la Política de gestión de incidentes y violaciones de datos personales, cláusula 4.4.4, los clientes responsables del tratamiento afectados deben ser notificados sin dilación indebida y dentro de los plazos contractuales. Se abre REG08.
A las 12:00, el DPO evalúa el riesgo para los interesados. Los datos parecen limitados, pero algunos adjuntos pueden incluir nombres de empleados e identificadores internos. El DPO registra la justificación del riesgo y la recomendación en REG10.
A las 15:00, los clientes responsables del tratamiento afectados reciben la notificación inicial: qué ocurrió, cuándo se detectó, qué se contuvo, qué datos personales pueden estar implicados, qué sigue analizándose y cuándo llegará la siguiente actualización.
A las 18:00, la dirección recibe una breve sesión informativa: se han enviado notificaciones a clientes; las decisiones de notificación al regulador corresponden a los responsables del tratamiento respecto de datos personales de clientes; el tratamiento interno como responsable del tratamiento sigue evaluándose; las evidencias están preservadas; y el análisis de causa raíz está en curso.
Esa cadencia evita los fallos más comunes en violaciones de datos personales: plazos incumplidos, roles confusos, asesoramiento no documentado y comunicaciones no controladas.
Patrones comunes de fallo que deben eliminarse antes de la próxima alerta
Los fallos más dañinos en violaciones de privacidad rara vez se deben a un único documento ausente. Se deben a desconexiones entre seguridad, privacidad, Legal, proveedores y propietarios de negocio.
Clarysec observa habitualmente estos patrones:
- Existen planes de respuesta a incidentes, pero falta la clasificación de violaciones de datos personales.
- Se menciona la notificación de 72 horas del GDPR, pero los plazos internos no son más cortos que el plazo legal.
- El escalado del encargado del tratamiento se retrasa porque los equipos esperan al análisis completo de causa raíz.
- Los contratos con proveedores no exigen notificación rápida de violaciones ni soporte de evidencias.
- El asesoramiento del DPO es verbal y nunca se incorpora al registro de violaciones.
- La comunicación individual en caso de alto riesgo se considera demasiado tarde.
- Las evidencias se almacenan en carpetas personales, hilos de chat o comentarios de tickets.
- Las decisiones de no notificación no se documentan.
- Las lecciones aprendidas no actualizan controles, formación, cláusulas de proveedores ni planes de tratamiento de riesgos.
Zenith Blueprint, paso 23, resume por qué la estructura importa:
“Una respuesta a incidentes sin estructura se convierte en improvisación. Vuelan correos, se convocan reuniones y las decisiones se toman de forma emocional o incoherente. Pero un SGSI maduro convierte la respuesta en disciplina.”
Esa disciplina es el propósito de la gestión de violaciones de datos personales conforme a ISO/IEC 27701:2025.
Construya el ciclo de vida de violaciones de datos personales de Clarysec
El enfoque de Clarysec combina tres capas.
Primero, Zenith Blueprint proporciona la hoja de ruta de implantación. El paso 16 garantiza que las personas reconozcan y notifiquen incidentes sospechados. El paso 23 operacionaliza la evaluación, la decisión, la respuesta y la recopilación de evidencias mediante los controles 5.25, 5.26 y 5.28 de ISO/IEC 27002:2022.
Segundo, el conjunto de políticas define la autoridad y las obligaciones. Las políticas para pymes hacen que la notificación, el conocimiento en 72 horas y los registros de incidentes sean prácticos para organizaciones más pequeñas. Las políticas empresariales asignan el liderazgo del DPO, los umbrales de violación, la comunicación a personas afectadas, las cláusulas de notificación de proveedores, la gestión de evidencias y la gobernanza forense. La Política de gestión de incidentes y violaciones de datos personales específica del PIMS añade obligaciones basadas en roles para responsables y encargados del tratamiento, REG08, REG10, justificación de notificación y evidencias de cierre.
Tercero, Zenith Controls actúa como brújula de cumplimiento transversal. Mapea la planificación, evaluación, respuesta y evidencias de incidentes en una visión integrada de ISO/IEC 27002:2022, GDPR, NIS2, DORA, NIST CSF 2.0 y expectativas de aseguramiento al estilo COBIT.
Para los CISO, esto reduce la confusión operativa. Para los DPO, crea una trazabilidad de decisiones de privacidad defendible. Para los responsables de cumplimiento, vincula un único registro de incidente con múltiples salidas regulatorias. Para los auditores, crea evidencias trazables. Para la alta dirección, reduce la probabilidad de que un incidente de privacidad gestionable se convierta en una crisis regulatoria y reputacional.
Su siguiente paso
No espere a la alerta de las 2 de la madrugada para descubrir si su proceso de violaciones de datos personales funciona.
Empiece esta semana con tres acciones:
- Revise si la recepción de incidentes captura explícitamente incidentes de datos personales sospechados.
- Confirme que las obligaciones de violación de responsables y encargados del tratamiento están separadas en políticas, contratos y registros de evidencias.
- Ejecute un ejercicio de mesa con un escenario realista, como credenciales comprometidas, exposición entre entornos de cliente, un archivo de nóminas enviado por error, un portátil cifrado perdido o el compromiso de un proveedor.
Clarysec puede ayudarle a operacionalizarlo mediante Zenith Blueprint: hoja de ruta de 30 pasos para auditores Zenith Blueprint, Zenith Controls: guía de correspondencia de cumplimiento Zenith Controls y el conjunto de políticas PIMS de ISO/IEC 27701:2025, incluida la Política de gestión de incidentes y violaciones de datos personales Política de gestión de incidentes y violaciones de datos personales, la Política de protección de datos y privacidad Política de protección de datos y privacidad, la Política de respuesta a incidentes para pymes Política de respuesta a incidentes para pymes, la Política de seguridad de terceros y proveedores Política de seguridad de terceros y proveedores y la Política de recopilación de evidencias y análisis forense Política de recopilación de evidencias y análisis forense.
Descargue el kit de herramientas PIMS de Clarysec, reserve una evaluación de preparación ante violaciones de datos personales o programe una demo para convertir su respuesta de 72 horas bajo el GDPR de una improvisación en un proceso disciplinado y preparado para auditorías.
Certifíquese en PECB ISO/IEC 27701 y ponga en marcha su PIMS
- ✓ Material oficial de PECB y dos intentos de examen
- ✓ Tasa de certificación y cuota anual de mantenimiento (AMF) del primer año incluidas, cuando corresponda
- ✓ Autoestudio o en directo online · curso asignado en 1 día hábil
Sobre el autor
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council