Medidas técnicas y organizativas

Este documento se publica en varios idiomas. En caso de discrepancia entre las versiones lingüísticas, prevalecerá la versión polaca.

Versión 1.1 · Última actualización: 22 de octubre de 2026

Medidas conforme al art. 32 RGPD con las que LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Polonia, protege el servicio formexposed. Esta página forma parte del Contrato de encargo del tratamiento como Anexo 2.

1. Ámbito y principio

Las medidas se aplican a todos los datos que trata el servicio: a los datos que tratamos por cuenta de nuestros Clientes (descritos en el Contrato de encargo del tratamiento) y a los datos de los que somos nosotros mismos responsables, como las cuentas de cliente y los registros. No existen niveles de protección distintos para unos y otros; lo que protege la cuenta protege también los datos tratados como encargado.

Estructura conforme al art. 32(1) RGPD. La seudonimización y el cifrado (letra a)) se tratan en la sección 4; la confidencialidad, integridad, disponibilidad y resiliencia permanentes de los sistemas (letra b)), en las secciones 3, 5, 6 y 7; la capacidad de restaurar la disponibilidad de forma rápida en caso de incidente (letra c)), en la sección 7.1; el proceso de verificación, evaluación y valoración regulares de la eficacia (letra d)), en la sección 9. Seleccionamos las medidas sobre la base de los riesgos descritos en nuestra Evaluación de impacto relativa a la protección de datos, teniendo en cuenta el estado de la técnica y los costes de aplicación.

Principio: medido, no pretendido. Aquí solo se indica lo que se ha aplicado efectivamente en el código o en el funcionamiento. Lo que está previsto pero aún no se ha aplicado se enumera expresamente como «previsto» en la sección 10. Una medida que no figure aquí no existe tácitamente.

Los nombres de las máquinas, las direcciones internas, los puertos, los nombres de usuario y las versiones de software no se indican deliberadamente. No ayudan a nadie a evaluar las medidas, pero sí a quien quiera eludirlas. Quien los necesite para una auditoría conforme al Contrato de encargo del tratamiento los recibirá en el marco de dicha auditoría bajo confidencialidad, en la medida en que sean necesarios para la auditoría.

2. Estructura del servicio

El servicio funciona en dos servidores propios del prestador en Polonia, ubicados en la misma red interna:

Servidor web con base de datos. Sirve la aplicación, aloja la base de datos, envía las notificaciones y realiza las copias de seguridad de los datos. Es el único configurado para aceptar solicitudes desde internet.
Servidor de escaneo. Realiza las comprobaciones de sitios web de terceros y propios en un navegador y ejecuta el modelo de lenguaje que clasifica formularios concretos y añade código en “Fix it for me”. No está configurado para aceptar solicitudes desde internet, sino que obtiene él mismo sus trabajos del servidor web y le devuelve los resultados.

En el funcionamiento no interviene ningún proveedor de alojamiento, centro de datos ni nube, y nada se envía a un servicio externo de IA. Qué terceros reciben datos se expone en la página Subencargados del tratamiento.

3. Confidencialidad

3.1 Control del acceso físico

Los servidores se encuentran en instalaciones del prestador en Polonia que no están abiertas al público. Solo el titular tiene acceso (según declara el operador). La dirección exacta de la ubicación no se indica aquí deliberadamente.

3.2 Control de acceso: inicio de sesión en el servicio

