Evaluación de impacto relativa a la protección de datos (art. 35 del RGPD) – Grabación de sesiones de MousePlayer

1. Por qué es necesaria esta evaluación

El art. 35(1) del RGPD exige una evaluación de impacto cuando sea probable que un tipo de tratamiento, en particular si utiliza nuevas tecnologías y teniendo en cuenta su naturaleza, alcance, contexto y fines, entrañe un alto riesgo para los derechos y libertades de las personas físicas. MousePlayer registra el comportamiento de los visitantes de sitios web de forma continua y por defecto: movimientos del puntero, clics, scroll, toques y cambios de pestaña, junto con una captura completa de la página que vio el visitante y cada cambio posterior, además del texto que introduce en los formularios. El material registrado se almacena, se reproduce, se puntúa y se puede compartir. No se trata de un caso marginal del art. 35(1), sino de su núcleo.

Es necesario precisar un aspecto de la clasificación, en lugar de repetirlo sin más. El art. 35(3) enumera tres casos en los que se exige una EIPD en particular, y ninguno de los tres encaja plenamente. La letra (a) abarca la evaluación sistemática y exhaustiva basada en un tratamiento automatizado sobre cuya base se toman decisiones que producen efectos jurídicos o de importancia similar: aquí existe esa evaluación (véase el riesgo R8), pero no se encontró ninguna decisión de ese tipo respecto de un visitante. La letra (b) abarca el tratamiento a gran escala de categorías especiales conforme al art. 9: aquí no está previsto, aunque categorías especiales llegan a la grabación por una vía no intencionada (riesgo R1), y los volúmenes medidos en este sistema no constituyen gran escala. La letra (c) abarca la observación sistemática de una zona de acceso público a gran escala, lo que se refiere a la observación física y no a un sitio web. Citar la letra (b) como fundamento de la grabación de sesiones sería incorrecto, y una cita errónea es lo primero que una autoridad descarta.

La vía correcta es el propio art. 35(1), aplicado mediante los nueve criterios de las directrices del GT29 sobre la EIPD (WP248 rev.01, refrendadas por el CEPD). Por lo general, se considera que dos criterios indican un alto riesgo. Este tratamiento cumple seis o siete.

• Evaluación o puntuación - se cumple. Cada sesión recibe engagement_score (0-255), session_quality e is_bot; en el examen de agosto de 2026 existían 4 043 filas de características y 3 203 relatos de sesiones redactados por una máquina. Desde entonces se han añadido otras puntuaciones y datos derivados (véase R8).
• Toma de decisiones automatizada con efectos jurídicos o similares - no constatada respecto de los visitantes. Sí se constata respecto de los clientes y las direcciones IP (bloqueo automático, is_suspicious), que constituyen otro grupo de interesados.
• Observación sistemática - se cumple en su forma más intensa. La grabación es continua, metódica e invisible para la persona observada una vez que desaparece el banner.
• Datos sensibles o de carácter muy personal - se cumple. Entradas de formularios, el texto completo de la página tal como se mostró a esa persona y un registro minuto a minuto de lo que leyó y de aquello ante lo que dudó.
• Gran escala - no se cumple según las cifras medidas en este sistema de desarrollo (examen de agosto de 2026: 706 sesiones, 329 identificadores de visitante distintos, 7 proyectos, 4 cuentas. Situación a 16/10/2026: 8 648 sesiones humanas con 7 363 identificadores de visitante distintos desde el 21/07/2026, de los cuales 3 515 identificadores distintos corresponden a los últimos 30 días, en 3 de los 75 proyectos creados; además, 186 163 sesiones marcadas como bots de los últimos 14 días, que se eliminan al vencer su plazo; 24 cuentas, 19 de ellas reconocibles como cuentas de prueba). Sí se cumple por la finalidad del diseño, y el diseño no contiene ningún límite superior.
• Cruce o combinación de conjuntos de datos - se cumple. MousePlayer.setUserId() y la vía automática dataLayer 'uid' vinculan el identificador propio del cliente a la grabación; la exportación a BigQuery envía visitor_id, custom_user_id e ip_address al almacén de datos del propio cliente.
• Interesados vulnerables - cabe sostener que se cumple. El visitante no puede ver qué se ha grabado ni verificarlo y, en 92 casos del examen de agosto de 2026, no se le podía vincular en absoluto con sus propios registros (situación a 16/10/2026: ninguna sesión de ese tipo; véase R9).
• Uso innovador - se cumple. La reproducción del DOM completo combinada con relatos de comportamiento generados por una máquina no es una técnica consolidada y bien comprendida.
• Impedir el ejercicio de un derecho o el uso de un servicio - se cumple de dos formas concretas: el bloqueo automático de IP pone fin al acceso posterior, y la carencia de identificación (R9) hace técnicamente imposible atender los arts. 15 y 17 respecto de una parte de los datos almacenados.

El art. 35(4) obliga a cada autoridad de control a publicar una lista de operaciones de tratamiento para las que la EIPD es obligatoria. La autoridad competente en este caso es la UODO polaca. pendiente de completar: qué entradas de la lista vigente de la UODO conforme al art. 35(4) son aplicables a la grabación de sesiones, y la fecha de la versión de la lista que se ha comprobado

2. Funciones: a quién corresponde esta obligación y respecto de qué

MousePlayer ocupa dos posiciones a la vez, y la respuesta a casi todas las preguntas de este documento depende de cuál de ellas se esté considerando. La distinción no es una opción de presentación: está escrita en el código. class/Server.class.php:416 lo declara en el propio código fuente: "REGEL B ... Hier sind wir AUFTRAGSVERARBEITER": aquí somos el encargado del tratamiento.

Datos	Función de MousePlayer	Responsable del tratamiento	Consecuencia
Visitantes de los sitios web de los clientes: grabaciones, contenido de páginas, entradas de formularios, identificadores, puntuaciones derivadas	Encargado del tratamiento (art. 28)	El cliente de MousePlayer que opera el sitio web	La obligación del art. 35 corresponde formalmente al cliente. MousePlayer tiene la obligación de prestar asistencia conforme al art. 28(3)(f).
Clientes propios de MousePlayer: cuentas, facturación, soporte, registros de acceso al portal, pista de auditoría	Responsable del tratamiento (art. 24)	LW IT Solutions Company Lukas Wójcik	MousePlayer debe realizar por derecho propio la evaluación del art. 35 respecto de este tratamiento, aunque esta parte por sí sola no la exigiría.

Esto conduce a un resultado que conviene expresar claramente, porque suele entenderse mal en ambos sentidos. El tratamiento que exige una EIPD es aquel respecto del cual MousePlayer no es el responsable del tratamiento. Un encargado no puede realizar la evaluación del responsable en su lugar, decidir en su nombre si es necesaria ni consultar a la autoridad de control en su lugar conforme al art. 36. Lo que un encargado puede y debe hacer es facilitar al responsable todo lo que necesita: la descripción del apartado (a), los hechos medidos del apartado (c) y una lista sincera del estado de las medidas del apartado (d). Eso es este documento: la evaluación que MousePlayer hace de sus propias operaciones y la base fáctica que el cliente necesita para la suya.

3. Delegado de protección de datos: la comprobación del art. 37

No se ha designado un delegado de protección de datos. El art. 37(1) obliga por igual al "responsable y al encargado del tratamiento", por lo que la cuestión corresponde al propio MousePlayer y no puede trasladarse a los clientes. Los tres supuestos legales:

Art. 37(1)	Comprobación	Resultado según los hechos medidos
(a)	Tratamiento por una autoridad u organismo público	No es aplicable. LW IT Solutions Company es una empresa privada.
(b)	Las actividades principales requieren una observación habitual y sistemática de interesados a gran escala	Actividad principal: sí, sin discusión: la observación es el producto, no una función de apoyo. Habitual y sistemática: sí - continua, metódica, conforme a un sistema establecido de antemano. Gran escala: no, según las cifras medidas (examen de agosto de 2026: 706 sesiones, 329 identificadores, 4 cuentas; situación a 16/10/2026: 3 515 identificadores distintos de visitantes humanos en 30 días; una instancia de desarrollo).
(c)	Las actividades principales consisten en el tratamiento a gran escala de datos de los arts. 9 o 10	No por diseño. No obstante, categorías especiales entran en el contenido almacenado de las páginas por la vía descrita en el riesgo R1. Es algo incidental y no constitutivo, por lo que actualmente no se da el supuesto, aunque pasa a ser defendible en cuanto se incorpora un cliente del sector sanitario, jurídico o financiero.

WP243 (refrendado por el CEPD) evalúa la "gran escala" según el número de interesados, el volumen y la variedad de datos, la duración y la extensión geográfica. Tres de esos cuatro factores ya están aquí en su máximo: la variedad es una reconstrucción completa de la sesión de la persona, la duración es continua y la extensión geográfica abarca las audiencias que tengan los clientes. Solo el número de personas es pequeño. Para no detectar el umbral demasiado tarde, srv/cron_status.php cuenta una vez al día, desde el 19/08/2026, los identificadores distintos de visitantes humanos de los últimos 30 días (excluidos 'unknown' y las sesiones marcadas como bots), compara la cifra con el umbral de 100000 usuarios finales al mes y comunica por correo electrónico tanto su superación como el vencimiento de la revisión anual. Situación a 16/10/2026: 3 515.

De ello se desprenden dos recomendaciones, no afirmaciones sobre lo que exige la ley. Primero, documentar por escrito ahora una evaluación del umbral, con un número declarado de usuarios finales observados a partir del cual la designación se produzca automáticamente y un intervalo fijo de revisión, de modo que conste que la decisión se ha tomado y no simplemente que aún no se ha tomado. Segundo, tener en cuenta que el art. 37(4) permite que el Derecho de los Estados miembros exija la designación en otros casos. pendiente de completar: confirmación jurídica de si el Derecho polaco, conforme al art. 37(4), impone una obligación de designación más allá del art. 37(1). El umbral y el intervalo de revisión están decididos: más de 100000 usuarios finales observados al mes, como mínimo una vez al año

El art. 35(2) exige que el responsable del tratamiento recabe el asesoramiento del delegado de protección de datos, si ha sido designado, al realizar una EIPD. Al no haber delegado designado, este paso no es aplicable y su omisión no constituye un defecto. Aprobado por Lukas Wójcik, propietario, el 17/08/2026. No se obtuvo asesoramiento externo en protección de datos. Se revisa anualmente y cada vez que cambia el tratamiento; las versiones fechadas se conservan en el control de versiones bajo ai/cms/.

4. Método, fuentes y límites de este borrador

Cada afirmación fáctica de este documento se ha contrastado con el sistema en funcionamiento —código fuente, esquema de la base de datos, recuentos de filas, lista de procesos, valores de configuración y archivos de registro—, en lugar de tomarse de descripciones del producto o de lo que se supone que hace el software. Cuando una medición contradice una intención, se informa de la medición. Cuando no se pudo establecer un hecho, se incluye un marcador en su lugar; no se ha estimado ninguna cifra ni inventado ningún plazo de conservación.

• El sistema medido es la instancia de desarrollo (APP_ENV=dev). Por ello, varias cifras son efectos de los datos de prueba y se identifican como tales, sobre todo los registros de consentimiento: 671 de 706 sesiones llevan consent_source='testdata' con una marca de tiempo NULL, escrita por ai/devdata/001_altsitzungen_markieren.sql (examen de agosto de 2026; situación a 16/10/2026: 566 de 8 648 sesiones humanas).
• Algunas mediciones se realizaron con unos minutos de diferencia y, por ello, difieren ligeramente (705 frente a 706 sesiones; 36 409 filas de registro frente a 36 542 direcciones comprobadas). Se indican ambas cifras tal como se midieron, sin conciliarlas a posteriori.
• No se disponía de acceso con privilegios de root. Por ello, no se pudieron verificar la configuración de las jaulas de fail2ban, los crontabs de root y www-data ni la llegada de la copia de seguridad externa a su destino. Cada punto figura como no verificado, en lugar de darse por supuesto. Añadido desde entonces: el operador ha efectuado entretanto el cambio de las copias de seguridad con permisos de root, y la llegada de la copia externa a su destino está acreditada desde el 11/08/2026, porque la propia ejecución diaria la registra y la comprueba; consta para los días 11/08/2026 y 12/08/2026 (véase R5). Nueva comprobación el 16/10/2026: fail2ban ejecuta nueve jaulas, entre ellas mp-nginx-429 para las direcciones que activan reiteradamente el límite de frecuencia de nginx. Las ejecuciones programadas de MousePlayer figuran en /etc/cron.d/mouseplayer y se ejecutan mediante srv/cron_run.sh con la cuenta específica mouseplayer-dev; los servicios de los trabajadores también se ejecutan con esa cuenta. La copia diaria se sigue iniciando desde el cron de root y la ejecución diaria de eliminación sigue realizándose dentro del proceso db_worker.
• No se buscaron endpoints de salida en los directorios de proveedores (Stripe SDK, Google Cloud SDK, PHPMailer, Symfony). Se examinó exhaustivamente el código propio para localizar curl_init, curl_exec, file_get_contents sobre http, fsockopen y stream_context_create, y todos los literales https.
• Una cifra de esta evaluación —92 sesiones con visitor_id 'unknown'— se adoptó como medición establecida en el examen de agosto de 2026 porque entonces no pudo volver a medirse. Nueva medición el 16/10/2026: ya no hay ninguna sesión con visitor_id 'unknown'. El código todavía puede escribir ese valor al crear una sesión (srv/db_worker.php); por tanto, R9 sigue siendo posible.

