Algunas cuestiones prácticas sobre brechas de seguridad

Acabamos de terminar el webinar sobre brechas de segurida

d. Os resumo algunos puntos interesantes que hemos comentado.

Algunas cifras…

De acuerdo con la información que figura en la Memoria de la AEPD, en 2023, aunque se abrieron menos procedimientos sancionadores relacionados con medidas de seguridad (14 en 2023, frente a 32 en 2022), el importe de las multas económica impuestas aumentó considerablemente con respecto al año anterior. En 2022, se impusieron en multas un total de 821.800 euros. En 2023, fueron 12.907.000 millones.

Junto con las resoluciones habituales relacionadas con errores “menores” como envíos de correos electrónicos sin copia oculta o difusión de documentos a personas no autorizadas, en 2023, se resolvieron algunos asuntos muy relevantes. Probablemente, las resoluciones estrella del año pasado que todos hemos comentado fueron éstas:

-   Multa al Banco Bilbao Vizcaya Argentaria de 1.640.000 euros, en un caso en el que se robó el DNI y el móvil a una anciana ingresada en una residencia, a la que, además, drogaron durante todo el fin de semana para que no se diera cuenta del robo, y aprovechando los efectos robados, se cambiaron las claves bancarias y se contrataron varios productos.

-   Un caso transfronterizo, relacionado con información que se solicita a un cliente en cumplimiento de normativa de prevención de blanqueo de capitales por parte de OPEN BANK, S.A. El cliente se negaba a remitir información que consideraba sensible por email, y no se le dio ninguna opción alternativa más segura. La multa impuesta fue de 2,5 millones de euros.

-  La más compleja de todas, la multa a Endesa de 6.100.000 euros en un supuesto en el que estaban implicados distintos proveedores de servicios de la entidad. En los dos primeros supuestos, no se considera incumplido el artículo 5.1.f) del RGPD, pero sí el 32 del RGPD. En el caso de Endesa, se consideran infringidos ambos.

La Audiencia Nacional también resolvió dos recursos contencioso-administrativos relacionados con confidencialidad y medidas de seguridad de interés. En uno de ellos, se pronuncia sobre el alcance del artículo 5.1.f) del RGPD y su relación con el artículo 32 del RGPD.  Se trata de un recurso presentado por Xfera Móviles en un supuesto de obtención fraudulenta de un duplicado de tarjeta SIM. La AEPD sanciona en base al artículo 5.1.f) y Xfera considera, entre otras cuestiones, que debería haber subsumido la infracción en el artículo 32 del RGPD. La AN explica que los ambos artículos tienen ámbitos diferentes, aunque relacionados entre sí, y que en ese caso es de aplicación el art. 5.1.f) como había dicho la AEPD en su resolución. En concreto señala esto:

“El Art. 5 RGPD, aplicado por la AEPD, referido a los "Principios relativos al tratamiento", dispone, en su apartado 1 que los datos personales serán : "f) tratados de manera que se garantice una seguridad adecuada de los datos personales, incluida la protección contra el tratamiento no autorizado o ilícito y contra su pérdida, destrucción o daño accidental, mediante la aplicación de medidas técnicas u organizativas apropiadas (integridad y confidencialidad)".

Por su parte, el artículo 32 del RGPD, "seguridad del tratamiento", cuya aplicación propugna la demandante, establece como ha de articularse la seguridad del tratamiento en relación con las medidas de seguridad concretas que hay que implementar … Es decir, el artículo 32, como pone de relieve el Abogado del Estado, aunque relacionado con el 5.1.f), no circunscribe el principio en su totalidad, pues el artículo 5.1.f) del RGPD requiere para su aplicación una pérdida de confidencialidad (…)”.

En la sentencia comentada, también se analiza si se ha aplicado una responsabilidad objetiva a la empresa multada. La AN considera que no es así, curiosamente, porque la pérdida de confidencialidad se ha producido por una causa imputable al responsable del tratamiento que es -redoble de tambor- la falta de medidas de seguridad adecuadas.

“(…) Sobre la supuesta responsabilidad objetiva, la resolución recurrida no considera responsable a Xfera por el resultado, sino por una pérdida de confidencialidad vinculada a la insuficiencia de las medidas de seguridad implantadas y, en definitiva, debido a una falta de diligencia de dicha entidad. Así, se argumenta por la AEPD -página 858 del expediente- " ha quedado acreditado que las medidas implantadas por Xfera son insuficientes (...) De una manera no exhaustiva nos fijaremos en la deficiente configuración de las preguntas formuladas en la política de seguridad para poder obtener el duplicado de la tarjeta SIM".