Las contraseñas solo se almacenan como hash mediante el método estándar de PHP (bcrypt). Si el método estándar cambia, el hash se renueva en el siguiente inicio de sesión. En un intento de inicio de sesión con una dirección desconocida, el servidor calcula igualmente un hash, para que el tiempo de respuesta no revele si existe una cuenta. Del mismo modo, la respuesta a una solicitud de restablecimiento de contraseña no revela ni por su redacción ni por su duración si la cuenta existe; los correos de restablecimiento se envían a la misma dirección como máximo tres veces por hora. Las contraseñas nuevas deben tener al menos diez caracteres y no pueden superar los 72 bytes (UTF-8), porque bcrypt no tiene en cuenta más bytes. Cambiar la contraseña cierra la sesión en todos los demás dispositivos; restablecerla mediante el enlace cierra la sesión en todos los dispositivos, y el enlace solo es válido una vez.
Bloqueo tras intentos fallidos. Los inicios de sesión fallidos se cuentan por dirección IP; tras demasiados en poco tiempo (actualmente ocho en 15 minutos), se bloquea temporalmente el inicio de sesión desde esa dirección. Un inicio de sesión correcto pone a cero este contador. Los intentos se suprimen al cabo de siete días. Además, antes de cada verificación de contraseña se cuenta un intento por cuenta (para una dirección desconocida, por dirección introducida) y por dirección IP, incluidos los correctos: actualmente, como máximo ocho por cuenta desde la misma dirección IP y 80 por dirección IP en 15 minutos; por cuenta y para todas las direcciones en conjunto se aplica un límite considerablemente más alto, contra los intentos distribuidos de adivinar contraseñas. Por tanto, los intentos fallidos desde otra dirección ya no bloquean al titular fuera de su cuenta. Estos contadores solo contienen una clave HMAC, ninguna dirección de correo electrónico ni IP en texto claro, y expiran con su ventana temporal. Si el almacenamiento de contadores no está disponible, el inicio de sesión se rechaza, no se deja pasar. El mismo tipo de límite se aplica a la confirmación de la contraseña antes de cambiar la contraseña o la dirección, activar o desactivar el segundo factor, transferir un espacio de trabajo, la exportación de datos y la eliminación de la cuenta (cinco intentos por cuenta en 15 minutos), a los registros (diez por dirección IP y hora) y a las contraseñas de los portales de cliente (diez intentos por portal y dirección IP, 50 por portal en 15 minutos).
Segundo factor. Cada cuenta puede activar el inicio de sesión con un código de un solo uso conforme a RFC 6238 (TOTP). El secreto correspondiente se almacena cifrado en la base de datos; la clave no se almacena en la base de datos, de modo que un extracto de la base de datos por sí solo no basta. Un código aceptado no es válido una segunda vez. Diez códigos de recuperación se almacenan solo como hash. Los códigos de un solo uso y de recuperación están limitados a diez intentos por cuenta en 15 minutos, también durante la configuración.
Área de administración solo con segundo factor. El área de administración del operador solo se abre para cuentas con el segundo factor activado. La lista de comprobación de la configuración señala toda cuenta de administrador sin segundo factor.
Sesiones. La cookie de sesión no puede ser leída por scripts (HttpOnly), solo se envía por HTTPS (Secure) y no se envía con solicitudes de sitios de terceros que puedan modificar algo (SameSite=Lax). Al iniciar sesión, se crea un nuevo ID de sesión, de modo que un ID introducido previamente deja de ser válido; el servidor no acepta un ID de sesión que no haya emitido él mismo. Cada cuenta ve sus dispositivos con sesión iniciada y puede cerrar la sesión en ellos individualmente.
«Mantener la sesión iniciada» es opcional y es válido durante 30 días, pero no para cuentas con derechos de administración; estas siempre inician sesión con contraseña y segundo factor. El token consta de dos partes; la parte de verificación solo se almacena como hash en la base de datos. Cada uso lo sustituye por uno nuevo y, incluso con solicitudes simultáneas, cada token solo es válido una vez, de modo que un token robado se detecta a más tardar en la siguiente visita legítima.
Enlaces en correos electrónicos. Los enlaces para confirmar la dirección y restablecer la contraseña solo se almacenan como hash en la base de datos. El enlace de restablecimiento es válido durante una hora; el enlace para confirmar un registro, durante 72 horas; el enlace para confirmar una dirección modificada, durante 24 horas. Si se cambia la dirección de correo electrónico, un enlace de restablecimiento abierto deja de ser válido.
Interfaces. Las claves de API, los códigos de conexión de las extensiones y los códigos de despliegue solo se almacenan como hash. Las claves de API solo pueden utilizarse un número limitado de veces por minuto; los códigos de conexión de las extensiones son válidos durante 15 minutos y una sola vez.
Protección contra bots en los formularios públicos (registro, inicio de sesión, contraseña, comprobación, herramienta de cabeceras, opt-out, soporte y contacto): Google reCAPTCHA, que solo se carga al enviar. Solo se acepta una respuesta válida de Google con una puntuación suficiente para exactamente la acción del formulario; si Google no responde en tres segundos, el envío se rechaza. Los detalles figuran en la Política de privacidad.