5. (a) Descripción sistemática de las operaciones de tratamiento y sus fines

5.1 Cómo funciona la grabación

El cliente integra un archivo JavaScript estático (www/mp.js) en su sitio web. Antes de que se grabe nada, deben abrirse dos controles. Primero se ejecuta una comprobación de bots que interrumpe el proceso para los navegadores automatizados. Detrás está la máquina de estados de consentimiento mpEinw, que solo permite crear el sistema de seguimiento ante una señal positiva de consentimiento: procedente de una llamada a la API del propio cliente, de Google Consent Mode, de una CMP compatible o de una cadena TCF. Cualquier otro resultado, incluida la ausencia total de señal, una CMP que no se carga, un error de script o un origen desconocido, da lugar a que no se grabe. El principio rector figura en las propias notas de trabajo del proyecto y se aplica en todo el código: en caso de duda, no grabar.

Una vez autorizado, el script abre un WebSocket cifrado (/mp_wss/) hacia el servidor de grabación. El cifrado TLS termina en nginx; el propio servidor WebSocket (srv/server.php) escucha únicamente en la dirección de bucle local 127.0.0.1:8081 y recibe desde allí la conexión sin cifrar dentro de la misma máquina. El servidor aplica el control por segunda vez, independientemente del navegador: class/Server.class.php:977-1004 solo admite GRANTED o GRANTED_LATE, o una exención regional explícita, y cierra la conexión con el código 1008 ante una retirada, un país desconocido o cualquier situación dudosa. Antes se aplica una lista de exclusión de rutas que compara únicamente la ruta, no la URL completa. Si el WebSocket no puede establecerse tres veces seguidas (porque un proxy o cortafuegos bloquea el establecimiento de la conexión), el script envía en su lugar los mismos mensajes mediante HTTPS POST a /mp_wst; ese endpoint no decide nada y los entrega al mismo proceso servidor, donde pasan por el mismo control (www/api/ws_tunnel.php, class/HttpTunnel.class.php). Si una captura de página supera 1 MB, el script la sube mediante HTTPS POST a /mp_dom (www/api/dom_upload.php); ese endpoint comprueba un token de acceso de duración limitada firmado por el servidor, mantiene la captura en Redis durante un máximo de 120 segundos y no toma ninguna otra decisión: la recupera la misma conexión que ya ha superado los controles. Además, /mp_wsfail cuenta las conexiones WebSocket fallidas por proyecto, sin identificador de visitante; allí la dirección IP solo se utiliza como hash para eliminar duplicados y caduca al cabo de una hora. Los eventos pasan por una cola en Redis y un trabajador de larga ejecución (srv/db_worker.php) los escribe en MariaDB.

Lo que se almacena no es un vídeo. Es la propia página: una copia serializada del DOM en el momento de la vista de página, más cada cambio posterior, que se reproduce después en un iframe con las posiciones registradas del puntero dibujadas encima. Esta distinción es relevante para la evaluación del riesgo, porque significa que el material almacenado contiene todo lo que contenía la página, incluido texto que el visitante nunca escribió y que nunca consideró "datos".

5.2 Registro de operaciones de tratamiento

Finalidad	Función	Tablas principales	Supresión (situación a 23/09/2026)
Grabación del comportamiento: movimientos, clics, scroll, toques, cambios de pestaña	Encargado del tratamiento	mouse_events (225 892 filas, 322,6 MB), session_pageviews, visitor_sessions	Purga diaria según el plan, supervisada (véase R7)
Contenido de páginas: captura del DOM y cambios en vivo, para reproducir la página tal como se vio	Encargado del tratamiento	session_pageviews.payload_blob (1 848 filas, 162,9 MB), mouse_events.target_selector para cambios (66 153 filas)	La misma purga
Entradas de formularios, carácter por carácter, enmascaradas según el nivel configurado	Encargado del tratamiento	mouse_events.target_selector para eventos de entrada (599 filas)	La misma purga; para las 173 filas heredadas, véase R2
Reconocimiento del mismo visitante entre sesiones y vistas de página	Encargado del tratamiento	visitor_sessions.visitor_id / custom_user_id, visitor_nicknames (329 filas)	visitor_nicknames: con la última sesión del visitante
Determinación de la red y de la ubicación aproximada	Encargado del tratamiento	visitor_sessions.ip_address, country, city, asn_number, asn_org; ip_lifetime_stats (446 filas)	ip_lifetime_stats: 365 días
Prueba del consentimiento y de sus cambios (art. 7(1))	Encargado del tratamiento; se conserva para la carga de la prueba del cliente	consent_events (120 filas), visitor_sessions.consent_*	730 días desde the withdrawal; se conserva deliberadamente hasta entonces, porque acredita que se retiró el consentimiento
Eventos personalizados, señales de frustración, errores de JavaScript	Encargado del tratamiento	session_custom_events (823), session_custom_event_params (1 264)	La misma purga
Características derivadas y relatos de sesiones redactados por una máquina	Encargado del tratamiento	ai_session_features (4 043), ai_timelines (3 203 filas, 5,5 MB)	Con la sesión, en la misma cadena de eliminación
Gestión de las cuentas de los propios clientes de MousePlayer	Responsable del tratamiento	users (4), user_ip_history (5), workspace_users, workspace_invites	Con la cuenta; las cuentas inactivas, tras 24 meses y una advertencia entregada
Registro de accesos, seguridad y cambios del portal	Responsable del tratamiento	mouseplayer_logs (36 409), security_access_logs (1 354), audit_logs (666), banned_ips	60 días / 72 horas / 60 días / al caducar
Solicitudes de soporte	Responsable del tratamiento	support_requests	730 días
Colaboración sobre una reproducción: comentarios y enlaces para compartir	Mixta: responsable del tratamiento respecto del autor y encargado del tratamiento respecto del contenido grabado	session_comments (12), session_shares (9)	Los comentarios, con la sesión; los enlaces para compartir, 90 días después de su caducidad
Aceptación por el cliente de las reglas regionales de grabación	Responsable del tratamiento	consent_region_acceptances (0 filas)	730 días

5.3 Base jurídica

Para todo lo que forma parte de la vía de grabación, la base es el consentimiento, y el razonamiento está documentado en la migración que introdujo la arquitectura de consentimiento (ai/migrations/018_consent.sql): la grabación es observación del comportamiento en el sentido del considerando 24 y acceso al equipo terminal conforme a la transposición polaca de las normas sobre privacidad electrónica; exige consentimiento y el interés legítimo no la ampara. Los 7 proyectos están configurados con consent_mode='required'. El interruptor de desactivación site_settings.consent_gate_active está activado. Ese análisis es correcto y está documentado con una precisión inusual; no se atenúa en ningún punto del código.

Para cuatro operaciones, el código no indica ninguna base: la gestión de las propias cuentas de MousePlayer, los registros de acceso y seguridad del portal, las solicitudes de soporte y los comentarios de reproducciones. Son las operaciones en las que actúa como responsable del tratamiento. El interés legítimo (art. 6(1)(f)) y la ejecución de un contrato (art. 6(1)(b)) son las bases candidatas evidentes, pero una candidata no equivale a una determinación, y el art. 6(1)(f) exige una ponderación documentada. Respondido el 17/08/2026: datos de cuenta y facturación, art. 6(1)(b); para la conservación de facturas, (c) (cinco años desde el final del año natural en el que venció el plazo de pago del impuesto). Registros de acceso, seguridad y cambios, así como reCAPTCHA y los registros del servidor: (f), con la finalidad de defenderse frente a abusos y de responsabilidad proactiva; las ponderaciones figuran en el registro, apartados B.2 y B.5. La demostración de la página de inicio: consentimiento, (a). Solicitudes de soporte: (b) cuando quien pregunta es un Cliente y la solicitud se refiere al contrato; en los demás casos, (f) (registro, B.3). MousePlayer trata los comentarios de reproducciones y los enlaces para compartir por instrucciones del Cliente (registro, A.9).

5.4 Destinatarios y transferencias a terceros países

Dentro de la vía de grabación no se encontró ninguna llamada de salida a terceros. La geolocalización se resuelve con archivos locales de bases de datos de MaxMind y no con un servicio web: una decisión deliberada de diseño documentada en el código para no contactar con terceros antes de que exista consentimiento. Las fuentes, banderas y scripts se sirven localmente. Es un resultado realmente bueno y debería indicarse como tal.

Destinatario	Qué se transfiere	Estado actual
El cliente	Todo lo grabado, mediante el panel y los tres endpoints del reproductor	Activo: esta es la finalidad
Cualquier persona que tenga un enlace para compartir, sin iniciar sesión	La reproducción completa de una sesión	Activo; situación a 16/10/2026: 5 enlaces para compartir creados; cada acceso se registra con la hora, la dirección IP y el identificador del navegador (share_views)
Google Cloud Storage, Varsovia (hasta el 05/09/2026: Google Drive, Estados Unidos)	Una copia diaria completa de cada base de datos y de todo el árbol web. Hasta el 11/08/2026 sin cifrar. Desde el 11/08/2026 cifrada en nuestro propio servidor antes de transferirse	Activo diariamente. La transferencia en claro terminó el 11/08/2026; las copias heredadas sin cifrar en Google se eliminaron el 12/08/2026. Desde el 05/09/2026, cuenta de empresa, región europe-central2 (Varsovia), amparada por el Google Cloud Data Processing Addendum; las copias de la antigua cuenta de Drive se eliminaron el 06/09/2026: véase el riesgo R5
Stripe (Estados Unidos / Irlanda)	Correo electrónico, nombre, dirección de facturación y datos de pago del cliente; ningún dato de visitantes	Solo claves de prueba; claves de producción vacías
Namecheap Private Email (envío de correo electrónico mediante SMTP)	Dirección del destinatario, asunto y contenido de correos salientes dirigidos a clientes y al operador, como confirmación de cuenta, restablecimiento de contraseña, invitaciones, avisos de inicio de sesión desde nuevos dispositivos, advertencia previa a la eliminación de cuentas inactivas, avisos sobre cambios en documentos contractuales, informe semanal, respuestas de soporte, avisos sobre marcas y anomalías, y alertas del sistema	Activo desde el 23/09/2026, remitente office@mouseplayer.com; figura entre los subencargados
Telegram (fuera de la UE)	Hasta el 11/08/2026: solicitudes de soporte completas, incluidas la dirección IP sin truncar y el texto íntegro del mensaje. Desde el 11/08/2026: solo una frase fija —"MousePlayer: es liegt eine neue Supportanfrage vor."—, sin variables, número de caso ni enlace; ya no sale ningún dato personal del sistema por este canal	El canal sigue activo (tokens configurados en .env), pero desde el 11/08/2026 no es destinatario de datos personales y, por tanto, no es encargado del tratamiento
Google reCAPTCHA (Estados Unidos)	Páginas de inicio de sesión, registro, soporte y facturación	Desactivado en este sistema (APP_ENV=dev); activo en producción
Google BigQuery (proyecto propio del cliente)	session_id, visitor_id, custom_user_id, ip_address, country, referrer, agente de usuario, tamaño de pantalla, marcas de tiempo, tipo de dispositivo	Inactivo: desactivado en los 7 proyectos, y el proceso no está en ejecución
URL de webhook definida por el cliente (destino sin restricciones)	Datos del evento más un enlace directo al reproductor de la sesión	Inactivo: desactivado en los 7 proyectos; proceso de envío en ejecución

5.5 Conservación: lo medido frente a lo previsto

