Medidas Técnicas y Organizativas

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

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

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

1. Ámbito de aplicación y principio

Las medidas se aplican a todos los datos tratados por el servicio: a los datos que tratamos por cuenta de nuestros Clientes (descritos en el Acuerdo de Tratamiento de Datos) y a los datos de los que nosotros mismos somos responsables del tratamiento, como cuentas de cliente y registros. No existen niveles de protección separados para ambos; lo que protege la cuenta también protege los datos tratados como encargados.

Estructura conforme al art. 32, apartado 1, del 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 manera oportuna después de un incidente (letra c)), en la sección 7.1; el proceso de verificación, evaluación y valoración periódicas de la eficacia (letra d)), en la sección 9. Seleccionamos las medidas a partir 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 costos de implementación.

Principio: medido, no meramente previsto. Aquí solo se indica lo que efectivamente se ha implementado en el código o en la operación. Lo previsto pero aún no implementado se enumera expresamente como «previsto» en la sección 10. Una medida que no figure aquí no está implementada de forma tácita.

Deliberadamente no se indican nombres de máquinas, direcciones internas, puertos, nombres de usuario ni versiones de software. No ayudan a nadie a evaluar las medidas, pero sí a quien quiera eludirlas. Quien los necesite para una auditoría conforme al Acuerdo de Tratamiento de Datos los recibirá en el marco de dicha auditoría bajo confidencialidad, en la medida en que sean necesarios para ella.

2. Estructura del servicio

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

Servidor web con base de datos. Entrega la aplicación, conserva la base de datos, envía notificaciones y realiza copias de seguridad de los datos. Solo él está configurado para aceptar solicitudes de internet.
Servidor de escaneo. Realiza en un navegador las verificaciones de sitios web propios y de terceros y ejecuta el modelo de lenguaje que clasifica formularios individuales, resume los hallazgos del escaneo como planes de acción priorizados para cuentas de pago y agrega código en «Fix it for me». No está configurado para aceptar solicitudes de internet, sino que recupera por sí mismo sus trabajos del servidor web y devuelve allí los resultados.

No interviene ningún proveedor de alojamiento, centro de datos o nube en la operación y no se envía nada a un servicio externo de IA. Los terceros que reciben datos se indican en la página Subencargados del Tratamiento.

3. Confidencialidad

3.1 Control de acceso físico