3.3 Control de acceso: administración de servidores

El servidor accesible desde internet utiliza un filtro de paquetes para permitir únicamente los servicios que ofrece y bloquea automáticamente las direcciones tras inicios de sesión fallidos repetidos en la administración del servidor.
Los procesos automatizados entre los servidores utilizan sus propias claves con derechos estrictamente limitados. La clave con la que el servidor web despliega nuevas versiones del escáner solo puede ejecutar una lista fija de comandos en el servidor de escaneo y solo puede copiar, en modo de solo escritura, en el directorio del escáner; con ella no es posible un inicio de sesión interactivo, y todo comando rechazado queda registrado. Del mismo modo, el servidor de escaneo solo puede escribir capturas de pantalla en un directorio concreto del servidor web.
El proceso que sirve el sitio web no tiene ni acceso de escritura a la instalación de producción ni una clave para el servidor de escaneo. Un despliegue iniciado en el área de administración solo registra un trabajo, que ejecuta un proceso independiente.
Los secretos, como las credenciales de la base de datos y las claves, se guardan en archivos de configuración fuera del directorio servido y no se copian durante el despliegue. La configuración del servidor web no se distribuye a través de la interfaz web.

3.4 Control de autorizaciones: derechos dentro del servicio

Roles. Cada espacio de trabajo tiene los roles de titular, administrador y lector. Modificar, eliminar, invitar y almacenar credenciales está reservado a titulares y administradores; solo el titular puede cambiar roles y eliminar miembros. Una invitación solo es válida mientras la persona que la envió siga siendo titular o administrador. Los lectores solo ven las direcciones de webhooks y canales de chat abreviadas al host, porque la dirección por sí sola permite publicar en el canal. La comprobación se realiza en el servidor, no solo en la interfaz.
Vinculación al espacio de trabajo. Los dominios y ajustes solo son accesibles para los miembros del espacio de trabajo. Para cada comprobación, el Servicio crea un informe bajo un enlace aleatorio que no puede adivinarse; los resultados y las capturas de pantalla de una comprobación pueden consultarse a través de este enlace sin iniciar sesión, y las capturas de pantalla solo junto con el enlace de su informe. El enlace aparece en la cuenta y en las alertas; quien lo comparte comparte el informe.
Las solicitudes que modifican el estado requieren un token de seguridad por sesión (protección CSRF), que se compara en tiempo constante.
«Ver como cliente». Para el soporte, el operador puede ver la aplicación tal como la ve un Cliente. La vista finaliza al cabo de una hora, bloquea los cambios de contraseña, dirección, segundo factor, dispositivos, suscripción, exportación y eliminación, cierra entretanto el área de administración y queda registrada. Al finalizarla, se cierra por completo la sesión del operador; este solo puede volver al área de administración iniciando sesión de nuevo con contraseña y segundo factor. El Cliente puede verlo en su exportación de datos.
Administración. Solo unas pocas cuentas expresamente autorizadas tienen derechos de administración; todo restablecimiento de un segundo factor por parte de la administración queda registrado.

3.5 Control de separación

