Medidas técnicas y organizativas (TOM)

1. Ámbito y finalidad

Este documento describe las medidas técnicas y organizativas (TOM) que MousePlayer aplica para garantizar un nivel de seguridad adecuado al riesgo, de conformidad con el art. 32 del RGPD. Se aplica a todo tratamiento de datos de Usuarios Finales realizado por cuenta de un Responsable del tratamiento (Cliente).

Operador del servicio: LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82 lok. 301, 90-437 Łódź, Poland · NIP PL7252266190.

2. Confidencialidad – Control de acceso

2.1 Acceso físico

El servicio funciona en hardware de nuestra propiedad y operado por nosotros, situado en Łódź, Polonia. En el propio funcionamiento no interviene ningún centro de datos, nube ni proveedor de alojamiento de terceros. Los servidores se operan internamente, en instalaciones cerradas dentro de Polonia. El acceso corresponde exclusivamente al responsable del tratamiento. La sala está cerrada con llave y bajo videovigilancia; ninguna otra persona — incluidos los arrendadores o los servicios de limpieza — tiene acceso (declaración del responsable del tratamiento, 17/08/2026). La dirección exacta no se indica aquí deliberadamente.

2.2 Acceso al sistema

• El acceso a la aplicación requiere una cuenta de usuario individual con contraseña; las contraseñas se almacenan como hashes con sal, nunca en texto claro.
• Las interfaces administrativas están separadas de la aplicación para clientes y solo son accesibles para superadministradores; la autorización se comprueba en el servidor.
• Las solicitudes de la interfaz web con sesión iniciada que modifican el estado están protegidas mediante tokens CSRF; las interfaces de programación se autentican con sus propias claves.
• La administración del servidor se realiza mediante SSH con autenticación basada en claves.
• El inicio de sesión puede protegerse opcionalmente con un segundo factor (códigos de un solo uso basados en el tiempo conforme a RFC 6238). El secreto se almacena cifrado y los códigos de recuperación solo como hashes; un código ya utilizado no se acepta por segunda vez y los intentos fallidos repetidos bloquean temporalmente el segundo factor de la cuenta.
• Cada inicio de sesión se registra individualmente (login_sessions). El titular de la cuenta ve la lista en los ajustes y puede revocar inicios de sesión individuales o todos los demás; la revocación también finaliza una sesión en curso y un token almacenado para recordar el inicio de sesión. Un cambio de contraseña finaliza todos los demás inicios de sesión. Si se inicia sesión en una cuenta desde un dispositivo desconocido (huella del navegador, sistema operativo, tipo de dispositivo y rango de red /24 o /48 de la dirección IP), el titular recibe un correo electrónico.

2.3 Acceso a los datos (autorización)

• Un modelo de roles (owner, admin, viewer) regula lo que un usuario puede ver y hacer dentro de un espacio de trabajo. La eliminación y el uso compartido están restringidos a owner y admin; la restricción se aplica en el servidor, no solo en la interfaz.
• Cada consulta de datos de sesión está vinculada al espacio de trabajo de la cuenta solicitante. No se puede acceder a una grabación de otro cliente ni siquiera conociendo su identificador.
• Los enlaces para compartir (véase 4.3) son la única forma de acceder a una grabación sin una cuenta. Los crea deliberadamente un usuario autorizado, pueden revocarse y pueden tener una fecha de caducidad.

2.4 Separación

• Los datos de los clientes se separan lógicamente por espacio de trabajo y proyecto (canal). Cada vía de lectura y escritura incorpora esta restricción.
• El desarrollo y la producción funcionan en instalaciones separadas con bases de datos separadas.

3. Seudonimización y minimización de datos