Los servidores están ubicados en instalaciones del proveedor en Polonia que no están abiertas al público. Solo el propietario tiene acceso (según lo declarado por el operador). Deliberadamente no se indica aquí la dirección exacta de la ubicación.

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 cambia el método estándar, el hash se renueva en el siguiente inicio de sesión. Ante 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. Asimismo, la respuesta a una solicitud de restablecimiento de contraseña no revela, ni por su texto 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 nuevas contraseñas deben tener al menos diez caracteres y no superar 72 bytes (UTF-8), porque bcrypt no tiene en cuenta más bytes. Cambiar la contraseña cierra la sesión de todos los demás dispositivos; restablecerla mediante el enlace cierra la sesión de todos los dispositivos y el enlace solo es válido una vez.
Bloqueo después de intentos fallidos. Los inicios de sesión fallidos se cuentan por dirección IP; después de 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 reinicia este contador. Los intentos se eliminan después de siete días. Además, antes de cada comprobación de contraseña se cuenta un intento por cuenta (para una dirección desconocida, por dirección ingresada) y por dirección IP, incluidos los intentos correctos: actualmente, como máximo ocho por cuenta desde la misma dirección IP y 80 por dirección IP en 15 minutos; se aplica un límite considerablemente mayor por cuenta sumando todas las direcciones, contra los intentos distribuidos de adivinar contraseñas. Por tanto, los intentos fallidos desde otra dirección ya no dejan al propietario sin acceso a su cuenta. Estos contadores solo contienen una clave HMAC, no direcciones de correo electrónico ni direcciones IP en texto claro, y vencen con su ventana temporal. Si el almacenamiento de contadores no está disponible, se rechaza el inicio de sesión, no se permite. El mismo tipo de límite se aplica a la confirmación de la contraseña antes de cambiar la contraseña o dirección, activar o desactivar el segundo factor, transferir un espacio de trabajo, exportar datos y eliminar la cuenta (cinco intentos por cuenta en 15 minutos), a los registros (diez por dirección IP por hora) y a las contraseñas de portales de clientes (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 ella, por lo que un extracto de la base de datos por sí solo no basta. Un código aceptado no vuelve a ser válido. 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 a cuentas con el segundo factor activado. La lista de comprobación de configuración informa de cada cuenta de administrador sin segundo factor.
Sesiones. La cookie de sesión no puede leerse mediante scripts (HttpOnly), se envía únicamente mediante HTTPS (Secure) y no se envía con solicitudes desde sitios de terceros que puedan modificar algo (SameSite=Lax). Al iniciar sesión, se crea un nuevo ID de sesión para que un ID colocado previamente deje de ser válido; el servidor no acepta un ID de sesión que no haya emitido él mismo. Cada cuenta ve los dispositivos con sesión iniciada y puede cerrar sus sesiones individualmente.
«Mantener mi sesión iniciada» es opcional y tiene una validez de 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 en la base de datos como hash. Cada uso lo sustituye por uno nuevo e, 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 en la base de datos como hash. 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 pendiente deja de ser válido.
Interfaces. Las claves de API, los códigos de conexión de las extensiones y los códigos de conexión masiva 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 solo una vez.
Protección contra bots en los formularios públicos (registro, inicio de sesión, contraseña, verificación, herramienta de encabezados, exclusión, soporte y contacto): Google reCAPTCHA, que se carga únicamente 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 dentro de tres segundos, se rechaza el envío. Los detalles están en la Política de Privacidad.

3.3 Control de acceso: administración del servidor

El servidor accesible desde internet utiliza un filtro de paquetes para permitir únicamente los servicios que ofrece y bloquea automáticamente direcciones después de repetidos inicios de sesión fallidos 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 entrega nuevas versiones del escáner solo puede ejecutar una lista fija de comandos en el servidor de escaneo y solo puede copiar, con acceso de solo escritura, al directorio del escáner; no permite un inicio de sesión interactivo y cada comando rechazado se registra. Asimismo, el servidor de escaneo solo puede escribir capturas de pantalla en un directorio específico del servidor web.
El proceso que sirve el sitio web no tiene acceso de escritura a la instalación en 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 una tarea independiente.
Los secretos, como las credenciales de la base de datos y las claves, se conservan 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 mediante la interfaz web.

3.4 Control de autorizaciones: derechos dentro del servicio

Roles. Cada espacio de trabajo tiene los roles de propietario, administrador y lector. Modificar, eliminar, invitar y almacenar credenciales se reserva a propietarios y administradores; solo el propietario puede cambiar roles y eliminar miembros. Una invitación solo es válida mientras la persona que la envió siga siendo propietaria o administradora. Los lectores 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 con el espacio de trabajo. Los dominios y la configuración solo son accesibles para los miembros del espacio de trabajo. Para cada verificación, el Servicio crea un informe bajo un enlace aleatorio que no puede adivinarse; puede accederse a los resultados y las capturas de pantalla de una verificación mediante este enlace sin iniciar sesión, y a las capturas 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 termina después de una hora, bloquea cambios de contraseña, dirección, segundo factor, dispositivos, suscripción, exportación y eliminación, cierra mientras tanto el área de administración y se registra. Al terminarla, se cierra completamente 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 administrativos; cada restablecimiento de un segundo factor por la administración se registra.

3.5 Control de separación

Los datos de los clientes se separan lógicamente por espacio de trabajo. Cada ruta de lectura y escritura del área con sesión iniciada lleva consigo esta vinculación; los informes también son accesibles mediante su enlace (sección 3.4).
El desarrollo y la operación funcionan en instalaciones separadas con bases de datos y usuarios de base de datos separados. El usuario de desarrollo no tiene acceso a la base de datos de producción. No se copian datos reales de clientes al desarrollo; allí trabajamos con datos de ejemplo generados.
Para cada entorno, el escáner tiene sus propias credenciales con derechos solo sobre los datos que necesita para sus trabajos. No puede leer cuentas, facturación ni registros.
Otros servicios del mismo proveedor también funcionan en el servidor web. 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 detrás del 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 de 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 existe únicamente en el servidor de escaneo. El servidor web, la base de datos y las copias de seguridad solo contienen texto cifrado; nosotros tampoco 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 verificación solo mediante 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 elimina del trabajo; una ejecución borra cualquier resto a más tardar después de una hora.
Las credenciales nunca se muestran, nunca se registran en los registros, nunca se proporcionan mediante la API ni se exportan. La interfaz solo muestra el primer carácter y la longitud del nombre de usuario. Su eliminación sobrescribe el texto cifrado.
Detrás del inicio de sesión, el escáner solo lee: sin envíos, sin pruebas activas, sin capturas de pantalla, sin páginas para cerrar sesión, eliminar o cancelar.

4.2 Otros cifrados y hashes

Las contraseñas, los códigos de recuperación, las contraseñas de portales de clientes, las claves de API, los códigos de conexión y de conexión masiva, los tokens de «Mantener mi sesión iniciada», los ID de sesión en 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 describe anteriormente.

4.3 Minimización de datos desde el diseño

Verificación de entrega: Solo se leen los encabezados y, como máximo, los primeros 8 KB del texto. Solo llegan a la base de datos la hora, la asignación, cuando corresponda el ID del envío de prueba y el resultado de la verificación de autenticidad (SPF, DKIM, DMARC), nunca el contenido ni una dirección completa del remitente. El resultado de autenticidad del correo más reciente se conserva con el dominio y el siguiente lo sobrescribe; contiene la dirección IP del servidor de correo que realiza la entrega y el dominio de correo del remitente. El correo se elimina del buzón después de procesarse correctamente; si falla la recuperación o la eliminación, esto ocurre en la siguiente ejecución correcta.
Verificaciones: La estructura de los formularios se almacena con nombres de campos, tipos y etiquetas, atributos de obligatoriedad y visibilidad, sin valores; el escáner lee el inicio de los campos ocultos rellenados previamente (hasta 24 caracteres) y de los atributos de datos (hasta 60 caracteres) solo durante la verificación y no los almacena. En las capturas de pantalla de la verificación completa no se oculta contenido; solo las verificaciones con navegador cubren los campos de entrada. Las direcciones de destinatarios de formularios se almacenan únicamente como dominio. Los envíos de prueba activos contienen únicamente textos de prueba identificados como tales, sin datos personales.
Las extensiones para WordPress y TYPO3 transmiten únicamente cifras diarias y características como el inventario de plugins y, para un plugin de WordPress conectado, también los dominios de enlaces de mensajes bloqueados para la protección colectiva (activada de forma predeterminada); ningún otro contenido, nombres, direcciones ni direcciones IP de visitantes. Los recuentos opcionales de formularios y errores de campos están desactivados de forma predeterminada.
«Fix it for me»: El código pegado se trata solo durante la solicitud y no se almacena.
Insignia: La imagen de la insignia en los sitios web de clientes no instala 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 contenido. Las notificaciones de errores por correo electrónico al operador contienen el texto sin procesar del mensaje de error, sin depurar y truncado a 400 caracteres; en casos individuales 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 local de base de datos; no se envía ninguna dirección 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 el exterior podría acceder a nuestra red interna o a 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 individual.

5.1 Ejecución aislada

Cada verificació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 elevar privilegios. Su sistema de archivos es de solo lectura, excepto 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 excede el tiempo se termina.

5.2 Red: dos capas

Primera capa, en el escáner: Antes del escaneo y después para cada solicitud individual del navegador, incluidas redirecciones y contenido incorporado, se comprueba a qué dirección se resuelve el nombre. Se rechazan las redes privadas, locales, reservadas y de documentación (IPv4 e IPv6), así como los puertos distintos de los habituales para la web. El navegador no permite service workers y se cierran las conexiones WebSocket, porque ambos podrían eludir esta comprobación.
Segunda capa, en la red: Los contenedores funcionan en su propia red. Las reglas del firewall solo permiten conexiones desde allí a internet por puertos web; las conexiones a redes privadas, incluida nuestra red interna con el servidor web y la base de datos, están bloqueadas. Las excepciones que requiere la propia ejecución de verificación se limitan a lo necesario y se describen en nuestra documentación interna. Esta capa también surte efecto 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 prueba de control del dominio, la herramienta de encabezados, la búsqueda de archivos expuestos, las solicitudes de pulso, las consultas RDAP y la verificación de certificados, para webhooks y alertas de chat y para el segundo punto de verificación opcional—, se aplican las mismas reglas: solo protocolos web, en los puertos web habituales (webhooks y alertas de chat solo mediante HTTPS en el puerto estándar), solo direcciones públicas, conexión únicamente a la dirección exacta comprobada previamente para que un nombre no pueda redirigirse posteriormente a un destino interno, redirecciones que no se siguen en absoluto o se siguen solo manualmente y se vuelven a comprobar cada vez, límites de tiempo cortos; para la prueba de control del dominio, las solicitudes de pulso y el segundo punto de verificación en las verificaciones con navegador, también un tamaño de respuesta limitado.

5.4 Qué no hace el escáner en sitios de terceros

Para los Clientes, los envíos de prueba activos (como máximo cinco por verificación) solo existen para dominios para los que se ha proporcionado prueba de control (DNS, metaetiqueta, archivo o extensión); la única excepción son las verificaciones internas de nuestros propios dominios de prueba y demostración. El nombre de host de un dominio con prueba de control no puede cambiarse para que la prueba no se transfiera a otro host. Todo lo demás es pasivo: leer páginas como un visitante.
Las verificaciones con navegador llegan hasta el punto anterior al envío y no generan ningún pedido, pago ni envío.
Los dominios de la lista de exclusión no se verifican; el monitoreo en curso termina con la siguiente verificación programada.

6. Integridad: transferencia y entrada

6.1 Transporte

Solo puede accederse a la aplicación desde internet mediante HTTPS; se indica al navegador que utilice únicamente HTTPS durante un año (HSTS). Los certificados se renuevan automáticamente.
Otros encabezados restringen la incorporació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 contenido solo permite ejecutar en la aplicación los scripts que el servidor autoriza con la respuesta correspondiente; los navegadores actuales no ejecutan scripts inyectados ni controladores de eventos en el HTML.
El buzón de la verificación de entrega se recupera mediante una conexión cifrada con verificación del certificado.
Los webhooks pueden firmarse con un secreto del Cliente (HMAC-SHA256 con marca de tiempo), de modo que el destinatario pueda verificar el origen y la integridad. Las solicitudes al segundo punto de verificación opcional se firman y, para las verificaciones con navegador, también sus respuestas.
Declarado abiertamente: Las conexiones dentro de nuestra red interna no están cifradas en su totalidad. Las credenciales para el escaneo detrás del inicio de sesión permanecen cifradas en todo momento (sección 4.1).

6.2 Control de entradas y registros

Las acciones importantes en cuentas y espacios de trabajo (como inicio de sesión, cambios en dominios, destinos de alertas y derechos, eliminaciones, acceso de soporte) se registran en el registro de auditoría con cuenta, hora, dirección IP y país, y se eliminan después de 365 días.
Los registros de acceso a páginas conservados para la seguridad y la prevención del abuso se eliminan después de 60 días; los registros de errores, después de 90 días; el contenido de los correos electrónicos enviados, después de 30 días. Los tokens de acceso en las direcciones solicitadas y los referentes, como los de enlaces de informes o portales, aparecen en los registros de acceso a páginas únicamente de forma enmascarada.
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 el identificador del navegador.
Los registros de evidencias pueden llevar un sello de tiempo de una autoridad externa de sellado de tiempo; solo se le envía una suma de comprobación del contenido, no el contenido en sí.

7. Disponibilidad y resiliencia

7.1 Copias de seguridad

Se realiza una copia de seguridad de la base de datos cada noche. Una copia recibe su nombre definitivo solo después de que se haya comprobado su contenido: finalización correcta del programa de copia de seguridad, al menos un registro, tantas tablas como tenga la base de datos y la línea de cierre de una ejecución completa. Las copias anteriores solo se eliminan después de una nueva copia correcta.
Cada copia se elimina después 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 producción y se elimina de nuevo. 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 después de un incidente: Si falla la base de datos o se dañan datos, 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 durante el proceso; si ha fallado una copia de seguridad, correspondientemente más. Después volvemos a ejecutar las solicitudes posteriores de supresión conocidas (sección 8). No nos comprometemos a ningún tiempo de recuperación específico.
Limitación, declarada 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 contra errores de operación, cambios defectuosos y datos dañados, no contra la pérdida del propio servidor. Se prevé una copia cifrada en una segunda ubicación (sección 10).
Las credenciales para el escaneo detrás del inicio de sesión solo están contenidas 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 Monitoreo

Una tarea de estado comprueba cada cinco minutos los componentes del servicio, incluidas la base de datos, la cola y la señal de actividad del escáner, que este escribe regularmente incluso cuando está inactivo. Si un componente falla, se envía una notificación; si se recupera, una confirmación de restablecimiento.
Vigilancia cruzada: Una tarea de estado no puede informar de la falla de la máquina en la que se ejecuta. Por ello, el servidor de escaneo comprueba cada minuto si la aplicación responde y, después de varias fallas consecutivas, informa con un texto fijo al teléfono del operador. A la inversa, el servidor web monitorea la señal de actividad del escáner; la lista de comprobación de configuración muestra si la vigilancia cruzada está funcionando.
Alerta de error: Un tipo de error que nunca ha ocurrido antes se notifica de inmediato una vez; una acumulación de errores solo genera una señal al teléfono del operador; una vez al día se envía un resumen. Esto significa que no nos enteramos de un error por primera vez a través de un Cliente.
Limitación, declarada abiertamente: Ambos servidores están en la misma ubicación. Una falla de toda la ubicación, por ejemplo, de la electricidad o de la conexión a internet, no se comunica mediante ningún mecanismo de alerta, sino que la detecta una persona.

7.3 Cambios y despliegue

Las nuevas versiones se construyen y prueban primero en el entorno de desarrollo separado. El despliegue comprueba todos los requisitos antes de que se escriba el primer archivo, realiza los cambios en el esquema de la base de datos y deja que las verificaciones en curso terminen de forma ordenada antes de que se reinicie el escáner.
Para el recorrido de un nuevo Cliente, existe una prueba básica mediante HTTP real que se ejecuta después de los cambios de versión. No afirmamos contar con un conjunto de pruebas automatizadas antes de cada despliegue individual.

8. Supresión y plazos de conservación

Una ejecución de eliminación cada noche aplica los plazos indicados en la Política de Privacidad y en el Acuerdo de Tratamiento de Datos. Lee la misma configuración de la que se toman las cifras de los textos; por tanto, para estos plazos, el texto y el comportamiento no divergen.
Los resultados de verificaciones, incluidas capturas de pantalla, se eliminan después de 13 meses (permanece el más reciente por dominio); las cifras de las extensiones, después de 13 meses; los registros de entrega de alertas, después de 90 días; las solicitudes de soporte, después de 24 meses.
Eliminar un dominio elimina sus datos, incluidas verificaciones, formularios, hallazgos, capturas de pantalla, informes, trabajos, destinos y registros de alertas, incidentes, datos de entrega, credenciales para el escaneo detrás del inicio de sesión y evidencias.
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 de mayor antigüedad. Hasta que venzan sus propios plazos, permanecen los siguientes: los registros cuyas entradas conservan el antiguo número de cuenta, que ya no se refiere 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 verificaciones de clientes potenciales (hasta 90 días) y los datos de facturación en Stripe; los detalles están en la Política de Privacidad.
Los datos eliminados permanecen en las copias de seguridad hasta que estas vencen después de 14 días. No se realiza una supresión selectiva dentro de una copia de seguridad; si se restaura una copia, las solicitudes posteriores de supresión conocidas vuelven a ejecutarse manualmente.

9. Organización y revisión

Personas: Actualmente, el propio propietario opera el servicio. Otras personas solo reciben acceso después de comprometerse a la confidencialidad y únicamente en la medida necesaria, y tratan datos solo por nuestras instrucciones (art. 29 y art. 32, apartado 4, del RGPD).
Subencargados del tratamiento: Solo los contratamos después de revisar sus garantías y mediante un contrato conforme al art. 28, apartado 4, del RGPD, y los enumeramos en la página Subencargados del Tratamiento; los detalles se rigen por el Acuerdo de Tratamiento de Datos.
Violaciones de seguridad de los datos personales: Si una violación afecta a datos tratados como encargados, notificamos al Cliente sin dilación indebida, de ser posible dentro de las 48 horas; los detalles se rigen por el Acuerdo de Tratamiento de Datos.
Notificación de vulnerabilidades: Aceptamos notificaciones en Seguridad y mediante el 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 copias de seguridad, administradores sin segundo factor, configuración de correo y señal de actividad, y muestra desviaciones.
Revisión de estas medidas (art. 32, apartado 1, letra d), del RGPD): en cada cambio significativo del servicio, después de 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 ajustándose a los riesgos, y registramos el resultado en una nueva versión de esta página o, si no cambia nada, con la fecha de revisión en la sección 11. De manera 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. Se indica aquí para que nadie las suponga.

10. Previsto, aún no implementado

Estos puntos no son medidas comprometidas hasta que se enumeren aquí como implementados 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, de modo que incluso una pérdida total del servidor no provoque la pérdida de datos.
Segundo punto de verificación: La confirmación independiente de las verificaciones 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 del servidor: Continúa en curso. Por los motivos indicados 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 en polaco 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 Acuerdo de Tratamiento de Datos. Correcciones 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 y las conexiones de la red interna no están cifradas en su totalidad. Nuevas descripciones: cifrado de las credenciales para el escaneo detrás del inicio de sesión, aislamiento del escáner, vigilancia cruzada y alerta de error.
Los cambios se publican con un nuevo número de versión aquí y en el resumen Cambios en los Documentos Contractuales; para cualquier debilitamiento de medidas, se aplica el plazo de aviso del Acuerdo de Tratamiento de Datos.
En caso de discrepancias entre las versiones lingüísticas, prevalece la versión en polaco.

¿Cómo podemos ayudarle?