Checklist de notificacion de brechas de datos personales para founders y responsables de compliance

La notificacion de brechas de datos personales funciona mejor cuando el equipo puede pasar rapido de la incertidumbre a una decision documentada. La checklist es directa: confirmar si hay datos personales, abrir un registro de evaluacion, asignar responsables, evaluar el riesgo para las personas, decidir si hay que notificar a la autoridad o a los afectados, conservar evidencias y seguir la remediacion hasta el cierre.

Segun el articulo 33 del RGPD, el responsable debe notificar a la autoridad competente sin dilacion indebida y, cuando sea posible, dentro de 72 horas desde que tiene conocimiento de una brecha, salvo que sea improbable que genere riesgo para los derechos y libertades de las personas. El articulo 34 anade la comunicacion a las personas cuando exista un alto riesgo probable. El encargado debe notificar al responsable sin dilacion indebida.

Que evita esta checklist

Muchos fallos empiezan antes de decidir si notificar. El equipo detecta un incidente de seguridad, pero no sabe si habia datos personales. Seguridad contiene el problema, pero privacidad y legal no tienen hechos suficientes. Customer success oye del incidente antes de revisar contratos. Direccion pregunta por la ventana de 72 horas y nadie sabe cuando la organizacion tuvo conocimiento.

La checklist conecta respuesta a incidentes, revision de privacidad, obligaciones con clientes, vendor management y evidencias de auditoria antes de que llegue la presion real.

La checklist

Usala para cualquier incidente de seguridad o datos que pueda afectar datos personales en produccion, soporte, logs, analitica, CRM, backups, funciones de IA, proveedores, sistemas de empleados o datasets de clientes.

1. Abrir el registro de evaluacion

No esperes a saber si es notificable. El registro es donde se toma esa decision. Incluye titulo, referencia, hora de deteccion, canal, primer revisor, posible momento de conocimiento, sistemas afectados, contencion inicial, owner de incidente, privacidad, legal, seguridad y comunicaciones, estado, hechos abiertos y proxima revision.

Un registro temprano puede estar incompleto. Debe mostrar la incertidumbre y quien la va a resolver.

2. Confirmar si hay datos personales

La definicion del RGPD cubre destruccion, perdida, alteracion, divulgacion no autorizada o acceso no autorizado a datos personales. Puede afectar confidencialidad, integridad o disponibilidad. Pregunta si habia datos de personas identificadas o identificables, usuarios, empleados, leads, administradores o end users; si habia logs, adjuntos, exportaciones, backups, analitica o prompts de IA; y si los datos se expusieron, cambiaron, perdieron o quedaron no disponibles.

3. Identificar el rol de la empresa

Una empresa SaaS puede ser responsable para datos de empleados, prospects, billing, analitica o cuentas, y encargada para contenido de clientes. Registra para cada dataset si la empresa actua como responsable, encargado, corresponsable o subencargado, que contrato o DPA aplica, que plazo de aviso existe y quien debe tomar la decision.

4. Reunir los hechos minimos para el articulo 33

Recoge categorias y numero aproximado de personas afectadas, categorias y numero aproximado de registros, tipos de datos, ventana temporal, acceso, descarga, divulgacion, alteracion, perdida o indisponibilidad, estado de contencion, consecuencias probables y medidas tomadas o previstas. Si faltan hechos, documenta que falta y quien lo aporta.

5. Evaluar riesgo y alto riesgo por separado

El articulo 33 y el articulo 34 usan umbrales distintos. Revisa sensibilidad, identificabilidad, severidad, probabilidad de abuso, credenciales, datos financieros, salud, categorias especiales, menores, medidas de proteccion como cifrado, duracion, escala y evidencias de acceso real.

6. Decidir a quien informar

Separa autoridad, personas afectadas, clientes, proveedores, aseguradora, liderazgo interno y board. Para cada audiencia registra si hay aviso, base legal o contractual, plazo, owner, aprobador, contenido y follow-up. Para clientes, revisa DPA y contrato en vez de asumir que el RGPD es el unico reloj.

7. Preparar el paquete de evidencias

Conserva timeline, logs, tickets, capturas, notas tecnicas, analisis de alcance, rol, evaluacion de riesgo, decisiones, aprobaciones, copias de avisos, remediacion, root cause y mejoras de control. Esto importara ante clientes, auditores, autoridad y aprendizaje interno.

8. Cerrar el ciclo

La notificacion no cierra el incidente. Confirma que se corrigieron configuraciones, permisos, codigo o problemas de proveedores; que los clientes recibieron actualizaciones; que se reevaluo la comunicacion a personas; que las evidencias se preservan; y que producto, seguridad, soporte y vendors actualizan sus procesos.

FAQ

Que deben entender los equipos?

Que la notificacion de brechas es un workflow sensible al tiempo con hechos de seguridad, evaluacion de privacidad, decisiones legales, obligaciones con clientes, evidencias y remediacion.

Cuando aplica a equipos SaaS?

Cuando una violacion de seguridad afecta datos personales mediante destruccion, perdida, alteracion, divulgacion no autorizada, acceso no autorizado o indisponibilidad.

Que se documenta primero?

Hora de deteccion, posible momento de conocimiento, sistemas afectados, datos afectados, rol de la empresa, contencion, owners, hechos abiertos y proxima revision.

Fuentes

• European Union, General Data Protection Regulation.
• European Data Protection Board, Guidelines 9/2022 on personal data breach notification under GDPR.
• Information Commissioner's Office, Personal data breaches - a guide.