• No se realiza ningún tratamiento antes del consentimiento. El script de seguimiento no realiza ninguna identificación ni almacenamiento, no instala ninguna cookie ni establece ninguna conexión de red hasta que existe una señal de consentimiento. La ausencia de señal se considera una negativa, no un permiso.
• Global Privacy Control. Una señal GPC del navegador se respeta en todo el mundo y prevalece sobre cualquier otra señal.
• Identificadores seudónimos. Los visitantes se distinguen mediante tokens generados aleatoriamente. El propio Servicio no recoge nombres, direcciones de correo electrónico ni números de teléfono.
• Direcciones IP. La dirección IP completa de un visitante se utiliza en la memoria de trabajo del servidor de grabación para establecer la conexión, determinar el país, la ciudad y el proveedor de red y defender frente a abusos; solo se escribe en la base de datos de forma truncada (para IPv4 a.b.c.xxx), y el panel nunca muestra una dirección IP completa de un visitante. Excepciones: para detectar avalanchas de conexiones, una dirección se contabiliza en Redis durante diez segundos; si activa el bloqueo automático, se conserva íntegramente durante un máximo de 24 h como entrada de bloqueo en Redis (mp_autoban:), y esta instancia de Redis escribe en disco mediante AOF. Los accesos a través de enlaces para compartir se registran con la dirección IP completa (share_views) y se eliminan junto con el enlace.
• Ocultación de datos en URL. Los valores de los parámetros que suelen contener datos personales o credenciales de acceso (por ejemplo, ?email=, ?token=, ?code=) se eliminan antes del almacenamiento – tanto en la cadena de consulta como después de #, donde los servicios de inicio de sesión colocan credenciales de acceso (por ejemplo, #access_token=). Se conservan las rutas de las aplicaciones de página única y los anclajes internos de la página.
• Entradas de formularios – tres niveles, el más estricto de forma predeterminada. El enmascaramiento completo (la opción predeterminada) sustituye cada carácter de cada entrada antes de salir del navegador. El enmascaramiento selectivo mantiene completamente enmascarados los nombres, las direcciones, el correo electrónico, el teléfono, los campos de pago y las áreas de texto libre, y en el resto de los campos sustituye solo los dígitos, de modo que los términos de búsqueda siguen siendo utilizables. El modo sin enmascaramiento graba las entradas tal como se escriben. Los dos niveles menos estrictos no son de autoservicio: cada uno requiere nuestra aprobación por escrito para esa propiedad concreta, registrada con la hora y la persona que la concede. La aplicación es del lado del servidor – un proyecto cuyo nivel almacenado supere el autorizado queda limitado al nivel autorizado antes incluso de que el valor llegue al navegador, por lo que establecer directamente el campo no consigue nada.
• El mínimo que ninguna aprobación rebaja. Los campos reconocidos como contraseñas o datos de pago permanecen completamente enmascarados en todos los niveles. El reconocimiento lee el nombre, el id, el tipo y el atributo autocomplete del campo y abarca términos en inglés, alemán y polaco. Nada de esto alcanza al contenido que el propio sitio web muestra en la página; las regiones marcadas con data-mp-mask se excluyen por completo de la grabación.
• Lista de exclusión. El Responsable del tratamiento puede excluir rutas enteras (por ejemplo, páginas de pago o de cuenta) de la grabación. La exclusión se aplica en el servidor y también cuando una aplicación de página única navega a una ruta excluida sin abrir una conexión nueva.

4. Integridad – Control de transferencia y entrada

4.1 Transporte

• Las conexiones desde internet están cifradas con TLS; TLS termina en nginx en el servidor. Las solicitudes sin cifrar en el puerto 80 se redirigen a HTTPS. El script de seguimiento se conecta mediante WSS de forma predeterminada (/mp_wss/). Si WebSocket no llega a conectarse, recurre a un túnel HTTP mediante HTTPS (/mp_wst) que pasa por las mismas comprobaciones del lado del servidor; las capturas de página muy grandes se cargan mediante HTTPS con un token firmado y de duración limitada (/mp_dom), y un endpoint de medición contabiliza las conexiones WebSocket fallidas sin ningún identificador de visitante (/mp_wsfail). Detrás de nginx, el servidor WebSocket escucha únicamente en la interfaz de bucle local del servidor, sin TLS.
• Dentro de nuestra propia red local en la misma ubicación, las conexiones con la base de datos (MariaDB) y la caché (Redis) no están cifradas; no se ha configurado el cifrado de transporte para estas conexiones. El acceso a ambas está restringido y solo son accesibles desde nuestra propia red local (sin reenvío de puertos); la instancia de Redis de la aplicación escucha únicamente en la interfaz de bucle local.
• Los certificados se renuevan automáticamente. La comprobación realizada cada minuto desde un segundo equipo (véase la sección 5) detectaría un certificado caducado de la aplicación, ya que consulta mediante HTTPS con verificación del certificado; no hay una supervisión separada de la vigencia de los certificados.