Existe una rutina de eliminación automática y se ejecuta. Está dentro del proceso trabajador que funciona permanentemente (srv/db_worker.php) y se ejecuta al iniciar el proceso y, después, una vez por día natural; el mismo proceso aplica cada hora los plazos de las sesiones marcadas como bots. La ejecución de eliminación no tiene una entrada cron propia. Sin embargo, su ausencia ya no pasa inadvertida: el trabajador registra su resultado y srv/cron_status.php —otro proceso— lo evalúa, comunica por correo electrónico si la última ejecución fue hace más de 48 horas y deja constancia del fallo como entrada en los Registros urgentes del área de administración. Las demás ejecuciones programadas figuran en /etc/cron.d/mouseplayer; el mismo proceso de estado también comunica sus fallos y las pausas excesivas (situación a 16/10/2026).

En el examen de agosto de 2026, la ejecución aún no había eliminado nada: todos los proyectos pertenecían a un propietario del plan Enterprise con 365 días de conservación, y la sesión más antigua tenía 20 días. A 16/10/2026, la eliminación está demostrada: se aplican los plazos de registros y datos derivados (la entrada más antigua de audit_logs se sitúa en el plazo de 60 días), las sesiones marcadas como bots se eliminan tras 14 días y sus grabaciones se vacían tras su propio plazo (plazo en días: 1). El plazo del plan para sesiones humanas aún no ha alcanzado a ninguna sesión, porque los dos proyectos con tráfico real de visitantes siguen perteneciendo a un propietario del plan Enterprise con 365 días y sus sesiones más antiguas datan del 21/07/2026.

6. (b) Evaluación de la necesidad y la proporcionalidad

La necesidad y la proporcionalidad se evalúan con respecto a la finalidad declarada: permitir al operador de un sitio web comprender cómo utilizan su sitio los visitantes, dónde encuentran dificultades y por qué lo abandonan. Esa finalidad es legítima y la técnica general es apta para alcanzarla. La pregunta del art. 35(7)(b) es más concreta y más difícil: ¿es este tratamiento, con este nivel de detalle, necesario para esa finalidad, y es la injerencia proporcionada al beneficio?

Componente	¿Necesario para la finalidad?	¿Proporcionado tal como está implementado?
Movimientos del puntero, clics, scroll, toques	Sí. Es la señal a la que se refiere la finalidad.	Sí.
Estructura y disposición de la página visitada	Sí. Las coordenadas carecen de sentido sin la disposición a la que se refieren.	En principio, sí.
Todo el contenido textual de la página, literalmente	No, en general. Para comprender dónde encontró dificultades un visitante hacen falta la estructura y las etiquetas, no el contenido personal que se muestra en ellas.	No, tal como está implementado actualmente. El enmascaramiento debe solicitarse para cada elemento; por defecto se almacena todo. Véase R1.
Entradas de formularios	Discutible. Saber que se abandonó un campo es valioso; saber qué se escribió en él rara vez es necesario.	En parte. El mínimo de enmascaramiento es sólido y todos los proyectos utilizan el nivel más estricto, pero el diseño sigue permitiendo niveles más débiles y la descripción de esa configuración está invertida (el nivel 0 es el más estricto; la indicación del panel dice lo contrario).
Estado de casillas de verificación y botones de opción	Discutible.	No. Nunca se enmascaran, en ningún nivel, y una casilla puede contener una declaración de salud, una afiliación política o un consentimiento para una finalidad sensible.
Reconocimiento entre sesiones	Sí para analizar visitantes recurrentes; no para la finalidad principal.	Con condiciones. El reconocimiento seudónimo es proporcionado; la proporcionalidad termina en el identificador que proporciona el cliente. Véase R6.
Dirección IP	Sí para atribuir una ubicación aproximada (país; la ciudad, solo a partir de la dirección ya truncada) y para defenderse frente a abusos.	Sí, de cara al futuro: la dirección se trunca inmediatamente después de leerse, antes de que la vea ningún componente que la utilice. Los datos heredados de la vía de grabación se depuraron el 17/08/2026; véase R3.
Puntuaciones y relatos de sesiones	No. Son funciones prácticas para el proceso de revisión del cliente.	Cuestionable y la parte menos examinada del sistema: el código no indica ninguna base jurídica para ella.
Copia externa completa (en un proveedor de un tercer país hasta el 05/09/2026)	Una copia de seguridad externa, sí: contribuye a la disponibilidad (art. 32(1)(c)). Su alcance supera este servicio: contiene todas las bases de datos de la máquina.	Desde el 05/09/2026, sí, con una reserva sobre el alcance. La copia se cifra antes de transferirse y se conserva en una región europea al amparo de un acuerdo conforme al art. 28. Hasta el 05/09/2026, no: no existía un contrato acreditado y, hasta el 11/08/2026, no estaba cifrada. Véase R5.

En cuanto a la minimización de datos (art. 5(1)(c)), el sistema presenta dos caras opuestas. En varios puntos se observa una minimización deliberada, bien justificada en el código: se clasifican los nombres de los campos en lugar de transmitirlos, porque en una tienda un nombre de campo sin procesar suele ser suficientemente descriptivo para identificar a la persona; la cadena TCF solo se almacena como hash SHA-256; la carga útil de la reproducción se excluye deliberadamente de la API pública. Frente a ello está la decisión central de diseño de almacenar por defecto la página completa de forma literal, que es lo contrario de la minimización y no se compensa con nada de lo anterior.

En cuanto a la limitación del plazo de conservación (art. 5(1)(e)), la evaluación fue inequívoca y desfavorable hasta el 17/08/2026. Trece tablas con datos personales no tenían ningún plazo de supresión, incluidas las dos que contienen el material más legible: ai_timelines, que presenta cada sesión en forma de prosa legible, y visitor_nicknames. La rutina que existía nunca se había ejecutado sobre datos reales. Un concepto de conservación que nunca ha eliminado un registro es un plan, no una garantía. Desde el 17/08/2026 las trece tablas tienen un plazo, la purga elimina datos de forma demostrable y se comunica su ausencia (véase R7).

7. (c) Evaluación de los riesgos para los derechos y libertades de los interesados

Los riesgos se evalúan para el interesado, no para la empresa. La probabilidad se califica como Remota, Posible, Probable o Materializada; esta última significa que el hecho no es una previsión, sino un estado actual y medido de los datos. La gravedad se califica como Limitada, Significativa, Grave o Muy grave, según lo que puede perder la persona afectada: no una situación embarazosa, sino la exposición de características de salud, financieras u otras protegidas, la pérdida de control sobre su identificación y la imposibilidad de ejercer un derecho.

ID	Riesgo	Probabilidad	Gravedad	Nivel
R1	Categorías especiales de datos dentro del contenido grabado de las páginas	Probable	Muy grave	Muy alto
R2	Entradas de formularios sin enmascarar en datos heredados (173 filas): calificación del examen; las filas se eliminaron el 17/08/2026 y está pendiente una nueva calificación por el responsable del tratamiento	Materializada	Significativa	Alto
R3	Direcciones IP sin truncar en datos heredados y registros del portal: calificación del examen; los datos heredados se truncaron el 17/08/2026 y desde entonces los registros del portal tienen plazos; está pendiente una nueva calificación	Materializada	Significativa	Alto
R4	Los enlaces para compartir exponen una reproducción completa sin iniciar sesión	Posible	Grave	Alto
R5	Copia externa diaria completa: sin cifrar hasta el 11/08/2026, cifrada en nuestro propio servidor antes de transferirse desde el 11/08/2026; los datos heredados sin cifrar se eliminaron del proveedor el 12/08/2026. Desde el 05/09/2026, la copia se conserva en un bucket de Google Cloud Storage en la región europe-central2 (Varsovia), con una cuenta de empresa, amparada por el Google Cloud Data Processing Addendum; las copias de la antigua cuenta de Drive se eliminaron el 06/09/2026. El alcance no ha cambiado. Si se pierden ambos archivos de claves, la copia de seguridad es irrecuperable; se conservan copias impresas en una caja fuerte	Remota (nueva calificación del 17/09/2026). Anteriormente: transferencia en claro hasta el 11/08/2026 y transferencia sin una base jurídica acreditada hasta el 05/09/2026; ambas se materializaron y han cesado	Muy grave	Medio - nueva calificación del 17/09/2026; muy alto hasta el 05/09/2026. La condición de la evaluación (retirar los scripts antiguos) se cumplió el 16/10/2026; la nueva calificación de R5 corresponde al responsable del tratamiento
R6	Reconocimiento entre sesiones y combinación con los registros propios del cliente	Probable	Grave	Alto
R7	Sin plazo de supresión para trece tablas; subsanado desde el 17/08/2026, la purga se ejecuta a diario y está supervisada	Remota (nueva calificación del 23/09/2026). Hasta el 17/08/2026: materializada	Grave	Bajo: nueva calificación del 23/09/2026; alto hasta el 17/08/2026
R8	Puntuación y clasificación automatizadas de cada sesión	Probable	Significativa	Medio
R9	92 sesiones inaccesibles mediante cualquier identificador; no existe una vía de la persona al registro: calificación del examen; a 16/10/2026 no hay ninguna sesión de ese tipo; consulta de autoservicio desde el 17/08/2026; está pendiente una nueva calificación	Materializada	Significativa	Alto
R10	Sin cifrado en reposo ni TLS hacia la base de datos; Redis sin protección de acceso (hasta el 16/08/2026; acceso restringido desde entonces; la base de datos y Redis también son accesibles desde la red local; está pendiente una nueva calificación)	Posible	Muy grave	Medio-alto
R11	No se registra quién vio cada grabación	Materializada	Significativa	Medio-alto
R12	Calidad de las pruebas de consentimiento; adaptadores de CMP sin probar	Materializada (datos de desarrollo)	Grave	Medio
R13	Solicitudes de soporte a Telegram con la IP sin truncar, hasta el 11/08/2026; desde el 11/08/2026 solo se envía un aviso de texto fijo sin ninguna variable. Persiste el almacenamiento local de la solicitud con correo electrónico e IP en support_requests; desde el 17/08/2026, con un plazo de 730 días (véase R7)	Transferencia: subsanada el 11/08/2026. Almacenamiento local: materializado	Significativa: hasta el 11/08/2026 para la transferencia y, desde entonces, solo para el almacenamiento local	Subsanado el 11/08/2026 respecto de la transferencia; el almacenamiento local restante se trata en R7 (calificado allí como bajo desde el 23/09/2026)
R14	Salida hacia destinatarios elegidos por el propio responsable del tratamiento: la solicitud de supresión no les llega	Posible (depende de que el responsable del tratamiento active un puente; en los datos actuales no hay ninguno activado)	Sustancial	Medio

R1 - Categorías especiales de datos dentro del contenido grabado de las páginas

Este es el riesgo más grave del sistema y el menos visible, porque nada en él parece un defecto. El enmascaramiento de la captura de página actúa solo dentro de las regiones marcadas (www/mp.js:3934-3970): dentro de un elemento con data-mp-mask o la clase .mp-masked se sustituye cada carácter que no sea un espacio en blanco, y los atributos que no figuren en una lista de conservación se establecen en [FILTERED]. Todo lo demás se almacena literalmente. Por tanto, el enmascaramiento es una anotación de inclusión voluntaria que el cliente debe aplicar, elemento por elemento, a una página que quizá no controle por completo.

La consecuencia es que la protección cubre lo que el visitante escribe y no lo que la página le devuelve. Una página de confirmación de una consulta médica que muestra una cita con una especialidad determinada; una cesta de farmacia; un presupuesto de seguro que enumera enfermedades preexistentes; un extracto bancario; un resumen de admisión para asistencia jurídica: todo ello es contenido que muestra la página, fuera de cualquier campo de entrada, y todo llega a payload_blob sin alteraciones. No es hipotético: hay 1 848 filas con contenido, con un promedio de 90,3 kB, y una muestra confirma que el valor almacenado comienza con el documento <html> completo. Lo mismo se aplica a cada cambio posterior de la página, serializado como fragmentos HTML en mouse_events.target_selector, en 66 153 filas de cambios.

Probabilidad: Probable. El mecanismo de protección exige una actuación deliberada de alguien distinto de la persona expuesta al riesgo, almacena todo por defecto y no dispone de detección, advertencia ni informe que indique al cliente que se está capturando contenido personal sin enmascarar. Nada en el sistema examina muestras de la carga útil almacenada para buscar patrones que lo indiquen. La probabilidad de que al menos una página de un cliente muestre datos de categorías especiales se aproxima a uno durante cualquier período significativo de funcionamiento.

Gravedad: Muy grave. Los datos del art. 9(1) gozan de la máxima protección y aquí no se dispone de ninguna de las excepciones del art. 9(2). El consentimiento del visitante para la grabación de sesiones no es un consentimiento explícito para el tratamiento de datos de salud, ni podría serlo: ni el visitante, ni el cliente, ni MousePlayer saben en ese momento que se están capturando esos datos. El material se almacena literalmente, puede reproducirse íntegramente, puede exportarse, se incluye en la copia externa diaria (R5) y puede entregarse a un tercero no identificado mediante un enlace para compartir (R4).

