Un procedimiento ante brechas de seguridad debe permitir actuar cuando faltan datos, una persona clave está ausente o el proveedor solo ha enviado un aviso preliminar. Este modelo organiza la detección, la contención, la evaluación del riesgo y las decisiones de notificación. Incluye un bloque editable y explica cómo adaptarlo a la organización. Su resultado debe ser una cadena de responsabilidades y evidencias que pueda utilizarse durante una incidencia real.
El procedimiento no sustituye al registro de cada caso. El primero establece quién hace qué; el segundo documenta qué ocurrió y por qué se decidió actuar de determinada manera. Tampoco convierte cualquier fallo técnico en una brecha de datos personales. El RGPD, artículos 4.12, 33 y 34, exige examinar si se han destruido, perdido, alterado o divulgado datos personales, o si se ha accedido a ellos sin autorización, accidental o ilícitamente.
Qué debe activar el procedimiento
Permita que cualquier trabajador comunique una sospecha sin tener que resolver primero su calificación jurídica. Un correo enviado al destinatario equivocado, un expediente en papel perdido o una alteración no autorizada de datos pueden merecer la misma atención inicial que una alerta informática. El canal debe recoger información suficiente para investigar, evitando que la persona difunda una copia completa del archivo afectado entre todos los responsables internos.
La primera revisión distingue una alarma sin afectación a datos personales de una brecha de seguridad sujeta al RGPD. Documentar esa distinción evita tanto notificaciones precipitadas sin fundamento como descartes injustificados. Si todavía no se sabe qué información está comprometida, asigne una investigación inmediata y deje constancia de la incertidumbre. Una etiqueta de «incidente técnico» no debe cerrar el caso cuando existen indicios de pérdida de disponibilidad, integridad o confidencialidad de datos personales.
Incluya los sistemas externos y los soportes físicos. Una interrupción que impide acceder a información necesaria puede producir daños aunque nadie haya descargado una base de datos. A la inversa, una alerta bloqueada antes de afectar a datos puede quedar en el circuito de seguridad sin convertirse en una brecha notificable. La clasificación depende de los hechos y de su evolución, no del nombre del producto que generó la alerta.
Responsables, suplentes y decisiones sin demora
El responsable del tratamiento conserva la responsabilidad de evaluar y cumplir las obligaciones. Puede distribuir tareas entre seguridad, operaciones, asesoría y comunicación, pero debe designar quién decide y quién sustituye a esa persona. La dirección tiene que facilitar los medios necesarios: acceso a documentación, capacidad de aislar sistemas y autorización para enviar una notificación inicial cuando procede. Una aprobación pendiente no suspende los plazos legales.
El delegado de protección de datos, si está designado, informa, asesora y actúa como punto de contacto en su ámbito. No debe convertirse automáticamente en el propietario de toda decisión operativa ni en la única persona capaz de abrir un expediente. La existencia de una brecha tampoco impone por sí sola nombrar un delegado. La guía sobre cuándo es obligatorio un DPO en España permite separar esa cuestión de la organización de la respuesta.
Si actúa como encargado, debe informar al responsable sin dilación indebida cuando tenga conocimiento de una brecha. El RGPD no le concede un plazo general propio de 72 horas para esperar. Los compromisos contractuales pueden concretar canales y tiempos de escalado compatibles con esa obligación. Revise el modelo de contrato de encargado del tratamiento y compruebe que identifica contactos operativos, asistencia y circulación de información entre subencargados.
Modelo editable del procedimiento
Complete los cargos, canales y medios antes de aprobar el documento. Los tiempos internos elegidos deben facilitar el cumplimiento legal; no son periodos de espera. Guarde los datos de contacto sensibles en un anexo de acceso restringido y asegure una copia disponible cuando los sistemas principales fallen. El modelo sirve de punto de partida y necesita adaptaciones sectoriales cuando existan otras obligaciones de comunicación.
PROCEDIMIENTO DE GESTIÓN DE BRECHAS DE DATOS PERSONALES
Entidad: [nombre]. Ámbito: [tratamientos, centros, sistemas y proveedores].
Versión/fecha: [ ]. Aprobación y titular del procedimiento: [ ].
1. Activación
Toda sospecha se comunica inmediatamente al canal [ ] y, si falla, a [ ].
Contacto de guardia/suplente: [ ]. No se exige certeza previa al informante.
Se registra hora, fuente, descripción, sistemas y posibles datos afectados.
No se reenvían archivos personales completos por canales no autorizados.
2. Dirección de la respuesta
Coordinación: [cargo y suplente]. Contención técnica: [ ].
Evaluación jurídica/riesgo: [ ]. DPD, si existe: [ ].
Decisor por cuenta del responsable: [ ]. Presentación de notificaciones: [ ].
Comunicación a afectados y atención posterior: [ ].
Si actuamos como encargado: responsables a informar y canal seguro [ ].
3. Clasificación y contención
Determinar si hay brecha de confidencialidad, integridad o disponibilidad.
Registrar hechos confirmados, hipótesis, alcance desconocido y diligencias.
Anotar separadamente detección y momento de conocimiento de la brecha,
con hechos que justifican este último. Investigar sin demoras evitables.
Contener el daño, preservar evidencia y recuperar el servicio de forma segura.
Registrar cada medida, persona ejecutora, hora y efecto comprobado.
4. Evaluación del riesgo para las personas
Examinar categorías y volumen de datos/personas, posibilidad de identificar,
contexto, vulnerabilidad, destinatarios, duración, consecuencias y probabilidad.
Comprobar medidas efectivas: cifrado, claves, accesos y recuperación.
Identificar daños posibles y medidas que las personas puedan adoptar.
Registrar la motivación, las incertidumbres y el momento de revisión.
5. Decisión sobre autoridad de control — artículo 33
Notificar sin dilación indebida y, de ser posible, en un máximo de 72 horas
desde el conocimiento, salvo que sea improbable que la brecha suponga
un riesgo para los derechos y libertades de las personas físicas.
Autoridad competente y fundamento: [ ]. Canal y representación: [ ].
Si se superan las 72 horas, explicar los motivos del retraso.
No esperar al informe forense definitivo: cuando no pueda facilitarse todo
simultáneamente, aportar la información por fases sin dilación indebida.
Contenido: naturaleza de la brecha; cuando sea posible, categorías y número
aproximado de afectados y de registros; contacto del DPD u otro punto;
consecuencias probables; medidas adoptadas/propuestas, incluida mitigación.
Conservar justificante, referencia, copia y responsable del seguimiento.
6. Decisión sobre afectados — artículo 34
Cuando sea probable un alto riesgo, comunicar sin dilación indebida en
lenguaje claro: naturaleza, contacto, consecuencias y medidas adoptadas
o propuestas, con instrucciones de protección pertinentes.
Valorar y justificar separadamente las excepciones: protección aplicada
que haga los datos ininteligibles para no autorizados; medidas posteriores
que garanticen que el alto riesgo ya no sea probable; o esfuerzo
desproporcionado, que exige comunicación pública o medida similar eficaz.
Canal seguro/accesible, destinatarios y responsable: [ ].
La comunicación no espera al vencimiento de 72 horas ni a una autorización
general de la autoridad. Atender sus instrucciones cuando intervenga.
7. Registro, seguimiento y cierre
Documentar toda brecha: hechos, efectos y medidas correctoras; incluir
motivos de notificar/no notificar y de comunicar/no comunicar a afectados.
Registro y repositorio de evidencias: [ ]; permisos y conservación: [ ].
Revisar decisiones con nuevos hechos. Actualizar notificaciones cuando proceda.
Cerrar con recuperación comprobada, acciones pendientes, responsables,
fechas de seguimiento y revisión de controles/proveedores/formación.
8. Preparación y mantenimiento
Probar contactos, suplencias, acceso al canal oficial y escenarios internos.
Revisar tras cambios de sistemas, proveedores, personal o incidentes.
Última comprobación y próxima revisión prevista: [ ].
El reloj comienza con el conocimiento, no con el informe final
Registre por separado cuándo sucedió el incidente, cuándo apareció la primera señal y cuándo hubo conocimiento de la brecha. No siempre coinciden. Conforme a las directrices del CEPD sobre notificación de brechas, el conocimiento se relaciona con un grado razonable de certeza de que ha ocurrido un incidente que ha comprometido datos personales. No requiere terminar todas las verificaciones técnicas ni celebrar una reunión formal.
El artículo 33 exige notificar sin dilación indebida y, de ser posible, dentro de las 72 horas desde ese conocimiento, salvo que sea improbable que exista riesgo para los derechos y libertades. Las 72 horas no son una autorización para demorar una notificación ya preparada. Los fines de semana no reinician el cómputo. Si se supera ese plazo, la notificación debe incluir los motivos del retraso; explicar el retraso no lo convierte automáticamente en justificado.
Imagine que un empleado confirma el viernes la remisión de un listado con datos personales a una dirección incorrecta. Esperar al lunes para abrir formalmente el expediente no desplaza necesariamente el conocimiento al lunes. El procedimiento debe permitir valorar desde el aviso la naturaleza del listado, el destinatario y las consecuencias. La gestión de la notificación a la AEPD desarrolla el contenido del envío, mientras este documento organiza la decisión y sus responsables.
Evaluar a las personas afectadas, no solo el daño empresarial
La indisponibilidad de un servicio puede costar dinero a la empresa y, además, impedir a una persona obtener asistencia o demostrar un derecho. La evaluación debe describir esa segunda dimensión. Examine posibles perjuicios económicos, discriminación, suplantación, exposición de información íntima o pérdida de control. El volumen importa, pero un expediente de una sola persona puede presentar un riesgo elevado por su contenido y contexto.
El cifrado requiere comprobar qué datos estaban protegidos y si las claves seguían siendo inaccesibles para el tercero. Un archivo cifrado junto a su contraseña no ofrece la misma protección que un soporte correctamente protegido sin acceso a las claves. Del mismo modo, la seudonimización no equivale a anonimización. La explicación sobre anonimización y seudonimización ayuda a distinguir una reducción verificable del riesgo de una etiqueta técnica insuficiente.
Una matriz puede ordenar la discusión, pero no sustituye la motivación. Escriba qué daño se considera, quién podría sufrirlo y qué pruebas apoyan la probabilidad estimada. Si faltan registros de acceso, no afirme que nadie consultó los datos solo porque no se ha encontrado una descarga. Documente la limitación, las verificaciones alternativas y la necesidad de revisar la decisión. La incertidumbre debe gestionarse, no convertirse automáticamente en ausencia de riesgo.
Autoridad y personas: dos decisiones distintas
La notificación del artículo 33 se dirige a la autoridad competente; la comunicación del artículo 34, a las personas cuando es probable un alto riesgo. Una brecha puede exigir la primera y no la segunda. La comunicación a afectados se realiza sin dilación indebida, sin una regla general de esperar a que terminen las 72 horas. Si una advertencia permite cambiar credenciales comprometidas, retrasarla hasta el cierre técnico puede aumentar el daño.
Las excepciones del artículo 34 también necesitan prueba. La aplicación efectiva de medidas que hagan ininteligibles los datos para personas no autorizadas puede excluir la comunicación individual; igualmente, medidas posteriores pueden garantizar que el alto riesgo ya no sea probable. Cuando la comunicación individual suponga un esfuerzo desproporcionado, se exige una comunicación pública o medida semejante que informe de manera igualmente efectiva. No basta con declarar que localizar a los afectados resulta incómodo.
La información debe ser clara y práctica: qué ha sucedido, qué consecuencias son probables, qué medidas se han adoptado y dónde obtener ayuda. Evite mensajes comerciales que minimicen hechos todavía inciertos. Tampoco incluya datos de otros afectados en correos colectivos. Prepare un canal de atención con instrucciones consistentes, y actualice la información si cambia materialmente la evaluación. La autoridad puede exigir la comunicación o valorar la concurrencia de una excepción.
Preparar el canal oficial antes de necesitarlo
La página actual de la AEPD para notificar brechas conduce al formulario específico de su sede electrónica. Verifique antes del incidente quién dispone de identificación y representación adecuadas para presentarlo. Una reclamación de una persona afectada no sustituye a la notificación del responsable. Tampoco presuponga que un correo enviado al contacto general de la autoridad equivale a utilizar el procedimiento previsto.
Determine la competencia según el tratamiento y la organización. En España pueden intervenir autoridades autonómicas dentro de su ámbito; los tratamientos transfronterizos requieren analizar las reglas del RGPD sobre autoridad principal y cooperación. No elija la AEPD únicamente porque uno de los afectados resida en España. La guía sobre la autoridad de control española sirve de orientación inicial, pero el expediente debe recoger el razonamiento concreto seguido.
Cuando no pueda completar todos los campos con cifras definitivas, distinga estimaciones de datos confirmados. El artículo 33 permite facilitar información por fases cuando no sea posible hacerlo simultáneamente, sin dilación indebida. Indique qué falta y quién lo obtendrá. Guarde el justificante y relacione las ampliaciones con la notificación inicial; enviar documentos inconexos dificulta reconstruir el cumplimiento y puede generar versiones contradictorias.
Evidencias y proveedores durante la investigación
El registro del caso debe permitir reconstruir las decisiones sin acumular indiscriminadamente datos personales. Conserve referencias a evidencias protegidas, permisos y fechas de obtención. El modelo de registro de brechas desarrolla esa estructura. Documente todas las brechas, incluidas las no notificadas, con sus hechos, efectos y medidas correctoras. Para un incidente descartado como brecha, conserve una justificación proporcional dentro del circuito de seguridad.
Un proveedor debe comunicar hechos útiles, no solo una valoración tranquilizadora. Solicite sistemas afectados, periodos, categorías de datos, medidas y novedades pendientes. Contraste la información con el registro de actividades para localizar tratamientos y colectivos. El contrato o acto jurídico vinculativo del artículo 28, por escrito, también electrónico, debe prever la asistencia pertinente; su existencia no reemplaza la comprobación de que los contactos y canales funcionan.
La cooperación técnica puede requerir preservar registros antes de que roten, revocar accesos o evitar una restauración contaminada. Coordine esas actuaciones para que la contención no destruya innecesariamente evidencia. La guía sobre comunicación y responsabilidades ante vulnerabilidades de proveedores ayuda a preparar ese intercambio. Una vulnerabilidad descubierta y una brecha consumada no son sinónimos, aunque la primera pueda desencadenar la investigación de la segunda.
Dos escenarios que conviene ensayar
En un envío equivocado, pida al destinatario que no utilice la información y que la elimine de forma segura, pero no considere su mera promesa una prueba universal de ausencia de riesgo. Examine qué recibió, si existe una relación de confianza verificable y qué posibilidades de copia o difusión hubo. Una nómina, un diagnóstico y una lista de direcciones profesionales no producen necesariamente las mismas consecuencias. Conserve la respuesta recibida y explique el peso que le atribuye en la evaluación.
En un ataque que bloquea el acceso a datos, compruebe tanto la recuperación como una posible extracción. Disponer de una copia de seguridad no demuestra que no se hayan divulgado datos, y restaurar el servicio no elimina automáticamente las consecuencias del periodo de indisponibilidad. La investigación técnica y la evaluación de derechos deben comunicarse entre sí. Si falta información sobre la extracción, describa esa limitación con precisión, en lugar de afirmar que el incidente solo afectó a la disponibilidad.
Ambos escenarios permiten comprobar un punto organizativo: quién reabre una decisión cuando llega un dato nuevo. El expediente debe tener una persona responsable del seguimiento, incluso después de una primera notificación. Una evaluación inicial razonable puede cambiar; lo importante es conservar su fundamento, registrar los nuevos hechos y actuar sin demoras evitables cuando modifiquen el riesgo o las medidas necesarias.
Cierre, ejercicio interno y preguntas frecuentes
Cerrar el incidente significa comprobar la recuperación y asignar las medidas pendientes, no archivar el correo de notificación. Revise qué falló en accesos, configuración, formación o contratos, y quién verificará la corrección. Incorpore los resultados a la auditoría de protección de datos. La existencia de un procedimiento escrito no garantiza ausencia de responsabilidad: importan su adecuación y aplicación real, como explica el marco de sanciones del RGPD.
Un ejercicio interno puede consistir en un envío equivocado o un aviso incompleto de un proveedor durante una ausencia. Observe si el equipo encuentra el suplente, identifica los datos y toma las dos decisiones de comunicación. No hace falta presentar una notificación ficticia a la autoridad. El objetivo es detectar obstáculos internos y corregirlos antes de un caso real, conservando una breve evidencia de las mejoras realizadas.
¿Hay que notificar todas las incidencias?
No. Primero se determina si existe una brecha de datos personales y después se evalúa el umbral del artículo 33. Si es improbable que suponga riesgo, no se exige esa notificación, pero toda brecha debe documentarse. La comunicación individual exige la evaluación diferenciada del alto riesgo y de las excepciones del artículo 34. Ninguna de estas decisiones debe depender exclusivamente del número de registros.
¿Puede encargarse de todo el proveedor informático?
Puede realizar tareas técnicas e incluso presentar comunicaciones con la habilitación correspondiente, pero el responsable conserva sus obligaciones. Debe recibir información suficiente y poder comprobar las decisiones. El procedimiento tiene que cubrir también incidentes que el proveedor no controla, como expedientes impresos o errores de destinatario. Externalizar la informática no elimina la necesidad de coordinación dentro de la organización.
¿Se espera a confirmar todos los daños para avisar?
No. Los umbrales se basan en riesgo, no en exigir que el perjuicio ya se haya materializado. Investigue con diligencia, notifique cuando proceda y complete la información por fases sin dilación indebida. Si nuevos hechos cambian una decisión inicial de no notificar o no comunicar, reevalúela y deje constancia del motivo y de las actuaciones posteriores.