Güncel olmayan altyapıdan kaynaklanan büyük veri ihlali

1/173

 Expediente N.º: EXP202305790
Procedimiento Sancionador N.º PS/00552/2023.

- RESOLUCIÓN DE PROCEDIMIENTO SANCIONADOR

Del procedimiento instruido por la Agencia Española de Protección de Datos y en base
a los siguientes

ANTECEDENTES

PRIMERO: Con fecha 19/04/2023 se notifica a la División de Innovación Tecnológica
de esta Agencia una brecha de seguridad de datos personales por parte del
responsable del tratamiento CECOTEC INNOVACIONES, S.L.U, con NIF B97937890
(en adelante, la empresa), relativa a la exfiltración y puesta en venta en internet de una
base de datos con datos personales de clientes y empleados con más de 1 millón de
registros, advertida el 5/04/23 por el Instituto de Ciberseguridad Español (INCIBE).

En dicha notificación de brecha se ponen de manifiesto los siguientes datos
principales:

- Resumen del incidente:

La empresa recibe notificación del INCIBE el 5/04/23 en la que se informa que
un actor malicioso ha publicado un post en un foro de la dark web en el que
indica estar en posesión de una base de datos de una empresa española con
aproximadamente 1 millón de registros, cuyo nombre no se menciona, si bien
de diversos datos aportados parece deducirse que podría tratarse de su
empresa, por lo que el INCIBE le advierte de tal publicación, requiriéndole para
que compruebe la veracidad del ciberataque a su base de datos, aportándole 17
registros de datos publicados como muestra por el actor malicioso.

La empresa no se percata de la notificación enviada hasta que no recibe una
segunda notificación del INCIBE del 12/04/23, comunicando el incidente a su
Delegada de Protección de Datos e iniciando una investigación de lo sucedido
el 14/04/23, que no finaliza hasta el 17/4/23, fecha en la que ésta le informa a
INCIBE de que no da crédito a que el ataque sea viable y, en su caso, veraz,
habiendo detectado únicamente 6 registros reales de entre los 17 remitidos que
pertenecen a una base de datos de su empresa que fue cerrada en 2021, a la
que sólo tienen acceso los empleados. Igualmente, se indica que desde la
empresa se han tomado medidas de seguridad respecto con la base de datos,
reforzando los límites de acceso y uso de la misma.

- Se manifiesta que la brecha afecta a la siguiente tipología de datos: “Datos
básicos (Ej: nombre, apellidos, fecha de nacimiento), DNI, NIE, Pasaporte y / o
cualquier otro documento identificativo, Datos de contacto”).

- El responsable manifiesta que los datos personales identificados se encuentran
ubicados en una plataforma de datos que se cerró en el año 2021, pero a la que
pueden acceder empleados para consultar asuntos relacionados con clientes y
pedidos.

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

2/173

- Afectados: 6 interesados. Los datos no estaban cifrados.

- Se califica de brecha de confidencialidad y gravedad baja.

- Se ha producido el incidente por algún fallo, deficiencia o incumplimiento de
medidas de seguridad implementadas: Desconocido

- No se ha denunciado ante autoridades.

- Se han adoptado nuevas medidas tras la brecha, que no se detallan.

- Los afectados no serán comunicados.

- Considera que ha tomado todas las acciones posibles y da por resuelta la
brecha.

SEGUNDO: Con fecha de 3 de mayo de 2023 se ordena por la Directora de la Agencia
a la Subdirección General de Inspección de Datos que realice las oportunas
investigaciones previas con el fin de determinar tanto la concurrencia y alcance de la
brecha de confidencialidad notificada, como la posible responsabilidad de la empresa
CECOTEC por un posible incumplimiento de sus obligaciones como responsable de la
protección de los datos personales contenidos en dicha plataforma, toda vez que:

- Existen dudas sobre la veracidad del ciberataque que niega la reclamada, así
como de la concurrencia de una brecha de confidencialidad, y su gravedad o
número de afectados, al manifestar el responsable que no da credibilidad
alguna al anuncio del ciberdelincuente, a pesar de reconocer que se han
identificado 6 datos reales de los 17 registros publicados en la muestra, que se
corresponden a datos que se encuentran en una plataforma del responsable.
Asimismo, es preciso concretar el tipo de datos personales afectados, puesto
que únicamente se indica que la brecha afectó: “a datos personales básicos (Ej:
nombre, apellidos, fecha de nacimiento), DNI, NIE, Pasaporte y / o cualquier
otro documento identificativo, Datos de contacto.” Y cuáles de ellos son de
prueba o reales.

- Existen dudas sobre el incumplimiento del deber de notificar la brecha a los
afectados de la misma, puesto que responsable manifiesta que la brecha afecta
a la confidencialidad de los datos y que los datos no estaban cifrados,
anonimizados o protegidos de otra forma para que los interesados no puedan
ser identificados. Pero, sin embargo, no les ha comunicado la posible brecha ni
siquiera a estos 6 casos reales detectados.

- Existen dudas sobre las medidas de seguridad previas al incidente al manifestar
el responsable que una plataforma cerrada en 2021 continúa en uso, y que
precisamente tiene más de un millón de registros de datos, entre los que hay
datos personales de clientes y empleados. Al tratarse de una plataforma
catalogada por el propio responsable como “cerrada”, existen dudas de que se
apliquen actualizaciones de seguridad a la plataforma, y que la misma disponga
de las medidas de seguridad adecuadas para proteger la trazabilidad,

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

3/173

disponibilidad, confidencialidad.

- Existen dudas sobre la adopción de las medidas de seguridad previas al
incidente en el caso de que se esté utilizando una nueva plataforma desde
2021, a la que se hayan migrado dichos datos, puesto que esta migración
requiere de medidas adicionales de protección de los datos personales que es
preciso comprobar.

- Existen dudas sobre las medidas de seguridad previas al incidente al manifestar
el responsable que en una misma base de datos en una plataforma cerrada
podrían almacenarse datos de prueba con datos reales todavía en uso.

- Por todo lo anterior, existen también dudas sobre el cumplimiento de la
obligación del responsable de tratar los datos de tal manera que se garantice su
confidencialidad.

TERCERO: Abiertas las actuaciones de investigación con el número AI/00150/2023, la
Subdirección General de Inspección de Datos procedió a la realización de actuaciones
previas de investigación para el esclarecimiento de los hechos en cuestión, y en virtud
de las funciones asignadas a las autoridades de control en el artículo 57.1 y de los
poderes otorgados en el artículo 58.1 del Reglamento (UE) 2016/679 (Reglamento
General de Protección de Datos, en adelante RGPD), y de conformidad con lo
establecido en el Título VII, Capítulo I, Sección segunda, de la LOPDGDD, formuló
diferentes requerimientos de información y diligencias de comprobación a las que se
hará referencia seguidamente.

CUARTO: Con fecha de 4/08/2023 se remite por la inspección de la AEPD un primer
requerimiento de información a la empresa -notificado el 8/8/23 a la misma-, al objeto
de que informase a esta Agencia de los datos y documentos que se solicitan, y de las
acciones llevadas a cabo para adecuarse a los requisitos previstos en la normativa de
protección de datos.

Con fecha 30/08/2023 se recibe en esta Agencia primer escrito de respuesta al
requerimiento, indicando lo siguiente:

1. En relación con las actividades de tratamiento afectadas por la brecha y el
Registro de Actividades de Tratamiento (RAT):

Se afirma que la plataforma afectada por el incidente era la antigua tienda en
línea de la empresa, basada en el software ***SOFTWARE.1, y que había sido
migrada a una nueva plataforma que daba continuidad a la anterior.

Las actividades afectadas por la brecha son:

o Actividad “Gestión de clientes” con los siguientes datos incorporados en
el RAT:

 Finalidad: gestionar los pedidos a través de la web. Atender dudas y
quejas de clientes. Gestionar devoluciones y cancelaciones de
pedidos. Enviar comunicaciones comerciales a los clientes.

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

4/173

 Fecha inicio actividad: año 2013.
 Datos afectados: Nombre y apellidos, NIF, email, teléfono y domicilio.
 Transferencias: los datos pueden ser transferidos haciendo uso de
Cláusulas Contractuales Tipo aprobadas por la CE.
 Plazo de conservación: están marcados por la prescripción de
acciones legales de la Ley de Defensa de Consumidores.
 Medidas de seguridad: (…).
 Base jurídica: contrato, cumplimiento obligación legal (Ley
Consumidores), interés legítimo.

o Otras actividades afectadas y de las que también consta información en
el RAT:
 Envío de Newsletter: con fecha de inicio de la actividad 2015.
 Cuentas de usuarios web: con fecha de inicio de la actividad 2013.
 Gestión de RRHH (afirman la existencia de un empleado afectado que
aparecía en la muestra publicada por el atacante): fecha de inicio de la
actividad 2014.

2. En relación con la plataforma afectada se afirma: “La plataforma se erigía
como una tienda en línea diseñada a través del software ***SOFTWARE.1,
dedicada a la creación y gestión de tiendas virtuales para el comercio
electrónico”.

Esta plataforma se alojaba en la infraestructura de ***PLATAFORMA.1 y
estaba configurada para que no tuviera exposición directa a través de internet,
de forma que se “garantiza que todos los datos personales se mantengan
resguardados y solo fueran accesibles para los componentes internos de la
plataforma.”.

Afirman que “La plataforma fue sustituida por una nueva tienda en línea
desarrollada internamente que adoptó tecnologías de desarrollo web de código
abierto más modernas (…) Esta transición se completó a principios de 2021. A
pesar del cierre de la plataforma original, se ha mantenido un acceso limitado a
la misma (su ***INTERFAZ.1) con el único fin de poder atender solicitudes,
necesidades y/o reclamaciones de clientes de la empresa”.

A la fecha de la brecha, por tanto, el ***INTERFAZ.2 (…) de esta plataforma no
se encontraba operativo, manteniéndose únicamente activo ***INTERFAZ.1
(…), que permite añadir/editar/eliminar productos y gestionar datos de clientes.

3. En relación con los datos afectados por la brecha de datos personales.

Se manifiesta que en la plataforma afectada: “Se almacena una variedad de
datos personales que eran esenciales para el funcionamiento y la gestión de la
tienda en línea, sin embargo, en el contexto del posible incidente reportado por
el INCIBE, los datos supuestamente afectados se relacionan con la tabla
***TABLA.1 dentro de la base de datos”.

Los datos afectados según la captura publicada por los ciberdelincuentes
fueron: ciudad, código postal, segunda dirección postal, notas sobre la

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

5/173

dirección postal, teléfono principal y móvil, DNI y número de identificación
fiscal.

4. En relación con la muestra publicada por los ciberdelincuentes se afirma lo
siguiente:

Se aporta un correo interno donde el departamento de ciberseguridad realiza la
siguiente afirmación en relación con los datos que contenía la captura de
pantalla publicada en el foro: “Tras realizar el análisis, se vio que los registros
de la tabla coinciden con los de la tienda antigua de la empresa. Tras investigar
junto al departamento ecommerce e infraestructura pudimos ver que los
registros que tiene el atacante son desde 2016 a 2020, esto suponiendo que
tenga el 1.000.000 de registros que dice tener, ya que solamente se muestra
18 registros en la imagen que adjunta. En dicha tabla se encuentran datos de
usuario como direcciones, código postal, ciudad, teléfono, email…”.

5. En relación con los usuarios que tenían acceso a esta plataforma afirman que:

- “Los usuarios que tenían acceso a la administración de la plataforma antes del
cierre de esta (…). A su vez, cada uno de estos departamentos tenía asignados
permisos específicos según su función en la operación de la tienda en línea.”

- “En cuanto a la asignación de roles y permisos de acceso a la plataforma, en
aquel momento no existía un procedimiento formalizado para esta tarea. La
estructura de usuarios, roles y sus permisos estaba configurada de manera
relativamente sencilla debido a que, en aquel entonces, la empresa contaba
con un número de empleados relativamente pequeño. Se operaba de la
siguiente manera: Los responsables de los distintos departamentos
comunicaban al Departamento de IT los permisos específicos que necesitaba
cada usuario, y IT procedía a asignarlos según las indicaciones.”

- Se afirma que después del supuesto incidente se tomaron medidas
significativas para fortalecer la seguridad de la plataforma: (…).

6. En relación con las medidas para garantizar la trazabilidad existente en la
plataforma, se realizan las siguientes afirmaciones:

- La empresa indica que “antes de recibir la notificación por parte de INCIBE, la
plataforma ya tenía medidas sólidas implementadas para garantizar la
trazabilidad de las acciones en los accesos tanto a la plataforma como al
sistema de gestión de la base de datos. Estas medidas fueron diseñadas para
garantizar la seguridad y la integridad de los datos, así como para detectar
cualquier actividad sospechosa de manera temprana”.

- No obstante, esta respuesta contrasta con la afirmación que hace el propio
departamento de ciberseguridad en uno de los correos internos aportados en la
investigación, donde se afirmaba lo siguiente: “intentamos ver los Logs para ver
la trazabilidad y destapar al atacante, pero no pudimos sacar nada en claro, ya
que vimos los logs del ***SOFTWARE.1 y no eran de gran utilidad ya que solo
mostraban los inicios de sesión de los usuarios, además en su día por temas de

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

6/173

rendimiento se desactivaron algunos logs que registraba el CMS y que no se
volvieron a activar posteriormente. También vimos que dicho ***SOFTWARE.1
presentaba varias vulnerabilidades de versión, pero no podemos determinar si
ese es el vector de entrada”.

- Que en lo referente al sistema gestión de base de datos dicen que existían
medidas de restricción de acceso directo desde internet y logs de
monitorización de accesos y actividad en la base de datos, pero no se detallan
ni acreditan.

7. Respecto a las circunstancias del incidente y a la certeza del ataque a la
empresa.

- Se aporta una hoja Excel que contiene el registro documentado del incidente,
que manifiesta que desde la empresa no se da crédito a la veracidad del
ataque, si bien se manifiesta que: “El responsable de seguridad corroboró que
el correo de INCIBE no era intento de Phishing, por lo que el día 17 de abril a
las 11:48 se contactó con este instituto que corroboró este mismo día que la
información enviada era correcta. Desde la empresa no se ha podido identificar
que el actor malicioso haya podido acceder a los sistemas de la empresa.
Aunque el atacante afirma estar en posesión de 1 millón de registros, desde la
empresa sólo se puede tener acceso a 17 de ellos. La plataforma tiene más de
1 millón de registros por lo que no coincide con lo publicado por el
ciberdelincuente”.

- En base a ello, se aporta el informe de la DEP de 19 de abril de 2023 que dio
lugar a notificar la brecha a esta Agencia, en el que se manifiesta que a fecha
19 de abril de 2023 la empresa sólo podía confirmar que no habían podido
identificar accesos sospechosos a los sistemas internos y que el número de
registros que afirmaba disponer el ciberdelincuente no coincidía con los
existentes en las bases de datos. Se realiza una valoración detallada del
incidente y se concluye con una severidad o impacto MEDIO y probabilidad de
materialización BAJA, concluyéndose comunicar el incidente a la AEPD.

- No obstante, la conclusión notificada por la empresa a INCIBE y a esta Agencia
no coincide con la dada por el responsable de ciberseguridad de la empresa a
la DPD, que remite un correo interno a la misma el 15 de abril de 2023 en el que
manifiesta no poder determinar con claridad la fuente del ataque, por no tener
ningún sistema de monitorización de equipos en la plataforma atacada. Nos
referimos al correo interno enviado desde la dirección ***EMAIL.1 a la dirección
***EMAIL.1 el día 14 de abril de 2023 aportando información sobre el incidente,
que indica:

“Tras realizar el análisis de los registros de la imagen publicada en el
foro se vio que coinciden con los de la tienda antigua de la empresa
(…) que se cerró en 2021 pero se sigue usando por algunas personas
en modo consulta”.
“También intentamos ver los logs para ver la trazabilidad y destapar al
atacante, pero no pudimos sacar nada en claro ya que solo mostraban
los inicios de sesión de los usuarios, además en su día por temas de

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

7/173

rendimiento se desactivaron algunos logs. A nivel servidor y base de
datos no pudimos ver mucho ya que no se estaba monitorizando.
También vimos que dicho ***SOFTWARE.1 presentaba varias
vulnerabilidades de versión, pero no podemos determinar si ese era el
vector de entrada”.
“Tras analizar todos los entornos, el departamento de ciberseguridad no
puede determinar si ha sido culpa de malware en un workstation o
desde el propio aplicativo web, ya que actualmente desde el
workstation no tenemos ningún sistema de monitorización de equipos,
además de no tener monitorizado el aplicativo web”.

- Se manifiesta asimismo que desde la empresa se han tomado las siguientes
medidas: (…).

- Se toma la medida adicional (…). No hay constancia de perjuicios causados
en posibles clientes afectados.

8. En respuesta a nuestra solicitud para que acrediten los análisis de riesgos de
las actividades de tratamientos afectadas por la brecha.

Se adjunta copia del informe definitivo de los análisis de riesgos para los
derechos y libertades de las personas afectadas por las actividades de
tratamiento relacionadas con la brecha (clientes) de fecha 10 de abril de 2022.
En este se manifiesta que: “Por motivos que se desconocen, en su día se
realizó un análisis de riesgos conjunto para los tratamientos de Clientes y
Proveedores, Gestión de RRHH y Selección de personal, por lo que se adjunta
el análisis de riesgo conjunto”.

Del análisis de este documento por el inspector se extrae que el Informe de
análisis de riesgos es de 10 de abril de 2022, por lo que no se informa de los
riesgos anteriores a esa fecha; y contiene los siguientes apartados:

 Un apartado con la descripción de los tres tratamientos afectados por el
análisis: “Clientes y Proveedores”, “Selección de Personal” y “Gestión
Recursos Humanos”.
 Contiene un apartado “Identificación y Análisis de los factores de riesgo
(inherente y residual) que remite a un Anexo I, que no se aporta.
 Contiene un apartado donde se asigna un valor a la probabilidad e
impacto para los siguientes riesgos inherentes identificados: realizar
transferencias internacionales a países sin adecuación, no facilitar la
información de forma correcta, almacenar datos por periodos
superiores, carecer mecanismos de control de la relación con
encargados, deficiencias en los protocolos de almacenamiento en
formato físico.
 Contiene un apartado con un plan de acción que incorpora las
siguientes medidas de control: (…).

9. En relación con los plazos de conservación de los datos personales de las
actividades afectadas, afirman que estos son de:

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

8/173

o Hasta 9 años en base a la prescripción de las acciones en materia de
consumidores y usuarios.
o Hasta 4 años conforme a la Ley General Tributaria.
o Hasta 5 años prescripción general de las acciones que no tienen plazo
específico, art 1964 Código Civil.
o Hasta 6 años en base al art 30 del Código de Comercio.

10. Sobre las medidas preventivas implantadas:

 (…)

11. En respuesta a nuestra solicitud para que acrediten los procedimientos
implantados en la organización para gestionar las brechas de seguridad que
afecten a datos personales.

Se afirma que se ha redactado una nueva versión de este procedimiento y se
ha puesto en conocimiento de los empleados. Se aporta captura de pantalla de
un correo interno informando sobre ello, no obstante, no se aporta copia
documental acreditativa. Solo se aporta captura de un correo interno enviado el
10 de agosto de 2023 con el siguiente texto: “(…)”.

Afirman que en los últimos meses se han realizado (…), se acreditan capturas
de pantalla de actividades realizadas en los días 11 de mayo de 2023 y 27 de
junio de 2023.

Se afirma que el Responsable de Ciberseguridad ha desarrollado una
herramienta interna con la que los empleados pueden (…). No se acredita.

12. En relación con la justificación del motivo por el que notificaron la brecha de
datos personales fuera de plazo.

La empresa afirma que no fue hasta el jueves 13 de abril de 2023 cuando el
INCIBE aportó toda la información referente a la posible brecha y, por tanto,
cuando tuvo constancia de la posible filtración y las capturas de pantalla
publicadas por el hacker. Y que no contestaron en el plazo máximo de 72 horas
porque este expiró fuera de la jornada laboral, puesto que el lunes 17 de abril
de 2023 fue también un día festivo y no laborable en Quart de Poblet
(municipio en el que se encontraba la sede de la misma en el momento de la
gestión del incidente).

QUINTO: En fecha 4 de septiembre de 2023 se realiza nuevo requerimiento de
información al responsable de tratamiento a la empresa para que amplíe la
documentación aportada, que se responde el 18 de septiembre de 2023 de la
siguiente forma:

1. Que confirmen si existían análisis de riesgos anteriores al 10 de abril de 2022,
así como las posibles actualizaciones posteriores de este tras la brecha.

Se confirma que no existe análisis anterior a esta fecha.

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

9/173

2. Que se aporte el documento referenciado en el análisis de riesgos y no
localizado en la respuesta anterior.

Se aporta documento Excel con el fichero referenciado en el análisis de riesgos
de 10 de abril de 2022 y no localizado en la respuesta al requerimiento anterior,
pero no se obtiene información adicional de su análisis. Se incluye fichero
Excel con la actualización del análisis de riesgos tras la brecha de seguridad.

3. Que acrediten el procedimiento interno implantado para la gestión de brechas
de seguridad.

Se realiza la siguiente afirmación: “Se informa a la AEPD que, en el último año
el puesto de Delegado de Protección de Datos ha sido ocupado por tres
personas distintas, no habiendo una continuidad en las funciones del Delegado
de Protección de Datos especificadas en el artículo 39 del Reglamento
2016/679 de 27 de abril de 2016 (en adelante, “RGPD”). Es por ello por lo que,
actualmente, la empresa se encuentra en un proceso de revisión urgente de
documentos y de decisión de medidas a tomar y de procedimientos a
implementar, entre los que se encuentra la revisión de todos los análisis de
riesgos realizados y la valoración de la necesidad de realizar una evaluación
de impacto de los mismos”.

Se afirma que el 14 de septiembre de 2023 se constituyó un Comité de
Seguridad al objeto de dictar medidas.

Se aporta un documento interno con lo que la empresa manifiesta ser unas
fichas que contienen el Plan interno de gestión de brechas de seguridad, que
no contiene firma ni fecha de creación, solo una “fecha de última actualización
(…)”, y se acompaña otro documento denominado Protocolo de Gestión de
Brechas de Seguridad, que no está firmado, en el que consta únicamente el
siguiente texto al final del documento: “Fecha de última actualización (…)”.

En relación con la versión de ***SOFTWARE.1 utilizada por la plataforma
(1.6.1.24), la empresa afirma: “Respecto a la versión 1.6.1.24 de la plataforma
de ***SOFTWARE.1 (en adelante, “la plataforma”), es importante determinar
que, aunque en esta versión existen vulnerabilidades conocidas (CVE), la
mayoría de estas afectan a ***INTERFAZ.2 (…) y, tal y como indicamos en
nuestro escrito contestando al anterior requerimiento, ***INTERFAZ.2 (…) no
se encuentra activo. Únicamente se encuentra activo el ***INTERFAZ.1 de la
plataforma que, además, tiene aplicado un nivel de acceso a datos. En cuanto
a las vulnerabilidades que le afectaban, las mismas ya fueron identificadas y
abordadas con las medidas de seguridad apropiadas, de conformidad con lo
establecido en nuestro primer escrito.

Reconoce que la razón por la cual la plataforma todavía está accesible en
Internet es que todavía no se ha realizado la migración de las integraciones de
la antigua plataforma a la nueva. Manifiestan que el ***INTERFAZ.1 sigue
activo por: “(…). Además, algunas de estas integraciones siguen requiriendo

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

10/173

que se pueda acceder al ***INTERFAZ.1 de la plataforma desde Internet. No
obstante, lo anterior, en los próximos meses (…)”.

4. Solicitar información sobre la posible comunicación a las personas afectadas
por la brecha.

Por parte de la empresa se afirma que “no se ha informado a las personas
físicas potencialmente afectadas por el ataque, sin perjuicio de que a futuro
desde esta entidad se tenga constancia de que la exfiltración sea, en su caso,
real; en cuyo supuesto, se realizará la preceptiva comunicación e información a
las personas físicas afectadas”.

Afirman, asimismo, (…) sin detectar compraventa o actividad alguna de los
datos supuestamente afectados.

SEXTO: Con fecha de 4 de agosto de 2023, al objeto de comprobar la veracidad de la
información publicada en el foro y la filtración de datos personales de clientes de la
empresa, el inspector establece comunicación con el usuario del foro que publicó el
mensaje con la muestra en el que afirmaba estar en posesión de esta base de datos, a
la que el usuario responde confirmando que la base de datos pertenece a la empresa,
que contiene 1.086.185 registros con datos de clientes con 837.606 números de
teléfonos móviles únicos, y aporta una nueva muestra que contiene hasta 7.000 datos
personales de 1.000 afectados o diferentes titulares organizados por NIF.

La referida muestra y las comunicaciones mantenidas entre ciber-atacante y el
inspector se unen como prueba al Informe de Actuaciones de Investigación de 1 de
diciembre de 2023, al que se hará referencia posteriormente.

SEPTIMO: Con fecha de 2 de noviembre de 2023, se une al expediente diligencia de
acceso por el inspector a la plataforma de la reclamada, en la que manifiesta que ha
accedido con dicha fecha a la URL aportada en las capturas de correos anteriores
(intercambiados con INCIBE) y que correspondía con la dirección de acceso a la
antigua plataforma basada en ***SOFTWARE.1 (y posible origen del ataque),
constatándose lo siguiente:

- Que el acceso a la URL ***URL.1 sigue estando disponible, accediéndose al
***SERVICIO.1 de la instalación del software ***SOFTWARE.1.

- Se constata que la versión utilizada de ***SOFTWARE.1 es la versión 1.6.1.24,
y contrastando el estado de esta versión en la propia web de este código abierto
se concluye que es una versión bastante obsoleta y fuera de soporte desde
junio de 2019, con múltiples vulnerabilidades (tanto en el ***SERVICIO.2 como
en el ***SERVICIO.1) que requieren como solución actualizar versiones
posteriores.

OCTAVO: Como consecuencia de estas actuaciones, con fecha de 1 de diciembre de
2023 se dicta Informe de Actuaciones Previas por parte del inspector encargado del
expediente de investigación, al que se une la documentación obtenida en las
diligencias practicadas por el instructor con fechas de 4 de agosto y 2 de noviembre a

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

11/173

las que se ha hecho referencia anteriormente, así como los requerimientos y
respuestas de la empresa y resto de documentos obrantes en el expediente.

En base a las actuaciones practicadas, el Informe emite las siguientes
CONCLUSIONES:

1.- En relación con el vector de ataque no se ha podido acreditar si fue a causa de
malware en una Workstation o a través de la propia aplicación software utilizada
para la antigua plataforma de tienda online de la empresa. No obstante, se ha
constatado que esta plataforma estaba basada en una versión obsoleta y
desactualizada del software ***SOFTWARE.1, con vulnerabilidades conocidas,
fuera de soporte desde el año 2019, y que disponía de la parte de administración
(***SERVICIO.1) con acceso público desde internet (aunque restringido por usuario
y contraseña).
2.- En relación con la detección y notificación de la brecha, desde la empresa se
tuvo conocimiento de la misma a raíz del aviso recibido vía mail por parte de
INCIBE el 5/4/23, alertando de la posible venta y filtración de datos de esta
organización a través de un foro en la dark web. Respecto a la cronología, queda
acreditado por los correos electrónicos aportados que el primer aviso de
brecha/ciberataque se produjo el 5/04/23, pero no se advirtió por la empresa hasta
que no se le hizo un segundo aviso el 12/04/23, contestando finalmente a INCIBE el
17/04/23, y notificando la brecha a esta AEPD el 19/04/23.
3.- Por parte de la empresa se niega que la filtración sea real, haciendo referencia a
que en el mensaje del foro no se menciona en ningún momento que la base de
datos pertenezca a esta organización y, por otro lado, que los 17 datos de muestra
que contiene la captura de pantalla publicada no son suficientes para poder
determinar que ha existido filtración real de la base de datos de la compañía. No
obstante, reconocen que estos registros de prueba coinciden con datos
almacenados en una de sus tablas de la base de datos.
4.- Por parte del inspector se ha contactado con el usuario que decía poner a la
venta la supuesta base de datos con objeto de contrastar la veracidad de la
información y verificar la existencia de filtración de datos personales, habiendo este
confirmado que la base de datos a la que hace referencia el mensaje
pertenece a la compañía la empresa y contiene 1086185 registros con datos de
clientes. El usuario aportó al inspector una nueva muestra que contiene 1000
registros (datos personales de 1.000 titulares diferentes), que son adicionales a los
17 publicados en la muestra, con idéntica estructura de campos y datos que la
captura publicada. En relación con esta estructura de campos la empresa había
confirmado que se corresponde con la tabla “***TABLA.1” de su base de datos, que
contiene los siguientes datos personales de 1.000 personas: “***TABLA.12,
postcode, city, other, phone,phone_mobile, vat_number, dni.
5.- En relación con las medidas preventivas implantadas antes de detectar la
brecha de seguridad para garantizar la seguridad de los tratamientos de datos
personales por la antigua plataforma de venta online, se ha constatado que:
- Los Logs de esta plataforma (basada en ***SOFTWARE.1) (…), por lo que no
fueron de utilidad para identificar y detectar el posible ataque, además por temas

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

12/173

de rendimiento (…), careciendo de medidas adecuadas para garantizar la
trazabilidad en el momento de suceder la brecha.
- Esta plataforma, pese a ser antigua y estar en proceso de migración, se
mantenía activa disponiendo de acceso directo desde internet únicamente a la
parte de ***SERVICIO.1 (afirman que esto era necesario por requisitos de
integración con la nueva plataforma implantada).
- De otro lado, ha quedado también acreditado que la antigua plataforma hacía
uso de la versión 1.6.1 de ***SOFTWARE.1, la cual se ha constatado que
pertenece a una versión desactualizada, fuera de soporte desde el año 2019 y
con múltiples vulnerabilidades críticas que afectaban tanto a ***SERVICIO.2 (…)
como al ***SERVICIO.1 (…).
- Por otra parte, se ha constatado que existían las siguientes medidas
preventivas implantadas:
 (…)
6.- Tras detectar la brecha de seguridad se adoptaron las siguientes medidas
reactivas para fortalecer la seguridad de la plataforma:
 (…)
7.- Se ha constatado que no se ha comunicado el incidente a las personas
afectadas por la brecha (o potencialmente afectadas). Por parte de la empresa se
afirma que no es necesaria esta comunicación alegando que no dan crédito a que
la filtración fuese real, teniendo únicamente la certeza de filtración de algunos
registros mostrados en la captura de pantalla publicada en el foro.
8.- En relación con los análisis de riesgos, ha quedado acreditado la existencia de
análisis documentado realizado en la fecha 10 de abril de 2022. La empresa
confirma que no constan análisis de riesgos con fecha anterior a la anteriormente
indicada, no obstante, ha quedado constado que la actividad de tratamiento
afectada por la brecha se inicia en el año 2013 (“Gestión de Clientes”).
NOVENO: Se obtiene el Informe Axesor de actividad mercantil de la empresa con
fecha de 1 de diciembre de 2023, que se une al expediente, que indica que la entidad
investigada posee el siguiente volumen de negocio según datos de Axesor a fecha de
2022:
a. (…)

DÉCIMO: Con fecha 1 de abril de 2024, la Directora de la Agencia Española de
Protección de Datos acordó iniciar procedimiento sancionador a la parte imputada, con
arreglo a lo dispuesto en los artículos 63 y 64 de la Ley 39/2015, de 1 de octubre, del
Procedimiento Administrativo Común de las Administraciones Públicas (en adelante,
LPACAP), por la presunta comisión de 4 infracciones administrativas tipificadas en el
Artículo 83.4 del RGPD y Artículo 83.5 del RGPD, sancionadas con la siguiente multa:

- Por la infracción del Artículo 5.1.f) del RGPD, una multa de 140.000 euros.
- Por la infracción del Artículo 32 del RGPD, una multa de 750.000 euros.
- Por la infracción del Artículo 33 del RGPD, una multa de 100.000 euros.
- Por la infracción del Artículo 34 del RGPD, una multa de 40.000 euros.

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

13/173

UNDÉCIMO: Notificado el citado acuerdo de inicio conforme a las normas establecidas
en la Ley 39/2015, de 1 de octubre, del Procedimiento Administrativo Común de las
Administraciones Públicas (en adelante, LPACAP), la parte imputada presentó solicitud
de ampliación de plazo y copia del expediente con fechas de 12, 15 y 17 de abril de
2024.

Con fecha de 18/04/2024 se dicta acuerdo de ampliación de plazo y remisión de copia
del expediente a CECOTEC. En dicho acuerdo se hace constar que la copia del
expediente se remitirá a la dirección postal de CECOTEC, en formato USB, a la vista
de que su tamaño excede del máximo que permite la notificación electrónica. La
notificación de dicho acuerdo de ampliación y copia y del escrito de las claves
necesarias para abrir el fichero adjunto se produce el 19/04/2024 por vía electrónica, si
bien la notificación de la copia del expediente por vía postal no se produce hasta el
30/04/24.

Con fecha de 25 de abril de 2024 -habiendo recibido la notificación de ampliación de
plazo y remisión de copia, pero no habiendo todavía recibido el expediente remitido
por vía postal-, CECOTEC presenta un primer escrito de alegaciones al acuerdo de
inicio (en adelante, Aleg AI #1).

Este primer escrito de alegaciones al acuerdo de inicio no adjunta documentación
alguna, y solicita el archivo del expediente y apertura de nuevo plazo de alegaciones,
manifestando, en síntesis, lo siguiente:

o PREVIA. VULNERACIÓN DEL PROCEDIMIENTO LEGALMENTE
ESTABLECIDO. INFRACCIÓN DEL ART. 24 CE.
Donde pone de manifiesto no haber recibido la copia del expediente alegando
que se produce indefensión al no disponer de la misma, constitutiva de nulidad
de pleno derecho por carencia absoluta del procedimiento. En virtud de ello,
mediante “OTROSIDIGO PRIMERO” formulan se abra plazo alegaciones
complementarias.

o PRIMERA.- VULNERACIÓN DEL PRINCIPIO NE BIS IN IDEM POR
SANCIONAR DOS VECES LA MISMA CONDUCTA RESPECTO A LAS
INFRACCIONES CONTEMPLADAS EN LOS ART. 5.1. F) Y ART. 32 DEL
RGPD.
Muestran su disconformidad respecto a la tipificación de los hechos realizada
por la AEPD en al ámbito del art. 5.1. f) y del art. 32 del RGPD, puesto que
implica sancionar dos veces la misma conducta, en base a lo siguiente:

o Conforme a las Directrices 04/2022 del European Data Protection Board,
o Comité Europeo de Protección de Datos (en adelante, “CEPD”) sobre
el cálculo de las multas bajo el RGPD, las disposiciones invocadas por la
AEPD en el presente expediente sancionador protegerían el mismo
interés jurídico, esto es, la seguridad adecuada de los datos personales,
siendo ilegal sancionar dos veces al infractor por la misma ofensa. En
este sentido, debemos citar la Sentencia ‘Austrian

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

14/173

Verwaltungsgerichtshof’, Ra 2018/02/1023, apartado 7.
Seguidamente, CECOTEC continúa señalando que: “En el presente
supuesto, el interés jurídico protegido (la confidencialidad de los datos)
es el mismo. La AEPD centra ambas infracciones en que no se han
adoptado medidas de seguridad técnicas y organizativas adecuadas, lo
que ha afectado a la capacidad de garantizar la confidencialidad”, lo que
implica vulnerar, según las Directrices del CEPD “el ‘principio de
consumo’ o que una infracción es un paso previo a la otra”
o Asimismo, existiría, a juicio de esta parte, una vulneración del principio
‘ne bis in idem’, conforme el criterio de la Audiencia Nacional (por todas:
Sentencia de la Audiencia Nacional de 23 de julio de 2021 (rec. 1/2017).
Se cita también el Auto del Tribunal Supremo (Contencioso), sec. 1ª, A
13-07-2023, rec. 3120/2023.
o Se alega la aplicación del Principio contenido en el artículo 29 de la Ley
40/2015, de 1 de octubre, de Régimen Jurídico del Sector Público (en
adelante, la “LRJSP”): 5. Cuando de la comisión de una infracción derive
necesariamente la comisión de otra u otras, se deberá imponer
únicamente la sanción correspondiente a la infracción más grave
cometida.

SEGUNDA. – AUSENCIA DE CULPABILIDAD O NEGLIGENCIA GRAVE
RESPECTO DE LAS INFRACCIONES CONTEMPLADAS EN LOS ART. 5.1. F)
Y ART. 32 DEL RGPD.

o “Es importante resaltar que la brecha de seguridad comunicada el 19
de abril del 2023 se produce en la plataforma de CECOTEC no por
falta de medidas de seguridad o que estas sean ineficaces sino por
el ataque de un tercero (hacker) que accede vulnerando de forma
irregular el acceso al sistema. Citamos, en este sentido, la Sentencia
de la Audiencia Nacional (Contencioso), sec. 1ª, S 10-11-2017, rec.
32/2016”.
o “Con relación a la plataforma de CECOTEC a la que, consta
acreditado, se accedió por un tercero ilegalmente, debemos resaltar
como se ha venido informando a la AEPD en fase de investigaciones
previas, que sí se disponía de medidas de seguridad técnicas y
organizativas tendentes a evitar el acceso de terceros no autorizados
como eran el disponer de “controles de acceso”.
o Con relación a dicha plataforma, informamos a la AEPD que se ha
deshabilitado y desconectado de internet.
o En la plataforma no se tratan por CECOTEC datos de categoría
especial o de mayor sensibilidad, ni tampoco de menores de edad.
o La existencia de vulnerabilidades que recoge el escrito relativo al
Acuerdo de Inicio, no supone necesariamente infracción de las
medidas de seguridad, habida cuenta que la seguridad total no existe
y que la obligación de seguridad de la información no es de
‘resultado’ sino una obligación ‘de medios’. En este sentido nuestro

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

15/173

Tribunal Supremo, en STS 188/2022 de 15 de febrero de 2022.
o Por otro lado, una comunicación no autorizada de datos personales o
un acceso no autorizado a tales datos por parte de terceros, no
bastan, por sí solos, para considerar que las medidas técnicas y
organizativas adoptadas por el responsable del tratamiento no eran
apropiadas con arreglo a los citados artículos 24 y 32. Sino que es
necesario que la administración acredite que existe cierto grado de
intencionalidad. Y es que en este sentido se ha pronunciado el
Tribunal de Justicia de la Unión Europea (en adelante, “TJUE”) a
través de su sentencia, de fecha 14 de diciembre de 2023, recaída
en el asunto C 340-2021. Y la jurisprudencia española, en sentencias
como la STC nº 76/1990 de 26 de abril, o la Sentencia de la Sala de
lo Contencioso-administrativo de la Audiencia Nacional, Sección 1ª,
de 23 de diciembre de 2013, Rec. 341/2012:
o Que no hay prueba- más allá de meros indicios- que permita
acreditar que se han visto afectados más de 6 usuarios reales.
o Se citan algunos de los supuestos de brechas de seguridad que
fueron archivados por esta Agencia, como la sufrida por Facebook en
2019, la de Decathlon, o el de Iberdrola en 2022.

TERCERA. - AUSENCIA DE PRUEBA DE QUE LAS MEDIDAS SON
INEFICACES.

Se señala que debe aplicarse la presunción de inocencia, y el “Principio In
dubio pro reo” al concurrir serias dudas de que las medidas adoptadas por
CECOTEC fueran ineficaces y que la base de datos objeto del ciberataque
fuera la de CECOTEC. Dado que la administración está aplicando una
responsabilidad objetiva que no existe, puesto que el acuerdo de inicio se basa
en indicios como el número de usuarios de la plataforma y a la vista de la
prueba practicada, existen dudas razonables.

CUARTA. - INEXISTENCIA DE LA INFRACCIÓN DEL ART. 33 RGPD EN
CUANTO A LA NOTIFICACIÓN FUERA DE PLAZO DE 72H.

o “El email remitido a CECOTEC por INCIBE el 13 abril de 2023 indica
que no puede determinar si se trata de información verídica y si ha sido
expuesta en otras filtraciones. La tabla con información es sólo de
dirección postal, número teléfono móvil y número de DNI. No estaban
afectados nombres y apellidos como se manifiesta en el acuerdo de
inicio del procedimiento sancionador”
o Y esta situación de incertidumbre se prolonga en el tiempo de forma
que, con los datos que se tenían tanto por INCIBE como por CECOTEC
al tiempo de brecha (abril 2023) no existía la obligación verdadera de
notificar la brecha, pues solo había certeza de 6 personas reales
afectadas, lo que conforme a la guía de la AEPD no implicaba
obligación de notificación, y aun así, por CECOTEC se decidió
proactivamente notificar.
o Que no es obligatorio notificar todas las brechas de datos personales,

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

16/173

dado que el RGPD prevé una excepción a esta obligación cuando el
responsable pueda garantizar que es improbable que la brecha de
datos personales entrañe un riesgo. Por ello, teniendo en consideración
la tipología de datos afectada, ya mencionada, en la que no había ni
datos identificativos de nombre y apellidos y resultando afectados,
inicialmente, sólo 6 personas reales, hacían improbable la existencia de
riesgo. En este sentido conviene traer el criterio del antiguo Grupo de
Trabajo del Artículo 29 que en las Directrices WP250, determina cuando
sería probable que entrañe un riesgo.
o El cómputo del día ‘a quo’ que ha tenido en cuenta la AEPD para
calcular el inicio del término de las 72 horas, esto es, el 17/04/2023 es
totalmente arbitrario, puesto que en aquel momento, en realidad,
CECOTEC no estaba en disposición o tenía un ‘conocimiento’ real de
que se hubiera producido una violación de datos.

QUINTA. - INEXISTENCIA DE LA INFRACCIÓN DEL ART 34 RGPD.
NOTIFICACIÓN A LOS INTERESADOS.

o No existe la infracción dado que no se ha acreditado que la brecha de
seguridad sufrida por CECOTEC haya supuesto un “alto riesgo” para los
derechos y libertades de los interesados con la consecuente obligación de
notificar a los mismos más allá de la valoración subjetiva llevada a cabo por el
instructor.

o CECOTEC inició las comprobaciones oportunas desde el momento inicial que
se tuvo conocimiento del email del INCIBE y se contactó con ellos
telefónicamente, y aunque inicialmente tuvo dudas acerca de la certeza de la
brecha pero ésta fue finalmente notificada a la Autoridad de Control conforme
fue obteniendo información al respecto.
o En este marco, se llevó a cabo internamente una valoración sobre el “alto
riesgo” en base a la información objetiva que disponía al tiempo de conocer la
brecha en base a los factores indicados en Directrices 9/2022 sobre la
notificación de violaciones de datos personales en virtud del RGPD de fecha
28 de marzo de 2023.
-Respecto a la naturaleza, la sensibilidad y el volumen de los datos
personales: Se trataba datos de contacto no completos ni de categoría
especial.
-Respecto al volumen de datos: Acreditados sólo 6 datos de personas
reales.
-Respecto a la facilidad de la identificación de los individuos: Era
compleja habida cuenta que no figuraban los nombres y apellidos de los
interesados, ni hay documentación asociada.
-Respecto al tipo de violación: Afectó a la confidencialidad de los datos
por un tercero no autorizado, pero no a otras esferas como la
disponibilidad e integridad.
- Respecto a la gravedad de las consecuencias para las personas: Se
consideró que no resultaba grave dado que no son datos de categoría

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

17/173

especial, la suplantación de identidad no es automática ni sencilla al no
constar nombre y apellidos de los afectados, ni por otro lado, consta
acreditada.
-Respecto a las características del individuo: No se trataba de sujetos
vulnerables ni de menores de edad.

o Tras dicha evaluación interna y acorde al resultado de la herramienta
COMUNICA BRECHA facilitada por la propia AEPD, CECOTEC no estimó
necesario comunicar la brecha.
o Se pretende también evitar la “fatiga innecesaria de las notificaciones”, a la
que se refieren las mencionadas Directrices 9/2022 sobre la notificación de
violaciones de datos personales, que señalan que el umbral para comunicar la
brecha a los particulares es más elevado que para notificar a las autoridades
de supervisión.
o Por último, la AEPD en función de las competencias correctivas que tiene
atribuidas por el artículo 34.4 del RGPD, debería haber indicado a CECOTEC
en la fase de actuaciones previas o al trasladarle el acuerdo de inicio del
presente procedimiento que procediese a la notificación de la brecha a los
interesados, si consideraba que era preceptivo. Y se indica que: “no alcanza a
entender esta parte que esta orden se haya instruido en otros procedimientos
seguidos ante la AEPD – tal y como se desprende, entre otras, de la
resolución, de fecha 17 de febrero de 2022, recaída en el PS Nº E/06660/2021
o en los expedientes de actuaciones previas de investigación E/06214/2020, y
E/06177/2020 y en el presente procedimiento se haya ignorado, íntegramente,
la posibilidad de ofrecer dicha posibilidad previa CECOTEC, optando
directamente por la apertura del presente Acuerdo de Inicio”.

SEXTA. - FALTA DE PROPORCIONALIDAD EN LA IMPOSICIÓN DE LAS
SANCIONES Y AUSENCIA DE GRADUACIÓN.

o Con carácter previo, se informa a la AEPD que la plataforma
‘***SOFTWARE.1’, está totalmente deshabilitada, cesando el tratamiento de
datos.

o No se contemplan circunstancias atenuantes que concurren: como que
CECOTEC no ha obtenido beneficio alguno; no consta reiteración de
conducta, antecedentes o intencionalidad de causar daño por parte de
CECOTEC; asimismo, no están acreditados daños y perjuicios ni existe
informe sobre hipotéticos daños, así como tampoco existe ninguna
reclamación por parte de algún usuario, la brecha no afecta datos de categoría
especial ni datos de menores de edad. Y no se han valorado las medidas
correctivas adoptadas por CECOTEC sin haber sido solicitadas o requeridas
por la AEPD, conforme artículo 83, apartado 2, letra i).
o En general existe una falta de proporcionalidad manifiesta al fijar la cuantía de
la sanción: que el límite cuantitativo máximo sea tan amplio no justifica esta
cantidad, que debe ajustarse a la capacidad económica y se considera

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

18/173

desproporcionada según la jurisprudencia y artículo 29 de la LRJSP.- Se
alegan sentencias varias como la STS de 2 de junio de 2003, Tribunal
Supremo en su Sentencia de 29 de julio de 2014 (Sala de lo Contencioso-
Administrativo, Sección 1ª).
o Respecto de cada infracción se considera que la multa impuesta es
desproporcionada por no haberse considerado las circunstancias siguientes:
a. Respecto a las sanciones impuestas de 140.000€ por la infracción
del artículo 5.1.f) del RGPD y 750.000€ por la infracción del artículo
32 del RGPD resultan totalmente desproporcionadas habida cuenta
la ausencia de prueba de que se haya materializado daño alguno y
de que no existe queja o reclamación de ningún usuario, unido a
que los datos accedidos de los 6 usuarios reales, no permitirían
actualmente una suplantación de identidad al no disponerse del
completo DNI/NIF y sólo del número y letra, ni tampoco de los
nombres y apellidos. Habiéndose adoptado medidas correctivas sin
ser requeridas por la AEPD procedería su graduación y atenuación.
b. Respecto a la sanción impuesta de 100.000€ por la infracción del
artículo 33 del RGPD, en caso de apreciarse su concurrencia, la
cuantía deviene completamente desproporcionada habida cuenta
que la brecha se comunicó voluntariamente por CECOTEC, no hay
reclamación alguna de usuarios y que el retraso respecto a esas 72
horas es tan sólo de sólo 3 días porque no se conocía el total
alcance de la violación, habiendo, asimismo, días festivos dentro del
citado plazo como se acreditó.
c. Respecto a la sanción impuesta de 40.000€ por la infracción del
artículo 34 del RGPD, indicar que en caso de apreciarse su
concurrencia, la cuantía deviene completamente desproporcionada
igualmente habida cuenta que, sólo hay prueba de 6 interesados
afectados reales, sus datos no son sensibles o de categoría especial
y no permitirían actualmente una suplantación de identidad al no
disponerse del completo DNI/NIF y sólo del número y letra, ni
tampoco de los nombres y apellidos.

- Se deben considerar las medidas correctivas que fueron adoptadas con
posterioridad y que han sido comunicadas a la AEPD, enumerando las mismas
y haciendo referencia a las evidencias de su adopción que se han aportado en
el procedimiento.
- Por último, se informa que la Compañía sigue mejorando, estando inmersa
actualmente en una auditoría de cumplimiento normativo RGPD y en la
actualización de los análisis de riesgos, realización de EIPD y verificación de
medidas de seguridad. Y que se muestra dispuesta a aceptar cualquier
propuesta de mejora.

DUODÉCIMO: Con fecha de 30/04/24 se notifica a CECOTEC acuerdo de inicio del
procedimiento en el que -contestando a la solicitud formulada mediante OTROSIDIGO
PRIMERO del escrito de alegaciones presentado así como a la alegación previa
formulada- se aclara que es posible la presentación de alegaciones complementarias
hasta que se dicte Propuesta de Resolución, y que el plazo de presentación de
alegaciones al acuerdo de inicio finalizará una vez transcurra el plazo otorgado que fue

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

19/173

objeto de ampliación (cuyo cómputo se ha reanudado al notificarse en esa misma
fecha 30/04/24 la copia del expediente que fue remitida a su domicilio postal).

Como consecuencia de ello, CECOTEC presenta un segundo escrito de alegaciones
al acuerdo de inicio con fecha de 8/05/2024 (en adelante, Aleg AI #2), en el que
“habiendo tenido acceso al expediente” formula, en síntesis 4 alegaciones
complementarias a las realizadas:

PRIMERA. - AUSENCIA DE GRADUACIÓN.

o Consta en la página 222 del expediente administrativo relativo a ‘EVIDENCIAS
SIGNIFICATIVAS PARA LA GRADUACIÓN’ que por el Inspector sólo se ha
tenido en cuenta como criterio para la graduación la cifra de volumen de
negocios de CECOTEC para el ejercicio 2022.
o Si bien, en el acuerdo de inicio se mencionan sucintamente la gravedad,
naturaleza y duración de cada una de las infracciones, a juicio de la AEPD,
pero no se ha contemplado por la Agencia ningún criterio de graduación de las
sanciones tendentes a su atenuación, como ya se señaló en su primer escrito
de alegaciones.
Se añade que: “Conforme a las Directrices 04/2022 del ‘European Data
Protection Board’ sobre el cálculo de las multas, siguiendo la estructura del
RGPD, después de haber evaluado la naturaleza, gravedad y duración de la
infracción, así como su carácter intencional o negligente de la infracción que,
es única y exclusivamente a lo que en este caso se ha ceñido la AEPD, la
autoridad de control debe tener en cuenta los factores agravantes y atenuantes
restantes enumerados en el artículo 83, apartado 2, del RGPD así como, las
categorías de datos personales afectados. Y sin embargo, repite CECOTEC
que la AEPD no ha valorado la escasa relevancia de las categorías de datos
personales afectados, ni que no hay reincidencia en infracciones por parte de
CECOTEC, y tampoco se ha tenido en cuenta el grado de cooperación con la
autoridad de control para mitigar riesgos.
Por otra parte, añaden que el artículo 76. 2 de la “LOPDGDD”) señala que se
deben tener en consideración dos circunstancias que no concurren en este
caso, para atenuar o agravar la sanción que son: c) Los beneficios obtenidos
como consecuencia de la comisión de la infracción. f) La afectación a los
derechos de los menores. Por tanto, al no concurrir deben ser considerados
para atenuar.

SEGUNDA. – RESPECTO AL ATAQUE DE UN TERCERO (HACKER) Y LA
COMUNICACIÓN MANTENIDA POR EL INSPECTOR.

 Se insiste en el carácter de víctima de un ataque informático de
CECOTEC, así como que no constan acreditados tampoco daños y
perjuicios y que no queda desvirtuada la presunción de inocencia de
CECOTEC.
 En relación con lo que se señala en el HECHO SEXTO (folio 12) referido al
contacto que el inspector hizo constar en su Informe API relativo a que

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

20/173

había mantenido con el ciber atacante el día 4 de agosto de 2023, en la
que el usuario responde confirmando que la base de datos pertenece a la
empresa, y que contiene 1.086.185 registros, adjuntándose una nueva
muestra; CECOTEC hace constar lo siguiente:
(i) Dado que en el folio 203 se observa que consta el dato del
correo electrónico del que podría ser un posible autor
identificable, por lo que se informa que se va a interponer la
correspondiente denuncia ante la Policía Nacional, cuya copia
se adjuntará para su unión al expediente administrativo.
(ii) Así mismo, señala que no consta que esta AEPD le haya
proporcionado dicho dato en ningún requerimiento, lo que
hubiera sido útil y no hubiera perjudicado a la investigación; y
que INCIBE tampoco se lo hizo constar, señalando que no podía
determinar si se trataba de información verídica.

Al igual que en el primer escrito de alegaciones presentado, no se adjunta
ningún documento al referido escrito de alegaciones complementarias.

Posteriormente, tal y como se había anunciado, se presenta con fecha de
13/5/24 un nuevo escrito de alegaciones cuyo objeto es aportar copia de la
denuncia presentada por CECOTEC por ciberdelincuencia ante la Policía
Nacional, a la que se hacía referencia en su escrito de alegaciones
complementarias. Que se acompaña como DOCUMENTO 1.

DÉCIMO TERCERO: Con fecha de 3/06/2024, se dicta acuerdo de apertura de
periodo de prueba del procedimiento por la inspectora.

En dicho acuerdo de prueba, además de darse por reproducido el expediente, así
como expedir y unir las dos diligencias que fueron expedidas por la instructora en la
misma fecha - sobre comprobación de no disponibilidad de acceso a la plataforma
***SOFTWARE.1 y para unir una copia del esquema base de datos publicado por el
desarrollador de la misma para la versión 1.6. de la plataforma ***SOFTWARE.1-, se
requiere CECOTEC la siguiente documentación/información:

- Al objeto de acreditar que, como manifiesta CECOTEC en sus alegaciones,
los campos de la muestra facilitada por el ciber-atacante al inspector con
fecha de 4 de agosto de 2023 no coinciden con los de la denominada tabla
“access” de la plataforma ***SOFTWARE.1 en el momento del ciber-
ataque, se requiere aporte dicha tabla de access.

Se especifica que deberá aportarse el contenido de la citada tabla access
con la totalidad de registros reflejados en la misma a fecha de 5 de abril de
2023; así como la posteriormente obtenida por el departamento de
ciberseguridad entre el 12 y 14 de abril de 2023 al objeto de comprobar la
veracidad del ciberataque.

Se hace constar que dicha tabla deberá presentarse, preferentemente en
formato electrónico, pudiendo aportarse en un soporte físico (CD o USB) en
el caso de no ser susceptible de conversión en formato electrónico, por

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

21/173

exceder en tamaño al máximo permitido en el sistema Notific@.

- Visto el Anexo 2 del escrito de 30 de agosto de 2023 denominado
“estructura.presta.png”, se requiere aporte de nuevo el mismo en un
formato y resolución adecuados para permitir que sus datos sean
claramente legibles.

Deberá informar expresamente si el citado Anexo 2 se corresponde con la
estructura de la base de datos de la plataforma personalizada por
CECOTEC a fecha del ciber-ataque (5 de abril de 2023), o en las fechas
posteriores de comprobación del ciber-ataque por CECOTEC.

Y en cualquier caso, se requiere concrete durante qué fechas se utilizó por
CECOTEC esta estructura del Anexo 2 como sistema de gestión de
contenido de la plataforma.

- Aporte documentación justificativa de los cambios producidos en la
citada estructura de la base de datos de la plataforma desde el 5 de abril
de 2023 hasta la actualidad.

- Habiéndose negado que el número de registros de la plataforma coincida
con el señalado con el ciber-atacante, se requiere aporte documentación
justificativa que acredite el número de registros contenidos en la
plataforma a fecha del ciberataque (o comprobación por CECOTEC del
mismo), distinguiendo lo siguiente:

- Por una parte, documento que acredite el número total de titulares de
datos personales contenidos en la plataforma, desglosados por
“consumers, supliers, y manufacturers”.

- Por otra parte, documento que acredite el número total de titulares de
datos personales correspondientes a personas físicas.

Con fecha de 4/07/24 CECOTEC contesta a este primer acuerdo de prueba,
solicitando copia de las dos Diligencias expedidas con fecha de 3 de junio de 2024,
aclaración respecto al alcance de la “documentación justificativa de los cambios
sufridos por la plataforma desde el 5-4-23 hasta la actualidad”, y aportando 5
documentos:

- Como Documento Nº.1 se facilita la tabla “access” que se entiende fue
solicitada por la instructora que contiene 2.047 accesos de 18 perfiles.
- Documento Nº.2 se correspondiente con la estructura genérica de la base
de datos de ***SOFTWARE.1.
- Se acompaña como Documento Nº.3 la estructura personalizada que
utilizaba CECOTEC en la plataforma, incluyéndose como Documento Nº.4
una breve explicación de sus funcionalidades para un mejor desarrollo y
seguimiento de la actividad de la entidad. Y se hace constar que la
estructura que consta en el documento 4 “fue utilizada por CECOTEC
desde junio de 2016 hasta la fecha de cierre de la plataforma”.
- Se acompaña como Documento Nº.5 captura de pantalla en la que se

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

22/173

puede comprobar el número total de titulares de datos personales
contenidos en la plataforma a fecha del ciberataque filtrados por
consumers, suppliers y manufacturers. Se hace constar que: “El número
que se observa es el total de los usuarios, correspondiendo los datos de
contacto a personas físicas, si bien algunos de ellos se refieren a datos de
personas físicas que no actúan en calidad de particulares, sino, en
representación de una empresa o en el ejercicio de su actividad
profesional.”

DÉCIMO QUINTO: A la vista de la documentación aportada por CECOTEC hasta el
momento, y las peticiones formuladas por la misma, con fecha de 27/08/24 se dicta
acuerdo ampliatorio de prueba por la instructora.

Dicho acuerdo de ampliación de prueba tiene por objeto entregar copia de las
diligencias solicitadas por la misma, aclarar la duda planteada, y requerir la aportación
por CECOTEC de los siguientes documentos:

- Aporte el contenido íntegro de la tabla que aparece en la estructura
personalizada de ***SOFTWARE.1 aportada como Documento 3, con el
nombre de “***TABLA.1” (en adelante, tabla ***TABLA.1), tal y como se
hallaba reflejada a la fecha del anuncio del ciberatacante (5 abril 2023), o a la
fecha en que se realizaron las comprobaciones por su departamento de
ciberseguridad (12 y 13 de abril de 2023). Toda vez que la tabla de access que
se aporta como Documento 1, sobre tipos de perfiles de empleados de la
entidad, no se corresponde con la tabla de access que fue solicitada por la
instructora.

- Habiendo señalado en su escrito de contestación al acuerdo de prueba que la
estructura del documento 3 era la que estaba vigente a la fecha de cierre de la
plataforma (enero de 2021), se le requiere para que aclare si esta estructura
permaneció invariable hasta el 5 de abril de 2023, fecha de publicación del
presunto ciberataque. Y en caso de ser diferente, aporte la captura de la
nueva estructura.

Con fechas de 20 y 24 de septiembre de 2024, CECOTEC contesta al acuerdo de
ampliación de prueba (en adelante, [ContPrueba#2]), aportando un fichero Excel
cifrado con clave, donde según la imputada se contiene la mencionada tabla
***TABLA.1 contenida en su plataforma, señalando que: ““De acuerdo con la
información facilitada por el departamento de IT, conviene indicar que el contenido de
la tabla “***TABLA.1” que se aporta en el presente escrito es el mismo que a fecha de
cierre de la plataforma en diciembre de 2022. En este sentido, se confirma que este
contenido es el mismo que a fecha del anuncio por el ciberatacante (5/4/2023) y que a
fecha en la que se hicieron las comprobaciones (12/04/2023 y 13/04/2023)”.

DÉCIMO SEXTO: Con fecha de 6 de febrero de 2025, se procede a cotejar y comparar
el contenido de la segunda muestra proporcionada por el actor malicioso, de 1000
registros, con los datos contenidos en la tabla ***TABLA.1 aportada por CECOTEC, a
los efectos de comprobar las coincidencias y comprobar si el ciber-atacante tuvo
acceso a estos registros, así como para conocer a cuántas personas afectó, en su
caso.

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

23/173

Como resultado de estas actuaciones se expide una diligencia con fecha de 14 de
febrero de 2025, que se une al presente procedimiento, en la que se adjunta el listado
Excel de coincidencias organizadas por DNI, tras realizar una validación de DNIs. Y se
hace constar el resumen del resultado obtenido:

1. Análisis registros y datos personales de la TABLA ***TABLA.1 DE CECOTEC.

Haciendo constar el número total de registros, campos, y datos personales
contenidos en la misma.

2. Análisis datos personales y titulares de la MUESTRA 2 proporcionada por el
actor malicioso.

Donde se señala que los datos personales contenidos en la muestra de 1000
registros corresponden a un total de 933 personas físicas que aparecen con un
DNI válido, 50 personas físicas cuyo número de DNI es inválido o incorrecto, y
17 corresponden con empresas. Y se detallan los campos y datos personales
contenidos en dicha muestra.

3.- Análisis comparativo entre la muestra 2 y la tabla ***TABLA.1.

Donde se señala que: “La muestra 2 contiene 1000 registros, todos los cuales
se encuentran incluidos en la tabla ***TABLA.1. Se observa que coinciden
hasta los códigos identificadores que se generan automáticamente por la base
de datos, que el actor malicioso no podría deducir si no hubiera accedido a la
misma. (id ***TABLA.1, id country, id costumer, id supplier…etc).
Las 933 personas físicas incluidas con DNI verificado se encuentran incluidas
en la tabla ***TABLA.1 de CECOTEC e incluyen los datos que se han
señalado”.

DÉCIMO SÉPTIMO: Con fecha de 7 de marzo de 2025, se notificó a CECOTEC la
Propuesta de resolución de expediente sancionador de 26 de febrero de 2025, por la
que a la luz de la prueba practicada, se consideraba probado que la citada tabla
“***TABLA.1” contenida en la plataforma ***SOFTWARE.1 de CECOTEC había sido
objeto del ciberataque publicado en la dark web el 5-4-23, y que como consecuencia
de éste se había constatado que el actor malicioso había accedido, al menos, a los
datos personales contenidos en la misma correspondientes a 933 personas físicas, en
lugar de las 6 personas físicas cuya brecha fue detectada y notificada por la empresa.
Y como consecuencia, de ello, se respondía a las alegaciones formuladas contra el
acuerdo de inicio y se acordaba elevar el importe de dos de las multas inicialmente
fijadas en el acuerdo de inicio relacionadas con el número de afectados (Art 5.1.f) y 34
del RGPD). Y como consecuencia de ello, proponer la imposición de las siguientes
multas administrativas por la comisión de las siguientes infracciones:

- Por la infracción del artículo 5.1.f) RGPD, multa de 300.000€.
- Por la infracción del artículo 32 RGPD, multa de 750.000€.
- Por la infracción del artículo 33 RGPD, multa de 100.000€.
- Por la infracción del artículo 34 RGPD, multa de 100.000€.

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

24/173

Se adjunta con esta Propuesta copia de la Diligencia expedida el 14 de febrero de
2025, por ser el único documento unido al expediente que no se hallaba en poder de la
parte imputada.

DÉCIMO OCTAVO: Con fecha de 18 de marzo de 2025, CECOTEC presenta escrito
de alegaciones frente a la propuesta de resolución del procedimiento, que no adjunta
documentación alguna, señalando en un total de seis alegaciones (previa, y primera a
quinta), que se enuncian a continuación, siendo objeto de desarrollo y contestación en
el Fundamento de Derecho V de esta Resolución:

PREVIA.- Se reiteran en las alegaciones y fundamentos ya efectuados en los
escritos previos.

PRIMERA.– Hechos controvertidos. Como introductorio de las alegaciones
segunda a cuarta se mencionan los que fueron declarados como 3 hechos
controvertidos en la propuesta de resolución.

SEGUNDA: Del número de registros finalmente afectados.

2.A. Principio de culpabilidad y proporcionalidad con relación a las infracciones
contempladas en los Arts. 5.1.f) y 32 del Reglamento General de Protección de
Datos (RGPD). Inexistencia de nexo de causalidad.
2.B) Ausencia de graduación de la sanción.

TERCERA. –De la eficacia de las medidas de seguridad técnicas y
organizativas con las que contaba la Compañía.

3.A. Infracción del principio de tipicidad y ausencia de responsabilidad del
artículo 5.1 f) RGPD.

3.B. Infracción del artículo 32 RGPD, ausencia de culpabilidad y falta de
Proporcionalidad.

CUARTA. – Disconformidad con el dies a quo respecto a la notificación de la
brecha. Falta de proporcionalidad de la infracción del artículo 33 del RGPD.

4.A) Dies ad quo. Señala que es el día 17-4-23, y que subsidiariamente,
debería ser el 14-4-24.
4.B) Falta de proporcionalidad infracción artículo 33 del RGPD.

QUINTA.– Ausencia de necesidad de notificación de los interesados al tiempo
de la brecha. Infracción artículo 34 del RGPD.

De las actuaciones practicadas en el presente procedimiento y de la documentación
obrante en el expediente, han quedado acreditados los siguientes:

HECHOS PROBADOS

PRIMERO: Consta acreditado que el día 5-4-23, el Instituto Nacional de
Ciberseguridad Español (INCIBE) detectó una publicación en un foro de la dark web

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

25/173

en la que se anuncia la venta de una base de datos de una empresa española cuyos
datos se correspondían con los publicados sobre CECOTEC en infoempresa.com,
remitiendo a la misma un correo electrónico el mismo día 5-4-23 a las 14:53 horas con
el asunto “alerta de incidente de ciberseguridad”, cuyo contenido era el siguiente:

“El pasado día 5 de abril se ha detectado una publicación en el foro sinister.ly donde el
actor malicioso que opera bajo el alias de "***USUARIO.1" indica estar en posesión de
base de datos con aproximadamente 1 millón de registros de clientes de una
reconocida empresa española cuya denominación social no menciona. Sin embargo,
específica que se trata de una empresa fundada en 1995, especializada en la venta de
artículos de hogar y electrodomésticos, con un patrimonio neto de 25.080.126 euros,
cuya facturación anual alcanzaría 106.423.475 euros y cuyos beneficios ascenderían a
16.733.555 euros.

Se ha podido comprobar que la entidad afectada podría ser su empresa (CECOTEC
INNOVACIONES SL) dada la coincidencia con los datos de facturación y de fundación
que indica el actor malicioso. (https://www.infoempresa.com/es—
es/es/empresa/cecotec innovaciones—sl)

Para acceder a la base de datos completa es preciso ponerse en contacto con el actor
malicioso, a través de correo electrónico o mensajería instantánea (Telegram o ICQ
Asimismo, ***USUARIO.1 proporciona un enlace para acceder a una muestra de los
datos en venta. La muestra es una imagen en la que aparece una tabla con
información carácter personal de un total de 17 ciudadanos, algunos españoles,
presuntos clientes de la empresa afectada. Aunque en algunas columnas de la tabla la
información está enmascarada, los siguientes datos aparecen en claro: - —Dirección
postal (ciudad, país y código postal) - -Número de teléfono móvil - -Número de
documento nacional de identidad Hasta el momento no se han publicado comentarios
0 respuestas que permiten determinar si se trata de información verídica y si ha sido
expuesta en otras filtraciones.

Fuentes: (…)

Lo ponemos en su conocimiento por si no tuviesen constancia o pudiesen comprobar si
realmente se hubiese producido la filtración y tomar las medidas oportunas.

De conformidad con el RGPD, si se trata de información real y ha afectado a la
confidencialidad, disponibilidad o integridad de datos personales, el responsable del
tratamiento deberá evaluar si existe riesgo (…)”.

A través de la fuente puesta de manifestó en dicho correo, se podía acceder al citado
anuncio de venta de la base de datos, que adjuntaba una muestra de 17 registros de
la base de datos, y tenía el siguiente contenido, que ha sido reflejado en el correo
electrónico de 14 de abril de 2023 aportado como Anexo 7 del escrito Resp#1 de
CECOTEC:

“(…)
Message: I have a Spain E-commerce base.
It is a renowed spanish company that was founded in 1995 The company
specialized in household articles and small electrical appliances.
It has a 25.080.126 euro Net Worth: Turnover 106.423.475 euro; Earnings
17.733.555 euro Year end results, and average daily purchase value of USS
749.795.
I have almost 1 M entries of costumers, manufacturers and suppliers phone leads.

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

26/173

Check the picture here: https….”

(Traducción al español por esta Agencia)

“(…)
Mensaje: Tengo una base de comercio electrónico en España.
Es una renombrada empresa española que fue fundada en 1995. La empresa
especializada en artículos para el hogar y pequeños electrodomésticos.
Tiene un valor neto de 25.080.126 euros; Volumen de negocios 106.423.475
euros; Ganancias 17.733.555 euros Resultados finales del año, y valor medio
diario de compra de USS 749.795.
Tengo casi 1 M entradas de clientes, fabricantes y proveedores con número de
teléfono.
Echa un vistazo a la imagen aquí: https....”

SEGUNDO: Con fecha 19 de abril de 2024 a las 18:19 horas, CECOTEC notifica a
esta Agencia que se ha detectado una brecha de confidencialidad de datos
personales que afecta a 6 personas reales, aportando un informe de su DPD en el
que consta señalado que se ha verificado que la muestra inicial de 17 registros
contenida en el anuncio del actor malicioso coincide con los contenidos en una tabla
denominada “***TABLA.1” de una antigua plataforma de tienda online denominada
“***SOFTWARE.1” que viene utilizándose por CECOTEC para gestionar sus clientes
desde el año 2016, cuyo (…) ***SERVICIO.2 se cerró en enero de 2021, pero que
seguía activa en ***INTERFAZ.1. Se hace constar que no se considera necesario
comunicar la brecha producida a estos 6 afectados, por no concurrir una probabilidad
de que entrañe alto riesgo tras la valoración realizada.

Respecto al tratamiento de los datos personales realizado a través de la citada
plataforma de antigua tienda on line queda acreditado que:

- CECOTEC inició el tratamiento de los datos personales obtenidos de sus
clientes para gestionar la tienda online contenidos en la citada Plataforma
***SOFTWARE.1 de código abierto basada en servicios web en el año 2013
(según RAT aportado).
- No obstante, la empresa manifiesta que la plataforma ***SOFTWARE.1 no
comenzó a utilizarse hasta 2016, lo que no consta actualizado en el RAT
aportado al procedimiento. La empresa no aporta acreditación de este aspecto.
No obstante, se ha podido comprobar que es cierto que los datos personales
contenidos en la tabla “***TABLA.1” se refieren todos ellos a datos obtenidos
entre 2016 y 2021 por lo que se tiene por cierto este hecho a favor de la
empresa.

- En enero de 2021 el tratamiento fue modificado en los términos manifestados
en el escrito de Resp#1, que señala que “la plataforma fue sustituida por una
nueva tienda en línea sustituida internamente que adoptó tecnologías de
desarrollo web de código abierto más moderno cuya transición se completó en
enero de 2021”, pero: “a pesar del cierre de la plataforma original, se ha
mantenido un acceso limitado a la misma (***INTERFAZ.1) con el único fin de

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

27/173

poder atender solicitudes, necesidades y/o reclamaciones de clientes de la
empresa”.
- Consta que a fecha de la brecha (5-4-23) la plataforma se correspondía con la
versión 1.6 de ***SOFTWARE.1, cuya estructura básica fue personalizada por
CECOTEC, y aporta como Anexo 2, y se hallaba desactualizada, sin soporte, y
con acceso directo a internet (con código de usuario y contraseña) al citado
***INTERFAZ.1 o ***SERVICIO.1 (), señalando la Resp#2 de CECOTEC que:
“(…) La razón por la cual la plataforma todavía estaba accesible en Internet en
dicha fecha es todavía no se ha realizado la migración de las integraciones de la
antigua plataforma a la nueva. El ***INTERFAZ.1 sigue activo por: “la necesidad
de mantener integraciones activas con nuestra nueva tienda en línea. Estas
integraciones operan en modo lectura y son esenciales para el funcionamiento de
nuestro sistema por lo que actualizar la plataforma a una versión más reciente
podría generar inconvenientes en las mismas. Además, algunas de estas
integraciones siguen requiriendo que se pueda acceder al ***INTERFAZ.1 de la
plataforma desde Internet. No obstante, lo anterior, en los próximos meses se van
a realizar las gestiones técnicas oportunas para realizar la migración de todas las
integraciones de la plataforma y eliminar por completo la exposición de la
plataforma de Internet”.

- Por último, se ha acreditado mediante Diligencia de 3 de junio de 2024 que
CECOTEC ha procedido a la inhabilitación del acceso a internet de la
plataforma al que hace referencia el escrito de AlegAI#1 de 25-4-23. Sin
embargo, no se aporta acreditación alguna que justifique que han cesado la
totalidad de las operaciones de tratamiento de los datos personales realizados
a través de dicha plataforma, no constando acreditado que la reclamada haya
procedido ni al cese del tratamiento, ni al bloqueo y/o supresión de los datos
personales contenidos en la misma.

TERCERO: CECOTEC ha reconocido que la base de datos que como consecuencia
del ciberataque al que se refieren los hechos anteriores, se ha producido una brecha
de confidencialidad de los datos personales contenidos en una de las tablas de
esta plataforma ***SOFTWARE.1 denominada “***TABLA.1”, cuyo contenido
íntegro ha sido aportado por CECOTEC el 24-9-24 (…), toda vez que se ha
comprobado que el actor malicioso ha podido acceder sin autorización a parte de los
datos personales contenidos en la misma, y los ha puesto en venta en un foro de la
dark web con fecha de 5-4-23, publicando una muestra de 17 registros que se
corresponden íntegramente con los contenidos en la citada tabla, de los cuales 6
corresponden a personas físicas y el resto son datos de prueba.

Ello se reconoce por la reclamada en los siguientes escritos:

- A la notificación de la brecha de 19 de abril de 2023, se adjunta un informe del
DPD, en el que se señala que en la plataforma ***SOFTWARE.1: “Se almacena
una variedad de datos personales que eran esenciales para el funcionamiento y la
gestión de la tienda en línea, sin embargo, en el contexto del posible incidente reportado
por el INCIBE, los datos supuestamente afectados se relacionan con la tabla ***TABLA.1
dentro de la base de datos”.

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

28/173

- En el primer Informe detallado del incidente aportado como Anexo 3 de su escrito
de 30 de agosto de 2023 (Resp#1), CECOTEC reconoce que coinciden los 17
registros de la muestra contenida en el anuncio pero que no se da crédito a que
lo expuesto por “***USUARIO.1 sea viable o, en su caso, veraz”.

- Como Anexo 7 del primer escrito de respuesta al requerimiento de investigación
(Resp#1), se acompaña un correo electrónico que el Director de Ciberseguridad
de CECOTEC remitió a la DPD de CECOTEC el 14 de abril de 2023, en el que
tras realizar las pertinentes averiguaciones al objeto de comprobar la
verosimilitud del ataque basándose en la muestra inicial que el actor malicioso
había publicado en su anuncio de 17 registros, señala lo siguiente (el subrayado
es nuestro):

“Tras realizar el análisis, se vió que los registros de la tabla coinciden con los
de la tienda antigua de cecotec (…) que se cerró en 2021. No obstante,
actualmente dicha página la usan algunas personas a modo de consulta. Tras
investigar junto al departamento de ecommerce e infraestructura, pudimos ver
los registros que tiene el atacante de la base de datos son desde el 2016 al
2020, esto suponiendo que tenga el 1.000.000 de registros que dice tener, ya
que solamente muestra 18 registros en la imagen que adjunta. En dicha tabla
se encuentran datos de usuario como direcciones, código postal, ciudad del
usuario, teléfono, dni .“

- Posteriormente, el primer escrito de alegaciones presentado frente al acuerdo de
inicio (Aleg AI#1) se reconoce que la citada plataforma de CECOTEC “fue víctima
de un ciberataque”, y por tanto, que el origen de la brecha fue el acceso ilegítimo
del actor malicioso que publicó el anuncio, al realizar siguientes afirmaciones:

o “Es importante resaltar que la brecha de seguridad comunicada el 19 de abril
del 2023 se produce en la plataforma de CECOTEC no por falta de medidas de
seguridad o que estas sean ineficaces sino por el ataque de un tercero (hacker)
que accede vulnerando de forma irregular el acceso al sistema”(…)
o “Con relación a la plataforma de CECOTEC a la que, consta acreditado, se
accedió por un tercero ilegalmente, debemos resaltar como se ha venido
informando a la AEPD en fase de investigaciones previas, que sí se disponía de
medidas de seguridad técnicas y organizativas tendentes a evitar el acceso de
terceros no autorizados como eran el disponer de “controles de acceso”.
o “No se ha acreditado que la brecha de seguridad sufrida por CECOTEC haya
supuesto un “alto riesgo”(…)” inicialmente tuvo dudas acerca de la certeza de
la brecha pero ésta fue finalmente notificada a la Autoridad de Control
conforme fue obteniendo información al respecto”.

- Ello se confirma en el segundo escrito de alegaciones presentado el 8 de mayo
de 2024 (AlegAI#2) al recibir la copia del expediente, se hace constar: “(…) Lo
empresa ha sido víctima de un ciberataque en sus sistemas, habiéndose adoptado
medidas correctoras de formo inmediata y existiendo medidas adecuadas previas al
incidente”.

- Y, finalmente, con fecha de 13 de mayo de 2024, se presenta copia de la
denuncia presentada ante la Policía Nacional, en la que CECOTEC denuncia
haber sido víctima de un presunto delito a causa del ciberataque anunciado en el

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

29/173

foro de la dark web al que se refiere el presente expediente. En concreto, se
indica que:
:
“II.— Que, como consecuencia de dicho traslado, CECOTEC ha tenido
conocimiento de los datos de carácter identificativo con los que opera aquél que
supuestamente habría obtenido datos de carácter personal de consumidores y/o
usuarios de la Compañía de forma ilícita, dedicándose a su vez a su Venta, a
través del foro https://sinister.ld” (copian datos del anuncio publicado el 5 de abril
de 2023 por el ciberdelincuente).
“IV.- Teniendo en cuenta que el tercero, cuyos datos se aportan a través de la
presente Denuncia, se dedica a la comercialización de una base de datos de
carácter personal de consumidores y/o usuarios, supuestamente de la Compañía,
así como pudiendo verse afectadas otras sociedades mercantiles ajenas a la
Compañía, esta parte quiere poner a disposición de las Fuerzas y Cuerpos de
Seguridad del Estado la información de la que se- dispone a los efectos legales
oportunos. ' '

CUARTO: Respecto al alcance de la brecha de confidencialidad de datos
personales cabe señalar que se ha practicado prueba y ha quedado acreditado que el
actor malicioso accedió de forma no autorizada, al menos, a un total de 1.000 registros
contenidos en la citada tabla “***TABLA.1” de CECOTEC, de los cuales 933
correspondían a personas físicas con DNI válido, cuyos datos personales no habían
sido cifrados ni seudonimizados, sino que aparecían visibles y expuestos en su
totalidad, y sin enmascarar en ninguno de sus 24 campos. Lo que se deduce de las
siguientes evidencias unidas al procedimiento:

- Con fecha de 4 de agosto de 2023, siguiendo las instrucciones contenidas en los
correos de alerta del INCIBE que constaban en el procedimiento, el inspector
contacta con el usuario malicioso y obtiene una segunda muestra de 1000
registros de la base de datos. Así lo hace constar en la conclusión cuarta de su
informe lo siguiente:
“4.- Por parte del inspector se ha contactado con el usuario que decía poner a la venta
la supuesta base de datos con objeto de contrastar la veracidad de la información y
verificar la existencia de filtración de datos personales, (…) y contiene 1086185
registros con datos de clientes. El usuario aportó al inspector (…), que son adicionales
a los 17 publicados en la muestra, con idéntica estructura de campos y datos que la
captura publicada. En relación con esta estructura de campos la empresa había
confirmado que se corresponde con la tabla “***TABLA.1” de su base de datos, que
contiene los siguientes datos personales de 1.000 personas: “***TABLA.12, postcode,
city, other, phone,phone_mobile, vat_number, dni.”

- Tal y como señala el informe API, con fecha de 2 de noviembre de 2023 se
incorporan al procedimiento la copia del correo electrónico de respuesta remitido
por el actor malicioso al inspector el 4 de agosto de 2023, y la muestra de 1000
registros obtenida del mismo. En concreto, dicho correo electrónico tiene el
siguiente contenido literal que se traduce a continuación:

“Re: Spanish Ieak 1 millon records From RKSinc©protonmail.ch
<RKS¡nc©protonmaíl.ch>
To paulecrypt<paulecrypt©proton.me>
Date Friday, August 4th, 2023 at 11:28 AM Many thanks for replying. –
Yes the company is CECOTEC. | accept BTC and maybe USDT (ERC20,TRC20)
majorly. As soon as your payment comes in , ¡ send your ñle ASAP. --Príce is

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

30/173

$3,000 (negotíable)
1,086,185 cecotec.es customer,manufacturers,supliers phone data 01/05/2023
7:25 pm Text Document 166,117 KB J
837,606 cecotec.es Customers (mobile Phone sorted) data 11/05/2023 7:54 pm
CSV File 128,060 KB *
* The first file is 1M Plus, when i sorted the phone numbers to (Mobile and
customers only) it came down to 837k plus.
You can see the files there”.

(Traducción al español por esta Agencia)

«Sí, la empresa es CECOTEC. | Aceptar BTC y tal vez USDT (ERC20, TRC20)
principalmente. Tan pronto como su pago llegue, ¡envíe su …. lo antes posible.
--Príce es $3,000 (negociable)
1,086,185 cecotec.es cliente,fabricantes,suministradores datos telefónicos
01/05/2023 7:25 pm Documento de texto 166,117 KB J
.837,606 cecotec.es Datos de los clientes (ordenados por teléfono móvil)
11/05/2023 7:54 pm CSV Archivo 128,060 KB *
* El primer archivo es 1M Plus, cuando ordené los números de teléfono a (Mobile
y clientes solamente) se redujo a 837k plus.
Puedes ver los archivos allí”

- En el primer escrito de contestación al acuerdo de prueba de 4-7-24, CECOTEC
aporta como doc 3 su estructura personalizada de la plataforma donde se
observa que hay una tabla que se llama “***TABLA.1”, cuyos campos coinciden
con los de la muestra de 1000 registros que el inspector obtuvo del
ciberdelincuente. Señala CECOTEC que esta estructura estaba vigente al cierre
de la plataforma en enero de 2021, permaneciendo invariable a fecha del
ciberataque.

- En el segundo escrito de contestación a prueba de 20-09-24 CECOTEC aporta
como DOC 1 un documento Excel sin fechar ni firmar, señalando que éste se
corresponde con el contenido íntegro de la citada tabla “***TABLA.1” que fue
requerida en fase de prueba, y haciendo constar que: “ De acuerdo con la
información facilitada por el departamento de IT, conviene indicar que el contenido de la
tabla “***TABLA.1” que se aporta en el presente escrito es el mismo que a fecha de cierre
de la plataforma en diciembre de 2022. En este sentido, se confirma que este contenido
es el mismo que a fecha del anuncio por el ciberdelincuente (5/4/2023) y que a fecha en
la que se hicieron las comprobaciones (12/04/2023 y 13/04/2023)”
- Con fecha de 14 de febrero de 2025 se expide Diligencia por la instructora del
procedimiento para hacer constar los datos obtenidos de la comparación entre los
registros contenidos en la muestra proporcionada por el ciber atacante el 4 de
agosto de 2023 y los contenidos en la tabla “***TABLA.1” aportada por
CECOTEC. En concreto, se constata lo siguiente:
“Se adjunta como Anexo I el listado Excel de coincidencias obtenidas de comparar
ambos listados, organizadas por DNI, tras realizar una validación de DNIs. Y se hace
constar el resumen del resultado obtenido:

1. Análisis registros y datos personales de la TABLA ***TABLA.1 DE CECOTEC.

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

31/173

La tabla ***TABLA.1 aportada por CECOTEC contiene un total de 2.057.313 registros
(filas), que se reducen a 2.054.164 registros que disponen de teléfono móvil. Por tanto,
no coinciden con los registros totales que dice tener el actor malicioso de 1.086.185, de
los cuales 837.606 con teléfono móvil.

La tabla ***TABLA.1 contiene 25 campos, en los que se contienen los siguientes tipos
de datos personales:
i. Dirección postal 1 (indicando la calle, número, código postal y ciudad).
ii. Dirección postal 2 (solo aparecen datos que parecen ser la
continuación o complemento de la dirección 1).
iii. Códigos identificadores completos: código de dirección, código de
país, código de cliente.
iv. Códigos identificadores de proveedor y fabricante: aparecen con 1 o 0.
v. Nombre y apellidos.
vi. Número DNI.
vii. Número NIF (aparece siempre en blanco).
viii. Teléfono fijo (no se cumplimenta siempre)
ix. Teléfono móvil (cumplimentado en casi todas las ocasiones).

*No se mencionan los campos que aparecen en blanco (NIF) o con valor cero, o
aquellos que no contienen datos personales de personas físicas como alias, company,
fecha, activo, borrado…etc.
Se señala también que no todos los registros tienen cumplimentados todos los
campos.”

2. Análisis datos personales y titulares de la MUESTRA 2 proporcionada por el actor
malicioso.

Los datos personales contenidos en la muestra de 1000 registros corresponden a un
total de 933 personas físicas que aparecen con un DNI válido, 50 personas físicas cuyo
número de DNI es inválido o incorrecto, y 17 corresponden con empresas.

Los datos aparecen visibles en su totalidad, sin aplicación de cifrado ni
seudonominización.

Los campos contenidos en la muestra 2, que contienen datos personales de personas
físicas con DNI válido ascienden a 933 personas, y son los siguientes*:
o Dirección postal 1 (indicando la calle, número, código postal y ciudad).
o Códigos identificadores: código de dirección, código de país, código de cliente,
código de suministrador y código de fabricante.
o Nombre y apellidos
o Número DNI.
o Teléfono fijo y teléfono móvil.”

*No se mencionan los campos que aparecen en blanco o con valor cero, como alias,
NIF, dirección 2, alias..etc. Y no todos los registros tienen cumplimentados todos los
campos:

3.- Análisis comparativo entre la muestra 2 y la tabla ***TABLA.1.

La muestra 2 contiene 1000 registros, todos los cuales se encuentran incluidos en la
tabla ***TABLA.1. Se observa que coinciden hasta los códigos identificadores que se
generan automáticamente por la base de datos, que el actor malicioso no podría
deducir si no hubiera accedido a la misma. (id ***TABLA.1, id country, id costumer, id

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

32/173

supplier…etc).

Las 933 personas físicas incluidas con DNI verificado cuyos datos personales
aparecen en el listado se encuentran incluidas en la tabla ***TABLA.1 de CECOTEC, e
incluyen los campos y datos personales que se han señalado”.

- En las alegaciones presentadas el 18 de marzo de 2025 frente a la propuesta
de resolución, tras recibir copia de la diligencia citada de cotejo de datos,
CECOTEC reconoce que la brecha alcanzó a un total de 933 personas físicas,
y pide que la sanción se gradué teniendo en cuenta este alcance, y no el de
1.086.185 que decía tener el ciber atacante. En concreto, señala que:

o Pag 2: “Junto a lo anterior, tras el cotejo realizado por la Agencia entre la
base de datos aportada por el atacante y la base de datos aportada por
CECOTEC, se desprende que: (…)El número de registros que coincide
en ambas tablas es de novecientos noventa y tres registros (993).
o Pag.4: “Por tanto, de conformidad con lo anterior:• No se ha podido
acreditar que el atacante haya accedido a 1.086.185 registros, sino,
únicamente, a 993, resultando desproporcionadas las cuantías de multas
impuestas en virtud del art 5 letra f) y artículo 32 del RGPD (…)”.
o Pág. 14: “No obstante, se ha de resaltar que, conforme se recoge en la
alegación segunda, la propia Agencia reconoce que el número total de
afectados es de 993, no de mil, ni de un millón”.
o Pág.15: “Por tanto:• El alcance del incidente es de 993 afectados, no de
1.086.185 como indicaba el atacante”.

QUINTO: En relación con la notificación de la brecha a esta Agencia consta
acreditada la siguiente cronología:

1. CECOTEC recibió en su buzón general (…) el primer correo electrónico de
alerta de incidente de ciberseguridad del INCIBE de 5-4-23 a las 14:53 horas al
que se refiere el hecho probado primero, pero dicho correo de alerta no se
remitió a los responsables de detectar la brecha y notificarla en la empresa,
incumpliéndose lo previsto en el Protocolo de Gestión de Incidentes de
Seguridad aprobado en abril de 2021 por la empresa, que señalaba que:

“Todo empleado de la organización que sea conocedor de un hecho
indiciario de un evento o incidente de seguridad en materia de
protección de datos personales, por cualquiera de los medios indicados
en el punto 2.1. de este documento (relativo a las fuentes de
identificación de una brecha de seguridad), deberá comunicarlo en el
plazo máximo de 24 horas a la Delegada de Protección de Datos y su
responsable inmediato y superior departamental”

Ello se reconoce por CECOTEC en el escrito de Resp#1 de CECOTEC: “El día
5 de abril a las 14:53 recibimos un correo electrónico del INCIBE (Instituto de
Ciberseguridad Español) a nuestro correo genérico ***EMAIL.1 en el que nos
informaban de un posible incidente de ciberseguridad con el código de referencia
[INCIBE—CERT 113713032]. Esta notificación no fue atendida a tiempo por esta
entidad ya que los correos electrónicos recibidos en este buzón (que está destinado a

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

33/173

clientes), son atendidos por orden de antigüedad. Además, esa semana hubo más
correos electrónicos a los que atender, teniendo en cuenta que los dias 7 y 10 de abril
fueron festivos.”

En el mismo escrito Resp#1 de CECOTEC se señala que la DPD se apercibió
de este error interno de comunicación y tomó medidas: “Por último, se hace saber
a la AEPD que el día 19 de abril de 2023 a las 13:29 horas la Delegada de Protección
de Datos remitió un correo electrónico a parte del equipo del Departamento de 820 de
CECOTEC que gestiona el buzón genérico ***EMAIL.1 en el que les advierte de la
importancia de remitirle los correos electrónicos que entren en este buzón referentes a
protección de datos a la mayor brevedad para su correcta gestión ”. Lo cual se
acredite mediante la aportación del citado correo electrónico de 19 de abril de
2023 adjuntado como Anexo 7 de la Resp#1.

2. El 12-4-23 a las 11:10 horas, se recibe en el mismo buzón un segundo correo
de alerta del INCIBE, en el que se hacía un seguimiento y se hacía constar que
estaban pendientes de respuesta del correo de alerta remitido 7 días antes y el
número de alerta.

3. Al recibir esta segunda alerta, se remite un correo electrónico por el
departamento de ciberseguridad al INCIBE en fecha 12-4-23 a las 12:17 horas,
solicitando se remita la información pertinente, que obraba desde el día 5-4-23
en el buzón general de CECOTEC.

4. El INCIBE contesta al departamento de ciberseguridad con fecha de 13-4-23 a
las 11:12 horas, remitiendo la información solicitada, que se corresponde con el
contenido del primer correo de alerta de 5-4-23, y se inician las actuaciones de
comprobación por el responsable de ciberseguridad de CECOTEC, tal y como
se reconoce en el informe inicial del DPD adjunto a la notificación de brecha el
subrayado es nuestro):

“El día 13 de abril a las 11:12 recibimos un correo de contestación de INCIBE en el
que nos indican que se ha detectado una publicación en el foro "synister.ly" de un
actor malicioso con el alias ***USUARIO.1 que indica estar en posesión de (…)
En el mismo momento en el que es conocedor de esa información, el responsable
de Ciberseguridad de CECOTEC junto con el Departamento de Informática,
empieza a gestionar esta supuesta brecha de seguridad de CECOTEC realizando
los trabajos y verificaciones técnicas necesarias para intentar corroborar a la
mayor brevedad posible que la información facilitada por el INCIBE efectivamente
afecta a CECOTEC.”

5. El mismo día 13-4-23 a las 17.26 horas el responsable de ciberseguridad
concluye la investigación realizada e informa al INCIBE de lo siguiente:

“Los datos que se muestran en la imagen que ha suministrado el usuario
***USUARIO.1 en ***FORO.1 se tratan de datos de prueba. Por otro lado,
la web con dichos datos se cerró en 2021 y no sigue en funcionamiento.
Por ahora, no podemos determinar si se considera una filtración con solo
la imagen que se muestra. La referencia de lo que se está hablando es
[***REFERENCIA.1]. De todas formas, estamos a vuestra disposición
para lo que necesitáis”.

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

34/173

6. Con fecha de 14-4-23 a las 14:31 horas, se aporta como Anexo 7 (Pag. 110
exp) un correo electrónico del departamento de ciberseguridad a la DPD
de CECOTEC, donde le informa de lo sucedido, las contestaciones al INCIBE,
y el resultado de estas investigaciones: El tenor literal de este correo es el
siguiente: (el subrayado es nuestro)

“Buenos días,
El miércoles 12 de abril de 2023 a las 11:10 nos notifica incibe—cert
(***EMAIL.2) a través del correo de ***EMAIL.1 lo siguiente: (COPIA
CORREO)
En dicho correo, no nos indican ningún tipo de información al respecto,
solamente nos dan un código de referencia por el que preguntar. No obstante,
el asunto era descriptivo ya que indicaba lo siguiente: [***REFERENCIA.1]
Posible incidente de ciberseguridad.
Posteriormente, el departamento de ciberseguridad envía un correo ese mismo
miércoles 12 de abril a las 12:17 al emisor incibe—cert (incidencias©incibe-
cert.es) para ver que datos son los que indican que está causando la posible
brecha de seguridad. El correo que redacta el departamento de ciberseguridad
es el siguiente: (COPIA CORREO)
A partir de esto, el departamento de ciberseguridad verificó a través de los
enlaces adjuntos en el correo y efectivamente el usuario ***USUARIO.1 está
vendiendo los supuestos datos en un foro privado llamado ***FORO.1. No
obstante, el usuario en ningún momento nombra a la organización cecotec,
solamente la descripción de la actividad de la supuesta empresa a la que
pertenecen dichos datos. (COPIA IMAGEN DEL ANUNCIO DEL FORO).
Por otro lado, en el otro enlace adjunto se encuentra una captura de pantalla
de la base de datos con algunos datos que el atacante estaba proporcionando
en el toro a mi de previsualización de lo-que contenía dicha base de datos.
(COPIA LA IMAGEN DE LA MUESTRA DE 17 REGISTROS).
Tras realizar el análisis, se vio que los registros de la tabla coinciden con los de
la tienda antigua de cecotec (…) que se cerró en 2021. No obstante,
actualmente dicha página la usan algunas personas a modo de consulta.
Tras investigar junto al departamento de ecommerce e infraestructura, pudimos
ver los registros que tiene el atacante de la base de datos son desde el 2016 al
2020, esto suponiendo que tenga el 1.000.000 de registros que dice tener, ya
que solamente muestra 18 registros en la imagen que adjunta. En dicha tabla
se encuentran datos de usuario como direcciones, código postal, ciudad del
usuario, teléfono, dni
También intentamos ver los logs para ver la trazabilidad y destapar al atacante,
pero no pudimos sacar nada en claro. Ya que vimos los logs del Presta8hop
(CMS monta en la tienda antigua ) y no eran de gran utilidad ya que solo
mostraban los inicios de sesión de los usuarios, además en su dia por temas
de rendimiento se desactivaron algunos logs que registraba el CMS y que no
se volvieron activar posteriormente. También, vimos que dicho
***SOFTWARE.1 presentaba varias vulnerabilidades de versión, por lo que no
podemos determinar si ese es el vector de entrada. Por otro lado, a nivel
servidor y accesos a la bd no pudimos ver mucho ya que no se estaba
monitorizando.
Tras analizar todos los entornos, el departamento de ciberseguridad no puede

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

35/173

determinar si ha sido por culpa de un malware en un workstation o desde el
propio aplicativo web, ya que a nivel workstation no tenemos actualmente
ningún sistema de monitorización de equipos, además de no tener
monitorizado dicho aplicativo web.
No obstante, aún no sabemos a ciencia cierta qué datos tiene el atacante, y es
por ello que le escribimos a incibe—cert ese mismo día jueves 13 de abril de
2023 a las 17::26 desde el departamento de ciberseguridad lo siguiente:
(COPIA ÚLTIMO CORREO REMITIDO A INCIBE).
Aún no hemos obtenido contestación en dicho correo.”

7. Con fecha de 17-4-23 el departamento de ciberseguridad comprueba con
INCIBE que no ha existido un intento de phishing.

8. Finalmente, la brecha de confidencialidad producida se notificó a esta Agencia
el 19 de abril de 2023 a las 18.19 horas.

Esta cronología queda acreditada mediante la aportación en el escrito Resp#1 al
requerimiento, de los siguientes correos electrónicos adjuntados como Anexos 6 y 7
(Pág. 98 del expediente):

o Correo electrónico de fecha 12 de abril de 2023 a las 11:10 horas remitido
desde INCIBE a ***EMAIL.1 de seguimiento del posible incidente.
o Correo electrónico de fecha 12 de abril de 2023 a las 12:17 horas remitido
desde ***EMAIL.3 a INCIBE pidiendo más información sobre el posible
incidente.
o Correo electrónico de fecha 13 de abril de 2023 a las 11:12 horas remitido
desde INCIBE a ***EMAIL.3 en el que se facilita información sobre el posible
incidente.
o Correo electrónico de fecha 13 de abril de 2023 a las 17:26 horas remitido
desde ***EMAIL.3 a INCIBE.
o Correo electrónico de fecha 14 de abril de 2023 (Pág 110 exp), remitido desde
***EMAIL.3 a [email protected], en el que el director de ciberseguridad informa a
la DPD de las investigaciones realizadas.
o Correo electrónico de fecha 17 de abril de 2023 a las 11:48 horas remitido
desde ***EMAIL.3 a INCIBE en el que, por medidas de seguridad, se solicita la
corroboración de identidad al INCIBE por no haber obtenido respuesta por parte
del INCIBE al último email remitido por ***EMAIL.3
o Correo electrónico de fecha 17 de abril de 2023 a las 12:38 horas remitido
desde INCIBE a ***EMAIL.3 en el que corroboran la identidad del remitente
INCIBE.
o Correo electrónico de fecha 19 de abril de 2023 a las 13:29 horas remitido por
***EMAIL.3 a INCIBE por el que se solicita a INCIBE la actualización del correo
electrónico para la recepción de futuras notificaciones para evitar posibles
demoras en la contestación a futuro.
o Correo electrónico de fecha 19 de abril de 2023 a las 15:56 horas remitido por
INCIBE a ***EMAIL.3 en el que se da contestación a lo solicitado por
CECOTEC.
SEXTO: Consta reconocido por la reclamada que no se ha comunicado la brecha a
los afectados por la misma cuyos datos aparecían en las muestras

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

36/173

proporcionadas por el actor malicioso, por considerar la reclamada que no
concurre alto riesgo de vulneración de sus derechos y libertades.

Así pues, consta en los informes de la DPD aportados junto con la notificación inicial
de la brecha el 19-4-23 y la Resp#1 al requerimiento, que la reclamada detectó que
la brecha había afectado a 6 personas reales cuyos datos personales estaban
incluidos en la primera muestra de 17 registros publicada en el anuncio del actor
malicioso. Y por otra parte, en sus alegaciones al acuerdo de inicio insiste en que no
es necesario comunicar la brecha a los afectados. Y en las alegaciones a la
propuesta de resolución, incluso tras haber reconocido que la brecha afectó a 933
personas, sigue manteniendo que no existe deber de comunicar la brecha por los
motivos indicados en sus alegaciones al acuerdo de inicio.

SÉPTIMO: Pese a haberse constatado la concurrencia de múltiples vulnerabilidades, y
deficiencias de la plataforma que pudieran haber posibilitado el ciberataque producido
a las que se hará referencia en el hecho probado siguiente, no se ha podido
determinar con certeza cuál ha sido el vector de entrada del ciberataque, tal y
como consta señalado en la conclusión primera del informe API, con base a lo
manifestado por el responsable de ciberseguridad de CECOTEC en el correo
electrónico de 14 de abril de 2023 que consta como Anexo 7 del escrito Resp#1 en el
que se señala que: “También vimos que dicho ***SOFTWARE.1 presentaba varias
vulnerabilidades de versión, pero no podemos determinar si ese es el vector de entrada”, y
“Tras analizar todos los entornos, el departamento de ciberseguridad no puede determinar si ha
sido culpa de malware en un workstation o desde el propio aplicativo web, ya que actualmente
desde el workstation no tenemos ningún sistema de monitorización de equipos, además de no
tener monitorizado el aplicativo web”.

Ahora bien, si consta acreditado, que los datos personales obtenidos por el
ciberatacante no habían sido cifrados ni seudonimizados, puesto que aparecen
visibles e inteligibles tanto los datos personales contenidos en la muestra de 17
registros que fue publicada en el anuncio (cuyo nombre y apellidos se hallaba
enmascarado, siendo publicados el resto de datos contenidos en la misma), como en
la muestra de 1000 registros que fue proporcionada al inspector, en el que no se
enmascaró ningún dato personal, quedando expuestos todos los datos personales que
constaban la misma.

OCTAVO. Sobre las vulnerabilidades y deficiencias de la Plataforma
***SOFTWARE.1 detectadas y las medidas preventivas adoptadas por CECOTEC
a fecha del ciber ataque.

En concreto, en relación con las medidas organizativas y técnicas que se hallaban
implantadas a fecha del ciberataque y antes de detectar la brecha de datos personales
para garantizar la seguridad de los datos personales contenidos en la antigua
plataforma ***SOFTWARE.1 de tienda online de CECOTEC (denominadas como
medidas preventivas en el informe API), ha quedado acreditado lo siguiente:

1. A fecha de la brecha producida existían vulnerabilidades de la plataforma

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

37/173

***SOFTWARE.1 empleada por CECOTEC, que afectaban al ***SERVICIO.1 y al
***SERVICIO.2, y que la plataforma se hallaba desactualizada, y fuera de soporte
desde 2019 y con acceso a internet (con código de usuario y contraseña)

La existencia de vulnerabilidades en la plataforma había sido manifestada por el
propio responsable de ciberseguridad en el correo de 14 de abril de 2023, en el
que se señaló que: “También vimos que dicho ***SOFTWARE.1 presentaba
varias vulnerabilidades de versión, pero no podemos determinar si ese era el
vector de entrada”.

Se hace constar en la Diligencia expedida por el inspector con fecha de 2 de
noviembre de 2023, tras acceder con dicha fecha a la plataforma a través de la
URL aportada en las capturas de correos anteriores (intercambiados con INCIBE)
y que correspondía con la dirección de acceso a la antigua plataforma basada en
***SOFTWARE.1 (y posible origen del ataque), lo siguiente:

- Esta plataforma, pese a ser antigua y estar en proceso de migración,
se mantenía activa disponiendo de acceso directo desde internet
únicamente a la parte de ***SERVICIO.1 (afirman que esto era
necesario por requisitos de integración con la nueva plataforma
implantada).

- De otro lado, ha quedado también acreditado que la antigua
plataforma hacía uso de la versión 1.6.1 de ***SOFTWARE.1, la cual se
ha constatado que pertenece a una versión desactualizada, fuera de
soporte desde el año 2019 y con múltiples vulnerabilidades críticas que
afectaban tanto a ***SERVICIO.2 (…) como al ***SERVICIO.1 (…).

Se adjuntan así mismo capturas de pantalla que acreditan que con anterioridad al
ciberataque se publicaron avisos de una vulnerabilidad de inyección de SQL
detectada en la versión 1.6 de la plataforma que estaba siendo explotada por
atacantes en servidores que contenían servicios web, y que se publicó una
actualización el 26-7-22 dirigida a subsanar la misma. Ello se desprende de las
capturas de pantalla adjuntas, que reflejan lo siguiente:

(i) Un aviso de vulnerabilidad de la plataforma ***SOFTWARE.1 publicado el
26/07/22 en la página del INCIBE en el que consta que “***SOFTWARE.1 ha
publicado una actualización de seguridad que corrige una vulnerabilidad
crítica por lo que se recomienda actualizar la última versión disponible cuanto
antes”, la cual afecta precisamente a la versión 1.6, utilizada por CECOTEC.
(ii) Publicación en la página del boletín de noticias sobre ciberseguridad
“Hispasec Una al día”, donde aparece este mismo aviso sobre: “Atacantes
explotan activamente vulnerabilidad de RCE en el CMS ***SOFTWARE.1 de
28julio, 2022. Ciberdelincuentes encuentran la manera de utilizar una
vulnerabilidad de inyección de SQL para ejecutar código remoto en
servidores que contienen servicios web de ***SOFTWARE.1”

2. Falta de medidas adecuadas para garantizar la trazabilidad de la plataforma:

o Queda acreditada por las manifestaciones realizadas por el responsable de
ciberseguridad de CECOTEC en el anteriormente citado correo electrónico de

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

38/173

14 de abril de 2023, cuando señala que:

“También intentamos ver los logs para ver la trazabilidad y destapar al
atacante, pero no pudimos sacar nada en claro. Ya que vimos los logs del
Presta8hop (CMS monta en la tienda antigua ) y no eran de gran utilidad ya
que solo mostraban los inicios de sesión de los usuarios, además en su dia por
temas de rendimiento se desactivaron algunos logs que registraba el CMS y
que no se volvieron activar posteriormente. También, vimos que dicho
***SOFTWARE.1 presentaba varias vulnerabilidades de versión, por lo que no
podemos determinar si ese es el vector de entrada. Por otro lado, a nivel
servidor y accesos a la bd no pudimos ver mucho ya que no se estaba
monitorizando. Tras analizar todos los entornos, el departamento de
ciberseguridad no puede determinar si ha sido por culpa de un malware en un
workstation o desde el propio aplicativo web, ya que a nivel workstation no
tenemos actualmente ningún sistema de monitorización de equipos, además de
no tener monitorizado dicho aplicativo web.”

o Además, el escrito Resp#1 de CECOTEC reconoce que la plataforma no
disponía de las medidas de seguridad apropiadas en relación con el control de
acceso de los usuarios de la plataforma, señalando que:

“(...)”

3. Sobre la falta actualización del análisis de riesgos de la plataforma.

Al respecto, tal y como hace constar Informe API punto 8: “ha quedado
acreditado la existencia de análisis documentado realizado en la fecha 10 de
abril de 2022. La empresa confirma que no constan análisis de riesgos con fecha
anterior a la anteriormente indicada, no obstante, ha quedado constado que la
actividad de tratamiento afectada por la brecha se inicia en el año 2013
(“Gestión de Clientes”).

Ello queda fijado dado que en el escrito de Resp#1 CECOTEC aporta un AR de
10-4-22, y en Resp#2 confirma que no realizaron ninguno anteriormente,
señalan que la plataforma estaba en funcionamiento desde 2013, y aportan dos
actualizaciones realizadas sin firmar de 2022 y de 2023, y se reconoce que la
empresa se halla inserta en un proceso de revisión de documentos y decisión de
medidas a tomar: “Se informa a la AEPD que, en el último año el puesto de Delegado
de Protección de Datos ha sido ocupado por tres personas distintas, no habiendo una
continuidad en las funciones del Delegado de Protección de Datos especificadas en el
artículo 39 del Reglamento 2016/679 de 27 de abril de 2016 (en adelante, “RGPD”). Es
por ello por lo que, actualmente, la empresa se encuentra en un proceso de revisión
urgente de documentos y de decisión de medidas a tomar y de procedimientos a
implementar, entre los que se encuentra la revisión de todos los análisis de riesgos
realizados y la valoración de la necesidad de realizar una evaluación de impacto de los
mismos”.

4. Falta de aprobación y aplicación de un Protocolo de Gestión de Brechas de
Seguridad adecuado a la normativa.

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

39/173

o Consta que la empresa había aprobado un Protocolo de gestión de incidentes
de seguridad” que no contiene firma, fechado el 22 de abril de 2021, aportado
con el escrito Resp#1. No se acompaña justificación de que el mismo fuera
comunicado al personal de la empresa con anterioridad a la brecha. En el
mismo no constan los datos de contacto de las personas a las que se debía
comunicar las alertas de incidente de ciberseguridad y las encargadas de
detectar y notificar la brecha.

- Al requerirse la aportación de la “actualización de 2022” citada por la reclamada,
ésta aporta en la Resp#2, un Protocolo de Gestión de Brechas de Seguridad,
que no está firmado y está fechado el 31 de julio de 2023, con posterioridad a la
producción y detección de la brecha (“Fecha de última actualización 29 de
agosto de 2023”). Protocolo que se considera adoptado como medida correctiva
pero que no existía como medida preventiva en el momento en que se produjo
la brecha de confidencialidad a la que se refiere el presente expediente, tal y
como lo confirman los hechos, y las propias afirmaciones contenidas en este
mismo escrito Resp#2.

Por otra parte, el informe API hace constar que de acuerdo con la documentación
aportada por la reclamada, se ha constatado que existían las siguientes medidas
preventivas implantadas por CECOTEC antes de detectar la brecha originada por el
ciberataque:

 (…)
NOVENO. Sobre las medidas correctivas adoptadas en la plataforma tras la
brecha producida.

A la vista de la documentación justificativa aportada y la prueba practicada, se
considera acreditado que se han adoptado por la empresa medidas correctivas en la
plataforma tras la brecha producida:

- Las alegadas en los escritos de respuesta durante la fase de investigación, cuya
acreditación fue comprobada por el inspector, haciendo constar en la conclusión
de su informe lo siguiente:

“Tras detectar la brecha de seguridad se adoptaron las siguientes medidas
reactivas para fortalecer la seguridad de la plataforma:

 (…)”

- Con posterioridad a conocer el inicio de actuaciones previas de investigación,
la empresa aprueba un Protocolo de Brechas de Seguridad el 31 de julio de
2023, actualizado a 29 de agosto de 2023, que remite junto con su Resp#2.

- Con posterioridad al acuerdo de inicio de este expediente el 1 de abril de 2024,
se ha procedido a deshabilitar el acceso a la plataforma desde internet.

En su escrito AlegAI#1 la reclamada manifiesta haber deshabilitado el acceso a
la plataforma ***SOFTWARE.1 desde internet, lo que ha podido ser
comprobado por esta instructora mediante Diligencia de 3 de junio de 2024, por

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

40/173

lo que se tiene por acreditada esta medida correctiva por CECOTEC con
posterioridad al inicio del procedimiento sancionador.

- Queda constatado también, que la plataforma se mantuvo accesible a internet
hasta, al menos, el 2 de noviembre de 2023, fecha en la que el inspector emitió
diligencia haciendo constar que: “El acceso a la URL ***URL.1 sigue estando
disponible, accediéndose al ***SERVICIO.1 de la instalación del software
***SOFTWARE.1”. Habiendo reconocido CECOTEC en su Resp#2 de CECOTEC, que:
“La razón por la cual la plataforma todavía está accesible en Internet radica en la
necesidad de mantener integraciones activas con nuestra nueva tienda en línea. Estas
integraciones operan en modo lectura y son esenciales para el funcionamiento de
nuestro sistema por lo que actualizar la plataforma a una versión más reciente podría
generar inconvenientes en las mismas. Además, algunas de estas integraciones siguen
requiriendo que se pueda acceder al ***INTERFAZ.1 de la plataforma desde Internet.
No obstante, lo anterior, en los próximos meses se van a realizar las gestiones técnicas
oportunas para realizarla migración de todas las integraciones dela plataforma y
eliminar por completo la exposición de la plataforma de Internet.

FUNDAMENTOS DE DERECHO

I
Competencia y procedimiento

De acuerdo con los poderes que el artículo 58.2 del Reglamento (UE) 2016/679
(Reglamento General de Protección de Datos, en adelante RGPD), otorga a cada
autoridad de control y según lo establecido en los artículos 47, 48.1, 64.2 y 68.1 de la
Ley Orgánica 3/2018, de 5 de diciembre, de Protección de Datos Personales y
garantía de los derechos digitales (en adelante, LOPDGDD), es competente para
resolver este procedimiento la Presidencia de la Agencia Española de Protección de
Datos.

Asimismo, el artículo 63.2 de la LOPDGDD determina que: "Los procedimientos
tramitados por la Agencia Española de Protección de Datos se regirán por lo dispuesto
en el Reglamento (UE) 2016/679, en la presente ley orgánica, por las disposiciones
reglamentarias dictadas en su desarrollo y, en cuanto no las contradigan, con carácter
subsidiario, por las normas generales sobre los procedimientos administrativos."

II.
Cuestiones Previas

2.1. Sobre los datos personales, operaciones y responsable del tratamiento.

El RGPD tiene por objeto garantizar el derecho a la protección de los datos de las
personas físicas, señalando en su artículo 4 lo que considera como “datos
personales”, “operaciones de tratamiento” sujetas al RGPD, y quien es el
“responsable” de un tratamiento de la forma siguiente:

- El artículo 4.1 del RGPD entiende por “datos personales” “toda información
sobre una persona física identificada o identificable («el interesado»); se

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

41/173

considerará persona física identificable toda persona cuya identidad pueda
determinarse, directa o indirectamente, en particular mediante un identificador,
como por ejemplo un nombre, un número de identificación, datos de
localización, un identificador en línea o uno o varios elementos propios de la
identidad física, fisiológica, genética, psíquica, económica, cultural o social de
dicha persona;”.

- El artículo 4.2 del RGPD define el “tratamiento” como “cualquier operación o
conjunto de operaciones realizadas sobre datos personales o conjuntos de
datos personales, ya sea por procedimientos automatizados o no, como la
recogida, registro, organización, estructuración, conservación, adaptación o
modificación, extracción, consulta, utilización, comunicación por transmisión,
difusión o cualquier otra forma de habilitación de acceso, cotejo o
interconexión, limitación, supresión o destrucción;”.

- El artículo 4.7. del RGPD entiende por responsable del tratamiento “la persona
física o jurídica, autoridad pública, servicio u otro organismo que, solo o junto
con otros determine los fines y medios del tratamiento”.

En el caso examinado, durante la instrucción del procedimiento ha sido acreditado que
CECOTEC ha actuado como responsable del tratamiento de los datos personales
contenidos en una antigua plataforma de tienda online denominada “***SOFTWARE.1”
cuyo ***SERVICIO.2 fue cerrado en enero de 2021, pero permaneció parciamente
activa en su ***SERVICIO.1, en la que se trataban varios tipos de datos personales
según la definición del artículo 4.1 del RGPD.

Así pues, tal y como se hace constar en hechos probados, consta acreditado que:

- Con fecha de 5 de abril de 2023 se produjo un incidente de ciberseguridad que
fue comunicado por INCIBE a CECOTEC, advirtiéndole de que dicho día se
había publicado un anuncio en un foro de la dark web que este organismo
monitoriza por el usuario malicioso denominado “***USUARIO.1” en el que se
ponía a la venta una base de datos de casi un millón de registros de una
conocida empresa de electrodomésticos cuyos datos podrían coincidir con
CECOTEC. Todo ello con el detalle que consta en el Hecho Probado Primero
de esta propuesta.

- Pese a que se desconoce cuál fue el vector de ataque, si ha quedado
acreditado que el ciber-atacante pudo acceder a los datos personales
contenidos en dicha plataforma “***SOFTWARE.1” de tienda online, y, en una
de las tablas denominada: “***TABLA.1: direcciones de clientes y pedidos”,
según lo que manifiesta CECOTEC y se ha podido comprobar a lo largo de la
instrucción. Más adelante se entrará en la cuestión controvertida del número
de registros a los que accedió el ciber-atacante.

- Dentro de dicha tabla “***TABLA.1” se almacenaban datos personales de
clientes de CECOTEC generados entre los años 2016 y 2020. Para concretar
los datos personales que fueron objeto de tratamiento, es necesario analizar la
información que se incluía en dicha tabla “***TABLA.1: direcciones de clientes
y pedidos”. A estos efectos, consta en el expediente la siguiente información:

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

42/173

(i) Por una parte, se dispone de dos muestras de la base de datos
proporcionadas por el actor malicioso:

La primera muestra (en adelante, muestra 1) es la que constaba en
el anuncio publicado el 5 de abril de 2023 (de 17 registros) en la
dark web, en la que el actor malicioso decía que se disponía de una
base de datos de casi 1 millón de registros que pertenecían a una
empresa cuyos datos coincidían con los publicados por
“infoempresa” de CECOTEC. Esta muestra ha sido la que fue
cotejada por CECOTEC al recibir la alerta del INCIBE, señalando en
su notificación de brecha que los 17 registros se encontraban en la
tabla ***TABLA.1 de esta plataforma antigua de tienda online.

En segundo lugar, durante la fase de actuaciones previas de
investigación, el inspector contactó con el actor malicioso para
obtener una muestra mayor y éste le confirmó que la base de datos
era de CECOTEC (“Yes, is CECOTEC”), y le proporcionó con fecha
de 4 de agosto de 2023 una muestra mayor de 1000 registros (en
adelante, muestra 2). CECOTEC pudo comprobar su contenido al
trasladarle la copia del acuerdo de inicio.

Pues bien, las dos muestras proporcionadas por el actor malicioso
contienen los mismos 24 campos que siguen el mismo orden de la
tabla ***TABLA.1 que posteriormente ha sido proporcionada por
CECOTEC.

La estructura de ambas muestras es la siguiente:
“***TABLA.1,id_country,id_state,id_customer,id_manufacturer,id_sup
plier,id_warehouse,alias,company,lastname,firstname,***TABLA.11,*
**TABLA.12,postcode,city,other,phone,phone_mobile,vat_number,dn
i,date_add, active,deleted.”

(Traducido al español por esta Agencia),
““
(…),id_país,id_estado,id_cliente,id_fabricante,id_proveedor,id_alma
cén,alias,empresa,apellido,nombre,dirección1,dirección2,
códigopostal,ciudad,otro,teléfono,teléfono_móvil,nº_iva,dni,fecha_alt
a, activo, eliminado.”

(i) En fase de prueba se requirió y la imputada aportó el contenido
íntegro de dicha tabla ***TABLA.1 de la antigua plataforma
***SOFTWARE.1 de CECOTEC que fue objeto del ciber-ataque, con
fecha de 24 de septiembre de 2024 (en adelante, la tabla/ tabla
***TABLA.1).

Éste se corresponde con un documento Excel que la misma dice
haber extraído de la plataforma en cuestión, señalando que su
contenido ha permanecido invariable desde el cierre de la
plataforma en enero de 2021 hasta la fecha del ciberataque el 5 de

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

43/173

abril de 2023, aunque no aporta prueba que justifique este aspecto.

Según CECOTEC, la misma contiene datos correspondientes a los
años 2016 y 2021 que se refieren a direcciones de clientes y
pedidos, que incluyen datos de personas físicas y algunos datos
correspondientes a empresas. Lo que coincide también con las dos
muestras proporcionadas por el actor malicioso.

La estructura de dicha tabla está compuesta por los mismos 24
campos que contienen las muestras del actor malicioso, a las que
se añade un campo más, denominado “date_upd”.
.
“***TABLA.1,id_country,id_state,id_customer,id_manufacturer,id_sup
plier,id_warehouse,alias,company,lastname,firstname,***TABLA.11,*
**TABLA.12,postcode,city,other,phone,phone_mobile,vat_number,dn
i,date_add, date_ upd, active,deleted.”

(Traducido al español por esta Agencia),
““
(…),id_país,id_estado,id_cliente,id_fabricante,id_proveedor,id_alma
cén,alias,empresa,apellido,nombre,dirección1,dirección2,
códigopostal,ciudad,otro,teléfono,teléfono_móvil,nº_iva,dni,fecha_alt
a, fecha_actualización, activo,eliminado.”

En conclusión, de ello se desprende que la estructura de los datos contenidos en las
dos muestras proporcionadas por el actor malicioso y la tabla “***TABLA.1” contenida
en la antigua plataforma ***SOFTWARE.1 1.6 personalizada por CECOTEC dispone
de 24 campos coincidentes, siendo la única diferencia la inclusión de un campo
adicional en el documento Excel que se aporta por CECOTEC extraído de la tabla
***TABLA.1, que es el referido a “date_upd”, correspondiente con la fecha actualizada
que es un campo que se genera automáticamente con cada actualización de la
plataforma realizada. Por ello, habiéndose alegado esta falta de coincidencia en las
alegaciones a la propuesta de resolución, cabe señalar que la falta de coincidencia de
este campo no excluye el hecho de que el ciberatacante disponga de los datos
personales que aparecen en el resto de campos incluidos en la muestra, que si
coinciden con la tabla.

Por otra parte, de acuerdo con la Diligencia expedida el 6 de febrero de 2025 al
comparar los datos de la muestra 2 de 1000 registros con los incluidos en la tabla
***TABLA.1 de CECOTEC, se ha comprobado que:

“La tabla ***TABLA.1 contiene un total de 2.057.313 registros, en cuyos
campos se contienen los siguientes tipos de datos personales:

a. Dirección postal 1 (indicando la calle, número, código postal y ciudad).
b. Dirección postal 2 (solo aparecen datos que parecen ser la
continuación o complemento de la dirección 1).
c. Códigos identificadores completos: código de dirección, código de país,
código de cliente.
d. Códigos identificadores de proveedor y fabricante: aparecen con 1 o 0.

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

44/173

e. Nombre y apellidos.
f. Número DNI.
g. Número NIF (aparece siempre en blanco).
h. Teléfono fijo (no se cumplimenta siempre)
i. Teléfono móvil (cumplimentado en casi todas las ocasiones).

*No se mencionan los campos que aparecen en blanco (NIF) o con valor
cero, o aquellos que no contienen datos personales de personas físicas como
alias, company, fecha, activo, borrado…etc.
Se señala también que no todos los registros tienen cumplimentados todos los
campos”

Consta, por tanto, que dentro de dicha tabla “***TABLA.1” que fue objeto del
ciber-ataque se almacenaban y explotaban por CECOTEC varios tipos de datos
personales correspondientes a personas físicas, cuyo tratamiento debe regirse por
lo establecido en el RGPD.

En segundo lugar, no cabe duda de que a fecha del ciber-ataque y en la actualidad,
CECOTEC continúa realizando operaciones de tratamiento sobre los datos
personales contenidos en dicha antigua plataforma de tienda online, sobre la que
reconoce lo siguiente:

- Se trata de una plataforma que se creó en el año 2013 “como una tienda en
línea diseñada a través del software ***SOFTWARE.1, dedicada a la creación
y gestión de tiendas virtuales para el comercio electrónico”; y “fue sustituida
por una nueva tienda en línea desarrollada internamente que adoptó
tecnologías de desarrollo web de código abierto más modernas (…) Esta
transición se completó a principios de 2021.”

- No obstante, a pesar de estar cerrada en su (…), la empresa reconoce que
continuaba utilizando la antigua plataforma en su (…) para realizar ciertas
operaciones de tratamiento de sus datos, en los siguientes términos: “A pesar
del cierre de la plataforma original, se ha mantenido un acceso limitado a la
misma (su ***INTERFAZ.1) con el único fin de poder atender solicitudes,
necesidades y/o reclamaciones de clientes de la empresa”. Así pues,
manifiesta la imputada que: “a la fecha de la brecha, por tanto, el
***INTERFAZ.2 (…) de esta plataforma no se encontraba operativo,
manteniéndose únicamente activo el ***INTERFAZ.1 ((…) ***SERVICIO.1),
que permite añadir/editar/eliminar productos y gestionar datos de clientes”.

Por tanto, es un hecho reconocido que, a la fecha del ciber-ataque (5-4-23), la
empresa continuaba realizando varias de las operaciones de tratamiento de los datos
personales contenidos en esta plataforma antigua a los que se refiere el artículo 4.2
del RGPD, dado que continuaba almacenando más de 2 millones de registros en esta
tabla “***TABLA.1”, y accedía a la misma para hacer operaciones de consulta,
extracción, y utilización de los datos personales que eran necesarios para solventar
estas incidencias.

Por lo que respecta a la responsabilidad del tratamiento, siendo la empresa quien
determinó que la plataforma antigua continuase usándose en (…) “***SERVICIO.1”, en

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

45/173

paralelo a la plataforma nueva, se considera que la misma continuaba siendo la
responsable del tratamiento, porque seguía fijando los fines y los medios relacionados
con el tratamiento de los datos de carácter personal que continuaban almacenados en
la misma. Por tanto, no es un hecho controvertido la condición de CECOTEC como la
responsable del tratamiento de estos, en virtud del artículo 4.7 del RGPD, lo que la
convierte, a su vez, en la responsable de las infracciones que se derivan del
incumplimiento de sus obligaciones como responsable del tratamiento.

Dicho en otras palabras, consta acreditado que a la fecha del ciberataque (5-4-23), la
antigua plataforma de tienda online de CECOTEC, contenía una base de datos de
clientes, fabricantes y proveedores obtenidos entre los años 2016 y 2020, que
continuaba operativa en su ***SERVICIO.1 o ***INTERFAZ.1, pese a haber sido
cerrado su ***SERVICIO.2 o ***INTERFAZ.2 en enero de 2021, que continuaba con
acceso a internet sin deshabilitarse, sin que CECOTEC hubiera ejecutado en dicho
momento la migración de los datos contenidos en la antigua plataforma a la nueva
plataforma, ni haber aplicado las adecuadas garantías de supresión o bloqueo de
datos. Plataforma que se hallaba desactualizada y con las vulnerabilidades
reconocidas por CECOTEC que se han hecho constar en el Hecho Probado Séptimo
de esta propuesta. Y esta decisión de mantener parcialmente activa la plataforma
antigua implica necesariamente que el tratamiento de los datos personales contenidos
en ésta continuase también, por lo que debía realizarse con los requisitos y garantías
exigidas en el RGPD.

Por tanto, no cabe duda de que CECOTEC, como responsable de los datos
contenidos en dicha plataforma debió cumplir con las obligaciones establecidas en la
normativa de protección de datos, que le obligan, entre otras cosas a: (i) evitar que se
vulnere la confidencialidad de los datos personales contenidos en su base de datos;
(ii) establecer determinadas medidas organizativas y técnicas adecuadas en dicha
plataforma para asegurar la protección de los datos personales contenidos en la
misma; (iii) y a detectar y notificar a la autoridad de control las brechas de datos
personales producidas y comunicarlas a los afectados, en su caso, en los plazos y
forma previstos en el RGPD.

Queda, pues, confirmado, que CECOTEC estuvo tratando datos personales de los
clientes contenidos en dicha plataforma antigua de tienda online, siendo responsable
de su tratamiento de acuerdo con los conceptos definidos en los artículos 4.1, 4.2 y 4.7
del RGPD.

2.2. Sobre la concurrencia de una brecha de confidencialidad de datos personales y su
alcance.

Como paso previo a valorar la concurrencia en el caso presente de las infracciones
que se imputan en el presente procedimiento, procede determinar, primeramente, si la
brecha que fue notificada a esta Agencia por CECOTEC el 19 de abril de 2023 supuso
un acceso no autorizado por parte del ciber-atacante a los datos contenidos en la
citada plataforma ***SOFTWARE.1 utilizada por CECOTEC, que pueda ser calificado
como una brecha de datos personales, en el sentido previsto en el artículo 4 apartado
12 del RGPD define, de un modo amplio, las “violaciones de seguridad de los datos
personales” como “todas aquellas violaciones de la seguridad que ocasionen la
destrucción, pérdida o alteración accidental o ilícita de datos personales transmitidos,

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

46/173

conservados o tratados de otra forma, o la comunicación o acceso no autorizados a
dichos datos.”

Tal y como consta en los hechos probados tercero y cuarto de esta propuesta, en el
presente supuesto ha sido acreditado durante la fase de instrucción, que CECOTEC
fue víctima de un ciber-ataque producido el 5 de abril de 2023, por lo que un actor
malicioso pudo acceder sin autorización a la información contenida en la denominada
tabla “***TABLA.1: direcciones de clientes y pedidos” contenida en la antigua
plataforma de tienda online ***SOFTWARE.1.

Y como consecuencia de este acceso ilegítimo se produjo una brecha de
confidencialidad que afectó, al menos, a los 1000 registros que se ha acreditado
durante la instrucción que se hallaban en poder del actor malicioso y se habían puesto
a la venta en un foro de la dark web, que contenían datos personales correspondientes
a 933 personas físicas con DNI verificado, que se han hecho constar en la referida
Diligencia de 14 de febrero de 2025. Datos personales que no se hallaban cifrados,
habiendo proporcionado el ciber-atacante una muestra en la que todos estos aparecen
visibles, y que de acuerdo con dicha Diligencia eran los siguientes:

o Dirección postal 1 (indicando la calle, número, código postal y ciudad).
o Códigos identificadores: código de dirección, código de país, código de
cliente, así como los códigos identificadores de proveedor y fabricante:
aparecen con 1 o 0), porque están junto y ligados con otros datos
personales del cliente.
o Nombre y apellidos
o Número DNI.
o Teléfono fijo y teléfono móvil.”

Por tanto, queda confirmada la concurrencia de una brecha de confidencialidad de
datos personales, puesto que de acuerdo con el artículo 4.12 del RGPD, se produjo
una violación de la seguridad de la plataforma que ocasionó la comunicación o acceso
no autorizados a dichos datos personales.

En la valoración de la prueba y contestación a las alegaciones al acuerdo de inicio y a
la propuesta de resolución se detallarán los motivos por los que se entiende que cabe
confirmar la comisión de las 4 infracciones administrativas, confirmando las
valoraciones realizadas por la propuesta de resolución a raíz de la instrucción
practicada, no habiendo la reclamada aportado en sus alegaciones a la propuesta de
resolución acreditación documental de sus afirmaciones ni motivos que justifiquen el
archivo ni la reducción de las sanciones que fueron propuestas por la instructora.

III.
Valoración de la prueba

La parte reclamada ha presentado varios escritos a lo largo de la fase de actuaciones
previas de investigación, y varios escritos en los que formula alegaciones frente al
acuerdo de inicio de este expediente, y frente a la propuesta de resolución, y contesta
a los dos requerimientos de prueba que fueron acordados por esta instructora con
fechas de 3 de junio y 27 de agosto de 2024.

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

47/173

En el presente supuesto, en los escritos de alegaciones al acuerdo de inicio se
reconoció desde un primer momento por CECOTEC que se produjo una brecha de
datos personales en una de sus bases de datos originada por el ciber-ataque al que se
refiere el hecho probado primero de esta propuesta, y se han tenido por acreditados
los hechos afirmados por la misma respecto a las características de la plataforma
***SOFTWARE.1 que fue objeto del ciberataque, y la falta de determinación del vector
de entrada del ciberataque.

No obstante, tal y como señala la propuesta de resolución, eran hechos controvertidos
relevantes del procedimiento cuya acreditación requirió de la práctica de prueba
(acuerdos de prueba de 3 de junio y 27 de agosto de 2024), los siguientes:

- El alcance o número de personas a las que afectó la brecha de
confidencialidad.

- Concurrencia de actuación culpable por parte de CECOTEC respecto a la
vulneración de confidencialidad de los datos imputada como infracción del
artículo 5.1.f).

- Las vulnerabilidades detectadas y medidas adoptadas en la plataforma
***SOFTWARE.1 de antigua tienda online de CECOTEC antes de detectar la
brecha originada por el ciberataque.

- Las medidas correctivas adoptadas por CECOTEC con posterioridad a
detectar el ciberataque.

Sin perjuicio de contestar por separado a las alegaciones formuladas en el fundamento
de derecho siguiente, la propuesta de resolución analizó en su Fundamento de
Derecho III la prueba practicada en el presente procedimiento y determinó las razones
y evidencias en base a las cuales considerado probados los hechos reconocidos y
controvertidos del presente procedimiento.

3.1. Hechos reconocidos por la reclamada.

A la vista de las alegaciones formuladas y documentos presentados por la reclamada
(con anterioridad a dictarse propuesta de resolución), se afirmó que en la propuesta
de resolución que se consideraban probados los siguientes hechos reconocidos
por la misma:

- Concurrencia de una brecha o filtración de los datos personales contenidos en
una antigua plataforma de tienda online de CECOTEC.

Es un hecho reconocido por CECOTEC que se produjo una brecha de
confidencialidad de los datos personales que constaban en la tabla “***TABLA.1”
de la antigua plataforma ***SOFTWARE.1 versión 1.6 de código abierto utilizada
para la tienda online de CECOTEC hasta el cierre de su ***SERVICIO.2 (…) en el
año 2021, que continuaba utilizándose en su ***SERVICIO.1 (…) a la fecha del
ciber-ataque (5-4-23).

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

48/173

Así pues, de acuerdo con lo que consta en el hecho probado primero de esta
propuesta el INCIBE advirtió a CECOTEC con fecha de 5-4-23 de que un actor
malicioso había publicado en dicha fecha en un foro de la dark web que estaba en
disposición de una base de datos de una conocida empresa española de
electrodomésticos cuyos datos económicos podrían corresponderse con
CECOTEC. Esta primera notificación de alerta de incidente de ciber-seguridad fue
recibida por el buzón general de CECOTEC y no se remitió al departamento
correspondiente, tal y como consta en el correo electrónico aportado como Anexo
7, de acuerdo con lo que consta en el hecho probado quinto.

Y consta también acreditado en el hecho probado tercero que, tras recibir una
segunda alerta de notificación por parte del INCIBE el 12-4-23, el director de
ciberseguridad de CECOTEC requirió la información al mismo, e inició realizó las
comprobaciones oportunas, para cotejar la muestra de 17 registros que el actor
malicioso había publicado en dicho foro, y remitió un correo interno al DPD de
CECOTEC con fecha de 14 de abril de 2023 (unido como Anexo 6 del escrito
Resp#1), en el que señalaba que los 17 registros se hallan incluidos en la tabla
denominada “***TABLA.1” perteneciente a la plataforma ***SOFTWARE.1 que fue
parcialmente cerrada en el año 2021, que estaban desactualizada y adolecía de
múltiples vulnerabilidades, cuyo ***SERVICIO.1 continuaba activo y con acceso a
internet (con código usuario y contraseña) y que solo 6 de estos se correspondían
con datos de personas reales, estando el resto incluidos también en la tabla, pero
correspondiendo a datos de prueba.

Hay que decir que en el presente caso, la empresa ha mantenido una versión
contradictoria respecto a la verosimilitud del ciber-ataque, puesto que:

o En sus dos escritos de contestación a los requerimientos realizados
durante la fase de investigación: (i) por una parte, niega que la filtración
sea real, haciendo referencia a que en el mensaje del foro no se menciona
en ningún momento que la base de datos pertenezca a esta organización
y, por otro lado, que los datos de muestra que contiene la captura de
pantalla publicada no son suficientes para poder determinar que ha
existido filtración real de la base de datos de la compañía; (ii) y, por otra
parte, reconocen que estos 17 registros que constaban en la muestra
inicial coinciden con los datos almacenados en una de sus tablas de la
base de datos denominada “***TABLA.1”. Y como consecuencia de ello, se
señala que CECOTEC decide notificar a esta Agencia una brecha de datos
personales en su base de datos producida como consecuencia del ciber-
ataque, considerando que este afectó a estas 6 personas reales que se
contenían en dicha tabla, aunque no considera que sea necesaria su
comunicación a los afectados por no ser creíble y calificar la brecha de
riesgo e impacto bajos.

o Pero en los 2 escritos de alegaciones presentados tras el acuerdo de
inicio, - tras pedir copia del expediente y conocer que el ciber-atacante
proporcionó a esta Agencia una muestra de 1000 registros- CECOTEC
reconoció que había sido víctima de un ciber-ataque, que afectó
únicamente a estas 6 personas, negando que se haya acreditado su
culpabilidad en la filtración producida, y que el ciber-atacante disponga de

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

49/173

la totalidad de la base de datos contenida en la tabla “***TABLA.1”.
Versión que mantiene en la actualidad, tras las alegaciones formuladas
contra la propuesta de resolución.

Por tanto, podemos decir que tras el acuerdo de inicio de este expediente y recibir
copia íntegra del mismo, CECOTEC reconoce que ha sido víctima de un
ciberataque, y que ha denunciado el mismo ante la Policía Nacional. Se
acompaña así, la denuncia presentada a la Policía Nacional con fecha de 13 de
mayo de 2024.

En su segundo escrito de alegaciones señala que interpone denuncia tras conocer
por esta Agencia que se había contactado con el ciber-atacante en la fase de
investigación, momento a partir del cual pudo conocer los datos de contacto del
actor malicioso, pero lo cierto es que estos mismos datos que utilizó el inspector
para contactar con éste durante la investigación se hallaban en la primera
comunicación del INCIBE que recibió la reclamada, que además proporcionaba el
link donde poder acceder a la publicación, y sugería contactar con el ciber-
atacante.

De acuerdo con el glosario sobre ciberseguridad publicado por el INCIBE en 2021,
se entiende por ciberataque el “intento deliberado de un ciberatacante de obtener
acceso a un sistema informático sin autorización sirviéndose de diferentes
técnicas y vulnerabilidades para la realización de actividades con fines maliciosos,
como el robo de información, extorsión del propietario o simplemente daños al
sistema”.

Tal y como se ha reflejado en el hecho probado tercero, si bien en un inicio la
empresa reclamada señalaba que aunque coincidían los 17 registros de la primera
muestra contenida en el anuncio, no podía confirmar la verosimilitud del
ciberataque, tras abrirse procedimiento sancionador y recibir la copia del
expediente, la reclamada presenta tres escritos de alegaciones en los que
reconoce que ha sido víctima de un ciberataque (sobre el que considera que
no ostenta ninguna responsabilidad), por el que un tercero no autorizado ha
conseguido acceder a una de las tablas de su base de datos, produciendo una
brecha de confidencialidad de los datos personales contenidos en su plataforma,
lo que se puede considerar como un hecho reconocido y acreditado, de acuerdo a
las múltiples evidencias que constan en el hecho probado tercero de esta
propuesta.

Así pues, pese a que previamente a dictarse la propuesta de resolución era un
hecho controvertido el número de registros y afectados por el ciber ataque
(alcance de la brecha de confidencialidad producida), sí era una cuestión fuera de
toda duda que esta brecha de datos personales existió y que se produjo sobre la
tabla “***TABLA.1” aportada por CECOTEC el 24-9-24, contenida en la estructura
personalizada de la antigua plataforma de tienda online de CECOTEC que se
aportó como Anexo 2 durante la fase de prueba.

Tras la propuesta de resolución, en la que se entregó copia de la Diligencia de 14
de febrero de 2025 a la reclamada, haciendo el cotejo de coincidencias entre la
muestra2 proporcionada al inspector y la tabla ***TABLA.1 proporcionada por

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

50/173

CECOTEC, la cuestión del alcance de la brecha fue fijada en 933 personas
físicas, y ha dejado de ser una cuestión controvertida para ser un hecho
reconocido en las alegaciones a la propuesta de resolución, como más adelante
se señalará.

- Sobre la base de datos objeto del ciber ataque en la que se produjo la brecha de
confidencialidad de datos personales.

Tal y como se hace constar en el hecho probado segundo, es un hecho
reconocido que se produjo un ciber ataque que afectó a la antigua plataforma de
tienda online denominada ***SOFTWARE.1 versión 1.6, donde se hallaba
almacenada la citada tabla “***TABLA.1”.

Según manifiesta CECOTEC en su escrito de Resp#1: “La plataforma se erigía
como una tienda en línea diseñada a través del software ***SOFTWARE.1,
dedicada a la creación y gestión de tiendas virtuales para el comercio electrónico”,
“ se alojaba en la estructura de Amazon web services” y “la plataforma fue
sustituida por una nueva tienda en línea desarrollada internamente que adoptó
tecnologías de desarrollo web de código abierto más modernas (…) Esta
transición se completó a principios de 2021. A pesar del cierre de la plataforma
original, se ha mantenido un acceso limitado a la misma (***INTERFAZ.1) con el
único fin de poder atender solicitudes, necesidades y/o reclamaciones de clientes
de la empresa”.

En el escrito Resp#2, CECOTEC señala que la razón por la cual la plataforma
todavía está accesible en Internet es que todavía no se ha realizado la migración
de las integraciones de la antigua plataforma a la nueva. Manifiestan que el
***INTERFAZ.1 sigue activo por: “la necesidad de mantener integraciones activas
con nuestra nueva tienda en línea. Estas integraciones operan en modo lectura y
son esenciales para el funcionamiento de nuestro sistema por lo que actualizar la
plataforma a una versión más reciente podría generar inconvenientes en las
mismas. Además, algunas de estas integraciones siguen requiriendo que se
pueda acceder al ***INTERFAZ.1 de la plataforma desde Internet. No obstante, lo
anterior, en los próximos meses se van a realizar las gestiones técnicas oportunas
para realizar la migración de todas las integraciones de la plataforma y eliminar
por completo la exposición de la plataforma de Internet”.

La estructura base de dicha plataforma se correspondía con la versión 1.6, y ha
sido diligenciada por esta instructora con fecha 3/6/24, y la reclamada ha aportado
la estructura personalizada de la misma que estaba vigente a fecha del
ciberataque, la cual se adjunta como Anexo 2 de su primer escrito de contestación
al acuerdo de prueba de 4/7/24. Dentro de dicha estructura, se observa que existe
una tabla denominada “***TABLA.1: direcciones de clientes y pedidos” que fue
requerida y aportada por la reclamada el 24/9/24, que fue objeto del ciberataque.

- Sobre la falta de determinación del vector de entrada del ciberataque.

No se discute tampoco el hecho de que la responsable del tratamiento no ha
podido determinar cuál ha sido el vector de entrada del ciberataque. Tal y como

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

51/173

consta en el hecho probado séptimo, así fue reflejado por el informe API del
inspector, teniendo por ciertas las comprobaciones realizadas por el responsable
de ciberseguridad de CECOTEC en el correo electrónico de 14 de abril de 2023
que consta como Anexo 6 del escrito Resp#1, en el que se informaba a la DPD
de las comprobaciones realizadas para determinar la certeza y vector de entrada
del ciberataque:

“También vimos que dicho ***SOFTWARE.1 presentaba varias vulnerabilidades
de versión, pero no podemos determinar si ese es el vector de entrada”, y “Tras
analizar todos los entornos, el departamento de ciberseguridad no puede
determinar si ha sido culpa de malware en un workstation o desde el propio
aplicativo web, ya que actualmente desde el workstation no tenemos ningún
sistema de monitorización de equipos, además de no tener monitorizado el
aplicativo web”.

3.2. Hechos controvertidos del procedimiento.

Ahora bien, eran hechos controvertidos, cuya concurrencia se negaba por la
reclamada antes de dictarse propuesta de resolución, aquellos que fueron objeto de
prueba en el presente procedimiento, y que se consideran acreditados en base a lo
siguiente:

- El alcance de dicha filtración o brecha de datos personales (número de registros y
afectados por la brecha).

Reconocida y notificada la brecha, la cuestión controvertida principal del
procedimiento se centró en concretar el alcance de la brecha de datos personales
producida, toda vez que la empresa reconoció desde un inicio (en su notificación
de brecha de 19-4-23) que el ciber-ataque a su plataforma afectó a 6 personas
reales, pero negó que el ciber-atacante tuviera acceso a la totalidad de los
registros, o incluso a los 1000 que contenía la muestra que fue proporcionada por
éste al contactar con el inspector actuante. Esta cuestión se ha tratado,
principalmente, en el hecho probado cuarto de esta propuesta.

Al respecto, cabe aclarar que el acuerdo de inicio de este expediente sancionador
señaló que del análisis inicial de la documentación obrante en el expediente se
podían “extraer diversas evidencias de las que se podía desprender que el ciber-
ataque ha sido real y que existía una probabilidad muy elevada de que la brecha
de datos personales producida pueda haber afectado a más de un millón de
registros que contenía la base de datos de la empresa”. Alta probabilidad que
podía inducirse del hecho de que el actor malicioso confirmase que la base de
datos era de CECOTEC, o que dispusiera de una muestra de 1000 registros
cuyos campos y orden era exactamente coincidente con el de la tabla ***TABLA.1
que decía tener CECOTEC. Pero lo cierto es que, el acuerdo de inicio no fijó la
sanción inicial de las infracciones en base a una posible brecha de casi 1 millón
de registros o de los 1000 registros de esta muestra, sino partiendo de los 17
registros correspondientes a 6 personas reales que se habían notificado como
brecha por la reclamada, y señalando que ello se realizaba “sin perjuicio de que
de la instrucción se derivase un número mayor de afectados”.

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

52/173

Pues bien, una vez presentadas alegaciones al acuerdo de inicio, y habiendo
negado la reclamada que la brecha afectase a más de 6 personas reales
contenidos en la muestra 1 del actor malicioso (de 17 registros), la instructora
acordó practicar prueba con la finalidad de fijar el alcance de afectados por la
misma.

En fase probatoria, se dictó un primer acuerdo de prueba, tras el que se pudo
confirmar cuál era la estructura personalizada de la Plataforma ***SOFTWARE.1
versión 1.6 que estaba siendo empleada como tienda online por CECOTEC
(Anexo 2), y se requirió a la misma en un segundo acuerdo ampliatorio de prueba
para que aportase el contenido íntegro de la tabla denominada “***TABLA.1:
direcciones de clientes y pedidos” tal y como estaba reflejada a fecha del ciber-
ataque ( 5 de abril de 2023), al objeto de cotejar si eran ciertas las afirmaciones de
CECOTEC.

Contestando al acuerdo ampliatorio de prueba, CECOTEC aportó dicha tabla
***TABLA.1 el 24-9-24, la cual ha sido analizada y cotejada con la segunda
muestra de los datos obtenidos por el ciber-atacante, uniendo al procedimiento el
listado de coincidencias del 100% de los registros incluidos en ambas tablas
mediante la Diligencia de 14 de febrero de 2025, de la que se desprenden los
datos objetivos que se han hecho constar en el hecho probado cuarto de esta
propuesta.

Son especialmente relevantes para fijar el alcance de la brecha a nivel probatorio,
los siguientes datos expuestos en dicha Diligencia:

- Que el número total de registros que dice tener el actor malicioso no coincide
con el número total de registros de la tabla ***TABLA.1 de CECOTEC,
debiendo estimarse esta alegación de la reclamada.
- Pero los 1000 registros incluidos en la segunda muestra proporcionada por el
actor malicioso se corresponden íntegramente con los contenidos en la tabla
***TABLA.1, y pertenecen a un total de 933 personas físicas con DNI
verificado, coincidiendo incluso los códigos identificadores generados
automáticamente por la base de datos (id costumer, id ***TABLA.1, idcountry…
etc).

Estas evidencias obtenidas durante la fase de prueba del procedimiento son
concluyentes y acreditan, sin lugar a dudas, tal y como señala la propuesta de
resolución, que el ciber-atacante accedió a esta tabla de la base de datos de
CECOTEC, y exfiltró o extrajo de la misma un mínimo de 1000 registros, que
correspondían con los datos personales de 933 personas que han sido señalados
en el apartado 2.2 de esta propuesta, lo que ha sido reconocido por la empresa
reclamada en sus alegaciones frente a la misma.

En relación con las alegaciones realizadas frente a la propuesta de resolución,
cabe aclarar que la valoración de prueba que fue realizada por la propuesta de
resolución no declaró probado en ningún momento que el ciber atacante
dispusiera de más de un millón de registros extraídos de la citada tabla. Se
distinguieron dos situaciones:

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

53/173

o Por un lado, se señaló que concurría una alta probabilidad de que el ciber-
atacante hubiera podido acceder al 1.086.185 registros de datos que decía
tener, porque pese a que dicho número no coincide con el número de
registros totales de la tabla ***TABLA.1 (superior a 2 millones), lo cierto es
que ello no excluía la posibilidad de que hubiera accedido a todos estos
registros: “porque la extracción de un número de datos elevados como el
presente lleva un tiempo y puede verse detenido o interrumpido por varias
causas, ajenas o voluntarias, ya provenga por vía externa a través de una
inyección de SQL o ataque de malware o workstation, o por vía interna con
un código de usuario y contraseña. Por tanto, desde el punto de vista
técnico es posible y habitual que el ciberataque se interrumpiera y no
llegase a obtener la totalidad de registros contenido en dicha tabla”.

o No obstante, desde el punto de vista jurídico, la propuesta consideró que
no podía tenerse por acreditado que la brecha alcanzase el 1.086.185
registros, porque pese a existir una alta probabilidad de que así fuera, los
procedimientos sancionadores requieren prueba de cargo basada en un
grado de certeza y no de probabilidad. Por tanto, entendió que este
número de registros no se hallaba probado, puesto que no se podía
obtener una prueba de cargo concluyente al respecto de dicho número en
el presente supuesto: “dado que el ciber atacante no proporcionó una
muestra con la totalidad de registros obtenidos para su cotejo, para cuya
obtención hubiera sido necesario el previo pago del precio requerido por el
mismo. No se dispone de la totalidad de la muestra del 1.086.185
registros que el actor malicioso dice tener, por lo que no se puede
comprobar con certeza por esta Agencia que sea cierto que todos estos
datos se hallen en su poder. La prueba de cargo que se exige en un
procedimiento sancionador, cuya carga se imputa a la administración,
exige acreditar con certeza cada hecho controvertido de cargo, que
perjudique al sancionado. Y en este supuesto, existe una alta probabilidad
pero no una certeza, puesto que no se dispone de una muestra de la
totalidad de registros que el actor malicioso dice tener, por lo que no puede
cotejarse la misma con la tabla original de CECOTEC, y tenerse por
acreditado que la brecha de confidencialidad producida afectase a más de
un millón de registros. Todo ello en aplicación del Principio de Presunción
de Inocencia y el Principio in dubio Pro Reo”.

o Pero, la propuesta señaló, con buen criterio, que este no es el caso de los
1000 registros contenidos en la muestra 2 que fueron obtenidos por el
inspector, respecto de los que, como señala la propuesta: “Si se dispone
de prueba de cargo suficiente que permita afirmar con certeza que el actor
malicioso accedió a los 1000 registros que constan en la muestra 2, que
fue proporcionada al inspector. Puesto que esta Agencia dispone de dicha
muestra y de la tabla ***TABLA.1 original que ha proporcionado
CECOTEC, y ha podido cotejar y comparar los datos contenidos en
ambas”.

Pues bien, en base a esta argumentación, la propuesta consideró acreditado en el
hecho probado cuarto y sexto que el alcance de la brecha había afectado a estos

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

54/173

1000 registros, en los que se contenían los datos personales de 933 personas que
constaban identificadas, lo que ha sido reconocido por la reclamada finalmente en
su escrito de alegaciones a la propuesta de resolución, en las páginas que han
sido transcritas literalmente en el hecho probado cuarto, último párrafo. En las que
se observa que la reclamada parte de que se ha acreditado que la brecha afectó a
933 registros y solicita que la sanción se gradúe en base a los mismos,
centrándose en descartar que el ciber atacante dispusiera del 1.086.185 registros
que decía tener cuando contactó con el inspector, lo que no es una cuestión
controvertida, puesto que la propuesta ya había aclarado esta cuestión.

Por tanto, tras la presentación de alegaciones a la propuesta de resolución, cabe
afirmar con rotundidad que el alcance de la brecha está fijado en 933 personas, y
que ello es un hecho reconocido y no controvertido por la reclamada.
.
- Concurrencia de actuación culpable por parte de CECOTEC respecto a la
vulneración de confidencialidad de los datos imputada como infracción del artículo
5.1.f).

Otra cuestión controvertida principal planteada por la reclamada desde sus
alegaciones al acuerdo de inicio ha sido el hecho de que no se ha probado que el
ciber ataque fuera consecuencia de una actuación negligente/culpable de
CECOTEC. En las mismas, se señalaba que en derecho sancionador no cabe la
responsabilidad objetiva y que es preciso cumplir con el Principio de culpabilidad,
y que no se ha conseguido acreditar en este supuesto que la filtración o brecha de
datos personales producida haya sido consecuencia de una actuación negligente
de la empresa, siendo ésta víctima de un ciberataque. Y sigue manteniendo la
misma interpretación en sus alegaciones a la propuesta de resolución,
introduciendo ciertas modificaciones a las que se hará referencia al contestar las
mismas en el Fundamento de Derecho V.

Por tanto, dicha actuación culpable de CECOTEC ha sido un hecho controvertido
del procedimiento que se ha considerado probado también a través de las
evidencias que constan en el hecho probado séptimo.

Tal y como señala la reclamada es requisito para imputar una infracción
administrativa del artículo 5.1.f) del RGPD, por incumplir con el deber de mantener
la confidencialidad de los datos personales, que, además de acreditarse que ha
existido una filtración de datos personales no autorizada, se acredite que esta se
ha debido a una actuación negligente de la empresa responsable del tratamiento.
Pero, tal y como ha señalado la propuesta, el deber de confidencialidad no se
vulnera únicamente por no haber adoptado las medidas que hubieran impedido
que el ciber ataque tuviera éxito, sino también por no haber protegido la
confidencialidad de los datos personales que contenía la base de datos de origen
(en reposo), encriptándolos debidamente para evitar que el ciber ataque pudiera
conocer su contenido, por ser estos ilegibles o indescifrables sin tener la clave de
descifrado.

Al respecto, cabe señalar que cuando se señaló en la propuesta de resolución que
“cabía estimar parcialmente esta alegación” fue para admitir que pese a que en un
principio el acuerdo de inicio partió de que existían evidencias de que las

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

55/173

vulnerabilidades y estado de desprotección de la plataforma podrían haber
posibilitado el ciberataque, lo cierto es que tras negarse por la reclamada, y
practicar prueba durante la fase de instrucción, seguían concurrieron indicios pero
no una certeza que permita afirmar con rotundidad que fueran esas
vulnerabilidades y deficiencias las que permitieron el ciber ataque, puesto que no
se había acreditado cuál era el vector de entrada. Y por ello, la propuesta de
resolución determinó que estimaba esta alegación parcialmente, para determinar
cómo no probado que el nexo de causalidad de la exflitración de datos personales
que se produjo a través del ciber ataque fuera la negligencia de la reclamada.

Pero no es cierto que la propuesta de resolución reconociera también que
CECOTEC no es culpable de permitir que se vulnere la confidencialidad de los
datos personales. Puesto que lo que señaló la propuesta es que -pese a no
poderse considerar responsable del ataque o acceso indebido por no poderse
acreditare el vector de entrada-, si se había acreditado y podía considerarse que
CECOTEC era culpable por no haber cifrado los datos personales que fueron
accedidos y exfiltrados. Toda vez que el cifrado de datos personales hubiera
impedido que el ciber atacante pudiera desvelar su contenido y que se vulnerase
la confidencialidad de los mismos, no pudiendo utilizarlos ni conocer su contenido
aunque hubiera podido acceder a ellos.

Así pues, la propuesta de resolución señaló expresamente lo siguiente:

“Cabe estimar parcialmente las alegaciones realizadas por CECOTEC
respecto a que no se ha podido acreditar que la filtración fuera posible
debido a la concurrencia de las referidas vulnerabilidades y la falta de
adopción de alguna de las medidas organizativas y técnicas que hubieran
sido necesarias para impedir el acceso no autorizado a los datos en caso de
ciberataque.

Ahora bien, la reclamada no está teniendo en cuenta el hecho de que el
deber de mantener la confidencialidad de los datos personales y el de
adoptar todas las medidas organizativas y técnicas apropiadas para
garantizar la misma, no se limita únicamente a prever medidas dirigidas a
asegurar que no se producen accesos no autorizados a sus datos
personales, sino que se extiende a adoptar medidas preventivas que
impidan que dichos datos personales puedan publicarse o conocerse por
aquellos que accedan ilegítimamente a los mismos.

En otras palabras, se entiende que la diligencia exigible al responsable del
por el artículo 5.1.f) del RGPD para cumplir con su deber de
confidencialidad de los datos personales no solo se extiende al deber de
prever medidas necesarias para impedir accesos no autorizados por
terceros (como el sucedido en este ciber-ataque), sino también a establecer
medidas adecuadas de seudonimización y cifrado de los datos personales,
realizando un adecuado proceso de codificación de información para poder
evitar que esta pueda ser desvelada y llegue a personas no autorizadas.

Y esto es precisamente lo que ha sucedido en el supuesto presente, donde
la ausencia de cifrado y seudonimización de los datos personales que

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

56/173

fueron objeto del ciberataque ha quedado probada con las siguientes
evidencias:

 El hecho objetivo de que las dos muestras proporcionadas
por el ciber atacante aparecen visibles y sin codificar los
datos personales de los clientes a los que se refieren.
 Unido al hecho de que, preguntada en fase de actuaciones
previas respecto a las medidas de seguridad adoptadas en
el momento del ciberataque, ésta no haya manifestado, ni
mucho menos acreditado, que había adoptado la medida de
cifrar los datos personales de su plataforma.

Así pues, tal y como señaló el acuerdo de inicio, lo cierto es que concurren
indicios racionales de que el acceso no autorizado o el ciberataque pudo
haberse producido debido a una actuación negligente de la reclamada al
emplear una versión obsoleta y desactualizada de la plataforma, que estaba
fuera de soporte desde 2019, y adolecía de múltiples vulnerabilidades que
afectaban tanto al ***SERVICIO.2 como al ***SERVICIO.1 de la plataforma,
una de las cuales se calificaba de “crítica”, y había sido publicada en julio de
2022 por el INCIBE y boletines de alerta de ciberataques, instando a
descargarse una actualización dirigida a corregir esta vulnerabilidad e
impedir los ciberataques que se estaban produciendo, sin que ello fuera
objeto de detección y corrección por CECOTEC.

En concreto, el inspector había constatado durante la investigación que: (i)
el informe del inspector puso de manifiesto que concurrían vulnerabilidades
de versión en la plataforma compatibles con un posible vector de entrada de
la brecha, cuya responsabilidad sería negligencia de la empresa (“se ha
constatado que esta plataforma estaba basada en una versión obsoleta y
desactualizada del software ***SOFTWARE.1, con vulnerabilidades
conocidas, fuera de soporte desde el año 2019, y que disponía de la parte
de administración (***SERVICIO.1) con acceso público desde internet
(aunque restringido por usuario y contraseña)”); (ii) y expidió una Diligencia
de 2 de noviembre de 2023 haciendo constar que estas vulnerabilidades
afectaban tanto al ***SERVICIO.1 como al ***SERVICIO.2 de la plataforma
y adjuntaba capturas de pantalla que daban fe de una vulnerabilidad crítica
que se detectó el 22-7-22 en la versión 1.6 de las plataformas
***SOFTWARE.1 con servicios web.

No obstante, lo cierto es cierto que, tal y como se ha puesto de manifiesto
en el hecho probado séptimo, ni durante la investigación ni tras la
instrucción practicada, ha podido probarse que este haya sido el vector de
entrada que posibilitase al ciberdelincuente acceder a la referida base de
datos. Y fue la falta de adecuadas medidas de trazabilidad y detección de
brechas por parte de la empresa -cuyo responsable de ciberseguridad
reconoce que no ha podido determinar el vector de entrada porque la
plataforma no disponía de un sistema de monitorización e incluso había
desactivado algunos logs- impidieron que se pudiera probar que estas
vulnerabilidades fueran el nexo de causalidad que permitió acceder a la
plataforma al ciber atacante.

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

57/173

Siendo necesario el requisito de culpabilidad, no puede imputarse a la
reclamada la responsabilidad de que el ciber ataque fuera posible y llegase
a producir un acceso no autorizado del actor malicioso a los registros
contenidos en la citada tabla. Cabe dar la razón a la reclamada en este
punto. Pues la omisión de este tipo de medidas es un incumplimiento de la
obligación de establecer medidas técnicas y organizativas apropiadas para
garantizar un nivel de seguridad adecuado al riesgo que permite imputar un
incumplimiento del artículo 32 del RGPD, pero no puede justificar la
actuación negligente de la empresa respecto a la producción de la brecha o
filtración de los datos personales que requiere la imputación de la infracción
del artículo 5.1.f) del RGPD.

Ahora bien, ello no significa que no le sea imputable a la reclamada la
infracción del artículo 5.1f) del RGPD, puesto que si se acreditado que
concurrió una falta de diligencia de la misma que hubiera podido impedir
que aunque el ciber atacante hubiera accedido a los datos personales de la
plataforma, éstos no pudieran ser expuestos ni publicados ni cedidos a
terceros, si hubiera aplicado las correspondientes medidas técnicas de
cifrado que hubieran impedido que los datos personales extraídos fueran
inteligibles y descifrados. La actuación negligente de la reclamada se centra
aquí en la omisión de su deber de adoptar medidas de “seudonimización y
el cifrado de datos personales”, lo que constituía una medida técnica para
proteger la confidencialidad de los datos, según el artículo 32.1. a) del
RGPD, que debió aplicarse el presente tratamiento por sus características,
número de interesados, número de datos personales, acceso directo por
internet, falta de actualización y soporte...etcy que no fue adoptada.

Así pues, se considera que concurre una actuación negligente de la
empresa, puesto que la misma: (i) no es culpable de haber permitido que el
ciberdelicuente accediera y extrajera sus datos personales; (ii) sino que es
culpable de no haber aplicado a la tabla ***TABLA.1 de dicha plataforma las
medidas de cifrado y seudonimización de los datos personales contenidos
en la misma, que hubieran impedido que el ciber-atacante pudiera conocer,
desvelar ni publicar o transferir a terceros el contenido de dichos datos.

Y en este segundo aspecto del deber de confidencialidad, si existe una
actuación negligente cuya responsabilidad es de la empresa, por lo que
cabe mantener la infracción del artículo 5.1.f) del RGPD, siendo culpable la
empresa de la vulneración de confidencialidad, no porque el ciberatacante
haya podido acceder a los datos personales contenidos en su plataforma,
sino porque la empresa no había aplicado sobre los mismos los necesarios
procesos de cifrado y seudonimización de datos personales, y este
incumplimiento ha permitido que al acceder pueda visualizar y conocer el
contenido de los mismos”.

Por último, cabe añadir que en las alegaciones a la propuesta de resolución
CECOTEC señala que en el escrito de 30 de agosto de 2023 acreditó que sí se
habían adoptado dos medidas de cifrado sobre la plataforma, pero que no se ha
considerado probado en el hecho séptimo que se hubieran cifrado los datos

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

58/173

personales que constaban en la base de datos “en reposo” que se encontraba
alojada en los servidores de la reclamada, por los motivos que se exponen a
continuación:

La reclamada afirma que ya había acreditado anteriormente que se habían
adoptado dos medidas de encriptación de los datos de la plataforma:

 (…).

En el citado escrito aportado el 30 de agosto de 2023, la reclamada
afirma que utilizaban la plataforma AWS como infraestructura, para alojar
la base de datos hacían uso del servicio Amazon RDS, que se refiere a
las copias de seguridad de la base de datos de la plataforma. No se
hace referencia expresa a que Amazon RDS encripte las copias de
seguridad ni se aporta la documentación que lo acredite. Por tanto, no
es cierto que este hecho conste acreditado, dado que el servicio de
Amazon RDS no cifra por defecto las copias de seguridad de las bases
de datos, sino que ello hay que configurarlo expresamente en el
momento de crear la instancia de la base de datos, y la reclamada no ha
acreditado que haya realizado dicha configuración para encriptar las
copias de seguridad.

Ahora bien, aún en el caso de que se aportase acreditación y fuera
cierto que se están encriptando las copias de seguridad de las bases de
datos, ello sería una medida de seguridad adicional al cifrado de la
propia base de datos original o “en reposo”, que debe también realizarse
y es esencial, puesto que en este caso el ciber ataque no se ha
producido respecto a las copias de seguridad almacenadas en Amazon
RDS, sino que se ha dirigido directamente a los datos contenidos en la
base de datos o plataforma ***SOFTWARE.1, que se almacenan en los
servidores de la empresa, los cuales consta acreditado que no se
hallaban cifrados ni seudononimizados, dado que ambas muestras
proporcionadas por el ciber atacante muestran los mismos de forma
visible e inteligible.

 La comunicación entre los dispositivos de acceso y la plataforma
estaba cifrada mediante TLS 1.2. o superior, lo que aseguraba la
protección de datos en tránsito.

Tampoco se aporta acreditación, si bien es cierto que la utilización de
este protocolo de comunicación TLS 1.2 permite que cuando se
producen transmisiones de datos personales desde uno de los
dispositivos con acceso a la base de datos de origen o en reposo hasta
un dispositivo de destino, los datos personales “en tránsito” se
transfieran por un canal cifrado, lo que protege a los datos personales
únicamente cuando están siendo transmitidos.

Pero si no se halla cifrada la base de datos personales en reposo (que
se remite), el cifrado dura mientras se transmite el mensaje y queda
descifrado de nuevo cuando llega al punto de destino. Por tanto, si los

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

59/173

datos almacenados en reposo no están cifrados, cifrar el canal de
transmisión es una medida de seguridad adicional que no garantiza la
confidencialidad de los datos puesto que el dispositivo que recibe el
mensaje al otro lado los obtendrá en el mismo estado que se hallaba la
base de datos original.

En definitiva, no cabe tener por acreditado que la reclamada hubiera adoptado
medidas de cifrado sobre la base de datos en reposo que contenía los datos
personales que fueron exfiltrados, toda vez que, aunque fuera cierto que la
reclamada hubiera adoptado estas medidas, las mismas no serían medidas de
cifrado de la base de datos en reposo, sino que se refieren al cifrado de las
copias de seguridad que se alojan en Amazon Web Services, o al protocolo de
comunicación entre dispositivos en los supuestos en los que se transfiere la
información, lo que no sustituye en ningún caso al hecho de tener que adoptar las
medidas de cifrado principales, que se deben aplicar a la propia base de datos
activa donde se contienen los datos personales, lo que no se acredita en este
supuesto.

Por tanto, y habiendo quedado expuestos y visibles todos los datos personales en
las dos muestras obtenidas del ciber atacante, se deduce sin lugar a dudas que el
cifrado de los datos personales contenido en la base de datos en reposo dentro de
los servidores de la reclamada no se había aplicado, puesto que de lo contrario el
ciber atacante no hubiera podido descifrar los datos personales contenidos en la
misma.

Se entiende, por tanto, acreditada la culpabilidad de la reclamada, siendo el nexo
de causalidad de la brecha de confidencialidad de los datos personales accedidos
y exflitrados por el ciber atacante la falta de adopción de las medidas de cifrado y
seudonimización sobre la base de datos original o en reposo donde se hallaban
almacenados los datos personales afectados, cuya encriptación hubiera impedido
que el ciber atacante pudiera conocer el contenido de estos datos y utilizarlo,
como lo ha hecho.

- Sobre las vulnerabilidades y deficiencias de la plataforma ***SOFTWARE.1 a
fecha del ciberataque.

En su escrito de alegaciones frente a la propuesta de resolución de 18 de marzo
de 2025 CECOTEC no formula alegaciones que cuestionen la concurrencia de los
hechos probados en relación con las vulnerabilidades y deficiencias de la
plataforma en la que se alojaban los datos personales objeto del ciber ataque, ni
aportado documentación nueva al respecto (más allá de las dos medidas de
cifrado a las que ya se ha hecho referencia), sino que se limita a plantear
cuestiones de cariz jurídico que se contestarán en el Fundamento de Derecho V
de esta Propuesta.

Por tanto, se tienen por acreditados los hechos probados que se han hecho
constar en el hecho probado octavo, en base a las razones que se hacen constar
en la propuesta de resolución, que se transcriben a continuación.

<<La existencia de vulnerabilidades de la versión de la plataforma que se

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

60/173

empleaba a fecha del ciberataque fue reconocida desde el primer escrito de
respuesta de CECOTEC, que aportó en su Anexo 6 el correo electrónico remitido
al DPD por el propio Director de seguridad de CECOTEC en su correo de 14 de
abril de 2023. Y éstas fueron aportadas por el primer escrito de respuesta de
investigación.

En este correo, el Director de Ciberseguridad de CECOTEC, manifiesta que no
puede determinar con claridad el vector de entrada del ciberataque, por no tener
ningún sistema de monitorización de equipos en la plataforma atacada, haber
desactivado los logs, y reconoce que la plataforma adolecía de vulnerabilidades:

“Tras realizar el análisis de los registros de la imagen publicada en el
foro se vio que coinciden con los de la tienda antigua de la empresa
(…) que se cerró en 2021 pero se sigue usando por algunas personas
en modo consulta”.

También intentamos ver los logs para ver la trazabilidad y destapar al
atacante, pero no pudimos sacar nada en claro ya que solo mostraban
los inicios de sesión de los usuarios, además en su día por temas de
rendimiento se desactivaron algunos logs. A nivel servidor y base de
datos no pudimos ver mucho ya que no se estaba monitorizando.
También vimos que dicho ***SOFTWARE.1 presentaba varias
vulnerabilidades de versión, pero no podemos determinar si ese era el
vector de entrada”.
“Tras analizar todos los entornos, el departamento de ciberseguridad no
puede determinar si ha sido culpa de malware en un workstation o
desde el propio aplicativo web, ya que actualmente desde el
workstation no tenemos ningún sistema de monitorización de equipos,
además de no tener monitorizado el aplicativo web”.

No obstante, en el segundo escrito de respuesta al requerimiento de investigación
CECOTEC niega o modula la concurrencia de alguna de estas vulnerabilidades o
deficiencias detectadas a fecha del ciberataque, señalando que había adoptado
medidas de seguridad sobre la misma, y aportando documentación. Y en sus
escritos de alegaciones al acuerdo de inicio no aporta nueva documentación
referente a las medidas adoptadas, pero sí solicita que las mismas se consideren
como atenuante.

Tal y como se hace constar en el hecho probado octavo de esta propuesta, una
vez examinada la documentación aportada, y las propias manifestaciones de la
reclamada, cabe señalar que ha quedado acreditado que a fecha de la brecha o
ciberataque (5 de abril de 2023) la plataforma ***SOFTWARE.1 adolecía de las
siguientes vulnerabilidades y deficiencias:

1. En relación con las “vulnerabilidades de versión” de la Plataforma,

Según el Glosario de Ciberseguridad publicado por INCIBE, se entiende por
“vulnerabilidad la debilidad o fallo de un sistema que puede ser aprovechado
con fines maliciosos (normalmente mediante un programa que se denomina

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

61/173

exploit). Cuando se descubre, el desarrollador del software o hardware lo
solucionará publicando una actualización de seguridad del producto”.

CECOTEC reconoce su concurrencia en su primer escrito de respuesta, por
ponerlo así de manifiesto el responsable de ciberseguridad en el citado correo
electrónico de 14 de abril de 2024, pero en su segundo escrito de respuesta
señala que afectaban solo a su ***SERVICIO.2, que no estaba activo, y no al
***SERVICIO.1 que sí estaba activo y con acceso directo a internet.

Para comprobar este hecho controvertido concreto, el inspector del
procedimiento accedió a la url de la plataforma que había sido proporcionada
por la reclamada, y expidió diligencia de 2 de noviembre de 2023, haciendo
constar lo siguiente:

(i) La versión 1.6.1 de ***SOFTWARE.1, pertenece a una versión
desactualizada, fuera de soporte desde el año 2019 y con múltiples
vulnerabilidades críticas que afectaban tanto a ***SERVICIO.2
(interfaz de usuario) como al ***SERVICIO.1 (…).
(ii) Esta plataforma, pese a ser antigua y estar en proceso de migración,
se mantenía activa disponiendo de acceso directo desde internet con
código de usuario y contraseña, aun a fecha de 2 de noviembre de
2023. Aun cuando la empresa manifiesta que dicho acceso era a la
parte de ***SERVICIO.1 (afirman que esto era necesario por requisitos
de integración con la nueva plataforma implantada), y señala hallarse
pendiente de ejecutar un proceso de migración de los datos a la nueva
plataforma.

Se adjuntan a dicha diligencia por el inspector capturas de pantalla donde se
hace constar:

(i) Un aviso de vulnerabilidad de la plataforma ***SOFTWARE.1
publicado el 26/07/22 en la página del INCIBE en el que consta que
“***SOFTWARE.1 ha publicado una actualización de seguridad que
corrige una vulnerabilidad crítica por lo que se recomienda actualizar
la última versión disponible cuanto antes”, la cual afecta precisamente
a la versión 1.6, utilizada por CECOTEC.
(ii) Publicación en la página del boletín de noticias sobre ciberseguridad
“Hispasec Una al día”, donde aparece este mismo aviso sobre:
“Atacantes explotan activamente vulnerabilidad de RCE en el CMS
***SOFTWARE.1 de 28 julio, 2022. Ciberdelincuentes encuentran la
manera de utilizar una vulnerabilidad de inyección de SQL para
ejecutar código remoto en servidores que contienen servicios web de
***SOFTWARE.1”
(iii) Publicación del anuncio de ***SOFTWARE.1 de que la Plataforma iba
a quedar fuera de soporte a partir de 2019.

Por este motivo, queda fijado en el hecho probado octavo de esta propuesta
que:

(i) Las vulnerabilidades o falta de medidas preventivas detectadas a
fecha del ciberataque afectaban tanto al ***SERVICIO.1 como al
***SERVICIO.2 de la plataforma.

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

62/173

(ii) Que la plataforma quedó fuera de soporte desde 2019.
(iii) Y además, que el 26 julio de 2022 se había publicado en la web de
***SOFTWARE.1 un aviso de una vulnerabilidad producida en la
misma versión de plataforma ***SOFTWARE.1 utilizada por
CECOTEC mediante la que los ciberdelincuentes estaban accediendo
a servidores que contenían servicios web de esta plataforma a través
de una inyección de SQL, por lo que era necesario obtener la
actualización que fue publicada por ***SOFTWARE.1 al objeto de
corregir la misma. Habiendo reconocido CECOTEC que no había
actualizado la plataforma desde 2019.

2. En segundo lugar, en su segundo escrito de respuesta CECOTEC plantea
como controvertido el hecho de que existieran medidas de trazabilidad
previas en la plataforma, puesto que CECOTEC mantiene en su escrito
Resp#1 que a fecha del ciberataque: “antes de recibir la notificación por parte
de INCIBE, la plataforma ya tenía medidas sólidas implementadas para
garantizar la trazabilidad de las acciones en los accesos tanto a la plataforma
como al sistema de gestión de la base de datos. Estas medidas fueron
diseñadas para garantizar la seguridad y la integridad de los datos, así como
para detectar cualquier actividad sospechosa de manera temprana”.

En lo referente al sistema gestión de base de datos se dice que existían
medidas de restricción de acceso directo desde internet y logs de
monitorización de accesos y actividad en la base de datos, pero éstos no se
detallan ni acreditan en ningún escrito. Ni tampoco aportan acreditación de las
medidas de trazabilidad presuntamente adoptadas antes del ciberataque, sino
de las adoptadas posteriormente a éste.

Por tanto, no habiéndose aportado acreditación de otras medidas adoptadas
previamente al ciberataque, debe tenerse por acreditado que no se habían
adoptado las medidas adecuadas de trazabilidad en la plataforma a fecha de
producirse la brecha, a la vista de que:

- El correo remitido por el responsable de ciberseguridad que analizó la
plataforma con fecha de 14 de abril de 2023 reconoció lo siguiente:
“Intentamos ver los Logs para ver la trazabilidad y destapar al atacante, pero no
pudimos sacar nada en claro, ya que vimos los logs del ***SOFTWARE.1 y no eran de
gran utilidad ya que solo mostraban los inicios de sesión de los usuarios, además en
su día por temas de rendimiento se desactivaron algunos logs que registraba el CMS
y que no se volvieron a activar posteriormente”.

- Además, el escrito Resp#1 de CECOTEC reconoce que la plataforma no
disponía de las medidas de seguridad apropiadas en relación con el control de
acceso de los usuarios de la plataforma, señalando que:

“(...)”

3. Sobre la falta actualización del análisis de riesgos de la plataforma.

Al respecto, tal y como hace constar Informe API punto 8: “ha quedado
acreditado la existencia de análisis documentado realizado en la fecha 10 de

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

63/173

abril de 2022. La empresa confirma que no constan análisis de riesgos con
fecha anterior a la anteriormente indicada, no obstante, ha quedado constado
que la actividad de tratamiento afectada por la brecha se inicia en el año 2013
(“Gestión de Clientes”).

Ello queda fijado dado que en el escrito de Resp#1 CECOTEC aporta un AR de
10-4-22, y en Resp#2 confirma que no realizaron ninguno anteriormente,
señalan que la plataforma estaba en funcionamiento desde 2013, y aportan dos
actualizaciones realizadas sin firmar de 2022 y de 2023, y se reconoce que la
empresa se halla inserta en un proceso de revisión de documentos y decisión
de medidas a tomar: “Se informa a la AEPD que, en el último año el puesto de
Delegado de Protección de Datos ha sido ocupado por tres personas distintas, no
habiendo una continuidad en las funciones del Delegado de Protección de Datos
especificadas en el artículo 39 del Reglamento 2016/679 de 27 de abril de 2016 (en
adelante, “RGPD”). Es por ello por lo que, actualmente, la empresa se encuentra en un
proceso de revisión urgente de documentos y de decisión de medidas a tomar y de
procedimientos a implementar, entre los que se encuentra la revisión de todos los
análisis de riesgos realizados y la valoración de la necesidad de realizar una
evaluación de impacto de los mismos”.

Sobre la falta de aplicación de un adecuado Protocolo de detección y gestión
de brechas de datos personales.

Consta acreditado también que la empresa no adoptó las medidas necesarias
para asegurar la aplicación de un Protocolo de gestión de brechas, puesto que:

(i) El escrito Resp#1 se aporta un documento interno denominado
“Protocolo de gestión de incidentes de seguridad” que no contiene
firma, fechado el 22 de abril de 2021. No constan en el mismo los datos
de contacto de las personas a las que se debía comunicar las alertas de
incidente de ciberseguridad y las encargadas de detectar y notificar la
brecha. Y además, no consta que el mismo fuera comunicado al
personal de la empresa con anterioridad a la brecha.

(i) Al requerirse la aportación de la “actualización de 2022” citada por la
reclamada, ésta aporta en la Resp#2, un Protocolo de Gestión de
Brechas de Seguridad, que no está firmado y está fechado con
posterioridad a la producción y detección de la brecha ( “Fecha de
última actualización 29 de agosto de 2023”). Protocolo que se considera
adoptado como medida correctiva pero que no existía como medida
preventiva en el momento en que se produjo la brecha de
confidencialidad a la que se refiere el presente expediente, tal y como lo
confirman los hechos, y las propias afirmaciones contenidas en este
mismo escrito Resp#2:

5. Falta de aplicación de medidas de cifrado de los datos personales contenidos
en la base de datos donde se produjo la brecha de confidencialidad.

Del hecho probado séptimo se deduce, como ya se ha dicho, del contenido de
la muestra publicada en el anuncio (que enmascaró el nombre y apellidos,
publicando y dejando expuestos el resto de datos personales contenidos en la

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

64/173

tabla), y del incluido en la muestra proporcionada por el actor malicioso al
inspector el 4 de agosto de 2023, en la que aparecen visibles y sin enmascarar
los 24 campos contenidos en la tabla ***TABLA.1 que fue objeto del
ciberataque, se deduce que CECOTEC no había adoptado tampoco la medida
esencial de seudonimización y el cifrado de datos personales que contenía
dicha tabla ***TABLA.1. Lo que se corrobora por el hecho de que CECOTEC
no mencione el cifrado y seudonimización entre las medidas adoptadas sobre
los datos contenidos en la plataforma.

No obstante, como se ha aclarado anteriormente, el incumplimiento imputable
por no adoptar este tipo de medidas no debe ser considerado para valorar la
infracción del artículo 32 del RGPD, sino la del artículo 5.1.f) del RGPD.

- Respecto a las medidas preventivas adoptadas en la plataforma antes de la
brecha producida.

En su escrito de alegaciones frente a la propuesta de resolución de 18 de
marzo de 2025 CECOTEC no formula alegaciones que cuestionen la
concurrencia de los hechos probados en relación con las medidas preventivas
adoptadas en la plataforma en la que se alojaban los datos personales objeto
del ciber ataque, ni aportado documentación nueva al respecto (más allá de las
dos medidas de cifrado a las que ya se ha hecho referencia), sino que se limita
a plantear cuestiones de cariz jurídico que se contestarán en el Fundamento de
Derecho V de esta Propuesta.

Por tanto, se tienen por acreditados los hechos probados que se han hecho
constar en el hecho probado octavo, en base a las razones que se hacen
constar en la propuesta de resolución, que se transcriben a continuación.

A la luz de la documentación aportada al procedimiento, se tiene por
acreditado que a fecha del ciberataque la plataforma disponía de las
siguientes medidas preventivas implantadas que se hicieron constar en el
informe API que se deducen de la documentación que fue aportada en el
escrito Resp#1:

o (…)
- Respecto a las medidas correctivas adoptadas en la plataforma después de la
brecha producida.

En su escrito de alegaciones frente a la propuesta de resolución de 18 de
marzo de 2025 CECOTEC no formula alegaciones que cuestionen las
medidas correctivas adoptadas sobre la plataforma tras el ciber ataque que se
consideraron probadas en el hecho probado noveno, ni se ha aportado
documentación nueva al respecto (más allá de las dos medidas de cifrado a
las que ya se ha hecho referencia), sino que se limita a plantear cuestiones
de cariz jurídico que se contestarán en el Fundamento de Derecho V de esta
Propuesta.

Por tanto, se tienen por acreditados los hechos probados que se han hecho
constar en el hecho probado novena, en base a las razones que se hacen

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

65/173

constar en la propuesta de resolución, que se transcriben a continuación.

<<Durante la fase de investigación de este expediente CECOTEC afirmó
haber adoptado medidas correctivas de las deficiencias observadas en la
plataforma ***SOFTWARE.1 una vez tuvo conocimiento del ciberataque,
aportando parte de la documentación justificativa de las mismas, que fue
tenida en cuenta por el inspector al emitir su informe, declarándolas
acreditadas en la conclusión séptima del mismo.

Posteriormente, en su primer escrito de alegaciones al acuerdo de inicio,
CECOTEC solicita que se consideren como atenuante, realizando una
enumeración de medidas correctivas diferente a la realizada hasta el
momento en los escritos previos, que no se acompaña de soporte
documental. En concreto, se señala lo siguiente:

“Habiéndose adoptado medidas correctivas ya comunicadas a la
AEPD durante toda la fase de investigaciones previas sin ser
requeridas por la AEPD procedería su graduación y atenuación. A
continuación, se describen las medias adoptadas con posterioridad y
que han sido comunicadas a la AEPD:
1. Medidas dirigidas a aumentar la concienciación de los empleados:
• Formaciones, campañas y simulacros de phishing.
• Correos electrónicos
Evidencia: Informes de formación en materia de protección de datos
2. Medidas de seguridad respecto a la plataforma:
• (…)
3. Identificación y Evaluación Riesgos Legales Identificación y
Evaluación de Brechas de Seguridad
Evidencia: Doc. Excel de análisis de riesgos
4. Definición de los plazos de conservación de la información.
5. Implantación de mecanismos que regulen y verifiquen la idoneidad y
cumplimiento de las obligaciones por parte de los encargados del
tratamiento.
6. (…)
8. Creación de un protocolo de brechas de seguridad dirigido a los
empleados.
9. (…)
10. Se ha constituido un Comité de Seguridad formado por el delegado
de protección de datos, el Responsable de Ciberseguridad, la
Responsable del Departamento Legal, el Responsable del
Departamento de IT, el Responsable de Tecnología de CECOTEC y un
miembro del Departamento de IT; con el objeto de (…)
Evidencia: Cecotec cuenta con un Reglamento del Comité de
Seguridad.”

En dichas alegaciones frente al acuerdo de inicio, CECOTEC realizó una
enumeración de medidas correctivas cuya adopción no puede tenerse por
acreditada, dado que: (i) incluye las medidas preventivas que se habían

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

66/173

adoptado antes de la brecha según había sido acreditado en la fase de
investigación, que no pueden considerarse como correctivas; (ii) se mencionan
medidas nuevas pero no se aporta ninguna documentación acreditativa de las
mismas (iii) y tampoco se referencia a las fechas en las que fue adoptada cada
una de las medidas relacionadas, al objeto de que se pueda comprobar por
esta administración si éstas podrían ser consideradas como atenuante por
adoptarse con anterioridad a tener conocimiento de que se había iniciado una
investigación al respecto, como alega la reclamada.

En consecuencia, se considera que ha sido acreditada la adopción de las
siguientes medidas correctivas que se hacen constar en el hecho probado
octavo:

- Las alegadas en los escritos de respuesta durante la fase de
investigación, cuya acreditación fue comprobada por el inspector,
haciendo constar en la conclusión de su informe lo siguiente:

“Tras detectar la brecha de seguridad se adoptaron las siguientes
medidas reactivas para fortalecer la seguridad de la plataforma:
 (…)

- Con posterioridad al acuerdo de inicio, se ha procedido a deshabilitar el
acceso a la plataforma desde internet.

En su escrito AlegAI#1 la reclamada manifiesta haber deshabilitado el
acceso a la plataforma ***SOFTWARE.1 desde internet, lo que ha podido
ser comprobado por esta instructora mediante Diligencia de 3 de junio de
2024, por lo que se tiene por acreditada esta medida correctiva por
CECOTEC con posterioridad al inicio del procedimiento sancionador.

Queda constatado también, que la plataforma se mantuvo accesible a
internet hasta, al menos, el 2 de noviembre de 2023, fecha en la que el
inspector emitió diligencia haciendo constar que: “el acceso a la URL
***URL.1 sigue estando disponible, accediéndose al ***SERVICIO.1 de la
instalación del software ***SOFTWARE.1”. Habiendo reconocido
CECOTEC en su Resp#2 de CECOTEC, que: “La razón por la cual la
plataforma todavía está accesible en Internet radica en la necesidad de
mantener integraciones activas con nuestra nueva tienda en línea. Estas
integraciones operan en modo lectura y son esenciales para el
funcionamiento de nuestro sistema por lo que actualizar la plataforma a
una versión más reciente podría generar inconvenientes en las mismas.
Además, algunas de estas integraciones siguen requiriendo que se
pueda acceder al ***INTERFAZ.1 de la plataforma desde Internet. No
obstante lo anterior, en los próximos meses se van a realizar las
gestiones técnicas oportunas para realizarla migración de todas las

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

67/173

integraciones dela plataforma y eliminar por completo la exposición de la
plataforma de Internet.”>>

IV
Contestación a las alegaciones al acuerdo de inicio

Antes de dictarse propuesta de resolución del expediente, la empresa reclamada ha
presentado diversos escritos de alegaciones contestando al acuerdo de inicio y a los
dos acuerdos de prueba dictados en el presente procedimiento:

- Alegaciones al acuerdo de inicio presentado el 25-4-24, antes de recibir la
copia del expediente (AlegAI#1). En la que se relacionan diversos motivos de
alegación, sin aportar documentación anexa alguna.

- Alegaciones complementarias presentado el 8-5-24, tras recibir la copia del
expediente (AlegAI#2). Donde no se aporta documentación, anunciándose la
interposición de una denuncia penal por haber sido víctima de un ciber-ataque,
que se adjunta posteriormente, mediante escrito de 13-5-24 (Doc AlegAI#2).

Al valorar la prueba la propuesta de resolución del expediente contestó en el
Fundamento de Derecho III a las alegaciones formuladas en los dos escritos
presentados al contestar a los acuerdos de prueba realizados, dedicando el
Fundamento de Derecho IV a la contestación de los dos escritos de alegaciones al
acuerdo de inicio, cuyo razonamiento se comparte íntegramente por esta Agencia y se
transcribe a continuación:

<<4.1. Contestación del primer escrito de alegaciones frente al acuerdo de inicio.

Con fecha de 25-4-24, antes de recibir la copia del expediente solicitada y transcurrir el
plazo de alegaciones, la reclamada formuló las alegaciones principales del
procedimiento con carácter preventivo (AlegAI#1), añadiendo en el segundo escrito de
alegaciones las relacionadas con los documentos que se contenían en la copia del
expediente.

Este primer escrito de alegaciones al acuerdo de inicio no adjunta documentación
alguna, y solicita el archivo del expediente y apertura de nuevo plazo de alegaciones,
manifestando, en base a una alegación previa y seis alegaciones.

A continuación, se exponen los motivos por los que deben entenderse desestimadas
las alegaciones, a la vista de los hechos probados que se han puesto de manifiesto
durante la instrucción y la normativa aplicable que es objeto de enjuiciamiento:

o PREVIA. VULNERACIÓN DEL PROCEDIMIENTO LEGALMENTE
ESTABLECIDO. INFRACCIÓN DEL ART. 24 CE.

La reclamada pone de manifiesto no haber recibido la copia del expediente en

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

68/173

el momento en que presentó las alegaciones (25-4-24) alegando que se
produce indefensión al no disponer de la misma, constitutiva de nulidad de
pleno derecho por carencia absoluta del procedimiento. Y en virtud de ello,
mediante “OTROSIDIGO PRIMERO” formulan se abra plazo alegaciones
complementarias.

Se entiende que no ha existido vulneración del procedimiento establecido, ni del
derecho de defensa del artículo 24 del CE, toda vez que cuando la reclamada
presentó este escrito de alegaciones le había sido notificada electrónicamente
la ampliación de plazo y remisión de copia del expediente de 17 de abril de
2024 en la dirección electrónica habilitada (que fue recogida el 18-4-24), si bien
estaba pendiente de entrega la copia del expediente, respecto a la que se
advertía que por su tamaño no podía remitirse electrónicamente, sino en la
dirección postal designada a efectos de notificaciones, lo que no se produjo
hasta el 30 de abril de 2024.

Por tanto, cuando se presentaron estas primeras alegaciones todavía no había
vencido el plazo de alegaciones, estando su cómputo interrumpido hasta la
entrega de la copia del expediente. Todo ello fue aclarado expresamente a la
reclamada en el escrito aclaratorio del acuerdo de ampliación de plazo y
entrega de copia de 30 de abril de 2024, unido a este procedimiento. En el que,
para tranquilidad de la misma, se indicó expresamente:
“Se hace constar que el plazo de alegaciones frente al acuerdo de inicio
finalizará, una vez transcurridos 5 días hábiles desde la notificación del
acuerdo de ampliación y entrega de copia, que se ha realizado por vía
postal en el día de hoy. Por lo que, sin perjuicio de que se tengan por
puestas las alegaciones presentadas con fecha de 25 de abril de 2023,
se aclara que podrá presentar escrito de alegaciones frente al acuerdo
de inicio dentro de dicho plazo”.

No habiendo transcurrido pues dicho plazo cuando la reclamada decidió
presentar las alegaciones referidas, y habiendo formulado unas nuevas con
fecha de 8 de mayo de 2024, una vez recibió la copia solicitada, se entiende,
además, que no se ha generado indefensión a la misma, dado que además de
haber sido concedida la ampliación del plazo de alegaciones y computado el
plazo de la forma más favorable a ésta, así como aclarado que podía presentar
alegaciones complementarias tras recibir la copia del expediente, la reclamada
ha presentado las mismas, y éstas han sido admitidas y se tienen en cuenta en
la presente propuesta de resolución.

o PRIMERA.- VULNERACIÓN DEL PRINCIPIO NE BIS IN IDEM POR
SANCIONAR DOS VECES LA MISMA CONDUCTA RESPECTO A LAS
INFRACCIONES CONTEMPLADAS EN LOS ART. 5.1. F) Y ART. 32 DEL
RGPD.
CECOTEC muestra su disconformidad respecto a la tipificación de los hechos

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

69/173

realizada por la AEPD en al ámbito del art. 5.1. f) y del art. 32 del RGPD, puesto
que, a su juicio, ello implica sancionar dos veces la misma conducta, en base a
lo siguiente:

o Conforme a las Directrices 04/2022 del European Data Protection
Board, o Comité Europeo de Protección de Datos (en adelante,
“CEPD”) sobre el cálculo de las multas bajo el RGPD (en adelante,
Directrices 04/22 CEPD), las disposiciones invocadas por la AEPD en
el presente expediente sancionador protegerían el mismo interés
jurídico, esto es, la seguridad adecuada de los datos personales,
siendo ilegal sancionar dos veces al infractor por la misma ofensa. En
este sentido, se cita la Sentencia ‘Austrian Verwaltungsgerichtshof’, Ra
2018/02/1023, apartado 7. Seguidamente, CECOTEC continúa
señalando que: “En el presente supuesto, el interés jurídico protegido
(la confidencialidad de los datos) es el mismo. La AEPD centra ambas
infracciones en que no se han adoptado medidas de seguridad
técnicas y organizativas adecuadas, lo que ha afectado a la capacidad
de garantizar la confidencialidad”, lo que implica vulnerar, según las
Directrices del CEPD “el ‘principio de consumo’ o que una infracción es
un paso previo a la otra.”

o Asimismo, existiría, a juicio de esta parte, una vulneración del principio
‘non bis in idem’, conforme el criterio de la Audiencia Nacional (por
todas: Sentencia de la Audiencia Nacional de 23 de julio de 2021 (rec.
1/2017). Se cita también el Auto del Tribunal Supremo (Contencioso),
sec. 1ª, A 13-07-2023, rec. 3120/2023.
o Por último, se alega la aplicación de la sanción que se contiene para los
supuestos de concurso medial de infracciones en el artículo 29 de la Ley
40/2015, de 1 de octubre, de Régimen Jurídico del Sector Público (en
adelante, la “LRJSP”): 5. Cuando de la comisión de una infracción derive
necesariamente la comisión de otra u otras, se deberá imponer
únicamente la sanción correspondiente a la infracción más grave
cometida.

En primer lugar, cabe señalar que las tres vulneraciones alegadas la
reclamada se están refiriendo al posible incumplimiento del mismo principio,
que es el “Principio Principio Ne is idem” recogido en el artículo 9.3 de la
Constitución, que establece como regla general que no podrá sancionarse
dos veces una misma conducta; cuya manifestación en el ámbito
sancionador dentro del ordenamiento jurídico español se encuentra en el
artículo 31 de la LRJSP. Y por último, el citado artículo 29 de la LRJSP,
establece una regla para imponer la sanción más grave en caso de que
concurra lo que doctrinalmente se denomina como concurso medial de
infracciones, siendo el “Principio especialidad, subsidiariedad o consumo” al

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

70/173

que se refieren las Directrices 04/2022 del CEPD sobre guía de cálculo de
multas una de las reglas aplicables para resolver los concursos de ofensas.

Las Directrices 04/2022 del CEPD (Guía de multas) que son citadas por la
reclamada, trasladan la teoría general sobre las reglas de concurso real,
medial o ideal de infracciones aplicables en derecho administrativo
sancionador español a la terminología empleada por el RGPD en materia de
protección de datos, distinguiendo 3 tipos de situaciones en su apartado 3.1:

“3.1 — Una conducta sancionable
25. Como primer paso, es esencial determinar si existe una misma conducta
sancionable («idem») o múltiples para identificar el comportamiento
sancionable pertinente que debe ser multado. Por lo tanto, es importante
entender qué circunstancias se consideran como una y la misma conducta,
en lugar de múltiples conductas. El comportamiento sancionable pertinente
debe evaluarse e identificarse caso por caso.. (…)
29. Si se demuestra que las circunstancias del asunto constituyen un mismo
comportamiento y dan lugar a una infracción única, la multa puede
calcularse sobre la base de dicha infracción y de su máximo legal. Sin
embargo, si las circunstancias del asunto constituyen un mismo
comportamiento, pero este comportamiento da lugar no solo a una, sino a
múltiples infracciones, debe determinarse si la imputación de una infracción
excluye la atribución de otra infracción (capítulo 3.1.1) o si pueden
imputarse entre sí (capítulo 3.1.2). Cuando las circunstancias del caso
formen conductas múltiples, se considerarán una pluralidad de acciones y
se tratarán de conformidad con el capítulo 3.2.
3.1.1. Concurrencia de ofensas
30. El principio de concurrencia de delitos (también denominado «aparente
concurrencia» (Véase, por ejemplo, la sentencia Austrian
Verwaltungsgerichtshof, Ra 2018/02/0123, apartado 9) o «falsa
concurrencia») se aplica siempre que la aplicación de una disposición
impida o subsuma la aplicabilidad de la otra. En otras palabras, la
concurrencia ya se produce en el nivel abstracto de las disposiciones
legales. Esto podría deberse al principio de especialidad, subsidiariedad o
consumo, que a menudo se aplica cuando las disposiciones protegen el
mismo interés jurídico. En tales casos, sería ilegal sancionar dos veces al
infractor por la misma ofensa.
En tal caso de concurrencia de infracciones, el importe de la multa solo
debe calcularse sobre la base de la infracción seleccionada con arreglo a
las normas anteriores (superposición a la infracción)”
“Principio de especialidad
32. El principio de especialidad (especialia generalibus derogant) es un
principio jurídico que significa que una disposición más específica (derivada
del mismo acto jurídico o de diferentes actos jurídicos de la misma fuerza)
sustituye a una disposición más general, aunque ambas persiguen el mismo
objetivo. La infracción más específica es algunas veces considerada un
“tipo cualificado” de la menos específica. El tipo de infracción cualificado
podría estar sujeto a un nivel de multa más elevado, a un máximo legal más
elevado o a un plazo de limitación más amplio.

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

71/173

33. Sin embargo, a veces a través de la interpretación, también puede
aplicarse la especialidad, cuando por razones de naturaleza y sistemática
una infracción se considera una restricción de una aparentemente más
específica, aunque su redacción por sí sola no mencione explícitamente un
elemento adicional.
34. Cuando, en cambio, dos disposiciones persiguen objetivos autónomos,
constituye un factor diferenciador que justifica la imposición de multas
separadas. Por ejemplo, si una infracción de una disposición da lugar
automáticamente a una infracción de la otra, pero lo contrario no es cierto,
estas infracciones persiguen objetivos autónomos.
35. Estos principios de especialidad solo pueden aplicarse, en la medida en
que los objetivos perseguidos por las infracciones en cuestión sean
realmente congruentes en el caso concreto. Dado que los principios de
protección de datos del artículo 5 del RGPD se establecen como conceptos
generales, puede haber situaciones en las que otras disposiciones sean una
concretización de dicho principio, pero sin circunscribir el principio en su
totalidad. En otras palabras, una disposición no siempre define el alcance
completo del principio. Por lo tanto, dependiendo de las circunstancias, en
algunos casos se solapan de manera congruente y una infracción puede
sustituir a la otra, mientras que en otros casos, el solapamiento es solo
parcial y, por lo tanto, no es totalmente congruente. En la medida en que no
son congruentes, no hay concurrencia de delitos. En su lugar, se pueden
aplicar uno al lado del otro, al calcular la multa.
Principio de subsidiariedad
36. Otra forma de concurrencia de delitos se denomina a menudo el
principio de subsidiariedad. Se aplica cuando una infracción se considera
subsidiaria a otra infracción. Esto podría deberse a que la ley declara
formalmente la subsidiariedad o porque la subsidiariedad se da por razones
materiales.(…)
Principio de consumo
37. El principio de consumo se aplica en los casos en que la infracción de
una disposición conduce regularmente a la infracción de la otra, a menudo
porque una infracción es un paso previo a la otra.
3.1.2 — Unidad de acción — Artículo 83, apartado 3, del RGPD
38. Similar a la situación de concurrencia de delitos, el principio de unidad
de acción (también denominado «concurrencia ideal») se aplica en los
casos en que una conducta está comprendida en varias disposiciones
legales, con la diferencia de que una disposición no está excluida ni
subsumida por la aplicabilidad de la otra, porque no entran en el ámbito de
aplicación de los principios de especialidad, subsidiariedad o consumo y
persiguen principalmente objetivos diferentes. (…)
(…) En caso de unidad de acción, el importe total de la multa administrativa
no excederá del importe especificado para la infracción más grave. «Por lo
que se refiere a la interpretación del artículo 83, apartado 3, del RGPD, el
CEPD señala que el principio «effet utile» exige que todas las instituciones
den pleno vigor y efecto al Derecho de la UE»16. A este respecto, el artículo
83, apartado 3, del RGPD no debe interpretarse de una manera en la que
«no importaría si un infractor cometió una o numerosas infracciones del
RGPD al evaluar la multa»(…)
3.2 — Conductas sancionables múltiples

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

72/173

44. El principio de pluralidad de acciones (también denominado
«Realkonkurrenz», «factual concurrence» o «coincidental concurrence»)
describe todos los casos no comprendidos en los principios de concurrencia
de delitos (capítulo 3.1.1) o artículo 83, apartado 3, del RGPD (capítulo
3.1.2).
45. La única razón por la que estas infracciones se tratan en una decisión
es por haber llamado la atención de la autoridad de control al mismo tiempo
sin ser la misma u operaciones de tratamiento vinculadas en el sentido del
artículo 83, apartado 3, del RGPD. Por lo tanto, se considera que el infractor
ha infringido varias disposiciones legales y se imponen multas separadas
según el procedimiento nacional, ya sea en la misma decisión de multa o en
decisiones de multas separadas. Además, dado que no se aplica el artículo
83, apartado 3, del RGPD, el importe total de la multa administrativa puede
superar el importe especificado para la infracción más grave (argumentum e
contrario). Los casos de pluralidad de acciones no plantean ninguna razón
para favorecer al infractor con respecto al cálculo de las multas. Sin
embargo, esto se entiende sin perjuicio de la obligación de seguir
respetando el principio general de proporcionalidad.(…)

Vemos, por tanto, que las Directrices 04-2022 sobre cálculo de la guía de
multas no hacen referencia en ningún caso a que las infracciones del
artículo 5.1.f) y 32 del RGPD tengan el mismo interés jurídico protegido, sino
que ello es una interpretación que realiza la propia reclamada de las reglas
generales que se prevén en el apartado 3.1.1 sobre “Concurrencia de
ofensas”.

Señala la reclamada que: “En el presente supuesto, el interés jurídico
protegido (la confidencialidad de los datos) es el mismo. La AEPD centra
ambas infracciones en que no se han adoptado medidas de seguridad
técnicas y organizativas adecuadas, lo que ha afectado a la capacidad de
garantizar la confidencialidad, lo que sin duda nos conduce, conforme a las
Directrices 04/2022 del European Data Protection Board, a la concurrencia
del ‘principio de consumo’ o que una infracción es un paso previo a la otra”.

La reclamada entiende que debe aplicarse el Principio de Consunción
porque estamos ante un caso de “concurrencia de ofensas” (equivalente al
concurso medial de infracciones del derecho español). Pero parte dos
premisas erróneas al considerar que en este caso existe una sola conducta
(o más bien, una omisión), que es la falta adopción de medidas de seguridad
en la plataforma ***SOFTWARE.1 para proteger la confidencialidad) que
está vulnerando dos normas (el artículo 5.1.f), y 32 de RGPD), que protegen
el mismo interés jurídico (la confidencialidad de los datos personales según
la reclamada), y que por tanto, debemos aplicar el Principio de Consunción
al que se refiere el CEPD.

Pero para que estemos en presencia de una “concurrencia de ofensas” el
CEPD requiere el cumplimiento de dos presupuestos que no concurren en el

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

73/173

presente caso: que nos encontrásemos ante una sola acción/omisión que
suponga incumplir dos preceptos, y además, que ambos preceptos o
infracciones administrativas protejan el mismo interés jurídico.

- En primer lugar, en este supuesto no estamos ante una
“concurrencia de ofensas” sino ante lo que el CEPD denominada
como una “pluralidad de acciones” o “conductas infractoras
múltiples” (concurso real de infracciones según el derecho
administrativo español) que justifica que se imputen dos
infracciones administrativas autónomas, y que éstas se sancionen
por separado, toda vez que, tal y como se ha hecho referencia al
valorar la prueba, en el presente supuesto, existen dos conductas
infractoras o incumplimientos de deberes por parte del responsable
del tratamiento (omisiones) que hay que diferenciar:

(i) Dentro de la infracción del artículo 5.1.f) del RGPD, como ya
se ha explicado, la conducta negligente acreditada que se
imputa a la reclamada es la omisión del deber de
seudononimizar y cifrar los datos personales que obraban
en la tabla ***TABLA.1 de la plataforma ***SOFTWARE.1.
No se imputa dentro de esta infracción responsabilidad por
no haber adoptado las medidas de seguridad del artículo 32
del RGPD apropiadas para evitar que se produzca una
extracción o filtración de datos personales, sino por no
adoptar las medidas que hubieran impedido que el ciber-
atacante pudiera visualizar o entender los datos personales
extraídos, así como publicarlos o cederlos a terceros.

(ii) Sin embargo, dentro de la infracción del artículo 32 del
RGPD, la conducta sancionable que se imputa se ciñe a la
omisión del deber de adoptar las medidas más esenciales
de carácter organizativo y técnico para proteger la seguridad
de la plataforma en general, a la vista de las
vulnerabilidades y deficiencias que se pusieron de
manifiesto en la misma durante la investigación. Dentro de
la infracción del artículo 32 del RGPD no se imputa
responsabilidad por las medidas que afectaron a la
vulneración del deber de confidencialidad (falta de cifrado
los datos personales), sino únicamente por el resto de
deficiencias reconocidas que afectan a otros aspectos de
seguridad de los datos personales y son independientes de
la brecha de datos personales producida ( falta de
actualización de la plataforma, acceso a internet, falta de
medidas de monitorización y trazabilidad, falta de análisis de
riesgos, de protocolos de gestión y detección de brechas…

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

74/173

etc).
- En segundo lugar, aun en el caso- como señala la reclamada- se
pudiera considerar que existe una “concurrencia de ofensas” por
existir una sola conducta que se tipifica como infracción en dos
preceptos diferentes, tampoco cabría aplicar los Principios de
especialidad, subsidiariedad o consumo, puesto que en este caso
las infracciones administrativas imputadas no protegen el mismo
interés jurídico. Y ello es un requisito para poder aplicar cualquiera
de estos principios, según el apartado 30 de las Directrices 04/22:
“El principio de especialidad, subsidiariedad o consumo, que a
menudo se aplica cuando las disposiciones protegen el mismo
interés jurídico. En tales casos, sería ilegal sancionar dos veces al
infractor por la misma ofensa”.

A diferencia de lo que señala la reclamada, no cabe aplicar el
Principio de especialidad, subsidiariedad ni del consumo (no existe
concurso medial de infracciones) porque los intereses jurídicos
protegidos por los artículos imputados son diferentes. Mientras que
el artículo 5.1.f) del RGPD tiene por finalidad el garantizar la
confidencialidad y la integridad de los datos personales, el artículo
32 del RGPD tiene por finalidad adoptar y aplicar medidas para
garantizar un nivel de seguridad adecuado al riesgo. Por tanto, en
el primer caso, el interés jurídico protegido es la confidencialidad e
integridad de los datos personales, mientras que en el segundo lo
es la seguridad del tratamiento.

La independencia de ambos preceptos -y por tanto, la posibilidad de
sea posible cometer dos infracciones independientes- se deduce de
la propia configuración que el legislador comunitario ha realizado de
ambos tipos infractores:

o Primero, los incluye en dos preceptos diferentes, el 5.1.f) y el
32 del RGPD, que protegen intereses jurídicos diferentes,
como ya se ha dicho.
o El RGPD realiza una tipificación y la LOPDGDD realiza la
calificación de la infracción a los efectos de la prescripción
diferente:

Mientras que la vulneración del art. 5.1.f) del RGPD se
encuentra tipificada en el art. 83.5.a) del RGPD y calificada a
los efectos de la prescripción en el artículo 72.1.a) de la
LOPDGDD; mientras que la vulneración del artículo 32 del
RGPD se tipifica en el artículo 83.4.a) del RGPD y calificada a
los efectos de la prescripción en el artículo 73.f) de la
LOPDGDD.

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

75/173

El límite máximo de las multas previstas en el artículo 83.4 y 5
del RGPD es distinto (10 millones de euros o tratándose de una
empresa, de una cuantía equivalente al 2% como máximo del
volumen de negocio total anual global del ejercicio financiero
anterior o de 20 millones de euros o del 4% respectivamente).

De igual forma, la infracción del art. 5.1.f) del RGPD prescribe a
los tres años (muy grave a los efectos de la prescripción),
mientras que a los dos años prescribe la infracción del art. 32
del RGPD (grave a los efectos de la prescripción).

o Incluso la forma de cumplir con cada obligación está
configurada de forma diferente: La finalidad del artículo 5.1.f)
del RGPD se logra a través de medidas técnicas y
organizativas adecuadas de todo tipo, mientras que el artículo
32 del RGPD se centra sólo en medidas técnicas y
organizativas sólo de seguridad.

Además, hay que señalar que la vulneración de ambos preceptos a
la vez es posible y algo previsto por el legislador comunitario, sin que
la vulneración de uno de ellos impida la del otro y sin que la
vulneración de uno obligue a la del otro.

Tal y como el apartado 34 de las Directrices 04/22 del CEPD señala:
“34. Cuando, en cambio, dos disposiciones persiguen objetivos
autónomos, constituye un factor diferenciador que justifica la
imposición de multas separadas. Por ejemplo, si una infracción de
una disposición da lugar automáticamente a una infracción de la otra,
pero lo contrario no es cierto, estas infracciones persiguen objetivos
autónomos.

No cabe duda de que ambas normas persiguen objetivos autónomos
en el presente supuesto puesto que no siempre que se cometa una
infracción del artículo 5.1.f) es por no haber adoptado una de las
medidas de seguridad a las que se refiere el artículo 32 del RGPD. Y
viceversa. Así pues:

 Se puede producir una infracción del artículo 5.1.f) del RGPD
sin que implique una infracción del artículo 32 del RGPD. Este
es el supuesto del gerente o administrador de una empresa
que decide divulgar datos personales que están en su poder
consecuencia del desempeño de sus funciones y que no
implica que no existan medidas de seguridad o que se hayan
quebrado.
 También se puede producir una infracción del artículo 32 del

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

76/173

RGPD sin que se vulnere el artículo 5.1.f) del RGPD cuando
la infracción se limite a la ausencia o quiebra de medidas de
seguridad, pues no haya constancia de que los datos
personales hayan podido, por ejemplo, ser conocidos por un
tercero no autorizado.

No concurre concurso medial de infracciones, sino una situación de
concurso real de infracciones o pluralidad de acciones, que justifica la
imputación de ambas infracciones y la sanción de cada una de ellas.

No estamos, por tanto, ante una vulneración del Principio ne bis in
idem, porque, tal y como la propia jurisprudencia alegada por la
reclamada señala (Sentencia de la Audiencia Nacional de 23 de
julio de 2021 (rec. 1/2017): “(…) para que pueda hablarse de "bis in
ídem" debe concurrir una triple identidad entre los términos
comparados: objetiva (mismos hechos), subjetiva (contra los mismos
sujetos) y causal (por el mismo fundamento o razón de castigar)”. Lo
cual se deduce a su vez del artículo 31 de la LRJSP, referida a la
concurrencia de sanciones, que señala que:

“Artículo 31. Concurrencia de sanciones.

1. No podrán sancionarse los hechos que lo hayan sido penal o
administrativamente, en los casos en que se aprecie identidad
del sujeto, hecho y fundamento.

2. Cuando un órgano de la Unión Europea hubiera impuesto una
sanción por los mismos hechos, y siempre que no concurra la
identidad de sujeto y fundamento, el órgano competente para
resolver deberá tenerla en cuenta a efectos de graduar la que,
en su caso, deba imponer, pudiendo minorarla, sin perjuicio de
declarar la comisión de la infracción”.

De todo lo expuesto cabe concluir que en el supuesto presente no se
vulnera el Principio ne bis in idem, ni cabe aplicar la regla del artículo
29 de la LRJSP, puesto que no existe una identidad de hecho ni
causal. No estamos en presencia de una única acción con
concurrencia de ofensas o infracciones administrativas (concurso
medial de infracciones), sino ante una pluralidad de acciones
(concurso real de infracciones), en la medida en que se han cometido
dos conductas infractoras diferentes que han dado lugar a la
vulneración de dos diferentes intereses jurídicos protegidos, en cuyo
caso, no cabe duda de que deben imputarse y sancionarse dos
infracciones administrativas independientes.

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

77/173

Cabe señalar, así mismo, que el Auto del Tribunal Supremo que se cita
por la reclamada únicamente admite a trámite el recurso de casación
interpuesto respecto a la causa citada, que está pendiente de resolver
en estos momentos.

SEGUNDA. – AUSENCIA DE CULPABILIDAD O NEGLIGENCIA GRAVE
RESPECTO DE LAS INFRACCIONES CONTEMPLADAS EN LOS ART. 5.1. F)
Y ART. 32 DEL RGPD.

Dentro de esta alegación la reclamada mantiene, principalmente y en resumen,
que no se ha acreditado que el acceso ilegítimo a los datos por el ciber-
atacante haya sido debido a la negligencia de la reclamada, y que no concurre
el requisito de culpabilidad de la reclamada, puesto que la reclamada ha sido
víctima de un ciber-ataque.

Se entiende resuelta esta alegación principal, estimando parcialmente la
misma, y corrigiendo lo manifestado en el acuerdo de inicio, puesto que se
reconoce que la plataforma fue objeto de un ciberataque, pero no se ha
acreditado que el ciber atacante lograse acceder a la plataforma y extraer los
datos personales contenidos en la citada tabla ***TABLA.1 debido a una
actuación negligente de la reclamada . Dado que la falta de medidas de
trazabilidad y monitorización de la plataforma impidieron comprobar cuál había
sido el vector de entrada del ciberataque, no se puede conocer si éstas se
debieron a las vulnerabilidades de la plataforma que se hicieron constar por el
inspector en su Diligencia de 2 de noviembre de 2023.

No obstante, como también se ha explicado, cabe mantener la culpabilidad de
la reclamada respecto a que los datos personales puedan ser susceptibles de
ser publicados o cedidos a terceros, dado que si consta acreditado que no se
aplicaron las medidas de seudonimización y cifrado de los datos personales
que los hubieran convertido en ininteligibles para las personas que no
dispongan de la clave de descifrado. Cifrado que no hubiera impedido el
ciberataque pero sí hubiera evitado que se vulnerase la confidencialidad de los
datos personales que contenía la plataforma, y le hubiera impedido su
publicación posterior y la cesión a terceros, pues consta acreditado que los
puso a la venta en la dark web, y le proporcionó una muestra al inspector en la
que no se enmascaraba ningún dato, y aparecían todos los datos personales
visibles e identificables con claridad.

Por otra parte, cabe descartar otros argumentos realizados por la reclamada en
esta alegación, puesto que: (i) si se ha considerado que no se tratan datos de
categoría especial o de menores, como más adelante se expondrá; (ii) y las
brechas de seguridad cuyos procedimientos han sido archivados por esta
Agencia no responden al mismo supuesto y circunstancias que el aquí
enjuiciado.

TERCERA. - AUSENCIA DE PRUEBA DE QUE LAS MEDIDAS SON
INEFICACES.

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

78/173

La reclamada repite los argumentos ya señalados anteriormente, cuando
señala en esta alegación que debe aplicarse la presunción de inocencia, y el
“Principio In dubio pro reo” al concurrir serias dudas de que las medidas
adoptadas por CECOTEC fueran ineficaces y que la base de datos objeto del
ciberataque fuera la de CECOTEC. Dado que la administración está aplicando
una responsabilidad objetiva que no existe, puesto que el acuerdo de inicio se
basa en indicios como el número de usuarios de la plataforma y a la vista de la
prueba practicada, existen dudas razonables.

Se entiende que estos argumentos ya han sido objeto de contestación en la
alegación anterior, no aplicándose una responsabilidad objetiva en este
supuesto, puesto que ya se han explicado los motivos por los que se entiende
que si concurrió negligencia grave respecto a la comisión de las infracciones
que se imputan en este procedimiento. A su vez, al analizar el hecho
controvertido de la culpabilidad de la reclamada en la comisión de la infracción
del artículo 5.1.f) del RGPD se ha aplicado el Principio “In dubio pro reo” por no
acreditarse en el procedimiento cuál había sido el vector de entrada, no
imputando la filtración de datos o acceso no autorizado del ciber-atacante a la
negligencia de la reclamada. Por otra parte, existen evidencias reconocidas por
el propio director de ciberseguridad y el DPD de la empresa, de la concurrencia
del resto de infracciones imputadas.

CUARTA. - INEXISTENCIA DE LA INFRACCIÓN DEL ART. 33 RGPD EN
CUANTO A LA NOTIFICACIÓN FUERA DE PLAZO DE 72H.

Los argumentos esgrimidos en torno a esta cuestión giran en torno a dos
cuestiones controvertidas, que cabe analizar por separado. Primero se plantea
que la fecha de inicio del cómputo de plazo es arbitraria, y segundo que no
existe infracción porque no existía un deber de notificar la brecha.

En primer lugar, CECOTEC considera que la fecha de inicio del cómputo del
plazo (día ‘ad quo’) que ha tenido en cuenta la AEPD para calcular el inicio del
término de las 72 horas, esto es, el 17/04/2023, es totalmente arbitraria, puesto
que en aquel momento, en realidad, CECOTEC no estaba en disposición o
tenía un ‘conocimiento’ real de que se hubiera producido una violación de
datos.

En concreto, señala lo siguiente:
“(…) Esta parte considera que el cómputo del día ‘a quo’ que ha tenido
en cuenta la AEPD para calcular el inicio del término de las 72 horas,
esto es, el 17/04/2023 es totalmente arbitrario, puesto que en aquel
momento, en realidad, CECOTEC no estaba en disposición o tenía un
‘conocimiento’ real de que se hubiera producido una violación de datos
pues la información procedente de INCIBE destacaba que no podía
asegurar que fuera información verídica y a mayor abundamiento,
únicamente se ha acreditado que eran 6 sujetos reales al tiempo de
notificar la brecha e incluso a fecha de hoy sigue siendo igual, pese a
las conjeturas y sospechas que pueda tener el instructor”·.

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

79/173

Primeramente, cabe aclarar que CECOTEC no señala expresamente en sus
alegaciones a partir de que fecha considera que debió iniciarse el cómputo de
este plazo y además, se equivoca al señalar que el acuerdo de inicio partió del
día 17/04/23, puesto que el acuerdo de inicio señaló que el plazo se computaba
por horas y no por días hábiles, y que en caso de haberse computado en días,
no se hubiera descontado el festivo del municipio en que CECOTEC tiene su
domicilio y el plazo hubiera finalizado el día 17/04/23. Por tanto, con el 17/04/23
el acuerdo de inicio se refería al dies ad quem o final del plazo y no al diez ad
quo o principio del plazo. Fecha fin de plazo que además se había calculado
teniendo en cuenta la opción más favorable para la empresa responsable.

Para fijar las fechas de cómputo inicial y final, debe partirse de la cronología
que se hace constar en el hecho probado cuarto de esta propuesta, según la
cual:

o El primer aviso del incidente de ciberseguridad realizado por el INCIBE
se produjo el mismo día del ciberataque (5/04/23), conteniendo toda la
información del anuncio de que disponía el mismo, y se recibió en el
buzón general de CECOTEC, pero no se remitió inmediatamente al
DPD ni al director de ciberseguridad, quedando “en cola” para ser
contestado por orden de antigüedad
o La remisión de este correo de alerta no se advirtió por la empresa
hasta que no se le remitió por INCIBE un segundo correo de aviso el
12/04/23, que si fue trasladado por el buzón general al director de
ciberseguridad de CECOTEC.
o Con fecha de 13/04/23, el director de ciberseguridad solicita al INCIBE
que le remita la información referida a dicho incidente, contestándole
INCIBE el mismo día 13/04/23 a las 17:23 horas para remitirle la
misma información que ya constaba en el correo inicial de 5/4/23. Es
entonces cuando el departamento de ciberseguridad comienza las
investigaciones en sus sistemas y bases de datos al objeto de
determinar si ha podido existir una brecha.
o Durante el día 13/04/23, el director de ciberseguridad realiza las
comprobaciones pertinentes y concluye su investigación,
informando a el mismo día 13/04/23 las 17:26 horas a INCIBE de
que los 17 registros de la muestra coinciden con los contenidos en una
antigua plataforma de CECOTEC que se cerró en 2021.
o Con fecha de 14/04/23 a las 14:31 horas, el responsable de
ciberseguridad remite un correo electrónico a la DPD (Anexo 7)
donde le informa de todos los correos intercambiados por el INCIBE,
de los análisis realizados, sus conclusiones, y hace referencia tanto a
que los registros coinciden con los incluidos en la tabla ***TABLA.1 de
la antigua plataforma, como a las vulnerabilidades y deficiencias que
se han puesto de manifiesto en el Fundamento de Derecho VIII y
hecho probado octavo de esta Propuesta. Informándole del resultado
de sus investigaciones, determina que no puede comprobar a ciencia

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

80/173

cierta el alcance de la brecha al no disponer de la totalidad de los
registros que dice tener el ciberatacante.
o El director de ciberseguridad comprueba que el correo de INCIBE no
es un intento de phishing y éste le contesta el 17/04/23.
o Y finalmente, CECOTEC notifica la brecha a esta AEPD el 19/04/23
a las 18:19 horas.

Para determinar cuándo comenzó el día inicial del plazo para notificar la
brecha a esta autoridad, debemos remitirnos a las Directrices 9/2022, sobre
la notificación de las violaciones de la seguridad de los datos
personales en el marco del RGPD, que señalan lo siguiente:

“2. ¿Cuándo «tiene constancia» un responsable del tratamiento?
31. Como se ha explicado anteriormente, el RGPD establece que, en
caso de una violación, el responsable del tratamiento lo notificará sin
dilación indebida y, de ser posible, a más tardar setenta y dos horas
después de que haya tenido constancia de ella. Esto puede plantear la
cuestión de cuándo puede considerarse que un responsable del
tratamiento «tiene constancia» de una violación. El CEPD piensa que
debe considerarse que el responsable del tratamiento «tiene
constancia» cuando tenga un grado razonable de certeza de que se ha
producido un incidente de seguridad que compromete datos personales.
32. Sin embargo, como se ha indicado anteriormente, el RGPD exige
que el responsable del tratamiento adopte todas las medidas
organizativas y de protección técnica apropiadas para determinar de
inmediato si se ha producido una violación e informar sin dilación a la
autoridad de control y a los interesados. Asimismo, indica que debe
verificarse que la notificación se ha realizado sin dilación indebida
teniendo en cuenta, en particular, la naturaleza y gravedad de la
violación y sus consecuencias y efectos adversos para el interesado24.
Esto obliga al responsable del tratamiento a garantizar que tendrá
constancia de cualquier violación de forma rápida para que pueda tomar
las medidas oportunas.
33. El momento exacto en que puede considerarse que un responsable
del tratamiento «tiene constancia» de una violación concreta dependerá
de las circunstancias de dicha violación. En algunos casos, estará
relativamente claro desde el principio que se ha producido una
violación, mientras que en otros puede llevar algún tiempo establecer si
los datos personales se han visto comprometidos. No obstante, debe
hacerse hincapié en la necesidad de actuar con rapidez para investigar
un incidente a fin de determinar si, efectivamente, se ha violado la
seguridad de los datos personales y, de ser así, para adoptar medidas
correctivas y, en caso necesario, notificarlo.
34. Tras haber sido informado de una posible violación por una persona,
un medio de comunicación u otra fuente, o cuando el propio

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

81/173

responsable del tratamiento haya detectado un incidente de seguridad,
este podrá iniciar un breve período de investigación para determinar si
se ha producido o no una violación. Durante este período de
investigación, no se puede considerar que el responsable del
tratamiento «tenga constancia». Sin embargo, cabe esperar que la
investigación inicial comience lo antes posible y establezca con un
grado razonable de certeza si se ha producido una violación; a
continuación, puede realizar una investigación más detallada. (…)
40. Por consiguiente, debe quedar claro que el responsable del
tratamiento está obligado a actuar a partir de cualquier alerta inicial y a
determinar si se ha producido o no una violación. Este breve período
permite que se realicen algunas investigaciones y que el responsable
del tratamiento reúna pruebas y otros detalles pertinentes. No obstante,
una vez que el responsable del tratamiento haya establecido con un
grado razonable de certeza que se ha producido una violación, si se
cumplen las condiciones del artículo 33, apartado 1, del RGPD, deberá
notificarlo a las autoridades de control sin dilación indebida y, de ser
posible, en un plazo máximo de setenta y dos horas. Si un responsable
del tratamiento no actúa de manera rápida y resulta evidente que se ha
producido una violación, esto podría considerarse una falta de
notificación de conformidad con el artículo 33 del RGPD.”

Aplicando estas directrices al supuesto presente, consta que se recibieron
dos alertas iniciales del INCIBE pero no se podría en este caso computar el
inicio del plazo para notificar la brecha desde la recepción de estas alertas,
puesto que según el CEPD, para poder tener constancia de que los datos que
tenía el actor malicioso pertenecían a una base de datos de CECOTEC, se
entiende que era necesario en este caso realizar una breve investigación
previa durante la cual no cabe iniciar el cómputo del plazo de notificar la
brecha, como señala el CEPD.

No obstante, como también señala el CEPD, la investigación debió realizarse
sin dilaciones indebidas y durar el tiempo estrictamente necesario para
obtener un “grado razonable de certeza de la brecha”. Esto es, bastaba con
realizar una investigación inicial, que se limitarse a comprobar si los 17
registros que constaban en la muestra del anuncio constaban en alguna de
sus bases de datos y a cuantos datos personales había afectado, sin
necesidad de comprobar con certeza absoluta que el actor malicioso disponía
de los datos personales de casi millón de personas ordenadas por número de
teléfono móvil que decía tener en su poder.

Todo ello, puesto que lo importante era iniciar cuanto antes los mecanismos
de mitigación de los efectos de la brecha producida, y continuar la
investigación hasta conocer mayores datos, como también señalan estas
Directrices. No era necesario dilatar la investigación hasta saber a ciencia

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

82/173

cierta que el ciberataque había afectado a la totalidad de registros que el
actor malicioso decía tener a su disposición.

En otras palabras, para tener conocimiento de la brecha y que se genere el
deber de notificar, es necesario certeza sobre que la brecha se ha producido,
pero no sobre su naturaleza (vector de entrada) ni su alcance (número de
datos extraídos), tal y como el propio “Protocolo de gestión de incidentes de
seguridad de 22-4-21”, aportado por la empresa hacía constar (el subrayado
es nuestro):
o “Obligación de comunicar cualquier evento de seguridad que afecte
a la confidencialidad, integridad o disponibilidad de datos
personales. Todo empleado de la organización que sea conocedor
de un hecho indiciario de un evento o incidente de seguridad en
materia de protección de datos personales, por cualquiera de los
medios indicados en el punto 2.1. de este documento (relativo a las
fuentes de identificación de una brecha de seguridad), deberá
comunicarlo en el plazo máximo de 24 horas a la Delegada de
Protección de Datos y su responsable inmediato y superior
departamental.
o Proceso de notificación a la autoridad de control. Cuando el
responsable del tratamiento tenga conocimiento de que se ha
producido una brecha de la seguridad de los datos personales
debe, sin dilación y, a más tardar en las 72 horas siguientes a tener
constancia, efectuar la correspondiente notificación a la Autoridad
de Control. Se considera que se tiene constancia de una brecha de
seguridad cuando hay una certeza de que se ha producido y se
tiene conocimiento suficiente de su naturaleza y alcance.

Para determinar si CECOTEC actuó con la diligencia debida para cumplir su
deber de notificar la brecha, hay que distinguir dos periodos: (i) un primero
referido al periodo de investigación, durante el que no puede considerarse
que el responsable tuviera conocimiento de la brecha, y que durará hasta que
se pueda determinar que concurría “un grado razonable de certeza de la
brecha”; (ii) y un periodo posterior, que surge a partir de la fecha en la que
CECOTEC tuvo conocimiento de ese grado razonable de certeza de la
brecha, que es el verdadero plazo inicial desde el que debe computarse el
plazo de 72 horas para notificar.

A) Fecha de inicio de las actuaciones de investigación de CECOTEC.

Se entiende, que tras recibir dos alertas del INCIBE el 5 y 12 de abril de 2023,
no se iniciaron por CECOTEC las investigaciones necesarias para comprobar
la certeza de la brecha hasta el 13 de abril de 2023, tal y como se reconoce
por la DPD de CECOTEC en el escrito inicial de respuesta aportado Resp#1:

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

83/173

“Al no obtener respuesta por nuestra parte, el día 12 de abril de 2023—
recibimos— un nuevo correo del INCIBE a la misma dirección indicada
anteriormente en el que nos solicitaban un reporte del seguimiento del
incidente, sin indicar nada más al respecto. Como no éramos conscientes
del primer correo remitido y en este último correo electrónico del INCIBE
no se daba información sobre incidente, desde CECOTEC se contestó
ese mismo día solicitando información sobre el mismo y no fue hasta el
jueves 13 de abril de 2023 cuando el lNCIBE aportó toda la información
referente a la posible brecha y, por tanto, cuando CECOTEC fue
verdaderamente consciente de esta supuesta amenaza.
Fue en el mismo momento en el que el Responsable de Ciberseguridad
junto con el Departamento de informática de CECOTEC empezó a
gestionar esta supuesta brecha de seguridad realizando los trabajos y
verificaciones técnicas necesarias para intentar corroborar a la mayor
brevedad posible que la información facilitada por el INCIBE
efectivamente afecta a CECOTEC.”

Consta acreditado que concurrió una dilación indebida en el deber de iniciar
las investigaciones pertinentes para comprobar la certeza de la brecha que
fue imputable a las siguientes actuaciones de la empresa reclamada, puesto
que:

(i) Consta acreditado que el primer correo de aviso de 5 de abril de 2023
se recibió en el buzón general de CECOTEC pero que no se remitió
dicho primer correo, con el orden de prioridad que merecía una alerta
de estas características, a las personas encargadas de gestionar la
brecha. Ello se reconoce expresamente por el informe del DPD
aportado, y se corrobora por el primer escrito de respuesta al
requerimiento de investigación, que señala lo siguiente:

“Tal y como se expuso en el informe aportado por la Delegada
de Protección de Datos en la notificación de la brecha, El día 5
de abril de 2023 recibimos un correo electrónico del INCIBE a
nuestro correo genérico ***EMAIL.1 en el que nos informaban
de un posible incidente de ciberseguridad con el código de
referencia [lNCIBE-CERT 3713032]. Esta notificación no fue
atendida a tiempo por esta entidad ya que los correos
electrónicos recibidos en este buzón (que está destinado a
clientes), son atendidos por orden de antigúedad. Además, esa
semana hubo más correos electrónicos a los que atender,
teniendo en cuenta que los días 7 y 10 de abril fueron festivos y
el correo electrónico que la DPD remitió a los encargados de
este buzón general en el que preguntaba por lo sucedido y les
advertía de la necesidad de remitir este tipo de comunicaciones
al DPD y al Director de Ciberseguridad, que consta aportado

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

84/173

como Anexo 7 de la Resp#1.”

(i) En segundo lugar, cuando se recibió el segundo correo de alerta el 12
de abril de 2023, el Director de Ciberseguridad perdió otro día para
obtener la información inicial que se encontraba en el primer correo de
5 de abril de 2023, contestándole el INCIBE el 13 de abril, remitiéndole
la misma información que se contenía en el correo originario.

El asunto de dicho correo de 12 de abril de 2023 era “Posible incidente
de ciberseguridad”, y en su texto se hacía constar claramente que era
un correo de seguimiento del primer correo remitido, y se incluía el
código de incidente, que podría haberse utilizado para recuperar el
mismo del buzón general de CECOTEC.

Así pues, en lugar de recuperar el mismo del buzón general,
CECOTEC retrasó la comprobación de la brecha un día más,
reconociendo que “no éramos conscientes del primer correo remitido”.

De lo expuesto se deduce que la reclamada no obró con la diligencia debida
al iniciar el periodo de investigación con fecha de 13 de abril de 2023 a las
11:12 horas, cuando recibió el tercer correo del INCIBE, con la información ya
remitida el 5 de abril de 2023.

B) Sobre la fecha a partir de la cual CECOTEC tuvo conocimiento de la
brecha.

Dentro de este periodo de investigación iniciado para comprobar la certeza
razonable o suficiente de la brecha, se ha constatado que se omitieron diversas
actuaciones de comprobación y se realizaron requerimientos innecesarios de
información que ponen de manifiesto la falta de diligencia de los responsables
de detectar la brecha, puesto que:

o En ambos correos de alerta del INCIBE de 5 y 12 de abril, se informaba
de que para obtener mayor información se podía contactar con el actor
malicioso en el foro, proporcionando el link al anuncio, y haciendo
constar toda la información necesaria para ello. Información que fue
utilizada para realizar una adecuada investigación por el inspector de
este procedimiento, que logró sin mayores dificultades contactar con el
mismo el 4 de agosto de 2023 y obtener una muestra mayor de 1000
registros que ha permitido comprobar que fueron muchos más los
afectados por la brecha (933 personas, como mínimo).

No obstante, pese a disponer de los datos de contacto desde el primer
correo de alerta, ni el director de ciberseguridad en su correo de 14 de
abril de 2023 ni el DPD en sus informes han hecho constar que se

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

85/173

intentase contactar con el actor malicioso e incluso tratan de imputar
responsabilidad a esta agencia en su segundo escrito de alegaciones al
acuerdo de inicio, por no haberle proporcionado sus datos de contacto,
cuando los tenían a su disposición desde la primera alerta, que les fue
reenviada de nuevo por el INCIBE el 13 de abril de 2023.

No cabe, por tanto, estimar la alegación de que CECOTEC no tuviera
“conocimiento real” de la brecha, por el mero hecho de que INCIBE le
señalase que no podía asegurar que la información publicada por el
actor malicioso fuera verídica, dado que es el responsable del
tratamiento el único que puede comprobar la verosimilitud del ciber-
ataque, cotejando los registros con los contenidos en su base de datos.
Y además, consta que desde el mismo día 5 de abril el INCIBE ya le
proporcionó todos los datos del actor malicioso que le hubieran
permitido realizar estas comprobaciones por sí mismo.

Por este mismo motivo, no cabe admitir tampoco las alegaciones
realizadas en su segundo escrito de alegaciones al acuerdo de inicio,
cuando CECOTEC señala que esta agencia conocía los datos del actor
malicioso, pero no los puso en conocimiento de CECOTEC, y que de
haberlos conocido hubiera podido denunciar antes el hecho. Dado que
CECOTEC tuvo a su disposición los mismos datos que el inspector
desde el principio, no utilizándolos para cumplir con su deber esencial
de realizar sin dilación las comprobaciones oportunas para detectar la
realidad y alcance de la brecha.

o Por otra parte, consta que el responsable de ciberseguridad realizó las
comprobaciones oportunas durante el día 13 de abril de 2023,
precisando menos de medio día para realizarlas, lo que acredita que de
haber funcionado el protocolo, se hubiera detectado la alerta el 5 de
abril de 2023 y se hubiera podido tener conocimiento de su certeza el
día 6 de abril, comenzando entonces el plazo de 72 horas para
notificarla.

o Sin embargo, aunque el periodo de investigación “en si” fue breve, las
conclusiones a las que llegó y la información proporcionada denotan
una falta de conocimiento absoluto del concepto de brecha, su
detección y su deber de notificación. Al informar del resultado de estas
comprobaciones, el responsable de ciberseguridad remite un correo
electrónico al INCIBE el 13 de abril a las 17:26 horas que no coincide
con lo que se informa a su DPD en el correo del 14 de abril de 2024,
llegando a la conclusión de que aunque todos los registros de la
muestra se encontraban incluidos en la citada tabla ***TABLA.1 de la
antigua plataforma, no podía determinar “a ciencia cierta” que se había
producido el ciber-ataque por disponer únicamente de 17 registros,

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

86/173

habiendo requerido información adicional al INCIBE para realizar esta
comprobación.

Del tenor literal del correo remitido al INCIBE no se infiere en ningún
momento que éste haya realizado una petición de información adicional
al INCIBE, ni que quedase a la espera de recibirse más información.

Pero en cualquier caso, hay que decir que el requerimiento de
información adicional no podía justificar el retraso de este periodo de
investigación, puesto que: (i) ya se ha dicho que la investigación inicial
no requiere este grado de certeza absoluta o “a ciencia cierta”, por lo
que no conocer más información no era excusa suficiente para esperar
a que el INCIBE contestase de nuevo, y dilatar de nuevo el plazo de
notificación; (ii) y el responsable debió percatarse de que el INCIBE ya
hizo constar en todos sus correos que no podía asegurar que la
información verídica y no disponía de más información, señalando como
podía obtener esta información adicional;

Así pues, con fecha 14 de abril de 2023 (Pág 110 exp), se remite un
correo desde ***EMAIL.3 a [email protected], en el que además de
ampliar detalles referidos a las deficiencias de la plataforma que le
habían impedido detectar el vector de ataque, se señalaba que estaba a
la espera de que el INCIBE le conteste al correo remitido el día anterior
a las 17:26, que como hemos visto, no formula requerimiento de
información alguno.

Pero el correo remitido con fecha 13 de abril de 2023 a las 17:26 horas
a INCIBE no requiere información adicional alguna ni informa de estas
vulnerabilidades: “Los datos que se muestran en la imagen que ha
suministrado el usuario ***USUARIO.1 en ***FORO.1 se tratan de datos
de prueba. Por otro lado, la web con dichos datos se cerró en 2021 y no
sigue en funcionamiento. Por ahora, no podemos determinar si se
considera una filtración con solo la imagen que se muestra. La
referencia de lo que se está hablando es [***REFERENCIA.1]. De
todas formas, estamos a vuestra disposición para lo que necesitáis”.

Ha quedado acreditado, por tanto, que CECOTEC no aplicó su propio
Protocolo de gestión de incidentes de 2021 (que regulaba cómo detectar
un incidente de seguridad, y notificar una brecha), cuya comunicación a los
empleados y responsables con anterioridad a la brecha no consta
acreditada. Puesto que consta en el expediente:

o Que los encargados del buzón general de CECOTEC no remitieron
a los responsables de detectar la brecha y notificarla la primera
alerta de incidente de ciberseguridad. En el Protocolo de 2021 no
constan los datos de las personas a las que debía realizase dicha

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

87/173

comunicación.
o Que tanto el responsable de ciberseguridad como la DPD de la
empresa, desconocían que su Protocolo señalaba que no era
necesario conocer a ciencia cierta cuál había sido el vector de
entrada del ciberataque ni si había afectado a la totalidad de
registros de la base de datos. Puesto que señalan que la
notificación se hizo de forma proactiva, y pese a no tener obligación,
porque no se le daba verosimilitud al ciberataque, puesto que el
responsable de ciberseguridad no había logrado determinar a
“ciencia cierta”

Se ha acreditado también que se han adoptado medidas correctivas con
posterioridad al incidente para evitar que estas dilaciones se vuelvan a
producir: (i) puesto que consta en el Anexo 7 del escrito Resp#1 que la
DPD remitió un correo electrónico el 15 de abril de 2023 al personal de
CECOTEC y al INCIBE informando de los correos electrónicos a los que
debían remitirse estas alertas, (ii) y se elaboró un nuevo Protocolo de
gestión de brechas de seguridad el 29 de agosto de 2023, que se aporta
en la Resp#2.

De haberse aplicado un adecuado protocolo de detección y gestión de
brechas, las actuaciones de comprobación que debieron conformar el
“breve periodo de investigación inicial” a la que se refieren las Directrices
09/22 del CEPD debió haber comenzado el 5 de abril de 2023, cuando se
recibió la primera alerta. Y habiendo la reclamada reconocido que se
percató de que había recibido la segunda alerta, no cabe duda de que,
como mínimo, debieron comenzar el 12 de abril de 2023 cuando se
recibió el segundo recordatorio, sin tener que esperar al 13 de abril de
2023, dado que CECOTEC podía recuperar el correo inicial de su buzón
y conocer todos los datos necesarios para iniciar dicha investigación.

No obstante, lo cierto es que el retraso indebido en el inicio de las
investigaciones prueba que la reclamada no disponía de las medidas
adecuadas de detección, prevención y mitigación de los efectos de las
posibles brechas de esta plataforma. Pero no influye en el cómputo del
plazo que se imputa como infracción del artículo 33 del RGPD, que
comienza cuando ésta tuvo un grado razonable de certeza de que se
había producido la brecha.

En consecuencia, de las actuaciones se desprende que la fecha a partir de
la cual puede considerarse que CECOTEC fue consciente de que existía
un grado razonable de certeza de la brecha, por haber comprobado que
ésta había afectado -como mínimo- a 6 personas reales, fue el 13 de abril
de 2023 a las 17:26 horas, tal y como manifiesta la DPD en su informe:

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

88/173

Será por tanto, a partir del 13 de abril de 2024 a las 17:26 horas cuando
deberá computarse el plazo inicial (dies ad quo) para notificar la brecha a
esta agencia, aplicando las reglas de cómputo de plazo previstas en el
reglamento europeo al que hizo referencia el acuerdo de inicio (Reglamento
CEE, EURATOM nº 1182/71, de 3 de junio de 1971), al que se hará
referencia en el fundamento de derecho XI de esta propuesta de resolución.

Siendo el DPD el órgano competente para informar sobre cuándo concurre
obligación de notificar, se ha reconocido expresamente por la DPD de
CECOTEC que se adoptó esta decisión de notificar la brecha producida el
14 de abril de 2024, cuando le fue remitido el correo del departamento de
ciberseguridad informando de la investigación realizada, alegando que el
retraso en el plazo de 72 horas se produjo se debió a la existencia de varios
días festivos. Sin perjuicio de que dichos días no se consideran festivos
cuando el plazo se computa en horas, por los motivos que se analizarán en
el fundamento de derecho IX, lo cierto es que no cabe duda de que se ha
reconocido que CECOTEC tuvo conocimiento de la brecha y decidió
notificarla el citado día 14.

Confirmada la actuación negligente, cabe señalar que, de acuerdo con lo
previsto en el artículo 33 del RGPD, interpretado por las Directrices
mencionadas, se considera que debe aplicarse la interpretación más
favorable al imputado, considerando que el plazo de inicio del deber de
notificar la brecha no comenzó el 12 de abril de 2024 tras recibir la segunda
alerta de INCIBE -como señaló el acuerdo de inicio- sino que comenzó el 14
de abril de 2024 a las 14:31 horas, cuando el responsable de ciberseguridad
informó a la DPD y ésta decidió que procedía notificar la brecha,
transcurriendo más de 72 horas hasta que finalmente fue notificada el 19 de
abril de 2023.

- Una vez aclarada la cuestión del plazo, cabe desestimar también las
alegaciones en base a las cuales CECOTEC considera que no existía
deber de notificar la brecha, y, pese a ello, CECOTEC decidió hacerlo
proactivamente.

En concreto, CECOTEC mantiene que no es obligatorio notificar todas las
brechas de datos personales, dado que el RGPD prevé una excepción a esta
obligación cuando el responsable pueda garantizar que es improbable que la
brecha de datos personales entrañe un riesgo. Por ello, teniendo en
consideración la tipología de datos afectada, ya mencionada, en la que no
había ni datos identificativos de nombre y apellidos y resultando afectados,
inicialmente, sólo 6 personas reales, se entiende que era improbable la
existencia de riesgo. Y mantienen que: “en este sentido conviene traer el
criterio del antiguo Grupo de Trabajo del Artículo 29 que en las Directrices
WP250, determina cuando sería probable que entrañe un riesgo”.

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

89/173

En primer lugar, cabe señalar que las citadas Directrices WP250 del GT 29
sobre la notificación de las violaciones de la seguridad de los datos
personales de acuerdo con el Reglamento 2016/679 hacen referencia al
factor riesgo como desencadenante de la notificación y sus excepciones
distinguiendo el deber de notificación a las autoridades de protección del
deber de comunicación a los afectados, que tienen un umbral diferente de
valoración del riesgo, señalando expresamente lo siguiente:

“Aunque el RGPD introduce la obligación de notificar una violación, no
es obligatorio hacerlo en todas las circunstancias:

• La notificación a la autoridad de control competente es obligatoria a
menos que sea improbable que una violación constituya un riesgo para
los derechos y las libertades de las personas.
• La comunicación de una violación a la persona solo se realizará
cuando sea probable que entrañe un alto riesgo para sus derechos y
libertades.

(…) Como se ha explicado anteriormente, la notificación de una
violación es obligatoria a menos que sea improbable que constituya un
riesgo para los derechos y las libertades de las personas, y el factor
clave que exige la comunicación de una violación a los interesados es
cuando sea probable que entrañe un alto riesgo para los derechos y las
libertades de las personas. Este riesgo existe cuando la violación puede
dar lugar a daños y perjuicios físicos, materiales o inmateriales para las
personas cuyos datos han sido violados. Ejemplos de tales daños y
perjuicios son la discriminación, la usurpación de identidad o el fraude,
la pérdida financiera y el daño para la reputación(…)”

Por tanto, para aplicar la excepción del deber de notificar la brecha a esta
agencia sería necesario que fuera improbable que la brecha constituya un
riesgo para los derechos y libertades de las personas. Es indiferente si el
riesgo es alto, medio, o bajo, y no se requiere que exista una certeza de ese
riesgo, sino una mera probabilidad.

En el presente supuesto, no existe duda de que hay una probabilidad de que
la brecha constituya un riesgo para los derechos y libertades de las personas
cuyos datos se hallasen incluidos en la tabla ***TABLA.1, toda vez que:

o La reclamada comprobó que la totalidad de los registros que se hallaban
en la muestra (17 registros) se hallaban incluidos en la referida tabla,
coincidiendo hasta los códigos identificadores de cliente, que se generan
automáticamente por la base de datos, y que la plataforma en la que se
hallaban se hallaba desactualizada, con acceso a internet en su
***SERVICIO.1 y adolecía de múltiples vulnerabilidades que podrían ser
hipotéticamente el vector de entrada. Si bien no existía certeza de que

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

90/173

éstas fueran el vector de entrada ni de que el actor malicioso dispusiera de
registros correspondientes a casi 1 millón de personas, si existía una
probabilidad de que así fuera.

o Y además, no cabe duda de que concurría un riesgo de que el ciber
.atacante o las personas a las que éste pudiera transferir los datos cuya
venta se estaba ofertando desde el 5 de abril de 2023, utilizasen los datos
personales presuntamente robados para cometer ilícitos de usurpación de
identidad, fraude, pérdida financiera...etc que las Directrices W250 califican
como claro supuesto de riesgo.

Y ello concurre aun cuando es cierto que la muestra de 17 registros
contenida en el anuncio no publicó el nombre y apellidos, enmascarando
los mismos según indicaba el INCIBE, porque los datos no se hallaban
cifrados, dado que el ciber atacante disponía de los mismos y los ha
proporcionado al completo al inspector al entregarle la segunda muestra de
1000 registros. La reclamada debió además entender que era altamente
probable que el ciber atacante dispusiera del contenido de dichos datos,
aunque no los hubiera publicado, dado que aparecían los campos en la
muestra. Y además, ya disponía de datos identificativos suficientes, como
el DNI, el domicilio, o número de teléfono de los titulares que le hubieran
posibilitado cometer estas usurpaciones de identidad, o fraudes sin
necesidad de disponer del nombre y apellidos.

Esta interpretación se confirma por las Directrices 1/2021 sobre ejemplos
de notificación de violaciones de la seguridad de los datos personales
adoptadas el 14 de diciembre de 2021 por el CEPD, que despejan todo tipo
de dudas al respecto del riesgo concurrente en supuestos de “Material robado
que almacena datos personales no cifrados” que se analiza como CASO N.º
11, señalando que: “Durante la evaluación del riesgo, el responsable del
tratamiento debe tener en cuenta las posibles consecuencias y efectos
adversos de la violación de la confidencialidad. Como consecuencia de la
violación de la seguridad, los interesados afectados pueden sufrir usurpación
de identidad recurriéndose a los datos disponibles en el dispositivo robado,
por lo que se considera que el riesgo es elevado.”

A mayor abundamiento, en caso de duda, las Directrices W250, señalan con
claridad que el responsable del tratamiento debe pecar por exceso de
precaución y notificar: “Por tanto, a la hora de evaluar el riesgo que puede
entrañar una violación, el responsable del tratamiento debe tener en cuenta
una combinación de la gravedad del impacto potencial en los derechos y las
libertades de las personas y la probabilidad de que este se produzca.
Evidentemente, cuando las consecuencias de una violación son más graves, el
riesgo es más elevado y, del mismo modo, cuando la probabilidad de que se

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

91/173

produzcan es mayor, el riesgo también aumenta. En caso de duda, el
responsable del tratamiento debe pecar por exceso de precaución y notificar.”

En conclusión, de lo expuesto se deduce que existía un deber de notificar la
brecha y por tanto, ésta debió hacerse dentro del plazo máximo de 72 horas
desde que CECOTEC tuvo un grado de certeza razonable de que el
ciberataque había afectado a su plataforma y el ciberatacante disponía de, al
menos, los 17 registros que aparecían en el anuncio.

QUINTA. - INEXISTENCIA DE LA INFRACCIÓN DEL ART 34 RGPD.
NOTIFICACIÓN A LOS INTERESADOS.

De acuerdo con lo expuesto en el hecho probado sexto de esta propuesta, consta
acreditado en el procedimiento que la reclamada no comunicó la brecha a los 6
afectados que constaban en la muestra inicial proporcionada por el anuncio del
actor malicioso, y tampoco se ha informado a esta Agencia de que se haya
comunicado la misma a los 933 afectados cuyos datos personales se contienen
en la segunda muestra que fue proporcionada al inspector de este procedimiento.

En sus alegaciones, la reclamada manifiesta su intención de no comunicar la
brecha, persistiendo en su conducta infractora, incluso después de conocer
los motivos detallados por los que el acuerdo de inicio consideraba que hubiera
sido y sigue necesario comunicar la brecha a los afectados.

o Principalmente, CECOTEC considera que no existe la infracción dado que no
se ha acreditado que la brecha de datos personales sufrida por CECOTEC
haya entrañado un “alto riesgo” para los derechos y libertades de los
interesados con la consecuente obligación de notificar a los mismos más allá
de la valoración subjetiva llevada a cabo por la instructora, que dicho sea de
paso, fue designada en dicho acuerdo de inicio, comenzando sus funciones al
iniciarse la instrucción.

A diferencia de lo que señala la reclamada, no se considera que la valoración
realizada en el fundamento de derecho XII del acuerdo de inicio fuera
subjetiva, sino que se basó en las evidencias que había reconocido la propia
reclamada, y motivó con exhaustividad los motivos por los que se entiende
que la brecha entrañaba un alto riesgo, y por los que no concurre ninguna de
las excepciones al deber de comunicar que están previstas por el artículo 34.

Entrando en el análisis de la cuestión controvertida, señala el artículo 34 del
RGPD que «Cuando sea probable que la violación de la seguridad de los
datos personales entrañe un alto riesgo para los derechos y libertades de las
personas físicas” el responsable la comunicará a los interesados sin dilación
indebida.

De nuevo se habla de probabilidad, no es necesario que exista certeza para
que exista deber de comunicar la brecha a los afectos. Como señala la
reclamada, se eleva el umbral de riesgo exigido respecto a la notificación de
la brecha, y es necesario que exista probabilidad de que la brecha entrañe un
alto riesgo.

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

92/173

En relación con los motivos por los que se consideró que la brecha no
entrañaba alto riesgo, señala la reclamada que:

“CECOTEC inició las comprobaciones oportunas desde el momento
inicial que se tuvo conocimiento del email del INCIBE y se contactó con
ellos telefónicamente, y aunque inicialmente tuvo dudas acerca de la
certeza de la brecha pero ésta fue finalmente notificada a la Autoridad de
Control conforme fue obteniendo información al respecto.

En este marco, se llevó a cabo internamente una valoración sobre el
“alto riesgo” en base a la información objetiva que disponía al tiempo de
conocer la brecha en base a los factores indicados en Directrices 9/2022
sobre la notificación de violaciones de datos personales en virtud del
RGPD de fecha 28 de marzo de 2023.
-Respecto a la naturaleza, la sensibilidad y el volumen de los datos
personales: Se trataba datos de contacto no completos ni de categoría
especial.
-Respecto al volumen de datos: Acreditados sólo 6 datos de personas
reales.
-Respecto a la facilidad de la identificación de los individuos: Era
compleja habida cuenta que no figuraban los nombres y apellidos de los
interesados, ni hay documentación asociada.
-Respecto al tipo de violación: Afectó a la confidencialidad de los datos
por un tercero no autorizado, pero no a otras esferas como la
disponibilidad e integridad.
- Respecto a la gravedad de las consecuencias para las personas: Se
consideró que no resultaba grave dado que no son datos de categoría
especial, la suplantación de identidad no es automática ni sencilla al no
constar nombre y apellidos de los afectados, ni por otro lado, consta
acreditada.
-Respecto a las características del individuo: No se trataba de sujetos
vulnerables ni de menores de edad.
Tras dicha evaluación interna y acorde al resultado de la herramienta
COMUNICA BRECHA facilitada por la propia AEPD, CECOTEC no
estimó necesario comunicar la brecha.”

Sin embargo, la reclamada no realiza una adecuada valoración del riesgo
concurrente, toda vez que no tiene en cuenta la totalidad de los factores
concurrentes para evaluar la concurrencia de este riesgo a los que hacen
referencia las Directrices W250 del GT29, que no se limitan a valorar la
únicamente la tipología de datos, ni del número de personas afectadas como
señala la reclamada.

Al evaluar los factores de riesgo para las personas derivado de una brecha de
confidencialidad de datos personales, el responsable del tratamiento debe
tener en cuenta las circunstancias específicas de la violación, incluida la
gravedad del impacto potencial y la probabilidad de que esto ocurra.

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

93/173

Por tanto, el GT29 recomienda que la evaluación tenga en cuenta los criterios
que señala la reclamada, como la naturaleza, el carácter no sensible de los
datos personales afectados, y el volumen de datos personales afectados que
la reclamada conocía en el momento de notificar la brecha.

Pero también concurrían otra serie de factores que las directrices señalan
como influyentes para determinar la concurrencia de alto riesgo, como la
facilidad de identificación de las personas, y la gravedad de las
consecuencias para las personas.

Así pues, por una parte, las Directrices señalan que: “Un factor importante a
tener en cuenta es lo fácil que será para una parte que tenga acceso a datos
personales comprometidos identificar a personas específicas, o comparar los
datos con otra información para identificar a esas personas. Dependiendo de
las circunstancias, la identificación podría ser posible directamente a partir de
los datos personales violados sin necesidad de realizar una investigación
especial para descubrir la identidad de la persona, o cotejar los datos
personales con los de una persona en particular podría ser extremadamente
difícil, pero esto aún sería posible en determinadas condiciones. La
identificación sería posible de forma directa o indirecta a partir de los datos
violados, pero también podría depender del contexto específico de la
violación y el acceso público a datos personales relacionados. Esto puede ser
más relevante para las violaciones de la confidencialidad y la disponibilidad”.

Y por otra parte, las directrices señalan que hay que valorar también la
gravedad de las consecuencias para las personas, indicando que: “El hecho
de que el responsable del tratamiento tenga constancia de que los datos
personales están en manos de personas cuyas intenciones se desconocen o
son posiblemente maliciosas puede influir en el nivel de riesgo potencial.
Puede producirse una violación de la confidencialidad por la que se revelen
datos personales a un tercero, tal como se define en el artículo 4, apartado
10, o a otro destinatario por error”.

Con más motivo cabe aplicar este factor de riesgo en el supuesto presente,
en el que no ha sido posible identificar al actor malicioso, y la base de datos
se halla a la venta en un foro de la dark web desde el 5-4-23, según disponen
las citadas Directrices, que indican que: “También se debe tener en cuenta la
permanencia de las consecuencias para las personas cuando se considere
que el impacto es mayor si los efectos son a largo plazo.

Por todo lo expuesto, cabe desestimar las alegaciones efectuadas, toda vez
que se considera que CECOTEC no ha realizado una adecuada valoración de
todos los factores de riesgo concurrentes, que se señalan en las Directrices
W250 del GT29, concluyendo erróneamente en que no existe una
probabilidad de que la violación de seguridad entrañase un alto riesgo, puesto
que no tuvo en cuenta los factores relacionados con la facilidad para

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

94/173

identificar a las personas afectadas y la gravedad de los daños que se
podrían producir en el momento en que detectó la existencia de la brecha,
que afectaba a 6 personas reales.

No cabe duda, pues, de que con fecha de 14 de abril de 2024 tuvo
conocimiento de que se había producido una brecha que entrañaba una
probabilidad de alto riesgo para estas 6 personas afectadas, por lo que la
reclamada tenía la obligación de comunicarles la brecha, como mínimo, a
estas 6 personas, tal y como señala el artículo 34 del RGPD. Por ello, a la
fecha del acuerdo de inicio, se imputó una infracción administrativa y se fijó
una sanción inicial de 40.000 euros, por no haber comunicado la brecha a
estas 6 personas cuya filtración de datos se conocía desde que se realizaron
las primeras investigaciones.

A la vista de la instrucción practicada, concurren motivos para reevaluar el
alcance de afectados, por lo que el responsable del tratamiento debe
reevaluar la probabilidad de riesgo concurrente a la vista de los nuevos
hechos acreditados durante la instrucción a los efectos previstos en las
citadas Directrices W250 y las Directrices 9/22 sobre notificación de brechas.

Así pues, tal y como consta en los hechos probados tercero y quinto, se ha
acreditado durante la instrucción del procedimiento que la brecha afectó a
más de 6 personas, ascendiendo los afectados, como mínimo, a las 933
personas físicas cuyos datos personales se incluían en la muestra que el
actor malicioso proporcionó al inspector.

En el acuerdo de inicio se puso de manifiesto que el actor malicioso había
proporcionado esta segunda muestra con 1000 registros al inspector, de la
que se dio traslado a la empresa reclamada, cuando solicitó copia del
expediente, entregándose dicho listado a la misma el 30 de abril de 2024.

Tal y como se ha hecho constar mediante Diligencia, dentro de dicha muestra
constan los datos personales de un total de 933 personas con DNI
identificado.

La reclamada disponía de dicha muestra de 1000 registros desde que recibió
la copia del expediente el 30 de abril de 2024. Y sin embargo, no consta
tampoco que la reclamada ampliase la investigación inicial y realizase el
pertinente cotejo y comprobación de datos, comparando dicha muestra con
los datos incluidos en su base de datos, como lo ha hecho esta instructora,
incumpliendo con ello su deber de reevaluar este riesgo, y valorar si procedía
realizar dicha comunicación a todos estos afectados.

Y es que no cabe lugar a dudas que el actor malicioso obtuvo estos 1000
registros de la tabla ***TABLA.1 de la reclamada, porque coincidían la
totalidad de los registros, incluidos los 4 códigos identificadores que
solamente se pueden obtener si se accede a la base de datos.

Por tanto, de acuerdo con las evidencias que se hacen constar en los hechos
probados tercero y sexto, cabe entender que el total acreditado de

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

95/173

afectados por la brecha es de 933 personas físicas que coinciden en la
muestra y tabla de la reclamada, debiendo confirmarse la comisión de la
infracción del artículo 34 del RGPD, y proponerse un aumento de la sanción a
imponer por la misma, dado que el acuerdo de inicio únicamente tuvo en
cuenta un alcance de 6 personas, demostrándose durante la instrucción
practicada que el número de afectados por la brecha ascendió a un mínimo
de 933 personas.

o Por otra parte, CECOTEC señala también que se pretende evitar la “fatiga
innecesaria de las notificaciones”, a la que dice que se refieren las Directrices
9/2022, sobre la notificación de las violaciones de la seguridad de los datos
personales en el marco del RGPD, que señalan que el umbral para comunicar
la brecha a los particulares es más elevado que para notificar a las
autoridades de supervisión.

Es cierto que las mencionadas Directrices 09/22 señalan que “Por tanto, el
umbral para la comunicación a las personas es más elevado que para la
notificación a las autoridades de control y, por tanto, no se exigirá la
comunicación de todas las violaciones a las personas, protegiéndolas así de
un exceso de notificaciones” pero la fatiga en las comunicaciones se
produciría únicamente en los supuestos en los que no existe obligación de
notificar a la autoridad (por ser improbable que exista un riesgo de
vulneración de derechos y libertades), y en los que no existe obligación de
comunicarla a los afectados ( por no concurrir una probabilidad de que la
brecha entrañe un alto riesgo), y aún así se decide hacer la notificación
/comunicación pese a no ser necesario.

En el presente supuesto, insistimos, tanto la notificación a esta Agencia como
la comunicación a los afectados eran un deber imperativo para el
responsable, y no una potestad, por lo que no concurre fatiga alguna.

o Por último, señala CECOTEC que esta agencia dispone de las competencias
correctivas que tiene atribuidas por el artículo 34.4 del RGPD, y en base a las
mismas, debería haber indicado a CECOTEC que procediese a la notificación
de la brecha a los interesados, si consideraba que ello era preceptivo, durante
la fase de actuaciones previas o al trasladarle el acuerdo de inicio del
presente procedimiento Y se indica que: “no alcanza a entender esta parte
que esta orden se haya instruido en otros procedimientos seguidos ante la
AEPD – tal y como se desprende, entre otras, de la resolución, de fecha 17
de febrero de 2022, recaída en el PS Nº E/06660/2021 o en los expedientes
de actuaciones previas de investigación E/06214/2020, y E/06177/2020 y en
el presente procedimiento se haya ignorado, íntegramente, la posibilidad de
ofrecer dicha posibilidad previa CECOTEC, optando directamente por la
apertura del presente Acuerdo de Inicio”.

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

96/173

En primer lugar, el Principio de responsabilidad proactiva que inspira la
regulación del RGPD implica que sea obligación del propio responsable
determinar cuándo debe producirse esta comunicación de la brecha,
debiendo, como ya se ha dicho, notificar a esta agencia y comunicarla a los
afectados en caso de duda. Sin que esta autoridad o ningún otro organismo
tengan obligación de advertirle de ello.

Sorprende esta afirmación, toda vez que la reclamada ha manifestado en todo
momento desde la primera comunicación realizada dentro de este expediente
que no existía esta necesidad de comunicar la brecha y continúa insistiendo
en ello en sus escritos de alegaciones frente al acuerdo de inicio, en contra
del criterio de esta Agencia, que se ha manifestado en diversas ocasiones al
respecto.

Ya durante la fase de actuaciones previas de investigación del procedimiento
se requirió informe sobre los motivos por los que no se había comunicado la
brecha, y la reclamada contestó que entendía no necesario comunicar la
brecha a estas 6 personas. Ante dicho reconocimiento de ausencia de
comunicación se entendió que concurrían evidencias de comisión de una
infracción del artículo 34 del RGPD, motivando el acuerdo de inicio de forma
exhaustiva porqué se entendía necesario imputar dicha infracción. En
concreto, dedicó el fundamento de derecho XII, al incumplimiento del deber
del artículo 34 del RGPD, señalando en el fundamento de derecho XV dentro
de las medidas correctivas que la reclamada debería: “Acreditar en el plazo
de 15 días hábiles a esta Agencia que la entidad reclamada ha comunicado la
brecha de datos personales producida a los afectados cuyos datos se han
visto afectados por el ciberataque, en los términos y condiciones previstos por
el artículo 34 del RGPD”.

Medida correctiva que, por cierto, no se ha cumplido hasta el momento,
deduciéndose de las alegaciones presentadas que la reclamada no tiene
intención de hacerlo, por no considerarlo necesario.

o Por último, respecto a la alegación referida a que: “La AEPD no ha aplicado, a
este supuesto de hecho, el mismo criterio que ha tenido en cuenta en otras
resoluciones, desconociendo esta parte la motivación jurídica que
fundamenta tal decisión”, cabe señalar que la motivación de apertura del
sancionador es exhaustiva en este supuesto, en el que concurrían evidencias
irrefutables de la falta de comunicación a los afectados, que había sido
reconocida por la reclamada, y persiste en el momento actual. Los supuestos
alegados por la reclamada (PS Nº E/06660/2021 o en los expedientes de
actuaciones previas de investigación E/06214/2020, y E/06177/2020 se
refieren a expedientes de actuaciones previas de investigación en cuyo
informe de actuaciones previas el inspector determinaba la necesidad de
comunicación, pero que no finalizaron con el inicio de un expediente
sancionador, sino que fueron archivados ante la falta de evidencias de
comisión de una infracción. Por lo tanto, partiendo de supuestos de hecho
totalmente diferentes al presente, y aún siendo potestativo para la autoridad
de control adoptar medidas correctivas durante la fase de investigación, lo
cierto es que no existe agravio comparativo alguno. Además, hay que

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

97/173

considerar que se trata de expedientes tramitados en los años 2020 y 2021,
donde la situación jurídica era diferente, toda vez que todavía no se habían
dictado las Directrices 09/2022 del CEPD sobre notificación de brechas a las
que se ha hecho referencia.

De todo lo expuesto se deduce que deben desestimarse también las
alegaciones de la reclamada en relación con la falta de comunicación de la
brecha a los afectados, puesto que ha quedado acreditado que la reclamada
debió comunicar la brecha a un total de 6 personas cuando tuvo conocimiento
de la brecha el 13 de abril de 2023, y ampliar dicha comunicación al total de
933 personas, una vez recibió copia del expediente el 30 de abril de 2023.

No habiendo cumplido con este deber, procede mantener la imputación de la
infracción del artículo 34 del RGPD y proponer una sanción mayor que la que
fue inicialmente fijada, en los términos que serán expuestos en los
Fundamentos de Derecho XIV y XVI de esta propuesta.

SEXTA. - FALTA DE PROPORCIONALIDAD EN LA IMPOSICIÓN DE LAS
SANCIONES Y AUSENCIA DE GRADUACIÓN.

- Con carácter previo, CECOTEC informa a la AEPD de que la plataforma
‘***SOFTWARE.1’, está totalmente deshabilitada, cesando el tratamiento de
datos.
Al respecto, cabe aclarar que, si bien la inhabilitación del acceso a internet de
la plataforma si se tiene por acreditado al haber sido este hecho comprobado
y diligenciado por esta instructora con fecha de 3 de junio de 2024, no se
aporta acreditación alguna que justifique que realmente se ha cesado el
tratamiento de datos personales realizado por CECOTEC respecto a la
plataforma, lo cual requiere de acreditación independiente puesto que la
inhabilitación de la plataforma no implica que se haya cesado en el
tratamiento de los datos personales que continúan siendo almacenados en la
plataforma de la reclamada, hasta que la misma justifique que ha procedido a
su bloqueo y/o supresión.

Y, cabe señalar también que la inhabilitación del acceso a internet de la
plataforma no puede actuar como eximente ni como atenuante de la
responsabilidad, toda vez que se ha ejecutado incluso después de haberse
acordado el inicio de este expediente. Únicamente podrá tener el efecto de no
incluir esta inhabilitación entre las posibles medidas correctivas que sea
procedente ordenar al respecto del tratamiento de conformidad con el artículo
58 del RGPD.

- Y lo mismo cabe decir respecto a la última afirmación realizada, respecto a
“Por último, se informa que la Compañía sigue mejorando, estando inmersa
actualmente en una auditoría de cumplimiento normativo RGPD y en la
actualización de los análisis de riesgos, realización de EIPD y verificación de
medidas de seguridad. Y que se muestra dispuesta a aceptar cualquier
propuesta de mejora.”

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

98/173

- En segundo lugar, las alegaciones indican que: “No se ha contemplado por la
AEPD, por ahora y sin perjuicio del resultado de la instrucción, ningún criterio
de graduación de las sanciones que las pueda atenuar”, relacionando a
continuación una serie de factores que entiende deberían considerarse como
tal para reducir la sanción a imponer, sin aportar detalles ni acreditación
alguna que sustente las afirmaciones realizadas.

En primer lugar, cabe señalar que la normativa de protección de datos, no
contiene un listado de circunstancias atenuantes y agravantes como tal, sino
una enumeración de circunstancias de graduación de la sanción, que de
acuerdo con las Directrices dictadas por el CEPD para el cálculo de multas
(Guía de multas a la que ha hecho referencia anteriormente la reclamada),
establecidas en el artículo 83.2 del RGPD, que pueden actuar como factores
neutrales, atenuantes o agravantes, en función de las circunstancias
concurrentes. Listado que se amplía por las circunstancias de graduación
contenidas en el artículo 76 de la LOPDGDD.

En general, se observa que la mayor parte de las circunstancias que señala la
reclamada en sus alegaciones no han sido previstas como atenuante por el
legislador europeo ni nacional, por lo que no podrían ser consideradas como
tal por esta autoridad de control. Recordemos que las administraciones
públicas encargadas de aplicar las normas están sujetas al Principio de
legalidad, sin que estén dotadas de libertad para decir aplicar circunstancias
atenuantes o agravantes que no vengan tasadas expresamente en la
normativa aplicable, y se hayan acreditado de forma fehaciente.

Por tanto, la aplicación de circunstancias o factores atenuantes que reduzcan
a la baja la sanción de una infracción solo es posible en los supuestos
legalmente tasados en los artículos 83.2 del RGPD y 73 de la LOPDGDD, y
siempre que conste acreditada su concurrencia, no bastando con la mera
afirmación.

A la vista de los hechos probados, se considera que no concurren en el
supuesto presente los siguientes factores atenuantes alegados por la
reclamada:

o “Por los hechos descritos en el Acuerdo de Inicio mi mandante no ha
obtenido beneficio alguno, recordemos que se trata del ataque de un
tercero no autorizado.”

Este criterio de graduación se establece en el artículo 76.2.c) de la
LOPDGDD de acuerdo con lo previsto en el artículo 83.2.k) del RGPD,
según el cual las multas administrativas se impondrán teniendo en cuenta
cualquier “factor agravante o atenuante aplicable a las circunstancias del
caso, como los beneficios financieros obtenidos o las pérdidas evitadas,

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

99/173

directa o indirectamente, a través de la infracción”, entendiéndose que
evitar una pérdida tiene la misma naturaleza a estos efectos que la
obtención de beneficios.

Tal y como señala la Guía de Multas del CEPD: “El artículo 83, apartado 2,
letra k), del RGPD otorga a la autoridad de control margen para tener en
cuenta cualquier otro factor agravante o atenuante aplicable a las
circunstancias del caso, pero como su propio texto literal indica, contiene
factores o circunstancias agravantes y atenuantes.

Por tanto, en esta circunstancia se deja abierta la posibilidad de que la
autoridad de control de cada país prevea en sus legislaciones nacionales
otras circunstancias, entre las que se encuentran las relacionadas con el
contexto socioeconómico en el que opera el responsable o encargado del
tratamiento, las relativas al contexto jurídico y las relativas al contexto del
mercado. Esto es, para que sean aplicables, habrán de preverse en la
legislación nacional, como ocurre en el caso español, donde el artículo 76.
2.c) de la LOPDGDD hace referencia a los beneficios económicos,
señalando lo siguiente:
““2. De acuerdo a lo previsto en el artículo 83.2.k) del Reglamento (UE)
2016/679 también podrán tenerse en cuenta:
c) Los beneficios obtenidos como consecuencia de la comisión de la
infracción.”
Por lo que respecta a la ausencia u obtención de beneficios económicos de
la infracción, la cuestión es clara, no admite dudas, puesto que la Guía de
Multas determina claramente, lo que la jurisprudencia ha venido
recogiendo de forma reiterada en derecho sancionador que es lo siguiente:
“110. En particular, el beneficio económico de la infracción podría ser una
circunstancia agravante si el caso proporciona información sobre los
beneficios obtenidos como resultado de la infracción del RGPD”

Por tanto, cabe desestimar la aplicación de esta atenuante porque los
beneficios económicos únicamente pueden operar como agravante cuando
se haya acreditado que el sancionado ha obtenido los mismos a raíz de la
comisión de la infracción, lo que no es el caso, por lo que no se ha
aplicado esta agravante al graduar la sanción. Sin que sea posible, por no
estar prevista en la normativa aplicable, que la ausencia de obtención de
beneficios económicos pueda operar como atenuante de la
responsabilidad. Lo que, por otra parte, tampoco se acredita por la
reclamada.

Así, valorar la ausencia de beneficios como una atenuante anularía el
efecto disuasorio de la multa, en la medida en que minora el efecto de las
circunstancias que inciden efectivamente en su cuantificación, reportando
al responsable un beneficio al que no se ha hecho merecedor. Sería una
rebaja artificial de la sanción que puede llevar a entender que infringir la

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

100/173

norma sin obtener beneficios, financieros o del tipo que fuere, no le
producirá un efecto negativo proporcional a la gravedad del hecho infractor.

o “No consta reiteración de conducta, antecedentes o intencionalidad de
causar daño por parte de CECOTEC”.

En primer lugar, cabe señalar que la falta de antecedentes, que
suponemos que se refiere a antecedentes penales o procedimientos
administrativos previos tramitados frente a la misma, no está prevista como
atenuante ni como agravante, sin que se hayan tenido en cuenta para
graduar la sanción a imponer.

En segundo lugar, la intencionalidad no se valora como una atenuante sino
que es una circunstancia de graduación de la sanción contenida en el
artículo 83.2.b) del RGPD, que fue valorada en el acuerdo de inicio al
graduar la sanción de cada una de las infracciones imputadas, donde se
ha fijado claramente qué grado de imprudencia se entendía cometido, lo
que va a realizarse igualmente en la presente propuesta. Por tanto, sí se
está valorando que las infracciones se han cometido en grado de
imprudencia y no con intencionalidad, en cuyo caso la sanción sería mucho
más alta, teniendo en cuenta que los límites legales de cada una de ellas
pueden ascender al 2% o 4% del volumen de negocios de la empresa.

Por último, la reiteración de la conducta opera únicamente como
circunstancia agravante cuando concurren los requisitos previstos en el
están previstas también como una circunstancia agravante, que no ha sido
de aplicación en este supuesto, prevista en el artículo 83, apartado 2, letra
e), del RGPD, que se refiere a: “toda infracción anterior pertinente
cometida por el responsable o encargado del tratamiento “.

El carácter agravante de la reincidencia es inherente a su naturaleza, sin
que quepa entender que la misma pueda operar a contrario sensu dado
que “la no comisión de una infracción anterior pertinente cometida por el
responsable o encargado” no ha sido prevista legalmente como atenuante,
sino que deberá tratarse como un factor neutral, esto es, que no tenga
efecto a favor ni en contra de la parte sancionada, tal y como dispone el
CEPD en la Guía de multas, señalando que:

“La existencia de infracciones anteriores puede considerarse un factor
agravante en el cálculo de la multa. El peso dado a este factor debe
determinarse teniendo en cuenta la naturaleza y la frecuencia de las
infracciones anteriores. Sin embargo, la ausencia de infracciones
anteriores no puede considerarse un factor atenuante, ya que el
cumplimiento del RGPD es la norma. Si no hay infracciones anteriores,
este factor puede considerarse neutral.”

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

101/173

El carácter de agravante y no atenuante es doctrina consolidada de la
jurisprudencia española en materia de derecho administrativo sancionador.
En materia de protección de datos personales, cabe citar, por ejemplo, la
Sentencia de la AN, de 05/05/2021, rec. 1437/2020, que indica:
“Considera, por otro lado, que debe apreciarse como atenuante la no
comisión de una infracción anterior. Pues bien, el artículo 83.2 del RGPD
establece que debe tenerse en cuenta para la imposición de la multa
administrativa, entre otras, la circunstancia "e) toda infracción anterior
cometida por el responsable o el encargado del tratamiento". Se trata de
una circunstancia agravante, el hecho de que no concurra el presupuesto
para su aplicación conlleva que no pueda ser tomada en consideración,
pero no implica ni permite, como pretende la actora, su aplicación como
atenuante”

o “Asimismo, no están acreditados daños y perjuicios ni existe informe sobre
hipotéticos daños, así como tampoco existe ninguna reclamación por parte
de algún usuario”.

Nuevamente, ninguna de estas circunstancias está prevista en la
normativa aplicable como circunstancia de graduación de la sanción, por lo
que no puede considerarse como factor atenuante ni agravante de la
responsabilidad, sin que la reclamada alegue aplicación de norma alguna.

o “Respecto al tratamiento de los datos, la brecha no afecta datos de
categoría especial ni datos de menores de edad”.

La circunstancia de graduación contenida en el artículo 83.2. “g) las
categorías de los datos de carácter personal afectados por la infracción”
opera como factor agravante, sin que se haya incluido la misma al graduar
la sanción, por entender probado la alegación formulada desde un inicio
por la reclamada de que los datos personales objeto de tratamiento
contenidos en la tabla “***TABLA.1” que fue objeto del ciberataque no
incluían datos de carácter personal, tipificados en el artículo 9.1 del RGPD.

Respecto a la ausencia de datos de menores de edad, se entiende que
esta circunstancia no ha sido acreditada por la reclamada, que no aporta
base documental suficiente para que esta agencia pueda comprobar la
edad de las personas cuyos datos personales se incluían en la
mencionada tabla. No obstante, en caso de aplicarse, la misma está
prevista únicamente como factor agravante y no atenuante, según el
artículo 76.2, que se refiere a considerar: “f) La afectación a los derechos
de los menores”. Toda vez que, como las anteriormente alegadas, la
redacción del precepto es en positivo, refiriéndose a cuando se acredite
que los derechos de menores han sido afectados, y no a cuando no lo

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

102/173

hayan sido.

- Respecto a las medidas correctivas adoptadas, se señala que: “No se han
valorado las medidas correctivas adoptadas por CECOTEC sin haber sido
solicitadas o requeridas por la AEPD, conforme artículo 83, apartado 2, letra
i) cuando las medidas indicadas en el artículo 58, apartado 2, hayan sido
ordenadas previamente” contra el responsable o el encargado de que se
trate en relación con el mismo asunto, el cumplimiento de dichas medidas; y
letra c), que se refiere a «cualquier acción tomada por el responsable o el
encargado del tratamiento para mitigar los daños sufridos por los
interesados».

Antes de entrar a valorar si procede aplicar alguna de estas circunstancias
como factores atenuantes, cabe aclarar que la reclamada realiza
afirmaciones que no coinciden con los hechos probados del presente
procedimiento:

o Primero, respecto al listado de medidas correctivas adoptadas. Tal y
como se ha analizado al valorar la prueba en el fundamento de
derecho 3.2, para determinar si concurren las referidas atenuantes
se debe partir del listado de medidas correctivas cuya constancia
se tiene por justificada en el hecho probado octavo de esta
propuesta, que no coincide con el listado enumerado en el escrito
de alegaciones. E incluyen tanto las que fueron señaladas como
acreditadas durante la fase de investigación en el informe API,
como la inhabilitación del acceso a la plataforma desde internet que
se produjo con posterioridad a la apertura del procedimiento
sancionador, según se ha constatado en Diligencia de 3 de junio de
2024 por esta instructora.

o Por otra parte, la reclamada señala que ha adoptado estas medidas
sin requerimiento previo de esta AEPD, pero lo cierto es que no se
ha acreditado en qué fecha fue adoptada cada medida correctiva,
puesto que únicamente consta documentación fechada respecto a
las siguientes medidas:

Durante la fase de investigación, se aportó la siguiente
documentación acreditativa de medidas correctivas adoptadas tras
la brecha:

 (…)

Por otra parte, la inhabilitación del acceso a internet de la
plataforma, se produjo con posterioridad al acuerdo de inicio,
aunque no se aportó acreditación, habiendo sido diligenciado este
hecho el 3 de junio de 2024.

o Por último, no es cierto que el acuerdo de inicio no haya tenido en
cuenta la adopción de todas estas medidas correctivas, pues la

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

103/173

misma se valoró en el fundamento de derecho XV, relativo a la
adopción de las medidas correctivas por esta Agencia del artículo
58.2 del RGPD. La adopción de medidas dirigidas a corregir los
incumplimientos cometidos podría justificar, en su caso, que no se
adopten medidas correctivas por parte de esta Agencia. Pero la
adopción de este tipo de medidas que debieron ser adoptadas con
anterioridad a la brecha y no lo fueron, no puede actuar como
eximente de la responsabilidad, puesto que suponen la
consumación de las infracciones que se han imputado. Y tampoco
podrán ser consideradas como una circunstancia atenuante de la
graduación de la sanción, si no encajan en los supuestos que se
prevén expresamente en las letras f) y c) del artículo 83.2 del
RGPD.

En el presente supuesto, no cabe aplicar la atenuante prevista en el
art.83.2.c) que se refiere a «cualquier acción tomada por el responsable o
el encargado del tratamiento para mitigar los daños sufridos por los
interesados», puesto que no se cumplen los presupuestos exigibles para
su aplicación.

Así pues, en primer lugar, cabe descartar su aplicación puesto que las
medidas correctivas cuya adopción ha sido acreditada en el hecho probado
octavo no son acciones tomadas para “mitigar los daños sufridos por los
interesados”. CECOTEC niega en sus alegaciones que se hayan producido
daños a los interesados, solicitando incluso que se le aplique una
atenuante por ello, y afirma también que no es necesario comunicar la
brecha a los afectados en base a esta misma consideración. Por tanto, no
puede, al mismo tiempo, afirmar que ha mitigado los daños que dice que
no existen.

Analizando las medidas correctivas que han sido adoptadas, se confirma
que no cabe la aplicación de esta atenuante, puesto que todas las medidas
se dirigían a corregir esta situación de incumplimiento de la obligación
prevista en el artículo 32.1 del RGPD, referida a “medidas técnicas y
organizativas apropiadas para garantizar un nivel de seguridad adecuado
al riesgo, que en su caso incluya, entre otros (…). Es más, se observa que
siguen sin incluirse medidas de necesaria adopción, como la señalada en
el artículo 32.1 a) “seudonimización y el cifrado de datos personales”.

Por tanto, su finalidad es fortalecer la seguridad de la plataforma, como se
indicó expresamente en el escrito de Resp#1. Ninguna de ellas se dirige a
mitigar los daños producidos a los interesados.

A mayor abundamiento, cabe señalar que la reclamada no ha acreditado
que haya adoptado dichas medidas espontáneamente antes de tener
conocimiento del inicio de la investigación por esta agencia, lo que se
produjo el 8-8-23, al serle notificado el primer requerimiento de
investigación. Ello es también un factor que debe ser evaluado para
determinar si procede aplicar la misma, tal y como señala la Guía de
Multas del CEPD, hay que .

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

104/173

75. La adopción de medidas adecuadas para mitigar los daños
sufridos por los interesados puede considerarse un factor
atenuante, que disminuyendo el importe de la multa.
76. Las medidas adoptadas deben evaluarse, en particular, en
relación con el elemento de oportunidad, es decir, el momento en
que son aplicadas por el responsable o el encargado del
tratamiento, y su eficacia. En este sentido, es más probable que las
medidas aplicadas espontáneamente antes del inicio de la
investigación de la autoridad de control sea conocidas por el
responsable o encargado del tratamiento como un factor atenuante
que las medidas que se hayan aplicado después de ese momento.”

Por otra parte, respecto a la atenuante del artículo 83.2.f) del RGPD
referida al “Grado de cooperación con la autoridad de control para
subsanar la infracción y mitigar los posibles efectos adversos de la
infracción”, tampoco se cumplen los presupuestos de aplicación, toda vez
que, tal y como señala la Guía de Multas del CEPD:

“95. El artículo 83, apartado 2, letra f), exige que la autoridad de control
tenga en cuenta el grado de cooperación del responsable o del
encargado con la autoridad de control para subsanar la infracción y
mitigar los posibles efectos adversos de la infracción.

96. Antes de seguir evaluando el nivel de cooperación que el
responsable o el encargado del tratamiento haya establecido con la
autoridad de control, debe reiterarse que la obligación general de
cooperar incumbe al responsable y al encargado con arreglo al artículo
31 del RGPD, y que la falta de cooperación puede dar lugar a la
aplicación de la multa prevista en el artículo 83, apartado 4, letra a), del
RGPD. Por lo tanto, debe considerarse que el deber ordinario de
cooperación es obligatorio y, por lo tanto, debe considerarse neutral (y
no un factor atenuante).

97. Sin embargo, cuando la cooperación con la autoridad de control
haya tenido el efecto de limitar o evitar las consecuencias negativas
para los derechos de los particulares que de otro modo podrían haberse
producido, la autoridad de control puede considerar esto un factor
atenuante en el sentido del artículo 83, apartado 2, letra f), del RGPD,
reduciendo así el importe de la multa. Este puede ser el caso, por
ejemplo, cuando un responsable o encargado del tratamiento «ha
respondido de manera particular a las solicitudes de la autoridad de
control durante la fase de investigación en ese caso concreto, lo que ha
limitado significativamente el impacto en los derechos de las personas
como resultado»

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

105/173

Tal y como señala el CEPD, las medidas adoptadas por la reclamada tras el
ciberataque son el resultado del cumplimiento de una obligación del
responsable de todo tratamiento, prevista en el artículo 31 del RGPD, cuyo
incumplimiento podría determinar la incursión en otra infracción diferente e
independiente de las imputadas. De no adoptarse las mismas, ello puede
conllevar como consecuencia la comisión de una nueva infracción y la
aplicación de una sanción independiente de multa, fijada en el artículo
83.4.a) del RGPD. No es un factor atenuante sino neutral.

Se considera que en el supuesto presente no cabe aplicarlas como factor
atenuante, puesto que las medidas correctivas adoptadas no han sido
consecuencia de una “cooperación con la autoridad de control”, ya que la
mayor parte de estas fueron adoptadas durante la fase de investigación, sin
que se formulase ningún requerimiento para proceder a su adopción por
esta Agencia, y la adoptada con posterioridad al acuerdo de inicio, referida a
la inhabilitación de la plataforma, no fue incluida entre las posibles medidas
correctivas señaladas en el fundamento XV del acuerdo de inicio. Y además,
tampoco se ha acreditado, como ya se ha dicho, que su adopción “haya
tenido el efecto de limitar o evitar las consecuencias negativas para los
derechos de los particulares”.

- En tercer lugar, se señala en las alegaciones que “en general existe una falta
de proporcionalidad manifiesta al fijar la cuantía de la sanción: que el límite
cuantitativo máximo sea tan amplio no justifica esta cantidad, que debe
ajustarse a la capacidad económica y se considera desproporcionada según
la jurisprudencia y artículo 29 de la LRJSP.- y se alegan sentencias varias
como la STS de 2 de junio de 2003, Tribunal Supremo en su Sentencia de 29
de julio de 2014 (Sala de lo Contencioso-Administrativo, Sección 1ª).

Al respecto de ello, cabe confirmar que la graduación realizada en el acuerdo
de inicio fue proporcional, habiéndose motivado suficientemente las
circunstancias tenidas en cuenta para la fijación inicial de la sanción. Y que
las multas fijadas en la misma, no solo no fueron desproporcionadas, sino que
se fijaron a la baja considerando que las circunstancias concurrentes, pese a
la negativa de la reclamada a comunicar la brecha a los afectados.

Y es más, se considera que el acuerdo de inicio actuó con prudencia: (i)
partiendo de 6 afectados por la brecha en el caso de las infracciones del
artículo 5.1.f) y 34 del RGPD, lo que debe modificarse al alza a la luz de la
prueba practicada; (ii) proponiendo una sanción de 750.000 euros por la
infracción del artículo 32 del RGPD, pese a haberse constatado la situación
de desprotección absoluta en la que se hallaban los datos personales
contenidos en la plataforma ***SOFTWARE.1, cuando el límite máximo es del
2% del volumen de negocio de la empresa; (iii) e interpretando el plazo de
forma favorable a la reclamada, si bien cabe modificar a la baja este aspecto,

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

106/173

de acuerdo con la interpretación realizada en esta propuesta.

- Por último, la reclamada señala porqué entiende que las multas fijadas para
cada infracción resultan “totalmente desproporcionadas por no haberse
considerado las circunstancias siguientes” :

a. Respecto a las sanciones impuestas de 140.000€ por la
infracción del artículo 5.1.f) del RGPD y 750.000€ por la
infracción del artículo 32 del RGPD entiende la reclamada que
resultan totalmente desproporcionadas habida cuenta la ausencia
de prueba de que se haya materializado daño alguno y de que no
existe queja o reclamación de ningún usuario, unido a que los
datos accedidos de los 6 usuarios reales, no permitirían
actualmente una suplantación de identidad al no disponerse del
completo DNI/NIF y sólo del número y letra, ni tampoco de los
nombres y apellidos. Habiéndose adoptado medidas correctivas
sin ser requeridas por la AEPD procedería su graduación y
atenuación.

b. Respecto a la sanción impuesta de 100.000€ por la infracción del
artículo 33 del RGPD, en caso de apreciarse su concurrencia, la
cuantía deviene completamente desproporcionada habida cuenta
que la brecha se comunicó voluntariamente por CECOTEC, no
hay reclamación alguna de usuarios y que el retraso respecto a
esas 72 horas es tan sólo de sólo 3 días porque no se conocía el
total alcance de la violación, habiendo, asimismo, días festivos
dentro del citado plazo como se acreditó.

c. Respecto a la sanción impuesta de 40.000€ por la infracción del
artículo 34 del RGPD, indicar que en caso de apreciarse su
concurrencia, la cuantía deviene completamente
desproporcionada igualmente habida cuenta que, sólo hay
prueba de 6 interesados afectados reales, sus datos no son
sensibles o de categoría especial y no permitirían actualmente
una suplantación de identidad al no disponerse del completo
DNI/NIF y sólo del número y letra, ni tampoco de los nombres y
apellidos.

Con ello se reiteran los argumentos relativos a la falta de aplicación de los
factores que, a criterio de la reclamada, deben aplicarse como atenuantes,
cuya desestimación ya ha sido motivada, debiendo remitirnos a los
argumentos ya expuestos a los efectos de evitar reiteraciones innecesarias.

4.2. Contestación a las alegaciones formuladas tras recibir la copia del expediente, con
fechas de 8 y 13 de mayo de 2024.

Tras recibir la copia del expediente, CECOTEC presenta un segundo escrito de
alegaciones al acuerdo de inicio con fechas de 8/05/2024 y 13/05/2024 (en adelante,
Aleg AI #2), en el que “habiendo tenido acceso al expediente” formula, en síntesis 4
alegaciones complementarias a las realizadas:

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

107/173

PRIMERA. - AUSENCIA DE GRADUACIÓN.

Contiene las siguientes alegaciones que deben ser desestimadas en base a lo
siguiente:

o Respecto a que: “Consta en la página 222 del expediente administrativo
relativo a ‘EVIDENCIAS SIGNIFICATIVAS PARA LA GRADUACIÓN’ que por el
Inspector sólo se ha tenido en cuenta como criterio para la graduación la cifra
de volumen de negocios de CECOTEC para el ejercicio 2022”, se hace constar
que el acuerdo de inicio del expediente sancionador, que es al que compete
fijar la graduación inicial de la sanción a imponer por la comisión de cada
presunta infracción, no ha tenido en cuenta únicamente esta evidencia del
volumen de negocio, cuya mención en el informe del inspector no tiene
carácter exhaustivo ni limitante.

La prueba de ello es que dicho acuerdo de inicio contiene una descripción
detallada de las múltiples circunstancias de graduación que se han tenido en
consideración en cada infracción (fundamentos de derecho V, VIII, XI, y XIV),
que tienen en cuenta el volumen de negocio de CECOTEC como uno de los
puntos de partida para calcular el importe de la multa, pero gradúan la sanción
considerando otros múltiples factores que afectan a la naturaleza, duración,
gravedad de la infracción, el grado de negligencia cometido…etc.

o Respecto a las atenuantes, se reitera de nuevo que en el acuerdo de inicio se
mencionan sucintamente la gravedad, naturaleza y duración de cada una de
las infracciones, a juicio de la AEPD, pero no se ha contemplado por la Agencia
ningún criterio de graduación de las sanciones tendentes a su atenuación,
como ya se señaló en su primer escrito de alegaciones. Reconociendo con ello
que el acuerdo de inicio no gradúa la sanción considerando únicamente el
volumen de negocio, como acababan de señalar.

Se añade que: “Conforme a las Directrices 04/2022 del ‘European Data
Protection Board’ sobre el cálculo de las multas, siguiendo la estructura del
RGPD, después de haber evaluado la naturaleza, gravedad y duración de la
infracción, así como su carácter intencional o negligente de la infracción que,
es única y exclusivamente a lo que en este caso se ha ceñido la AEPD, la
autoridad de control debe tener en cuenta los factores agravantes y atenuantes
restantes enumerados en el artículo 83, apartado 2, del RGPD así como, las
categorías de datos personales afectados. Y sin embargo, repite CECOTEC
que la AEPD no ha valorado la escasa relevancia de las categorías de datos
personales afectados, ni que no hay reincidencia en infracciones por parte de
CECOTEC, y tampoco se ha tenido en cuenta el grado de cooperación con la
autoridad de control para mitigar riesgos.

Y repiten de nuevo que el artículo 76. 2 de la “LOPDGDD”) señala que se
deben tener en consideración dos circunstancias que no concurren en este

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

108/173

caso, para atenuar o agravar la sanción que son: c) Los beneficios obtenidos
como consecuencia de la comisión de la infracción. f) La afectación a los
derechos de los menores. Por tanto, al no concurrir deben ser considerados
para atenuar.
Siendo una reiteración de las alegaciones ya realizadas, y la única novedad la
mención a la Guía de Multas, que ya se ha examinado al contestar las primeras
alegaciones, nos remitimos a lo ya dicho al respecto.

SEGUNDA. – RESPECTO AL ATAQUE DE UN TERCERO (HACKER) Y LA
COMUNICACIÓN MANTENIDA POR EL INSPECTOR.

Se entiende que ya se ha dado respuesta respecto a todas las cuestiones planteadas
en esta alegación, dado que:

 Se insiste en el carácter de víctima de un ataque informático de CECOTEC, así
como que no constan acreditados tampoco daños y perjuicios y que no queda
desvirtuada la presunción de inocencia de CECOTEC. Lo que se ha tratado en el
fundamento de derecho 3.2 al fijar el hecho controvertido de la culpabilidad de la
reclamada respecto a la comisión de la infracción tipificada en el artículo 5.1.f) del
RGPD.

 Señalan que al recibir la copia del correo electrónico de 4 de agosto de 2023 que
el inspector remitió al actor malicioso, la reclamada ha observado que consta el
correo electrónico que podría ser un posible autor identificable, por lo que se
informa que se va a interponer la correspondiente denuncia ante la Policía
Nacional. Dicha copia se adjuntó en escrito posterior de 24-9-23, y quedó unida al
expediente. No obstante, la denuncia presentada se dirige a determinar la posible
responsabilidad penal que podría en su caso concurrir por la filtración de datos
derivada del ciber ataque. Pero no es relevante a los efectos de determinar la
responsabilidad administrativa concurrente por los incumplimientos de la normativa
de protección de datos que se imputan en el supuesto presente a la responsable
del tratamiento.

 Así mismo, la reclamada señala que no consta que esta AEPD le haya
proporcionado dicho dato en ningún requerimiento, lo que hubiera sido útil y no
hubiera perjudicado a la investigación; y que INCIBE tampoco se lo hizo constar,
señalando que no podía determinar si se trataba de información verídica. Como ya
se ha indicado al fijar los hechos probados reconocidos por la reclamada, en el
fundamento de derecho 3.1 de esta Propuesta, consta acreditado que el dato del
correo electrónico del usuario malicioso estaba en poder de la reclamada desde el
primer correo de alerta del INCIBE, que no solo mencionaba el nombre del usuario,
sino que proporcionaba un link al anuncio donde constaba toda la información
necesaria para poder contactar con el mismo.

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

109/173

Por todo lo expuesto, se considera debe mantenerse la imputación de las 4
infracciones administrativas que fueron imputadas en el acuerdo de inicio, con las
modificaciones que se derivan de la instrucción practicada, respecto a la graduación
de la sanción de las infracciones, tal y como se ha expuesto con detalle a lo largo de
este fundamento de derecho. >>
V.

Contestación a las alegaciones frente a la Propuesta de Resolución.

Con fecha de 18 de marzo de 2025, CECOTEC presenta escrito de alegaciones frente
a la propuesta de resolución del procedimiento, que no adjunta documentación alguna,
señalando en un total de seis alegaciones (previa, y primera a quinta), que cabe
desestimar en su totalidad en base a los siguientes motivos:

ALEGACIÓN PREVIA.- CECOTEC reitera las alegaciones y fundamentos ya
efectuados en los escritos previos, frente a los que procede la misma contestación que
fue realizada por la propuesta de resolución de este procedimiento, que se comparte
en su integridad por esta Agencia.

ALEGACIÓN PRIMERA.– Hechos controvertidos. Es un mero epígrafe introductorio de
las alegaciones segunda a cuarta, que no contiene alegaciones, en el que se
mencionan los que fueron declarados como 3 hechos controvertidos en la propuesta
de resolución.

o Número de registros finalmente afectados, entendiendo la Agencia que
se trataría de novecientos noventa y tres (993) registros.
o Eficacia de las medidas de seguridad técnicas y organizativas con las
que cuenta la Compañía.
o Determinación del dies ad quo en relación con el plazo de notificación
de la brecha de seguridad.

ALEGACIÓN SEGUNDA: Del número de registros finalmente afectados.

2.A. Principio de culpabilidad y proporcionalidad con relación a las infracciones
contempladas en los Arts. 5.1.f) y 32 del Reglamento General de Protección de Datos
(RGPD). Inexistencia de nexo de causalidad.

- En primer lugar, la reclamada recalca que no se ha acreditado que el ciber
atacante hubiera podido exfiltrar los datos personales contenidos en la tabla
“***TABLA.1” de su plataforma ***SOFTWARE.1 debido a la negligencia de la
empresa. Lo cual ya ha sido contestado en el Fundamento de Derecho 3.2, al
analizar el hecho controvertido del alcance de la brecha y número de registros
afectados, al que nos remitimos.

Queda, pues, resuelta la cuestión principal de acreditación de la culpabilidad de
la reclamada en la vulneración del deber de confidencialidad de los datos
personales que fueron accedidos y exfilitrados por el ciber atacante, que se
basa en no haber adoptado las medidas de cifrado y seudonimización que
hubieran evitado que el ciber atacante hubiera podido conocer y utilizar el

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

110/173

contenido de los datos personales que fueron exfiltrados, y no en el hecho de
no haber adoptado las medidas que impidieran el ciber ataque, lo que no ha
sido acreditado.

Ahora bien, cabe aclarar algunas afirmaciones que realiza la reclamada en esa
alegación respecto a que la propuesta de resolución señala que existen dudas
razonables sobre el alcance y dimensión de la tabla y de los registros, puesto
que no se ha podido acreditar cuál era el vector de entrada, el número total de
registros que decía tener el ciber atacante (más de 1.086.000) no coincide con
el número total de registros de la tabla, hay un campo añadido de ”date upd”
que no consta en la muestra del ciber atacante, y que el número de registros
coincidente era de 933 personas según la diligencia de 14 de febrero de 2025.
Al respecto, cabe aclarar lo siguiente:

o En primer lugar, que las dudas razonables declaradas en la propuesta de
resolución se referían al hecho de que el ciber atacante dispusiera del
1.086.185 registros que decía tener cuando contactó con el inspector,
pero nunca se ha declarado que exista duda razonable alguna de que el
mismo dispusiera de los 1000 registros que aportó al inspector como
muestra 2, declarando como hecho probado que el ciber ataque afectó a
un total de 933 personas cuyos datos personales se han podido
identificar al cotejar la citada muestra de 1000 registros con los datos de
la tabla ***TABLA.1 que fue proporcionada por CECOTEC en fase de
prueba, mediante Diligencia de 14 de febrero de 2025. Registros y
afectados cuya coincidencia no se ha negado por CECOTEC en sus
alegaciones frente a la propuesta de resolución, que se centra en negar
que el ciber ataque dispusiera del más de un millón de registros que
decía tener, lo que es una cuestión no controvertida en la propuesta de
resolución, como ya se ha dicho.

Por tanto, tras la presentación de alegaciones a la propuesta de
resolución, cabe afirmar con rotundidad que el alcance de la brecha está
fijado en 933 personas, y que ello es un hecho reconocido y no
controvertido por la reclamada a lo largo de su escrito.

o Por otra parte, en relación a la falta de coincidencia total de los campos de
registro contenidos en la muestra 2 y la tabla proporcionada por CECOTEC,
cabe señalar que, tal y como se ha hecho constar en el FD 2.1. “En
conclusión, de ello se desprende que la estructura de los datos contenidos
en las dos muestras proporcionadas por el actor malicioso y la tabla
“***TABLA.1” contenida en la antigua plataforma ***SOFTWARE.1 1.6
personalizada por CECOTEC dispone de 24 campos coincidentes, siendo
la única diferencia la inclusión de un campo adicional en el documento
Excel que se aporta por CECOTEC extraído de la tabla ***TABLA.1, que es
el referido a “date_upd”, correspondiente con la fecha actualizada que es
un campo que se genera automáticamente con cada actualización de la

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

111/173

plataforma realizada”. Habiéndose alegado esta falta de coincidencia en las
alegaciones a la propuesta de resolución, cabe señalar que: (i) este campo
de date_upd es compatible con la generación automática de un listado de la
base de datos que se añade al actualizar las tablas contenidas en la base
de datos; (ii) y la falta de coincidencia de este campo no excluye el hecho
de que el ciber atacante disponga de los datos personales que aparecen en
el resto de campos incluidos en la muestra, que sí coinciden íntegramente
con la tabla.

2.B) Ausencia de graduación de la sanción.

En relación con la ausencia de perjuicios causados a clientes afectados, y la
ausencia de culpabilidad, se señala por CECOTEC que pese a reconocerse
que no existe culpabilidad al estimar parcialmente esta alegación, no se han
tenido en cuenta en la propuesta esta falta de culpabilidad ni tampoco otros
hechos que han sido reconocidos expresamente por la Agencia como
elementos graduadores de la sanción impuesta aumentando incluso la cuantía
impuesta, lo que contraviene el principio de culpabilidad y proporcionalidad
toda vez que el artículo 29.3 Ley 40/2015.

- Por lo que respecta a la falta de acreditación de que CECOTEC fuera
culpable de no haber evitado la exfiltración de datos personales, siendo
víctima de un ciber ataque, y su afectación en la graduación de la sanción,
cabe remitirnos a lo que ya se ha dicho en el Fundamento de Derecho III.

Cabe añadir que esta Agencia ha considerado cumplido el requisito de
culpabilidad de cada una de las 4 infracciones imputadas en el presente
procedimiento, por entender en cada caso que concurría negligencia grave
de la reclamada, por la omisión de sus obligaciones como responsable del
tratamiento.

En el caso concreto que se está planteando, se ciñe a la culpabilidad en la
comisión de la infracción del artículo 5.1.f) del RGPD, en la que la
propuesta estimó parcialmente la alegación referida a que no se había
acreditado el nexo causal entre el acceso a los datos personales por el
ciber delincuente y las deficiencias y vulnerabilidades de la plataforma (por
la falta de adopción de las medidas que hubieran sido necesarias para
impedir la exfiltración de datos personales). Pero se entiende que se han
justificado en la propuesta y en esta resolución los motivos por los que esta
estimación parcial no es una estimación total, puesto que el requisito de
culpabilidad de esta infracción se cumple al no haberse adoptado la medida
de cifrado de los datos personales que hubiera impedido que aunque el
ciber atacante hubiera logrado extraer los datos, pudiera conocer su
contenido, hacerlo público, e utilizarlo.

Así pues, siendo un requisito típico la culpabilidad, se considera ajustada a
derecho y a los Principios de Culpabilidad y Proporcionalidad la graduación
de la sanción del artículo 5.1.f) del RGPD que fue realizada en la propuesta
de resolución, por la que se considera que cabe imputar un grado de
negligencia grave en la actuación de la reclamada, por no proteger la

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

112/173

confidencialidad, aplicando la circunstancia de graduación del artículo
83.2.b) del RGPD, sin reducir por ello la cuantía de la sanción a imponer
respecto a la que fue fijada inicialmente en el acuerdo de inicio, en base a
lo siguiente:

“(…) se entiende que concurre una actuación negligente de la
empresa, por no haber aplicado las medidas necesarias de cifrado y
seudonimización de datos personales a su base de datos, que no
hubieran impedido que el ciberatacante accediese ilegítimamente a los
mismos, y los extrajera o usurpara, pero si hubiera impedido que se
materializase la vulneración de confidencialidad de los datos, puesto
que de haber estado codificados el ciberataque no hubiera podido
conocer su contenido, descifrarlos sin tener la clave, ni, por ende,
utilizarlos, ni publicarlos ni cederlos a terceros”.

- La parte reclamada considera que se ha incrementado en un 155% la multa en
base al número de afectados y que la misma resulta desproporcionada. Dicha
alegación se estima por parte de esta AEPD, procediendo a través de la
presente resolución a fijar la cuantía de multa en los términos indicados en el
acuerdo inicio; esto es, 140.000 euros.

- Por último, se señala por la reclamada que la página 7 de la propuesta de
resolución reconoció que “no hay constancia de perjuicios causados en posibles
clientes afectados”, sin tenerlo en cuenta como atenuante, lo que vulnera el
artículo 29 de la Ley 40/2015 sobre Régimen Jurídico del Sector Público. Pero
el párrafo al que se refiere la reclamada está situado dentro de los antecedentes
de hecho, y se limita a exponer/ sintetizar las alegaciones formuladas por la
propia reclamada en su escrito de 30/08/2023 de respuesta al primer escrito de
respuesta al requerimiento. Pero esta frase no es una afirmación de esta
agencia, sino de la propia reclamada que se transcribe para hacer constar en
los antecedentes de hecho cuál fue su postura ante el requerimiento realizado.
Por tanto, no hay reconocimiento alguno de la agencia respecto a la ausencia
de perjuicios. Y por otra parte, cabe remitirnos a lo ya expuesto en el
Fundamento de Derecho anterior respecto a los motivos por los que la ausencia
de perjuicios -que no ha sido acreditada-no puede considerarse como atenuante
sino que está prevista únicamente como factor agravante en caso de que se
acredite que existen perjuicios.

TERCERA. –De la eficacia de las medidas de seguridad técnicas y
organizativas con las que contaba la Compañía.

3.A) Infracción del principio de tipicidad y ausencia de responsabilidad del
artículo 5.1 f) RGPD.

Habiendo la propuesta de resolución justificado la concurrencia de culpabilidad
de la infracción del artículo 5.1.f) en no haber adoptado las medidas técnicas
de cifrado y seudonimización de los datos personales que fueron exfiltrados,
señala la reclamada que:

- Por una parte, indica que el artículo 5.1.f) RGPD no recoge que la medida

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

113/173

de protección adecuada sea la seudonimización y el cifrado de los datos,
sino que se refiere a la adopción de medidas técnicas u organizativas
apropiadas con carácter general. Según la reclamada, ello es así dado
que, tal y como indica el CEPD en sus Directrices 04/2022, el artículo 5.1.
f) RGPD es un precepto genérico que regula los principios de protección
de datos, mientras que las medidas de integridad y confidencialidad
estarían recogidas de forma específica en el artículo 32 RGPD. Y en el
presente caso se desconoce el vector de entrada del ciber atacante, por
tanto, no se puede determinar si las medidas de seguridad técnicas u
organizativas con las que contaba la Compañía habrían sido las
apropiadas, precisamente por no poderse determinar cómo accedió y, por
tanto, qué medidas esquivó el hacker.

Cabe descartar este argumento puesto que:

o En primer lugar, las citadas Directrices 04/22 de cálculo de multas
(Guía de Multas) del CEPD no señala en ningún caso que el artículo
5.1.f) del RGPD recoge un principio pero que las medidas de
protección de la integridad y confidencialidad están recogidas
solamente en el artículo 32 del RGPD. Se trata de una interpretación
de la reclamada, que parte de varias premisas erróneas. Primero
porque ni siquiera es cierto que el artículo 32 del RGPD recoja un
catálogo de medidas necesarias a adoptar por todo responsable del
tratamiento (sino que dependerán del tratamiento y de garantizar en
este un nivel de seguridad adecuado al riesgo), y segundo porque el
artículo 32 del RGPD tampoco es el único precepto del que se
deriva la adopción de medidas dirigidas a garantizar la
confidencialidad de los datos personales, como se señalará en los
fundamentos de derecho siguientes.

o En segundo lugar, porque ya se ha dicho que la responsabilidad de
la reclamada por la comisión de la infracción del artículo 5.1.f) del
RGPD no se basa en no haber adoptar las medidas que hubieran
impedido que el hacker accediese a los datos personales.

o Y por último, porque tampoco es verdad que el artículo 5.1.f) no
haga referencia a la necesidad de adoptar medidas que garanticen
la confidencialidad, puesto que el tenor literal del mismo es
precisamente el siguiente: “f)tratados de tal 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»). Siendo el cifrado y seudonimización de los datos

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

114/173

personales una medida apropiada para proteger la confidencialidad
de los mismos, sin lugar a dudas.

- Y por otra parte, señala la reclamada que no es cierto que existiera una
ausencia total de medidas de cifrado pues la comunicación entre los
dispositivos de acceso y la plataforma se encontraba cifrada y las copias
de seguridad también lo estaban, de acuerdo con lo que se señaló en el
30 de agosto de 2023. Ya se ha contestado a esta cuestión en el
Fundamento de Derecho 3.2, en el que se han hecho constar los motivos
por lo que no cabe entender acreditado que la reclamada hubiera
adoptado medidas de cifrado de la base de datos “en reposo” que
contenía los datos personales alojados en los servidores de la reclamada
que fueron objeto de exfiltración.

3.B. Infracción del artículo 32 RGPD, ausencia de culpabilidad y falta de
Proporcionalidad.

- En primer lugar, se ha de decir que no es cierta la manifestación realizada
por la reclamada de que no conste prueba de las vulnerabilidades y la
insuficiencia de medidas técnicas y organizativas de la plataforma existentes
a fecha del ciberataque, puesto que cabe recordar que todas las
enumeradas han sido reconocidas en un correo electrónico interno del
propio Director de Ciberseguridad remitido el 14 de abril de 2023 a la DPD
de CECOTEC, lo cual se confirma y aporta por la propia reclamada en sus
dos escritos de respuesta a los requerimientos de información de la fase de
investigación, y por ello fueron reflejados por el inspector en su informe API.

- Por otra parte, señala que no debe equipararse el concepto de
vulnerabilidad con el de insuficiencia de medidas técnicas u organizativas
pues no son exactamente lo mismo, aunque están estrechamente
relacionados, lo que es cierto, sin que la propuesta haya realizado
equiparación conceptual alguna, habiéndose relacionado como parte de las
medidas no adoptadas dentro del incumplimiento del artículo 32 del RGPD,
pero en diferentes apartados. Esto es, en el hecho probado noveno, que
contiene las mismas, y en el Fundamento de Derecho VIII, se enumeran
varias medidas preventivas que no fueron adoptadas por la reclamada antes
del ciber ataque, distinguiendo como primera de ellas la referida a las
vulnerabilidades de versión de la plataforma ***SOFTWARE.1, de las demás
medidas no adoptadas por el responsable que se detectaron durante la
investigación.

Así pues, la distinción es clara, señalando el Fundamento de Derecho VIII
de la propuesta lo siguiente:

“-Se ha detectado que la plataforma adolecía de las siguientes deficiencias y
vulnerabilidades de versión, que eran necesarias para proteger la seguridad de
la plataforma, y por tanto, de adopción obligatoria para el responsable del

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

115/173

tratamiento de acuerdo con lo previsto en el artículo 32 del RGPD. Nos
referimos con ello a la constatación de que existían vulnerabilidades que
afectaban al ***SERVICIO.1 y al ***SERVICIO.2, a que la plataforma se
hallaba desactualizada, y fuera de soporte desde 2019 y con acceso a internet
(con código de usuario y contraseña (…)
-Y se ha comprobado que no se habían adoptado las siguientes medidas
necesarias para garantizar un nivel de seguridad adecuado al riesgo:

 Falta de medidas adecuadas para garantizar la trazabilidad de la
plataforma: Las referidas a los logs, la falta de monitorización, y a la falta
de control de acceso de los usuarios de la plataforma que se detallan en el
hecho probado octavo.

 Falta actualización del Análisis de Riesgos de la plataforma(…).

 Falta de aprobación y aplicación de un Protocolo de Gestión de Brechas de
Seguridad adecuado a la normativa(…)”.

- Por otra parte, señala la reclamada que la propuesta y el informe del
inspector reconocen que antes de la brecha no hubo una ausencia o
inobservancia de las medidas de carácter técnico y organizativo, y relaciona
las 4 medidas que fueron expresamente reconocidas como adoptadas en el
hecho probado octavo de la propuesta. Por tanto, no es que no se haya
considerado acreditado que se adoptaron estas 4 medidas, sino que las
mismas se han considerado manifiestamente insuficientes para garantizar
un nivel de seguridad adecuado a los riesgos derivados del tratamiento de
los datos personales que se contenían en la plataforma. No es cierto que se
parta de una ausencia total de medidas preventivas, y por este motivo, tanto
el acuerdo de inicio como la propuesta de resolución y la resolución
presente hacen referencia a una situación de desprotección “casi absoluta”,
y no absoluta. Motivo por el que la graduación de la sanción se fija en
750.000 euros, y no en su máximo posible, que sería de 10.000.000 euros o
el 2% del volumen de negocios de la empresa.

- Y, por otro lado, señalan las alegaciones que “sorprende que, habiendo
aceptado la AEPD, la adopción de medidas correctoras por parte de
CECOTEC (folio 65) no hayan sido tomadas en consideración como
atenuante del artículo 83.2.c) del RGPD”, no estando de acuerdo la empresa
reclamada con la afirmación de que “no son un factor atenuante sino
neutral”, puesto que según su visión ello es contrario a la Guía de Multas
(Directrices 4/2022), respecto a lo que cabe remitirnos a los motivos que
fueron señalados en la propuesta de resolución, que se han puesto de
manifiesto anteriormente.

- Respecto a la alegación de que “habiéndose indicado que no puede
aplicarse la atenuante porque no hubo un requerimiento de la agencia,
entiende que precisamente este hecho debe tenerse en cuenta para aplicar
la atenuante recogida en el art. 83.2.c) RGPD”. Cabe remitirnos igualmente

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

116/173

a la argumentación realizada en el fundamento de derecho anterior respecto
a los diferentes requisitos necesarios para que la adopción de medidas
correctivas tras el incidente puedan ser considerados como atenuante, que
no concurren en el supuesto presente: (i) ni respecto a la atenuante del
artículo 83.2. c) del RGPD (cualquier medida tomada por el responsable o
encargado del tratamiento para paliar los daños y perjuicios sufridos por los
interesado), que no se aplica porque las medidas adoptadas eran para
fortalecer la seguridad de la plataforma y no para paliar los daños, que la
propia reclamada niega); (ii) ni respecto a la atenuante del 83.2.g (el grado
de cooperación con la autoridad de control con el fin de poner remedio a la
infracción y mitigar los posibles efectos adversos de la infracción), puesto
que las Directrices de la Guía de Multa señalan que éstas deben adoptarse
tras requerirlo la autoridad de protección, puesto que de lo contrario no se
trataría de una cooperación.

- Se insiste en que se ha vulnerado el principio de proporcionalidad, y que
las cuantías de 300.000 € y de 750.000 € resultan desproporcionadas toda
vez que no han sido tenidos consideración por la Agencia para atenuar la
multa administrativa circunstancias, sin que quepa estimar esta alegación
dado que:

a) Se mencionan circunstancias que no concurren en el supuesto presente
conforme ya se ha explicado en varias ocasiones. Nos referimos a
hechos que la parte considera acreditados y que no lo están, tales como
la ausencia de culpabilidad, imposibilidad de determinar el nexo de
causalidad, o la limitación del acceso de terceros; que solo ha accedió el
ciber atacante, y la ausencia de consecuencias para los interesados al
no haberse comprado la base de datos por ningún tercero. Siendo estos
dos últimos hechos, además, de imposible comprobación en el supuesto
presente.

b) Otras circunstancias que se mencionan en las alegaciones si se han
tenido en cuenta al graduar la sanción a imponer, como también se ha
expuesto repetidamente (desconocimiento del vector de entrada, y
tipología de datos afectados).

c) Otras no se han considerado por no cumplirse los requisitos para
considerarse como factor atenuante, según lo dicho, como las medidas
correctoras adoptadas.

- Por otra parte, niegan también que el protocolo de gestión de brechas no
existiera con anterioridad a la brecha y que no se estuviera aplicando en la
empresa, dado que la propia DPD en su informe de 19/04/23 recoge que se
ha seguido el procedimiento, evidenciando que existía con anterioridad y
habiéndose realizado formación al respecto.

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

117/173

Reconocida la participación en cursos de formación como una medida
preventiva recogida en el hecho probado noveno, ni esta medida ni la mera
mención del informe de la DPD al cumplimiento del protocolo interno de la
empresa se consideran suficientes para considerar que la empresa estuviera
aplicando un adecuado Protocolo de gestión de brechas.

Lo que la propuesta de resolución señaló y ha quedado evidenciado a la
vista de los evidentes fallos cometidos por el personal para detectar la
brecha y gestionar la misma, es que la empresa incumplió con su deber de
disponer y aplicar un protocolo de detección y gestión de brechas, por dos
motivos:

“Primero, porque se ha acreditado que no disponían de un Protocolo
de gestión de brechas adecuado a la normativa, que cumpliera con los
requisitos a los que hace referencia las Directrices 09/22 sobre
notificación de brechas del CEPD, sino de un Protocolo de Gestión de
Incidentes de Seguridad de 2021, que no se adecuaba a los requisitos
mínimos para ser considerado un Protocolo de gestión de brechas.

Y segundo porque la empresa no aplicó su propio Protocolo de gestión
de incidentes de 2021 (que regulaba cómo detectar un incidente de
seguridad, y notificar una brecha), cuya comunicación a los empleados
y responsables con anterioridad a la brecha no consta acreditada.(…)

En este caso, tal y como se ha señalado al contestar las alegaciones
de la empresa, se ha demostrado que el Protocolo de 2021 se
desconocía por el personal de la empresa, o no fue aplicado, ya que:
(i) la primera alerta de ciber incidente del INCIBE se recibió el 5-4-23
al buzón general, pero no se remitió a los responsables de detectar y
gestionar la brecha como prevenía dicho protocolo; (i) ni tampoco se
aplicó por el responsable de ciberseguridad y la DPD puesto que el
mismo indicaba que bastaba con una certeza suficiente de que se
pudiera haber producido una brecha, y no con una certeza absoluta
para hacer la comunicación, como entendían ambos según sus
comunicaciones”.
Y cabe añadir que en caso de ser cierto lo que señalan ahora las
alegaciones a la propuesta de resolución respecto a que el cómputo del
plazo para notificar la brecha a esta agencia comenzó el día 14 de abril,
cuando el responsable de ciberseguridad le comunicó las gestiones a la
DPD, ello implicaría que tampoco habría involucrado a la misma desde el
mismo momento en que éste tuvo conocimiento de la alerta recibida del
INCIBE, tal y como es obligatorio de acuerdo con el artículo 38 del RGPD, y
constaba en el Protocolo.
- Por último, la reclamada invoca otros supuestos de brechas de datos
personales en los que la Agencia ha impuesto sanciones menores por la
infracción del artículo 32 del RGPD, cuando el número de afectados fue
mayor.

En concreto, se mencionan dos casos:

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

118/173

o “Así, en el caso PS/00179/2020 de AIR EUROPA donde se vieron
afectados interesados nacionales e internacionales en un total de
489.000 con un número de registros afectados de 1.500.000, se
impuso una multa de 500.000€ por infracción del artículo 32 RGPD.

o Adicionalmente y en un caso mucho más reciente, en el
EXP202210465 frente a Telefónica en la que se vieron expuestos
datos personales de 1.407.257 afectados se impone, por la
infracción del artículo 32 RGPD una multa de 500.000€”.

Cabe desestimar esta alegación, toda vez que:

 En primer lugar, porque no existen dos supuestos iguales que puedan
ser equiparados a la hora de graduar la sanción a imponer por cada
infracción, puesto que en cada supuesto se debe partir del volumen de
negocio cuando se trata de empresas, como es el caso, que es diferente
en CECOTEC respecto de las empresas que son objeto de
comparación. Y deben considerarse, tal y como se realizó en la
propuesta de resolución y se realiza en la presente resolución, todas las
circunstancias de graduación concurrentes en cada supuesto, que se
deben valorar conjuntamente, y no solo el número de afectados al que
apela la reclamada. Así pues, se han considerado en este supuesto
otras múltiples circunstancias para valorar la cuantía de la multa a
imponer que la reclamada no analiza al realizar la comparación, como
son la duración de la infracción, la tipología de datos personales, el
grado de culpabilidad, el grado de incumplimiento de las obligaciones…
etc. Todo ello es necesario, a los efectos de que la multa sea
individualizada, proporcional, efectiva y disuasoria.

 En segundo lugar, además, la reclamada al comparar el número de
afectados por la brecha, la reclamada parte de una premisa
comparativa errónea que no está considerando las diferencias existentes
entre las infracciones de preceptos -como es el caso de las contenidas
en los artículos 5.1.f) y 34 del RGPD-, en los que la consumación de la
infracción requiere un resultado (brecha de confidencialidad); y las
infracciones de preceptos -como es el caso de artículo 32 del RGPD –
en los que la infracción se consuma por el mero hecho de no adoptar los
medios o cumplir con las obligaciones que se exigen en la norma,
independientemente de que este incumplimiento genere o no un
resultado, que sería sancionado en su caso de forma independiente, si
vulnera otro interés jurídico protegido.

Centrándonos en los artículos 5.1.f) y 32 del RGPD, lo cierto es que la
obligación del artículo 5.1.f) del RGPD exige un resultado (basta con que

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

119/173

se pierda la confidencialidad o la integridad de los datos personales),
mientras que la obligación del artículo 32 del RGPD es de medios (hay
que diseñar las medidas de seguridad atendiendo al nivel de seguridad
adecuado al riesgo, implantarlas correctamente y utilizarlas
apropiadamente, y la falta de todas o algunas de estas actuaciones es lo
que se sanciona).

Y como consecuencia de ello, mientras que los afectados por la
infracción del artículo del 5.1.f) del RGPD son aquellos afectados por la
pérdida de confidencialidad producida a raíz del ciber ataque al que se
refiere este expediente (933 personas), los afectados por las
infracciones que generaban obligaciones de medios del artículos 32 del
RGPD fueron todas las personas cuyos datos personales se hallaban
contenidas en la base de datos (plataforma ***SOFTWARE.1) y estaban
siendo puestos en riesgo potencialmente a fecha del ciberataque puesto
que la misma no tenía un nivel de seguridad adecuado al riesgo.

Y en este caso, se ha de recordar que estamos en presencia de un
número muy elevado de afectados cuyos datos personales están
siendo puestos en grave riesgo puesto que la reclamada manifiesta
que solamente la tabla ***TABLA.1 contenía datos de más de
2.052.000 personas. Y hay que considerar la duración de la
infracción y que el grado de incumplimiento de medidas fue
incrementándose paulatinamente con el tiempo, puesto que comenzó
al no adaptar el tratamiento a las previsiones del nuevo RGPD, una
vez entró en vigor el mismo, pero esta situación de incumplimiento se
incrementó exponencialmente en 2019 cuando se dejó de contratar
el soporte y actualizar la plataforma, de nuevo en el año 2021 al
cerrar el ***SERVICIO.2 de la misma, como ya se ha señalado, y en
el año 2022, cuando se publicó la existencia de una vulnerabilidad
crítica de la versión de ***SOFTWARE.1 utilizada por la reclamada
que estaba siendo explotada por los ciber atacantes para exfiltrar
datos, y la reclamada no descargó la actualización o “parche”
publicado por el fabricante de la misma, para corregir dicha
vulnerabilidad. Siendo por tanto la duración de la infracción
continuada de más de 6 años (entre la entrada en vigor del RGPD y
la actualidad, en la que siguen sin adoptarse todas las medidas
correctivas necesarias para adecuar el tratamiento al RGPD).

Como señalaron el acuerdo de inicio y la propuesta, se considera
que la infracción del artículo 32 del RGPD es especialmente
reprochable en este caso, puesto que estamos ante una infracción
sistémica, donde la falta de medidas organizativas y técnicas que
protegían la plataforma a la fecha del ciber ataque era casi absoluta,
limitándose a 4 medidas aisladas que eran claramente insuficientes.

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

120/173

Y es que no se estaban adoptando las medidas más comunes de
protección de cualquier sistema operativo o base de datos conectado
a internet con una clave de usuario y contraseña, al hallarse la
plataforma sin soporte desde 2019, desactualizada, con
vulnerabilidades críticas publicadas por el fabricante en el año 2022
que no se habían reparado al no descargarse la pertinente
actualización publicada según consta en la diligencia de 2 de
noviembre de 2023 del inspector. Y concurriendo una ausencia de
una adecuada gestión del riesgo, dado que consta que la empresa
no había actualizado su análisis de riesgos a fecha del ciber ataque,
y que el realizado en el año 2022 no era válido ni contenía la
totalidad de riesgos concurrentes ni el análisis de su impacto y
medidas, con el rigor requerido a todo responsable de tratamiento.

Por todos estos motivos, se considera que 750.000 euros por la
infracción del artículo 32 del RGPD es una sanción proporcional,
efectiva, disuasoria e individualizada, considerando la situación de
desprotección clamorosa en la que se hallaban los datos personales
contenidos en dicha plataforma.

CUARTA. – Disconformidad con el dies ad quo respecto a la notificación de la
brecha. Falta de proporcionalidad de la infracción del artículo 33 del RGPD.

4.A) Dies ad quo.

- En primer lugar, la empresa se muestra disconforme con que el dies ad
quo para computar el plazo de notificación de la brecha a esta Agencia sea
el 13 de abril de 2023. Entiende que la fecha de inicio del cómputo del
plazo de 72 horas para notificar la brecha debería ser del 17 de abril,
momento en el que el Director de Ciberseguridad, tras analizar la situación
con la Delegada de Protección de Datos responde a INCIBE y da lugar a
que, posteriormente, en fecha de 19 de abril, se notifique la brecha. El
motivo que aducen es que INCIBE debería haberse dirigido directamente a
la dirección del DPD y no a una genérica en la que se reciben multitud de
correos diarios. Toda vez que, al recibirse a través de la dirección genérica,
se hizo necesario hacer comprobaciones adicionales para verificar que la
información que se facilitaba era cierta, motivo por el cual tanto el Director
de Ciberseguridad como la Delegada de Protección de Datos necesitaron
de unos días para analizar y determinar la necesidad de notificar.

Debe descartarse tal argumentación, manteniendo que como señala la
propuesta de resolución en su Fundamento de Derecho XI el cómputo del
plazo se inició el 13 de abril de 2023 a las 17:23 horas, cuando el director
de ciberseguridad de CECOTEC concluyó sus investigaciones remitiendo
una contestación a INCIBE en la que le informaba del resultado de las

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

121/173

mismas. Sin que el día 17 de abril de 2023 tenga sustrato alguno para ser
admitido como inicio del cómputo, puesto que dicho día únicamente consta
un correo remitido por el director de ciberseguridad al INCIBE para cotejar
que no se había producido un intento de phishing y la contestación de éste;
habiendo sido el 5-4-23 cuando se recibió la primera alerta del INCIBE en
el buzón, el 12-4-23 cuando se detectó la alerta del INCIBE al remitir éste
un recordatorio que si fue reenviado al responsable de ciberseguridad, el
13-4-23 cuando la DPD reconoce en su informe que se iniciaron y
concluyeron las investigaciones para comprobar que los 17 registros de la
muestra 1 del anuncio coincidían con los de CECOTEC; y el 14-4-23
cuando el responsable de ciberseguridad le remitió un informe a la DPD
detallando las investigaciones realizadas y conclusiones obtenidas.

Ante dicha cronología, acreditada a través de las propias comunicaciones
aportadas como Anexos 6 y 7 del primer escrito de respuesta y reconocida
en los informes del DPD aportados, no cabe en ningún caso admitir el día
17 de abril como aquel en el que la empresa ”tuvo constancia de la
brecha”, para servir de inicio del cómputo del plazo.

La remisión de la primera alerta de INCIBE al buzón y no al correo
electrónico de la DPD no puede servir de excusa para retrasar el inicio del
cómputo al día 17-4-23 (ni al día 14-4-23), toda vez que:

o Primero, no es cierto que el retraso se debiera a la necesidad de
comprobar el origen del correo, toda vez que el director de
ciberseguridad contestó al INCIBE el día 13-4-23, dándole la
información requerida, y no fue hasta el 17-4-23 cuando corroboró
si la alerta se trataba de un intento de phishing.

o La remisión de la alerta del INCIBE al buzón genérico de la
empresa se considera válida, sin que se haya acreditado que la
empresa comunicase el correo de la DPD al mismo para que
pudiera servir de canal de comunicación, ni que el mismo constase
en la política de privacidad de la empresa. Es más, consta
acreditado que el propio personal encargado del buzón desconocía
que debía reenviar este correo a la DPD y responsable de
ciberseguridad, pues se ha aportado un correo de 19-4-23 donde la
DPD advierte de esta necesidad y comunica al propio personal
cuales son las direcciones de correo a las que deben remitirse
estas alertas con carácter urgente.

o En este caso, consta también que el personal que atendía el buzón
genérico, ignoró las propias previsiones del “Protocolo de gestión
de incidentes de seguridad de 22-4-21”, aportado por la empresa,
que hacía constar que (el subrayado es nuestro):

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

122/173

“Obligación de comunicar cualquier evento de seguridad que afecte
a la confidencialidad, integridad o disponibilidad de datos
personales. Todo empleado de la organización que sea conocedor
de un hecho indiciario de un evento o incidente de seguridad en
materia de protección de datos personales, por cualquiera de los
medios indicados en el punto 2.1. de este documento (relativo a las
fuentes de identificación de una brecha de seguridad), deberá
comunicarlo en el plazo máximo de 24 horas a la Delegada de
Protección de Datos y su responsable inmediato y superior
departamental.”

- Subsidiariamente, para el caso de que se entienda que la notificación se hizo
de forma tardía fuera del plazo de 72h, la reclamada entiende que el dies ad
quo debe ser el 14 de abril a las 14:31h, momento en el que el Director de
Ciberseguridad comunica a la DPD las investigaciones realizadas ya que,
hasta ese momento, la DPD necesitaba conocer las conclusiones obtenidas
por el Director de Ciberseguridad para poder valorar el alcance y naturaleza
de la brecha. En este sentido, se alega que el artículo 33, cuando refiere al
plazo de 72h recoge la expresión “(…)” resultando de vital la consideración
“(…)”. Y que se está reclamando por la AEPD al responsable del tratamiento
que notifique dentro de 72h cuando hay simplemente sospechas (tal y como
lo consideró inicialmente el propio INCIBE) y no cuando se tiene constancia,
que es lo exigido en el RGPD.

No obstante, no cabe admitir este argumento, puesto que:

o En primer lugar, como ya se ha dicho al contestar a las alegaciones al
acuerdo de inicio, la fecha a partir de la cual se tiene constancia de la
brecha es la fecha a partir de la cual se tiene un “grado razonable de
certeza de que se ha producido una brecha”, sin que sea necesaria la
certeza absoluta, como advertía el propio Protocolo de Gestión de
Incidentes que tenía la empresa desde 2021. Y en concreto, cabe
recordar que el punto 40 de las Directrices 09/2022 del CEPD sobre
notificación de brechas, señala expresamente cuando se considera
que se tiene constancia de la brecha:

“40. Por consiguiente, debe quedar claro que el responsable del
tratamiento está obligado a actuar a partir de cualquier alerta
inicial y a determinar si se ha producido o no una violación. Este
breve período permite que se realicen algunas investigaciones y
que el responsable del tratamiento reúna pruebas y otros
detalles pertinentes. No obstante, una vez que el responsable
del tratamiento haya establecido con un grado razonable de

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

123/173

certeza que se ha producido una violación, si se cumplen las
condiciones del artículo 33, apartado 1, del RGPD, deberá
notificarlo a las autoridades de control sin dilación indebida y, de
ser posible, en un plazo máximo de setenta y dos horas. Si un
responsable del tratamiento no actúa de manera rápida y resulta
evidente que se ha producido una violación, esto podría
considerarse una falta de notificación de conformidad con el
artículo 33 del RGPD.”

Por tanto, lo primero que debe aclararse es que esta Agencia no está
exigiendo que se notifique en base a “sospechas” como indica la
reclamada, sino que se notifique cuando existe este grado razonable
de certeza, que sin duda concurría en el supuesto presente.

o No es que existieran sospechas, sino que se ha constatado que el día
13-4-23 el director de ciberseguridad disponía de evidencias que le
hubieran permitido determinar que existía un “grado de certeza
razonable” de que se había producido una brecha, que alcanzaba, al
menos, a todos los datos personales incluidos en los 17 registros de la
muestra inicial que había sido publicada por el ciber atacante. Y así lo
informó al INCIBE.

Cuestión distinta es que el mismo no realizase un debido análisis de la
brecha por desconocimiento del propio protocolo de incidentes de
2021 aprobado por la empresa, que indicaba expresamente con no
era necesaria una certeza absoluta de que el actor malicioso hubiera
accedido a la totalidad de la base de datos, al igual que determinan las
Directrices 09/2022 del CEPD. De haberse aplicado los mecanismos,
procedimientos y medidas necesarias para detectar la brecha, analizar
los riesgos y evaluarlos, responder a la misma con medidas y
notificarla/comunicarla, se hubiera podido actuar con la diligencia
esperable a un responsable del tratamiento. Pero se ha acreditado
que hubo una falta de diligencia tanto al detectar la brecha antes de
iniciar la fase de investigación, como después de finalizar la
investigación, en que concurrieron errores de evaluación de la brecha
y su riesgo, así como de comunicación con la DPD, notificación de la
brecha a la agencia en plazo, y comunicación de la brecha a los
afectados.

o No hay que olvidar tampoco que en el presente supuesto se está
realizando una interpretación del inicio del plazo favorable a la
reclamada. Puesto que consta que el responsable del tratamiento no
actuó de forma diligente y con dilación debida en varias ocasiones: (i)
al no detectar la primera alerta de incidente remitida el 5-4-23, (ii) y al
detectar la segunda alerta del incidente el 12-4-23, dilató de nuevo el

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

124/173

inicio del periodo de investigaciones al requerir de nuevo el contenido
de dicho correo al INCIBE -cuando el mismo se hallaba en su buzón
genérico-y perder otro día más hasta que lo recibió. Y pese a ello,
esta Agencia ha aplicado una interpretación favorable a la empresa, al
entender que no comenzó el cómputo ni el día 5, ni el día 12 de abril,
sino el 13 de abril de 2023 cuando se contestó al INCIBE por el
Director de Ciberseguridad, por entender que entonces se finalizó el
“breve periodo de investigación” de la brecha que de acuerdo con las
Directices 09/22 era necesario para poder comprobar si los 17
registros que constaban en la muestra del anuncio estaban dentro de
alguna de las bases de datos de CECOTEC, toda vez que se entiende
que en este momento ya se disponía de suficientes evidencias para
determinar que existía una certeza mucho más que razonable de que
se había producido una brecha en la citada tabla ***TABLA.1, que
afectaba, al menos a 6 afectados. Por tanto, ya desde entonces se
inició el plazo para computar la notificación a esta Agencia. Sin que el
hecho de que no conste que el mismo involucrase desde el inicio de
las comprobaciones a la DPD, y esperase un día más para
comunicarle el resultado de sus investigaciones mediante correo
electrónico, pueda servir de óbice para dilatar todavía más el plazo de
notificación, que venía siendo retrasado ya desde el 5-4-23 por la falta
de una adecuada aplicación de protocolo de gestión de brechas.

o Por otra parte, existen evidencias, constatadas en los hechos
probados y detalladas en el Fundamento de Derecho XI de la
Propuesta de Resolución, y XII de la presente Resolución, que llevan
a concluir que el momento en el que la reclamada tuvo “constancia de
la brecha” fue el 13-4-24, cuando el director de ciberseguridad
concluyó las investigaciones y determinó que se había producido una
brecha con un “grado razonable de certeza”, informando de ello al
INCIBE, siendo la propia reclamada (informe DPD) la que reconoce
que fue entonces cuando “fue consciente de la brecha”, entre otras
múltiples evidencias.

o Así mismo, dilatar la notificación hasta comprobar “a ciencia cierta”
que el ciber ataque ha afectado a la totalidad de registros que el actor
malicioso decía disponer en el anuncio (casi un millón de registros
correspondientes a usuarios filtrados por número de teléfono) no es
excusa para dilatar el plazo de notificación, toda vez que, tal y como
se señala el fundamento de derecho anterior y en la propuesta de
resolución, el artículo 33.4 del RGPD permite realizar una notificación
gradual de la brecha en estos casos.

El propio artículo 33 en su apartado 4 establece la posibilidad de
realizar una notificación gradual al determinar:

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

125/173

“4. Si no fuera posible facilitar la información simultáneamente, y en
la medida en que no lo sea, la información se facilitará de manera
gradual sin dilación indebida”.

Por tanto, no puede entenderse que la notificación a la autoridad de
control requiera que el responsable tenga “pleno conocimiento” o
“constancia plena” de la existencia de una brecha de datos personales
y de todos los elementos de esta y completa el significado de “tener
constancia” al que hace referencia el apartado 1.

En definitiva, el RGPD entiende que existirán situaciones en las que la
complejidad de la brecha de datos personales exija de actuaciones e
investigaciones posteriores por parte del responsable. No obstante,
estas circunstancias no le eximen, en ningún caso, de la comunicación
a la autoridad de control con la máxima celeridad y rapidez, aun
cuando sea gradualmente. En este sentido se pronuncian las
Directrices 9/2022, en los apartados 56 y ss, a los que nos hemos
referido anteriormente.

56. Dependiendo de la naturaleza de la violación, puede ser
necesario que el responsable del tratamiento siga investigando
para establecer todos los hechos pertinentes relacionados con el
incidente.
57. Esto significa que el RGPD reconoce que los responsables
del tratamiento no siempre dispondrán de toda la información
necesaria sobre una violación en un plazo de setenta y dos
horas a partir del momento en que tengan constancia de la
misma, ya que es posible que no siempre se disponga de
detalles completos y exhaustivos del incidente durante este
período inicial. Como tal, permite una notificación gradual. Es
más probable que esto ocurra en el caso de violaciones más
complejas, como algunos tipos de incidentes de ciberseguridad
en los que, por ejemplo, puede ser necesaria una investigación
forense pormenorizada para determinar plenamente la
naturaleza de la violación y en qué medida se han visto
comprometidos los datos personales. Por consiguiente, en
muchos casos el responsable del tratamiento tendrá que
investigar más a fondo y hacer un seguimiento con información
adicional en una fase posterior. Esto es admisible, siempre que
el responsable del tratamiento justifique el retraso, de
conformidad con el artículo 33, apartado 1, del RGPD (…)”.

En esta línea, aplicando una interpretación “teleológica o finalista” de
las normas, se debe tener presente cuál es el propósito del deber de

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

126/173

notificación a la autoridad de control que fija el legislador comunitario.

El propósito del artículo 33 en la manera en que está concebido,
basado en los principios de celeridad e inmediatez respecto a la
notificación a la autoridad de control por parte del responsable, es
asegurar las máximas garantías para los potenciales afectados de
brechas de datos personales. A este respecto conviene destacar el
considerando 85 del RGPD:

“85.Si no se toman a tiempo medidas adecuadas, las violaciones
de la seguridad de los datos personales pueden entrañar daños
y perjuicios físicos, materiales o inmateriales para las personas
físicas, como pérdida de control sobre sus datos personales o
restricción de sus derechos, discriminación, usurpación de
identidad, pérdidas financieras, reversión no autorizada de la
seudonimización, daño para la reputación, pérdida de
confidencialidad de datos sujetos al secreto profesional, o
cualquier otro perjuicio económico o social significativo para la
persona física en cuestión. Por consiguiente, tan pronto como el
responsable del tratamiento tenga conocimiento de que se ha
producido una violación de la seguridad de los datos personales,
el responsable debe, sin dilación indebida y, de ser posible, a a
más tardar 72 horas después de que haya tenido constancia de
ella, notificar la violación de la seguridad de los datos personales
a la autoridad de control competente, a menos que el
responsable pueda demostrar, atendiendo al principio de
responsabilidad proactiva, la improbabilidad de que la violación
de la seguridad de los datos personales entrañe un riesgo para
los derechos y las libertades de las personas físicas. Si dicha
notificación no es posible en el plazo de 72 horas, debe
acompañarse de una indicación de los motivos de la dilación,
pudiendo facilitarse información por fases sin más dilación
indebida”

En el mismo sentido se pronuncian las Directrices 9/2022:

“58. El objetivo del requisito de notificación es alentar a los
responsables del tratamiento a que actúen con prontitud en caso
de violación, contenerla y, si es posible, recuperar los datos
personales comprometidos, así como recabar el asesoramiento
pertinente de la autoridad de control. El hecho de notificar a la
autoridad de control dentro de las primeras setenta y dos horas
puede permitir que el responsable del tratamiento se asegure de
que las decisiones sobre si debe o no notificar a las personas
sean correctas.”

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

127/173

En definitiva, la notificación a la autoridad de control permite, por
una parte, recibir orientación sobre la necesidad de comunicar la
brecha de datos personales a los afectados, pero también habilita
a esta a que, en el ejercicio de sus competencias -y siempre que
lo estime necesario- actúe y despliegue las potestades que el
RGPD expresamente le atribuye en el artículo 58, en particular, la
consagrada en el artículo 58.2 e) “ordenar al responsable del
tratamiento que comunique al interesado las violaciones de la
seguridad de los datos personales”, aunque también pueden ser
otras, atendiendo a las circunstancias del caso concreto, como la
imposición de limitaciones temporales o definitivas del tratamiento
(58.2 f), decisión que, en cualquier caso, corresponde a la
autoridad de control y que no debe verse entorpecida por el
responsable.

El incumplimiento del artículo 33 supone una privación del
ejercicio de las competencias de la autoridad de control, que si no
tiene conocimiento de los hechos no puede actuar (o decidir no
hacerlo), en detrimento, además, de los derechos y libertades de
los afectados, puesto que las brechas de datos personales
suponen o pueden suponer la pérdida de control que estos tienen
sobre sus propios datos personales, principio inspirador del
RGPD”.

Llegados a este punto, la STJUE de 24 de septiembre de 2024, en el
asunto C-768/2021, va más allá al recordar que, la autoridad de
control en ocasiones estará obligada a intervenir en función de los
hechos de los que tenga conocimiento, por lo que la ausencia de
notificación por parte del responsable supone una injerencia en sus
obligaciones.

Y no solo la ausencia de notificación impide a la autoridad de control
actuar atendiendo a las circunstancias del caso concreto, también las
notificaciones tardías, en función del tiempo transcurrido desde que el
responsable tuvo constancia, desvirtúan el objetivo perseguido por el
artículo 33 del RGPD y dejan este vacío de contenido, al imposibilitar
la actuación por la autoridad de control o una rápida reacción por parte
de los afectados. En esta línea se pronuncian la Directrices 9/2022,
punto
40, al que nos referimos anteriormente.

En definitiva, la obligación de notificar a la autoridad de control no
responde a una mera obligación formal de comunicación, sino que es,
a todos los efectos, una obligación con contenido material cuyo

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

128/173

incumplimiento tiene implicaciones negativas que redundan, en último
término, en los afectados de una brecha de datos personales.

o En el supuesto presente, se considera que no cabe retrasar al día 14-
4-24 el inicio del cómputo del plazo (cuando el Director de
Ciberseguridad remitió un informe detallado a la DPD de la empresa),
en base al argumento alegado por la reclamada de que fue entonces
cuando la DPD pudo conocer la brecha y evaluar su alcance, toda vez
que, de haber cumplido con el protocolo de gestión de incidentes de
su empresa, y la obligación prevista en el artículo 38 del RGPD, la
DPD de la empresa debió estar involucrada en el proceso de
detección desde el inicio, sin que quepa dilatar un día más el inicio del
plazo porque el responsable técnico encargado de realizar la
investigación y analizar decidiera comunicar dicha información a su
DPD al día siguiente.

Se ha de recordar que la obligación de notificar la brecha se imputa al
responsable del tratamiento, con independencia de que los miembros
del personal encargados de su detección y notificación incumplan las
medidas previstas en su propio protocolo y en las Directrices 09/2022
del CEPD, dilatando indebidamente la notificación, como sucedió en el
presente supuesto en varias ocasiones. Máxime cuando el artículo
33.4 del RGPD, permite la notificación gradual de la brecha, en el
sentido que ha sido expuesto anteriormente.

Y en cualquier caso además, el hecho de que el plazo comience a
computarse el día 13-4-23, no obsta a que al ser informada la DPD el
día siguiente, ésta no cuente con tiempo suficiente como para valorar
y determinar que debía notificarse la brecha en un plazo de 72 horas
desde el citado día 13-4-23. La DPD tuvo otros dos días para poder
realizar la notificación, cuyo plazo acababa el día 16-4-23 a las
18Horas, pero no lo hizo hasta el día 19-4-23.

3. B) Falta de proporcionalidad infracción artículo 33 del RGPD.

- Entiende la reclamada que la sanción impuesta incurre en una falta de
proporcionalidad toda vez que se está penalizando a la Compañía por
haber notificado la brecha, lo que no puede admitirse, dado que lo que se
sanciona en este caso, es el incumplimiento del requisito del plazo de
notificación contenido en el citado precepto, ya que consta acreditado que
la empresa ha excedido el plazo máximo para notificar la brecha en más
de 72 horas.

Por tanto, consta acreditado que se ha producido una notificación tardía o
extemporánea, que es una infracción de la obligación prevista en el artículo
33 del RGPD, que esta agencia debe imputar, por aplicación del Principio
de Tipicidad. En caso de no haberse notificado la brecha, la sanción a

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

129/173

aplicar hubiera sido más elevada, dado que dicha conducta sería más
merecedora de reproche que la notificación fuera de plazo.

Cabe aclarar que el Fundamento de Derecho dedicado a la graduación de
la sanción impuesta por el incumplimiento del artículo 33 del RGPD, se ha
hecho constar que para fijar la cuantía de 100.000 euros se había tenido
en consideración que la brecha se notificó, aunque la notificación fue
tardía, y que el número de horas por las que se ha excedido el plazo al fijar
la cuantía de la multa, por lo que en ningún caso cabría imponer la misma
sanción de no haberse notificado la brecha, o de haber sido posterior la
notificación.

- Manifiesta también la reclamada que aunque la notificación se hiciese
fuera del plazo de 72h lo cierto es que la brecha se notificó facilitando toda
la información que prevé el artículo 33 RGPD, a pesar de lo cual se ha
impuesto una multa de 100.000€ por una demora de, en su caso, cuarenta
y ocho horas, lo que se considera desproporcionado. Al respecto, cabe
señalar que la notificación tardía ascendió a 72,19 horas y no a 48 horas, y
confirmar la interpretación realizada por la propuesta de resolución,
considerando que 100.000 euros es una sanción ajustada al reproche de la
conducta, toda vez que el límite máximo de cuantía asciende a 10 millones
de euros o al 2% del volumen de negocio de CECOTEC. E insistir en que
la notificación tardía es reprochable y debe ser objeto de sanción puesto
que notificar tarde una brecha reduce la capacidad de la autoridad de
control para reaccionar y proteger a los afectados si fuera preciso, como
por ejemplo sería la orden de que se les comunicara la brecha a los
afectados, y que estos estuvieran prevenidos ante por ejemplo cualquier
fraude y puedan reaccionar para protegerse.

- Respecto a la alegación de que “se debe valorar que la brecha ha afectado
a 993 personas, no habiéndose materializado daño alguno a los
interesados, toda vez que la propia compañía hizo averiguaciones y se ha
comprobado que no se ha comprado la base de datos, por tanto, habría un
solo tercero (el ciber atacante) que habría accedido a los datos”. Cabe
reiterar, una vez más, que no se ha acreditado la ausencia de daños, ni
que no se haya producido el acceso por alguien ajeno al ciber atacante a
los datos exfiltrados. Y que la infracción del artículo 33 del RGPD se
consuma al no notificar la brecha en plazo a la autoridad de control, en la
que se consideran afectados todas las personas cuyos datos personales
estuvieran siendo objeto de tratamiento por la plataforma cuyo nivel de
protección no era adecuado a la situación de riesgo en la que se hallaban,
y no solamente los de aquellos que fueron afectados por la brecha de 5-4-
23.

- Subsidiariamente, la reclamada entiende que la infracción en la que, en su
caso, se habría incurrido no es la prevista en el artículo 76. 2 LOPDGDD,
sino la infracción leve del artículo 74 m) LOPDGDD: “la notificación
incompleta, tardía o defectuosa a la autoridad de protección de datos de la

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

130/173

información relacionada con una violación de seguridad de los datos
personales de conformidad con lo previsto en el artículo 33 del
Reglamento (UE) 2016/679”.

Al respecto de esta cuestión, cabe aclarar que el RGPD no contiene una
calificación de tipos de infracciones leves, graves y muy graves, y que la
clasificación de los artículos 72 a 74 de la LOPDGDD se realiza a los solos
efectos de computar los plazos de prescripción.

En este caso, ya desde el acuerdo de inicio de este expediente
sancionador se ha considerado que el plazo de prescripción es,
efectivamente, el plazo de 1 año fijado para la “notificación incompleta,
tardía o defectuosa” en el artículo 74.m) de la LOPDGDD, computado
desde la fecha en la que finalizó el plazo para notificar la misma (16-4-23 a
las 18horas). Sin que se haya producido tal prescripción, por haber sido
interrumpido el plazo de prescripción al iniciar el presente procedimiento
sancionador con fecha de 1-4-24, y notificarse el citado acuerdo de inicio a
la reclamada con fecha de 11-4-23, de acuerdo con lo previsto en el
artículo 75 de la LOPDGDD, que establece lo siguiente:

“Artículo 75. Interrupción de la prescripción de la infracción.
Interrumpirá la prescripción la iniciación, con conocimiento del
interesado, del procedimiento sancionador, reiniciándose el plazo de
prescripción si el expediente sancionador estuviere paralizado durante
más de seis meses por causas no imputables al presunto infractor”.

- Por último, solicita la reclamada que se considere subsidiariamente la
infracción como leve y se reduzca la sanción, equiparando este supuesto a
las sanciones que se han impuesto en otros expedientes precedentes por
esta Agencia.

En concreto, menciona dos casos:

o “El EXP202307460 frente a ‘Dental cuadros’, en el que se analiza la
brecha de seguridad ocurrida en fecha de 20 de abril de 2023 que
fue notificada a la Agencia en fecha de 12 de mayo de 2023 que
afectó a 2.500 pacientes de una clínica dental. En este caso, la
Agencia entendió que resultaba aplicable la infracción del artículo
74 m) LOPDGDD y aplicó una multa de cinco mil euros (5.000€),
dado que apreció como agravante el tratamiento de datos de
categoría especial. Comparando esta situación con la que nos
ocupa en el presente, tanto el número de afectados como la
tipología de datos, y el número de días que se excedió el plazo
favorecen a CECOTEC, y aun así la sanción es mucho mayor. Por
lo tanto, subsidiariamente, se debe entender que se habría incurrido
en la infracción del artículo 74 m) LOPDGDD debiéndose minorar la

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

131/173

cuantía sancionadora a cinco mil euros”.
o Asimismo, en el PS/00179/2020 frente a AIR EUROPA en la que
también se valora una brecha de seguridad y se sanciona por
infracción del artículo 33, se aplica una multa de 100.000€ ante una
notificación extemporánea de 41 días”.

No cabe admitir tampoco esta alegación, toda vez que:

(i) Nuevamente incurre la reclamada en el mismo error de comparar
este asunto con otros expedientes precedentes valorando el
número de afectados por la brecha, que afecta a la graduación de
las infracciones de resultado concurrentes, en lugar del número
potencial de afectados cuyos datos personales se hallaban en la
plataforma que es el que debe valorarse en infracciones de riesgo
como la presente, como ya se ha explicado anteriormente.
(ii) Además, interpreta erróneamente que esta Agencia ha fijado esta
infracción como leve en otros asuntos a diferencia del presente,
cuando no es cierto, como también se ha indicado anteriormente.
(iii) Por lo que respecta al EXP202307460 frente a ‘Dental cuadros’, no
tiene en consideración la reclamada que esta empresa contaba con
un volumen de negocios mucho menor al de CECOTEC (de
517.290 euros en el año 2022 frente a más de 105 millones de
euros de CECOTEC), siendo el volumen de negocio un punto de
partida que debe ser considerado obligatoriamente para la
graduación de la sanción, de acuerdo con lo señalado por la Guía
de Multas (Directrices 04/2022 del CEPD).
(iv) Y por lo que respecta al PS/00179/2020 frente a Air Europa, en el
que se produjo una notificación de brecha extemporánea de 41
días, hay que señalar que la resolución fue dictada el 15-3-2021,
cuando todavía no se habían aprobado ni las directrices 09/2022 de
notificación de brechas del CEPD ni la Guía de Multas aprobada
mediante Directrices 04/2022 del CEPD, por lo que la situación
jurídica existente en aquel momento no es equiparable a la actual.
Se ha de señalar, que el caso particular de referencia la brecha
comenzó días antes de la entrada en vigor del RGPD (cuando se
hicieron exigibles dichas obligaciones). Y en el presente supuesto,
la brecha se produjo el 5-4-23 (casi 5 años después de la entrada
en vigor del RGPD, cuando ya estaban aprobadas las Directrices
de notificación de brechas y fijados los criterios de cálculo de
multas por el CEPD), y estamos en presencia de una infracción
cuyos efectos pueden tener efectos permanentes e irreversibles en
los derechos de los interesados, dado que la base de datos se puso
a la venta al mejor postor en la dark web.

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

132/173

QUINTA.– Ausencia de necesidad de notificación de los interesados al
tiempo de la brecha. Infracción artículo 34 del RGPD.

- A fin de evitar redundancias, se reiteran en lo indicado en alegaciones previas
presentadas, lo que supone que sigue manteniendo que no concurría alto
riesgo por lo que no tiene el deber de comunicar la brecha. Y se precisa que el
número total de afectados es de 993, no de mil, ni de un millón, lo que, como
ya se ha dicho, no es una cuestión controvertida sino admitida por la propuesta
de resolución, que en modo alguno excluye el deber de comunicar la brecha a
estos 933 afectados, sino que lo confirma. Frente a estos argumentos cabe
reiterarnos en la contestación realizada en la propuesta de resolución a la que
se ha hecho referencia en el Fundamento de Derecho anterior, confirmando
que no cabe lugar a dudas de que en este supuesto concurren los requisitos
del artículo 34 del RGPD -y en concreto del alto riesgo que niega la reclamada-
que determinar que es obligatorio comunicar la brecha a los 933 afectados que
han sido confirmados a lo largo de la instrucción, y reconocidos por la
reclamada.

- Por otra parte CECOTEC señala que no está conforme con la afirmación
realizada en la propuesta de resolución (página 93) en relación a que “no ha
sido posible identificar al actor malicioso y la base de datos se halla a la venta
en un foro de la dark web desde el 5-4-23”, puesto que: (i) lo cierto es que se
llevó a cabo (…) por parte de la Compañía tras la que concluyó que no se
había detectado ningún tipo de actividad ni compra y que “no hay constancia
de perjuicio alguno para los interesados” (página 7 Resolución); (ii) además, el
atacante sí está identificado al haberse puesto la propia Agencia en contacto
con él y al facilitar su dato contacto desde el propio INCIBE (páginas 22,30,50
Resolución).

Esta afirmación -que se realizó en la propuesta para contestar a las
alegaciones realizadas por la reclamada sobre que el actor no había sido
identificado y esta agencia no le había comunicado sus datos al objeto de
contactar como lo hizo el inspector del procedimiento- no es una cuestión
relevante en este caso para determinar si concurre la obligación de comunicar
la brecha a los afectados ni ninguna de las otras infracciones imputadas en
este procedimiento.

No obstante, a los efectos aclaratorios oportunos cabe señalar que la
afirmación referida no se realizó en los términos que plantea la parte
reclamada, toda vez que: (i) la reclamada parte de nuevo de que la afirmación
realizada en la página 7 de la propuesta fue un hecho reconocido en la misma,
cuando únicamente era un resumen de las alegaciones formuladas por la
reclamada realizado en los antecedentes de hecho; (ii) y además hay que
aclarar que cuando en el FD 3.1 sobre “Hechos reconocidos”, la frase señalada

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

133/173

se refería a que si se conocía desde el inicio cuáles eran los datos de contacto
del actor malicioso (correo electrónico), y no a que éste estuviera identificado
en su identidad, tal y como se deduce claramente del tenor literal de este
fragmento de la propuesta, que señalaba lo siguiente: “En su segundo escrito
de alegaciones (CECOTEC) señala que interpone denuncia tras conocer por
esta Agencia que se había contactado con el ciber-atacante en la fase de
investigación, momento a partir del cual pudo conocer los datos de contacto del
actor malicioso, pero lo cierto es que estos mismos datos que utilizó el
inspector para contactar con éste durante la investigación se hallaban en la
primera comunicación del INCIBE que recibió la reclamada, que además
proporcionaba el link donde poder acceder a la publicación, y sugería contactar
con el ciber-atacante”.

VI.

Incumplimiento del Principio del artículo 5.1.f) RGPD.

Los principios relativos al tratamiento son, por un lado, el punto de partida y la cláusula
de cierre del ordenamiento jurídico de protección de datos, constituyendo verdaderas
reglas informadoras del sistema con una intensa fuerza expansiva; por otro lado, al
tener un alto nivel de concreción, son normas de obligado cumplimiento susceptibles
de ser infringidas.

El artículo 5.1.f) “Principios relativos al tratamiento” del RGPD establece el Principio de
protección de la confidencialidad e integridad de los datos personales, en los
siguientes términos:

“1. Los datos personales serán: f) tratados de tal 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»).”

Este Principio atribuye al responsable de cualquier tratamiento de datos personales la
obligación de impedir tratamientos no autorizados o ilícitos de estos datos. Dicho de
otro modo, un responsable no debe tratar datos personales de sus clientes si no está
en disposición de garantizar la confidencialidad e integridad de los mismos e impedir
que un tercero acceda a datos que no son de su titularidad. Por esta razón
precisamente, una actividad comercial que implica la gestión de datos que supera el
millón de clientes como la realizada por la entidad imputada (solo la tabla ***TABLA.1
objeto del ciberataque contenía más de 2 millones de registros), requiere una especial
diligencia de cuidado para evitar este tipo de accesos.

Pero el deber de garantizar la confidencialidad de los datos personales no se limita a
impedir que un tercero acceda a estos datos personales sin disponer de autorización,
sino que se extiende a impedir que el mismo pueda conocer y descifrar estos datos
personales, a que los pueda exponer, publicándolos, y a que los pueda ceder a
terceros.

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

134/173

En otras palabras, se entiende que la diligencia exigible al responsable por el artículo
5.1.f) del RGPD para cumplir con su deber de confidencialidad de los datos personales
no solo se extiende al deber de prever medidas necesarias para impedir accesos no
autorizados por terceros (como el sucedido en este ciber-ataque), sino también a
establecer medidas adecuadas de seudoniminación y cifrado de los datos personales,
realizando un adecuado proceso de codificación de información para poder evitar que
esta pueda ser desvelada y llegue a personas no autorizadas. De forma que, en casos
de ciberataques como el presente, el cifrado y seudonimización impiden que se
materialice el tratamiento no autorizado, puesto que pese a que el ciberatacante
consiga usurpar los datos personales, no llegará a conocerlos por ser ininteligibles al
hallarse cifrados, y no podrá hacer un uso posterior ilegítimo de los mismos. Esta
obligación de cifrado es esencial, entonces, para cumplir con el deber de
confidencialidad impuesto al responsable del tratamiento.

En este sentido, el Considerando 75 del RGPD hace referencia a los riesgos para los
derechos y libertades de las personas que se generan en estas situaciones:

“Los riesgos para los derechos y libertades de las personas físicas, de gravedad y
probabilidad variables, pueden deberse al tratamiento de datos que pudieran
provocar daños y perjuicios físicos, materiales o inmateriales, en particular en los
casos en los que el tratamiento pueda dar lugar a problemas de discriminación,
usurpación de identidad o fraude, pérdidas financieras, daño para la reputación,
pérdida de confidencialidad de datos sujetos al secreto profesional, reversión no
autorizada de la seudonimización o cualquier otro perjuicio económico o social
significativo; en los casos en los que se prive a los interesados de sus derechos y
libertades o se les impida ejercer el control sobre sus datos personales; en los
casos en los que los datos personales tratados revelen el origen étnico o racial, las
opiniones políticas, la religión o creencias filosóficas, la militancia en sindicatos y el
tratamiento de datos genéticos, datos relativos a la salud o datos sobre la vida
sexual, o las condenas e infracciones penales o medidas de seguridad conexas; en
los casos en los que se evalúen aspectos personales, en particular el análisis o la
predicción de aspectos referidos al rendimiento en el trabajo, situación económica,
salud, preferencias o intereses personales, fiabilidad o comportamiento, situación o
movimientos, con el fin de crear o utilizar perfiles personales; en los casos en los
que se traten datos personales de personas vulnerables, en particular niños; o en
los casos en los que el tratamiento implique una gran cantidad de datos personales
y afecte a un gran número de interesados”.

En el presente supuesto, de acuerdo con los hechos probados primero a cuarto de
esta Resolución, consta acreditado que:

- Se produjo una brecha de confidencialidad de los datos personales que se
hallaban incluidos en la tabla “***TABLA.1: direcciones y clientes” de la antigua
plataforma de tienda online de CECOTEC, como consecuencia del ciberataque
de un actor malicioso que publicó un anuncio de venta de los datos extraídos de
dicha plataforma en un foro de la dark web con fecha de 5-4-23, al que se refiere
el hecho probado primero, que fue advertido por el INCIBE el mismo día y
comunicado a la empresa en diversas ocasiones hasta que ésta detectó la
existencia de una brecha de confidencialidad de datos personales y la notificó a
esta Agencia.

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

135/173

- Se ha confirmado que el actor malicioso pudo acceder de forma ilegítima a la
información contenida en dicha plataforma, y que dispone, como mínimo, de un
total de 1.000 registros incluidos en dicha tabla “***TABLA.1: direcciones y
clientes” de CECOTEC, correspondientes a 933 personas que constan incluidas
en la muestra que éste proporcionó al inspector del procedimiento de
actuaciones previas con fecha de 4 de agosto de 2023, que se haya unido al
procedimiento con fecha de 2 de noviembre de 2023.

- Tal y como se hace constar en la Diligencia de 14 de febrero de 2023 unida al
presente procedimiento -cuya copia se remitió a la parte reclamada junto con la
propuesta de resolución-, una vez comparados los datos de la muestra 2 con los
datos incluidos en la tabla ***TABLA.1, cuyo contenido íntegro fue aportado por
CECOTEC con fecha de 24-9-23, no cabe duda de la coincidencia absoluta de
los 24 campos y los 1000 registros incluidos en ambos listados (muestra y tabla),
siendo incluso idénticos los 4 tipos de códigos identificadores de la base de
datos, por lo que se ha constatado sin lugar a dudas que el ciber atacante ha
podido acceder a estos datos personales de forma ilegítima. Lo que se reconoce
por la propia reclamada en sus alegaciones a la propuesta de resolución, tal y
como consta en el hecho probado cuarto.

- No ha podido acreditarse cuál fue el vector de entrada que posibilitó el
ciberataque, por lo que se imputa responsabilidad alguna a la misma por no
haber adoptado las medidas organizativas y técnicas adecuadas para impedir
que el ciber atacante pudiera acceder a la plataforma y exfiltrar estos datos
personales. Tal y como se detalla en los Fundamentos de Derecho III al V,
aunque concurre una alta probabilidad de que el vector de entrada que posibilitó
la exfiltración de datos personales por el ciber delincuente, fue la falta de
actualización de la plataforma desde 2019, y la existencia de una vulnerabilidad
crítica en el año 2022 publicada por el fabricante de ***SOFTWARE.1, para la
que se publicó una actualización que reparaba la misma que no fue descargada
por la reclamada; lo cierto es que no concurre una prueba de cargo suficiente
que permita determinar este nexo de causalidad entre la existencia de
vulnerabilidades y deficiencias no corregidas de la plataforma que alojaba los
datos y la exfiltración realizada a raíz del ciber incidente.

- No obstante, si se ha acreditado que existió una actuación negligente de la
empresa responsable del tratamiento en la vulneración de confidencialidad de
los datos personales exfiltrados, puesto que sí ha sido acreditado que los datos
personales contenidos en las dos muestras proporcionadas por el actor
malicioso (en el anuncio y en la muestra proporcionada posteriormente al
inspector) no habían sido cifrados ni seudonimizados.

Al respecto de esta cuestión, pese a que la reclamada dice haber adoptado
medidas de cifrado sobre las copias de seguridad alojadas en Amazon y en los
protocolos de comunicación de los datos en sus alegaciones a la propuesta de
resolución, no se ha acreditado que hubiera aplicado medidas de cifrado sobre
la base de datos en reposo donde se alojaban los datos personales accedidos y
exfiltrados ni sobre los servidores o dispositivos donde se hallaban
almacenados los datos personales exfiltrados. Y, sin embargo, si consta

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

136/173

acreditado que los datos personales que fueron exfiltrados de la tabla
***TABLA.1 de la plataforma no habían sido cifrados ni seudonimizados en
origen (en reposo) antes de su exfiltración, puesto que todos los datos
personales exfiltrados que aparecen en la muestra 2 de 1000 registros que fue
proporcionada por el actor malicioso al inspector son legibles e inteligibles.

En definitiva, de todo lo expuesto se deduce que se ha probado durante la instrucción
que el ciber atacante dispone de parte del contenido de una base de datos de
CECOTEC (al menos, de los datos personales de las 933 personas con DNI válido
que aparecían en la muestra proporcionada al inspector de este procedimiento sin
cifrar ni seudonimizar). Ello implica que el riesgo de pérdida de confidencialidad de los
datos personales al que estaba sometida la base de datos se ha materializado, puesto
que: (i) por una parte, se ha producido una filtración o usurpación de los datos
personales a los que se ha hecho referencia anteriormente, accediendo un tercero
ilegítimamente a los mismos, que ha podido conocer su contenido íntegro, dado que
no habían sido codificados por CECOTEC; (ii) y por otra parte, esta usurpación de
datos personales ha permitido que el ciber atacante pueda utilizados para usos no
autorizados por sus titulares (vendidos, comunicados, publicados, explotados para
otros usos…etc), todo ello sin consentimiento de sus titulares.

Por tanto, ha quedado acreditado en este supuesto que la brecha de confidencialidad
producida ha conllevado una pérdida total y absoluta de control sobre los datos
personales por sus titulares y el responsable del tratamiento, y, lo que es peor, al
hallarse los datos a la venta desde 5-4-23 existe un riesgo muy alto de que se haga un
uso fraudulento de los mismos (usurpación de identidad, fraude, pérdidas financieras,
etc.) o de que sirvan para cualquier otra utilidad que en determinadas circunstancias
constituya una amenaza para sus titulares. Debe tenerse en cuenta además que la
mayoría de los datos personales filtrados son datos que no pueden ser modificados o
cambiados por otros (nombre, apellidos, DNI, domicilio…).

Esta pérdida de control sobre los propios datos personales se traduce en una
vulneración del derecho fundamental a la protección de datos reconocido en el artículo
18. 4 de la Constitución Española, pues tal y como ha indicado el Tribunal
Constitucional (Sentencia 292/2000, de 30 de noviembre de 2000): “el derecho
fundamental a la protección de datos persigue garantizar a la persona un poder de
control sobre sus datos personales, sobre su uso y destino, con el propósito de
impedir su tráfico ilícito y lesivo para la dignidad y derecho del afectado (…)”, toda vez
que el derecho a la protección de datos garantiza a los individuos un poder de
disposición sobre esos datos, que solo pueden estar en manos de personas
autorizadas por alguna base de licitud prevista en la normativa de protección de datos.

Por tanto, se entiende que cabe confirmar que CECOTEC es responsable de la
comisión de una infracción del artículo 5.1.f), desestimando las alegaciones realizadas
por la empresa al respecto de la misma por los motivos que se han hecho constar en
los Fundamentos de Derecho IV y V de esta Propuesta, toda vez que:

- Tal y como se ha hecho constar al contestar a las alegaciones formuladas por
CECOTEC, en el presente supuesto se entiende que la empresa es culpable de
incumplir su deber de proteger la confidencialidad de los datos personales que
han sido exfiltrados, no porque el ciber atacante haya podido acceder y exfiltrar

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

137/173

los datos personales contenidos en la citada tabla ***TABLA.1 de su antigua
plataforma de tienda online, sino porque se ha demostrado que no había
aplicado sobre los mismos los necesarios procesos de cifrado y seudonimización
de datos personales que los hubieran convertido en ininteligibles para las
personas que no dispongan de la clave de descifrado de los mismos.

Cifrado que no hubiera impedido el acceso ilegítimo a los datos personales por el
ciber atacante pero sí hubiera evitado que se vulnerase la confidencialidad de
los mismos, puesto que ello le hubiera impedido entender (y, por tanto, conocer)
su contenido, así como utilizarlos, procediendo a su difusión a terceros, y/o
publicación en internet, como efectivamente ha sucedido en este supuesto, en el
que consta que la base de datos fue puesta a la venta en un foro de la dark web
con fecha de 5.4.23.

- En relación con el Principio ne bis in idem, no habiéndose realizado alegaciones
en la propuesta de resolución frente a la argumentación realizada al contestar
las alegaciones al acuerdo de inicio (al contestar a la alegación primera de las
formuladas por la imputada en el fundamento de derecho IV), cabe entender
confirmado que no concurre en este supuesto una vulneración del Principio Ne
Bis in Idem ni se deben aplicar las reglas sobre concurrencia de sanciones, por
lo que no cabe aplicar la regla prevista en el artículo 29 de la LRJSP, toda vez
que la responsable del tratamiento ha incurrido en el incumplimiento de dos
obligaciones diferentes, incurriendo en dos actuaciones negligentes (en este
caso, omisiones), por lo que estamos ante la presencia de dos conductas
diferentes (obligaciones exigibles al responsable) cuya omisión vulnera los
intereses jurídicos protegidos en dos preceptos diferentes:

- La omisión del deber de cifrado y seudonimización de los datos prevista en
el artículo 5.1.f) del RGPD supone una actuación negligente que vulnera la
obligación de proteger la confidencialidad prevista en el art. 5.1.f) del RGPD.
- Y la omisión del resto de medidas organizativas y técnicas de la plataforma
que se han constatado en el hecho probado octavo de esta propuesta
vulneran el deber de mantener la seguridad de la plataforma prevista en el
artículo 32 del RGPD.

Además, no puede decirse que “se sancione la misma conducta dos veces”, toda
vez que la omisión del deber de cifrado de los datos personales únicamente se
va a considerar para imputar una actuación negligente de la responsable en la
comisión de la infracción del artículo 5.1.f) del RGPD, y no para imputar una
actuación negligente en la comisión de la infracción del artículo 32 del RGPD, lo
que se justifica por la falta de adopción del resto de medidas organizativas y
técnicas de seguridad a las que se refiere el hecho probado octavo.

Por tanto, como ya se ha dicho, no cabe aplicar el Principio de Consunción
alegado por la imputada, toda vez que estamos en presencia de un supuesto de
“pluralidad de acciones” o concurso real de infracciones, y no un supuesto de
“concurrencia de ofensas” o concurso medial de infracciones, de acuerdo con lo
previsto en las Directrices aprobadas por el CEPD a las que se ha hecho
referencia anteriormente (Guía de multas).

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

138/173

En consecuencia, tras la instrucción practicada, se considera que los hechos probados
son constitutivos de una infracción del artículo 5.1.f) del RGPD, por no haber adoptado
los mecanismos y medidas necesarias para garantizar la confidencialidad de los datos
personales que fueron objeto de exfiltración por el ciber incidente publicado el día 5-4-
23, toda vez que se ha acreditado que la reclamada no había adoptado las medidas
técnicas de cifrado y seudonimización que hubieran sido apropiadas para proteger la
confidencialidad de los datos personales contenidos en la misma en caso de que se
produjera una posible exfiltración no autorizada de datos personales como la presente,
impidiendo al tercero no autorizado que, pese a disponer de los mismos, no pudiera
conocer su contenido, publicarlo, explotarlo para otros fines, así como difundirlos y
cederlos a terceros, por hallarse encriptados y ser ininteligibles.

VII.

Tipificación de la infracción del artículo 5.1.f) RGPD

La infracción del Principio contenido en el artículo 5.1.f) del RGPD se encuentra
tipificada en el artículo 83.5 a) del RGPD, que dispone que:

“4. Las infracciones de las disposiciones siguientes se sancionarán, de acuerdo
con el apartado 2, con multas administrativas de 20 000 000 EUR como máximo
o, tratándose de una empresa, de una cuantía equivalente al 4 % como máximo
del volumen de negocio total anual global del ejercicio financiero anterior,
optándose por la de mayor cuantía:

a) las obligaciones del responsable y del encargado a tenor de los artículos 8,
11, 25 a 39, 42 y 43.”

Por su parte, la LOPDGDD en su artículo 72, a efectos de prescripción, califica de
“Infracciones consideradas muy graves:

“Infracciones consideradas muy graves: 1. En función de lo que establece el
artículo 83.5 del Reglamento (UE) 2016/679 se consideran muy graves y
prescribirán a los tres años las infracciones que supongan una vulneración
sustancial de los artículos mencionados en aquel y, en particular, las siguientes:

1. El tratamiento de datos personales vulnerando los principios y garantías
establecidos en el artículo 5 del Reglamento (UE) 2016/679.”

VIII.

Sanción por el incumplimiento del artículo 5.1.f) RGPD

A fin de establecer la multa administrativa que procede imponer han de observarse las
previsiones contenidas en los artículos 83.1 y 83.2 del RGPD, que señalan:

“1. Cada autoridad de control garantizará que la imposición de las multas
administrativas con arreglo al presente artículo por las infracciones del presente
Reglamento indicadas en los apartados 4, 5 y 6 sean en cada caso individual
efectivas, proporcionadas y disuasorias.

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

139/173

2. Las multas administrativas se impondrán, en función de las circunstancias de
cada aso individual, a título adicional o sustitutivo de las medidas contempladas
en el artículo 58, apartado 2, letras a) a h) y j). Al decidir la imposición de una
multa administrativa y su cuantía en cada caso individual se tendrá debidamente
en cuenta:

a) la naturaleza, gravedad y duración de la infracción, teniendo en cuenta la
naturaleza, alcance o propósito de la operación de tratamiento de que se trate
así como el número de interesados afectados y el nivel de los daños y perjuicios
que hayan sufrido;
b) la intencionalidad o negligencia en la infracción;
c) cualquier medida tomada por el responsable o encargado del tratamiento para
paliar los daños y perjuicios sufridos por los interesados;
d) el grado de responsabilidad del responsable o del encargado del tratamiento,
habida cuenta de las medidas técnicas u organizativas que hayan aplicado en
virtud de los artículos 25 y 32;
e) toda infracción anterior cometida por el responsable o el encargado del
tratamiento;
f) el grado de cooperación con la autoridad de control con el fin de poner
remedio a la infracción y mitigar los posibles efectos adversos de la infracción;
g) las categorías de los datos de carácter personal afectados por la infracción;
h) la forma en que la autoridad de control tuvo conocimiento de la infracción, en
particular si el responsable o el encargado notificó la infracción y, en tal caso, en
qué medida;
i) cuando las medidas indicadas en el artículo 58, apartado 2, hayan sido
ordenadas previamente contra el responsable o el encargado de que se trate en
relación con el mismo asunto, el cumplimiento de dichas medidas;
j) la adhesión a códigos de conducta en virtud del artículo 40 o a mecanismos de
certificación aprobados con arreglo al artículo 42, y
k) cualquier otro factor agravante o atenuante aplicable a las circunstancias del
caso, como los beneficios financieros obtenidos o las pérdidas evitadas, directa
o indirectamente, a través de la infracción.

En relación con la letra k) del artículo 83.2 del RGPD, la LOPDGDD, en su artículo 76,
“Sanciones y medidas correctivas”, establece que:

“2. De acuerdo a lo previsto en el artículo 83.2.k) del Reglamento (UE)
2016/679 también podrán tenerse en cuenta:

a) El carácter continuado de la infracción.
b) La vinculación de la actividad del infractor con la realización de tratamientos
de datos personales.
c) Los beneficios obtenidos como consecuencia de la comisión de la infracción.
d) La posibilidad de que la conducta del afectado hubiera podido inducir a la
comisión de la infracción.
e) La existencia de un proceso de fusión por absorción posterior a la comisión
de la infracción, que no puede imputarse a la entidad absorbente.
f) La afectación a los derechos de los menores.

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

140/173

g) Disponer, cuando no fuere obligatorio, de un delegado de protección de
datos.
h) El sometimiento por parte del responsable o encargado, con carácter
voluntario, a mecanismos de resolución alternativa de conflictos, en aquellos
supuestos en los que existan controversias entre aquellos y cualquier
interesado.”

En este caso, considerando la gravedad de la infracción constatada, atendiendo
especialmente a las consecuencias que su comisión provoca en los interesados,
procede imponer una sanción de multa.

La multa que se imponga deberá ser, en cada caso individual, efectiva, proporcionada
y disuasoria, conforme a lo establecido en el artículo 83.1 del RGPD. Para garantizar
estos principios, se considera, con carácter previo, la condición de gran empresa, y el
volumen de negocio de la parte reclamada.

De acuerdo con los preceptos transcritos, una vez practicada la instrucción del
procedimiento, a efectos de fijar el importe de la sanción a imponer en el presente
caso por la infracción tipificada en el artículo 5.1.f) del RGPD, tipificada en el artículo
83.5.a) del RGPD de la que se responsabiliza a la empresa, se estiman concurrentes
los siguientes criterios de graduación de la sanción:

1. Artículo 83.2.a) RGPD. “la naturaleza, gravedad y duración de la infracción,
teniendo en cuenta la naturaleza, alcance o propósito de la operación de
tratamiento de que se trate, así como el número de interesados afectados y el
nivel de los daños y perjuicios que hayan sufrido”.

Tal y como se ha señalado en los Fundamentos de Derecho III y IV de esta
Propuesta, el acuerdo de inicio fijó la “sanción inicial” partiendo de un número
de 6 registros de personas reales que la empresa CECOTEC reconoció y
reconoce como afectados por la filtración, puesto que antes de la instrucción
únicamente se había comprobado que el ciberatacante disponía de los 17
registros correspondientes a 6 personas, que constaban en la primera muestra
publicada por el ciberatacante en el anuncio.

No obstante, tras la instrucción practicada, se ha acreditado a través de las
evidencias que constan en el hecho probado cuarto de esta propuesta, que el
ciber atacante ha tenido acceso ilegítimo a un total de 1000 registros
correspondientes a un total de 933 personas físicas que constan identificadas
con un DNI válido, tras haberse realizado una validación de DNI y
comprobado que todos estos registros constaban y coinciden exactamente con
los incluidos en la tabla ***TABLA.1: direcciones de clientes y pedidos que fue
proporcionada por CECOTEC durante la fase de prueba. Siendo esta cantidad
de afectados una cuestión no controvertida en las alegaciones a la propuesta
de resolución presentadas por la responsable del tratamiento.

En cuanto a la naturaleza de los datos personales afectados, hay que tener en
cuenta que la filtración se refiere a los siguientes tipos de datos personales
que aparecen en la muestra de 1.000 registros que fue proporcionada al
inspector, de acuerdo con el listado Excel que se adjunta al Anexo I de la

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

141/173

Diligencia de 13 de febrero de 2025 son los siguientes:

o Dirección postal 1 (indicando la calle, número, código postal y ciudad).
o Códigos identificadores: código de dirección, código de país, y los
códigos de cliente, proveedor y fabricante.
o Nombre y apellidos
o Número DNI.
o Teléfono fijo y teléfono móvil.

Por tanto, la propuesta de resolución propuso elevar la cuantía de la sanción,
a la vista de estos hechos probados. No obstante, tal y como se indicó
anteriormente el fundamento de derecho V, se procede a estimar la alegación
formulada por CECOTEC relativa al incremento de la cuantía de la multa en
base al número de afectados.

Respecto a la duración de la infracción, hay que considerar que los datos
personales han sido puestos a la venta en la dark web con fecha de 5 de abril
de 2023, y que continúan actualmente a la venta, y sin que pueda
determinarse la fecha de cesación de efectos de la filtración, que es de
carácter indefinido.

2. Art. 83.2b) “la intencionalidad o negligencia en la infracción”.

Aunque no se puede entender que la entidad actuara con dolo, se observa que
concurre un grado de negligencia grave de la entidad en el cumplimiento de las
obligaciones que le impone la normativa de protección de datos, puesto que,
como ya se ha señalado al contestar a las alegaciones formuladas, se entiende
que concurre una actuación negligente de la empresa, por no haber aplicado
las medidas necesarias de cifrado y seudonimización de datos personales a su
base de datos personales, servidores y dispositivos, que no hubieran impedido
que el ciberatacante accediese ilegítimamente a los mismos, y los extrajera o
exfiltrase, pero si hubiera impedido que se materializase la vulneración de
confidencialidad de los datos, puesto que de haber estado codificados el
ciberataque no hubiera podido conocer su contenido, descifrarlos sin tener la
clave, ni, por ende, utilizarlos, ni publicarlos ni cederlos a terceros.

No obstante, para la fijación de la cuantía a imponer por la actuación negligente
cometida, se considera que concurre negligencia grave sólo respecto a la
omisión de estas medidas de cifrado y pseudonimización, al no haberse
acreditado que concurriese negligencia por no haber adoptado las medidas que
hubieran podido impedir el ciber ataque, por lo que la sanción fijada es menor
de la que correspondería en el caso de que se hubiera podido acreditar que
concurrían ambas conductas negligentes u omisiones de medidas.

En este sentido puede citarse la SAN de 17/10/2007, que si bien fue dictada
antes de la vigencia del RGPD su pronunciamiento es perfectamente
extrapolable al supuesto que analizamos. La sentencia, después de aludir a
que las entidades en las que el desarrollo de su actividad conlleva un continuo
tratamiento de datos de clientes y terceros han de observar un adecuado nivel
de diligencia, precisaba que “(...) el Tribunal Supremo viene entendiendo que

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

142/173

existe imprudencia siempre que se desatiende un deber legal de cuidado, es
decir, cuando el infractor no se comporta con la diligencia exigible. Y en la
valoración del grado de diligencia ha de ponderarse especialmente la
profesionalidad o no del sujeto, y no cabe duda de que, en el caso ahora
examinado, cuando la actividad de la recurrente es de constante y abundante
manejo de datos de carácter personal ha de insistirse en el rigor y el exquisito
cuidado por ajustarse a las prevenciones legales al respecto” (artículo 83.2, b)
del RGPD).

3. “La actividad de la entidad presuntamente infractora se encuentra vinculada
con el tratamiento de datos de carácter personal tanto de clientes como de
terceros” (artículo 76.2.b) de la LOPDGDD en relación con el artículo 83.2.k).

En la actividad de la entidad imputada es imprescindible el tratamiento de datos
de carácter personal por ser su objeto social el comercio al por mayor de
electrodomésticos y aparatos electrónicos a través de plataformas de gestión
de tienda online de clientes, proveedores y empleados de la empresa
investigada, por lo que la transcendencia de la conducta objeto de la presente
reclamación es innegable.

En consecuencia, con los elementos que se disponen, y en atención al volumen de
negocio de la empresa, se procede a imponer una sanción de multa de 140.000
euros, por la comisión de una infracción del artículo 5.1.f) del RGPD.

IX.

Incumplimiento de la obligación del artículo 32 RGPD

Por otra parte, y con independencia del deber de garantizar la confidencialidad de los
datos personales previsto en el artículo 5.1.f) del RGPD, todo responsable del
tratamiento que gestione bases de datos personales de sus clientes, empleados o
proveedores con acceso a internet, como lo hace la empresa sobre la que versa el
presente procedimiento, está obligado también a adoptar procedimientos que
contengan las medidas técnicas y organizativas que sean apropiadas para garantizar
que estas bases de datos personales tengan un nivel de seguridad adecuado al
riesgo, entre los que se encuentra la posibilidad de sufrir ciberataques o robos de
datos de carácter personal o la suplantación de identidad, entre otros.

En concreto, es el artículo 32 del RGPD “Seguridad del tratamiento”, el que establece
esta obligación:

“1. Teniendo en cuenta el estado de la técnica, los costes de aplicación, y la
naturaleza, el alcance, el contexto y los fines del tratamiento, así como riesgos de
probabilidad y gravedad variables para los derechos y libertades de las personas
físicas, el responsable y el encargado del tratamiento aplicarán medidas técnicas y
organizativas apropiadas para garantizar un nivel de seguridad adecuado al riesgo,
que en su caso incluya, entre otros:

a) la seudonimización y el cifrado de datos personales;

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

143/173

b) la capacidad de garantizar la confidencialidad, integridad, disponibilidad y
resiliencia permanentes de los sistemas y servicios de tratamiento;
c) la capacidad de restaurar la disponibilidad y el acceso a los datos
personales de forma rápida en caso de incidente físico o técnico;
d) un proceso de verificación, evaluación y valoración regulares de la eficacia
de las medidas técnicas y organizativas para garantizar la seguridad del
tratamiento.

2. Al evaluar la adecuación del nivel de seguridad se tendrán particularmente en
cuenta los riesgos que presente el tratamiento de datos, en particular como
consecuencia de la destrucción, pérdida o alteración accidental o ilícita de datos
personales transmitidos, conservados o tratados de otra forma, o la comunicación o
acceso no autorizados a dichos datos.

3. La adhesión a un código de conducta aprobado a tenor del artículo 40 o a un
mecanismo de certificación aprobado a tenor del artículo 42 podrá servir de
elemento para demostrar el cumplimiento de los requisitos establecidos en el
apartado 1 del presente artículo.

4. El responsable y el encargado del tratamiento tomarán medidas para garantizar
que cualquier persona que actúe bajo la autoridad del responsable o del encargado
y tenga acceso a datos personales solo pueda tratar dichos datos siguiendo
instrucciones del responsable, salvo que esté obligada a ello en virtud del Derecho
de la Unión o de los Estados miembros”.

Hay que señalar que el RGPD no establece en el citado precepto un listado de las
medidas de seguridad que sean de aplicación de acuerdo con los datos que son objeto
de tratamiento, sino que establece que el responsable y el encargado del tratamiento
aplicarán medidas técnicas y organizativas que sean adecuadas al riesgo que conlleve
el tratamiento, teniendo en cuenta el estado de la técnica, los costes de aplicación, la
naturaleza, alcance, contexto y finalidades del tratamiento, los riesgos de probabilidad
y gravedad para los derechos y libertades de las personas interesadas.

Esto es, de acuerdo con el Principio de responsabilidad proactiva inspirador de la
regulación contenida en el RGPD, el responsable deberá evaluar todos los riesgos
concurrentes y determinar, por sí mismo y bajo su propia responsabilidad, cuáles son
las medidas de seguridad adecuadas al específico tratamiento que esté realizado.
Dicho de otra forma, la falta de enumeración de un listado general de medidas a
adoptar en el RGPD no excluye la obligación de tener disponibles y en correcto
funcionamiento todas las medidas necesarias.

Para garantizar estos factores de la seguridad son necesarias medidas tanto de índole
técnica como de índole organizativo que sean adecuadas.

Estas medidas de protección deben resultar adecuadas y proporcionadas al riesgo
detectado. Ello implica realizar un análisis de riesgos previo al tratamiento. Al evaluar
la adecuación del nivel de seguridad al riesgo se tendrán particularmente en cuenta los
riesgos que presente el tratamiento de datos de que se trate, en el sentido expresado
en el Considerando 83 del RGPD señala que:

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

144/173

“A fin de mantener la seguridad y evitar que el tratamiento infrinja lo dispuesto en el
presente Reglamento, el responsable o el encargado deben evaluar los riesgos
inherentes al tratamiento y aplicar medidas para mitigarlos, como el cifrado. Estas
medidas deben garantizar un nivel de seguridad adecuado, incluida la
confidencialidad, teniendo en cuenta el estado de la técnica y el coste de su
aplicación con respecto a los riesgos y la naturaleza de los datos personales que
deban protegerse. Al evaluar el riesgo en relación con la seguridad de los datos, se
deben tener en cuenta los riesgos que se derivan del tratamiento de los datos
personales, como la destrucción, pérdida o alteración accidental o ilícita de datos
personales transmitidos, conservados o tratados de otra forma, o la comunicación o
acceso no autorizados a dichos datos, susceptibles en particular de ocasionar
daños y perjuicios físicos, materiales o inmateriales”.

En el presente supuesto, partimos de una situación concreta de convivencia de dos
plataformas de gestión de tienda online de clientes, proveedores y empleados de la
empresa investigada, que no fue correctamente ejecutada desde el punto de vista de
protección de los datos personales que seguían gestionándose en la plataforma
antigua.
Al respecto, la empresa afirma que:

“La plataforma fue sustituida por una nueva tienda en línea desarrollada
internamente que adoptó tecnologías de desarrollo web de código abierto más
modernas. La decisión de cerrar la plataforma original en favor de la nueva solución
se basó en la limitación que el sistema ***SOFTWARE.1 comenzó a mostrar en
relación con las demandas crecientes del comercio electrónico moderno. Esta
transición se completó a principios de 2021. A pesar del cierre de la plataforma
original, se ha mantenido un acceso limitado a la misma (su ***INTERFAZ.1) con el
único fin de poder atender solicitudes, necesidades y/o reclamaciones de clientes
de la empresa”.

Tal y como consta en el hecho probado segundo de esta propuesta, se ha acreditado
en este supuesto que CECOTEC venía realizando operaciones de tratamiento de los
datos personales contenidos en la plataforma ***SOFTWARE.1 1.6 de tienda online
para prestar servicios de comercio electrónico vía servicios web desde el año 2016
(según manifiesta la misma), y ha continuado realizando operaciones de tratamiento
sobre los mismos hasta la actualidad, si bien ha realizado diferentes cambios en el
tratamiento, que por otra parte, no se reflejan documentalmente en su RAT, pero no ha
adaptado el tratamiento a las nuevas obligaciones que surgieron con la entrada en
vigor del nuevo RGPD el 25 mayo de 2018, cuya aprobación supuso un cambio de
paradigma que reforzó exponencialmente las garantías de los interesados, con la
consiguiente imposición de obligaciones a los responsables del tratamiento de datos
personales.

Así pues, consta que:

- Inició el tratamiento de los datos personales en el año 2016, y cuando entró en
vigor el nuevo RGPD no adaptó el tratamiento de los datos personales
contenidos en dicha plataforma a las nuevas obligaciones derivadas del mismo,
que eran exigibles desde el mismo día el 25 mayo de 2018, siendo todos los
documentos aportados a este procedimiento posteriores al año 2021 y 2022.

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

145/173

Así pues, pese a ser obligatorio, no analizó los riesgos en los derechos y
libertades de los interesados a los efectos de analizar si era precisa una EIPD,
para elaborar la misma, ni adoptó las medidas de seguridad a las que se refiere
el artículo 32 del RGPD, ni aprobó un adecuado protocolo de gestión de
brechas de datos personales que se comunicase a todo el personal. Todos los
documentos aportados datan de 2021 (Protocolo de gestión de incidentes de
seguridad) o de 2022 (Análisis de riesgos, medidas de formación del
personal..etc), y sus requisitos no se ajustan a las obligaciones legales.
Habiendo corregido a raíz del ciberataque algunos de estos incumplimientos
mediante las medidas correctivas que constan acreditadas en el hecho probado
noveno de esta Propuesta.

- Hay que decir además que la situación de incumplimiento empeoró cuando se
implantó la nueva tienda en línea a principios de 2021, a partir de la cual, se
creó una nueva plataforma para los nuevos clientes generados a partir de
2021, pero se optó por no realizar una migración de los datos contenidos en la
antigua plataforma a la nueva, eliminando su exposición en internet, migración
que CECOTEC señalaba como “prevista en los próximos meses” durante la
fase de investigación, sin haber vuelto a manifestar nada más al respecto, más
allá de afirmar que ha inhabilitado su acceso a internet, sin señalar qué ha
ocurrido con los datos personales que se almacenan en la misma.

Así pues, en su Resp#2, CECOTEC señala que cuando creó la nueva
plataforma de tienda online a partir de enero de 2021, prefirió mantener el
tratamiento de los datos personales contenidos en la plataforma antigua pero
limitada (…) manteniendo almacenados los datos personales de sus clientes,
proveedores y fabricantes generados entre 2016 y 2020 en esta plataforma
antigua, lo cual es perfectamente posible. Pero constan evidencias en el
procedimiento de que la falta de migración de datos personales a la nueva
plataforma no se acompañó de las debidas actualizaciones y garantías que
asegurasen que (…) que continuaba operativa estuviera debidamente
protegida.

- Efectivamente, y a raíz de las comprobaciones realizadas por el responsable
de ciberseguridad en la plataforma, para comprobar la veracidad del
ciberataque, se ha constatado que a fecha de detección de la brecha producida
(14-4-23 según el correo electrónico aportado como Anexo 6), la plataforma
adolecía de las vulnerabilidades que se señalan en el hecho probado octavo de
esta Propuesta. Esto es, la versión 1.6 de la plataforma en la que se hallaban
los datos personales filtrados estaba basada en una versión obsoleta y
desactualizada del software ***SOFTWARE.1, sobre con vulnerabilidades
conocidas tanto en su ***SERVICIO.2 como en su ***SERVICIO.1, fuera de
soporte desde el año 2019, y que disponía de la parte de administración
(***SERVICIO.1) con acceso público desde internet (aunque restringido por
usuario y contraseña). Y además, se puso de manifiesto que a fecha de
detección de la brecha (14-4-23) que no se habían adoptado las medidas
organizativas y técnicas de seguridad en dicha plataforma que constan en el
citado hecho probado.

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

146/173

Plataforma que continuaba gestionando en ese momento más de 2 millones de
registros con datos personales (solo la tabla “***TABLA.1” aportada durante la
fase de prueba contenía un total de 2.057.313 registros, que se reducen a
2.054.164 registros que disponen de teléfono móvil). Y que al quedarse en
estas condiciones en enero de 2021, quedaba desde entonces sin la adecuada
protección que garantizase la trazabilidad, disponibilidad, confidencialidad,
integridad, y autenticidad de los datos personales contenidos en ella.

En concreto, tal y como se motiva en el Fundamento de Derecho Tercero de esta
resolución, en relación con las medidas organizativas y técnicas se hallaban
implantadas a fecha del ciberataque y antes de detectar la brecha de seguridad para
garantizar la seguridad de los datos personales contenidos en la antigua plataforma
***SOFTWARE.1 de tienda online de CECOTEC (denominadas como medidas
preventivas en el informe API), consta como acreditado en el hecho probado octavo de
esta Propuesta que:

- La plataforma estaba provista únicamente de las medidas preventivas que
CECOTEC manifestó y acreditó durante la fase de investigación del presente
procedimiento: que el inspector reflejó en su informe API.

 (…)
- Se ha detectado que la plataforma adolecía de las siguientes deficiencias y
vulnerabilidades de versión, que eran necesarias para proteger la seguridad de
la plataforma, y por tanto, de adopción obligatoria para el responsable del
tratamiento de acuerdo con lo previsto en el artículo 32 del RGPD.

Nos referimos con ello a la constatación de que existían vulnerabilidades que
afectaban al ***SERVICIO.1 y al ***SERVICIO.2, a que la plataforma se hallaba
desactualizada, y fuera de soporte desde 2019 y con acceso a internet (con
código de usuario y contraseña.

Todas ellas fueron reconocidas por el responsable de ciberseguridad en el
correo de 14-4-23, puestas de manifiesto por CECOTEC en su Resp#2, y
comprobadas por el inspector mediante Diligencia de 2 de noviembre de 2023.

Como ya se ha señalado en diversas ocasiones, aunque no se haya acreditado
que estas fueran el origen o vector de entrada del ciberataque, su omisión si
debe castigarse porque supone un incumplimiento del artículo 32 del RGPD.

- Y, por otra parte, se ha comprobado también que no se habían adoptado las
siguientes medidas necesarias para garantizar un nivel de seguridad adecuado
al riesgo:

 Falta de medidas adecuadas para garantizar la trazabilidad de la
plataforma: Las referidas a los logs, la falta de monitorización, y a la falta
de control de acceso de los usuarios de la plataforma que se detallan en
el hecho probado octavo.

 Falta actualización del Análisis de Riesgos de la plataforma.

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

147/173

Consta en el expediente que la empresa no realizó un adecuado
análisis de riesgos previo al tratamiento inicial de 2013, ni tras la
entrada en vigor del RGPD en mayo de 2018, ni previo a la modificación
sufrida por la plataforma en 2021.

El informe definitivo de los análisis de riesgos para los derechos y
libertades de las personas afectadas por las actividades de tratamiento
relacionadas con la brecha (clientes) aportado por la empresa es del 10
de abril de 2022, cuando el tratamiento de datos personales de clientes
se inició el 2013, según el RAT, o en 2016, según manifiesta la
empresa.

Además de ser tardío, este análisis de riesgos de 2022 no considera
todos los riesgos concurrentes con la diligencia exigible a un
responsable de una base de datos de más de 2 millones de registros.
Entre otras cosas, analiza conjuntamente los riesgos de los tratamientos
de datos de clientes y proveedores; gestión de RRHH y selección de
personal, de una forma confusa y sin expresar independientemente los
riesgos correspondientes a cada tipo de tratamiento afectado, ni graduar
su nivel de gravedad de forma adecuada.

Tampoco ha sido actualizado dicho análisis de riesgos tras detectar las
vulnerabilidades puestas de manifiesto con el incidente. Manifiesta la
empresa en su escrito de 18 de agosto de 2023 que: “Se informa a la
AEPD que, en el último año el puesto de Delegado de Protección de
Datos ha sido ocupado por tres personas distintas, no habiendo una
continuidad en las funciones del Delegado de Protección de Datos
especificadas en el artículo 39 del Reglamento 2016/679 de 27 de abril
de 2016 (en adelante, “RGPD”). Es por ello por lo que, actualmente, la
empresa se encuentra en un proceso de revisión urgente de
documentos y de decisión de medidas a tomar y de procedimientos a
implementar, entre los que se encuentra la revisión de todos los análisis
de riesgos realizados y la valoración de la necesidad de realizar una
evaluación de impacto de los mismos”.

Y señala, que se ha constituido un Comité de Seguridad que tiene este
objetivo de revisión de documentos y adopción de medidas correctivas
el 14 de septiembre de 2023. No obstante, a fecha de hoy, la empresa
no ha aportado un nuevo análisis de riesgos adecuado al RGPD, ni ha
valorado si es necesario realizar una evaluación de impacto en los
términos previstos en el artículo 35 del RGPD. Pese a haber
manifestado en sus alegaciones al acuerdo de inicio de mayo de 2024
su intención de hacerlo en los próximos meses, las alegaciones a la
propuesta de resolución formuladas el pasado 18 de marzo de 2025 no
realizan mención alguna a este particular.

 Falta de aprobación y aplicación de un Protocolo de Gestión de Brechas
de Seguridad adecuado a la normativa.

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

148/173

De acuerdo con las evidencias que constan en el hecho probado
octavoy noveno de esta propuesta, se deduce que a fecha de detección
de la brecha (13-4-23), la empresa no había cumplido con su obligación
de establecer procedimientos que permitiesen la pronta detección y
comunicación de este tipo de alertas dentro de su organización, de
acuerdo con lo que se señala en la “Guía para la notificación de brechas
de datos personales” publicada por esta Agencia, y lo previsto en las
Directrices del Consejo Europeo de Protección de Datos (en adelante,
CEPD), máxima autoridad europea en la materia.

Así pues, las Directrices 01/2021 del CEPD sobre ejemplos de
notificación de brechas de datos personales, adoptadas el 14 de enero
de 2021, que señalan que: “11. Todos los responsables y encargados
del tratamiento deben contar con planes y procedimientos para tratar
posibles violaciones de la seguridad de los datos. Las organizaciones
deben contar con jerarquías claras y personas responsables de
determinados aspectos del proceso de recuperación”

Y tal y como desarrolla ampliamente en el apartado II de las Directrices
WP 250 sobre notificación de brechas de datos personales de 3 de
octubre de 2017: “El artículo 32 deja claro que el responsable y el
encargado del tratamiento deben disponer de las medidas técnicas y
organizativas adecuadas para garantizar un nivel adecuado de
seguridad de los datos personales: la capacidad para detectar, abordar
y notificar una violación en tiempo oportuno debe considerarse un
elemento esencial de estas medidas.”

Tal y como consta en el hecho probado noveno, antes de detectar la
brecha, CECOTEC ha aportado al procedimiento un protocolo de
gestión de Brechas de Seguridad con fecha 31 de julio de 2023, fecha
de actualización de 29 de agosto de 2023, que fue realizado con
posterioridad a recibir el primer requerimiento de investigación realizado
por esta Agencia, y debe entenderse adoptado como medida correctiva.

Antes de detectarse la brecha el 13-4-23, únicamente consta aprobado
un Protocolo de Gestión de incidentes de seguridad de 22-4-21, que no
consta firmado, y no se ajustaba a los requerimientos previstos en la
normativa aplicable, según las Directrices del CEPD a las que se ha
hecho referencia anteriormente. No se ha acreditado por la empresa
que este protocolo de 2021 fuera conocido y aplicado por el personal de
la empresa, puesto que no se aporta acreditación de su publicación o
comunicación al personal.

Es más, de las evidencias existentes en el procedimiento se deduce que
el Protocolo de 2021, no fue correctamente aplicado por el personal
encargado de detectar la brecha del 5.4.23, toda vez que: (i) la primera
alerta de ciber incidente del INCIBE se recibió el 5-4-23 al buzón
general, pero no se remitió a los responsables de detectar y gestionar la
brecha, tal y como señalaba el protocolo; (i) ni tampoco se aplicó por el
responsable de ciberseguridad y la DPD que intervinieron en la

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

149/173

detección, análisis, y respuesta de la brecha, puesto que éstos
desconocían que el protocolo indicaba que bastaba con tener una
certeza suficiente de que se pudiera haber producido una brecha, y
ambos entendieron que era necesario tener una certeza absoluta de
que se había producido la exfiltración de todos los datos que decía tener
el ciber atacante paraque fuera necesario hacer la notificación a la
agencia y la comunicación a los afectados, como se desprende de las
comunicaciones aportadas al procedimiento y las propias
manifestaciones realizadas en el informe del DPD aportados al
procedimiento.
Además, por otra parte, la empresa manifiesta en sus escritos de 30 de agosto y 18 de
septiembre de 2023, y en sus alegaciones al acuerdo de inicio, que ha adoptó nuevas
medidas para fortalecer la seguridad de la plataforma tras el incidente al que se refiere
la brecha. Estas nuevas medidas se califican como medidas correctivas en el hecho
probado noveno, y son las siguientes:

- Tras detectar la brecha, se adoptan las medidas correctivas que tiene por
acreditadas el inspector en su informe API:

 (…)
- Con posterioridad a conocer el inicio de actuaciones previas de investigación,
la empresa aprueba un Protocolo de Brechas de Seguridad el 31 de julio de
2023, actualizado a 29 de agosto de 2023, que remite junto con su Resp#2.
- Con posterioridad al acuerdo de inicio de este expediente el 1 de abril de 2024,
la instructora ha comprobado mediante Diligencia de 3 de junio de 2024, que se
ha procedido a deshabilitar el acceso a la plataforma desde internet. Sin
embargo, se dice en las alegaciones al acuerdo de inicio -pero no se acredita ni
se dan detalles al respecto- que ha cesado el tratamiento de los datos
personales contenido en esta plataforma. Y pese a que se hizo referencia a esta
falta de acreditación en la propuesta de resolución, la reclamada sigue sin
presentar acreditación de haber cesado el tratamiento de los datos personales
en sus alegaciones frente a la propuesta. Por tanto, no cabe tener por
acreditado el cese del tratamiento, sino la deshabilitación de la plataforma de
internet.

La adopción de estas medidas correctivas que, sin duda, hubiera sido necesario
implantar con anterioridad, acreditan por sí solas que el responsable no tuvo en cuenta
los riesgos que suponía mantener activo el ***INTERFAZ.1 esta antigua plataforma
desactualizada y sin soporte ni medidas adecuadas de protección. Toda vez que es
indubitado que algunas de estas medidas deberían haberse previsto desde el inicio del
tratamiento de la plataforma en 2016, y otras desde que se inició la migración a la
nueva plataforma, cerrando parcialmente la antigua en 2021.
En conclusión, a la vista de los hechos probados durante la fase de instrucción, cabe
confirmar que – incluso aunque no se hubiera llegado a materializar una pérdida de
confidencialidad o filtración de datos personales a causa de un ciberataque como se
ha producido en el supuesto presente-, la empresa sería responsable de haber
vulnerado gravemente la obligación prevista del artículo 32 del RGPD respecto a
los datos personales que contenía esta plataforma, dado que se ha acreditado que

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

150/173

existía la falta casi absoluta del procedimiento adecuado que estableciese medidas de
seguridad técnicas y organizativas apropiadas, adoptados para garantizar un nivel de
seguridad adecuado al riesgo en relación, entre otras cuestiones citadas, con los datos
personales contenidos en su plataforma de tienda online. Habiendo quedado
acreditado también que la empresa no había realizado un adecuado análisis de
riesgos que reflejase los riesgos derivados del tratamiento, analizase su impacto, y
previera las medidas adecuadas para mitigar, reducir o evitar los mismos.

X.

Tipificación de la infracción del artículo 32 RGPD

La vulneración del artículo 32 del RGPD se encuentra tipificada en el artículo 83.4.a)
del citado RGPD en los siguientes términos:

“4. Las infracciones de las disposiciones siguientes se sancionarán, de acuerdo
con el apartado 2, con multas administrativas de 10 000 000 EUR como máximo
o, tratándose de una empresa, de una cuantía equivalente al 2 % como máximo
del volumen de negocio total anual global del ejercicio financiero anterior,
optándose por la de mayor cuantía:

a) las obligaciones del responsable y del encargado a tenor de los artículos 8,
11, 25 a 39, 42 y 43.”

Por su parte, la LOPDGDD en su artículo 73, a efectos de prescripción, califica de
“Infracciones consideradas graves:

En función de lo que establece el artículo 83.4 del Reglamento (UE) 2016/679 se
consideran graves y prescribirán a los dos años las infracciones que supongan
una vulneración sustancial de los artículos mencionados en aquel y, en particular,
las siguientes: f) La falta de adopción de aquellas medidas técnicas y
organizativas que resulten apropiadas para garantizar un nivel de seguridad
adecuado al riesgo del tratamiento, en los términos exigidos por el artículo 32.1
del Reglamento (UE) 2016/679”
XI.
Sanción por el incumplimiento del artículo 32 RGPD

De acuerdo con los preceptos transcritos en el fundamento de derecho VIII (artículos
83.1 y 2 del RGPD, y 76 de la LOPDGDD), en este caso, considerando la gravedad de
la infracción constatada, atendiendo especialmente a las consecuencias que su
comisión provoca en los interesados, procede imponer una sanción de multa.

La multa que se imponga deberá ser, en cada caso individual, efectiva, proporcionada
y disuasoria, conforme a lo establecido en el artículo 83.1 del RGPD. Para garantizar
estos principios, se considera, con carácter previo, la condición de gran empresa, y el
volumen de negocio de la parte reclamada.

Una vez practicada la instrucción del procedimiento, a efectos de fijar el importe de la
sanción a imponer en el presente caso por la infracción tipificada en el artículo 32 del

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

151/173

RGPD, tipificada en el artículo 83.4 del RGPD de la que se responsabiliza a la
empresa, se estiman concurrentes los siguientes criterios de graduación de la sanción:

1. Artículo 83.2.a) RGPD. “la naturaleza, gravedad y duración de la infracción,
teniendo en cuenta la naturaleza, alcance o propósito de la operación de
tratamiento de que se trate, así como el número de interesados afectados y el
nivel de los daños y perjuicios que hayan sufrido”.

En relación con la gravedad de la conducta infractora deben considerarse
como factor agravante en este caso el número elevado de deficiencias o
vulnerabilidades detectadas en la plataforma, y el grado de escasez de
medidas organizativas y técnicas que habían sido adoptadas por la empresa
sobre los datos personales de la plataforma para garantizar un nivel de
seguridad adecuado al riesgo, con la finalidad última de proteger los derechos
y libertades de las personas físicas que se contenían en la misma, no
habiendo realizado un adecuado análisis de los riesgos del tratamiento que
concurrían, su impacto y las medidas y garantías que era necesario adoptar
para garantizar un nivel de seguridad apropiado al riesgo de los datos
personales tratados en esta plataforma.

Así mismo, se considera que la infracción del artículo 32 del RGPD reviste
especial gravedad en este supuesto, dado que la base de datos contenida en
la plataforma disponía de más de dos millones de registros (solo en su tabla
“***TABLA.1” que es la que se ha aportado por la empresa imputada) y
contenía datos de carácter personal como el domicilio, DNI, NIF, teléfono,
domicilio, y otros campos de los interesados a los que ya se ha hecho
referencia en la Diligencia de 13 de febrero de 2025.

Así pues, teniendo en cuenta que la falta de medidas adecuadas afectaba a
toda la base de datos personales contenida en la plataforma, se entiende que
con esta infracción se estaba poniendo en riesgo los derechos y libertades de
un volumen muy elevado y nutrido de clientes, empleados y proveedores de la
entidad, al no analizar los riesgos exhaustivamente y adoptar las medidas
técnicas y organizativas apropiadas para garantizar su seguridad de
conformidad con las nuevas exigencias del RGPD.

Y en este caso, se considera también para valorar la gravedad de la infracción
que estamos en presencia de un número muy elevado de afectados puesto
que la reclamada manifiesta que solamente la tabla ***TABLA.1 contenía datos
de más de 2.052.000 personas, cuyos datos personales fueron puestos en
riesgo. desde al menos el año 2016, sin adaptarse a las nuevas prescripciones
del RGPD que obligaban a realizar una gestión y análisis del riesgo, y a
adoptar las medidas a las que se refiere el artículo 32 del RGPD. Riesgo que
se incrementó exponencialmente en 2019 cuando se dejó de contratar el
soporte y actualizar la plataforma, y de nuevo en el año 2021 al cerrar el
***SERVICIO.2 de la misma, como ya se ha señalado. Siendo por tanto la
duración de la infracción continuada de más de 6 años (entre la entrada en
vigor del RGPD y la actualidad, en la que siguen sin adoptarse todas las
medidas correctivas necesarias para adecuar el tratamiento al RGPD).

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

152/173

2. El grado de intencionalidad o negligencia en la infracción del artículo 83.2.b)
del RGPD.

Aunque no se puede considerar que el reclamado actuara con intencionalidad
o dolo, se confirma que concurre una gravísima falta de diligencia calificada
como negligencia muy grave en el cumplimiento de la obligación que establece
el artículo 32, que mantenía los datos personales contenidos en la plataforma
de tienda online en un estado casi absoluto de desprotección. El nivel de
incumplimiento es tal que podemos hablar de una infracción sistémica, de una
falta de procedimiento casi absoluta en relación con el establecimiento y la
adopción de las medidas de seguridad técnicas y organizativas apropiadas,
por los motivos expresados al contestar a las alegaciones en el Fundamento
de Derecho V.

Respecto a la posibilidad de sancionar la falta de diligencia, nos remitimos de
nuevo a lo indicado en la Sentencia de la Audiencia Nacional de 17/10/2007.

3. La actividad de la entidad presuntamente infractora se encuentra vinculada
con el tratamiento de datos de carácter personal tanto de clientes como de
terceros.

En la actividad de la entidad imputada es imprescindible el tratamiento de
datos de carácter personal por ser su objeto social el comercio al por mayor
de electrodomésticos y aparatos electrónicos a través de plataformas de
gestión de tienda online de clientes, proveedores y empleados de la empresa
investigada, por lo que la transcendencia de la conducta objeto de la presente
reclamación es innegable (artículo 76.2.b) de la LOPDGDD en relación con el
artículo 83.2.k).

A efectos de decidir sobre la imposición de la multa y su cuantía, de conformidad con
la instrucción practicada, teniendo en cuenta en su conjunto los criterios de graduación
de la sanción del artículo 83.2 del RGPD a los que se ha hecho referencia, y el
volumen de negocio de la reclamada, con respecto a la infracción cometida por
vulneración del artículo 32 del RGPD, se considera que debe imponerse a la parte
reclamada una sanción de multa de 750.000 € (Setecientos cincuenta mil euros).
XII.
Incumplimiento de la obligación del Artículo 33 del RGPD.

Constatada la concurrencia de una brecha de datos personales, el responsable del
tratamiento tiene la obligación de notificarla en los términos y supuestos previstos en el
Artículo 33 del RGPD sobre “Notificación de una violación de la seguridad de los datos
personales a la autoridad de control”, que establece:

“1. En caso de violación de la seguridad de los datos personales, el responsable
del tratamiento la notificará a la autoridad de control competente de conformidad
con el artículo 55 sin dilación indebida y, de ser posible, a más tardar 72 horas
después de que haya tenido constancia de ella, a menos que sea improbable que
dicha violación de la seguridad constituya un riesgo para los derechos y las
libertades de las personas físicas. Si la notificación a la autoridad de control no

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

153/173

tiene lugar en el plazo de 72 horas, deberá ir acompañada de indicación de los
motivos de la dilación.

2. El encargado del tratamiento notificará sin dilación indebida al responsable del
tratamiento las violaciones de la seguridad de los datos personales de las que
tenga conocimiento.

3. La notificación contemplada en el apartado 1 deberá, como mínimo:
a) describir la naturaleza de la violación de la seguridad de los datos personales,
inclusive, cuando sea posible, las categorías y el número aproximado de
interesados afectados, y las categorías y el número aproximado de registros de
datos personales afectados;
b) comunicar el nombre y los datos de contacto del delegado de protección de
datos o de otro punto de contacto en el que pueda obtenerse más información;
c) describir las posibles consecuencias de la violación de la seguridad de los
datos personales;
d) describir las medidas adoptadas o propuestas por el responsable del
tratamiento para poner remedio a la violación de la seguridad de los datos
personales, incluyendo, si procede, las medidas adoptadas para mitigar los
posibles efectos negativos.

4. Si no fuera posible facilitar la información simultáneamente, y en la medida en
que no lo sea, la información se facilitará de manera gradual sin dilación indebida.

5. El responsable del tratamiento documentará cualquier violación de la seguridad
de los datos personales, incluidos los hechos relacionados con ella, sus efectos y
las medidas correctivas adoptadas. Dicha documentación permitirá a la autoridad
de control verificar el cumplimiento de lo dispuesto en el presente artículo.”

Tal y como se ha expuesto en los Fundamento de Derecho IV y V, al contestar a las
alegaciones formuladas por la empresa, en el presente supuesto se ha acreditado que
se produjo una brecha de confidencialidad de datos personales contenidos en una de
las tablas contenidas en la antigua plataforma de venta online de CECOTEC, que
afectó a un mínimo de 933 personas cuyos datos se hallaban incluidos en la misma

Hay evidencias suficientes de que concurren los presupuestos del artículo 33 del
RGPD que obligan a notificar la brecha a esta autoridad de control, puesto que se ha
producido una “violación de seguridad de los datos personales” (brecha de datos
personales), y no es improbable que la brecha constituya un riesgo para los derechos
y las libertades de las personas físicas.

En el presente supuesto, la empresa ha notificado la brecha de datos personales a
esta Agencia con fecha de 19 de abril de 2023, pero no en los términos y plazos
exigidos por el artículo 33 del RGPD, que se refiere a que la empresa responsable del
tratamiento estaba obligada a notificar la violación de la seguridad de los datos
personales a esta autoridad de control “sin dilación indebida y, de ser posible, a más
tardar 72 horas después de que haya tenido constancia de ella”.

Del análisis de los correos electrónicos aportados por la empresa como Anexos 6 y 7
del escrito de alegaciones de 30 de diciembre de 2023, y del Informe de análisis del

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

154/173

incidente de la DPD acompañado como Anexo 3 del mismo escrito, se desprende la
siguiente cronología de los hechos en relación con la detección y notificación de la
brecha:

o La alerta de ciber incidente de seguridad en una base de datos de CECOTEC
fue detectada y comunicada por primera vez a la empresa por INCIBE mediante
correo electrónico remitido el mismo día 5-4-23 a las 14:53 horas, fecha en la
que el usuario malicioso publicó un post en el foro de la dark web anunciando
que disponía de una base de datos de una empresa española que podría
corresponderse con CECOTEC. No obstante, la empresa no dio respuesta a
este correo ni comenzó las comprobaciones hasta que no recibió una segunda
comunicación por correo electrónico de INCIBE a las 11:10 horas del 12-4-23,
ante la falta de respuesta de CECOTEC, solicitando reportase qué había
ocurrido con el incidente comunicado el 5-4-23.

o La segunda notificación de brecha realizada por INCIBE el 12-4-23, sí fue
contestada por el responsable de ciberseguridad, que no disponiendo del primer
correo, requirió su remisión a INCIBE el día 12-4-23, perdiendo otro día más
hasta que recibió esta información de INCIBE el día 13-4-23, cuando ésta ya
había sido proporcionada en el correo inicial de 5-4-23, que estaba en el buzón
de la empresa.

o INCIBE remitió de nuevo la información el mismo día 13-4-23 a las 11:10 horas,
comenzando entonces el responsable de ciberseguridad de la empresa las
comprobaciones oportunas de cotejo de la muestra y análisis de seguridad de la
plataforma, que podrían calificarse de inicio del “periodo de investigación
necesario para comprobar que existe un grado razonable de certeza de la
brecha” al que se refieren las Directrices 9/2022, sobre la notificación de las
violaciones de la seguridad de los datos personales en el marco del RGPD,
según se ha explicado en el Fundamento de Derecho IV al contestar a las
alegaciones de la responsable.

o El mismo día 13-4-23 a las 17.26 horas el responsable de ciberseguridad
concluye la investigación realizada e informa al INCIBE de lo siguiente:

“Los datos que se muestran en la imagen que ha suministrado el usuario
***USUARIO.1 en ***FORO.1 se tratan de datos de prueba. Por otro lado,
la web con dichos datos se cerró en 2021 y no sigue en funcionamiento.
Por ahora, no podemos determinar si se considera una filtración con solo
la imagen que se muestra. La referencia de lo que se está hablando es
[***REFERENCIA.1]. De todas formas, estamos a vuestra disposición
para lo que necesitáis”.

o Con fecha de 14-4-23 a las 14:31 horas, se remite un correo electrónico
del departamento de ciberseguridad a la DPD de CECOTEC, que se ha
transcrito literalmente en el hecho probado quinto, donde le informa de lo
sucedido, las contestaciones al INCIBE, y el resultado de estas
investigaciones, y esta señala que decide notificar la brecha de forma proactiva
por haber afectado dichos 17 registros a 6 personas reales.

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

155/173

o La notificación de la violación de la seguridad de los datos personales a esta
Agencia no se realiza hasta el 19-4-23.

Tal y como se ha señalado al contestar a las alegaciones sobre el cómputo del plazo
de notificación de la brecha, no cabe duda de que la falta de diligencia de la empresa
cometida al notificar la brecha:

- Primero, porque se ha acreditado que no disponían de un Protocolo de gestión
de brechas adecuado a la normativa, que cumpliera con los requisitos a los que
hace referencia las Directrices 09/22 sobre notificación de brechas del CEPD,
sino de un Protocolo de Gestión de Incidentes de Seguridad de 2021, que no se
adecuaba a los requisitos mínimos para ser considerado un Protocolo de
gestión de brechas.

- Y segundo porque la empresa no aplicó su propio Protocolo de gestión de
incidentes de 2021 (que regulaba cómo detectar un incidente de seguridad, y
notificar una brecha), cuya comunicación a los empleados y responsables con
anterioridad a la brecha no consta acreditada. Puesto que consta en el
expediente:

 Que los encargados del buzón general de CECOTEC no remitieron a
los responsables de detectar la brecha y notificarla la primera alerta de
incidente de ciberseguridad. En el Protocolo de 2021 no constan los
datos de las personas a las que debía realizase dicha comunicación.
Consta que la empresa corrigió este defecto tras el incidente,
remitiendo un correo el 19 de abril de 2023 en el que informaba de las
direcciones a las que debían remitirse todas las alertas, tras preguntar
porqué no se les había remitido la alerta de 5/4/23.

 Que tanto el responsable de ciberseguridad como la DPD de la
empresa, desconocían que su Protocolo señalaba que no era
necesario conocer a “ciencia cierta” cuál había sido el vector de
entrada del ciberataque ni si había afectado a la totalidad de registros
de la base de datos para entender que concurría una brecha de datos
personales. Puesto que el responsable de ciberseguridad niega que
exista filtración, entendiendo erróneamente que precisaba disponer de
todos los registros que decía tener el actor malicioso para poder tener
una certeza de que se había producido la brecha, cuando ya había
comprobado que los 17 registros que contenía la muestra publicada en
el anuncio coincidían con los incluidos en la tabla ***TABLA.1 de la
plataforma, lo que podía considerarse como una “certeza suficiente”
de que fuera probable que la brecha se había producido respecto a
estos. Y, en la misma línea, la DPD señaló en su informe que la
notificación se hizo de forma proactiva, y pese a no tener obligación,
porque no se le daba verosimilitud al ciberataque, puesto que el

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

156/173

responsable de ciberseguridad no había logrado determinar a “ciencia
cierta” que se había producido. Queda patente, pues, que ninguno de
los responsables intervinientes en el proceso conocía realmente
cuáles eran los mecanismos que permiten determinar cuando se debe
notificar una brecha a esta Agencia. Y además, se limitaron a alegar
que precisaban una mayor muestra de registros para comprobarlo sin
contactar con el actor malicioso para obtenerla -como hizo el inspector
del procedimiento- y dicen haber solicitado al INCIBE que les aportase
mayor información -cuando todos los correos de alerta del mismo
indicaban claramente que para mayor información podían contactar
con el actor malicioso.

De haberse aplicado un adecuado protocolo de detección y gestión de
brechas, las actuaciones de comprobación que debieron conformar el
“breve periodo de investigación inicial” a la que se refieren las Directrices
09/22 del CEPD debió haber comenzado el 5 de abril de 2023, cuando se
recibió la primera alerta. Y habiendo la reclamada reconocido que se
percató de que había recibido la segunda alerta de 12-4-23, no cabe duda
de que, como mínimo, debieron comenzar las investigaciones precisas de
comprobación el 12 de abril de 2023 cuando se recibió el segundo
recordatorio, sin tener que esperar a recibir de nuevo el correo del INCIBE
con dicha información el 13 de abril de 2023, dado que CECOTEC podía
recuperar el correo inicial de su buzón y conocer todos los datos
necesarios para iniciar dicha investigación.

No obstante estar constatada esta dilación indebida al detectar la brecha, lo cierto es
que el retraso indebido en el inicio de las investigaciones prueba que la reclamada no
disponía de las medidas adecuadas de detección, prevención y mitigación de los
efectos de las posibles brechas de esta plataforma, que supone un incumplimiento de
adoptar las medidas organizativas y técnicas del artículo 32 del RGPD. Pero ello no
influye en el cómputo del plazo máximo de 72 horas que se imputa como infracción del
artículo 33 del RGPD, cuyo día de inicio o dies ad quo ha sido un hecho
controvertido del procedimiento.

Tal y como se ha señalado en los Fundamentos de Derecho III a V, el inicio del plazo o
dies ad quo comienza cuando la empresa “tuvo constancia de la brecha”, lo que
supone tener “un grado razonable de certeza” de que se había producido la brecha,
según manifiestan las Directrices 09/22 del CEPD sobre notificación de brechas,
indicando lo siguiente:

“40. Por consiguiente, debe quedar claro que el responsable del
tratamiento está obligado a actuar a partir de cualquier alerta inicial y a
determinar si se ha producido o no una violación. Este breve período
permite que se realicen algunas investigaciones y que el responsable
del tratamiento reúna pruebas y otros detalles pertinentes. No obstante,

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

157/173

una vez que el responsable del tratamiento haya establecido con un
grado razonable de certeza que se ha producido una violación, si se
cumplen las condiciones del artículo 33, apartado 1, del RGPD, deberá
notificarlo a las autoridades de control sin dilación indebida y, de ser
posible, en un plazo máximo de setenta y dos horas. Si un responsable
del tratamiento no actúa de manera rápida y resulta evidente que se ha
producido una violación, esto podría considerarse una falta de
notificación de conformidad con el artículo 33 del RGPD.”

En el presente supuesto, se considera que el “breve periodo de investigación” para
comprobar si existía un grado razonable de certeza de la brecha era necesario, y que
concluyó al finalizar las investigaciones del departamento de ciberseguridad e informar
al INCIBE de su resultado.

De acuerdo con la cronología señalada, tal y como se ha señalado al contestar a las
alegaciones, queda acreditado que la investigación necesaria para tener un grado
razonable de certeza de la brecha concluyó el 13-4-23 a las 17:26 horas, cuando el
responsable de ciberseguridad de CECOTEC concluyó la investigación e informó al
INCIBE de que los datos de la muestra coincidían con los contenidos en la plataforma
de CECOTEC, toda vez que:

- El último correo informando del incidente y posible brecha al INCIBE fue
este de 13-4-23, siendo los posteriores para comprobar un intento de
phishing.

- Así lo reconoce la DPD en el informe adjunto a la Resp#1, cuando señala:
“no fue hasta el jueves 13 de abril de 2023 cuando el lNCIBE aportó toda
la información referente a la posible brecha y, por tanto, cuando CECOTEC
fue verdaderamente consciente de esta supuesta amenaza.

- Cuando se remitió el correo a la DPD (14-4-23 a las 14:31 horas), el
departamento de ciberseguridad ya había concluido estas averiguaciones,
y detectado la brecha (aunque desconociera que la coincidencia de estos
17 registros y la existencia de estas vulnerabilidades y deficiencias
implicase tener un grado razonable de certeza de que había una brecha).
Ya que en este correo se enviaba un informe final completo a la DPD de en
el que se informó de todos los correos intercambiados con INCIBE, se
incluyeron muchos otros datos no informados al INCIBE, reconociendo
todas las vulnerabilidades y deficiencias detectadas, y que la muestra
coincidía íntegramente con los datos de la tabla ***TABLA.1.

De su lectura se deduce claramente que todos los análisis y
comprobaciones cuya información se amplía se habían realizado antes de
contestarle al INCIBE el 13-4-23. Así pues, tal y como se ha hecho constar
en el hecho probado quinto de esta propuesta, que transcribe íntegramente
este correo:

 Se hacen múltiples referencias a los análisis ya realizados en pasado (Tras
realizar el análisis, se vio que los registros de la tabla coinciden con los de

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

158/173

la tienda antigua de cecotec; Tras investigar junto al departamento de
ecommerce e infraestructura, pudimos ver los registros que tiene el
atacante de la base de datos son desde el 2016 al 2020; También
intentamos ver los logs para ver la trazabilidad; Tras analizar todos los
entornos, el departamento de ciberseguridad no puede determinar si ha
sido por culpa de un malware en un workstation o desde el propio
aplicativo web, ya que a nivel workstation no tenemos actualmente (…)…
etc).

 Y todos estos análisis o comprobaciones son anteriores a la conclusión
obtenida por el mismo, que es la siguiente:

“No obstante, aún no sabemos a ciencia cierta qué datos tiene el atacante,
y es por ello que le escribimos a incibe—cert ese mismo día jueves 13 de
abril de 2023 a las 17:26”.

En consecuencia, de las actuaciones se desprende que la fecha a partir de
la cual puede considerarse que CECOTEC fue consciente de que existía
un grado razonable de certeza de la brecha, por haber comprobado a
través de su departamento de ciberseguridad que ésta había afectado a
los 17 registros contenidos en la muestra publicada en el anuncio (que
afectaban a 6 personas reales), tras concluir sus investigaciones, fue el 13
de abril de 2023 a las 17:26 horas.

Tal y como se ha expuesto al contestar a las alegaciones a la propuesta de resolución
en el Fundamento de Derecho V, no cabe admitir que dicha fecha de inicio del
cómputo (dies ad quo) fuera: a) ni el 14 de abril de 2023 a las 14:31 horas cuando el
director de ciberseguridad remitió correo electrónico a la DPD informando de las
comunicaciones mantenidas y la investigación realizada a la misma, por ser el día
anterior cuando se tuvo certeza suficiente o razonable de que coincidían los 17
registros y se comunicó este hecho al INCIBE, con independencia de que no se
informase detalladamente de ello a la DPD hasta el día siguiente; b) ni mucho menos
el 17 de abril de 2023, respecto del que la reclamada no aporta ningún motivo
justificativo, puesto que la comunicación realizada al INCIBE en tal fecha se limitó a
constatar que su correo no se trataba de una alerta de phishing.

Será, por tanto, a partir del 13 de abril de 2024 a las 17:26 horas cuando deberá
computarse el plazo inicial (dies ad quo) para notificar la brecha a esta agencia,
aplicando las reglas de cómputo de plazo previstas en el reglamento europeo al que
hizo referencia el acuerdo de inicio (Reglamento CEE, EURATOM nº 1182/71, de 3 de
junio de 1971).

Aclarado el dies ad quo o fecha en la que comenzó el inicio del plazo para notificar la
brecha, cabe entrar en la cuestión de las reglas de cómputo de plazo a los
efectos de fijar el dies ad quem o fecha fin en la que concluyó el plazo máximo de 72
horas fijado para notificar la brecha.

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

159/173

Por lo que respecta a las reglas de cómputo de plazo, la empresa partió en sus
alegaciones al acuerdo de inicio de varias premisas erróneas que fueron aclaradas en
la propuesta de resolución, sin haber sido cuestionadas por la misma en las
alegaciones frente presentadas posteriormente por la misma:

- Realizar un cómputo en días hábiles, en lugar de en horas como señala el
artículo 33 del RGPD.

- Aplicar las reglas de cómputo de plazos previstas en la normativa española,
siendo que según el propio artículo 30 de la LPACAP, estas reglas son
aplicables “salvo que por ley o normativa europea se disponga otra cosa”, como
es el caso, en que existe un reglamento europeo que regula esta cuestión.

- Proponer una aplicación incorrecta de la regla prevista en el artículo 30.6 de la
LPACAP, que dispone lo siguiente: “·Cuando un día fuese hábil en el municipio
o Comunidad Autónoma en que residiese el interesado, e inhábil en la sede del
órgano administrativo, o a la inversa, se considerará inhábil en todo caso”,
puesto que el día 17-4-23 no consta como día inhábil en el calendario de días
inhábiles a efecto de cómputo de plazos para el año 2023, que fue aprobado
por Resolución de la Secretaría de Estado de Función Pública de 1 de
diciembre de 2022, donde se incluyen los días inhábiles a nivel nacional y en
cada comunidad autónoma.

En el caso de plazos fijados por horas, y estando fijado el plazo en un Reglamento
europeo (RGPD), cabe aplicar lo previsto en el artículo 3 del Reglamento (CEE,
EURATOM) nº 1182/71, de 3 de junio de 1971, por el que se determinan las normas
aplicables a los plazos, fechas y términos, que dispone lo siguiente:
“Artículo 3 del Reglamento CEE 1182/71.

1. Si un plazo expresado en horas debe contarse a partir del momento en que
sobrevenga un acontecimiento o se cumplimente un acto, la hora durante la
cual ocurra dicho acontecimiento o se cumplimente dicho acto no se computara
en el plazo.

Si un plazo expresado en días, semanas, meses o años debe contarse a partir
del momento en que sobrevenga un acontecimiento o se cumplimente un acto,
el día durante el cual ocurra dicho acontecimiento o se cumplimente dicho acto
no se computara en el plazo.

2. Sin perjuicio de lo dispuesto en los apartados 1 y 4 :

a) el plazo expresado en horas empezar a correr al comienzo de la primera hora
y concluirá al finalizar la última hora del plazo;

b) el plazo expresado en días comenzará a correr al comienzo de la primera
hora del primer día y concluirá al finalizar la última hora del último día del plazo;

c) el plazo expresado en semanas, meses o años comenzara a correr al
comienzo de la primera hora del primer día del plazo y concluirá al finalizar la

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

160/173

última hora del día que, en la última semana, en el último mes o en el último
año, lleve el mismo nombre o la misma fecha que el día a partir del cual
empieza a computarse un plazo. Si en un plazo expresado en meses o años,
falta en el último mes el día en que debe expirar el plazo, éste concluirá al
finalizar la última hora del último día de dicho mes ;

d) si un plazo comprende partes de un mes , se considerara , para el cálculo de
estas partes , que un mes se compone de treinta días.

3. Los plazos comprenderán los días festivos, los domingos y los sábados,
salvo si éstos quedan expresamente excluidos o si los plazos se expresan en
días hábiles.

4. Si el último día de un plazo expresado de cualquier otro modo, menos en
horas , es un día festivo, un domingo o un sábado , el plazo concluirá al finalizar
la última hora del día hábil siguiente.

Esta disposición no se aplicará a los plazos calculados retroactivamente a partir
de una fecha o de un suceso determinado.

5. Todo plazo de dos días o más comprenderá, por lo menos, dos días hábiles.”

En consecuencia, se considera que el inicio del plazo fue el 13-4-23 a las 17:23 horas
(lo que sería el “acontecimiento” a partir del cual empieza a correr el plazo en horas
según el citado artículo 3 del Reglamento), de la aplicación de este precepto se
deduce que el plazo comenzó a computar “al comienzo de la primera hora siguiente”,
esto es desde las 18:00 horas del día 13-4-23 y finalizó a las 18:00 horas del día 16-
4-23, cuando transcurrieron 72 horas.

No cabe descontar las horas de los días festivos que cayeron en sábado y domingo,
dado que la normativa europea aplicable no prevé el concepto de horas inhábiles
como regla general, señalando en el artículo 3.3 del citado Reglamento CEE que: “
Los plazos comprenderán los días festivos, los domingos y los sábados, salvo si éstos
quedan expresamente excluidos o si los plazos se expresan en días hábiles.”, no
concurriendo una excepción en el supuesto presente que permita excluir del cómputo
las horas correspondientes al sábado y domingo.

En consecuencia, pese a haber realizado una interpretación favorable a la empresa
responsable a los efectos de considerar que la misma tuvo constancia de la brecha
cuando concluyeron las investigaciones del día 13-4-23 – en lugar del 5.4.23 cuando
se recibió la alerta del INCIBE o el día 12.4.23 cuando se recibió la segunda, sin tener
en cuenta las dilaciones indebidas que se produjeron previamente y retrasaron
indebidamente el inicio de estas investigaciones y la detección de la brecha,- lo cierto
es que, aún así, cabe concluir que la empresa excedió el plazo de 72 horas para
notificar al brecha desde que concluyó las mismas. Toda vez que el plazo concluía el
16-4-23 a las 18:00horas y la brecha no fue notificada hasta el 19-4-23 a las 18:19
horas (72 horas y 19 minutos después de que concluyese el plazo)

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

161/173

Por todo lo expuesto, tras la instrucción practicada, se entiende acreditado que se ha
excedido en este caso el plazo máximo de 72 horas previsto en el art.33 del RGPD
para notificar la brecha, por lo que cabe confirmar que la empresa CECOTEC ha
incurrido en una infracción administrativa por vulneración del artículo 33 del RGPD, por
no haber notificado la brecha en plazo (duplicando el plazo máximo permitido).

XIII.

Tipificación de la infracción del artículo 33 del RGPD

Confirmada la citada vulneración de la obligación de notificar la brecha a la autoridad
de protección de datos prevista en el artículo 33 del RGPD, ello supone la comisión de
una infracción tipifica en el artículo 83.4 del RGPD que, bajo la rúbrica “Condiciones
generales para la imposición de multas administrativas”, dispone:

“Las infracciones de las disposiciones siguientes se sancionarán, de acuerdo con el
apartado 2, con multas administrativas de 10 000 000 EUR como máximo o,
tratándose de una empresa, de una cuantía equivalente al 2 % como máximo del
volumen de negocio total anual global del ejercicio financiero anterior, optándose
por la de mayor cuantía:

a) las obligaciones del responsable y del encargado a tenor de los artículos 8, 11,
25 a 39, 42 y 43; (…)”

A este respecto, la LOPDGDD, en su artículo 71 “Infracciones” establece que
“Constituyen infracciones los actos y conductas a las que se refieren los apartados 4,
5 y 6 del artículo 83 del Reglamento (UE) 2016/679, así como las que resulten
contrarias a la presente ley orgánica”.

A efectos del plazo de prescripción, el artículo 7. m) “Infracciones consideradas leves”
de la LOPDGDD indica:

“En función de lo que establece el artículo 83.4 del Reglamento (UE) 2016/679 se
consideran leves y prescribirán al año las infracciones que supongan una
vulneración sustancial de los artículos mencionados en aquel y, en particular, las
siguientes:

m) La notificación incompleta, tardía o defectuosa a la autoridad de protección de
datos de la información relacionada con una violación de seguridad de los datos
personales de conformidad con lo previsto en el artículo 33 del Reglamento (UE)
2016/679.

XIV.
Sanción por la infracción del artículo 33 del RGPD

De acuerdo con los preceptos transcritos en el fundamento de derecho VIII (artículos
83.1 y 2 del RGPD, y 76 de la LOPDGDD), en este caso, considerando la gravedad de

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

162/173

la infracción constatada, atendiendo especialmente a las consecuencias que su
comisión provoca en los interesados, procede imponer una sanción de multa.

La multa que se imponga deberá ser, en cada caso individual, efectiva, proporcionada
y disuasoria, conforme a lo establecido en el artículo 83.1 del RGPD. Para garantizar
estos principios, se considera, con carácter previo, la condición de gran empresa, y el
volumen de negocio de la parte reclamada.

Una vez practicada la instrucción del procedimiento, a efectos de fijar el importe de la
sanción a imponer en el presente caso por la infracción tipificada en el artículo 33 del
RGPD, tipificada en el artículo 83.4 del RGPD de la que se responsabiliza a la
empresa, se estiman concurrentes los siguientes criterios de graduación de la sanción:

1. Artículo 83.2.a) RGPD. “la naturaleza, gravedad y duración de la infracción,
teniendo en cuenta la naturaleza, alcance o propósito de la operación de
tratamiento de que se trate, así como el número de interesados afectados y el
nivel de los daños y perjuicios que hayan sufrido”.

Para graduar la sanción se considera a favor de la empresa responsable que la
brecha fue notificada a esta Agencia, y en contra que hubo un exceso del doble
del plazo establecido de 72 horas para notificar la misma, puesto que el plazo
para notificar comenzó el 13-4-23 a las 18 horas, concluyó el 16-4-23 a las
18:00 horas, pero la empresa responsable no notificó la brecha hasta el 19-4-
23 a las 18:19 horas.

Así mismo, cabe considerar que se tuvo una razonable certeza de que la
brecha detectada afectaba a un mínimo de 6 personas reales cuyos datos
aparecían en la muestra publicada por el actor malicioso, pero de la
investigación realizada el 13-4-23 cabe deducir que concurría una probabilidad
de alto riesgo sobre los derechos y libertades de las personas, así como un alto
riesgo de que el alcance de la brecha fuera mayor, en el caso de que se
hubiera podido comprobar posteriormente que era cierto que el actor malicioso
disponía de casi un millón de registros como decía tener en su anuncio, o de
más de un millón como manifestaba cuando contactó con el inspector. Y no
consta en este supuesto, que se ampliase la investigación a los efectos de
comprobar el alcance de la brecha y notificar la posible ampliación a esta
Agencia en su caso.

2. El grado de intencionalidad o negligencia en la infracción.

Aunque no se puede considerar que el reclamado actuara con intencionalidad
o dolo, se observa un grado de negligencia grave en el cumplimiento del plazo
para detectar y notificar la brecha, habiéndose acreditado que la empresa no
actuó con la diligencia exigible por los motivos que ya han sido expuestos en
el Fundamento de Derecho anterior, y desarrollados con detalle en el
Fundamento de Derecho 4.1 al contestar a las alegaciones formuladas por la
empresa responsable.

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

163/173

3. La actividad de la entidad presuntamente infractora se encuentra vinculada
con el tratamiento de datos de carácter personal tanto de clientes como de
terceros.

En la actividad de la entidad imputada es imprescindible el tratamiento de datos
de carácter personal por ser su objeto social la venta de electrodomésticos y
aparatos electrónicos a través de plataformas de gestión de tienda online de
clientes, proveedores y empleados de la empresa investigada, por lo que la
transcendencia de la conducta objeto de la presente reclamación es innegable
(artículo 76.2.b) de la LOPDGDD en relación con el artículo 83.2.k).

El balance de las circunstancias contempladas en el artículo 83.2 del RGPD y el
artículo 76.2 de la LOPDGDD, en atención al volumen de negocio de la empresa
reclamada, considerando en su conjunto las circunstancias de graduación
concurrentes, con respecto a la infracción cometida al vulnerar lo establecido en el
artículo 33 del RGPD, permite mantener la sanción inicial fijada y proponer una
sanción de 100.000 € (CIEN MIL EUROS).
XV.

Incumplimiento de la obligación del Artículo 34 del RGPD

El artículo 34 del RGPD prevé la obligación del responsable de “Comunicación de una
violación de la seguridad de los datos personales al interesado”, en los siguientes
términos:

“1. Cuando sea probable que la violación de la seguridad de los datos personales
entrañe un alto riesgo para los derechos y libertades de las personas físicas, el
responsable del tratamiento la comunicará al interesado sin dilación indebida.

2. La comunicación al interesado contemplada en el apartado 1 del presente
artículo describirá en un lenguaje claro y sencillo la naturaleza de la violación de la
seguridad de los datos personales y contendrá como mínimo la información y las
medidas a que se refiere el artículo 33, apartado 3, letras b), c) y d).

3. La comunicación al interesado a que se refiere el apartado 1 no será necesaria si
se cumple alguna de las condiciones siguientes:

a) el responsable del tratamiento ha adoptado medidas de protección técnicas y
organizativas apropiadas y estas medidas se han aplicado a los datos personales
afectados por la violación de la seguridad de los datos personales, en particular
aquellas que hagan ininteligibles los datos personales para cualquier persona que
no esté autorizada a acceder a ellos, como el cifrado;

b) el responsable del tratamiento ha tomado medidas ulteriores que garanticen que
ya no exista la probabilidad de que se concretice el alto riesgo para los derechos y
libertades del interesado a que se refiere el apartado 1;

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

164/173

c) suponga un esfuerzo desproporcionado. En este caso, se optará en su lugar por
una comunicación pública o una medida semejante por la que se informe de
manera igualmente efectiva a los interesados.

4. Cuando el responsable todavía no haya comunicado al interesado la violación de
la seguridad de los datos personales, la autoridad de control, una vez considerada
la probabilidad de que tal violación entrañe un alto riesgo, podrá exigirle que lo
haga o podrá decidir que se cumple alguna de las condiciones mencionadas en el
apartado 3”.

Por otro lado, como ya se ha indicado anteriormente, el considerando 75 del RGPD
enumera una serie de factores o supuestos asociados a riesgos para las garantías de
los derechos y libertades de los interesados.

De acuerdo con lo expuesto en el hecho probado sexto de esta propuesta, consta
acreditado en el procedimiento que la empresa responsable del tratamiento:

- Detectó la brecha (tuvo constancia al comprobar que existía un grado de
certeza razonable de que se había producido) el 13-4-23, y notificó la brecha a
esta Agencia el 19-4-23, pero decidió que no era necesario comunicar la brecha
a los 6 afectados que constaban en la muestra inicial proporcionada por el
anuncio del actor malicioso, dado que a su parecer la filtración producida no
tenía verosimilitud, y no entrañaba una probabilidad de alto riesgo.

- Y posteriormente al acuerdo de inicio, se le remitió copia del expediente, donde
constaba la muestra de 1.000 registros que el inspector obtuvo del actor
malicioso, y reconoció en sus alegaciones al acuerdo de inicio que había sido
víctima de un ciberataque de este actor malicioso. Y en las alegaciones a la
propuesta de resolución se reconoce por la reclamada que la brecha alcanzó a
los 933 afectados cuyos datos personales se contienen en esta segunda
muestra, de acuerdo con el Anexo I de la Diligencia de 13 de febrero de 2025.

Tanto en el acuerdo de inicio como en la propuesta de resolución se detallaron los
motivos por los que se entendía que la comunicación a los afectados por la brecha era
obligatoria en el presente supuesto. Y en concreto, tras practicarse la instrucción, la
propuesta de resolución expuso con detalle los motivos por los que la reclamada
estaba realizando un análisis erróneo de los riesgos derivados de la brecha producida,
determinando que concurría una probabilidad clara de alto riesgo, y que se cumplían el
resto de requisitos previstos en el artículo 34 del RGPD, que hacían exigible dicha
comunicación.

No obstante, en sus alegaciones a la propuesta de resolución la parte reclamada se
reitera y remite a las alegaciones previamente realizadas al respecto, insistiendo en
que no procede comunicar la brecha porque, a su juicio, no concurre alto riesgo,
aceptando que la cantidad de afectados asciende a 933 personas. Por tanto, sigue la
reclamada persistiendo en su conducta infractora, puesto que continúa sin comunicar
la brecha a los interesados, incrementando con ello los riesgos generados, incluso
después de conocer los motivos detallados por los que el acuerdo de inicio y la
propuesta de resolución han considerado que hubiera sido y sigue necesario
comunicar la brecha a los afectados.

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

165/173

Tal y como se ha señalado al contestar a las alegaciones formuladas en los
Fundamentos de Derecho III y IV, no cabe duda de que concurría en este supuesto la
obligación de comunicar la “violación de la seguridad de los datos personales” a los
afectados, puesto que concurren en el presente supuesto los requisitos previstos en el
artículo 34 del RGPD, cuales son: (i) que exista una probabilidad de que se haya
producido una violación de la seguridad de los datos personales que entrañe un alto
riesgo para los derechos y libertades de las personas físicas; (ii) y que no concurra
uno de los motivos de exención del deber de comunicar que establece el artículo 34.3.

o Respecto a la probabilidad de que se haya producido una violación de
seguridad de alto riesgo para los derechos y libertades de las personas físicas.

Para evitar reiteraciones innecesarias nos remitimos a lo indicado en el
Fundamento de Derecho IV, donde se señalan los motivos por los que cabe
desestimar la alegación quinta del escrito de AlegAi#1, que se refería a esta
cuestión, puesto que CECOTEC niega que exista un alto riesgo en este caso,
señalando que:

“CECOTEC inició las comprobaciones oportunas desde el momento
inicial que se tuvo conocimiento del email del INCIBE y se contactó con
ellos telefónicamente, y aunque inicialmente tuvo dudas acerca de la
certeza de la brecha pero ésta fue finalmente notificada a la Autoridad de
Control conforme fue obteniendo información al respecto.

En este marco, se llevó a cabo internamente una valoración sobre el
“alto riesgo” en base a la información objetiva que disponía al tiempo de
conocer la brecha en base a los factores indicados en Directrices 9/2022
sobre la notificación de violaciones de datos personales en virtud del
RGPD de fecha 28 de marzo de 2023.
-Respecto a la naturaleza, la sensibilidad y el volumen de los datos
personales: Se trataba datos de contacto no completos ni de categoría
especial.
-Respecto al volumen de datos: Acreditados sólo 6 datos de personas
reales.
-Respecto a la facilidad de la identificación de los individuos: Era
compleja habida cuenta que no figuraban los nombres y apellidos de los
interesados, ni hay documentación asociada.
-Respecto al tipo de violación: Afectó a la confidencialidad de los datos
por un tercero no autorizado, pero no a otras esferas como la
disponibilidad e integridad.
- Respecto a la gravedad de las consecuencias para las personas: Se
consideró que no resultaba grave dado que no son datos de categoría
especial, la suplantación de identidad no es automática ni sencilla al no
constar nombre y apellidos de los afectados, ni por otro lado, consta
acreditada.
-Respecto a las características del individuo: No se trataba de sujetos
vulnerables ni de menores de edad.
Tras dicha evaluación interna y acorde al resultado de la herramienta
COMUNICA BRECHA facilitada por la propia AEPD, CECOTEC no

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

166/173

estimó necesario comunicar la brecha.”

Sin embargo, se entiende que la reclamada no ha realizado una adecuada
valoración del riesgo concurrente, toda vez que no ha tenido en cuenta la
totalidad de los factores concurrentes para evaluar la concurrencia de este
riesgo a los que hacen referencia las Directrices W250 del GT29, que no se
limitan a valorar la únicamente la tipología de datos, ni del número de
personas afectadas como señala la reclamada, sino que también establece
que deben valorarse otros factores que no se han tenido en cuenta, como los
factores relacionados con la facilidad para identificar a las personas afectadas
y la gravedad de los daños que se podrían producir en el momento en que
detectó la existencia de la brecha, que afectaba a 6 personas reales.

De haber realizado una correcta valoración que atendiera a todos los factores
de riesgo concurrentes, hubiera concluido en que la brecha entrañaba un
riesgo alto para los derechos y libertades de los afectados, lo que es
especialmente claro en este supuesto, en el que los datos personales
constaban a la venta en un foro de la dark web, quedando expuestos para un
uso fraudulento de terceros.

Por tanto, una vez comprobó el 13-4-23 que el usuario malicioso disponía de
al menos de los datos personales identificativos de estos 6 afectados, debió
determinar que la brecha de confidencialidad de los datos personales era
altamente probable, y que al estar a la venta los datos, concurría un alto
riesgo para los derechos y libertades de estas 6 personas. Y con
independencia de la realidad del ciberataque sobre toda la base de datos,
debió al menos comunicárselo a estas 6 personas sin dilación, y no lo hizo. Y
posteriormente, cuando supo por esta Agencia que el actor malicioso había
entregado una segunda muestra de 1000 registros, que le fue entregada a la
reclamada al solicitar la copia del expediente, debió realizar por sí misma el
cotejo que ha realizado la instructora del procedimiento para analizar la
brecha y comunicar la misma a los 933 afectados. Pero no lo hizo, ni lo ha
hecho siquiera tras serle notificada la propuesta de resolución y la diligencia
de 14 de febrero de 2024 que realizó el mencionado cotejo y comprobación
de datos, en el que se concluía que la brecha había afectado a las 933
personas. Y a fecha de hoy, en la que se reconoce que la brecha afectó a
estas 933 personas, sigue persistiendo en mantener que no existe alto riesgo
para sus derechos y libertades, por lo que no tiene obligación de comunicar
dicha brecha. Lo que supone cometer la infracción del artículo 34 del RGPD,
en grado, sino de dolo, si de negligencia grave, dado que sigue actuando
pese a conocer que actúa en contra del criterio de esta Agencia.

o Tal y como se ha señalado, no concurre tampoco ninguna de las excepciones
del deber de comunicar la brecha a los afectados previstas en el artículo 34.3
del RGPD, tal y como señaló el acuerdo de inicio:

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

167/173

No concurre la excepción del 34.3.a), puesto que tal y como se ha indicado en
los Fundamentos de Derecho anteriores, consta acreditado que la empresa no
había adoptado las medidas de protección apropiadas para evitar la
vulneración de confidencialidad de los datos personales de esta plataforma,
que se hallaban sin cifrar.

Tampoco concurre la excepción del apartado b), puesto que las medidas
implantadas posteriormente, se dirigen a garantizar la trazabilidad del sistema,
y a detectar o evitar nuevas filtraciones o violaciones de seguridad de los datos
personales, pero no son susceptibles de impedir que se materialice el alto
riesgo de los datos personales que ya han sido filtrados, y están a la venta. A lo
que se une el alto riesgo que genera el hecho de que no se ha podido
identificar el vector de ataque por el que se ha logrado acceder a la base de
datos debido a la falta de medidas adecuadas de monitorización y trazabilidad
del sistema.

Y por último, no concurre la excepción del apartado c), puesto que se considera
que notificar la brecha a 6 afectados no sería un esfuerzo desproporcionado. Ni
tampoco sería desproporcionado exigir una comunicación pública dirigida a
todos los afectados del más de millón de registros contenido en la plataforma.

De todo lo expuesto se deduce que, de conformidad con la instrucción practicada, ha
quedado acreditado que la empresa responsable del tratamiento incumplió con el
deber de comunicar la brecha a los afectados, puesto que ha quedado acreditado que
la reclamada debió comunicar la brecha a un total de 6 personas cuando tuvo
constancia de la brecha el 13 de abril de 2023, y ampliar dicha comunicación al total
de 933 personas, una vez recibió copia del expediente el 30 de abril de 2023.

No habiendo cumplido con este deber, procede mantener la imputación de la infracción
del artículo 34 del RGPD, por no haber comunicado la brecha a los 933 afectados que
constan acreditados en el procedimiento, e imponer una sanción mayor que la que fue
inicialmente fijada partiendo de 6 afectados por la brecha, en los términos que serán
expuestos en el Fundamentos de Derecho XVII de esta propuesta.

XVI.

Tipificación de la infracción del artículo 34 del RGPD

Habiéndose confirmado que efectivamente se ha vulnerado la obligación de comunicar
la brecha a los afectados del artículo 34 del RGPD, ello supone la comisión de la
infracción tipificada en el artículo 83.4, apartado a) del RGPD, que bajo la rúbrica
“Condiciones generales para la imposición de multas administrativas” dispone que:

“Las infracciones de las disposiciones siguientes se sancionarán, de acuerdo con
el apartado 2, con multas administrativas de 10 000 000 EUR como máximo o,
tratándose de una empresa, de una cuantía equivalente al 2 % como máximo del
volumen de negocio total anual global del ejercicio financiero anterior, optándose
por la de mayor cuantía:

a) las obligaciones del responsable y del encargado a tenor de los artículos 8, 11,
25 a 39, 42 y 43;”

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

168/173

A este respecto, la LOPDGDD, en su artículo 71 “Infracciones” establece que
“Constituyen infracciones los actos y conductas a las que se refieren los apartados 4,
5 y 6 del artículo 83 del Reglamento (UE) 2016/679, así como las que resulten
contrarias a la presente ley orgánica”.

A efectos del plazo de prescripción de las infracciones, el artículo 74.ñ) de la
LOPDGDD, dispone que:

“Se consideran leves y prescribirán al año las restantes infracciones de carácter
meramente formal de los artículos mencionados en los apartados 4 y 5 del
artículo 83 del Reglamento (UE) 2016/679 y, en particular, las siguientes:

“ñ) El incumplimiento del deber de comunicación al afectado de una violación de
la seguridad de los datos que entrañe un alto riesgo para los derechos y
libertades de los afectados, conforme a lo exigido por el artículo 34 del
Reglamento (UE) 2016/679, salvo que resulte de aplicación lo previsto en el
artículo 73 s) de esta ley orgánica.”
XVIII.

Sanción por la infracción del artículo 34 del RGPD.

De acuerdo con los preceptos transcritos en el fundamento de derecho VIII (artículos
83.1 y 2 del RGPD, y 76 de la LOPDGDD), en este caso, considerando la gravedad de
la infracción constatada, atendiendo especialmente a las consecuencias que su
comisión provoca en los interesados, procede imponer una sanción de multa, que será
individual, efectiva, proporcionada y disuasoria, conforme a lo establecido en el
artículo 83.1 del RGPD. Para garantizar estos principios, se considera, con carácter
previo, la condición de gran empresa, y el volumen de negocio de la parte reclamada.

Una vez practicada la instrucción del procedimiento, a efectos de fijar el importe de la
sanción a imponer en el presente caso por la infracción tipificada en el artículo 34 del
RGPD, tipificada en el artículo 83.4 del RGPD de la que se responsabiliza a la
empresa, se estiman concurrentes los siguientes criterios de graduación de la sanción:

1. Artículo 83.2.a) RGPD. “la naturaleza, gravedad y duración de la infracción,
teniendo en cuenta la naturaleza, alcance o propósito de la operación de
tratamiento de que se trate, así como el número de interesados afectados y el
nivel de los daños y perjuicios que hayan sufrido”.

Respecto a la gravedad de la infracción se tiene en cuenta el número de
afectados a los que no ha sido comunicada la brecha, que son los titulares de
los datos personales cuya filtración ha sido acreditada durante la instrucción
de este expediente, que asciende a un total de 933 personas, en lugar de las 6
que fueron tenidas en cuenta para graduar la sanción inicial fijada en el
acuerdo de inicio.

Se tiene en consideración también la naturaleza de los datos personales
afectados, hay que tener en cuenta que la filtración se refiere a los tipos de
datos que aparecen en la muestra proporcionada por el actor malicioso al

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

169/173

inspector, a los que hace referencia la Diligencia de 13 de febrero de 2025. Y
se considera también el número de factores de riesgo concurrentes que
determinan el alto riesgo para los derechos y libertades de los afectados, y
especialmente, el hecho de que los datos personales no solo han sido
exfiltrados, y se hallan en poder de un usuario malicioso, sino que además
éstos han sido parcialmente difundidos y puestos en venta en la dark web.

Para graduar la sanción se considera así mismo la duración de la infracción,
considerando que la empresa debió haber comunicado la brecha a los
afectados sin dilación, y como máximo, una vez detectó que la muestra del
anuncio contenía los datos de estos 6 afectados. Y posteriormente, una vez
recibió el acuerdo de inicio y la copia del expediente el 30-4-23, debiendo
haber iniciado investigaciones para determinar si concurría esta brecha, como
lo ha hecho esta administración, y comunicarla a los afectados que constaban
en la muestra proporcionada por el actor malicioso al inspector.

Infracción que persiste en el momento actual y continuará hasta que la
comunicación sea remitida a los mismos.

2. Artículo 83.2b) del RGPD: “La intencionalidad o negligencia en la infracción”.

Aunque no se puede considerar que el reclamado actuara con intencionalidad
o dolo, se observa falta grave de diligencia en el cumplimiento de las
obligaciones que le impone la normativa en materia de protección de datos,
puesto que consta que la empresa ha advertido que coinciden 6 registros de la
muestra y aun así, han decidido no realizar la comunicación por realizar una
valoración del riesgo manifiestamente incompleta, y tras recibir el acuerdo de
inicio en el que consta esta medida correctiva, ha decidido no cumplirla. Y a
mayor abundamiento, al recibir la copia del expediente, no ha realizado las
actuaciones necesarias para comprobar y comunicar esta brecha, y al recibir
la propuesta de resolución donde se descartan las alegaciones en base a las
que considera la reclamada que no existe deber de comunicar, sigue
manteniendo las mismas.

Respecto a la posibilidad de sancionar la falta de diligencia, nos remitimos de
nuevo a lo indicado en la Sentencia de la Audiencia Nacional de 17/10/2007.

3. La actividad de la entidad presuntamente infractora se encuentra vinculada
con el tratamiento de datos de carácter personal tanto de clientes como de
terceros.

En la actividad de la entidad imputada es imprescindible el tratamiento de datos
de carácter personal por ser su objeto social la venta de electrodomésticos y
aparatos electrónicos a través de plataformas de gestión de tienda online de
clientes, proveedores y empleados de la empresa investigada, por lo que la
transcendencia de la conducta objeto de la presente reclamación es innegable
(artículo 76.2.b) de la LOPDGDD en relación con el artículo 83.2.k).

El balance de las circunstancias contempladas en el artículo 83.2 del RGPD y el
artículo 76.2 de la LOPDGDD, considerando el volumen de negocio de la empresa

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

170/173

reclamada, con respecto a la infracción cometida al vulnerar lo establecido en el
artículo 34 del RGPD, permite elevar la sanción de multa que fue fijada inicialmente en
el acuerdo de inicio de 40.000 € e imponer una sanción de multa de 100.000 € (CIEN
MIL EUROS).

XVIII.

Adopción de medidas correctoras

Una vez confirmada la comisión de las 4 infracciones imputadas, procede imponer al
responsable la adopción de medidas adecuadas para ajustar su actuación a la
normativa mencionada en este acto, de acuerdo con lo establecido en el citado artículo
58.2 d) del RGPD, según el cual:

“Cada autoridad de control podrá ordenar al responsable o encargado del
tratamiento que las operaciones de tratamiento se ajusten a las disposiciones
del presente Reglamento, cuando proceda, de una determinada manera y
dentro de un plazo especificado (…)”.

La imposición de esta medida es compatible con la sanción consistente en multa
administrativa, según lo dispuesto en el art. 83.2 del RGPD.

En este sentido, se acuerda la imposición de las siguientes medidas correctoras del
artículo 58.2.d) del RGPD:

o Acreditar en el plazo de 1 mes a esta Agencia que la entidad imputada ha
comunicado la brecha de datos personales producida a los afectados cuyos
datos se han visto afectados por el ciberataque, en los términos y condiciones
previstos por el artículo 34 del RGPD.

o Acreditar a esta Agencia en el plazo de 7 meses el cumplimiento de las
siguientes medidas de seguridad en atención al cumplimiento del artículo 32 del
RGPD:

1. Actualización del Informe de Análisis de Riesgos de octubre de 2022,
elaborando un documento que contenga un análisis exhaustivo que
identifique todos los factores de riesgo o amenazas para los derechos y
libertades de la plataforma objeto del ciberataque, y gradúe el nivel de riesgo
individual y global a los efectos de determinar qué medidas y garantías
serían necesarias para reducir el impacto de los riesgos.

2. En caso de que del resultado del nuevo análisis de riesgos resulte necesario
realizar una EIPD del tratamiento, acredite haberla realizado y superado,
asegurándose de que su contenido cumpla con los requisitos exigidos por el
artículo 35 del RGPD.

3. Acreditar documentalmente que ha adoptado todas las medidas
organizativas y técnicas que sean necesarias para garantizar un nivel de
seguridad adecuado a los riesgos que presente el tratamiento de los datos,
de acuerdo con el nuevo análisis de riesgos, y en su caso la EIPD.

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

171/173

Se advierte que no atender la posible orden de adopción de medidas impuestas por
este organismo en la resolución sancionadora podrá ser considerado como una
infracción administrativa conforme a lo dispuesto en el RGPD, tipificada como
infracción en su artículo 83.5 y 83.6, pudiendo motivar tal conducta la apertura de un
ulterior procedimiento administrativo sancionador.

Por lo tanto, de acuerdo con la legislación aplicable y valorados los criterios de
graduación de las sanciones cuya existencia ha quedado acreditada, la Presidencia de
la Agencia Española de Protección de Datos RESUELVE:

PRIMERO: IMPONER a CECOTEC INNOVACIONES, S.L.U., con NIF B97937890,
por la comisión de las 4 infracciones administrativas del RGPD las siguientes
sanciones administrativas de multa:

o Por la infracción del artículo 5.1.f) del RGPD tipificada en el Artículo 83.5 del
RGPD, una multa de 140.000€.
o Por la infracción del artículo 32 del RGPD, tipificada en el Artículo 83.4 del
RGPD, una multa de 750.000€.
o Por la infracción del artículo 33 del RGPD, tipificada en el Artículo 83.4 del
RGPD, una multa de 100.000€.
o Por la infracción del artículo 34 del RGPD, tipificada en el Artículo 83.4 del
RGPD, una multa de 100.000€.

Todo lo cual suma un total de 1.090.000 € (UN MILLÓN NOVENTA MIL EUROS).

SEGUNDO: Que por la Presidencia de la Agencia Española de Protección de Datos se
ordene a CECOTEC INNOVACIONES, S.L.U., con NIF B97937890, que en virtud del
artículo 58.2.d) del RGPD, que acredite haber cumplido las medidas correctoras
previstas en el Fundamento de Derecho XVIII de esta Resolución:

o Acreditar en el plazo de 1 mes a esta Agencia que la entidad imputada ha
comunicado la brecha de datos personales producida a los afectados cuyos
datos se han visto afectados por el ciberataque, en los términos y condiciones
previstos por el artículo 34 del RGPD.

o Acreditar a esta Agencia en el plazo de 7 meses el cumplimiento de las
siguientes medidas de seguridad en atención al cumplimiento del artículo 32 del
RGPD:

1. Actualización del Informe de Análisis de Riesgos de octubre de 2022,
elaborando un documento que contenga un análisis exhaustivo que
identifique todos los factores de riesgo o amenazas para los derechos y
libertades de la plataforma objeto del ciberataque, y gradúe el nivel de riesgo
individual y global a los efectos de determinar qué medidas y garantías
serían necesarias para reducir el impacto de los riesgos.

2. En caso de que del resultado del nuevo análisis de riesgos resulte necesario
realizar una EIPD del tratamiento, acredite haberla realizado y superado,

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

172/173

asegurándose de que su contenido cumpla con los requisitos exigidos por el
artículo 35 del RGPD.

3. Acreditar documentalmente que ha adoptado todas las medidas
organizativas y técnicas que sean necesarias para garantizar un nivel de
seguridad adecuado a los riesgos que presente el tratamiento de los datos,
de acuerdo con el nuevo análisis de riesgos, y en su caso la EIPD.

TERCERO: NOTIFICAR la presente resolución a A.A.A..

CUARTO: COMUNICAR la presente resolución al Defensor del Pueblo, de
conformidad con lo establecido en el artículo 77.5 de la LOPDGDD.

QUINTO: Esta resolución será ejecutiva una vez finalice el plazo para interponer el
recurso potestativo de reposición (un mes a contar desde el día siguiente a la
notificación de esta resolución) sin que el interesado haya hecho uso de esta facultad.
Se advierte al sancionado que deberá hacer efectiva la sanción impuesta una vez que
la presente resolución sea ejecutiva, de conformidad con lo dispuesto en el art. 98.1.b)
de la ley 39/2015, de 1 de octubre, del Procedimiento Administrativo Común de las
Administraciones Públicas (en adelante LPACAP), en el plazo de pago voluntario
establecido en el art. 68 del Reglamento General de Recaudación, aprobado por Real
Decreto 939/2005, de 29 de julio, en relación con el art. 62 de la Ley 58/2003, de 17 de
diciembre, mediante su ingreso, indicando el NIF del sancionado y el número de
procedimiento que figura en el encabezamiento de este documento, en la cuenta
restringida nº IBAN: ES00-0000-0000-0000-0000-0000 (BIC/Código SWIFT:
CAIXESBBXXX), abierta a nombre de la Agencia Española de Protección de Datos en
la entidad bancaria CAIXABANK, S.A.. En caso contrario, se procederá a su
recaudación en período ejecutivo.

Recibida la notificación y una vez ejecutiva, si la fecha de ejecutividad se encuentra
entre los días 1 y 15 de cada mes, ambos inclusive, el plazo para efectuar el pago
voluntario será hasta el día 20 del mes siguiente o inmediato hábil posterior, y si se
encuentra entre los días 16 y último de cada mes, ambos inclusive, el plazo del pago
será hasta el 5 del segundo mes siguiente o inmediato hábil posterior.

De conformidad con lo establecido en el artículo 50 de la LOPDGDD, la presente
Resolución se hará pública una vez haya sido notificada a los interesados.

De conformidad con lo establecido en el artículo 76.4 de la LOPDGDD y dado que el
importe de la sanción impuesta es superior a un millón de euros, será objeto de
publicación en el Boletín Oficial del Estado la información que identifique al infractor, la
infracción cometida y el importe de la sanción.

Contra esta resolución, que pone fin a la vía administrativa conforme al art. 48.6 de la
LOPDGDD, y de acuerdo con lo establecido en el artículo 123 de la LPACAP, los
interesados podrán interponer, potestativamente, recurso de reposición ante la
Presidencia de la Agencia Española de Protección de Datos en el plazo de un mes a
contar desde el día siguiente a la notificación de esta resolución o directamente
recurso contencioso administrativo ante la Sala de lo Contencioso-administrativo de la
Audiencia Nacional, con arreglo a lo dispuesto en el artículo 25 y en el apartado 5 de

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es

173/173

la disposición adicional cuarta de la Ley 29/1998, de 13 de julio, reguladora de la
Jurisdicción Contencioso-administrativa, en el plazo de dos meses a contar desde el
día siguiente a la notificación de este acto, según lo previsto en el artículo 46.1 de la
referida Ley.

Finalmente, se señala que conforme a lo previsto en el art. 90.3 a) de la LPACAP, se
podrá suspender cautelarmente la resolución firme en vía administrativa si el
interesado manifiesta su intención de interponer recurso contencioso-administrativo.
De ser éste el caso, el interesado deberá comunicar formalmente este hecho mediante
escrito dirigido a la Agencia Española de Protección de Datos, presentándolo a través
del Registro Electrónico de la Agencia [https://sedeagpd.gob.es/sede-electronica-
web/], o a través de alguno de los restantes registros previstos en el art. 16.4 de la
citada Ley 39/2015, de 1 de octubre. También deberá trasladar a la Agencia la
documentación que acredite la interposición efectiva del recurso contencioso-
administrativo. Si la Agencia no tuviese conocimiento de la interposición del recurso
contencioso-administrativo en el plazo de dos meses desde el día siguiente a la
notificación de la presente resolución, daría por finalizada la suspensión cautelar.
926-070623

Lorenzo Cotino Hueso
Presidente de la Agencia Española de Protección de Datos

C/ Jorge Juan, 6 www.aepd.es
28001 – Madrid sedeagpd.gob.es