4.2 Control de entrada

• Las actuaciones administrativas se registran en un registro de auditoría con la cuenta, la hora y la actuación.
• Cada cambio del estado de consentimiento se escribe como un registro propio, junto con su fuente (API explícita, Consent Mode, TCF, adaptador CMP, GPC), para que siga siendo verificable el estado en el momento de la grabación.

4.3 Transferencia ulterior

• El script de seguimiento transmite exclusivamente a la infraestructura propia de MousePlayer. No se contacta con ningún tercero durante la grabación normal.
• Las interfaces opcionales (webhooks, BigQuery, sistemas de relaciones con clientes, marketing por correo electrónico y tickets, hojas de cálculo y almacenamiento de objetos, interfaces de conversión de redes publicitarias) las configura el Responsable del tratamiento; se dirigen a sistemas que elige el Responsable del tratamiento, están inactivas salvo que este las habilite y transmiten elementos individuales; solo la exportación a BigQuery puede incluir también, en el plan Enterprise y a petición, los eventos sin procesar de la grabación (mouse_events). Cuando el Responsable del tratamiento activa un puente hacia una herramienta que él mismo ha incrustado en su página (como chat, seguimiento de errores o análisis web), el script entrega en el navegador elementos individuales, como el enlace a la grabación, a esa herramienta; el propio script de la herramienta los transmite a su proveedor. Los destinatarios no son subencargados de MousePlayer.
• Un modelo de lenguaje formula los textos generados en nuestros propios equipos con tarjeta gráfica, en la misma red local y en la misma ubicación que el servidor. Estos obtienen los resultados calculados mediante HTTPS, con cada solicitud firmada con su propio secreto; la propia grabación nunca les llega y no se envía nada a un servicio externo de IA – ni siquiera mientras uno de esos equipos está fuera de servicio por mantenimiento: los trabajos esperan entonces y la interfaz muestra la versión calculada.
• Los enlaces para compartir transfieren datos únicamente a quien tenga el enlace. El Responsable del tratamiento decide si crea uno.

5. Disponibilidad y resiliencia