R2 - Entradas de formularios sin enmascarar en datos heredados

173 filas de mouse_events contienen valores de entrada de formularios en claro. Se localizaron buscando un patrón en la estructura almacenada ('"v":"' seguido de un carácter distinto del de enmascaramiento), corresponden al período del 21/07/2026 al 27/07/2026 e incluyen entradas como el nombre completo de una persona. Las filas escritas el 10/08/2026 están enmascaradas, por lo que el comportamiento actual ya es correcto: los 7 proyectos utilizan smart_masking=0, que, pese a su descripción, es la configuración más estricta y sustituye cada carácter de cada campo, y una protección mínima incondicional sustituye las contraseñas y los datos de pago en cualquier configuración.

Probabilidad: Materializada. No es una predicción. Las filas existen ahora y, como mouse_events solo se vacía mediante la purga del plan —que no elimina nada antes de que un registro tenga 365 días y nunca se ha ejecutado—, permanecerán al menos hasta julio de 2027 salvo que se eliminen manualmente. La probabilidad de repetición futura es baja.

Gravedad: Significativa. Las muestras conocidas son inocuas, pero no se ha clasificado el contenido de las filas restantes, y las categorías de campos que reconoce el sistema incluyen correo electrónico, teléfono, pago, dirección y nombre. No se ha determinado si la protección mínima incondicional de contraseñas y pagos ya existía durante ese período. Completado el 17/08/2026: las filas se eliminaron sin revisarlas (decisión del responsable del tratamiento). Según la medición, eran 174 filas de 18 sesiones de un solo proyecto, del 21/07/2026 al 06/08/2026; después de la ejecución quedan 0. La brecha en sí ya se había cerrado: desde el 07/08/2026 ningún valor contiene texto en claro. Casi se produjo un segundo error en la medición: el carácter de enmascaramiento es el asterisco, no la viñeta: buscar el patrón de la viñeta encontró 862 filas, la más reciente de hoy, por lo que parecía una filtración en curso. Eliminar esa cantidad habría suprimido también 688 filas correctamente enmascaradas.

R3 - Direcciones IP sin truncar en datos heredados y registros del portal

El truncamiento de IP en la vía de grabación está implementado correctamente y en el lugar adecuado: class/Server.class.php:432-435 sustituye el último octeto IPv4 o el último grupo IPv6 inmediatamente después de leer la dirección, antes de que exista ningún componente que utilice el valor. Se ha verificado su eficacia para datos nuevos: todas las sesiones grabadas desde el 07/08/2026 tienen la dirección truncada. No es retroactivo y no existe una rutina de actualización de datos anteriores; en su lugar, los datos heredados se depuraron una sola vez, manualmente, el 17/08/2026: véase la nota de estado bajo la tabla.

Tabla	Direcciones sin truncar (estado en la evaluación, antes del 17/08/2026)	Plazo de supresión
visitor_sessions	236 de 705, fechadas entre el 21/07/2026 y el 07/08/2026, direcciones públicas completas	Purga del plan: nunca ejecutada
ip_lifetime_stats	291 de 446	Ninguno en ninguna parte
mouseplayer_logs	Ninguna de las 36 542 direcciones comprobadas estaba truncada	60 días
audit_logs	Las 666 filas	Ninguno
user_ip_history	Las 5 filas	Ninguno
security_access_logs	1 004 de 1 354	72 horas
support_requests	Todas, y reenviadas a su vez: véase R13	Ninguno
Registro de acceso de Apache	Todas	14 rotaciones diarias

Probabilidad: Materializada. Gravedad: Significativa. Una dirección IP por sí sola supone una exposición limitada. En visitor_sessions no está sola: figura en la misma fila que la grabación, de modo que vincula una identidad de red y, a través de ella, a una persona con una reproducción completa de su comportamiento, incluido todo lo capturado por R1. Los registros del portal son menos críticos, pero mucho más numerosos, y corresponden al tratamiento en el que MousePlayer actúa como responsable y responde directamente de esa elección.

Completado el 17/08/2026: las direcciones heredadas de audit_logs (681) y user_ip_history (7) se truncaron retroactivamente, de la misma forma en que ya las escribe el grabador; quedan 0. Los plazos futuros están en vigor desde ese mismo día. (decisión del responsable del tratamiento, 17/08/2026)

Situación a 17/08/2026. Los datos heredados de la vía de grabación están resueltos: según la medición, 267 de 267 direcciones de ip_lifetime_stats se truncaron, y 881 de 901 de visitor_sessions; las 20 restantes contienen 0.0.0.0 y proceden de datos de prueba del análisis de formularios, por lo que no son direcciones de visitantes. En los registros del portal se conserva la dirección completa deliberadamente y, desde el 17/08/2026, con un plazo declarado: mouseplayer_logs 60 días, security_access_logs 72 horas, audit_logs 60 días, user_ip_history 90 días desde la última vez que se observó una dirección (desde el 24/09/2026), support_requests 730 días. La necesidad de la dirección completa para las solicitudes de soporte se explica en el registro del art. 30, apartado B.3.

R4 - Los enlaces para compartir exponen una reproducción completa sin iniciar sesión

Una regla de reescritura dirige /s/<40 caracteres hexadecimales> directamente al reproductor. El token constituye toda la barrera, y el diseño lo reconoce de forma transparente: el token son 20 bytes de random_bytes (160 bits, imposibles de adivinar), los identificadores del canal y de la sesión proceden exclusivamente del token y no de la solicitud, y el resto de la cadena de consulta se sustituye en lugar de ignorarse; el rol permanece en NULL, por lo que la eliminación y la creación de nuevos enlaces para compartir son imposibles del lado del servidor; los tres endpoints del reproductor se limitan a la sesión del token; y los tokens inventados, caducados y revocados producen una respuesta idéntica, de modo que los sondeos no revelan nada. La duración por defecto es de 7 días, con un mínimo de 1 y un máximo de 90; existe revocación. Es un mecanismo construido con cuidado.

La exposición residual es humana, no criptográfica, y dos detalles de implementación la amplían. Primero, la página que muestra la grabación mediante un enlace para compartir (player.php en modo compartido) sí lleva las cabeceras Referrer-Policy: no-referrer y Cache-Control: no-store, pero no una cabecera X-Robots-Tag; noindex solo aparece en www/share.php, que ahora es únicamente la página de error, y robots.txt lo permite todo (comprobado el 16/10/2026). Segundo, desde el 17/08/2026 el sistema registra cada acceso a un enlace para compartir —hora, dirección IP sin truncar e identificador del navegador en share_views (véase también R11)—, pero eso no permite determinar quién está detrás del acceso.

Probabilidad: Posible. El token no se descubrirá por fuerza bruta. Se reenviará: pegado en una incidencia, un chat de grupo o un hilo de correo al que se añade un destinatario, y puede filtrarse mediante una cabecera Referer. Gravedad: Grave: un enlace expone toda una sesión a una audiencia ilimitada y no identificada, incluido todo lo cubierto por R1 y R2, y después solo puede determinarse desde qué dirección y navegador se accedió (share_views), no quién la vio. Las propias notas del proyecto recogen una cuestión relacionada como abierta y sigue sin verificarse: medido el 17/08/2026: los enlaces para compartir no eluden el límite de espectadores: ese límite no les es aplicable en absoluto. Los espectadores en vivo se cuentan mediante el indicador IS_LIVE_VIEWER de la conexión WebSocket (class/Server.class.php, zaehleLiveViewers). www/player.php no contiene ningún código WebSocket; el reproductor solo reproduce. Un enlace para compartir conduce al reproductor, no a la vista en vivo. Lo que realmente no tiene límite es otra cosa: cuántas personas abren el mismo enlace al mismo tiempo. No hay límite para ello ni, a diferencia de la vista en vivo, contador. Desde el 17/08/2026 al menos se registra cada acceso (share_views, registro B.6), de modo que posteriormente puede determinarse con qué frecuencia y desde dónde se utilizó un enlace.

R5 - Copia externa diaria completa (a Google Drive hasta el 05/09/2026 y, desde entonces, a Google Cloud Storage en Varsovia; transferida cifrada desde el 11/08/2026; datos heredados eliminados el 12/08/2026)

Este riesgo no figura en la base de hechos técnicos; se estableció a partir del propio archivo de puntos pendientes del proyecto y está documentado allí con detalle. Hasta el 11/08/2026 un script anterior de copias de seguridad se ejecutaba desde el cron de root a las 02:00 de cada día. Ejecutaba mysqldump sobre todas las bases de datos y creaba un archivo tar de todo el árbol web, para después subir el resultado mediante rclone a gdrive:backups/rpi-ls5/daily, sin cifrado en ningún momento. Localmente se confirma una salida diaria de 653 MB de base de datos y 678 MB de archivos. Desde el 11/08/2026 se ha cambiado la línea cron: la ejecución diaria corresponde a un nuevo script de copias de seguridad mantenido en el proyecto, que captura el mismo alcance, pero lo cifra en nuestro propio servidor antes de la transferencia (rclone crypt) y escribe en una carpeta de destino propia y separada; está programado para las 03:00. Los nombres de archivos y directorios también se cifran, por lo que el proveedor solo conserva bloques sin significado. La ejecución del 11/08/2026 se inició manualmente y llegó a su destino (733 MB de base de datos, 678 MB de archivos); la del 12/08/2026 finalizó según lo previsto a las 03:00. Ambas están registradas y, en los dos casos, la comprobación en destino encontró allí el volcado de la base de datos con el mismo número de bytes.

Por tanto, lo que sale de la máquina no es una copia de seguridad de las grabaciones de sesiones. Es una copia completa de todas las bases de datos y todos los sistemas del servidor, incluidas las grabaciones con sus capturas del DOM, las 173 entradas de formularios en claro, las 236 direcciones sin truncar y cada archivo .env con sus secretos de producción. El alcance no ha cambiado; el cifrado no modifica eso. Lo que ha cambiado es la legibilidad para el proveedor: hasta el 11/08/2026 no había ninguna capa de cifrado antes de la subida y el texto en claro llegaba en claro; desde el 11/08/2026 el cifrado se realiza en nuestro propio servidor antes de que salga nada, y las claves están en dos archivos con modo 600 en ese mismo servidor; Google no las tiene. Los datos heredados no estaban cubiertos por ello: el nuevo script solo limpia su propia carpeta de destino y la carpeta anterior conservaba copias semanales durante un máximo de 364 días. Se eliminó el 12/08/2026; por tanto, el proveedor ya no conserva copias completas sin cifrar anteriores al 11/08/2026.

• La transferencia es real y diaria. Hasta el 11/08/2026 no se había verificado si llegaba a su destino: la ejecución utilizaba la configuración de rclone de root, el script no registraba nada y cron descartaba su salida. Desde el 11/08/2026 la ejecución escribe un registro y comprueba por sí misma, tras la transferencia, si el volcado de la base de datos está en el destino con el número esperado de bytes; consta para el 11/08/2026 (manualmente) y el 12/08/2026 (programada, a las 03:00), en ambos casos con comprobación satisfactoria. Por tanto, está acreditado el funcionamiento diario, no solo el primer intento. Esto no resuelve el riesgo para la disponibilidad, sino que lo desplaza: si se pierden ambos archivos de claves, toda la copia de seguridad externa es irrecuperable. Una medida que impide al proveedor leer el contenido crea así una nueva dependencia de la custodia de las claves; según el responsable del tratamiento, fuera de esta máquina se conservan impresas en una caja fuerte (apartado 8.3). El operador ha probado el descifrado: es una declaración suya, no una medición realizada en este documento.
• Hasta el 05/09/2026 no se había acreditado ningún instrumento para la transferencia. La copia se conservaba en Google Drive con una cuenta privada (respondido el 17/08/2026), sin posibilidad de contratar una región de datos europea y sin acuerdo de encargado del tratamiento. Desde el 05/09/2026 se conserva en un bucket de Google Cloud Storage en la región europe-central2 (Varsovia) con una cuenta de empresa, amparada por el Google Cloud Data Processing Addendum; las copias de la cuenta de Drive se eliminaron el 06/09/2026.
• El script antiguo constituía una escalada de privilegios. Hasta el 11/08/2026 pertenecía a root, lo ejecutaba el cron de root y su modo de archivo era 777: cualquiera que tuviera la cuenta SSH pi obtenía privilegios de root a las 02:00. Desde el 11/08/2026 la ejecución diaria ya no pasa por ese script; la transferencia a Google Drive se retiró de él el 09/09/2026. Los scripts antiguos de copias de seguridad se retiraron el 16/10/2026. La nueva calificación de R5 corresponde al responsable del tratamiento.
• Hasta el 05/09/2026, la copia quedaba fuera de cualquier instrucción del cliente. El art. 28(3)(a) exige que el encargado actúe solo siguiendo instrucciones documentadas; ninguna instrucción registrada cubría una copia diaria de las grabaciones de visitantes del cliente a un servicio de nube estadounidense para consumidores. Desde entonces, el apartado 9 del acuerdo de tratamiento de datos y la lista de subencargados mencionan la copia de seguridad en Google Cloud Storage.