En general, los datos personales asociados a la política de seguridad son los básicos de cualquier cliente: nombre y apellidos, DNI y número de línea de teléfono (YOYGO y MASMÓVIL) (...) basta con poseer los datos básicos de un cliente para poder superar la política de seguridad, sin que ninguna pregunta adicional sea formulada respecto de algún dato que conozca únicamente la operadora y su cliente. Ningún requisito suplementario es requerido. Llama la atención que sólo en algunas de las marcas se realizan comprobaciones adicionales más rigurosas, como son datos de uso que solo la persona que utiliza la línea en cuestión podría contestar correctamente. Así, respecto de la marca LEBARA se establece la superación de la política de seguridad en dos capas, figurando en la segunda de ellas la formulación y respuesta correcta de dos o tres preguntas de uso para verificar datos muy concretos que podrían identificar fehacientemente al cliente. Esto muestra que Xfera si tenía establecidas medidas de seguridad muy sencillas más apropiadas para identificar de manera más fidedigna a un cliente yque no implementó en todas sus marcas.”

Podríamos pensar que cuando hay medidas de seguridad inadecuadas y como resultado de ello se produce una pérdida de confidencialidad, se sancionará solamente por el artículo 5.1.f) y no por el 32… pero no… A veces, la AEPD y la AN han considerado que se incumplen los dos artículos, sin que exista “non bis in idem”.

En mi opinión, todavía no se ha explicado de una forma comprensible para el abogado lopedé medio qué deficiencia distinta de las medidas de seguridad insuficientes se han detectado en estos casos para sancionar por ambos artículos. Por ejemplo, en el supuesto de Pillows Hotels S.L., donde la AEPD propone sancionar tanto por el art. 5.1.f) como por el art. 32, dice esto:

“La documentación obrante en el expediente ofrece indicios evidentes de que la entidad, podría haber vulnerado el artículo 5.1.f) del RGPD, principios relativos al tratamiento, al no garantizar debidamente la confidencialidad de los datos de carácter personal como consecuencia de la quiebra de seguridad producida.

Este deber de confidencialidad, debe entenderse que tiene como finalidad evitar que se realicen filtraciones de datos no consentidas por los titulares de los mismos.

(…)

En el presente caso, se evidencia que las medidas de seguridad que la parte reclamada tenía implantadas en relación con los datos que sometía a tratamiento no eran las pertinentes ni adecuadas para garantizar la seguridad de los datos personales en el momento de producirse los citados incidentes (quiebras)”.

Es lógico que con explicaciones como estas surjan las dudas de por qué se sanciona en base a un artículo y no a otro, o se piense que se están imponiendo dos multas por los mismos hechos. Al fin y al cabo, todo gira alrededor de la falta de medidas de seguridad. Y sí, es cierto que se pueden tener unas medidas de seguridad muy deficientes sin que se haya materializado una pérdida de confidencialidad, pero cuando se vulnera la confidencialidad de los datos porque las medidas de seguridad no son las adecuadas (no por otro motivo), no se debería considerar que existen dos infracciones por los mismos hechos (la pérdida de confidencialidad es el resultado de las medidas de seguridad insuficientes). Hay un punto de coincidencia entre los dos artículos, una especie de intersección que regulan ambos preceptos, que no se ha aclarado suficientemente… salvo que la idea sea sancionar la pérdida de confidencialidad en sí misma y de forma objetiva. En este caso, la consecuencia es que nunca se va a poder archivar un procedimiento donde haya pérdida de confidencialidad (entre otras cosas)...

Plazo de notificación de la brecha de seguridad a la AEPD

En otro orden de cosas, hemos analizado algunos aspectos que pueden tomarse en consideración para valorar el riesgo de la brecha, más allá de la fórmula simplona que propuso la Agencia en las primeras versiones de su guía de brechas de seguridad: posibles efectos negativos para el afectado, vulnerabilidad de los afectados, posibilidad de identificación de los titulares de los datos, etc. Dicho análisis debe efectuarse en el plazo de 72 horas naturales (es decir, si se produce en viernes, cuenta el fin de semana…) desde que se tiene constancia del incidente. El plazo no empieza a computarse cuando he analizado la brecha, valorado su gravedad y decidido que reviste un riesgo que hace que deba notificar. En caso de duda, se debe notificar.

En el caso de que la brecha afecte a un encargado del tratamiento, el plazo para el responsable (que es el obligado a notificar, salvo que en el contrato se acuerde otra cosa), empieza a contar desde que recibe la comunicación del encargado. Así lo determina el EDPB en las Guidelines 9/2022 (y diculpen que no me levante a buscar el link al documento): “The processor just needs to establish whether a breach has occurred and then notify the controller. The controller uses the processor to achieve its purposes; therefore, in principle, the controller should be considered as “aware” once the processor has informed it of the breach”.

Por eso, es recomendable dejar muy claro en el contrato que la brecha se comunique por escrito y a través de un medio que nos permita gestionarla rápidamente. La notificación por escrito servirá de prueba del momento en el que tuvimos constancia tanto ante la AEPD, como a efectos de exigir responsabilidad al proveedor.

Normalmente, los contratos dicen que el proveedor debe comunicar la brecha en un plazo de 24 o 48 horas. Ese tiempo no se descuenta del plazo de 72 horas, como hemos visto. Tampoco es un plazo legal, porque el RGPD no impone al encargado del tratamiento la obligación de notificar al responsable en un periodo concreto. Simplemente, se determina que la notificación se hará “sin dilación indebida”. Eso sí, si incluimos un plazo en el contrato, el encargado deberá cumplirlo.