• Una copia de seguridad completa de la base de datos, del directorio de la aplicación y – desde el 06/10/2026 – del archivo de grabaciones se crea a diario a las 03:00; hasta el 11/08/2026 se ejecutaba a las 02:00.
• Conservación local de las copias de seguridad: 7 días. La copia local se conserva sin cifrar en una unidad conectada; el cifrado se realiza cuando la copia se transfiere fuera de la ubicación. Los volcados sin cifrar del período anterior al cambio se eliminaron de allí el 12/08/2026, de modo que la carpeta local solo contiene ahora los volcados realizados desde el cambio y se les aplica esa conservación. Además de la copia local, la copia de seguridad diaria se transfiere a una ubicación externa – desde el 05/09/2026 a un bucket de Google Cloud Storage en la región europe-central2 (Varsovia); antes, a una cuenta privada de Google Drive; las copias allí conservadas se eliminaron el 06/09/2026, tras verificarse una restauración desde el nuevo destino. Conservación allí: copias diarias durante 7 días, copias semanales (los domingos) durante 364 días. Ambas cifras son un ajuste, no una constante en un script: la copia de seguridad las lee de la misma fila de la configuración que cita esta frase, por lo que la declaración publicada y el comportamiento no pueden divergir. La copia contiene la base de datos completa. Al cabo de 7 días, los eventos de una grabación se trasladan de la base de datos a un archivo. Desde el 06/10/2026, este archivo forma parte de la copia de seguridad diaria; antes no se incluía en las copias de seguridad y las grabaciones de más de 7 días no tenían copia de seguridad. El archivo reside en el mismo disco que el sistema; la copia local en una unidad separada y la copia externa protegen frente al fallo de ese disco. Desde el 11/08/2026 se cifra en nuestro propio servidor antes de la transferencia (rclone crypt); los nombres de archivos y directorios también se cifran, de modo que el proveedor solo conserva bloques sin significado discernible. Las claves se conservan en dos archivos de nuestro propio servidor, que solo su propietario puede leer y escribir (modo de archivo 600); el proveedor no las tiene y no puede leer el contenido. Se ha verificado el descifrado de una copia de ese tipo. La anterior carpeta de destino sin cifrar, que contenía las copias completas anteriores al 11/08/2026, se eliminó el 12/08/2026. Desde el 19/08/2026 se supervisa automáticamente el éxito de la transferencia. La copia de seguridad escribe su resultado en un archivo de estado y el supervisor consulta la última ejecución satisfactoria en lugar de la última ejecución – un script que se inicia todas las noches y se interrumpe todas las noches tiene una marca de tiempo reciente y ninguna copia de seguridad. Cuando no se haya producido ninguna ejecución satisfactoria durante más tiempo que el plazo configurado (36 horas de forma predeterminada, lo que permite exactamente una ejecución diaria omitida), se envía una advertencia por correo electrónico, como máximo una vez al día.
• Los datos eliminados en el sistema activo permanecen en las copias de seguridad hasta que caduque la copia correspondiente – como máximo 364 días después de la supresión permanente; después ya no están contenidos en ninguna copia de seguridad. Esta es una consecuencia inevitable de tener copias de seguridad; las solicitudes de supresión ejecutadas a través de la administración retiran los datos del tratamiento de inmediato (archivados, ocultos, ya no se graban) y los suprimen de forma permanente al cabo de 30 días como máximo, sin esperar cuando se solicite expresamente; una solicitud presentada en la página de datos /my-data se ejecuta sin archivo previo, por regla general en cuestión de minutos. No se realiza ninguna supresión selectiva dentro de una copia de seguridad: una copia es un único archivo sellado cuya finalidad es ser una imagen fiel de un momento concreto, y abrirlo, modificarlo y volver a sellarlo destruiría esa propiedad y la posibilidad de demostrar que nadie lo ha manipulado. Las copias de seguridad no tienen otra finalidad que restaurar el sistema tras una pérdida; no se hacen búsquedas en ellas, no se analizan ni se comunican a terceros. Cuando se restaura una copia de seguridad, las solicitudes de supresión registradas para los usuarios finales se ejecutan de nuevo antes de que el sistema vuelva a estar en servicio – el registro de solicitudes sobrevive a la supresión precisamente para que esta pueda repetirse. Para una cuenta de cliente eliminada, la situación es distinta: su eliminación no deja deliberadamente ningún registro que la identifique, por lo que una copia restaurada contendría una cuenta eliminada después de la fecha de esa copia.
• Supervisión. Un proceso supervisor comprueba a intervalos de un minuto la base de datos y el trabajador de eventos, el servidor WebSocket, la interfaz web, la actualización de la base de datos de geolocalización, la ejecución diaria de eliminación, el éxito de la copia de seguridad y el espacio libre en disco del volumen del sistema y del volumen de copias de seguridad. Cada resultado se escribe en el estado compartido y se muestra en el área de administración, y cada comprobación fallida se comunica por correo electrónico como máximo una vez al día – un supervisor que envía correos cada minuto acaba desactivándose y entonces tampoco informa ya del fallo real. Antes del 19/08/2026 solo se comprobaban los cinco primeros elementos y únicamente la ejecución de eliminación generaba una alerta; el resto era manual y este documento así lo indicaba.
• Lo que esta supervisión no puede hacer, declarado en lugar de insinuado: se ejecuta en el equipo que supervisa, por lo que no puede informar del fallo total de ese equipo. Desde el 02/10/2026, un segundo equipo en la misma ubicación comprueba cada minuto si la aplicación acepta grabaciones – base de datos, caché, servidor WebSocket, procesos en segundo plano, cola y script de seguimiento – y alerta por Telegram después de dos comprobaciones fallidas consecutivas. Accede al servidor a través de la red local: no detecta un fallo de la conexión a internet, del router o del DNS, que sigue siendo advertido por una persona, no por un monitor. Objetivo de tiempo de recuperación (RTO): no más de 24 horas. Pruebas de restauración: la recuperación desde la copia de seguridad externa se probó el 05/09/2026, el 06/09/2026 y el 07/10/2026 (restauración completa de los datos); no se ha establecido un calendario fijo.
• Sobrecarga y ataques. nginx limita las solicitudes y conexiones simultáneas por dirección; fail2ban rechaza durante una hora en el cortafuegos una dirección que supere el límite de forma persistente. El servidor WebSocket bloquea automáticamente durante 24 h las direcciones que generan avalanchas de conexiones; los bloqueos establecidos manualmente por el operador se conservan en la base de datos.