Los datos de los clientes están separados lógicamente por espacio de trabajo. Toda ruta de lectura y escritura en el área con sesión iniciada lleva consigo esta vinculación; los informes son además accesibles a través de su enlace (sección 3.4).
El desarrollo y el funcionamiento se ejecutan en instalaciones separadas con bases de datos separadas y usuarios de base de datos separados. El usuario de desarrollo no tiene acceso a la base de datos de producción. Los datos reales de clientes no se copian al entorno de desarrollo; allí trabajamos con datos de ejemplo generados.
Para cada entorno, el escáner tiene sus propias credenciales con derechos únicamente sobre los datos que necesita para sus trabajos. No puede leer cuentas, facturación ni registros.
En el servidor web funcionan también otros servicios del mismo prestador. Tienen sus propias bases de datos y sus propios usuarios de base de datos sin acceso a los datos de este servicio.

4. Cifrado, seudonimización y minimización de datos

4.1 Credenciales para el escaneo tras el inicio de sesión

Para esta función, el Cliente almacena el nombre de usuario y la contraseña de una cuenta de prueba. Son los datos más sensibles del servicio y, por ello, se protegen de forma distinta a todo lo demás:

Al almacenarlos, el servidor web los cifra con la clave pública del servidor de escaneo (ECIES: X25519 con una clave de un solo uso por registro, HKDF-SHA256, AES-256-GCM). La clave privada solo existe en el servidor de escaneo. El servidor web, la base de datos y las copias de seguridad solo contienen texto cifrado; tampoco nosotros podemos leerlo allí.
Cada registro está vinculado criptográficamente a su dominio. Si se traslada a otro dominio, el descifrado falla.
Para un escaneo, el texto cifrado se adjunta al trabajo. El servidor de escaneo lo descifra y transmite las credenciales al contenedor de comprobación únicamente a través de la entrada estándar, nunca como argumento de línea de comandos que sería visible en las listas de procesos. En cuanto el servidor de escaneo lo ha leído, el texto cifrado se suprime del trabajo; un proceso elimina cualquier resto a más tardar al cabo de una hora.
Las credenciales nunca se muestran, nunca se registran, nunca se emiten a través de la API y no se exportan. La interfaz solo muestra el primer carácter y la longitud del nombre de usuario. Al eliminarlas, se sobrescribe el texto cifrado.
Tras el inicio de sesión, el escáner solo lee: sin envíos, sin pruebas activas, sin capturas de pantalla, sin páginas de cierre de sesión, eliminación o cancelación.

4.2 Otros cifrados y hashes

Las contraseñas, los códigos de recuperación, las contraseñas de los portales de cliente, las claves de API, los códigos de conexión y de despliegue, los tokens de «Mantener la sesión iniciada», los ID de sesión de la lista de dispositivos y los enlaces de confirmación y restablecimiento solo se almacenan como hash.
Los secretos del segundo factor se almacenan cifrados (sección 3.2).
No afirmamos que toda la base de datos esté cifrada en reposo. Los valores sensibles se protegen individualmente, como se ha descrito arriba.

4.3 Minimización de datos desde el diseño

Comprobación de entrega: solo se leen las cabeceras y como máximo los primeros 8 KB del texto. En la base de datos solo se guardan la hora, la asignación, en su caso el ID del envío de prueba y el resultado de la comprobación de autenticidad (SPF, DKIM, DMARC), nunca el contenido ni una dirección de remitente completa. El resultado de autenticidad del correo más reciente se conserva con el dominio y lo sobrescribe el siguiente; contiene la dirección IP del servidor de correo remitente y el dominio de correo electrónico del remitente. El correo se elimina del buzón tras su procesamiento correcto; si la recuperación o la eliminación fallan, esto ocurre en la siguiente ejecución correcta.
Comprobaciones: la estructura de los formularios se almacena con nombres de campo, tipos y etiquetas, atributos de obligatoriedad y visibilidad, sin valores; el escáner solo lee durante la comprobación, sin almacenarlos, los inicios de los campos ocultos prerrellenados (hasta 24 caracteres) y de los atributos data (hasta 60 caracteres). Las capturas de pantalla de la comprobación completa no se anonimizan; solo las comprobaciones con navegador ocultan los campos de entrada. Las direcciones de destinatario de los formularios solo se almacenan como dominio. Los envíos de prueba activos solo contienen textos de prueba identificados, sin datos personales.
Las extensiones para WordPress y TYPO3 solo transmiten cifras diarias y características como el inventario de plugins y, en el caso de un plugin de WordPress conectado, también los dominios de los enlaces de mensajes bloqueados para la protección colectiva (activada por defecto); ningún otro contenido, ni nombres, direcciones o direcciones IP de visitantes. Los recuentos opcionales de errores de formulario y de campo están desactivados por defecto.
“Fix it for me”: el código pegado solo se trata durante la solicitud y no se almacena.
Distintivo: la imagen del distintivo en los sitios web de los clientes no establece ninguna cookie ni inicia ninguna sesión.
Las notificaciones operativas al teléfono del operador son textos fijos sin variables, es decir, sin nombres, direcciones ni contenidos. Las notificaciones de error por correo electrónico al operador contienen el texto en bruto del mensaje de error, sin depurar y truncado a 400 caracteres; en casos concretos, puede contener direcciones o enlaces.
Protección colectiva: entre las extensiones de los Clientes solo se comparten dominios de enlaces de spam bloqueado; el intercambio de redes IP está desactivado.
Ubicación: el país de una dirección IP se determina a partir de un archivo de base de datos local; ninguna dirección se envía a un servicio de geolocalización.