Superado desde el 05/09/2026 (véase arriba); se conserva aquí como historial. Respondido el 17/08/2026: cuenta privada. Por tanto, no se puede contratar una región de datos europea y no existe un acuerdo de tratamiento de datos - para una cuenta privada de Google no están disponibles las condiciones de tratamiento de datos. Decisión del responsable del tratamiento: la copia de seguridad permanece allí por ahora. Pruebas de restauración mensuales a partir de ahora. Los dos archivos de claves se conservan impresos en una caja fuerte a la que solo puede acceder el responsable del tratamiento (declaración del responsable, 17/08/2026); por tanto, sobreviven a la pérdida de esta máquina.

Medido el 17/09/2026: la última copia de seguridad satisfactoria se ejecutó a las 03:30 de ese día y superó la comprobación en destino. La prueba de restauración está prevista mensualmente; se superó antes de eliminar las copias de Drive el 06/09/2026 y ningún supervisor recuerda la siguiente. El 07/10/2026 se realizó además una restauración completa de datos desde la copia en la nube a un entorno separado (unos 70 minutos; muestras del archivo y de la base de datos sin errores). Desde el 06/10/2026, la copia diaria también contiene el archivo de grabaciones (/mnt/mouseplayer-dev-archive); está en el mismo disco que el sistema. Salvo indicación en contrario, la lista anterior describe el estado previo al 05/09/2026.

R6 - Reconocimiento entre sesiones y combinación con los registros propios del cliente

Se crea un identificador seudónimo y se conserva en el localStorage del visitante como mp_visitor_id. Por sí solo, esto es habitual y proporcionado para el análisis de visitantes recurrentes. Otros dos mecanismos cambian su naturaleza. MousePlayer.setUserId() permite al cliente vincular su propio identificador —un nombre de inicio de sesión, un número de cliente— a la grabación, almacenado en visitor_sessions.custom_user_id con un índice específico; y el mismo valor se recoge automáticamente de una ruta de dataLayer llamada 'uid', sin actuación deliberada del cliente. Si un gestor de etiquetas ya publica un identificador de usuario, las grabaciones pasan a ser atribuibles a una persona identificada como efecto secundario de la instalación.

A partir de ese momento, la grabación deja de ser seudónima en manos del cliente. Puede combinarse con su CRM, y la exportación a BigQuery está diseñada para incluir exactamente las columnas que hacen trivial la combinación: visitor_id, custom_user_id e ip_address en la misma fila. Esa exportación está actualmente desactivada en todos los proyectos y su proceso no está en ejecución: existe la capacidad, pero no la actividad.

Debería dejarse constancia de una debilidad del diseño sin exagerarla. visitor_nicknames tiene una restricción UNIQUE sobre visitor_id únicamente, sin límite entre clientes: la tabla abarca estructuralmente varios proyectos. En la práctica, el identificador reside en localStorage y, por tanto, se limita a un origen, de modo que esto no crea por sí solo un seguimiento entre sitios de distintos dominios de clientes. Es la ausencia de un límite en el esquema, no una filtración demostrada, y debería subsanarse antes de cualquier despliegue en el que dos proyectos puedan compartir un origen.

Probabilidad: Probable para el reconocimiento entre sesiones (es el comportamiento por defecto y hay 329 identificadores registrados); De posible a probable para la identificación, dada la vía automática de dataLayer. Gravedad: Grave: la identificación elimina el factor atenuante que hace tolerable la grabación del comportamiento, y lo hace retroactivamente: una vez vinculado un identificador, también pasan a ser atribuibles las sesiones antes seudónimas de ese visitante.

R7 - Sin plazo de supresión para trece tablas; plazos establecidos el 17/08/2026

La purga que tiene en cuenta el plan elimina cinco tablas: mouse_events, session_custom_event_params, session_custom_events, session_pageviews y visitor_sessions. Faltan en esa lista trece tablas que contienen datos personales: ai_session_features, ai_timelines, consent_events, session_comments, session_shares, visitor_nicknames, ip_lifetime_stats, audit_logs, user_ip_history, users, incluido last_ip, support_requests, consent_region_acceptances y heatmap_page_stats.

La consecuencia práctica es peor de lo que sugiere la lista, por el orden en que ocurrirían las cosas. Cuando finalmente se active la purga, desaparecerá la sesión y permanecerán los datos derivados: ai_timelines conservaría la sesión como prosa legible, con 3 203 filas y 5,5 MB, que describe a una persona cuyo registro subyacente se ha eliminado. Actualmente no hay registros huérfanos de ese tipo, pero solo porque nunca se ha eliminado nada.

Otros tres defectos agravan la situación. La rutina no está programada mediante cron o systemd, sino que se ejecuta dentro del proceso trabajador; por ello, si ese proceso se detiene, la supresión se detiene y nada lo comunica. Su consulta de selección combina las sesiones con proyectos, espacios de trabajo, propietarios y usuarios mediante uniones internas, de modo que una sesión cuyo proyecto se haya eliminado nunca puede seleccionarse y nunca se suprimirá: una de las 706 sesiones ya está en ese estado. Además, la conservación realmente vigente es de 365 días para todos los proyectos del sistema, frente a un conjunto de datos cuyo registro más antiguo tiene 20 días; por ello, la cadena de eliminación nunca se ha ejecutado de principio a fin.

Probabilidad: Materializada. Gravedad: Grave, como infracción estructural y no accidental del art. 5(1)(e). Cambiado el 17/08/2026. La ejecución permanece en db_worker, pero ahora se detecta su AUSENCIA: el trabajador registra su resultado (mp_purge_status) y srv/cron_status.php —un proceso DIFERENTE— lo evalúa cada 60 segundos, escribe sys_purge para el área de administración y avisa por correo electrónico cuando han pasado más de 48 horas desde la última ejecución. Como máximo, un mensaje al día; un supervisor que envía un correo cada minuto termina siendo ignorado y tampoco comunica a nadie el fallo real. El supervisor se sitúa deliberadamente fuera del trabajador: un proceso muerto no puede informar de sí mismo. Situación a 23/09/2026: el envío de correo saliente está operativo; el mensaje se envía a la dirección de alertas configurada en el área de administración.

Situación a 17/08/2026. Resuelto. Cinco de las trece tablas forman parte de la cadena común de eliminación desde el 12/08/2026; seis recibieron un plazo propio configurable en el área de administración (migración 039), y dos faltaban por completo en la lista: ai_visitor_value y ai_insights - precisamente la puntuación de la persona y el texto generado sobre ella. Los plazos están en site_settings y se leen de la misma fila de la que los obtiene el registro del art. 30 para su propio texto. La purga sí se ejecuta; la ejecución del 17/08/2026 a las 17:37:09 consta en el registro del trabajador. Por tanto, ya no puede ocurrir lo que preocupaba en este apartado: que desaparezca la sesión y queden sus datos derivados huérfanos. La ejecución sigue dependiendo del proceso trabajador y no está programada mediante cron ni systemd; desde el 17/08/2026, el supervisor del proceso de estado comunica su ausencia y, desde el 23/09/2026, también lo hace por correo electrónico.

Nueva calificación del 23/09/2026. Medido ese mismo día: la purga se había ejecutado por última vez 21 horas antes; la fila más antigua de audit_logs tiene 60 días, exactamente el plazo configurado, y ninguna sesión carece de proyecto. La selección sigue utilizando uniones internas; aun así, no se generan sesiones huérfanas, porque al eliminar un proyecto o una cuenta se eliminan también sus sesiones mediante channelid. Desde el 24/09/2026, user_ip_history también tiene un plazo propio: 90 días desde la última vez que se observó una dirección y, como máximo, hasta la eliminación de la cuenta. Probabilidad: Remota. Gravedad: Grave. Nivel global: bajo.

R8 - Puntuación y clasificación automatizadas de cada sesión

Cada sesión se evalúa automáticamente. engagement_score (0-255) se calcula a partir de señales de profundidad y de irritación; session_quality distingue las sesiones en las que ocurrió poco; is_bot, con un código de motivo, clasifica al visitante como no humano, y esa comprobación se ejecuta antes del control de consentimiento. Las puntuaciones están indexadas y determinan el orden de la lista de revisión del cliente, lo que significa que determinan qué personas son observadas. En el examen de agosto de 2026 existían 4 043 filas de características y 3 203 relatos generados.

Esto constituye elaboración de perfiles en el sentido del art. 4(11): evaluación automatizada de aspectos personales de una persona física, específicamente para analizar o predecir su comportamiento. Según las pruebas, no constituye toma de decisiones automatizada conforme al art. 22: no se encontró ninguna decisión de crédito, precio, acceso o admisibilidad respecto de un visitante. Un mecanismo se aproxima más al límite que los demás y debería mencionarse: al detectar un clic de rabia, www/mp.js envía un juicio sobre el comportamiento a widgets de chat de terceros que se ejecutan en el propio navegador del visitante; Intercom recibe un indicador y LiveChat una variable de sesión. Así, un juicio formado sobre el visitante sale del sistema en tiempo real y puede cambiar el trato que recibe esa persona en el sitio.

Alcance de la elaboración de perfiles, situación a 16/10/2026. Desde el examen se han añadido otras puntuaciones y datos derivados, y todos forman parte de este riesgo: frases e informes formulados por una máquina sobre visitantes individuales (ai_insights, ai_besucher_bericht; los hallazgos se calculan y un modelo de lenguaje en nuestras propias máquinas de la misma red local los redacta); un modelo de salida (regresión logística) que estima un riesgo de salida en el navegador del visitante y, si el operador lo activa, desencadena una oferta de salida cuyo texto solo se muestra tras la aprobación del operador; un indicador de riesgo de fuga basado en reglas para visitantes recurrentes (ai_churn); perfiles de comportamiento que agrupan sesiones según su desarrollo (k-means, mp_profile, mp_profil_sitzung) y patrones de secuencias; una puntuación de fricción por sesión; encuestas y un botón de comentarios con las respuestas del visitante; seguimiento de elementos que asigna los clics a elementos marcados; un índice de los textos mostrados para búsquedas (mp_text_block, mp_text_pv, 30 días); y mensajes de consola, así como solicitudes fallidas o lentas de la página del cliente (sin cuerpo ni cabeceras). Según las pruebas, ninguno de ellos toma una decisión del art. 22 respecto del visitante; sin embargo, la oferta de salida cambia directamente lo que se muestra al visitante en la página y, por ello, es la más cercana al límite de las funciones enumeradas. Los detalles figuran en el registro del art. 30.

Por separado, dos consecuencias automatizadas sí tienen un efecto real, pero sobre clientes y direcciones IP, no sobre visitantes: una cuenta marcada automáticamente como is_suspicious al registrarse ve reducida su conservación de datos a 24 horas, y una IP que supera los umbrales de conexión se bloquea, tras lo cual se interrumpe toda solicitud posterior; en el examen de agosto de 2026 había 24 bloqueos de este tipo registrados. En el momento del examen, ninguno tenía una vía documentada de revisión humana ni un canal de oposición; para el bloqueo existe uno desde el 17/08/2026 (más abajo), pero para el indicador is_suspicious sigue sin existir.

Probabilidad: Probable (comportamiento por defecto). Gravedad: Significativa: no produce efectos jurídicos sobre los visitantes, pero recibir una puntuación y una posición sin saberlo y que esa puntuación se exporte a un widget de un tercero constituye precisamente la pérdida de control descrita en el considerando 75. Evaluado el 17/08/2026. Desde ese día, el bloqueo automático caducaba por sí solo tras 7 días; antes nunca caducaba. A 16/10/2026, el servidor WebSocket bloquea por sí mismo y el bloqueo caduca tras 24 h (configurable de 1 a 168 h); fail2ban bloquea durante una hora; banned_ips solo se rellena manualmente. La oposición se presenta mediante el formulario de soporte o a office@mouseplayer.com y la tramita una persona; el área de administración permite levantar el bloqueo. La duración está en site_settings (autoban_stunden). Por tanto, la medida tiene un efecto limitado, revisión humana previa solicitud y una vía identificada para solicitarla: las características de las que depende el art. 22. La clasificación en sí sigue siendo una cuestión jurídica; lo decidido es la garantía, no la interpretación. (decisión del responsable del tratamiento, 17/08/2026)

