Te han entrado en la web, o tu hosting te ha avisado de algo raro, y alguien ha pronunciado la frase «72 horas». Antes de que te agobies, tres cosas que conviene tener claras desde el minuto uno: no todas las brechas se notifican, el reloj no empieza cuando ocurrió el ataque, y una notificación incompleta presentada dentro de plazo vale mucho más que una completa presentada tarde.
Esta es la guía operativa para decidir si hay que notificar y, si es que sí, presentarlo bien. No es asesoramiento jurídico: si los datos son sensibles o los afectados son muchos, que lo revise un abogado. Para el escenario habitual de una pyme con la web comprometida, esto es lo que hay que hacer.
Qué cuenta como brecha: confidencialidad, integridad y disponibilidad
Una brecha (el RGPD la llama violación de la seguridad de los datos personales) es cualquier incidente que ocasione la destrucción, pérdida o alteración de datos personales, o el acceso o la comunicación no autorizados a ellos. Da igual que sea accidental o ilícito. Se agrupa en tres tipos, y conviene identificar el tuyo porque cambia el análisis:
- Confidencialidad. Alguien ha accedido a datos que no debía. Es el caso típico de la web hackeada con acceso a la base de datos, del buzón de correo comprometido o del correo enviado con 200 clientes en copia visible en lugar de en copia oculta.
- Integridad. Los datos se han alterado sin autorización. Precios cambiados, pedidos modificados, fichas de clientes manipuladas.
- Disponibilidad. Has perdido el acceso a los datos o los has perdido del todo: un cifrado por ransomware, un borrado accidental, o una restauración que no funciona porque las copias estaban corruptas.
Dos matices. El primero: no hace falta que haya un ataque; un portátil sin cifrar olvidado en un taxi es una brecha, y el correo con copias visibles es de los incidentes más notificados que existen. El segundo, el que más gente se salta: si te cambian la portada, es tentador concluir que no hubo acceso a datos. Quien pudo escribir en tu servidor casi siempre pudo también leer la base de datos. Eso hay que descartarlo con pruebas, no por sentido común.
Cuándo empiezan a contar las 72 horas, que no es cuando te enteras del ataque
El plazo arranca cuando el responsable tiene constancia de la brecha, es decir, cuando alcanza un grado razonable de certeza de que ha ocurrido un incidente de seguridad que ha comprometido datos personales. Traducido a la práctica:
- No arranca cuando ocurrió el ataque. La intrusión puede ser de hace tres meses y tú enterarte hoy; el plazo cuenta desde hoy.
- No arranca cuando terminas de investigar. Este es el error caro: esperar al informe forense completo. Para entonces el plazo se ha ido.
- Sí admite un periodo corto de verificación. Si tu hosting dice que ha visto algo raro, tienes un margen razonable para confirmarlo. Se mide en horas, no en días, y deja registrado qué comprobaste y cuándo.
- Si te enteras por un proveedor, el reloj empieza cuando él te lo comunica. Él tenía la obligación de avisarte sin dilación indebida, y por eso conviene tener ese plazo fijado por escrito con tu hosting o tu agencia, que son encargados del tratamiento.
Las 72 horas son naturales: incluyen sábado, domingo y festivos. Y si te pasas, se notifica igual indicando los motivos de la demora, porque llegar tarde con una explicación razonable es mucho mejor que no presentar nada.
Cómo decidir si es notificable: el análisis de riesgo
La regla es esta: se notifica salvo que sea improbable que la brecha suponga un riesgo para los derechos y libertades de las personas. Fíjate en el orden. La notificación es lo normal; la excepción es la que hay que justificar, y la justificación tienes que poder enseñarla tú.
Para valorarlo se miran estos factores:
- Tipo de datos. No es lo mismo un nombre y un correo que un DNI, datos bancarios, contraseñas o datos de salud.
- Volumen de personas y de registros afectados.
- Facilidad de identificar a las personas a partir de lo expuesto.
- Gravedad de las consecuencias posibles: fraude, suplantación de identidad, phishing dirigido, daño reputacional, discriminación.
- Vulnerabilidad de los afectados: menores, pacientes, personas en situación sensible.
- Medidas que atenúan el daño: si los datos estaban cifrados y la clave no se ha comprometido, el riesgo baja mucho.
| Situación | Qué suele proceder |
|---|---|
| Base de datos de la tienda expuesta: nombres, direcciones, teléfonos y pedidos | Notificable |
| Formulario de contacto con nombres y correos de cientos de personas al alcance del atacante | Normalmente notificable: habilita phishing dirigido |
| Contraseñas de usuarios accesibles, aunque estén cifradas | Notificable, y además hay que forzar el cambio |
| Copia de seguridad cifrada robada, con la clave a salvo y fuera de alcance | Probablemente no notificable, pero documenta el porqué |
| Portada modificada, sin poder demostrar que no hubo acceso a la base de datos | Trátalo como notificable: la duda no juega a tu favor |
Y aquí la advertencia más importante del artículo. Si no tienes registros del servidor, no puedes concluir que el riesgo es improbable. La ausencia de logs no demuestra que no hubo acceso: demuestra que no puedes saberlo, y esa falta juega en tu contra tanto en el análisis como después. Tener registros y conservarlos es, de hecho, una de las medidas de seguridad apropiadas que el RGPD te pide traducidas a una pyme.
La AEPD publica guías y herramientas de ayuda para esta valoración, como Comunica-Brecha RGPD. Úsalas, pero guarda tu propio razonamiento por escrito: lo que te defiende es el documento donde explicas por qué decidiste lo que decidiste.
El formulario de la sede electrónica de la AEPD, campo por campo
La notificación se presenta en la sede electrónica de la AEPD, en el procedimiento de notificación de brechas de seguridad de datos personales. Necesitas certificado electrónico o Cl@ve. Consíguelo antes de que pase nada: sacar un certificado el segundo día de las 72 horas es un plan pésimo, y es una de las causas más tontas de llegar tarde.
El contenido mínimo que tienes que aportar está tasado por el RGPD y es este:
- Naturaleza de la brecha: qué ha pasado, cómo y cuándo. Si puedes, las categorías de datos y de interesados afectados.
- Número aproximado de personas afectadas y de registros implicados. La palabra clave es aproximado: es válido dar una horquilla, y es mucho mejor que inventarse una cifra exacta que luego no cuadre.
- Punto de contacto: el delegado de protección de datos si lo tienes, y si no, la persona de tu empresa a la que se puede llamar.
- Consecuencias probables de la brecha para los afectados.
- Medidas adoptadas o propuestas, incluidas las de mitigación: qué has cerrado, qué contraseñas has cambiado, qué has restaurado, qué vas a hacer.
Al redactar: cronología con fechas y horas, hechos y no interpretaciones, y distingue lo que sabes de lo que sospechas. Al terminar, guarda el justificante y el número de expediente con el resto de la documentación del incidente.
Notificación incompleta y ampliación posterior: cómo se hace bien
El RGPD permite expresamente facilitar la información por fases cuando no se dispone de todo a la vez. Esta es la salida al conflicto entre investigar bien y llegar a tiempo, y muy poca gente la usa.
Se hace así: dentro del plazo presentas una notificación inicial con lo que sabes, dices que la investigación sigue abierta y te comprometes a una fecha de ampliación. Después amplías sobre el mismo expediente con las conclusiones y corriges las cifras si el alcance era otro.
Lo que no funciona es el silencio mientras investigas. Y hay un detalle operativo que condiciona todo lo demás: no restaures la copia de seguridad antes de conservar la evidencia. Restaurar borra las huellas de qué pasó y a qué se accedió, y sin eso no puedes rellenar honestamente ni la mitad del formulario. El orden completo de las primeras horas, incluidas las decisiones que no son de protección de datos, lo tienes en la guía sobre qué obligaciones legales tienes cuando te atacan la web y en qué orden cumplirlas.
El registro interno de brechas, notifiques o no
Esta es la obligación que casi nadie conoce y que la AEPD sí pregunta: tienes que documentar cualquier violación de seguridad de datos personales, la notifiques o no, incluyendo los hechos, sus efectos y las medidas correctivas adoptadas.
Una hoja de cálculo basta. Lo que debe contener cada entrada:
- Fecha y hora de detección, y de ocurrencia si se conoce.
- Cómo se detectó y quién lo detectó.
- Sistemas afectados y tipo de brecha (confidencialidad, integridad, disponibilidad).
- Categorías de datos y número aproximado de afectados.
- Decisión de notificar o no, y su motivación. Este campo es el que te salva si decidiste no notificar.
- Medidas adoptadas, quién las ejecutó y cuándo.
- Si se comunicó a los afectados y con qué texto.
Crea ese fichero hoy, aunque esté vacío. Improvisarlo el día del incidente se nota, y se nota mucho.
Qué ha sancionado la AEPD por notificar tarde o no notificar
No te voy a dar aquí importes ni números de expediente de memoria, porque en este terreno las cifras inventadas hacen más daño que bien. Sí te puedo dar los patrones que se repiten, que es lo que de verdad te sirve:
- La sanción por no notificar rara vez viaja sola. Suele ir acompañada de un incumplimiento del deber de aplicar medidas de seguridad adecuadas y del principio de integridad y confidencialidad. Es decir, la Agencia mira el incidente, y de paso mira cómo tenías montada la casa.
- La mayoría de los expedientes arrancan por una reclamación de un afectado que se ha enterado por su cuenta, no por una inspección de oficio. Esto tiene una consecuencia práctica: el silencio no te protege, porque el afectado suele acabar enterándose igual.
- Notificar no es autoinculparse. Sufrir un ataque no está sancionado. Lo que se sanciona es no haber tomado medidas razonables y no haber cumplido con la obligación de informar.
- Colaborar, reconocer los hechos y acreditar medidas correctivas se tiene en cuenta a la hora de graduar la respuesta.
Si quieres verlo con casos concretos, la AEPD publica sus resoluciones en su web y se pueden consultar libremente. Y si estás ubicando esto dentro del conjunto de obligaciones de tu empresa, el mapa completo está en la guía de normativa de protección de datos y ciberseguridad para pymes en España.
Y después: ¿hay que avisar también a los clientes?
Son dos obligaciones distintas y con criterios distintos. La notificación a la AEPD procede salvo que el riesgo sea improbable. La comunicación a los afectados solo procede cuando la brecha entraña un alto riesgo para sus derechos y libertades, y tiene sus propias reglas sobre qué decir, cómo decirlo y cuándo puedes ahorrártela. Está desarrollada en el artículo sobre cuándo hay que comunicar una brecha a los afectados y cómo hacerlo.
Y una nota sobre el tono: si te toca avisar, usa lenguaje claro, di qué datos están afectados, qué debe hacer la persona y da un canal de contacto real. Los avisos redactados para no reconocer nada se notan y multiplican las reclamaciones.
Si el reloj ya está corriendo y lo que necesitas es que alguien confirme el alcance antes de que se te acabe el plazo, mira cómo trabajamos una respuesta a incidentes en las primeras horas: conservar la evidencia, determinar a qué datos se accedió de verdad y dejarte por escrito lo que necesitas para rellenar la notificación con hechos y no con suposiciones.
Seguir leyendo en esta sección
- Sanciones de la AEPD a pymes: por qué se ponen de verdad y cómo evitarlas
- Me han atacado la web: qué obligaciones legales tengo y en qué orden
Ver todo en Brechas y obligaciones tras un incidente → · Mapa completo del sitio