5. Protección contra el uso indebido del escáner

El escáner carga páginas de terceros con un navegador real. Sin protección, sería una herramienta con la que alguien desde fuera podría acceder a nuestra red interna u otros destinos no públicos (falsificación de solicitudes del lado del servidor). Por ello existen dos capas independientes y el aislamiento de cada ejecución.

5.1 Ejecución aislada

Cada comprobación se ejecuta en su propio contenedor, que se elimina después. Se ejecuta sin derechos de administrador, sin capacidades adicionales del sistema operativo y sin posibilidad de escalar privilegios. Su sistema de archivos es de solo lectura, salvo pequeñas áreas volátiles.
La memoria, el número de procesos y el tiempo de ejecución están limitados; una ejecución que supera el tiempo se termina.

5.2 Red: dos capas

Primera capa, en el escáner: antes del escaneo y después en cada solicitud del navegador, incluidas redirecciones y contenidos integrados, se comprueba a dónde se resuelve la dirección. Se rechazan las redes privadas, locales, reservadas y de documentación (IPv4 e IPv6), así como los puertos distintos de los habituales en la web. El navegador no permite service workers, y las conexiones WebSocket se cierran, porque ambos podrían eludir esta comprobación.
Segunda capa, en la red: los contenedores se ejecutan en su propia red. Las reglas del cortafuegos solo permiten desde allí conexiones a internet en puertos web; se bloquean las conexiones hacia redes privadas, incluida nuestra red interna con el servidor web y la base de datos. Las excepciones que requiere el propio proceso de comprobación se limitan a lo necesario y se describen en nuestra documentación interna. Esta capa surte efecto también si un nombre se resuelve de forma distinta solo después de la primera comprobación.

5.3 Solicitudes realizadas por el servidor web

Cuando el propio servidor web solicita direcciones de terceros —para la acreditación del control del dominio, para la herramienta de cabeceras, para la búsqueda de archivos expuestos, para las solicitudes de pulso, para las consultas RDAP y la comprobación de certificados, para los webhooks y las alertas de chat y para el segundo punto de control opcional—, se aplican las mismas reglas: solo protocolos web, en los puertos web habituales (webhooks y alertas de chat solo por HTTPS en el puerto estándar), solo direcciones públicas, conexión únicamente a exactamente la dirección comprobada previamente, de modo que un nombre no pueda redirigirse posteriormente a un destino interno, redirecciones no seguidas en absoluto o seguidas solo manualmente y comprobadas de nuevo cada vez, límites de tiempo breves; para la acreditación del control del dominio, para las solicitudes de pulso y para el segundo punto de control en las comprobaciones con navegador, además, un tamaño de respuesta limitado.

5.4 Lo que el escáner no hace en sitios de terceros