R9 - 92 sesiones inaccesibles mediante cualquier identificador; no existe una vía de la persona a su registro

92 sesiones llevan visitor_id 'unknown'. No existe ninguna clave que permita llegar a esos registros: los datos existen, son personales, contienen una reproducción y quizá una dirección, y no pueden recuperarse mediante ninguna consulta que pudiera derivarse de una solicitud de un interesado. No puede atenderse su supresión conforme al art. 17 ni responderse al acceso conforme al art. 15. Nueva medición el 16/10/2026: ya no hay ninguna sesión con visitor_id 'unknown'; no obstante, el código todavía puede escribir ese valor al crear una sesión.

El problema más amplio es peor que esas 92 filas y las propias notas del proyecto ya lo recogen como no resuelto. Incluso cuando existe un visitor_id, reside en el localStorage del visitante y la persona no lo conoce. No hay ninguna vía de una persona real —que puede aportar un nombre, un correo electrónico, una fecha y una página— a sus registros. Un botón de supresión al que no puede acceder quien tiene derecho a pulsarlo es un mero decorado.

El art. 11 ofrece una respuesta parcial e incómoda: cuando el responsable pueda demostrar que no está en condiciones de identificar al interesado, no se aplican los arts. 15 a 20; pero el art. 11(2) exige que el responsable informe de ello al interesado, y este puede aportar información adicional que permita su identificación. Esa última cláusula es la clave: el visitante puede aportar su identificador porque está en su propio navegador. Una página de autoservicio que muestre al visitante su propio mp_visitor_id convertiría una solicitud imposible en una rutinaria, lo que hace difícil defender la invocación del art. 11 mientras no exista esa página.

Probabilidad: Materializada. Gravedad: Significativa, que pasa a Grave en combinación con R1: quien menos puede acceder a su registro es quien no sabe que existe. Decidido el 17/08/2026: se habilitará una página de acceso a los propios datos para visitantes en la que el visitante vea su identificador y pueda solicitar la eliminación de sus grabaciones, enlazada desde la política de privacidad. (decisión del responsable del tratamiento, 17/08/2026) Operativa desde el 17/08/2026 en /my-data (alemán /meine-daten, polaco /moje-dane), enlazada desde el pie de todas las páginas. Muestra el número de sesiones, el período y los dominios afectados, pero ninguna grabación: el identificador es un token al portador y, de otro modo, cualquiera que lo conociera podría ver el comportamiento de otra persona. La eliminación se pone en cola y la ejecuta el trabajador mediante la cadena existente; la propia página no elimina.

La medida en que esto mitiga R9 depende de dónde se grabó al visitante, y ese límite es técnico: el almacenamiento del navegador está separado por origen. El identificador está en el almacenamiento del sitio web en el que se ejecutó el script, no en el nuestro. Por tanto, una página de mouseplayer.com no puede verlo por sí sola; se ha verificado con los datos, en los que ningún identificador aparece en más de un dominio. De ello se derivan tres vías de acceso:

• Los visitantes del propio mouseplayer.com acceden directamente a sus datos, porque aquí el almacenamiento del navegador es nuestro. Para ellos, R9 desaparece.
• Los visitantes de un sitio web de un cliente acceden mediante un enlace que el cliente coloca en su propio aviso de privacidad; MousePlayer.privacyUrl() lo devuelve preparado, con el identificador incluido. No es una evasión, sino la distribución de funciones conforme al art. 28: frente a sus propios visitantes, el cliente es el responsable del tratamiento, y la información del art. 13 corresponde de todos modos a su política. Nosotros proporcionamos la herramienta y somos el destinatario.
• Cualquiera que ya conozca su identificador lo introduce en la página.

Si un cliente no coloca el enlace, R9 sigue plenamente vigente para sus visitantes: la solicitud no es entonces imposible, pero pasa por el cliente y no por nosotros; para ese caso, la política de privacidad contiene la declaración del art. 11. Quien haya borrado el almacenamiento de su navegador no es accesible por ninguna de las tres vías. Por tanto, la página no elimina R9: lo transforma de "técnicamente imposible de atender" en "atendible, siempre que el responsable del tratamiento señale el camino".

R10 - Sin cifrado en reposo ni TLS hacia la base de datos o Redis a través de la LAN

Tres carencias de infraestructura figuran como no implementadas y se han verificado, no supuesto. El cifrado de tablas InnoDB, registros y tablas temporales está desactivado, y el disco no está cifrado; por ello, todo el conjunto —322,6 MB de eventos y 162,9 MB de capturas de páginas— permanece en reposo en claro. La conexión a la base de datos funciona sin TLS: el servidor lo admite, pero no hay configurado ningún certificado, clave ni CA; la conexión es local, lo que atenúa el problema sin eliminarlo. Hasta el 16/08/2026, Redis funcionaba sin protección de acceso y persistía en disco, y sus colas contienen en tránsito la IP truncada, la URL completa y la carga útil del DOM.

Probabilidad: Posible. Es improbable una explotación remota: en el momento del examen, Redis y la base de datos solo estaban vinculados a localhost (para el estado actual, véase más abajo), se obliga a usar HTTPS y la conexión TLS del WebSocket termina con un certificado real en nginx. Las vías realistas son físicas —robo de la máquina, retirada del disco— y la vía de la copia de seguridad de R5, que sacaba de la máquina cada noche el mismo texto en claro hasta el 11/08/2026 y, desde entonces, transfiere cifrado; las copias sin cifrar anteriores a esa fecha se eliminaron del proveedor el 12/08/2026. Gravedad: Muy grave si se materializa, porque queda expuesto todo a la vez.

Respondido el 17/08/2026: el servidor está en una sala cerrada con videovigilancia en Łódź; solo el responsable del tratamiento tiene acceso. El disco USB de copias de seguridad está en la misma sala que el servidor. Respondido el 17/08/2026: el cifrado en reposo no se introducirá antes de producción: no es viable en la fase inicial en la Raspberry Pi (decisión del responsable del tratamiento). Por tanto, este riesgo permanece íntegro: todos los datos están en claro en el disco y el disco USB de copias de seguridad está en la misma sala. La garantía restante es física —una sala cerrada con videovigilancia, a la que solo accede el responsable del tratamiento— y solo protege frente al robo o a la retirada inadecuada de un disco en la medida en que resista esa sala. Debe reevaluarse en cuanto la operación salga de la Raspberry Pi.

Situación a 17/08/2026. Una parte está resuelta y otra se ha desplazado. Redis tiene el acceso restringido desde el 16/08/2026; se ha comprobado con el servicio que rechaza solicitudes sin autenticación. Sigue sin haber cifrado en reposo. Sin embargo, el supuesto atenuante de este apartado ya no se cumple: desde el 16/08/2026, Redis y la base de datos ya no escuchan solo en localhost, sino también en la dirección LAN (bind-address = 127.0.0.1,192.168.20.2), para que un segundo nodo pueda acceder al estado compartido; las líneas ssl- de la configuración del servidor siguen comentadas. Mientras funcione un solo nodo, esto es teórico. Con el segundo, el contenido de las sesiones y el tráfico de la base de datos atraviesan la red en claro, y las vías dejan de ser únicamente físicas. La calificación de este riesgo debe reevaluarse antes de que entre en servicio un segundo nodo.

Situación a 16/10/2026. Las conexiones desde Internet están cifradas mediante TLS; el cifrado termina en nginx y el servidor WebSocket escucha solo en 127.0.0.1:8081, es decir, en la misma máquina. MousePlayer utiliza su propia instancia de Redis en 127.0.0.1:6381, con acceso restringido y persistencia en disco (archivo de solo adición); por tanto, el contenido de las colas y las direcciones IP sin truncar conservadas durante el bloqueo automático (24 h) también llegan al disco. Una instancia anterior y compartida de Redis escucha además, con acceso restringido, en la dirección LAN. MariaDB escucha en 127.0.0.1 y en la dirección LAN 192.168.20.2 sin TLS (sin certificado configurado), y hay conexiones desde la red local. Así, dentro de nuestra propia red local, en la misma ubicación, las conexiones de base de datos y Redis funcionan sin cifrar; tienen el acceso restringido y solo son accesibles desde nuestra propia red local (sin redirección de puertos). Sigue sin haber cifrado en reposo.

R11 - No se registra quién vio cada grabación

El registro de auditoría recoge acciones de escritura: creación y revocación de enlaces para compartir, eliminación de comentarios, eliminación de sesiones y visitantes, bloqueos automáticos y acciones de superadministrador; 666 entradas en total en el examen. No registra las lecturas. Una llamada a la página del reproductor, al endpoint de eventos o al endpoint de teatro no deja rastro. Nadie puede determinar después qué empleado de un cliente vio la sesión de una persona identificada, cuántas veces o si lo hizo un administrador de MousePlayer. Desde el 17/08/2026 al menos se registran los accesos a enlaces para compartir (share_views); las llamadas de usuarios que han iniciado sesión no dejan rastro (situación a 16/10/2026).

Probabilidad: Materializada como carencia de control. Gravedad: Significativa, con un efecto agravante más importante que el directo: tras cualquier incidente, los arts. 33 y 34 exigen al responsable del tratamiento describir las categorías y el número aproximado de interesados y registros afectados. Sin registrar las lecturas, esa descripción no puede elaborarse a partir de pruebas y cada notificación se convierte en una estimación.

R12 - Calidad de las pruebas de consentimiento y adaptadores de CMP sin probar

El art. 7(1) atribuye al responsable del tratamiento la carga de probar el consentimiento, y el código lo indica expresamente como razón de ser del registro de consentimiento. En los datos medidos del examen (agosto de 2026), 671 de 706 sesiones llevan consent_source='testdata' con una marca de tiempo NULL, escrita por una estructura de datos de prueba de desarrollo: no prueban nada. Los registros auténticos eran entonces 35: 27 de la API, 5 de Google Consent Mode, 2 consentimientos tardíos y 1 retirada. A 16/10/2026, 566 de 8 648 sesiones humanas llevan consent_source='testdata'; las demás llevan un registro de la API (7 451), del adaptador Consented (620) o de Google Consent Mode (9). La eliminación al retirar el consentimiento existe como opción y está desactivada en todos los proyectos (situación a 16/10/2026), por lo que una retirada detiene la grabación futura, pero conserva las grabaciones anteriores.

De los seis adaptadores de CMP y las tres capas de detección de consentimiento, solo se han probado en condiciones reales tres vías: la API directa, Google Consent Mode y Cookiebot. TCF y cinco adaptadores —Usercentrics, OneTrust, Consentmanager, Borlabs y Complianz— están implementados, pero nunca se han ejecutado con una CMP real. Dado el principio rector de cierre ante fallo, un adaptador que interprete mal una señal falla hacia la ausencia de grabación, que es la dirección segura; por tanto, el riesgo consiste principalmente en pruebas no verificadas y no en una grabación ilícita.

Probabilidad: Materializada para este conjunto de datos. Gravedad: Grave en términos de producción, porque un consentimiento que no puede acreditarse es, en caso de controversia, un consentimiento que no existió. Esta calificación se aplica a los datos de desarrollo y debe medirse de nuevo. pendiente de completar: la proporción medida de sesiones de producción con un registro auténtico de consentimiento y la fecha en que se verificó cada adaptador de CMP con una instalación real

R13 - Solicitudes de soporte reenviadas a Telegram con la IP sin truncar (transferencia interrumpida el 11/08/2026)

Hasta el 11/08/2026, al enviar una solicitud de soporte, se remitía todo el asunto a Telegram: estado de la cuenta, dirección de correo electrónico, asunto, el texto completo del mensaje, la URL de origen y la dirección IP sin truncar. Los tokens estaban configurados, por lo que esa rama estaba activa. Quien solicita soporte a menudo no es cliente y el texto de soporte no tiene restricciones: las personas describen situaciones de salud, controversias y circunstancias financieras en las solicitudes porque eso es lo que invita a hacer el campo. Desde el 11/08/2026 cfg/lib.php envía exactamente una cadena fija: "MousePlayer: es liegt eine neue Supportanfrage vor." No llega ni una sola variable al mensaje, no hay parse_mode y deliberadamente no hay número de caso —sería un identificador relativo a una persona— ni enlace construido a partir del nombre de host solicitado, porque ese valor procede de la propia solicitud. Un control (ai/pruefstand/test_telegram_signal.php) comprueba no el resultado, sino la posibilidad: qué variables pueden llegar al mensaje. Se permiten cuatro, se prohíben 15 identificadores y el texto debe ser una cadena entre comillas simples sin interpolación; el control se ejecutó contra dos versiones rotas deliberadamente y detectó ambas. Lo que no se ha subsanado es el almacenamiento local. La solicitud se almacena sin cambios en support_requests, incluidas la dirección de correo electrónico y la dirección IP: es intencionado, el operador las necesita para controversias; support_requests no tenía plazo de conservación hasta el 17/08/2026 y, desde entonces, la solicitud se suprime tras 730 días (véase R7). El objetivo del cambio es que los datos no salgan, no que desaparezcan.

