Imagen generada con IA.
Hay una frase que resume bien lo ocurrido: en casa de herrero, cuchillo de palo. Una resolución del Consejo de Transparencia y Buen Gobierno (CTBG) ha obligado a la Agencia Española de Protección de Datos (AEPD) a revelar un dato que la propia Agencia se negaba a facilitar: la fecha exacta en la que notificó una brecha de seguridad que ella misma había sufrido. El organismo que exige a empresas y administraciones cumplir con el RGPD ha tenido que ser corregido por otro organismo público por no aplicarse a sí mismo el mismo rigor. El caso es breve, pero la lección de fondo es directamente aprovechable para cualquier entidad que trate datos personales: el plazo de 72 horas del artículo 33 RGPD no admite lecturas cómodas, ni siquiera para quien lo supervisa.
El origen: un envío erróneo que expuso datos de terceros
El caso arranca en octubre de 2024. Un ciudadano recibió por error un correo de la AEPD que en realidad iba dirigido a una empresa con la que, años atrás, había tenido relación. El error no se limitó al destinatario equivocado: el mensaje incluía documentos adjuntos con datos identificativos de terceras personas —DNI, nombre, apellidos y firma incluidos—. Es decir, la propia Agencia había provocado una violación de la seguridad de datos personales ajenos.
El ciudadano pidió explicaciones sobre cómo se había gestionado internamente el incidente. La AEPD respondió, pero solo a medias: confirmó que hubo fuga de datos, que fue comunicada y documentada, y que, a su juicio, no representaba un riesgo alto para los afectados conforme al artículo 34 del RGPD. Lo que no quiso entregar fue un dato muy concreto: en qué fecha la propia AEPD notificó esa brecha a sí misma como autoridad de control.
Ese detalle no es accesorio. El artículo 33 del RGPD obliga a cualquier responsable del tratamiento a notificar una violación de seguridad en un máximo de 72 horas desde que tiene conocimiento de ella. Sin la fecha de notificación, no hay forma de comprobar si ese plazo se respetó.
Por qué Transparencia le dio la razón al ciudadano
Ante la negativa, el ciudadano acudió al CTBG. La AEPD defendía su silencio con los mismos argumentos que suelen usar las empresas que ella misma investiga: que dar el dato podría perjudicar sus pesquisas, afectar a sus funciones de control y comprometer la seguridad del proceso.
El Consejo de Transparencia distinguió con claridad entre dos cosas muy distintas. Por un lado, el expediente técnico completo del incidente —origen, consecuencias, medidas adoptadas— sobre el que sí admite que puede existir un margen de reserva mientras dura una investigación. Por otro, la simple fecha en la que se comunicó la brecha, que es lo único que el ciudadano pedía. Ahí el CTBG fue rotundo: consideró injustificado el argumento de que revelar únicamente esa fecha pudiera perjudicar ninguna investigación en curso. El propio texto de la resolución deja claro que invocar de forma genérica que algo «afecta a las funciones de control» no basta como excusa automática para negar información: los límites al derecho de acceso deben interpretarse de forma restrictiva, y quien los alega tiene que acreditar el perjuicio real, no solo mencionarlo. Con ese razonamiento, el Consejo ordenó a la AEPD entregar la fecha en un plazo de diez días.
La AEPD, responsable del tratamiento cuando gestiona sus propios datos
Lo más interesante del caso, más allá de la anécdota, es la idea de fondo: la AEPD no actúa siempre como autoridad de control. Cuando gestiona su correo, sus archivos y sus sistemas internos, es un responsable del tratamiento como cualquier empresa, sujeto a las mismas obligaciones del RGPD que ella misma exige a terceros. El hecho de que en este caso concreto coincidieran ambos papeles —supervisor y supervisado— es precisamente lo que reforzaba el interés público en conocer cómo se había gestionado el incidente puertas adentro.
Esa doble condición, además, no es exclusiva de la AEPD: cualquier administración pública —un ayuntamiento, una consejería, un organismo autónomo— es responsable del tratamiento de los datos que gestiona en su día a día, tenga o no, además, competencias de inspección o control sobre otras materias. Tener funciones de vigilancia sobre terceros nunca ha sido, ni debería serlo, un salvoconducto para relajar el propio cumplimiento.
Qué implica para la rendición de cuentas en el sector público
La resolución del CTBG fija un criterio con recorrido más allá de este caso concreto: la fecha en la que se notificó una brecha de seguridad tiene valor jurídico propio y no puede ocultarse invocando de forma genérica un perjuicio a la investigación, precisamente porque es el dato que permite verificar si se cumplió el plazo del artículo 33. Para cualquier administración pública, el mensaje es directo: ni ser organismo público, y mucho menos ser autoridad supervisora, exime de acreditar con datos concretos —fechas, plazos, registros— el cumplimiento de sus propias obligaciones frente a una brecha.
Para las empresas privadas que son inspeccionadas por la AEPD, o que simplemente se relacionan con administraciones públicas, el caso también deja una lectura práctica: si la propia Agencia ha sido corregida por no documentar con transparencia el cumplimiento de un plazo de notificación, es razonable esperar que exija ese mismo nivel de trazabilidad cuando evalúe cómo gestionó una empresa su propia brecha de seguridad. Tener bien registradas la fecha de detección, la fecha de notificación a la AEPD y el análisis de riesgo de cada incidente deja de ser una buena práctica recomendable para convertirse en la prueba documental que, ante una inspección, marca la diferencia entre una sanción y un expediente archivado.
Si tu empresa necesita revisar su protocolo de gestión y notificación de brechas de seguridad para que quede correctamente documentado ante una eventual inspección, en DataIbérica podemos ayudarte a diseñarlo o auditarlo. Contacta con nosotros si quieres revisar tu caso concreto.
Fuente principal: Confilegal — «Transparencia corrige a la AEPD por no aplicarse sus propias exigencias en una brecha de seguridad».