Los envíos de prueba activos (como máximo cinco por comprobación) solo existen para los Clientes en dominios para los que se ha acreditado el control (DNS, metaetiqueta, archivo o extensión); la única excepción son las comprobaciones internas de nuestros propios dominios de prueba y demostración. El nombre de host de un dominio con acreditación del control no puede modificarse, para que la acreditación no pase a otro host. Todo lo demás es pasivo: leer páginas como un visitante.
Las comprobaciones con navegador llegan hasta el momento previo al envío y no desencadenan ningún pedido, pago ni envío.
Los dominios de la lista de opt-out no se comprueban; la supervisión en curso finaliza con la siguiente comprobación programada.

6. Integridad: transmisión e introducción

6.1 Transporte

La aplicación solo es accesible desde internet mediante HTTPS; se indica al navegador que utilice solo HTTPS durante un año (HSTS). Los certificados se renuevan automáticamente.
Otras cabeceras restringen la integración de la aplicación en páginas de terceros, la adivinación de tipos de archivo y el envío de formularios a destinos de terceros. Una política de seguridad de contenidos solo permite ejecutar en la aplicación los scripts que el servidor habilita con la respectiva respuesta; los navegadores actuales no ejecutan scripts ni controladores de eventos inyectados en el HTML.
El buzón de la comprobación de entrega se consulta mediante una conexión cifrada con verificación de certificado.
Los webhooks pueden firmarse con un secreto del Cliente (HMAC-SHA256 con marca de tiempo), para que el destinatario pueda verificar el origen y la integridad. Las solicitudes al segundo punto de control opcional están firmadas y, en las comprobaciones con navegador, también sus respuestas.
Dicho abiertamente: las conexiones dentro de nuestra red interna no están cifradas en su totalidad. Las credenciales para el escaneo tras el inicio de sesión permanecen cifradas en todo momento (sección 4.1).

6.2 Control de introducción y registros

Las acciones importantes en cuentas y espacios de trabajo (como el inicio de sesión, los cambios en dominios, destinos de alerta y derechos, las eliminaciones y los accesos de soporte) se registran en el registro de actividad con cuenta, hora, dirección IP y país, y se suprimen al cabo de 365 días.
Los registros de acceso a las páginas conservados por motivos de seguridad y prevención de abusos se suprimen al cabo de 60 días; los registros de errores, al cabo de 90 días; los contenidos de los correos electrónicos enviados, al cabo de 30 días. Los tokens de acceso en las direcciones solicitadas y en los referentes, como los de los enlaces de informes o portales, solo aparecen enmascarados en los registros de acceso a las páginas.
La aceptación de los documentos contractuales se almacena con la versión mostrada, su suma de comprobación, la hora, la dirección IP y la identificación del navegador.
Los registros probatorios pueden dotarse de un sello de tiempo de una autoridad externa de sellado de tiempo; a esta solo se envía una suma de comprobación del contenido, no el propio contenido.

7. Disponibilidad y resiliencia

7.1 Copia de seguridad

Se realiza una copia de seguridad de la base de datos cada noche. Una copia de seguridad solo recibe su nombre definitivo después de comprobar su contenido: finalización correcta del programa de copia de seguridad, al menos un registro, tantas tablas como tiene la base de datos y la línea final de una ejecución completa. Las copias de seguridad más antiguas solo se eliminan tras una nueva copia correcta.
Cada copia de seguridad se suprime al cabo de 14 días. La ubicación de almacenamiento está fuera de cualquier directorio servido; se rechaza una ubicación dentro del proyecto.
Prueba de restauración: una vez por semana, la copia de seguridad más reciente se carga en una base de datos desechable, se compara tabla por tabla con la de producción y se vuelve a eliminar. El resultado se almacena.
Si falla una copia de seguridad o una prueba, se envía una notificación por correo electrónico y al teléfono del operador.
Recuperación tras un incidente: si la base de datos falla o los datos se corrompen, restauramos la copia de seguridad probada más reciente. Los cambios realizados desde esa copia, por regla general como máximo los de un día, pueden perderse en el proceso; si ha fallado una copia de seguridad, correspondientemente más. Después volvemos a ejecutar las solicitudes de supresión posteriores conocidas (sección 8). No nos comprometemos a ningún tiempo de recuperación concreto.
Límite, dicho abiertamente: actualmente, las copias de seguridad se almacenan en la misma ubicación que la base de datos y no están cifradas por separado. Protegen frente a errores de operación, cambios defectuosos y datos corrompidos, no frente a la pérdida del propio servidor. Está prevista una copia cifrada en una segunda ubicación (sección 10).
Las credenciales para el escaneo tras el inicio de sesión solo figuran en las copias de seguridad como texto cifrado; el secreto del segundo factor, solo de forma cifrada, con una clave fuera de la base de datos.