Probabilidad: Materializada hasta el 11/08/2026 en cada envío; desde el 11/08/2026 la transferencia ya no se produce. Gravedad: Significativa: hasta el 11/08/2026 porque Telegram está fuera de la UE y no ofrece un acuerdo de tratamiento para canales de bots; desde entonces, la misma calificación corresponde solo al almacenamiento local, porque persiste la conservación de correo electrónico, IP y texto libre sin restricciones en la propia base de datos del operador, limitada a 730 días desde el 17/08/2026. Ha desaparecido el elemento de tercer país y la conservación está limitada; se trata en R7. La decisión está tomada y fechada: se mantiene el canal y, desde el 11/08/2026, el mensaje no contiene datos. Por tanto, ya no se requieren una base jurídica ni un instrumento para una transferencia a un tercer país, porque no llega ningún dato personal a Telegram; para esta operación, Telegram no es encargado del tratamiento. Nivel global: medio hasta el 11/08/2026 y bajo desde entonces.

R14 - Salida hacia destinatarios elegidos por el propio responsable del tratamiento

MousePlayer ofrece puentes mediante los que se transmiten elementos individuales a los sistemas propios del responsable del tratamiento: su sistema de relación con clientes, asistencia, marketing, publicidad, almacenamiento o tareas, o una dirección que él mismo indique. Solo él hace la selección y almacena las credenciales; por tanto, la transmisión constituye una instrucción suya. Los detalles figuran en el Registro, apartado 4.1.

Dónde reside el riesgo. No en el volumen: se transmiten identificadores y nombres de eventos, nunca el contenido grabado de las páginas, la trayectoria del ratón ni el texto de formularios. El riesgo reside en la irreversibilidad. Si recibimos una solicitud de supresión conforme al art. 17, suprimimos nuestra copia; no podemos acceder a la copia del destinatario. Cuánto tiempo la conserva, adónde la lleva y a quién la transmite está fuera de nuestra influencia y no podemos supervisarlo. Lo mismo se aplica a una transferencia a un tercer país: el responsable determina el destino y, con él, la garantía conforme al capítulo V.

Qué se ha hecho al respecto. La política de privacidad indica claramente ambos extremos —qué sale y que una solicitud de supresión no tiene efecto allí— y remite al interesado al operador del sitio web, que tomó esa decisión, para saber qué destinatarios están activados. El DPA aclara que esos destinatarios no son subencargados de MousePlayer. Técnicamente, el volumen se mantiene reducido y no se envían expresamente a redes publicitarias nombre, dirección de correo electrónico, teléfono ni dirección IP. Desde el 20/08/2026, cada proyecto mantiene un registro de entregas (Registro A.11) en el que el responsable puede ver qué salió realmente; antes no le era visible.

Qué permanece. Un riesgo residual que no puede eliminarse técnicamente mientras exista la función: la comunicación es intencionada y sus consecuencias quedan fuera de nuestra esfera. Lo asume el responsable que activa el puente, y se le indica en el DPA y en esta evaluación.

8. (d) Medidas previstas para afrontar los riesgos

Cada medida siguiente tiene un estado, y esos estados no son decorativos. Implementada significa verificada hoy en el sistema en funcionamiento. Parcial significa que el mecanismo existe, pero aún no alcanza su finalidad. Prevista significa que no existe. Presentar en una EIPD medidas previstas como si estuvieran implementadas es el reproche habitual contra este instrumento y el que destruye el valor del documento precisamente en la única situación en que importa.

8.1 Implementadas actualmente: verificadas

Medida	Aborda	Prueba
Control de consentimiento en el navegador, con cierre ante fallo: la ausencia de señal, el fallo de la CMP, un error de script y un origen desconocido dan lugar a "no grabar"	Licitud	Máquina de estados mpEinw en www/mp.js, después de la comprobación de bots
Aplicación independiente del lado del servidor: solo pasan GRANTED o GRANTED_LATE o una exención regional explícita; la retirada, un país desconocido y cualquier situación dudosa cierran la conexión	Licitud	class/Server.class.php:977-1004; 24 conexiones bloqueadas registradas en el examen
Lista de exclusión de rutas aplicada antes del control, con coincidencia solo sobre la ruta	Minimización	class/Server.class.php:963-975; 71 conexiones bloqueadas registradas en el examen
Truncamiento de IP en el momento de leerla, antes de cualquier componente que utilice el valor	R3, solo de cara al futuro	class/Server.class.php:432-435; todas las sesiones desde el 07/08/2026 tienen la dirección truncada
Enmascaramiento de formularios con una protección mínima incondicional para contraseñas y datos de pago en cualquier configuración; todos los proyectos en el nivel más estricto	R2, solo de cara al futuro	www/mp.js:4818-4853
Clasificación de nombres de campos en lugar de transmitirlos	Minimización	www/mp.js:4653-4674
Enmascaramiento del DOM dentro de regiones marcadas, también aplicado a cambios en vivo	R1, parcialmente	www/mp.js:3934-3970 y 4732-4768
Cadena TC almacenada solo como hash SHA-256	Minimización	visitor_sessions.tcf_hash
Carga útil de la reproducción excluida deliberadamente de la API pública	R4	www/api/v1_session_detail.php:25
Enlaces para compartir: token de 160 bits, duración por defecto de 7 días y máxima de 90 días, identificadores obtenidos solo del token, cadena de consulta sustituida en lugar de ignorada, rol NULL, los tres endpoints restringidos, respuesta idéntica para tokens inventados, caducados y revocados, revocación disponible	R4	cfg/lib.php mp_share_erstellen / mp_share_pruefen; www/.htaccess
Geolocalización mediante archivos locales de bases de datos: ninguna llamada a terceros en toda la vía de grabación	Transferencias a terceros países	class/IP2CityLite.class.php:37; class/Server.class.php:724
Modelo de roles por espacio de trabajo; eliminación restringida a propietario y administrador y siempre limitada al proyecto	Control de acceso	www/player.php:267, 275-282
Registro de eventos de consentimiento conservado deliberadamente más allá de la eliminación de la sesión, como prueba de que se produjo una retirada	Art. 7(1)	srv/db_worker.php:257-259
Registro de auditoría de acciones de escritura	Responsabilidad proactiva	cfg/lib.php:2878-2890; 666 entradas en el examen
Seguridad del transporte: HTTPS obligatorio; TLS con un certificado real termina en nginx, también para el WebSocket (/mp_wss/), el túnel HTTP (/mp_wst), la subida de capturas (/mp_dom) y el punto de medición (/mp_wsfail); el servidor WebSocket escucha solo en la dirección de bucle local. Las conexiones de base de datos y Redis dentro de la red local no están cifradas (véase R10)	Confidencialidad	www/.htaccess; configuración de nginx (srv/nginx/); srv/server.php vinculado a 127.0.0.1:8081
Tokens CSRF de random_bytes con comparación en tiempo constante; cookie de sesión httponly, SameSite=Lax y secure; hash de contraseñas; sentencias preparadas en todas las vías de escritura auditadas; límite de frecuencia de inicio de sesión; bloqueo automático y límites de conexiones por IP; fail2ban en ejecución	Confidencialidad	cfg/lib.php:110-132; www/login.php; class/Server.class.php:449-455, 660-668
Secretos fuera del control de versiones	Confidencialidad	.gitignore incluye .env; solo .env.example está bajo control de versiones
Conservación aplicada a los registros del portal: 60 días y 72 horas, respectivamente, más la caducidad de bloqueos	Limitación del plazo de conservación	srv/db_worker.php (ejecución diaria de eliminación)
Ejecución diaria de eliminación por plan y por plazos separados para las demás tablas, más la aplicación cada hora de los plazos de sesiones marcadas como bots; un proceso de estado separado comunica su ausencia por correo electrónico y en los Registros urgentes	Limitación del plazo de conservación, R7	srv/db_worker.php; srv/cron_status.php (sys_purge); entrada más antigua de audit_logs el 16/10/2026 en el plazo de 60 días
fail2ban con nueve jaulas, entre ellas mp-nginx-429, que bloquea direcciones que activan reiteradamente el límite de frecuencia de nginx; además, límites de frecuencia en nginx	Disponibilidad, prevención de abusos	fail2ban-client status, comprobado el 16/10/2026
Archivado antes de la eliminación definitiva: al eliminar proyectos, espacios de trabajo y cuentas, así como al eliminar por dirección IP o visitante, primero se ocultan los datos y se detiene la grabación; la eliminación definitiva se realiza tras 30 días o antes, previa solicitud, y el trabajador la ejecuta y vuelve a contar los registros. La eliminación de cuentas inactivas no realiza un archivado previo	Integridad, limitación del plazo de conservación	Migración 189; cfg/archivierung_lib.php; mp_loesch_archiv
Plazos para sesiones marcadas como bots: vaciado de la grabación (plazo en días: 1), eliminación de la fila de sesión tras 14 días	Limitación del plazo de conservación	site_settings retention_bot_recording_days y retention_bot_session_days; srv/db_worker.php

8.2 Parciales: existen, pero aún no alcanzan su finalidad

Medida	Por qué aún no es eficaz
Enmascaramiento del DOM	Activación expresa por elemento. Protege lo que escribe el visitante, no lo que muestra la página: el núcleo de R1
Eliminación al retirar el consentimiento	Implementada como opción, desactivada en todos los proyectos (situación a 16/10/2026), por lo que una retirada no elimina lo ya grabado
Cabeceras noindex y no-referrer	La página que muestra la grabación mediante un enlace para compartir (player.php en modo compartido) lleva Referrer-Policy: no-referrer y Cache-Control: no-store, pero no una cabecera X-Robots-Tag; noindex solo aparece en www/share.php, la página de error, y robots.txt lo permite todo (comprobado el 16/10/2026)

8.3 Previstas: no implementadas

Medida	Aborda	Prioridad
Cifrar la copia externa antes de subirla: hecho el 11/08/2026: la ejecución diaria cifra en nuestro propio servidor antes de transferir (rclone crypt, incluidos los nombres) y las claves están en dos archivos con modo 600. Eliminar los datos heredados sin cifrar de la carpeta de destino anterior: hecho el 12/08/2026. Depositar los archivos de claves de modo que sobrevivan a la destrucción de la máquina: hecho el 17/08/2026: se conservan impresos en una caja fuerte (declaración del responsable del tratamiento). Formalizar o finalizar la relación con Google Drive – hecho el 05/09/2026: desde ese día, la copia externa se conserva en un bucket de Google Cloud Storage en la región europe-central2 (Varsovia) y está amparada por el Google Cloud Data Processing Addendum. El resto de la cuenta privada de Drive se eliminó el 06/09/2026, después de superar la prueba de restauración desde el nuevo destino. Retirar los scripts antiguos de copias de seguridad: hecho el 16/10/2026.	R5	Ya no es aplicable: hecho
Invertir el valor por defecto del contenido de páginas: almacenar el texto enmascarado salvo habilitación explícita y exigir una confirmación escrita del cliente antes de capturar literalmente el texto de la página	R1	Primera
Política contractual de sectores: qué sectores se admiten y con qué condiciones adicionales	R1	Primera
Truncar o eliminar una sola vez las 236 + 291 + 666 + 5 direcciones heredadas: hecho el 17/08/2026: los datos heredados de la vía de grabación y de audit_logs y user_ip_history están truncados (véase R3)	R3	Ya no es aplicable: hecho el 17/08/2026
Revisar y suprimir las 173 filas de entradas en claro: hecho el 17/08/2026: eliminadas sin revisión (decisión del responsable del tratamiento, véase R2)	R2	Ya no es aplicable: hecho el 17/08/2026
Ampliar la purga a las trece tablas no cubiertas; trasladarla a una programación supervisada; corregir la carencia de las uniones internas para que las sesiones huérfanas sean accesibles	R7	No es aplicable: completado el 17/08/2026 (plazos y supervisor); se mantiene la selección con uniones internas, pero no se generan sesiones huérfanas (véase R7)
Registrar el acceso de lectura al reproductor y a ambos endpoints de datos	R11, art. 33	Alta
Referrer-Policy y X-Robots-Tag en la página del reproductor; reducir la duración por defecto de los enlaces para compartir: Referrer-Policy: no-referrer está configurado en modo compartido (comprobado el 16/10/2026); están pendientes X-Robots-Tag y una duración por defecto más corta (sigue siendo de 7 días)	R4	Media
Consulta de autoservicio para que un visitante recupere su identificador y puedan atenderse las solicitudes de los arts. 15 y 17: hecho el 17/08/2026: /my-data (alemán /meine-daten, polaco /moje-dane), véase R9	R9	Ya no es aplicable: hecho el 17/08/2026
No eximir nunca del enmascaramiento el estado de casillas de verificación y botones de opción; ampliar el enmascaramiento para incluirlo	R1, R2	Media
Cifrado en reposo; TLS hacia la base de datos; protección de acceso de Redis: la protección de acceso de Redis está hecha desde el 16/08/2026; están pendientes el cifrado en reposo y TLS hacia la base de datos (véase R10)	R10	Media
Retirar la IP de la notificación a Telegram o sustituir el canal: completado el 11/08/2026: la notificación consiste ahora en un aviso de texto fijo sin ninguna variable (cfg/lib.php), protegido por ai/pruefstand/test_telegram_signal.php	R13	No es aplicable: completado el 11/08/2026
Plazo de conservación para support_requests, audit_logs y user_ip_history	R7	No es aplicable: completado el 17/08/2026 para support_requests y audit_logs, y el 24/09/2026 para user_ip_history
Límite entre clientes en visitor_nicknames	R6	Baja
Vía documentada de revisión y oposición para el bloqueo automático y el indicador is_suspicious; para el bloqueo automático, hecho el 17/08/2026 (caducidad entonces tras 7 días y ahora tras 24 h, oposición mediante el formulario de soporte y levantamiento en el área de administración, véase R8); sigue pendiente para el indicador is_suspicious	R8	Baja
Verificar cada adaptador de CMP con una instalación real antes de ofrecerlo	R12	Baja

