Notificacion de brechas de datos personales: guia practica para equipos SaaS

La notificacion de brechas de datos personales es el flujo operativo para decidir si un incidente de seguridad o de datos debe notificarse a una autoridad de control, comunicarse a las personas afectadas, documentarse internamente o escalarse a clientes. Para equipos SaaS, el punto no es memorizar una regla de 72 horas. El punto es saber rapido que paso, que datos pueden estar afectados, si se cumplen los umbrales del RGPD, quien decide y que evidencia respalda la decision.

Segun el articulo 33 del RGPD, el responsable debe notificar a la autoridad competente sin dilacion indebida y, cuando sea posible, dentro de las 72 horas desde que tiene conocimiento de una brecha de datos personales, salvo que sea improbable que genere un riesgo para los derechos y libertades de las personas. El articulo 34 exige comunicar a las personas afectadas cuando sea probable un alto riesgo. Los encargados deben informar al responsable sin dilacion indebida cuando tengan conocimiento de una brecha.

Por que importa en la practica

Una empresa SaaS trata datos en infraestructura de producto, soporte, analitica, CRM, pagos, logs, copias de seguridad, funciones de IA y proveedores. Por eso una brecha puede convertirse rapidamente en un problema de seguridad, privacidad, legal, confianza de clientes y preparacion para auditorias.

Las primeras horas suelen ser ruidosas. Seguridad intenta contener. Ingenieria revisa sistemas. Customer success pregunta si hay cuentas afectadas. Legal necesita hechos para evaluar los umbrales. Liderazgo quiere una posicion externa clara. Sin un flujo preparado, el equipo pierde tiempo descubriendo quien decide.

Cuando aplica

El RGPD define una brecha de datos personales como una violacion de seguridad que provoca destruccion, perdida, alteracion, divulgacion no autorizada o acceso no autorizado a datos personales. Puede afectar confidencialidad, integridad o disponibilidad. No se limita a ataques maliciosos.

Ejemplos SaaS habituales incluyen una base de datos de produccion expuesta por configuracion incorrecta, tickets de soporte enviados al cliente equivocado, acceso no autorizado a logs con datos personales, un dispositivo robado sin cifrado, eliminacion o corrupcion de datos sin recuperacion fiable, o un incidente en un encargado o subencargado.

No todo incidente de seguridad es una brecha notificable. Si no hay datos personales, estas reglas pueden no aplicar. Si hay datos personales pero es improbable que haya riesgo para las personas, puede no requerirse notificacion a la autoridad. Aun asi, el equipo debe documentar hechos, evaluacion, decision y medidas correctivas.

Separar deteccion y notificacion

Los programas rapidos separan cuatro preguntas: si ocurrio un incidente, si incluyo datos personales, si existe riesgo o alto riesgo para personas, y quien debe ser informado, por quien y cuando.

Seguridad puede liderar deteccion y contencion, pero privacidad o legal deberia decidir el umbral de notificacion. Producto, ingenieria, gestion de proveedores y equipos de cliente aportan hechos. Si la empresa SaaS actua como encargado de datos de clientes, tambien debe revisar los plazos y contenidos del DPA, que pueden ser mas estrictos que el plazo regulatorio.

Crear un registro de evaluacion

El registro de evaluacion es la evidencia central. Debe incluir hora de deteccion, momento de conocimiento, sistemas y proveedores implicados, categorias de datos y personas afectadas, numero aproximado de afectados y registros, si hubo acceso, divulgacion, alteracion, perdida o indisponibilidad, medidas de contencion, consecuencias probables, mitigacion, decision sobre autoridad, decision sobre personas afectadas, razones para no notificar, owner, aprobador y acciones de seguimiento.

El registro puede evolucionar. El articulo 33 permite aportar informacion por fases cuando no todo esta disponible a la vez, siempre que el seguimiento no se retrase indebidamente. La leccion practica es no esperar certeza perfecta para iniciar la evaluacion.

Operar las 72 horas

Un modelo practico: de 0 a 4 horas, confirmar si puede haber datos personales, abrir registro y asignar owners; de 4 a 24, identificar sistemas, categorias, personas, proveedores, contencion y consecuencias; de 24 a 48, decidir si se notifica a la autoridad y preparar borrador; de 48 a 72, notificar si corresponde, explicar retrasos y planear informacion adicional; despues, continuar remediacion, comunicacion, analisis de causa y preservacion de evidencias.

A quien informar

La autoridad puede requerir notificacion si es probable un riesgo para derechos y libertades. Las personas afectadas deben recibir comunicacion si es probable un alto riesgo. Los clientes pueden requerir aviso por contrato, DPA, compromisos de seguridad o promesas del trust center.

La comunicacion a personas debe estar en lenguaje claro: naturaleza de la brecha, contacto, consecuencias probables y medidas tomadas o previstas. No debe escribirla solo seguridad; necesita precision juridica y orientacion practica.

Conectar con controles de producto y proveedores

La notificacion es mas facil si existen inventarios de datos, registros de encargados, logs de acceso, reglas de retencion y revisiones de lanzamiento. El flujo debe conectarse con respuesta a incidentes, registros de actividades, vendor management, contratos de cliente, backup y recuperacion, revisiones de acceso, avisos de privacidad y acciones correctivas.

Errores comunes

El primer error es tratar la notificacion como un tema legal tardio. Legal puede evaluar el umbral, pero no puede inventar los hechos. El segundo es abrir el registro demasiado tarde. El tercero es olvidar plazos de clientes y encargados. El cuarto es asumir que cifrado o recuperacion terminan automaticamente el analisis. El quinto es cerrar el incidente despues de la notificacion externa sin remediacion, lecciones aprendidas y mejoras de control.

FAQ

Que deben entender los equipos?

Que la notificacion de brechas es un flujo operativo sensible al tiempo con deteccion, contencion, evaluacion de riesgo, decisiones legales, obligaciones con clientes, evidencias y remediacion.

Cuando aplica a equipos SaaS?

Aplica cuando una violacion de seguridad afecta datos personales mediante perdida, alteracion, divulgacion, acceso no autorizado o indisponibilidad.

Cual es el mayor error?

Esperar a tener todos los hechos completos antes de iniciar la evaluacion. Es mejor abrir el registro pronto, asignar owners y actualizar la decision segun avancen los hechos.

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.