7.2 Supervisión

Un proceso de estado comprueba cada cinco minutos los componentes del servicio, incluidos la base de datos, la cola y el latido del escáner, que este escribe periódicamente incluso cuando está inactivo. Si falla un componente, se envía una notificación; si se recupera, un aviso de restablecimiento.
Vigilancia cruzada: un proceso de estado no puede notificar el fallo de la máquina en la que se ejecuta. Por ello, el servidor de escaneo comprueba cada minuto si la aplicación responde y, tras varios fallos consecutivos, lo notifica con un texto fijo al teléfono del operador. A la inversa, el servidor web supervisa el latido del escáner; la lista de comprobación de la configuración muestra si la vigilancia cruzada está en funcionamiento.
Alarma de errores: un tipo de error que no se ha producido nunca antes se notifica una vez de inmediato; una acumulación de errores solo desencadena una única señal al teléfono del operador; una vez al día se envía un resumen. Así no nos enteramos de un error primero por un Cliente.
Límite, dicho abiertamente: ambos servidores están en la misma ubicación. Un fallo de toda la ubicación, por ejemplo del suministro eléctrico o de la conexión a internet, no lo notifica ningún mecanismo de alerta, sino que lo detecta una persona.

7.3 Cambios y despliegue

Las nuevas versiones se compilan y prueban primero en el entorno de desarrollo independiente. El despliegue comprueba todos los requisitos previos antes de escribir el primer archivo, realiza los cambios en el esquema de la base de datos y deja que las comprobaciones en curso finalicen ordenadamente antes de reiniciar el escáner.
Para el recorrido de un nuevo Cliente existe una prueba de humo a través de HTTP real, que se ejecuta tras los cambios. No afirmamos disponer de un conjunto de pruebas automatizadas antes de cada despliegue.

8. Supresión y plazos de conservación

Un proceso de supresión cada noche hace cumplir los plazos indicados en la Política de privacidad y en el Contrato de encargo del tratamiento. Lee los mismos ajustes de los que se toman las cifras de los textos; por tanto, para estos plazos, texto y comportamiento no divergen.
Los resultados de las comprobaciones, incluidas las capturas de pantalla, se suprimen al cabo de 13 meses (se mantiene el más reciente de cada dominio); las cifras de las extensiones, al cabo de 13 meses; los registros de entrega de alertas, al cabo de 90 días; las solicitudes de soporte, al cabo de 24 meses.
Eliminar un dominio suprime sus datos, incluidas comprobaciones, formularios, resultados, capturas de pantalla, informes, trabajos, destinos y registros de alertas, incidencias, datos de entrega, credenciales para el escaneo tras el inicio de sesión y pruebas.
La eliminación de una cuenta se realiza de inmediato; los espacios de trabajo sin otros miembros se eliminan con sus datos, y los espacios de trabajo con otros miembros pasan a otro miembro, primero a los administradores y, entre ellos, al más antiguo. Hasta que expiren sus propios plazos, permanecen: los registros cuyas entradas conservan el antiguo número de cuenta, que ya no remite a ninguna cuenta existente, incluida la entrada de eliminación, así como los correos electrónicos enviados, la prueba de celebración del contrato, las solicitudes de soporte, los informes de comprobaciones de posibles clientes (hasta 90 días) y los datos de facturación en Stripe; los detalles figuran en la Política de privacidad.
Los datos suprimidos permanecen en las copias de seguridad hasta que estas expiran al cabo de 14 días. No se realiza una supresión selectiva dentro de una copia de seguridad; si se restaura una copia de seguridad, las solicitudes de supresión posteriores conocidas se vuelven a ejecutar manualmente.