6. Procedimientos de revisión periódica

• Las medidas de este documento se revisan cuando cambia el tratamiento y, en los demás casos, con la periodicidad indicada en la sección 10.
• Una comprobación de instalación verifica para cada proyecto del Cliente si el script está incrustado correctamente y si llegan grabaciones con un registro de consentimiento. Los proyectos sin dicho registro se señalan en el panel.
• Actualmente no se encargan pruebas de penetración externas ni se dispone de certificaciones de seguridad. Se declara aquí en lugar de omitirse: un documento TOM que guarde silencio al respecto se lee como si tales pruebas existieran.
• El número de usuarios finales observados en el conjunto de todos los clientes se mide a diario y se compara con el umbral a partir del cual debe repetirse la evaluación conforme al art. 37 del RGPD (100000 al mes; véase la sección 9 del Registro de actividades de tratamiento). Esa magnitud viene determinada por el tráfico de los sitios web de los clientes y no por nosotros, por lo que dejarla sin supervisión significaría que la evaluación quedase desactualizada silenciosamente. El mismo proceso supervisa la repetición anual.

7. Subencargados

MousePlayer recurre a subencargados únicamente con la autorización general por escrito del Responsable del tratamiento conforme al DPA. La lista actual, incluida la finalidad, las categorías de datos y el lugar del tratamiento, se publica por separado:

• Lista de subencargados

Ningún tercero participa en la propia grabación: el script de seguimiento transmite exclusivamente a la infraestructura propia de MousePlayer. Para los datos de los usuarios finales existe un destinatario más allá de esta: una copia externa diaria de la base de datos completa y del archivo de grabaciones — incluidas las grabaciones de sesiones — se almacena en Google (Google Cloud Storage, bucket en Varsovia). Allí se conserva cifrada desde el 11/08/2026: el cifrado se realiza en nuestro propio servidor antes de la transferencia (rclone crypt) y abarca también los nombres de archivos y directorios; MousePlayer conserva las claves. Google no las recibe y no puede leer el contenido, pero sigue siendo un subencargado — el cifrado es una medida técnica, no un cambio de rol. La anterior carpeta de destino sin cifrar, que contenía las copias anteriores al 11/08/2026, se eliminó el 12/08/2026.

8. Conservación y supresión

La conservación de las grabaciones de sesiones depende del nivel de suscripción del Cliente:

• Gratis: 7 días · Small: 30 días · Business: 90 días · Enterprise: según lo acordado contractualmente de forma individual.
• Tras un cambio a un plan inferior, se aplica un período de gracia de al menos 30 días durante el cual se mantiene la conservación más larga del nivel anterior. Un cambio a un plan superior nunca acorta la conservación.
• El registro de la aplicación se suprime al cabo de 60 días, los registros del servidor web al cabo de 14 días y los registros de seguridad al cabo de 72 horas.
• Para las sesiones identificadas como acceso automatizado, la grabación se elimina al cabo de 1 día y la sesión se suprime al cabo de 14 días. Para una cuenta del Plan Gratuito marcada como sospechosa de abuso, solo se graba una parte de las visitas y las grabaciones se eliminan al cabo de 1 día.
• El registro de entrega de las integraciones se suprime al cabo de 30 días. Se encuentra en Redis y no en la base de datos y caduca allí por sí solo; la lista también está limitada a 25 entradas por proyecto. Por tanto, tampoco forma parte de la copia de seguridad diaria.
• La supresión al finalizar un plazo de conservación se ejecuta automáticamente y sin supervisión; no necesita activarse manualmente.