8.4 Procedimientos y garantías aún por establecer

El art. 35(7)(d) exige garantías, medidas de seguridad y mecanismos - lo que incluye los procedimientos organizativos, no solo el código. En el momento del examen faltaban cuatro; junto a cada uno figura su estado actual.

• Establecido el 17/08/2026. Detección: el responsable del tratamiento, un Cliente o un visitante del sitio web. Vía para comunicárnoslo: privacy@mouseplayer.com. Decisión sobre la notificación a la autoridad de control: Lukas Wójcik, propietario, dentro de las 72 horas conforme al art. 33(1). Información al Cliente: por correo electrónico, sin dilación indebida conforme al art. 33(2), a más tardar en 48 horas (acuerdo de tratamiento de datos, apartado 8). Envío: el correo saliente está configurado desde el 23/09/2026 mediante SMTP de Namecheap Private Email (remitente office@mouseplayer.com); por tanto, la vía prometida al Cliente está operativa. Hasta ahora no se ha realizado ningún simulacro.
• Respondido el 17/08/2026: hasta entonces no se había realizado ninguna prueba de restauración; se preveía una prueba mensual, con un objetivo de tiempo de recuperación de un máximo de 24 horas. Los dos archivos de claves se conservan impresos en una caja fuerte a la que solo puede acceder el responsable del tratamiento. Realizado desde entonces: una prueba de restauración desde el nuevo destino en Google Cloud Storage antes de eliminar las copias de Drive (05/09/2026 y 06/09/2026) y, el 07/10/2026, una restauración completa de datos desde la copia en la nube a un entorno separado: unos 70 minutos, con muestras del archivo y de la base de datos sin errores. Esto acredita la recuperación de datos, no la reconstrucción de una máquina de producción completa; no hay ningún supervisor que recuerde la siguiente prueba.
• Respondido el 17/08/2026: NO hay alertas automáticas; la comprobación se hace manualmente. Medido ese mismo día: el código no contiene ningún monitor de fallos, espacio en disco o éxito de las copias de seguridad; las únicas apariciones de Telegram están en una biblioteca de proveedor que nadie llama, srv/cron_status.php solo escribe un valor de estado en Redis y system_alerts está vacía. Hasta el 17/08/2026, las TOM prometían lo contrario ("en caso de fallo del sistema, el administrador recibe una notificación automática"). Era una garantía que el código no cumple; se corrigió ese mismo día. Resuelto el 19/08/2026: srv/backup-crypt.sh registra ahora el resultado de cada ejecución en un archivo de estado, y srv/cron_status.php comprueba, además de los cinco componentes existentes, el éxito de la copia de seguridad, el espacio libre de los volúmenes del sistema y de las copias y –como vigilancia jurídica, no operativa– el umbral del art. 37. Cada comprobación fallida se comunica por correo electrónico como máximo una vez al día. El supervisor consulta la última copia de seguridad satisfactoria y no el último intento: un script que se inicia cada noche y se interrumpe cada noche tiene una marca de tiempo reciente, pero ninguna copia de seguridad; así fue precisamente como la actualización de GeoIP pasó inadvertida durante cinco días. Persiste un límite que se declara expresamente: el supervisor se ejecuta en la máquina que supervisa y no puede comunicar el fallo total de esa máquina; no había ninguna comprobación externa de disponibilidad. Desde el 02/10/2026, una segunda máquina de la misma ubicación comprueba la aplicación cada minuto (TOM, apartado 5); sigue sin detectar un fallo de la conexión a Internet. Las TOM se armonizaron ese mismo día (versión 1.2), de modo que la corrección no se limita a este documento.
• No se ha recabado la opinión de los interesados. Motivo: frente a los usuarios finales observados, MousePlayer actúa exclusivamente como encargado del tratamiento y no tiene un canal propio para dirigirse a ellos; cualquier contacto pasaría por los sitios web de los Clientes y constituiría por sí mismo un tratamiento de sus datos para una finalidad nueva. En su lugar, los intereses de los interesados se tienen en cuenta indirectamente: mediante el control de consentimiento, que no graba nada sin una señal, el enmascaramiento de entradas y los plazos de supresión. Sigue siendo posible recabar su opinión en cuanto exista un canal que permita llegar a ellos sin volver a capturarlos para esa finalidad. (decisión del responsable del tratamiento, 17/08/2026)

9. Riesgo residual y consulta previa conforme al art. 36

El art. 36(1) exige consultar previamente a la autoridad de control cuando una EIPD indique que el tratamiento entrañaría un alto riesgo si no se toman medidas para mitigarlo. Por tanto, la comprobación no consiste en si se identificaron riesgos altos —se identificaron dos muy altos—, sino en si persiste un riesgo alto una vez aplicadas las medidas del apartado (d). Hay que responder con sinceridad a esa pregunta para cada uno de los dos.

R5, la copia externa diaria, podía subsanarse por medios ordinarios y se ha subsanado. La capa de cifrado anterior a la subida está en vigor desde el 11/08/2026; los datos heredados sin cifrar del proveedor se eliminaron el 12/08/2026 y, desde el 05/09/2026, la copia se conserva en una región europea al amparo del Google Cloud Data Processing Addendum. Por tanto, está respondida la cuestión del fundamento de la transferencia diaria. Tras la nueva calificación del 17/09/2026, R5 se sitúa en medio. La condición de la evaluación (retirar los scripts antiguos) se cumplió el 16/10/2026; la nueva calificación de R5 corresponde al responsable del tratamiento.

R1, las categorías especiales en el contenido de páginas, no puede subsanarse por completo. El sistema no puede saber qué muestra la página de un cliente y ninguna lógica de enmascaramiento cambia eso. Las medidas pueden invertir el valor por defecto para que, ante un fallo, se obtenga una grabación poco útil en lugar de ilícita, además de una política contractual de sectores y una confirmación del cliente. Esto reduce sustancialmente el riesgo. No lo elimina, porque un cliente todavía puede habilitar el texto de una página que más adelante muestre algo sensible.

Respecto del art. 36, la conclusión tiene dos partes que no deben fundirse. Formalmente, la obligación de consultar recae en el responsable del tratamiento - el cliente que opera el sitio web, no MousePlayer, que es el encargado del tratamiento de los datos de visitantes que entrañan el alto riesgo. MousePlayer no puede consultar en lugar de un cliente, y un cliente no puede delegar la decisión. Lo que MousePlayer debe hacer conforme al art. 28(3)(f) es facilitar al cliente los hechos que le permitan tomarla; para eso sirven los apartados (a) y (c) de este documento.

En cuanto al fondo: no procede la consulta previa si las medidas de 8.3 se implementan antes del inicio en producción, porque entonces el riesgo residual cae por debajo del umbral al que se refiere el art. 36. Procede la consulta previa en una situación concreta, que es una decisión y no un accidente: si el operador decide no invertir el valor por defecto del contenido de páginas mientras sigue admitiendo clientes de los sectores sanitario, jurídico, financiero o público. En ese caso, el riesgo residual permanece alto por elección y se aplica el art. 36(1) en sus propios términos. Una segunda situación que figuraba aquí hasta el 17/09/2026 —mantener la copia externa diaria sin un instrumento de transferencia acreditado— ya no existe desde el 05/09/2026 (R5).

Corresponde añadir otro punto porque es fácil perderlo de vista. El art. 36 no es una sanción y consultar no es una admisión. Es el mecanismo que el Reglamento prevé precisamente para la situación de este sistema: una técnica realmente útil cuyo riesgo residual depende de un factor que el operador no puede controlar por completo. Si un responsable pretende continuar con un riesgo residual alto, la consulta es la vía lícita para hacerlo.

10. Revisión, versión y aprobación

El art. 35(11) exige al responsable del tratamiento revisar si el tratamiento se realiza de acuerdo con esta evaluación, al menos cuando cambie el riesgo. Aquí hay tres acontecimientos que cambian sustancialmente el riesgo y cada uno debería desencadenar una repetición de la evaluación, no una mera lectura: el primer cliente de un sector regulado; la primera activación de la exportación a BigQuery o de un webhook; y el momento en que los usuarios finales observados superen el umbral recogido en el apartado 3.

La evaluación se basa esencialmente en mediciones realizadas el 10/08/2026 y el 11/08/2026 en el sistema de desarrollo; se aprobó el 17/08/2026 y se ha actualizado desde entonces, por última vez el 16/10/2026 mediante una conciliación con el estado técnico. Siguen abiertos los marcadores de los apartados 1, 3 y 4 y de R12, que solo puede completar el responsable del tratamiento, así como la nueva calificación de los riesgos cuyas causas se han eliminado total o parcialmente desde el examen (R2, R3, R9, R10); la conclusión sobre el riesgo residual del apartado 9 está sujeta a las medidas aún pendientes de 8.3.

Elemento	Entrada
Responsable y encargado del tratamiento	LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82 lok. 301, 90-437 Lodz, Poland - NIP PL7252266190 - office@mouseplayer.com
Delegado de protección de datos	No designado. Véase el apartado 3 para el análisis del art. 37 y la recomendación.
Documentos relacionados	Registros de actividades de tratamiento conforme al art. 30(1) y al art. 30(2), medidas técnicas y organizativas, lista de subencargados, acuerdo de tratamiento de datos e información de privacidad
Base de los hechos	Código fuente, esquema de la base de datos, recuentos de filas, lista de procesos, valores de configuración y archivos de registro del sistema de desarrollo, del 10/08/2026 al 11/08/2026, actualizados hasta el 16/10/2026
Versión y fecha de aprobación	Aprobado por Lukas Wójcik, propietario, el 17/08/2026. No se obtuvo asesoramiento externo en protección de datos. Se revisa anualmente y cada vez que cambia el tratamiento; las versiones fechadas se conservan en el control de versiones bajo ai/cms/. Añadido el 17/09/2026 por instrucciones del propietario: nueva calificación de R5 (apartados 5.4, 6, 7, 8.3 y 9). Añadido el 16/10/2026: conciliación con el estado técnico (cabecera, apartados 1, 3, 4, 5, 7, 8 y 10); niveles de riesgo sin cambios; pendiente nueva calificación de R2, R3, R9 y R10 por el responsable del tratamiento. Añadido el 16/10/2026 (segunda pasada): plazos y duración del bloqueo automático como valores de configuración en lugar de números fijos, bases jurídicas de las solicitudes de soporte y los comentarios, custodia de las claves y accesibilidad de los scripts antiguos de copias de seguridad (R5), plazo para informar al Cliente; niveles de riesgo sin cambios; pendiente nueva calificación de R5 por el responsable del tratamiento. Añadido el 16/10/2026 (tercera pasada): constancia de la retirada de los scripts antiguos de copias de seguridad (R5), armonización de las afirmaciones sobre protección de acceso de la base de datos y Redis (R10); niveles de riesgo sin cambios; pendiente nueva calificación de R5 por el responsable del tratamiento.