9. Organización y revisión

Personas: actualmente, el servicio lo gestiona el propio titular. Otras personas solo reciben acceso tras un compromiso de confidencialidad y solo en la medida necesaria, y solo tratan datos siguiendo nuestras instrucciones (art. 29 y art. 32(4) RGPD).
Subencargados del tratamiento: solo recurrimos a ellos tras revisar sus garantías y en virtud de un contrato conforme al art. 28(4) RGPD, y los enumeramos en la página Subencargados del tratamiento; los detalles se rigen por el Contrato de encargo del tratamiento.
Violaciones de la seguridad de los datos personales: si una violación de la seguridad de los datos personales afecta a datos tratados como encargado, lo notificamos al Cliente sin dilación indebida, a ser posible en un plazo de 48 horas; los detalles se rigen por el Contrato de encargo del tratamiento.
Notificación de vulnerabilidades: aceptamos notificaciones en Seguridad y a través del archivo /.well-known/security.txt.
Lista de comprobación de configuración y lanzamiento: en el área de administración, una lista de comprobación mide el estado de los ajustes relevantes para la seguridad, como la copia de seguridad, los administradores sin segundo factor, la configuración del correo y el latido, y muestra las desviaciones.
Revisión de estas medidas (art. 32(1)(d) RGPD): en cada cambio significativo del servicio, tras cada incidente de seguridad y, en los demás casos, al menos una vez al año. Al hacerlo, evaluamos si las medidas son eficaces y siguen correspondiéndose con los riesgos, y documentamos el resultado en una nueva versión de esta página o, si no cambia nada, con la fecha de la revisión en la sección 11. De forma continua, la lista de comprobación de configuración y lanzamiento mide el estado de los ajustes que abarca.
Auditorías externas: actualmente no se encargan pruebas de penetración externas y no existen certificaciones de seguridad. Lo indicamos aquí para que nadie suponga lo contrario.

10. Previsto, aún no aplicado

Estos puntos no son medidas comprometidas hasta que figuren aquí como aplicados en una nueva versión:

Copia de seguridad en una segunda ubicación: una copia cifrada de la copia de seguridad nocturna fuera del servidor, para que ni siquiera una pérdida total del servidor provoque una pérdida de datos.
Segundo punto de control: la confirmación independiente de las comprobaciones con navegador desde una segunda ubicación está preparada en el servicio, pero no configurada. Sin ella, no hay confirmación desde una segunda ubicación.
Refuerzo de la administración de servidores: continúa. Por los motivos expuestos en la sección 1, no publicamos detalles.

11. Estado y versión

Versión 1.1 · Última actualización: 22 de octubre de 2026 · en caso de discrepancias entre las versiones lingüísticas, prevalece la versión polaca en lugar de la alemana; sin otros cambios.
Versión 1.0 · Última actualización: 11 de octubre de 2026 · primera versión como página independiente; anteriormente Anexo 2 del Contrato de encargo del tratamiento. Corregido respecto del anexo anterior: la prueba de restauración se ejecuta semanalmente, las copias de seguridad están en el mismo servidor, no se ejecuta un conjunto de pruebas automatizadas antes de cada despliegue, las conexiones en la red interna no están cifradas en su totalidad. Descrito por primera vez: cifrado de las credenciales para el escaneo tras el inicio de sesión, aislamiento del escáner, vigilancia cruzada y alarma de errores.
Los cambios se publican con un nuevo número de versión aquí y en el resumen Modificaciones de los documentos contractuales; para cualquier debilitamiento de las medidas, se aplica el plazo de preaviso del Contrato de encargo del tratamiento.
En caso de discrepancias entre las versiones lingüísticas, prevalece la versión polaca.

¿En qué podemos ayudarle?