Al finalizar la cuenta del Cliente, todos los datos personales asociados se suprimen en un plazo de 30 días, salvo que el Derecho de la Unión o de los Estados miembros exija seguir conservándolos. El Cliente inicia la eliminación en los ajustes de la cuenta; no se requiere ninguna solicitud por correo electrónico. Primero se archiva la cuenta: el acceso termina de inmediato, ya no se graba ni se muestra nada y, durante 30 días, aún podemos restaurarla a petición del Cliente si la eliminación fue un error. Transcurrido ese plazo, se suprime de forma permanente; al iniciar la eliminación, el Cliente también puede elegir la supresión permanente inmediata. Un proyecto o un espacio de trabajo que el Cliente elimina también se archiva primero durante 30 días y puede restaurarse en el panel durante ese tiempo. Se conservan deliberadamente tres cosas, porque la ley lo exige o porque documentan una decisión y no a una persona: el registro de aceptación de estos documentos, el registro de seguridad y de cambios (con la referencia al usuario eliminada) y las solicitudes de soporte. Como excepción, una cuenta del Plan Gratuito que lleve 24 meses sin utilizarse se suprime de forma permanente, sin archivo previo, 30 días después de un aviso entregado.

Los registros de consentimiento se conservan más allá de la supresión de la propia grabación. No contienen datos de comportamiento, sino solo el hecho, la hora y la fuente de la decisión de consentimiento, y existen para cumplir la obligación de responsabilidad proactiva conforme al art. 5(2) del RGPD.

9. Violación de la seguridad de los datos personales

MousePlayer notifica al Responsable del tratamiento sin dilación indebida y a más tardar en un plazo de 48 horas después de tener conocimiento de una violación de la seguridad de los datos personales que afecte a los datos del Responsable del tratamiento. La notificación contiene la información que el Responsable del tratamiento necesita para cumplir sus propias obligaciones conforme al art. 33 del RGPD.

Dirección para comunicar problemas de seguridad: office@mouseplayer.com

10. Estado y versión

• Versión: 1.5 · Entrada en vigor: 16/10/2026 · Próxima revisión: 19/08/2027 · sustituye a la versión 1.4 del 07/10/2026. Cambios: la sección 2.2 menciona el inicio de sesión en dos pasos, la lista de inicios de sesión activos con revocación y la alerta de inicio de sesión; la sección 2.3 menciona los roles owner, admin y viewer; la sección 3 menciona las excepciones para direcciones IP completas; la sección 4.1 describe las vías de transmisión del script y las conexiones sin cifrar de la red local en lugar de afirmar que no hay ninguna vía sin cifrar; la sección 4.3 menciona las demás interfaces; la sección 5 registra que el archivo de grabaciones se incluye en las copias de seguridad desde el 06/10/2026 y menciona las pruebas de restauración realizadas y los límites de sobrecarga; la sección 8 añade plazos de conservación y la eliminación de cuentas inactivas. Además, la sección 2.2 indica el estado del inicio de sesión SSH y la duración del bloqueo automático se indica como ajuste. La versión 1.4 sustituyó a la versión 1.3 del 17/09/2026. Cambios: las secciones 5 y 8 indican que la supresión archiva primero los datos – retirados del tratamiento de inmediato – y los suprime de forma permanente al cabo de 30 días como máximo. La versión 1.3 sustituyó a la versión 1.2 del 19/08/2026. Cambios: la sección 4.3 menciona los equipos que ejecutan el modelo de lenguaje para los textos generados, cómo llegan allí los resultados y qué sucede durante el mantenimiento. La versión 1.2 sustituyó a la versión 1.1 del 11/08/2026. Cambios: la sección 5 indica la conservación de las copias de seguridad como ajuste y no como constante, describe qué sucede con las supresiones al restaurar y registra que ahora se supervisan automáticamente el éxito de las copias de seguridad y el espacio en disco; la sección 6 añade la medición del umbral del art. 37.
• En caso de divergencia entre las versiones lingüísticas, prevalece la versión en inglés.