Este documento se publica en varios idiomas. En caso de discrepancia entre las versiones lingüísticas, prevalecerá la versión polaca.
Versión 1.2 · Última actualización: 29 de octubre de 2026
1. Cómo leer este registro
Este es el registro de las actividades de tratamiento conforme al art. 30 RGPD de formexposed. No es una política de privacidad ni material de marketing. Su función es mostrar a una autoridad de control, a un Cliente que nos audita como encargado del tratamiento o a la próxima persona que tenga que responder una pregunta qué se trata realmente, dónde se conserva, quién lo recibe y cuánto tiempo permanece. Lo publicamos porque un servicio que comprueba y supervisa formularios debe estar él mismo abierto a comprobación.
Su redacción se rigió por tres reglas.
- Medido, no pretendido. Una afirmación sobre campos de datos, plazos de conservación, destinatarios o garantías solo figura cuando la respaldan el código del programa, el esquema de la base de datos o una medición. Lo previsto se denomina «previsto». Lo que está desactivado por defecto se denomina «desactivado por defecto». Cuando no podemos demostrar algo, lo decimos.
- La conservación se indica dos veces. Una vez para cada actividad de tratamiento y otra en la sección 6 como panorama general: qué proceso nocturno suprime qué datos y a qué datos no llega. Un registro que afirma un plazo de conservación que solo se aplica a una parte de los datos es peor que uno que menciona el punto pendiente.
- Los puntos pendientes se indican en el texto, no en una nota a pie de página. La sección 8.1 enumera las medidas que aún no se han aplicado; la sección 10, los puntos pendientes con las medidas previstas. Un registro es una herramienta de trabajo, no un certificado.
Campos de datos en lugar de nombres de tablas. Para cada actividad de tratamiento, enumeramos los datos almacenados como campos en lenguaje claro. El nombre de la tabla de la base de datos figura entre paréntesis para que un auditor pueda encontrar el lugar, por ejemplo «intentos de inicio de sesión (login_attempts)». Las listas de campos se derivaron del esquema de la base de datos, no de memoria.
Plazos de conservación como marcadores. Cuando un plazo de conservación puede configurarse en el área de administración, aparece aquí exactamente como lo lee el proceso nocturno: el número que ve procede del mismo ajuste que rige la supresión. Los plazos de conservación fijados en el programa se indican como números.
Base de la medición. El esquema, el código y los ajustes se midieron el 11 de octubre de 2026 en el sistema de desarrollo, que coincide con el sistema de producción en código y esquema. No indicamos recuentos de filas del sistema de desarrollo; contienen datos de prueba y no dicen nada sobre el funcionamiento real.
Omitido deliberadamente. Este registro no menciona nombres de host, direcciones de red internas, puertos, nombres de usuario ni versiones de software de nuestros servidores. Tales detalles ayudan a un atacante y a ningún interesado. Por el mismo motivo, describimos los puntos pendientes en la protección de nuestros propios servidores solo en términos generales (sección 8.1): mencionamos el riesgo, no el camino hacia él. Facilitamos los detalles a una autoridad de control previa solicitud.
Naturaleza jurídica. Este registro es la documentación que llevamos conforme al art. 30 RGPD para la autoridad de control; se publica voluntariamente. No forma parte de ningún contrato y no constituye ninguna declaración, garantía ni acuerdo sobre calidad frente a Clientes o terceros. Lo que debemos a los Clientes se rige por las Condiciones del servicio, el Contrato de encargo del tratamiento y sus anexos; en lo que respecta a estas obligaciones, prevalecen sobre este registro. El registro describe la situación a la fecha de esta versión. Las calificaciones como «punto pendiente» o «evaluación» reflejan nuestra propia opinión y no anticipan ninguna valoración jurídica de una autoridad de control o de un tribunal; las medidas descritas como «previstas» son intenciones sin fecha comprometida.
2. La entidad jurídica y por qué este registro tiene dos mitades
| Campo | Entrada |
| Entidad jurídica | LW IT Solutions Company Lukas Wójcik, empresa individual inscrita en el registro mercantil polaco (CEIDG); titular Lukas Wójcik |
| Dirección | al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Polonia |
| Identificadores fiscales | NIP 7252266190, NIF-IVA PL7252266190 |
| Contacto | contact@lukaswojcik.com; la ventana de soporte (signo de interrogación de la navegación); la página de contacto |
| Servicio | formexposed: comprobación, supervisión y protección de formularios de contacto en sitios web (aplicación en formexposed.com, página de presentación en form.exposed) |
| Representante conforme al art. 27 RGPD | No aplicable. La entidad jurídica está establecida en la Unión (Polonia). |
| Delegado de protección de datos | No designado. La evaluación conforme al art. 37 figura en la sección 9. |
| Autoridad de control competente | Prezes Urzędu Ochrony Danych Osobowych (UODO, la autoridad polaca de protección de datos), ul. Moniuszki 1A, 00-014 Warszawa |
| Alojamiento | Nuestros propios servidores en Polonia: un servidor web con la aplicación y la base de datos, y un servidor de escaneo con un modelo de lenguaje local en la misma red interna. Ningún centro de datos de terceros ni proveedor de nube. |
formexposed desempeña funciones distintas frente a distintos grupos de personas. Mezclarlas da lugar a un registro que no es correcto para ninguno de ellos.
- Responsable del tratamiento (parte B, art. 30(1)). Somos nosotros mismos el responsable del tratamiento de los datos de nuestros propios Clientes y de los miembros de sus equipos (cuenta, inicio de sesión, facturación, soporte, registros), de los visitantes de nuestro propio sitio web, de las comprobaciones sin cuenta (comprobación gratuita, herramienta de cabeceras, estudio, comprobación de posibles clientes) y de la prevención de abusos.
- Encargado del tratamiento (parte A, art. 30(2)). Respecto de los datos personales de terceros que un Cliente introduce en el servicio o que se generan cuando prestamos un servicio al Cliente, actuamos por cuenta del Cliente: copias de correos electrónicos de formulario reales en la comprobación de entrega, suscriptores del portal de cliente del Cliente, destinatarios de las alertas del Cliente, personas que resultan visibles en las páginas comprobadas del Cliente, las credenciales de la cuenta de prueba del Cliente y el código de formulario que pega el Cliente. La base es el Contrato de encargo del tratamiento, que se celebra con cada Cliente en el momento del registro.
- Solo en el lado del Cliente. Algunas funciones del plugin de WordPress y de la extensión de TYPO3 tratan datos exclusivamente en el sitio web del Cliente, sin que los datos lleguen nunca a nosotros (cuarentena, red de seguridad, acertijo aritmético, ajustes de conservación, contadores locales, grabador). No constituyen un tratamiento por nuestra parte y, por tanto, no figuran en ninguna de las dos partes. No obstante, las describimos al final de la parte A para que el límite sea visible.
La separación está incorporada en el código, no solo en el texto: de un correo electrónico de formulario real, la comprobación de entrega solo escribe en la base de datos la hora, la asignación y el resultado de la autenticación; las capturas de pantalla de las comprobaciones con navegador ocultan los campos de entrada; las credenciales de las cuentas de prueba se cifran de tal modo que el servidor web ya no puede leerlas. Los detalles figuran en las entradas.
Las secciones 6 a 11 se aplican a ambas mitades: conservación, decisiones automatizadas, medidas técnicas y organizativas, delegado de protección de datos, puntos pendientes y mantenimiento de este registro.
Ámbito. Este documento es la parte del registro que se refiere al servicio formexposed. Los tratamientos de la misma entidad jurídica para otros servicios se recogen en sus propios registros; la contabilidad general y la administración empresarial ajenas al servicio no están cubiertas por esta parte.
3. Parte A – art. 30(2): tratamiento por cuenta de los Clientes
A.0 Partes intervinientes
| Campo | Entrada |
| Encargado del tratamiento | LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Polonia; contact@lukaswojcik.com |
| Responsables del tratamiento | Los Clientes de formexposed: empresas y agencias que tienen dominios en su cuenta y utilizan funciones en las que se generan datos de terceros. En el caso de las agencias, el propio cliente de la agencia puede ser además el responsable del tratamiento; la agencia actúa entonces como encargada del tratamiento frente a ese cliente y nosotros actuamos como otro encargado del tratamiento. |
| Lista de responsables del tratamiento | Parte de este registro, llevada en formato electrónico (art. 30(3) RGPD) en el sistema del servicio y no reproducida en esta versión pública, porque contiene datos personales de Clientes y quedaría desactualizada con cada nuevo Cliente: el titular de cada espacio de trabajo con nombre, dirección de correo electrónico y empresa de la cuenta de cliente (dirección y NIF-IVA solo en Stripe) (users, workspaces, workspace_users), más los dominios del espacio de trabajo (domains). La facilitamos a una autoridad de control como extracto previa solicitud. |
| Representantes y delegados de protección de datos de los responsables | No existe un campo específico para ello en el sistema. Si un Cliente ha designado un representante conforme al art. 27 RGPD o un delegado de protección de datos, puede comunicárnoslo; conservamos la comunicación junto con la lista de responsables del tratamiento. |
| Representante del encargado del tratamiento | No aplicable (establecido en Polonia). |
| Delegado de protección de datos | No designado (sección 9). |
| Instrucciones | La instrucción se deriva del Contrato de encargo del tratamiento y de los ajustes que realiza el Cliente: el Cliente activa la comprobación de entrega, configura destinos de alerta, almacena una cuenta de prueba y configura un portal de cliente. Sin esa acción, el tratamiento correspondiente no se produce. |
| Medidas técnicas y organizativas | La sección 8 y la página Medidas técnicas y organizativas se aplican a todas las actividades de tratamiento de la parte A. Las medidas especiales se indican en la entrada correspondiente. |
A.1 Comprobación de entrega – copia de control de los correos electrónicos de formulario
| Campo | Entrada |
| Finalidad | Comprobar si el correo electrónico del formulario de contacto del Cliente se envía realmente y cómo se autentica (SPF, DKIM, DMARC, alineación). Tras un envío de prueba activo aceptado, su copia debe llegar al buzón de control dentro de un tiempo de espera configurable (actualmente 3 horas); de lo contrario, se genera la alerta «Correo de prueba no recibido». Las cabeceras se utilizan además para derivar la autenticidad del correo electrónico del formulario, el servicio de correo utilizado y la dirección de envío para la comprobación en listas de bloqueo. |
| Requisito previo | Plan de pago, dominio verificado, activado por el Cliente. El Cliente introduce su propia dirección de control con un identificador (del tipo «delivery+identificador@…») como copia oculta en la notificación de su formulario. Sin un buzón de control configurado, la función no está disponible. |
| Categorías de interesados | Visitantes del sitio web del Cliente que envían el formulario del Cliente; personas cuyos datos escribe un visitante en el mensaje; personal del Cliente que aparece como destinatario en las cabeceras. |
| Categorías de datos personales | En el buzón de control (en el proveedor de servicios de correo): la copia completa de cada correo electrónico de formulario, incluidas consultas reales con nombre, dirección de correo electrónico, número de teléfono y texto libre, hasta su supresión. Leído por la recuperación: las cabeceras y como máximo los primeros 8 KB del cuerpo. En la base de datos: hora de recepción, asignación al dominio y, en su caso, a la ejecución de prueba (delivery_log); el resultado de autenticación más reciente por dominio con el resultado de SPF, DKIM y DMARC, la alineación, el dominio del remitente, los dominios de firma y la dirección del servidor de correo remitente (campo de autenticación del dominio en domains). El contenido, el asunto y la dirección de remitente del visitante no se escriben en la base de datos. |
| Nota sobre el dominio del remitente | Si un formulario introduce la dirección del visitante como remitente (una configuración errónea que la comprobación está diseñada para detectar), el resultado de autenticación contiene el dominio de esa dirección, no la propia dirección. Si un visitante utiliza un dominio personal, también este puede ser un dato personal. Se sobrescribe en la siguiente recepción. |
| Origen | El formulario del sitio web del Cliente, a través de la copia oculta introducida por el Cliente. |
| Base jurídica (determinada por el responsable) | Determinada por el Cliente. Nuestro texto sugerido para la política de privacidad del Cliente basa la copia en el art. 6(1)(f) RGPD (interés legítimo en recibir las consultas de forma fiable). El Cliente informa a sus visitantes sobre este flujo de datos; el Contrato de encargo del tratamiento le obliga a ello. |
| Destinatarios | El proveedor de servicios de correo que gestiona el buzón de control (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA). La copia va directamente allí: solo llega si los registros MX de nuestro dominio apuntan a este buzón (la lista de comprobación previa al lanzamiento lo verifica); mediante un reenvío no llega al buzón. En la página del dominio, el Cliente solo ve la hora, la asignación y el resultado de autenticación. Si el resultado de autenticación empeora, la alerta al Cliente y a los canales que haya elegido menciona el dominio del remitente si no pertenece al sitio web (A.3, 4.1). |
| Tercer país | Depende del proveedor de servicios de correo; véase la sección 4. El contrato con el proveedor previsto y la base de la transferencia aún no están documentados. |
| Conservación | Tras su procesamiento correcto, el correo se marca para su supresión y se elimina del buzón en la misma ejecución, aunque no pueda asignarse a ningún dominio. La recuperación se ejecuta con el proceso de estado cada cinco minutos mientras la supervisión esté activada en el área de administración (srv/cron_status.php, cfg/zustellung_lib.php). Si la recuperación o la eliminación fallan, el correo permanece en el buzón hasta la siguiente ejecución correcta. La misma recuperación suprime las asignaciones de delivery_log al cabo de 180 días. El resultado de autenticación se conserva mientras exista el dominio. |
| Lo que prueba la evidencia | Únicamente la recepción, en el buzón de control, de la copia asignada a la ejecución de prueba concreta. No prueba ni la recepción por el destinatario real ni una entrada en el CRM. No se ofrece una confirmación nativa de HubSpot. |
| Medidas técnicas y organizativas | Sección 8. En particular: el contenido solo se evalúa en memoria; no se almacenan el cuerpo, el asunto ni las direcciones completas de remitente; supresión independientemente de si la asignación ha tenido éxito. |
La comprobación de entrega es la única función a través de la cual nos llegan mensajes reales de los visitantes de nuestros Clientes. Por eso es un tratamiento por cuenta del Cliente y no un servicio bajo nuestra propia responsabilidad, y por eso el tiempo de permanencia en el buzón es la medida real del riesgo: normalmente minutos; si la recuperación se ve perturbada, hasta que vuelva a ejecutarse. Las copias no deben contener categorías especiales de datos personales; no podemos impedirlo técnicamente, porque lo que escribe un visitante depende del visitante.
A.2 Portal de cliente e informe mensual a suscriptores
| Campo | Entrada |
| Finalidad | Una agencia (plan Business) muestra a sus clientes el estado de sus dominios bajo su propia marca (portal en una dirección aleatoria, opcionalmente con contraseña, opcionalmente bajo un subdominio propio de la agencia). El cliente puede solicitar allí un informe mensual por correo electrónico. El informe se envía en nombre de la agencia. |
| Categorías de interesados | Los clientes de la agencia y su personal que solicitan el informe; personas que abren el portal. |
| Categorías de datos personales | Suscriptor: dirección de correo electrónico, idioma, identificador de confirmación, hora de la solicitud y dirección IP en el momento de la solicitud, hora de la confirmación (doble opt-in), hora de la baja, último mes enviado (client_subscribers). Portal: nombre, selección de dominios, identificador aleatorio, contraseña solo como hash, persona que lo creó, hora, revocación (client_portals). Las visitas al portal figuran en el registro de visualizaciones de páginas (B.2). |
| Origen | Introducidos por los propios suscriptores en el portal. |
| Base jurídica (determinada por el responsable) | El consentimiento del suscriptor, obtenido mediante un procedimiento de doble opt-in; el responsable del tratamiento es la agencia. No escribimos a nadie que no se haya suscrito y confirmado por sí mismo. |
| Destinatarios | La agencia (ve a sus suscriptores); el proveedor de servicios de correo (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA) para el correo de confirmación y el informe. |
| Tercer país | A través del proveedor de servicios de correo; véase la sección 4. |
| Conservación | Proceso nocturno de supresión (cfg/fristen_lib.php, parte «suscriptores del portal»): solicitudes nunca confirmadas al cabo de 30 días; suscriptores dados de baja tres años después de la baja, como prueba del consentimiento anterior. Los suscriptores confirmados que no se han dado de baja permanecen mientras exista el espacio de trabajo de la agencia. Un portal revocado solo se bloquea, no se elimina; sus suscriptores ya no reciben informes, pero sus datos permanecen (sección 10). Los portales y los suscriptores se suprimen de inmediato con el espacio de trabajo (fe_arbeitsbereich_daten_loeschen()). Los informes enviados permanecen en la bandeja de salida durante 30 días (B.25). |
| Medidas técnicas y organizativas | Sección 8. En particular: contraseña del portal solo como hash, intentos de adivinación limitados (diez por portal y dirección IP, 50 por portal en 15 minutos); baja con un solo clic en cada correo; el portal solo muestra el estado y las cifras clave, no resultados individuales con pruebas. |
A.3 Destinatarios de alertas, personas que confirman y personas asignadas del Cliente
| Campo | Entrada |
| Finalidad | Notificaciones sobre fallos y cambios a los destinos que el Cliente configura para un dominio: correo electrónico, webhook, Slack, Discord, Microsoft Teams, Google Chat, Telegram. Por destino, de inmediato o agrupadas diaria o semanalmente, además de destinos solo para escalados. Cada notificación de problema se convierte en una incidencia, que el destinatario puede confirmar mediante un enlace. Para los formularios supervisados, el Cliente puede indicar una persona responsable y una fecha límite. |
| Categorías de interesados | Personal y proveedores de servicios del Cliente que el Cliente introduce como destino de alerta o designa como personas asignadas; personas que confirman una incidencia. Los miembros del equipo con cuenta propia figuran también en la parte B. |
| Categorías de datos personales | Destino de alerta: canal, dirección de destino (dirección de correo electrónico, dirección de webhook o de chat, ID de chat de Telegram), eventos seleccionados, modo de entrega, secreto de firma para webhooks, última entrega y último error (alerts). Registro de envíos: destino, eventos, estado, error, hora (alert_log). Cola de resúmenes: líneas de notificación y enlace hasta la entrega (alert_queue). Incidencia: título, líneas de notificación, enlace, identificador de confirmación, hora y nombre o dirección de correo electrónico de la persona que confirma tal como se introdujo en el formulario o, en su defecto, la dirección del miembro con sesión iniciada (alert_incidents). Intentos de entrega de escalado por incidencia y destino: número de intentos (como máximo cinco), horas del último y del siguiente intento y del éxito, referencia al correo en la bandeja de salida, error (tabla alert_escalation_deliveries). Asignación: cuenta de la persona responsable y fecha límite (en monitored_forms). |
| Contenido de las notificaciones | Dominio, evento, una breve explicación y un enlace a la página del dominio. Ningún contenido de los mensajes de los visitantes. |
| Origen | Introducidos por el Cliente; la persona que confirma introduce ella misma su nombre; el ID de chat de Telegram se genera cuando el destinatario pulsa «Iniciar» en el bot (B.32). |
| Base jurídica (determinada por el responsable) | Determinada por el Cliente; por regla general, la organización de las propias operaciones del Cliente (art. 6(1)(b) o (f) RGPD en relación con el personal y los proveedores de servicios del Cliente). |
| Destinatarios | Los operadores de los canales elegidos; véase 4.1. Alertas por correo electrónico a través del proveedor de servicios de correo (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA). |
| Tercer país | Según el canal elegido; varios proveedores tienen su sede en EE. UU., Telegram fuera de la UE sin decisión de adecuación. Véase 4.1. |
| Conservación | Registro de envíos al cabo de 90 días (cada noche, fe_alert_log_aufraeumen() desde srv/cron_status.php). Notificaciones de resumen 30 días después de la entrega (cfg/kanal_lib.php, en cada entrega de resumen). Incidencias mientras no estén resueltas; las resueltas, 180 días después de su resolución (cfg/vorfall_lib.php, proceso de escalado), junto con sus intentos de entrega de escalado. Destinos de alerta y asignaciones hasta que el Cliente los elimine o junto con el dominio. |
| Medidas técnicas y organizativas | Sección 8. En particular: webhooks firmados con un secreto distinto por destino; confirmación solo tras un clic (POST), para que las vistas previas de enlaces en los programas de chat no desencadenen nada; las alertas durante una ventana de mantenimiento solo se registran, no se envían. |
A.4 Personas visibles de forma incidental en páginas comprobadas del Cliente y en capturas de pantalla
| Campo | Entrada |
| Finalidad | La comprobación de los dominios de la cuenta del Cliente (escaneo, supervisión, comprobación activa) lee las páginas públicas del Cliente y toma capturas de pantalla de los formularios. Lo que muestra la propia página puede referirse a personas que no tienen nada que ver con la comprobación. Estos datos se generan de forma incidental; no son la finalidad de la comprobación. |
| Categorías de interesados | Personas cuyo nombre, fotografía o datos de contacto aparecen en la página comprobada (persona de contacto junto al formulario, fotos del equipo en la página de inicio, datos del aviso legal). |
| Categorías de datos personales | Capturas de pantalla: el área visible de la página de inicio, cada formulario visible como recorte y la imagen de la página siguiente tras un envío de prueba activo; almacenadas como archivos fuera del directorio web, con solo la referencia en la base de datos (scan_screenshots). Estructura del formulario: dirección de la página, selector, nombres de campo, tipos de campo, etiquetas de campo, indicadores de obligatoriedad y visibilidad, etiquetas de los botones de envío (forms, campo «mapa de campos»); sin valores de campo. El escáner solo lee durante la comprobación el inicio de los campos ocultos (hasta 24 caracteres) y de los atributos data (hasta 60 caracteres), para reconocer marcas de tiempo y tokens; solo se almacena el resultado. Resultados con pruebas (findings), resumen con los títulos de las páginas (scans). Si en el formulario aparece una dirección de correo electrónico como destinatario, solo se almacena su dominio, nunca la dirección. |
| Origen | Las páginas públicas del dominio del Cliente, obtenidas por el escáner. |
| Base jurídica (determinada por el responsable) | Determinada por el Cliente para el contenido de su propio sitio web. Para nosotros, el tratamiento forma parte de la comprobación encargada. |
| Destinatarios | El Cliente; en el caso de las agencias, su cliente a través del portal o de un informe de marca blanca; cualquiera que reciba un enlace a un informe (informes en direcciones aleatorias, no en buscadores). Cuando el tipo de formulario no está claro, un modelo de lenguaje local en nuestro propio servidor recibe la estructura del formulario con el título de la página, la dirección de la página y el texto visible del formulario (hasta 400 caracteres) para su clasificación; no recibe imágenes. |
| Tercer país | Ninguno. |
| Conservación | Resultados de las comprobaciones de un dominio durante un máximo de 13 meses; se mantiene la última comprobación completada de cada dominio (proceso nocturno de supresión, parte «resultados de comprobaciones antiguos»). Los formularios, los resultados, las referencias de imágenes y los archivos de imagen se suprimen con el resultado de la comprobación. Con el dominio, estos datos se suprimen de inmediato (cadena de supresión en B.15; excepciones en la sección 6.4). |
| Límites del enmascaramiento | Las capturas de pantalla de la comprobación completa no ocultan nada: muestran lo que la página muestra a cualquier visitante. Los campos del formulario están vacíos al obtenerlos, porque el escáner no introduce nada; los valores prerrellenados serían visibles. No se toman capturas de pantalla tras un inicio de sesión (A.5). Las imágenes de las comprobaciones con navegador ocultan los campos de entrada (A.6). |
| Medidas técnicas y organizativas | Sección 8. En particular: las imágenes solo pueden obtenerse a través del informe, y el identificador de imagen de otra persona devuelve «no encontrado»; informes con noindex; cada comprobación se ejecuta en su propio contenedor aislado. |
Los mismos datos se generan en las comprobaciones sin cuenta (comprobación gratuita, estudio, comprobación de posibles clientes). En ellas no hay ningún Cliente por cuya cuenta actuemos; por tanto, estos casos figuran en la parte B (B.5, B.7, B.8).
A.5 Credenciales de la cuenta de prueba para el escaneo tras el inicio de sesión
| Campo | Entrada |
| Finalidad | Leer formularios que solo aparecen tras iniciar sesión (área de clientes, área de socios). El escáner inicia sesión con una cuenta de prueba que el Cliente ha creado en su propio sitio web y lee las páginas indicadas. Aparte del formulario de inicio de sesión, no envía nada, no realiza allí ninguna prueba activa, no toma capturas de pantalla y no visita direcciones de cierre de sesión, eliminación o cancelación. Si el formulario de inicio de sesión tiene un CAPTCHA, se detiene; los CAPTCHA no se eluden. |
| Requisito previo | Dominio verificado, plan de pago, rol de titular o administrador, confirmación expresa de que la cuenta es una cuenta de prueba. Como máximo cinco páginas, todas del mismo dominio. |
| Categorías de interesados | La persona a cuyo nombre figura la cuenta de prueba (idealmente nadie; el Cliente debería utilizar una cuenta funcional); personas cuyos datos aparecen en las páginas tras el inicio de sesión. |
| Categorías de datos personales | Nombre de usuario y contraseña de la cuenta de prueba, solo cifrados; una pista del nombre de usuario (primer carácter y longitud); dirección de inicio de sesión, lista de páginas, nombres de los campos de inicio de sesión, indicador de éxito, persona que lo creó, horas, último resultado como código breve (domain_logins). Para un trabajo en curso, una copia del texto cifrado (campo «paquete de inicio de sesión» en scan_jobs). De las páginas tras el inicio de sesión: estructura del formulario como en A.4, sin capturas de pantalla y sin cookies. |
| Origen | Introducidos por el Cliente en la cuenta. |
| Base jurídica (determinada por el responsable) | Determinada por el Cliente. El Cliente garantiza que está facultado para utilizar la cuenta de prueba. |
| Destinatarios | Ninguno. Ni el Cliente, ni el soporte, ni la interfaz de programación pueden leer las credenciales; la interfaz solo muestra la pista del nombre de usuario. |
| Tercer país | Ninguno. |
| Protección de las credenciales | El nombre de usuario y la contraseña se cifran inmediatamente al almacenarse con la clave pública del servidor de escaneo (X25519, HKDF-SHA256, AES-256-GCM; el dominio se vincula como dato asociado, de modo que un texto cifrado no puede adjuntarse a otro dominio). Solo el servidor de escaneo tiene la clave privada. El servidor web, la base de datos y las copias de seguridad solo contienen texto cifrado; tampoco nosotros podemos descifrarlo allí. El servidor de escaneo solo descifra para la ejecución, transmite las credenciales al contenedor de comprobación aislado únicamente a través de la entrada estándar, suprime de inmediato la copia del trabajo y no las escribe en ningún resultado, registro ni texto de error. En el camino hacia el sitio web del Cliente solo están protegidas por el cifrado de dicho sitio web; los límites de este transporte se exponen en la sección 10. |
| Conservación | Credenciales almacenadas hasta que el Cliente las elimine. Al eliminarlas, el texto cifrado se sobrescribe con datos aleatorios de la misma longitud y se suprime la fila; se borran los trabajos en espera (fe_login_loeschen()). Con el dominio, la fila se suprime mediante una clave foránea. El servidor de escaneo borra las copias de los trabajos tras la ejecución; cualquier resto (trabajo abortado, servidor de escaneo caído) lo borra el proceso de estado a más tardar al cabo de una hora (fe_login_aufraeumen(), parte «login_jobs»). Las copias de seguridad de la base de datos contienen el texto cifrado hasta que la copia expira al cabo de 14 días. |
| Medidas técnicas y organizativas | Sección 8. En particular: cifrado asimétrico con claves separadas; lista de bloqueo para rutas de cierre de sesión y eliminación; sin capturas de pantalla tras el inicio de sesión; función solo para planes de pago y dominios verificados; cada cambio en el registro de actividad (sin credenciales). |
Deliberadamente no hemos creado ninguna forma de almacenar credenciales para el servidor del Cliente, el área de administración de su CMS o sus cuentas de alojamiento. La cuenta de prueba es una cuenta de visitante en el sitio web del Cliente, no un acceso al sistema del Cliente.
A.6 Recorridos de formulario configurados, comprobaciones con navegador y sonda independiente
| Campo | Entrada |
| Finalidad | Un formulario supervisado se recorre en un navegador real (Chromium, WebKit o ambos) hasta el momento inmediatamente anterior al envío: cargar la página, realizar los clics previos (como máximo cinco, nunca en un campo de entrada ni en un botón de envío), rellenar los campos con valores reconociblemente sintéticos (como una dirección bajo la terminación reservada .invalid), avanzar en formularios de varios pasos. La comprobación con navegador no envía nada; el envío está bloqueado técnicamente en el navegador. Además, mediciones de tiempo y comparaciones visuales del formulario. |
| Categorías de interesados | Como en A.4 (personas visibles en la página del formulario); personal del Cliente introducido como persona asignada (A.3). |
| Categorías de datos personales | Configuración: dirección del formulario, selectores, dirección de entrada, pasos de clic, elección de navegador, etiqueta, criticidad, asignación, fecha límite (monitored_forms). Resultados por ejecución: estado, motivo técnico del fallo, mensajes de error depurados, mediciones de red y de tiempo, una imagen del formulario como JPEG de como máximo 32 KB con los campos de entrada ocultos (form_browser_runs). Observaciones por comprobación (form_observations), series temporales (form_performance). Trabajos con una lista de destinos (campos «destinos» y «resultado» en scan_jobs). |
| Acceso de prueba | Si el Cliente ha almacenado una cuenta de prueba (A.5), la comprobación completa la utiliza también para los recorridos de formulario configurados. Según el código medido, las comprobaciones con navegador independientes entre dos comprobaciones completas funcionan sin cuenta de prueba. |
| Sonda independiente | Está prevista una segunda sonda en otra ubicación, que haría una verificación cruzada antes de una alerta. Recibiría el dominio, la configuración depurada y el identificador del trabajo, ninguna entrada de visitantes ni credenciales. Actualmente no está configurada (desactivada por defecto). Sin la sonda no hay pruebas desde una segunda ubicación; en tal caso, una alerta se basa en nuestra propia medición. |
| Origen | Configurado por el Cliente; resultados de la obtención de la página del Cliente. |
| Base jurídica (determinada por el responsable) | Determinada por el Cliente para el contenido de su sitio web y para las responsabilidades de su personal. |
| Destinatarios | El Cliente; si se configura una sonda, su operador (actualmente nadie). |
| Tercer país | Ninguno. |
| Conservación | Resultados de las ejecuciones con navegador, trabajos con navegador completados y series temporales al cabo de 13 meses (proceso nocturno de supresión, partes «browser_runs», «browser_jobs», «form_performance»). Configuraciones hasta que se elimine el dominio (individualmente pueden modificarse o desactivarse, no eliminarse); con el dominio se suprimen, junto con las ejecuciones, las observaciones y las series temporales, mediante claves foráneas. |
| Lo que prueba la medición | Tiempos y estados de nuestro navegador de comprobación. No miden lo que experimentan los visitantes reales ni prueban tasas de finalización ni consultas perdidas. |
| Medidas técnicas y organizativas | Sección 8. En particular: envío impedido técnicamente; solo direcciones del mismo dominio; imágenes con campos ocultos; contenedor de comprobación aislado. |
A.7 “Fix it for me” – código de formulario pegado
| Campo | Entrada |
| Finalidad | El Cliente pega el código de su formulario; un modelo de lenguaje en nuestro propio hardware integra el módulo de protección. Se devuelve el archivo modificado, un parche, el resultado de una comprobación de sintaxis y una indicación de si la llamada de comprobación se ha integrado realmente. Sin código pegado, el servicio entrega un módulo listo para usar con los nombres de campo del último escaneo. |
| Categorías de interesados | Personas cuyos datos figuran casualmente en el código pegado (como una dirección de destinatario, nombres en comentarios, credenciales de un servidor de correo). |
| Categorías de datos personales | El código pegado, como máximo 30.000 caracteres. En la base de datos, solo una entrada en el registro de actividad (acción «fix_ai» con espacio de trabajo y hora), que cuenta para el límite diario de actualmente diez llamadas por espacio de trabajo. |
| Origen | Pegado por el Cliente. |
| Base jurídica | Ejecución del contrato con el Cliente (art. 6(1)(b) RGPD) para el propio código; para los datos de terceros contenidos casualmente en él, el Cliente determina la base. |
| Destinatarios | Ninguno. El modelo de lenguaje se ejecuta en nuestro propio servidor de escaneo en la red interna; ningún servicio externo de IA, ni siquiera como alternativa. |
| Tercer país | Ninguno. |
| Conservación | El código no se almacena. Se crea un archivo temporal para la comprobación de sintaxis que se suprime inmediatamente después. La entrada del registro de actividad se suprime al cabo de 365 días. |
| Nota para el Cliente | El código que contenga contraseñas, claves de API o datos personales debe limpiarse antes de pegarlo. No comprobamos el contenido. |
| Medidas técnicas y organizativas | Sección 8. En particular: solo titulares y administradores en planes de pago; el código pegado se pasa al modelo marcado como datos y nunca se ejecuta; ninguna carga en servidores de terceros. |
A.8 Marca blanca y personas de contacto de la agencia
| Campo | Entrada |
| Finalidad | Los informes, informes breves, registros probatorios y el portal de cliente de una agencia (plan Business) aparecen bajo su marca y, si lo solicita, bajo un subdominio propio de la agencia. |
| Categorías de interesados | Personas de contacto de la agencia cuyo nombre o datos de contacto aparecen en la línea de contacto. |
| Categorías de datos personales | Nombre de la empresa, sitio web, línea de contacto, nota para el cliente, color de acento, apariencia, archivo del logotipo, interruptor para la referencia a formexposed, dominio propio con identificador de verificación y estado de verificación (workspace_branding). |
| Origen | Introducidos por la agencia. |
| Base jurídica | Ejecución del contrato con la agencia (art. 6(1)(b) RGPD). Cuando la línea de contacto menciona a personal de la agencia, la agencia determina la base. |
| Destinatarios | Cualquiera a quien la agencia facilite un enlace a un informe, informe breve o portal. |
| Tercer país | Ninguno. |
| Conservación | Hasta que la agencia los modifique; la marca y el archivo del logotipo se suprimen con el espacio de trabajo (fe_arbeitsbereich_daten_loeschen()). Un dominio propio cuya verificación DNS falle durante siete días se desactiva. El dominio propio está desactivado por defecto. |
| Medidas técnicas y organizativas | Sección 8. |
A.9 Recuentos, indicadores de estado y errores de campo del plugin y la extensión
| Campo | Entrada |
| Finalidad | Una vez al día, el plugin de WordPress y la extensión de TYPO3 comunican cifras sobre los formularios del sitio web conectado: envíos bloqueados por motivo, envíos, correos electrónicos enviados y fallidos, indicadores de estado de los ajustes del formulario, consultas almacenadas por origen y plazo de conservación. Opcional, desactivado por defecto: eventos de formulario y categorías de errores de campo por posición de campo. Estas cifras generan «Protección en cifras», el informe mensual, la alerta de silencio y los avisos sobre ajustes de riesgo. |
| Clasificación | Las cifras están diseñadas para no describir a ninguna persona. Las enumeramos en la parte A porque proceden de eventos en el sitio web del Cliente desencadenados por los visitantes del Cliente; en nuestra opinión, son datos personales a lo sumo en casos límite (un sitio web con muy pocos envíos en un día determinado). La propia transmisión (claves, versiones, host) figura en la parte B (B.20). |
| Categorías de interesados | Visitantes del sitio web del Cliente que envían un formulario. |
| Categorías de datos personales | Cifras diarias por host: bloqueados en total y por motivo, envíos, correos enviados y fallidos, categoría de error del envío de correo (solo una de cuatro categorías, nunca el texto del error, porque puede contener direcciones de destinatarios), recuentos de respuestas de reCAPTCHA, consultas suprimidas y liberadas (plugin_stats). Estado: versiones de una lista fija de plugins de formulario, CAPTCHA y correo, indicadores de ajustes como números, plazos de conservación (plugin_health). Notificaciones de cambios: nombre y versión de un plugin actualizado (plugin_changes). Opcional: contadores por formulario y día con categorías de error por posición de campo (form_metrics). Nunca: entradas, nombres de campo, contraseñas, archivos, direcciones de correo electrónico, nombres, direcciones IP ni identificadores persistentes de visitantes. |
| Origen | El plugin en el sitio web del Cliente, a través de una interfaz de programación mediante el secreto de conexión del sitio web. |
| Base jurídica (determinada por el responsable) | Determinada por el Cliente; el Cliente decide si activa los recuentos opcionales y cómo informa a sus visitantes. |
| Destinatarios | El Cliente. Los dominios de los enlaces de mensajes bloqueados pasan a la protección colectiva (B.21). |
| Tercer país | Ninguno. |
| Conservación | Cifras diarias, notificaciones de cambios y contadores de formularios al cabo de 13 meses (proceso nocturno de supresión, partes «plugin_stats» y «form_metrics»). Los indicadores de estado se sobrescriben con cada comunicación. Todos los datos del plugin de un host se suprimen en cuanto ningún dominio del sistema remite ya a ese host (de inmediato al eliminar el último dominio; los datos heredados, cada noche, parte «orphan_hosts»). |
| Lo que prueban las cifras | Lo que contó el plugin. No prueban tasas de finalización ni consultas perdidas. |
| Medidas técnicas y organizativas | Sección 8. En particular: aceptación solo con el par de claves vinculado del sitio web; solo se aceptan claves y números conocidos, todo lo demás se descarta; se rechazan los días fuera de una ventana de 14 días. |
A.10 Límite: lo que permanece solo en el sitio web del Cliente
Las siguientes funciones del plugin de WordPress y de la extensión de TYPO3 tratan datos exclusivamente en el servidor del Cliente. No nos llegan y no tenemos acceso a ellos. El único responsable es el operador del sitio web; el operador decide sobre la activación, los plazos de conservación y cómo informa a sus visitantes. Para ello, el plugin sugiere párrafos para la política de privacidad del operador.
| Función | Qué se trata localmente | Conservación en el lado del Cliente |
| Cuarentena | Envíos detenidos con el motivo, que pueden liberarse por correo electrónico a la dirección del sitio web | 14 días |
| Red de seguridad | Envíos cuyo correo electrónico de formulario falló, para su reenvío (activada por defecto) | 30 días |
| Acertijo aritmético en lugar de reCAPTCHA | Operación aritmética en el navegador del visitante, sin servicio de terceros (desactivado por defecto) | – |
| Ajustes de conservación | Supresión de las consultas almacenadas en los plugins de formulario tras el plazo elegido por el operador (desactivado por defecto) | según la configuración |
| Limitación de frecuencia | un identificador de corta duración derivado de la dirección IP, que no se nos transmite | corta duración |
| Contadores diarios locales | Valores de los contadores antes de la transmisión | como máximo 14 días |
| Grabador para administradores | selectores técnicos y pasos de navegación en el almacenamiento de sesión del navegador de un administrador con sesión iniciada; las entradas no se leen. Solo se transmite la configuración seleccionada (entonces A.6) | como máximo 15 minutos |
| Ayuda al visitante | puede activarse por separado; no almacena borradores y no reenvía automáticamente | – |
| Observación de nuevas reglas antispam | los aciertos adicionales se cuentan localmente, sin activación automática | siete días |
A.11 Protección de formularios (formconfirmed)
| Campo | Contenido |
| Finalidad | Evaluación de los envíos realizados a través de formularios de los sitios web del Cliente para reconocer los envíos automatizados: emisión y verificación de tareas (prueba de trabajo), tokens de verificación de un solo uso, tiempo de cumplimentación, campo trampa, solicitudes acumuladas; a petición del Cliente, evaluación del texto del mensaje por un modelo de lenguaje. Solo para los Clientes que activan la protección de formularios. |
| Categorías de interesados | Visitantes de los sitios web del Cliente que abren una página con un formulario protegido o lo envían. |
| Categorías de datos personales | Dirección IP (almacenada solo de forma abreviada y convertida en hash con una clave que cambia a diario), dirección y dominio de la página, momentos y tiempo de cumplimentación, campo trampa rellenado sí/no, identificador del navegador en el registro del servidor web; solo con la comprobación del contenido activada, el texto del mensaje (solo en la memoria de trabajo). |
| Origen | Navegador del visitante (tarea, token de verificación); servidor del Cliente (solicitud de verificación y, en su caso, texto). |
| Destinatarios | El Cliente (puntuación, acción, motivos). Ningún otro; ningún subencargado del tratamiento para este tratamiento. |
| Tercer país | Ninguno. |
| Conservación | Identificador convertido en hash, 1 hora; tokens de verificación utilizados, 11 minutos como máximo; resultados de la verificación sin dirección IP y sin texto, 30 días; cifras diarias, 400 días; registro del servidor web, 14 días; texto, ningún almacenamiento. |
| MTO | Sección 8; además, abreviación y hash con clave diaria, tareas firmadas, uso único, modelo de lenguaje en hardware propio sin registro del texto. |
4. Parte A – destinatarios, subencargados del tratamiento y transferencias a terceros países
La siguiente tabla enumera los destinatarios a los que recurrimos nosotros mismos y que pueden recibir datos de la parte A. La lista determinante y actualizada de forma continua es la página Subencargados del tratamiento; si difiere de esta tabla, se trata de una incidencia, no de una cuestión de formato.
| Destinatario | Qué recibe | Tercer país | Base | Estado |
| Namecheap, Inc. (Private Email), Phoenix, Arizona, USA | Buzón de control de la comprobación de entrega (A.1); envío de correos electrónicos de alerta (A.3), confirmaciones e informes a los suscriptores del portal (A.2) | Lugar de tratamiento pendiente de verificar; véase la página «Subencargados del tratamiento» | Contrato de encargo del tratamiento; base de la transferencia pendiente de verificar | Pendiente. El contrato correspondiente, los lugares reales de tratamiento y la base de la transferencia aún no están documentados. Este registro no confirma ni una certificación ni un contrato celebrado. |
| Namecheap, Inc. (registrador, DNS; reenvío de correo electrónico hasta que se configure el buzón) | Hasta que se configure el buzón, el correo entrante general a direcciones de nuestro dominio; no las copias de la comprobación de entrega, que solo llegan con registros MX que apunten directamente al buzón (A.1) | EE. UU. | pendiente de verificar: certificación conforme al Marco de Privacidad de Datos UE-EE. UU. o cláusulas contractuales tipo | En uso; base pendiente. |
| Nuestro propio servidor de escaneo con un modelo de lenguaje local | Estructura del formulario para su clasificación (A.4), código pegado (A.7), acceso de prueba descifrado solo durante la ejecución (A.5) | – | Gestionado por nosotros, no por un tercero | En uso. |
| Sonda independiente en una segunda ubicación | Dominio, configuración depurada, identificador del trabajo (A.6) | según la ubicación | por determinar antes de su puesta en marcha | No configurada. |
Alojamiento: ningún tercero. La aplicación, la base de datos, las capturas de pantalla y las copias de seguridad se conservan en nuestros propios servidores en Polonia. Si pasamos a un centro de datos o a un proveedor de nube, este párrafo deberá reescribirse.
4.1 Canales de alerta elegidos por el Cliente
Además de los destinatarios a los que recurrimos, existen canales que el Cliente elige para sus alertas (A.3). Nuestro servidor desencadena la transmisión; el Cliente determina el destino y el proveedor. La elección de un canal no nos exime de nuestras propias obligaciones como encargado del tratamiento. La función, el contrato y las garantías necesarias para terceros países deben determinarse para cada proveedor; en el caso de los servicios de chat, esto aún no se ha completado (cuestión pendiente para la revisión jurídica).
| Canal | Qué se envía | Sede del proveedor |
| Correo electrónico | Dominio, evento, explicación, enlace; a la dirección introducida | a través de Namecheap, Inc. (Private Email), Phoenix, Arizona, USA |
| Webhook a una dirección elegida libremente | Evento como JSON (dominio, eventos, líneas, enlace, marca de tiempo), firmado con el secreto del destino | determinada por el Cliente |
| Slack, Discord, Microsoft Teams, Google Chat | la misma notificación como mensaje de chat a la dirección de webhook introducida | predominantemente EE. UU. |
| Telegram | destino elegido por el Cliente; enviamos el mensaje a través de nuestro bot al ID de chat vinculado | fuera de la UE, sin decisión de adecuación; la base de la transferencia es una cuestión pendiente para la revisión jurídica |
En ningún caso se envía el contenido de un mensaje de un visitante. Las notificaciones contienen el dominio, el evento y el enlace.
5. Parte B – art. 30(1): tratamiento bajo nuestra propia responsabilidad
Responsable del tratamiento de todo lo incluido en esta parte: LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Polonia, contact@lukaswojcik.com. No se requiere representante (establecido en la Unión). No se ha designado delegado de protección de datos (sección 9). Medidas técnicas y organizativas: sección 8 y la página Medidas técnicas y organizativas. Cómo ejercen los interesados sus derechos se describe en la página Acceso, supresión y sus demás derechos; los titulares de cuentas pueden descargar ellos mismos sus datos como archivo (Ajustes).
Cuando nos basamos en intereses legítimos (art. 6(1)(f) RGPD), mencionamos el interés y el motivo por el que no basta un medio menos invasivo. La ponderación es nuestra evaluación; forma parte de la revisión jurídica.
B.1 Visitantes de nuestro sitio web – registros del servidor web
| Campo | Entrada |
| Finalidad | Funcionamiento y seguridad del sitio web y de la aplicación: entrega, resolución de incidencias, detección de ataques y sobrecargas. |
| Categorías de interesados | Toda persona que abre una página de formexposed.com o form.exposed, incluidos los visitantes de páginas de Clientes cuyo navegador carga nuestra imagen de distintivo (B.18), los destinatarios que abren un enlace de informe o de confirmación y los sitios web cuyo plugin llama a nuestra interfaz. |
| Categorías de datos personales | Dirección IP completa, hora, dirección solicitada, código de estado, bytes transferidos, página de procedencia (referente), identificación del navegador (user agent). |
| Dónde se almacenan | Registros de acceso del proxy previo y del servidor web como archivos en el servidor web, no en la base de datos. |
| Origen | El navegador o el programa que realiza la solicitud. |
| Base jurídica | Art. 6(1)(f) RGPD. Interés: funcionamiento seguro e ininterrumpido. Ponderación: sin la dirección completa, no pueden vincularse las solicitudes repetidas de un mismo remitente ni repelerse los ataques; una dirección truncada no permite esta distinción. Los registros no se combinan con otros datos y se suprimen al cabo de un breve plazo. |
| Destinatarios | Ninguno. |
| Tercer país | Ninguno. |
| Conservación | 14 días: rotación diaria con 14 generaciones, después se sobrescriben (servicio de rotación de registros del sistema, no el proceso nocturno de supresión de la aplicación). |
| Medidas técnicas y organizativas | Sección 8. |
B.2 Registro de visualizaciones de páginas de la aplicación
| Campo | Entrada |
| Finalidad | Seguridad y detección de abusos (quién solicita qué y con qué frecuencia), trazabilidad de los accesos a las cuentas, estadísticas de uso sencillas sin servicio de analítica. |
| Categorías de interesados | Todos los visitantes del sitio web y usuarios de la aplicación en visualizaciones de páginas reales (sin solicitudes en segundo plano ni envíos de formularios). |
| Categorías de datos personales | Dirección IP completa, el país derivado de ella al escribir (base de datos geográfica local, sin consulta a terceros), ID de cuenta de los usuarios con sesión iniciada, dirección solicitada y página de procedencia (con los tokens de acceso que contengan, como los de los enlaces de informes o portales, enmascarados), identificación del navegador y el tipo de dispositivo, sistema operativo y navegador derivados de ella, idioma, hora (access_logs). Durante «Ver como cliente» (B.14) no se establece ningún ID de cuenta, para que las visualizaciones de páginas del soporte no aparezcan en el registro del Cliente. |
| Origen | La solicitud del navegador. |
| Base jurídica | Art. 6(1)(f) RGPD. Interés: prevención de abusos y trazabilidad. Ponderación: como en B.1; el plazo de conservación es más largo porque los patrones de abuso se hacen visibles a lo largo de semanas. Si debe truncarse la dirección IP o acortarse el plazo de conservación es una cuestión pendiente para la revisión jurídica. |
| Destinatarios | Ninguno. Los titulares de cuentas reciben sus propias visualizaciones de páginas en la exportación de datos. |
| Tercer país | Ninguno. |
| Conservación | 60 días (cada noche entre las 03:00 y las 03:05, srv/cron_status.php, ajuste «registro de visualizaciones de páginas»). |
| Medidas técnicas y organizativas | Sección 8. La dirección IP solo se toma de una cabecera reenviada si la solicitud procede de nuestro propio proxy previo, y en tal caso solo la entrada añadida por dicho proxy; de lo contrario, cualquiera podría indicar su origen a voluntad. |
B.3 Cookies y almacenamiento en el navegador
| Campo | Entrada |
| Finalidad | Almacenamiento técnicamente necesario: sesión, protección contra la falsificación de solicitudes entre sitios (CSRF), recuento de los límites de las comprobaciones sin cuenta, inicio de sesión, mantener la sesión iniciada si se solicita, visualización clara u oscura. |
| Categorías de interesados | Visitantes y usuarios de formexposed.com. |
| Categorías de datos personales | Cookie de sesión bpid (identificador de sesión; finaliza al cerrar el navegador; HttpOnly, SameSite=Lax, Secure por HTTPS). Cookie bp_remember solo tras elegir «Mantener la sesión iniciada» (selector y verificador; 30 días). Almacenamiento local bp_theme (claro, oscuro o sistema). En el área de administración, además, ajustes de visualización locales de los operadores. Para los límites, se forma un hash a partir del identificador de sesión; el propio identificador no se almacena. |
| No se establecen | Ninguna cookie de analítica, publicidad o seguimiento. El programa de socios (B.33) funciona sin cookie. La imagen del distintivo en las páginas de los Clientes no establece ninguna cookie (B.18). reCAPTCHA puede establecer cookies de Google cuando se envía un formulario protegido (B.23). |
| Base jurídica | Acceso al equipo terminal: estrictamente necesario para el servicio solicitado por el usuario (§ 25(2) n.º 2 TDDDG, la Ley alemana de protección de datos en telecomunicaciones y servicios digitales; art. 399(3) PKE, la Ley polaca de comunicaciones electrónicas (Prawo komunikacji elektronicznej)). Tratamiento: art. 6(1)(b) RGPD (cuenta) y (f) (seguridad, límites). |
| Destinatarios | Ninguno. |
| Tercer país | Ninguno. |
| Conservación | Sesión; 30 días para el token de recordatorio. El proceso nocturno suprime los tokens de recordatorio caducados en la base de datos (remember_tokens); al cerrar sesión, cambiar la contraseña o revocar un dispositivo, de inmediato. |
| Medidas técnicas y organizativas | Sección 8. |
B.4 Comprobación gratuita sin cuenta – aceptación, límites y supervisión de abusos
| Campo | Entrada |
| Finalidad | Cualquiera puede hacer comprobar un dominio sin cuenta. Para que el campo de entrada no se convierta en un arma contra sitios web de terceros, se aplican límites escalonados: una comprobación anónima por dominio en siete días (después, el mismo informe), límites por dirección IP y por sesión en 24 horas, un límite diario para todo el sistema, un bloqueo de los dominios muy recientes, lista de bloqueo y opt-out, solo direcciones públicas. Los patrones llamativos se registran y se notifican al operador. Los límites por dirección IP, por sesión y para todo el sistema, contados cada uno por separado, se aplican también a la comprobación desde el plugin sin cuenta (un plugin con un par de claves vinculado cuenta por sitio web en lugar de por dirección) y al opt-out (B.30); la herramienta gratuita de cabeceras (B.9) tiene sus propios límites por dirección IP y día y para todo el sistema. |
| Categorías de interesados | Personas que inician una comprobación, una solicitud de la herramienta de cabeceras o un opt-out; servidores en los que está instalado un plugin. |
| Categorías de datos personales | Registro de cada solicitud: origen (comprobación, plugin, herramienta de cabeceras, opt-out), dirección IP completa, hash del identificador de sesión, host comprobado, país de la dirección IP, aceptada o rechazada con el motivo, hora (check_throttle). Anomalías: tipo (dirección IP, sesión, país, sistema), clave (para el tipo «IP», la dirección IP completa), patrón, gravedad, breve descripción, horas de detección y resolución, persona que la resuelve (abuse_flags). Trabajo: host, modo, nivel de confianza y un hash de sesión truncado como identificador del solicitante (scan_jobs). Informe: identificador aleatorio, host, idioma, caducidad, primera visualización, número de visualizaciones (reports). Antigüedad del dominio almacenada en caché de la consulta al registro (domain_age_cache). |
| Origen | Lo introducido por la persona; su solicitud; consulta al registro (RDAP) para la antigüedad del dominio. |
| Base jurídica | Realización de la comprobación solicitada: art. 6(1)(b) RGPD (uso de la comprobación gratuita conforme a las Condiciones del servicio); subsidiariamente, (f). Límites y supervisión: art. 6(1)(f). Interés: impedir que el servicio se utilice como herramienta contra sitios web de terceros o como cañón de spam. Ponderación: sin vincularlo a la dirección y a la sesión, los límites no podrían hacerse cumplir; el plazo de siete días es tan breve como el límite más largo que se cuenta a partir de él. |
| Destinatarios | Google (reCAPTCHA al enviar, B.23). Para la antigüedad del dominio, el escáner consulta el servicio de redirección RDAP rdap.org, que remite al registro responsable; solo se transmite el nombre de dominio. Cuando se produce una anomalía, el operador recibe una señal a través de Telegram sin ninguna variable (sin host, sin dirección). El informe puede verlo quien tenga su enlace aleatorio. |
| Tercer país | EE. UU. a través de reCAPTCHA (B.23). |
| Conservación | Registro de solicitudes 7 días (cada noche, srv/cron_status.php). Anomalías resueltas, 90 días después de su resolución; las no resueltas permanecen hasta que alguien las resuelva (sección 10). Los informes anónimos caducan al cabo de 30 días; el proceso nocturno suprime entonces el informe, el trabajo, el resultado de la comprobación, los formularios, los resultados y las imágenes (fe_reports_aufraeumen()). Un administrador puede liberar manualmente las entradas de una dirección; esto suprime su registro de las últimas 24 horas. |
| Medidas técnicas y organizativas | Sección 8. Parada de emergencia para todas las comprobaciones anónimas en el área de administración; contrapresión que no acepta nuevas comprobaciones gratuitas cuando hay acumulación. |
B.5 Comprobación de sitios web de terceros por el rastreador
| Campo | Entrada |
| Finalidad | Comprobación de seguridad de formularios de contacto públicos: protecciones contra el spam y los abusos, características de protección de datos y accesibilidad, scripts de terceros integrados, comportamiento tras el rechazo en el banner de cookies, visualización móvil. Se aplica a las comprobaciones sin cuenta (B.4), a los dominios de una cuenta que aún no están verificados y como base del estudio (B.7) y de la comprobación de posibles clientes (B.8). Para los dominios verificados de una cuenta, actuamos por cuenta del Cliente (A.4). |
| Comportamiento del rastreador | Identificador propio con referencia a la página del rastreador; lee robots.txt antes de la comprobación y se detiene si una regla disallow abarca la página de inicio (igualmente si robots.txt no es accesible o se produce un error de servidor); las reglas disallow para subrutas concretas no se respetan por separado. El pulso del formulario, la obtención de la acreditación, la herramienta de cabeceras y la búsqueda de archivos expuestos no leen robots.txt. Como máximo ocho páginas públicas por comprobación, más hasta tres páginas con un clic en «Rechazar» en el banner de cookies, hasta tres páginas en vista de móvil, sondeos activos para dominios verificados y hasta cinco páginas tras un inicio de sesión (A.5); las páginas se cargan una tras otra, no en paralelo; solo direcciones públicas, ninguna red interna, las redirecciones se comprueban de nuevo; la lista de bloqueo y el opt-out se comprueban antes de la aceptación y una segunda vez en el escáner. Pasivo: sin acreditación del control, no se envía nada para los Clientes (excepción: comprobaciones internas de nuestros propios dominios de prueba y demostración, B.6). |
| Categorías de interesados | Operadores de los sitios web comprobados (cuando son personas físicas, como empresarios individuales); personas que resultan visibles en las páginas comprobadas. |
| Categorías de datos personales | Como en A.4: direcciones y títulos de las páginas, estructura de los formularios (nombres, tipos y etiquetas de campo, sin valores de campo), protecciones, scripts de terceros (direcciones; los ID de cuenta de píxeles y herramientas de grabación se sustituyen antes del almacenamiento), comportamiento del banner de cookies, capturas de pantalla (área visible de la página de inicio, formularios). Si en el formulario aparece una dirección de destinatario, solo su dominio (scans, forms, findings, scan_screenshots). |
| Origen | Páginas accesibles públicamente. |
| Base jurídica | Art. 6(1)(f) RGPD. Interés: realizar la comprobación de seguridad solicitada; alertar a los operadores de sitios web de debilidades que puedan perjudicar a sus visitantes. Ponderación: solo se lee lo que ve cualquier visitante, en pequeña medida y sin enviar nada; el operador puede excluir su dominio de forma permanente en cualquier momento sin acreditación. La información conforme al art. 14 RGPD se facilita a través de la página del rastreador, el opt-out y la Política de privacidad; si esto es suficiente conforme al art. 14(5)(b) es una cuestión pendiente para la revisión jurídica. |
| Destinatarios | Quien inicia el informe y cualquiera a quien facilite el enlace aleatorio; el modelo de lenguaje local en nuestro propio servidor cuando el tipo de formulario no está claro (estructura del formulario, título y dirección de la página, texto visible del formulario). Las advertencias de vulnerabilidades derivadas de versiones de plugins nunca aparecen en los informes anónimos. |
| Tercer país | Ninguno. |
| Conservación | Anónimo: 30 días (B.4). Comprobación de posibles clientes: 90 días (B.8). Estudio: hasta su publicación (B.7). Dominio en una cuenta: como máximo 13 meses, se mantiene la última comprobación; de inmediato con el dominio. Comprobaciones internas del operador sin dominio y sin informe (como las creadas desde la línea de comandos): sin plazo de conservación (sección 10). Los archivos temporales del servidor de escaneo se suprimen tras cada ejecución. |
| Medidas técnicas y organizativas | Sección 8. En particular: contenedor de comprobación independiente con privilegios reducidos, sistema de archivos de solo lectura, límite de memoria y red propia; doble comprobación del destino. |
B.6 Envíos de prueba activos
| Campo | Entrada |
| Finalidad | Comprobar si un formulario de contacto acepta un envío sin protección, si el CAPTCHA, la trampa (honeypot), el token, la validación de la dirección de correo electrónico y la limitación de frecuencia surten efecto en el lado del servidor, y si pueden inyectarse cabeceras. |
| Requisito previo | Para los Clientes, solo en dominios para los que se ha acreditado el control (registro DNS, metaetiqueta, archivo o plugin conectado); además, el operador utiliza una herramienta interna de línea de comandos para crear comprobaciones con el nivel «verificado» para nuestros propios dominios de prueba y demostración. Solo con el interruptor global activado, solo para un formulario clasificado de forma fiable como formulario de contacto general. Nunca para pedidos, reservas, registros, boletines, pagos, cargas de archivos, campos obligatorios con datos personales reales ni dominios de autoridades públicas, instituciones sanitarias o educativas. |
| Categorías de interesados | Personal del Cliente que recibe los correos electrónicos del formulario. |
| Categorías de datos personales | El envío de prueba no contiene datos personales: remitente “FormExposed Security Scanner”, nuestra propia dirección de remitente o una dirección bajo .invalid, un asunto identificado y un texto en el idioma de la página con una referencia a la página del rastreador y al opt-out y el número de la comprobación. Almacenado por nosotros: la respuesta de la página, los resultados, una imagen de la página siguiente (como en A.4). |
| Alcance | Como máximo cinco envíos por comprobación (ajuste, por defecto 5); de forma periódica con la frecuencia de comprobación del plan, a diario en el plan superior. |
| Origen | La instrucción del Cliente. |
| Base jurídica | Ejecución del contrato con el Cliente (art. 6(1)(b) RGPD); los envíos van al propio formulario del Cliente. Para los destinatarios en el lado del Cliente: la organización del Cliente. |
| Destinatarios | El Cliente (su correo electrónico de formulario). |
| Tercer país | Ninguno a través de nosotros. |
| Conservación | Resultados como en A.4. |
| Medidas técnicas y organizativas | Sección 8. La inyección de cabeceras solo se detecta, nunca se ejecuta con un destinatario real; la validación de la dirección de correo electrónico solo utiliza un dominio que no puede existir. |
B.7 Estudio «Índice de seguridad de formularios»
| Campo | Entrada |
| Finalidad | Estadísticas sobre la protección de los formularios de contacto en un país o sector. Solo se publican totales, sin nombres de sitios web; segmentos solo a partir de 20 páginas con formulario. |
| Categorías de interesados | Operadores de los sitios web de la lista; personas visibles de forma incidental. |
| Categorías de datos personales | Como en B.5, solo pasivo. Además, la lista: host, segmento, estado, trabajo (study_domains); estudio con título, país, totales de resultados (studies). |
| Origen | Una lista de sitios web públicos elaborada por el operador; las propias páginas. |
| Base jurídica | Art. 6(1)(f) RGPD. Interés: afirmaciones estadísticas sobre el estado de la seguridad de los formularios. Ponderación: pasivo, limitado (pocos trabajos por ejecución), se aplican la lista de bloqueo y el opt-out, publicación solo como totales, los datos en bruto se suprimen. |
| Destinatarios | El público, solo totales. |
| Tercer país | Ninguno. |
| Conservación | Los datos en bruto (resultados de las comprobaciones, formularios, resultados, imágenes, trabajos) se suprimen al publicarse (fe_studie_veroeffentlichen()). La lista de hosts con segmento permanece después; no existe plazo de conservación para ella ni para los estudios que nunca se publican (sección 10). El operador decide qué listas se comprueban y si se publican los estudios. |
| Medidas técnicas y organizativas | Sección 8. |
B.8 Comprobación de posibles clientes (modo de captación para agencias)
| Campo | Entrada |
| Finalidad | Una agencia (plan Business) comprueba de forma pasiva el sitio web de un posible cliente y recibe un informe breve bajo su marca y el informe pasivo. Nosotros no nos ponemos en contacto con nadie; la agencia transmite ella misma el enlace. |
| Categorías de interesados | Operador del sitio web comprobado; personas visibles de forma incidental; personal de la agencia que inicia la comprobación. |
| Categorías de datos personales | Como en B.5, solo pasivo. Además: espacio de trabajo, persona que inicia la comprobación, host, identificador aleatorio del informe, hora (prospect_checks). |
| Origen | Lo introducido por la agencia; páginas públicas. |
| Base jurídica | Art. 6(1)(f) RGPD (nuestro interés en prestar el servicio y el interés de la agencia en un acercamiento fundamentado). Las funciones de la agencia y de nosotros y las obligaciones de la agencia al transmitir el informe son cuestiones pendientes para la revisión jurídica: si la agencia envía el informe por correo electrónico sin que se lo hayan solicitado o realiza una llamada telefónica, se trata de marketing directo que requiere consentimiento conforme al art. 398 PKE y al § 7(2) UWG (la Ley alemana contra la competencia desleal), incluso entre empresas. Ello es responsabilidad de la agencia; las Condiciones del servicio la obligan en consecuencia. |
| Destinatarios | La agencia y cualquiera a quien esta facilite el enlace. |
| Tercer país | Ninguno. |
| Conservación | El informe y el resultado de la comprobación caducan al cabo de 90 días y el proceso nocturno los suprime entonces (fe_reports_aufraeumen()); la entrada de la comprobación se suprime al cabo de 90 días en el proceso colectivo diario a partir de las 04:00 (srv/cron_status.php). Con el espacio de trabajo, de inmediato. |
| Medidas técnicas y organizativas | Sección 8. Cuota mensual (ajuste, por defecto 30); la misma página dentro de un plazo de siete días devuelve el mismo informe; se aplica el opt-out. |
B.9 Herramienta de cabeceras sin cuenta
| Campo | Entrada |
| Finalidad | Calificación gratuita (de A+ a F) de las cabeceras de seguridad de la página de inicio de un dominio. Dos solicitudes, sin navegador, sin formulario, sin envío. |
| Categorías de interesados | Personas que utilizan la herramienta; operadores del dominio comprobado. |
| Categorías de datos personales | Registro de solicitudes como en B.4 (origen «headers», dirección IP, hash de sesión, host). Resultado: host, calificación, puntos, cabeceras evaluadas (header_checks). |
| Base jurídica | Art. 6(1)(f) RGPD, como en B.4 y B.5. |
| Destinatarios | Google (reCAPTCHA, B.23). |
| Tercer país | EE. UU. a través de reCAPTCHA. |
| Conservación | Registro de solicitudes 7 días; resultados al cabo de actualmente 90 días (proceso nocturno de supresión, parte «header_checks», ajuste «headers_keep_days»). Para los dominios de una cuenta, la calificación se vuelve a determinar a diario y se almacena con el dominio. |
| Medidas técnicas y organizativas | Sección 8. Límites por dirección IP y día; se aplica el opt-out. |
B.10 Cuentas de cliente
| Campo | Entrada |
| Finalidad | Gestión de cuentas de cliente, espacios de trabajo y planes. |
| Categorías de interesados | Clientes (empresas) y los miembros de sus equipos con cuenta propia. |
| Categorías de datos personales | Dirección de correo electrónico y forma normalizada, contraseña solo como hash, nombre (obligatorio), apellidos y empresa (si se facilitan); la aplicación no almacena la dirección ni el NIF-IVA, que solo se facilitan en Stripe (B.26); estado, idioma, modo de visualización, moneda, plan y estado de facturación, ID de cliente y de suscripción de Stripe, fin del periodo de facturación, cancelación al final del periodo, identificadores de confirmación y restablecimiento con caducidad, nueva dirección de correo electrónico hasta su confirmación, hora del registro, último inicio de sesión y última dirección IP, hora en que se revocaron todas las sesiones, datos del segundo factor (B.11), informe mensual activado/desactivado, hora del correo de recordatorio, desbloqueos mediante códigos, código de referencia y referencia (users). Espacios de trabajo con nombre, horas, estado (workspaces); pertenencia con rol y fecha de incorporación (workspace_users). |
| Origen | Registro y ajustes realizados por la persona; estado de facturación procedente de Stripe. |
| Base jurídica | Art. 6(1)(b) RGPD (contrato). Última dirección IP: (f) (seguridad de la cuenta). |
| Destinatarios | Stripe (B.26); proveedor de servicios de correo para los correos de la cuenta (B.25). Los miembros del mismo espacio de trabajo ven el nombre, la dirección de correo electrónico y el rol de los demás miembros. |
| Tercer país | A través de Stripe y del proveedor de servicios de correo. |
| Conservación | Hasta que el titular de la cuenta la elimine. Al eliminarla, los espacios de trabajo propios del titular que nadie más utiliza se suprimen con todos los dominios y sus datos; los espacios de trabajo con otros miembros pasan a otro miembro, primero a los administradores y, entre ellos, al más antiguo. Se suprimen las pertenencias, los tokens de recordatorio, los dispositivos, las claves de API, los códigos de Telegram abiertos, las valoraciones de informes (B.35) y la fila de la cuenta; una suscripción de pago en curso se finaliza primero de inmediato en Stripe, sin reembolso (www/ajax.php, fe_konto_reste_loeschen()). En cambio, una cancelación en el área de facturación surte efecto al final del periodo; después, la cuenta continúa con el plan gratuito. Lo que permanece se expone en la sección 6.4. Las cuentas nunca confirmadas y en las que nunca se ha iniciado sesión se suprimen al cabo de 30 días, salvo que haya otro miembro vinculado a su espacio de trabajo (proceso nocturno de supresión, parte «pending_accounts»). No existe supresión de cuentas inactivas. Si el contrato de la cuenta finaliza de otro modo, por ejemplo por nuestra resolución, eliminamos la cuenta a más tardar 30 días después del final del contrato; actualmente esto se realiza manualmente (compromiso asumido en el Contrato de encargo del tratamiento). |
| Medidas técnicas y organizativas | Sección 8. |
B.11 Inicio de sesión, dispositivos, segundo factor y registro de actividad
| Campo | Entrada |
| Finalidad | Proteger las cuentas: limitar los intentos de inicio de sesión y otros intentos de contraseña, mostrar y revocar los dispositivos con sesión iniciada, inicio de sesión con segundo factor, trazabilidad de los cambios. |
| Categorías de interesados | Titulares de cuentas y miembros del equipo; personas que intentan un inicio de sesión, un registro o la contraseña de un portal de cliente. |
| Categorías de datos personales | Intentos de inicio de sesión: dirección IP, dirección de correo electrónico introducida, éxito, hora (login_attempts). Dispositivos: hash del identificador de sesión (nunca el propio identificador), vínculo al token de recordatorio, dirección IP, identificación del navegador y el navegador, sistema operativo y tipo de dispositivo derivados de ella, horas del inicio de sesión, de la última actividad y de la revocación y, en el caso de «Ver como cliente», el identificador de la persona de soporte (login_sessions). Tokens de recordatorio para «Mantener la sesión iniciada»: selector, verificador, caducidad (remember_tokens). Segundo factor: secreto cifrado, hora de activación, último intervalo de tiempo utilizado, códigos de recuperación solo como hash (en users). Registro de actividad: cuenta, espacio de trabajo, acción, objetivo, detalles, dirección IP, país, hora (audit_logs). Contadores de intentos para el inicio de sesión, el segundo factor, la confirmación de contraseña, el restablecimiento de contraseña, el registro y las contraseñas de los portales de cliente: una clave HMAC derivada de la finalidad y del ID de cuenta (para una dirección desconocida o para un restablecimiento, la dirección de correo electrónico en minúsculas), la dirección IP, la cuenta y la dirección IP conjuntamente, o el ID del portal (también conjuntamente con la dirección IP), número de intentos, caducidad; las direcciones de correo electrónico e IP no se almacenan allí en texto claro (tabla auth_attempt_buckets). |
| Base jurídica | Art. 6(1)(b) RGPD en relación con el art. 32 (lista de dispositivos, segundo factor) y (f) (intentos de inicio de sesión, registro de actividad). Interés: proteger las cuentas frente a su usurpación, documentar los cambios (art. 5(2)). Ponderación: una dirección truncada no responde a la pregunta «¿fui yo?»; el registro de actividad debe sobrevivir a una controversia que surja solo meses después. |
| Destinatarios | Ninguno. El titular de la cuenta ve sus dispositivos y recibe los intentos de inicio de sesión, los dispositivos y las actividades en la exportación de datos; durante una sesión de «Ver como cliente», no aparecen allí ni la dirección IP ni el navegador de la persona de soporte. |
| Tercer país | Ninguno. |
| Conservación | Intentos de inicio de sesión 7 días; tras un inicio de sesión correcto, los intentos fallidos desde la misma dirección se suprimen de inmediato. Contadores de intentos al final de su ventana temporal (actualmente 15 minutos, una hora para el restablecimiento de contraseña y el registro); los caducados se suprimen en el siguiente acceso y en el proceso nocturno. Dispositivos 90 días después del último uso o de la revocación (proceso nocturno de supresión, parte «sessions»), de inmediato con la cuenta. Los tokens de recordatorio caducan al cabo de 30 días. Registro de actividad 365 días (cada noche); cuando se elimina una cuenta, sus entradas permanecen hasta el final del plazo de conservación (sección 6.4). |
| Medidas técnicas y organizativas | Sección 8. |
B.12 Prueba de la celebración del contrato
| Campo | Entrada |
| Finalidad | Demostrar qué versión de las Condiciones del servicio, del Contrato de encargo del tratamiento y de la Política de privacidad aceptó o conoció un Cliente al registrarse, y que el Cliente utiliza el servicio para su actividad empresarial. |
| Categorías de interesados | Clientes. |
| Categorías de datos personales | Por documento: cuenta, documento, versión (hash del texto mostrado), ocasión, dirección IP, identificación del navegador, hora (legal_consents). La propia versión mostrada con el texto completo, el idioma, el título y la dirección, una vez por versión (legal_versions; no contiene datos personales). |
| Base jurídica | Art. 6(1)(b) y (f) RGPD (prueba de la celebración del contrato, defensa frente a reclamaciones). |
| Destinatarios | Ninguno. El titular de la cuenta recibe sus registros en la exportación de datos. |
| Tercer país | Ninguno. |
| Conservación | Mientras exista la cuenta; tras la eliminación de la cuenta, cuatro años desde el consentimiento, después se suprime cada noche (srv/cron_status.php). Justificación en el código: plazo de prescripción de tres años desde el final del año, redondeado al alza. Si el Derecho polaco sugiere un plazo distinto forma parte de la revisión jurídica. |
| Medidas técnicas y organizativas | Sección 8. Si falta cualquiera de los tres documentos, el registro queda cerrado. |
B.13 Invitaciones al equipo
| Campo | Entrada |
| Finalidad | Invitar a otras personas a un espacio de trabajo. |
| Categorías de interesados | Personas invitadas. |
| Categorías de datos personales | Dirección de correo electrónico, rol, identificador de la invitación, persona que invita, caducidad, hora de aceptación (workspace_invites); el correo de invitación en la bandeja de salida (B.25). |
| Origen | Introducidos por el miembro que invita. |
| Base jurídica | Art. 6(1)(b) RGPD en relación con el Cliente; frente a la persona invitada, (f) (interés del Cliente en involucrar a su equipo). |
| Destinatarios | Proveedor de servicios de correo (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA). |
| Tercer país | A través del proveedor de servicios de correo. |
| Conservación | Una invitación es válida durante 14 días y solo mientras la persona que invita sea titular o administrador del espacio de trabajo. Las invitaciones no aceptadas, tras su caducidad; las aceptadas, 30 días después de su aceptación (cada noche, srv/cron_status.php y parte «invites» en cfg/fristen_lib.php). Con el espacio de trabajo, de inmediato. |
| Medidas técnicas y organizativas | Sección 8. |
B.14 «Ver como el Cliente» por parte del soporte
| Campo | Contenido |
| Finalidad | Un superadministrador ve la aplicación tal como la ve un Cliente para resolver una consulta de soporte («a mí no me aparece el botón»). |
| Categorías de interesados | El Cliente afectado; el superadministrador. |
| Categorías de datos personales | Todo lo que el Cliente ve en la aplicación. Se registra: una fila de dispositivo independiente con el identificador del superadministrador (login_sessions), y el inicio y el fin en el registro de actividad (audit_logs). |
| Base jurídica | Art. 6(1)(b) RGPD (soporte como parte del servicio), subsidiariamente la letra f). |
| Límites | Como máximo una hora; después, cierre de sesión completo. Al finalizar la vista, el superadministrador también queda desconectado por completo, incluida la sesión desde la que accedió; solo vuelve al área de administración iniciando sesión de nuevo con contraseña y segundo factor. Finaliza de inmediato si el superadministrador es degradado o bloqueado. Todo lo que modifica la cuenta del Cliente está bloqueado: contraseña, dirección de correo electrónico, segundo factor, dispositivos, suscripción, exportación, eliminación, transferencia. El área de administración permanece cerrada durante la sesión. El Cliente ve el acceso en su lista de dispositivos y en la exportación de datos como acceso de soporte. |
| Destinatarios | Ninguno. |
| Tercer país | Ninguno. |
| Conservación | Fila de dispositivo 90 días, registro de actividad 365 días. |
| MTO | Sección 8. |
B.15 Dominios, prueba de control y monitorización
| Campo | Contenido |
| Finalidad | El servicio principal para los Clientes: mantener dominios en la cuenta, aportar la prueba de control, comprobar periódicamente y detectar cambios. Esto incluye el pulso del formulario (una solicitud ligera sin navegador cada 10 a 30 minutos según el plan), la vigilancia diaria del DNS de correo y de los certificados, la fecha de caducidad del dominio, las listas de bloqueo, los archivos expuestos, las versiones visibles desde fuera, el inventario de scripts, los cambios visuales en el formulario, las interrupciones de los proveedores de CAPTCHA y de correo, y la vigilancia de vulnerabilidades de los plugins de formularios. |
| Categorías de interesados | Clientes y los miembros de sus equipos; titulares de los dominios, cuando sean personas físicas. |
| Categorías de datos personales | Dominio con host, identificador público, nota, etiqueta del cliente, tipo e identificador de la prueba, frecuencia de comprobación, monitorización activada/desactivada, ventanas de mantenimiento, valor por consulta, identificadores del distintivo, de la comprobación de entrega y del deploy hook, clave del plugin, estados y últimos resultados de las vigilancias (DNS, certificado, autenticidad del correo electrónico del formulario, listas de bloqueo, archivos expuestos, cabeceras, versiones) (domains). Pulso por página de formulario (form_pulse). Vulnerabilidades derivadas de las versiones de plugins (vuln_hits). Inventario de scripts con dirección, hash, tamaño, aprobación con la persona que aprueba y el motivo (script_inventory, script_changes). Comprobaciones como en A.4. En el caso de archivos expuestos se almacenan la ruta, la gravedad y el tipo, nunca el contenido. |
| Solicitudes a terceros | Consultas DNS (SPF, DMARC, MX, registro de prueba). Consulta al registro mediante RDAP según el directorio de la IANA: solo el nombre de dominio. Listas de bloqueo DNS (SpamCop, PSBL, Mailspike, SURBL; Spamhaus solo con credenciales de acceso almacenadas, actualmente no): direcciones IP del servidor web y del servidor de correo y el nombre de dominio, ningún dato de visitantes. Google Web Risk solo si está configurado (actualmente no): la dirección de la página de inicio. Autoridad de sellado de tiempo: solo un valor hash (B.19). WPVulnerability: solo el identificador de un plugin o tema, o la versión de WordPress; la comparación con la versión del plugin instalada la realizamos nosotros mismos. Páginas de estado de Cloudflare, hCaptcha, Google Cloud, SendGrid, Mailgun y Brevo: no se transmite nada salvo la propia solicitud. |
| Origen | Cliente; solicitudes a la página del Cliente; directorios públicos. |
| Base jurídica | Art. 6(1)(b) RGPD. |
| Destinatarios | Los servicios mencionados no reciben datos personales de nuestros Clientes, en la medida en que los nombres de dominio y las direcciones de servidor de una empresa no son datos personales; en el caso de empresarios individuales, el nombre de dominio puede constituir un dato personal. Los miembros del espacio de trabajo ven el dominio. |
| Tercer país | Las solicitudes pueden llegar a servicios situados en terceros países (por ejemplo, consultas al registro, listas de bloqueo). Solo se transmite lo indicado en la fila «Solicitudes a terceros». |
| Conservación | Hasta que se elimina el dominio. A continuación, fe_domain_loeschen() elimina de inmediato los resultados de las comprobaciones, formularios, hallazgos, imágenes, informes, tareas, destinos de alerta y registro de alertas, incidencias, códigos de Telegram, entregas, pulso, vulnerabilidades y pruebas; mediante claves externas, los formularios monitorizados, las ejecuciones de navegador, la cuenta de prueba y los contadores de formularios; los datos del plugin del host si ningún otro dominio hace referencia a él. También se eliminan el inventario de scripts y los cambios de scripts del dominio; no tienen un plazo de conservación propio (sección 6.4). Resultados de las comprobaciones como máximo 13 meses; el último se conserva. |
| MTO | Sección 8. Vigilancia de archivos expuestos y de versiones solo para dominios verificados, como máximo una solicitud por ruta y solo los primeros 8 KB; sondear rutas de terceros sin que lo hayan solicitado sería una herramienta de ataque. |
B.16 Alertas, incidencias y escalado frente al titular de la cuenta
| Campo | Contenido |
| Finalidad | Informar al Cliente sobre fallos y cambios, respetar las ventanas de mantenimiento, confirmar y escalar incidencias. Cuando los destinatarios son terceros, actuamos por cuenta del Cliente (A.3); cuando se trata del propio titular de la cuenta, se regula aquí. |
| Categorías de interesados | Titulares de cuentas y miembros del equipo como destinatarios. |
| Categorías de datos personales | Como en A.3. Las notificaciones aparecen en el idioma del titular de la cuenta. |
| Base jurídica | Art. 6(1)(b) RGPD. |
| Destinatarios | Proveedor de servicios de correo; servicios de chat elegidos (4.1). |
| Tercer país | Según el canal (4.1). |
| Conservación | Como en A.3: registro de entregas 90 días, notificaciones resumidas 30 días tras la entrega, incidencias hasta su resolución y después 180 días. Destinos de alerta junto con el dominio. |
| MTO | Sección 8. |
B.17 Informe mensual a las cuentas
| Campo | Contenido |
| Finalidad | El día 1 de cada mes a partir de las 08:00 (con recuperación hasta el día 3), un correo electrónico por cuenta que abarca todos sus dominios: nivel, puntuación y variación, alertas, bots bloqueados, envío de correo electrónico, valor de comparación. |
| Categorías de interesados | Titulares de cuentas activas con el informe mensual activado. |
| Categorías de datos personales | Dirección de correo electrónico, idioma, cifras clave de los dominios. |
| Base jurídica | Art. 6(1)(b) RGPD (parte del servicio). Puede darse de baja en la configuración; puede desactivarse de forma centralizada. |
| Destinatarios | Proveedor de servicios de correo (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA). |
| Tercer país | A través del proveedor de servicios de correo. |
| Conservación | Sin almacenamiento propio; el correo electrónico permanece en la bandeja de salida durante 30 días (B.25). |
| MTO | Sección 8. |
B.18 Distintivo y página pública de confirmación
| Campo | Contenido |
| Finalidad | Un Cliente puede insertar una imagen de distintivo en su sitio web y enlazarla con una página pública de confirmación. El distintivo muestra «Protegido» solo si el dominio está verificado, la monitorización está en marcha y la última comprobación finalizada tiene como máximo 45 días de antigüedad y dio como resultado «Protegido» o «Parcialmente protegido»; de lo contrario, muestra de forma neutra «Comprobación del formulario de contacto». La página de confirmación indica el nivel y la fecha, sin hallazgos concretos. |
| Categorías de interesados | Visitantes del sitio web del Cliente cuyo navegador carga la imagen; visitantes de la página de confirmación. |
| Categorías de datos personales | Al cargar la imagen: dirección IP, hora, dirección solicitada, página de referencia e identificador del navegador en el registro del servidor web (B.1). La dirección de la imagen no inicia ninguna sesión, no instala ninguna cookie y no escribe en el registro de páginas vistas. La página de confirmación es una página normal (B.2, B.3). |
| Base jurídica | Art. 6(1)(f) RGPD. Interés: entregar la imagen y mantener la seguridad del funcionamiento. Si el Cliente y nosotros somos corresponsables del tratamiento en cuanto a la transmisión de la dirección IP del visitante, en el sentido de la jurisprudencia sobre contenidos de terceros integrados, y si se requiere un acuerdo conforme al Art. 26, es una cuestión abierta para la revisión jurídica. El Cliente recibe un texto sugerido para su política de privacidad. |
| Destinatarios | Ninguno. |
| Tercer país | Ninguno. |
| Conservación | 14 días (registro del servidor web). La imagen se almacena en caché durante una hora. Al desactivar el distintivo, el identificador deja de ser válido. |
| MTO | Sección 8. |
B.19 Registro probatorio y sello de tiempo
| Campo | Contenido |
| Finalidad | Un registro por dominio y mes (planes de pago): qué se comprobó, con qué resultado, qué se notificó y qué cambió, como prueba a efectos de responsabilidad proactiva, aseguradoras o auditorías de proveedores. Cada versión recibe un número de verificación; una página pública confirma el dominio, el período y las cifras clave, sin detalles. Desde el 7 de octubre de 2026, una autoridad de sellado de tiempo conforme a RFC 3161 confirma la hora. |
| Categorías de interesados | Clientes; indirectamente, las personas que puedan figurar en el registro como aprobadoras o como quienes han confirmado algo. |
| Categorías de datos personales | Dominio, mes, número de verificación, hash del contenido (SHA-512), resumen y datos del registro, respuesta del sello de tiempo, autoridad de sellado de tiempo y hora, intentos fallidos (proof_docs). |
| Base jurídica | Art. 6(1)(b) RGPD. |
| Destinatarios | La autoridad de sellado de tiempo (por defecto Certum, alternativa DigiCert) recibe únicamente el hash del registro, no su contenido. Públicamente: cifras clave a través de la página de confirmación. El Cliente y cualquier persona a la que el Cliente entregue el registro o el número de verificación. |
| Tercer país | No hay transferencia de datos personales: un hash no permite deducir el contenido. La autoridad alternativa tiene su sede en EE. UU. |
| Conservación | Hasta que se elimina el dominio (fe_domain_loeschen()). El sello de tiempo no es un sello cualificado de tiempo electrónico conforme a eIDAS. |
| MTO | Sección 8. |
B.20 Plugin y extensión: comprobación, conexión y transmisión
| Campo | Contenido |
| Finalidad | El plugin de WordPress y la extensión de TYPO3 pueden solicitar una comprobación (incluso sin cuenta), conectarse a una cuenta (la instalación cuenta como prueba de control con un clic en la cuenta), desbloquear funciones de protección, comunicar cifras a diario (A.9) y comunicar de inmediato errores de correo electrónico y el modo de mantenimiento. |
| Categorías de interesados | Clientes; titulares de sitios web que utilizan el plugin sin cuenta. |
| Categorías de datos personales | Por host: versión del plugin y del CMS, número de comprobaciones, identificador del último informe, hash del secreto de conexión, primer y último contacto (plugin_sites). Códigos de conexión de un solo uso como hash con caducidad (plugin_connect_tokens). Códigos de despliegue de una agencia como hash con prefijo, etiqueta, usos y persona creadora (workspace_connect_codes). Registro de solicitudes con la dirección IP del servidor que realiza la llamada (B.4). La clave del plugin es visible públicamente en el head del sitio web; es un hash del secreto, y el propio secreto solo se almacena como hash y nunca se devuelve. |
| Base jurídica | Art. 6(1)(b) RGPD (cuenta); sin cuenta, la letra f) (comprobación solicitada, prevención de abusos). |
| Destinatarios | Ninguno. |
| Tercer país | Ninguno. |
| Conservación | Los datos de un host se eliminan en cuanto ningún dominio hace ya referencia a él; la fila de un plugin sin cuenta, solo tras 90 días sin contacto (proceso nocturno de borrado, parte «orphan_hosts»). Códigos de un solo uso, un día después de su caducidad. Códigos de despliegue, junto con el espacio de trabajo. |
| MTO | Sección 8. Desde el 27 de septiembre de 2026, el servidor solo acepta pares de claves vinculados al sitio web; los secretos de conexión antiguos no vinculados se eliminaron. |
B.21 Protección colectiva (swarm)
| Campo | Contenido |
| Finalidad | Defensa común contra el spam: los sitios web conectados comunican los dominios de los enlaces contenidos en mensajes que su capa de protección ha detenido. Un dominio que aparece en al menos tres sitios web con al menos cinco coincidencias en un plazo de siete días pasa a una lista que se devuelve a todos los sitios web conectados; su capa de protección envía los mensajes con dichos enlaces a cuarentena, nunca al olvido. |
| Categorías de interesados | Titulares de los dominios de enlace comunicados, cuando sean personas físicas (por ejemplo, el operador de un sitio de spam a su propio nombre). No los remitentes ni los destinatarios de los mensajes: no se comunican direcciones, textos ni nombres. |
| Categorías de datos personales | Señales: tipo, dominio, host que comunica, día, coincidencias (swarm_signals). Lista: tipo, dominio, número de sitios web y de coincidencias, fechas y horas (swarm_list). Nunca se incluyen en la lista los grandes servicios, los dominios de nuestros Clientes ni las excepciones fijadas por el operador. |
| Redes IP | Se ha preparado el intercambio de redes IP (/24, /48). Está desactivado y el plugin no comunica ninguna; solo se activará tras una revisión jurídica, porque las direcciones IP son datos personales. |
| Base jurídica | Art. 6(1)(f) RGPD. Interés: proteger los formularios de todos los Clientes frente a oleadas de spam. Ponderación: solo dominios, umbrales mínimos contra el envenenamiento, ninguna pérdida de mensajes, eliminación posible en cualquier momento. |
| Destinatarios | Todos los sitios web conectados (la lista de dominios). |
| Tercer país | Según la ubicación de los sitios web conectados; la lista también puede llegar a sitios web situados fuera del EEE. Solo constituye datos personales en casos límite (dominios de personas físicas). La base para la transferencia conforme al capítulo V del RGPD en estos casos aún está por determinar (cuestión abierta para la revisión jurídica). |
| Conservación | Señales 30 días (proceso diario de swarm a partir de las 04:00, cfg/swarm_lib.php). La lista se recalcula a diario; lo que deja de alcanzar el umbral desaparece de ella. |
| MTO | Sección 8. |
B.22 Claves de API, interfaz de programación y servidor MCP
| Campo | Contenido |
| Finalidad | Acceso de las herramientas propias del Cliente (API REST, Zapier, Make, servidor MCP para asistentes de IA) a los dominios, comprobaciones e incidencias del Cliente. |
| Categorías de interesados | Clientes que crean claves. |
| Categorías de datos personales | Clave solo como hash, prefijo, etiqueta, fechas de creación, último uso y revocación (api_keys). Llamadas por minuto (api_usage). |
| Base jurídica | Art. 6(1)(b) RGPD. |
| Destinatarios | La herramienta a la que el Cliente proporciona la clave; la determina el Cliente. |
| Tercer país | Según la herramienta del Cliente. |
| Conservación | Claves hasta su revocación; inmediatamente junto con la cuenta; claves sin cuenta (datos heredados), cada noche. Contadores de llamadas, tras un día (ocasionalmente se depuran durante una llamada). |
| MTO | Sección 8. |
B.23 reCAPTCHA y nuestra propia protección de formularios
| Campo | Contenido |
| Finalidad | Defensa frente a accesos automatizados a nuestros propios formularios: comprobación gratuita, herramienta de cabeceras, opt-out, inicio de sesión, registro, contraseña olvidada y restablecimiento de contraseña, soporte y contacto. Además, nuestra propia protección sin terceros: trampa (campo oculto), comprobación de tiempo firmada y token CSRF. Desde el 29 de octubre de 2026, además, nuestra protección de formularios formconfirmed (prueba de trabajo y token de verificación de un solo uso) en la comprobación gratuita, el registro, el inicio de sesión y «contraseña olvidada». |
| Categorías de interesados | Personas que envían estos formularios. |
| Categorías de datos personales | En Google: dirección IP, datos del navegador y del dispositivo, datos de comportamiento, cookies de Google. En nuestro sistema: la evaluación de Google (puntuación y acción) solo en el momento de la comprobación, sin almacenamiento, ni siquiera cuando se rechaza un envío. En nuestra propia protección de formularios: dirección IP (almacenada solo de forma abreviada y convertida en hash), página, momentos, campo trampa rellenado sí/no; ningún contenido. |
| Momento | El script de Google solo se carga cuando se envía un formulario protegido, no al abrir la página. Nuestra propia protección de formularios obtiene su tarea al abrir la página y realiza el cálculo en cuanto se utiliza el formulario. En el sistema de desarrollo, reCAPTCHA está desactivado. |
| Base jurídica | Art. 6(1)(f) RGPD. Interés: protección frente a bots, en especial para la comprobación gratuita, que de lo contrario podría utilizarse contra sitios web de terceros. Si el acceso al equipo terminal requiere consentimiento conforme al § 25 TDDDG o al Art. 399 PKE, aunque el script solo se cargue al enviar, es una cuestión abierta para la revisión jurídica. Nuestra propia protección de formularios no instala cookies, no almacena nada en el navegador y no genera ninguna huella digital; está previsto que sustituya a reCAPTCHA de forma permanente. |
| Destinatarios | Google Ireland Limited; Google LLC. En nuestra propia protección de formularios, ninguno. |
| Tercer país | EE. UU. (solo reCAPTCHA). Base: certificación conforme al Marco de Privacidad de Datos UE-EE. UU. o cláusulas contractuales tipo; pendiente de documentar en detalle. |
| Conservación | reCAPTCHA: ningún almacenamiento en nuestro sistema; en Google, conforme a sus normas. Nuestra propia protección de formularios: identificador convertido en hash, 1 hora; tokens de verificación utilizados, 11 minutos como máximo; resultados de la verificación sin dirección IP, 30 días. |
| Interrupción | Si Google no responde en un plazo de tres segundos o responde de forma inutilizable, el envío se rechaza; lo mismo ocurre con un token vacío y con una respuesta para una acción distinta de la del formulario. La comprobación solo se omite cuando reCAPTCHA está desactivado. En nuestra propia protección de formularios, un envío sin token de verificación válido se rechaza; si el servicio no estaba disponible para la tarea, se admite. |
| MTO | Sección 8. |
B.24 Soporte y formulario de contacto
| Campo | Contenido |
| Finalidad | Recibir y responder consultas a través de la ventana de soporte y de la página de contacto. Ambas utilizan la misma ruta y la misma tabla. |
| Categorías de interesados | Personas que realizan consultas, con o sin sesión iniciada. |
| Categorías de datos personales | Cuenta (si se ha iniciado sesión; en ese caso se aplica la dirección de la cuenta, no la introducida), dirección de correo electrónico, motivo de una lista fija, texto de hasta 4000 caracteres, estado, dirección IP completa, país, identificador del navegador, página de referencia (solo rutas propias), idioma, fechas y horas de recepción y de respuesta (support_requests); entrada en el registro de actividad (sin texto); acuse de recibo a la persona que consulta en la bandeja de salida (B.25), con el texto de hasta 2000 caracteres solo para remitentes con sesión iniciada, sin el texto para las solicitudes realizadas sin iniciar sesión. |
| Base jurídica | Art. 6(1)(b) RGPD cuando la consulta se refiere a un contrato; en otro caso, la letra f). Dirección IP completa: letra f) (límite de tres consultas por hora y dirección, prevención de abusos). |
| Destinatarios | Proveedor de servicios de correo (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA) para el acuse de recibo y la respuesta. Telegram recibe una señal fija sin ninguna variable («hay una nueva solicitud de soporte») y, por tanto, ningún dato personal. |
| Tercer país | A través del proveedor de servicios de correo. |
| Conservación | 24 meses (proceso nocturno de borrado, parte «support»); manualmente antes. Si se elimina una cuenta, las consultas se conservan hasta el final del plazo de conservación (sección 6.4). |
| MTO | Sección 8. reCAPTCHA, nuestra propia protección de formularios, limitación de frecuencia. |
B.25 Envío de correo electrónico (bandeja de salida)
| Campo | Contenido |
| Finalidad | Correos electrónicos transaccionales: confirmación del registro y de nuevas direcciones de correo electrónico, restablecimiento de contraseña, invitaciones, alertas, informes mensuales, confirmaciones e informes del portal, acuses de recibo y respuestas de soporte, recordatorios sobre el período de prueba y la configuración, notificaciones operativas a los operadores. Nada de publicidad ni de correos electrónicos a personas que no se hayan registrado ellas mismas o que el Cliente no haya introducido como destinatarias. |
| Categorías de interesados | Destinatarios de estos correos electrónicos. |
| Categorías de datos personales | Dirección del destinatario, asunto, contenido completo, dirección de respuesta, finalidad, vía de envío, estado, error, intentos, fechas y horas (mail_outbox). El contenido puede incluir enlaces de confirmación y de restablecimiento con identificadores válidos. |
| Base jurídica | Art. 6(1)(b) RGPD; para las notificaciones operativas, la letra f). |
| Destinatarios | Namecheap, Inc. (Private Email), Phoenix, Arizona, USA (envío); el titular de la cuenta ve los correos electrónicos que se le han enviado en la exportación de datos (sin contenido). |
| Tercer país | Según el lugar de tratamiento del proveedor de servicios de correo; el contrato y la base para la transferencia aún deben documentarse (sección 4). |
| Conservación | 30 días (cada noche, srv/cron_status.php). Este plazo es deliberadamente el más corto de todos los registros: un registro de envíos prolongado sería una colección de claves válidas. El proceso de estado comprueba cada cinco minutos si corresponde un nuevo intento. |
| Estado | El envío de correo electrónico debe configurarse antes del lanzamiento. Hasta que se determinen el proveedor de servicios de correo, su sede y la base jurídica, los textos legales muestran un marcador. |
| MTO | Sección 8. Los correos electrónicos fallidos se reintentan a intervalos crecientes y se abandonan tras un número máximo de intentos. |
B.26 Pagos y facturación
| Campo | Contenido |
| Finalidad | Celebración y gestión de suscripciones (mensuales o anuales por adelantado), período de prueba de 14 días sin tarjeta con un recordatorio tres días antes de su fin, pago contra factura para suscripciones anuales (desactivado por defecto), desbloqueos mediante códigos de proveedores de alojamiento y de socios sin pago, facturación, conservación a efectos fiscales. |
| Categorías de interesados | Clientes. |
| Categorías de datos personales | En Stripe: dirección de correo electrónico, nombre, dirección de facturación, NIF-IVA, datos de pago, facturas; como metadatos, nuestro ID de cuenta y el plan. En nuestro sistema: ID de cliente y de suscripción de Stripe, plan, estado, fin del período, cancelación al final del período (users); eventos de Stripe recibidos solo con identificador, tipo, estado y fechas y horas, sin contenido (stripe_events); canjes de códigos de proveedores de alojamiento con cuenta, campaña y caducidad (bundle_redemptions). Los datos de la tarjeta nunca llegan a nosotros. |
| Origen | El Cliente en el proceso de pago de Stripe; eventos de Stripe. |
| Base jurídica | Art. 6(1)(b) RGPD; para la conservación a efectos fiscales, la letra c). |
| Destinatarios | Stripe Payments Europe Limited (Irlanda); Stripe, Inc. (EE. UU.). En partes del procesamiento de pagos, Stripe actúa bajo su propia responsabilidad; la asignación exacta de funciones forma parte de la revisión jurídica. |
| Tercer país | EE. UU. a través de Stripe, Inc.; base: Marco de Privacidad de Datos o cláusulas contractuales tipo conforme a las condiciones de Stripe. |
| Conservación | Campos de facturación junto con la cuenta; una suscripción en curso se finaliza antes de eliminar la cuenta. Facturas y documentos de facturación conforme a la legislación fiscal polaca durante cinco años a contar desde el final del año en que venció el plazo de pago del impuesto; se conservan en Stripe y pueden consultarse en el portal de clientes de Stripe. Los eventos de Stripe y los canjes de códigos no tienen plazo de conservación (sección 6.4). |
| MTO | Sección 8. Los eventos de Stripe solo se aceptan con una firma válida; cada evento se procesa una sola vez. |
B.27 Copias de seguridad
| Campo | Contenido |
| Finalidad | Recuperación tras un error: eliminación indebida, migración dañada. |
| Categorías de interesados | Todas las personas cuyos datos se encuentran en la base de datos. |
| Categorías de datos personales | Volcado completo y comprimido de la base de datos de la aplicación. Las capturas de pantalla y los archivos de logotipos se guardan fuera de la base de datos y no forman parte de esta copia de seguridad. Las credenciales de las cuentas de prueba solo están contenidas en ella como texto cifrado (A.5). |
| Procedimiento | Cada noche a las 03:00, después del proceso de borrado, para que la copia de seguridad no arrastre lo que los plazos de conservación acaban de eliminar. El volcado solo se conserva una vez comprobado su contenido (código de salida, número de tablas, línea final). Los domingos, una prueba de restauración carga la última copia de seguridad en una base de datos desechable y la compara tabla por tabla. Si algo falla, se emite una señal y un correo electrónico a los operadores. |
| Base jurídica | Art. 6(1)(f) RGPD en relación con el Art. 32(1)(c). |
| Destinatarios | Ninguno. |
| Tercer país | Ninguno. |
| Conservación | 14 días; los volcados más antiguos solo se eliminan tras una nueva copia de seguridad correcta (cfg/backup_lib.php). Las eliminaciones que se producen durante este tiempo solo alcanzan a la copia de seguridad cuando esta caduca; si se restauran datos a partir de una copia de seguridad, las solicitudes de supresión se aplican de nuevo a continuación. |
| Ubicación | Actualmente, las copias de seguridad se guardan en la misma ubicación que la base de datos y no están cifradas por separado; está prevista una copia cifrada en una segunda ubicación (secciones 8.1 y 10). |
| MTO | Sección 8. |
B.28 Registro de errores y alerta de errores
| Campo | Contenido |
| Finalidad | Encontrar y corregir errores antes de que un Cliente los notifique. Los nuevos tipos de error y las oleadas de errores se comunican a los operadores, además de un resumen diario a partir de las 08:00. |
| Categorías de interesados | Usuarios cuya solicitud provoca un error; indirectamente, personas cuyos datos aparecen en un mensaje de error. |
| Categorías de datos personales | Nivel, origen, mensaje, contexto en JSON, ID de cuenta de la sesión, hora (error_logs). Tipos de error: huella, patrón (del que se han eliminado direcciones de correo electrónico, direcciones, números e identificadores), un mensaje de muestra sin modificar de hasta 2000 caracteres, primera y última aparición, recuento (error_kinds). |
| Base jurídica | Art. 6(1)(f) RGPD (seguridad operativa, Art. 32). |
| Destinatarios | Los operadores por correo electrónico a través del proveedor de servicios de correo: para un nuevo tipo de error, el origen y el texto sin procesar del mensaje de hasta 400 caracteres (sin depurar), además del correo electrónico de resumen diario; en caso de oleada de errores, solo se envía la señal de Telegram. Telegram solo recibe frases fijas sin variables («Se ha producido un nuevo tipo de error», «Muchos errores en poco tiempo»). |
| Tercer país | A través del proveedor de servicios de correo. |
| Conservación | Registro de errores 90 días (cada noche). Tipos de error sin plazo de conservación (sección 10). La alerta de errores está activada en el sistema de producción y desactivada en el sistema de desarrollo. |
| MTO | Sección 8. |
B.29 Señales operativas y supervisión del estado
| Campo | Contenido |
| Finalidad | Detectar interrupciones: cada cinco minutos, una comprobación de los componentes (página de inicio, base de datos, espacio en disco, latido del escáner, acumulación en la cola), página de estado, señal ante un fallo y al restablecerse, latido hacia un servicio de monitorización externo para que se detecte incluso una caída total; acumulación pendiente ante el escáner. |
| Categorías de interesados | Por regla general, ninguno. |
| Categorías de datos personales | Ninguna. Filas diarias por componente con el número de comprobaciones y el último error (system_status_logs), latido del escáner (scanner_heartbeat), cifras clave diarias sin referencia personal (daily_stats). Las señales a Telegram son frases fijas sin variables; el latido es una solicitud sin contenido. |
| Base jurídica | No aplicable, al no haber datos personales; por precaución, Art. 6(1)(f). |
| Destinatarios | Telegram (frases fijas); el servicio de monitorización externo (solo la solicitud); los operadores por correo electrónico. |
| Tercer país | Telegram, fuera de la UE; no se transmiten datos personales. |
| Conservación | Filas de estado 400 días (cada noche). |
| MTO | Sección 8. |
B.30 Opt-out: exclusión de un dominio
| Campo | Contenido |
| Finalidad | Cualquier persona puede excluir de forma permanente cualquier dominio de las comprobaciones sin aportar prueba; el bloqueo surte efecto de inmediato para todas las vías de comprobación (comprobación gratuita, plugin sin cuenta, estudio, comprobación de clientes potenciales, herramienta de cabeceras) y también para dominios de Clientes de pago con prueba de control; su monitorización en curso finaliza con la siguiente comprobación programada. Se aplica al dominio y a su variante www, no a otros subdominios. Solo lo levantamos nosotros, previa solicitud y con prueba. Para poder detectar y revertir abusos (por ejemplo, un competidor que bloquea dominios ajenos), el bloqueo se registra. |
| Categorías de interesados | Personas que excluyen un dominio. |
| Categorías de datos personales | Dominio, motivo voluntario de hasta 250 caracteres, origen, dirección IP, país, identificador del navegador, hora; al levantarlo, hora, persona que levanta el bloqueo y motivo (blocklist). Registro de solicitudes como en B.4. |
| Base jurídica | Para la exclusión, Art. 6(1)(f) RGPD. Interés: dar efecto, de forma permanente y en todas las vías de comprobación, al deseo de que un dominio no sea comprobado. Cuando la persona que excluye es ella misma un interesado, la exclusión da efecto al mismo tiempo a su oposición conforme al Art. 21 (Art. 6(1)(c)). Para la dirección, el país y el identificador del navegador, la letra f) (detección de abusos). |
| Destinatarios | Google (reCAPTCHA, B.23). |
| Tercer país | EE. UU. a través de reCAPTCHA. |
| Conservación | Dirección IP, país e identificador del navegador, tras 12 meses (proceso nocturno de borrado, parte «optout_ip»). La exclusión en sí se mantiene de forma permanente para que surta efecto. |
| MTO | Sección 8. Muchos bloqueos desde un mismo país en poco tiempo generan una anomalía (B.4). |
B.31 Recordatorio tras el registro
| Campo | Contenido |
| Finalidad | Un único correo electrónico entre dos y 14 días después del registro a cuentas confirmadas sin dominio confirmado: «Añadir sitio web» o «Confirmar dominio». Sin oferta, sin precio, sin mejora de plan; con la indicación de que no se volverá a enviar. Días laborables de 09:00 a 18:00, como máximo 50 por ejecución. |
| Categorías de interesados | Nuevos titulares de cuentas. |
| Categorías de datos personales | Dirección de correo electrónico, idioma, hora de envío (campo «recordatorio enviado» en users), dominio y estado de confirmación. |
| Base jurídica | Art. 6(1)(b) RGPD (indicación sobre la configuración de la propia cuenta). Si el correo electrónico constituye una comunicación relativa a la relación contractual o una información comercial que requeriría consentimiento (Art. 10 UŚUDE, la Ley polaca de prestación de servicios por vía electrónica (ustawa o świadczeniu usług drogą elektroniczną); Art. 398 PKE; § 7 UWG) es una cuestión abierta para la revisión jurídica; el operador puede desactivarlo de forma centralizada. |
| Destinatarios | Proveedor de servicios de correo (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA). |
| Tercer país | A través del proveedor de servicios de correo. |
| Conservación | La hora se conserva mientras exista la cuenta; el correo electrónico, 30 días en la bandeja de salida. |
| MTO | Sección 8. La hora se fija antes del envío, para que una interrupción no provoque un segundo correo electrónico. |
B.32 Bot de Telegram para alertas a Clientes
| Campo | Contenido |
| Finalidad | Se vincula un chat de Telegram como destino de alerta: el Cliente recibe un enlace a nuestro bot con un código de un solo uso; cuando el destinatario pulsa «Start», nuestro servidor lee el código de los nuevos mensajes dirigidos al bot y almacena el ID del chat. Para ello no se necesita ningún punto de acceso abierto por nuestra parte (webhook). |
| Categorías de interesados | Clientes y las personas cuyo chat de Telegram se vincula. |
| Categorías de datos personales | Código de un solo uso, dominio, cuenta creadora, eventos, modo de entrega, ID del chat, fechas y horas (telegram_links); el ID del chat como destino (alerts). Telegram facilita otros datos del perfil junto con el mensaje; solo se evalúan y almacenan el código y el ID del chat. |
| Base jurídica | Art. 6(1)(b) RGPD; para terceros como destinatarios, A.3. |
| Destinatarios | Telegram. |
| Tercer país | Fuera de la UE, sin decisión de adecuación; la elección la realiza el Cliente (4.1). La base y la información son cuestiones abiertas para la revisión jurídica. |
| Conservación | Un código es válido durante 30 minutos; las filas de vinculación se eliminan tras un día cuando se crea un nuevo código; los códigos abiertos, junto con la cuenta y el dominio. El ID del chat como destino, hasta que se elimina el destino de alerta o el dominio. |
| MTO | Sección 8. |
B.33 Programa de socios y códigos de desbloqueo
| Campo | Contenido |
| Finalidad | Una cuenta puede recomendar nuevos Clientes mediante un código de recomendación y recibe una comisión sobre sus facturas pagadas durante un número limitado de meses. El código viaja en la dirección hasta el registro; no se instala ninguna cookie. Los proveedores de alojamiento y los socios pueden emitir códigos que desbloquean un plan durante un período sin pago; una semana antes del final, el Cliente recibe un recordatorio. |
| Estado | El programa de socios está desactivado por defecto hasta que estén vigentes las Condiciones para socios. |
| Categorías de interesados | Socios y Clientes recomendados. |
| Categorías de datos personales | Código de recomendación, socio que recomienda y fecha de la recomendación (en users); comisión con socio, Cliente, ID de factura de Stripe, importe, moneda, comisión, estado, fechas y horas (partner_commissions). Desbloqueo con plan, fin, origen, recordatorio (en users); campañas y canjes (bundle_campaigns, bundle_redemptions). |
| Base jurídica | Art. 6(1)(b) RGPD (acuerdo de socio); para el Cliente, la letra f) (liquidación de la comisión, sin transmitir al socio datos del Cliente más allá del importe de la comisión); registros fiscales, la letra c). |
| Destinatarios | El socio ve sus comisiones. |
| Tercer país | Ninguno. |
| Conservación | Recomendación y desbloqueo, junto con la cuenta. Las comisiones y los canjes no tienen plazo de conservación en el código; como documentos contables, las comisiones están sujetas a la conservación a efectos fiscales (sección 6.4). |
| MTO | Sección 8. |
B.34 Punto de notificación de vulnerabilidades
| Campo | Contenido |
| Finalidad | Recibir notificaciones de vulnerabilidades en formexposed, conforme a las normas de la página de Seguridad y de /.well-known/security.txt. |
| Categorías de interesados | Personas que notifican; personas cuyos datos contiene una notificación como prueba. |
| Categorías de datos personales | Dirección de correo electrónico, nombre, contenido de la notificación y archivos adjuntos, tal como los envía la persona que notifica. La notificación nos llega por correo electrónico a la dirección indicada allí; la aplicación no la almacena. |
| Base jurídica | Art. 6(1)(f) RGPD (seguridad del servicio, Art. 32); cuando una notificación contiene datos personales de terceros como prueba, igualmente la letra f), con el fin de cerrar la vulnerabilidad. |
| Destinatarios | Proveedor de servicios de correo y, hasta que se configure el buzón, el reenvío de dominio en Namecheap (sección 4). |
| Tercer país | A través del proveedor de servicios de correo y, hasta el cambio, del reenvío. |
| Conservación | No se ha fijado ningún plazo de conservación ni se aplica técnicamente (sección 10). El operador aún debe fijar el plazo; un enfoque razonable sería eliminar las pruebas de terceros una vez cerrada la vulnerabilidad y tratar la correspondencia como las consultas de soporte. |
| MTO | Sección 8. |
B.35 Comentarios sobre un informe
| Campo | Contenido |
| Finalidad | Recibir comentarios debajo de un informe («¿Hay algo incorrecto en este informe?») para encontrar errores en la detección de formularios. El superadministrador los clasifica (nuevo, confirmado, corregido, rechazado) y puede descargar los datos de comprobación del informe como caso de prueba (formularios con campos, motivos y hallazgos, sin capturas de pantalla y sin textos enviados activamente). |
| Categorías de interesados | Personas que consultan un informe, con o sin sesión iniciada. |
| Categorías de datos personales | Categoría y comprobación de listas fijas, dirección de la página de hasta 500 caracteres, texto de hasta 1000 caracteres, idioma, hora, identificador del informe, comprobación, host; identificador de la cuenta si se ha iniciado sesión; HMAC-SHA256 de la dirección IP con una clave secreta para el límite; estado, persona que lo tramita, hora de tramitación (report_feedback). Registro de actividad: cambios de estado y descargas de un caso de prueba. Ninguna dirección de correo electrónico, ninguna dirección IP en texto claro. |
| Base jurídica | Art. 6(1)(f) RGPD (encontrar y corregir errores de detección; límite contra abusos). |
| Destinatarios | Ninguno. |
| Tercer país | Ninguno. |
| Conservación | 24 meses (proceso nocturno de borrado, parte «report_feedback»); la suma de comprobación de la dirección IP se elimina tras 2 días (parte «report_feedback_ip»); de inmediato al eliminar una cuenta. Los casos de prueba descargados no contienen datos sobre la persona que comunica. |
| MTO | Sección 8. Protección propia de formularios (trampa, tiempo firmado, CSRF), como máximo 5 comunicaciones por hora y 20 por día por suma de comprobación, 10 por informe; solo legible por superadministradores. |
6. Conservación: qué cubre el proceso nocturno de borrado y qué no
Existe un borrado automático y tiene un lugar definido. Un proceso de estado (srv/cron_status.php) se inicia cada cinco minutos a través del crontab del servidor web, tanto en el sistema de producción como en el de desarrollo. Comprueba los componentes, recoge el correo de la comprobación de entrega, programa comprobaciones y envía alertas. Una vez al día, en la franja de 03:00 a 03:04, elimina datos conforme a los plazos de conservación y después crea la copia de seguridad. Desde el 27 de septiembre de 2026 llama además al proceso de plazos de cfg/fristen_lib.php (fe_fristen_lauf()), cuyas partes se ejecutan de forma independiente entre sí: si una falla, las demás continúan y el error se anota en el registro de errores.
Prueba de que el proceso se ejecuta: el estado de las copias de seguridad del sistema de desarrollo muestra una copia correcta a las 03:00 del 11 de octubre de 2026; la copia de seguridad se crea en el mismo bloque inmediatamente después del borrado. El proceso escribe un registro por cada tabla depurada únicamente en la salida estándar, que el crontab descarta; no existe un registro permanente de qué se eliminó y cuándo (sección 10).
Los plazos de conservación que aparecen como marcadores de posición se fijan en el área de administración, en la configuración de conservación. El proceso lee la misma configuración; por tanto, los textos muestran siempre el plazo tras el cual los datos se eliminan realmente.
6.1 Cubierto por el proceso diario
| Datos | Plazo de conservación y desencadenante | Lugar en el código |
Registro de páginas vistas (access_logs) | 60 días | srv/cron_status.php |
Registro de actividad (audit_logs) | 365 días | srv/cron_status.php |
Registro de errores (error_logs) | 90 días | srv/cron_status.php |
Bandeja de salida (mail_outbox) | 30 días | srv/cron_status.php |
Tokens de «Mantener la sesión iniciada» (remember_tokens) | tras su caducidad (30 días) | srv/cron_status.php |
Invitaciones no aceptadas (workspace_invites) | tras su caducidad (14 días) | srv/cron_status.php |
Intentos de inicio de sesión (login_attempts); contadores de intentos (auth_attempt_buckets) | 7 días; los contadores, al expirar su ventana de tiempo (actualmente 15 minutos, una hora para el restablecimiento de contraseña y el registro), también en el siguiente acceso | srv/cron_status.php |
Registro de solicitudes de comprobaciones sin cuenta (check_throttle) | 7 días | srv/cron_status.php |
Códigos de un solo uso para conectar el plugin (plugin_connect_tokens) | 1 día después de su caducidad | srv/cron_status.php |
Anomalías resueltas (abuse_flags) | 90 días después de su resolución | srv/cron_status.php |
| Informes caducados junto con el resultado de la comprobación, formularios, hallazgos, imágenes y tarea (solo sin dominio en una cuenta) | anónimos 30 días, clientes potenciales 90 días | fe_reports_aufraeumen() |
Registro de entrega de alertas (alert_log) | 90 días | fe_alert_log_aufraeumen() |
Filas de estado (system_status_logs) | 400 días | srv/cron_status.php |
Registros de consentimiento de cuentas eliminadas (legal_consents) | una vez eliminada la cuenta y cuando el consentimiento tiene 4 años de antigüedad | srv/cron_status.php |
| Huérfanos de dominios eliminados: resultados de comprobaciones, tareas, datos de alertas, incidencias, códigos de Telegram, entregas, pulso, vulnerabilidades, pruebas, inventario de scripts y cambios de scripts | de inmediato en el siguiente proceso | fe_fristen_lauf(), partes «orphan_scans», «orphan_rows» |
| Datos de plugin de hosts sin dominio; fila de plugin sin cuenta | de inmediato; la fila, tras 90 días sin contacto | parte «orphan_hosts» |
Resultados de la herramienta de cabeceras (header_checks) | actualmente 90 días | parte «header_checks» |
| Resultados de comprobación de un dominio con formularios, hallazgos, imágenes, informes, tareas | 13 meses; se conserva el último finalizado por dominio | parte «old_scans» |
Ejecuciones de navegador, tareas de navegador finalizadas, series temporales (form_browser_runs, scan_jobs, form_performance) | 13 meses | partes «browser_runs», «browser_jobs», «form_performance» |
Contadores de formularios (form_metrics), cifras diarias del plugin y avisos de cambios (plugin_stats, plugin_changes) | 13 meses | partes «form_metrics», «plugin_stats» |
Dispositivos con sesión iniciada (login_sessions) | 90 días después del último uso o de la revocación | parte «sessions» |
| Invitaciones aceptadas | 30 días después de su aceptación | parte «invites» |
Solicitudes de soporte (support_requests) | 24 meses | parte «support» |
Comentarios sobre informes (report_feedback) | 24 meses; suma de comprobación de la dirección IP 2 días | partes «report_feedback» y «report_feedback_ip» |
Versiones PDF de informes en la caché (var/pdf) | 7 días | parte «pdf_cache» |
Dirección IP, país e identificador del navegador en el opt-out (blocklist) | 12 meses; la exclusión se mantiene | parte «optout_ip» |
Suscriptores del portal (client_subscribers) | no confirmados 30 días; dados de baja 3 años | parte «subscribers» |
| Cuentas nunca confirmadas, junto con el espacio de trabajo | 30 días sin inicio de sesión, salvo que haya otro miembro vinculado | parte «pending_accounts» |
| Claves de API sin cuenta (datos heredados) | de inmediato | parte «api_keys» |
6.2 Fuera de la franja de las 03:00
| Datos | Plazo de conservación y desencadenante | Lugar en el código |
| Copias en el buzón de control de la comprobación de entrega | tras su procesamiento, cada cinco minutos | fe_zustellung_abholen() |
Asignaciones de la comprobación de entrega (delivery_log) | 180 días, en cada recogida | fe_zustellung_abholen() |
Texto cifrado de la cuenta de prueba en tareas (scan_jobs) | tras la ejecución, a más tardar tras una hora | servidor de escaneo; fe_login_aufraeumen() |
Incidencias (alert_incidents) con sus intentos de entrega de escalado | mientras no estén resueltas; 180 días después de su resolución | fe_vorfaelle_aufraeumen() en cfg/vorfall_lib.php |
Notificaciones resumidas enviadas (alert_queue) | 30 días después de la entrega | cfg/kanal_lib.php |
Señales de swarm (swarm_signals) | 30 días, diariamente a partir de las 04:00 | cfg/swarm_lib.php |
Comprobaciones de clientes potenciales (prospect_checks) | 90 días, diariamente a partir de las 04:00 | srv/cron_status.php |
Códigos de vinculación de Telegram (telegram_links) | 1 día, al crear un nuevo código | cfg/kanal_lib.php |
Contadores de llamadas a la API (api_usage) | 1 día, ocasionalmente durante una llamada | cfg/agentur_lib.php |
Interrupciones de proveedores resueltas (provider_incidents), caché de vulnerabilidades (vuln_cache) | 90 y 30 días respectivamente; sin datos personales | cfg/anbieter_lib.php, cfg/luecken_lib.php |
| Datos brutos de estudios | al publicarse | fe_studie_veroeffentlichen() |
| Copias de seguridad | 14 días, tras una nueva copia de seguridad correcta | cfg/backup_lib.php |
| Registros del servidor web | 14 días | rotación de registros del sistema |
6.3 En caso de eliminación por parte del Cliente
- Eliminación de un dominio (
fe_domain_loeschen()): resultados de comprobaciones con formularios, hallazgos y archivos de imagen, informes, tareas, destinos de alerta, registro de entregas, cola de resúmenes, incidencias, códigos de Telegram, entregas, pulso, vulnerabilidades, registros probatorios, el dominio en portales de clientes con una selección fija; mediante claves externas, formularios monitorizados con ejecuciones de navegador, observaciones y series temporales, cuenta de prueba, contadores de formularios; los datos del plugin del host si ningún otro dominio hace referencia a él. El inventario de scripts y los cambios de scripts del dominio se eliminan también junto con él; no tienen un plazo de conservación propio (secciones 6.4 y 10). Los datos que hayan quedado sin dominio asociado del período anterior al 27 de septiembre de 2026 los depura el proceso nocturno (partes «orphan_scans», «orphan_rows»).
- Eliminación de un espacio de trabajo (
fe_arbeitsbereich_daten_loeschen()): además, la marca incluido el logotipo, los portales de clientes incluidos los suscriptores, los códigos de despliegue, las comprobaciones de clientes potenciales; además de invitaciones y membresías.
- Eliminación de una cuenta: finalizar de inmediato en Stripe una suscripción de pago en curso, sin reembolso; transferir o eliminar los espacios de trabajo propios del titular; eliminar membresías, tokens de recordatorio de sesión, dispositivos, claves de API con contadores, códigos de Telegram abiertos y la fila de la cuenta.
- Eliminación de una cuenta de prueba (
fe_login_loeschen()): sobrescribir el texto cifrado, eliminar la fila, depurar las tareas en espera.
6.4 Lo que el proceso no cubre
Esta lista es la más importante. Recoge los datos para los que no existe un plazo de conservación automático o que sobreviven a una eliminación.
| Datos | Qué se aplica | Valoración |
Datos de la cuenta, incluida la última dirección IP (users) | hasta que el titular de la cuenta los elimina; no se eliminan las cuentas inactivas | datos contractuales; falta una regla para cuentas inactivas de forma permanente sin suscripción |
| Registro de actividad, páginas vistas, registro de errores de una cuenta eliminada | se mantienen con el ID de cuenta y la dirección IP hasta el final de su plazo de conservación | intencionado (prueba de acciones incluso tras la baja); el ID ya no remite a ninguna cuenta |
| Solicitudes de soporte de una cuenta eliminada | se mantienen hasta 24 meses con el ID de cuenta antiguo | intencionado; el ID no se elimina |
| Registros de consentimiento de una cuenta eliminada | hasta que el consentimiento tiene 4 años de antigüedad (contados desde el consentimiento, no desde la eliminación de la cuenta) | intencionado (sección B.12) |
Anomalías no resueltas con dirección IP (abuse_flags) | hasta que alguien las resuelva | punto abierto (sección 10) |
Tipos de error con mensaje de muestra sin modificar (error_kinds) | sin plazo de conservación | punto abierto (sección 10) |
Inventario de scripts y cambios de scripts (script_inventory, script_changes) | sin plazo de conservación propio; se conservan mientras exista el dominio y se eliminan con él | punto abierto (sección 10) |
| Suscriptores de portales de clientes revocados | hasta que se elimina el espacio de trabajo | punto abierto (sección 10) |
| Claves de API y códigos de despliegue revocados | hasta que se elimina la cuenta o el espacio de trabajo | solo hashes, prefijo y etiqueta; de escasa relevancia |
Lista de hosts de estudios (study_domains), estudios nunca publicados | sin plazo de conservación | punto abierto (sección 10) |
| Comprobaciones internas sin dominio y sin informe (resultados de comprobaciones, formularios, hallazgos, capturas de pantalla) | sin plazo de conservación; ninguna vía de eliminación las cubre | punto abierto (sección 10) |
| Comisiones, canjes de códigos, eventos de Stripe | sin plazo de conservación | relevancia contable; plazo a fijar conforme a la legislación fiscal |
Antigüedad del dominio en caché (domain_age_cache) | sin plazo de conservación | solo nombre de dominio y fecha de registro |
| Resultado de autenticación del correo electrónico del formulario con dominio remitente | junto con el dominio; se sobrescribe en cada recepción | véase A.1 |
| Exclusiones en el opt-out | permanentes | intencionado; sin permanencia, ninguna exclusión surte efecto |
| Correos electrónicos en el buzón del punto de notificación y en el buzón general | sin plazo de conservación técnico | punto abierto (sección 10) |
6.5 Fuera de la base de datos
- Las capturas de pantalla se guardan como archivos fuera del directorio web y se eliminan junto con su resultado de comprobación (todas las vías de eliminación anteriores eliminan también los archivos).
- Los archivos de logotipo de la marca se eliminan al sustituirlos y junto con el espacio de trabajo.
- En el servidor de escaneo se crea por cada tarea un directorio temporal con el resultado y las imágenes; se elimina tras cada ejecución, incluso tras un error.
- Las copias de seguridad se guardan en el servidor web (B.27).
- Los registros del servidor web con la dirección IP completa se conservan durante 14 días (B.1).
7. Decisiones automatizadas, elaboración de perfiles y evaluación
formexposed evalúa sitios web, no personas. A nuestro juicio, el servicio no adopta ninguna decisión que produzca efectos jurídicos en una persona o le afecte significativamente de modo similar (Art. 22(1) RGPD). No obstante, existen evaluaciones automatizadas y bloqueos automáticos. Los enumeramos para que pueda comprobarse la calificación.
| Mecanismo | Qué hace | A quién afecta |
| Puntuación y veredicto de una comprobación | Suma ponderada de las capas de protección que faltan (CAPTCHA, trampa, token, comprobación de tiempo, CAPTCHA ineficaz, configuración expuesta conocida), de 0 a 100; de ello resulta «Expuesto», «Parcialmente protegido» o «Protegido». El veredicto del sitio web se rige por el peor formulario de contacto reconocido como tal por las reglas (no por el modelo de lenguaje); sin formulario de contacto no hay veredicto. Las ponderaciones pueden ajustarse en el área de administración. | Titulares de sitios web; en el caso de empresarios individuales, indirectamente una persona. El veredicto no tiene consecuencias jurídicas; es una constatación con pruebas e instrucciones. |
| Clasificación del tipo de formulario | Primero las reglas; un modelo de lenguaje local solo si las reglas devuelven «desconocido». Decide si se permite un envío de prueba activo (solo para un formulario de contacto reconocido de forma fiable por las reglas). Los formularios clasificados por el modelo de lenguaje nunca se envían y no cuentan para la puntuación ni el veredicto. | El Cliente y los destinatarios de los correos electrónicos de su formulario; efecto protector: en caso de duda, no se envía nada. |
| Distintivo | Muestra «Protegido» solo en condiciones fijas (B.18); de lo contrario, es neutro. | Cliente; sin efecto para los visitantes. |
| Límites y bloqueos para la comprobación gratuita, la herramienta de cabeceras y el opt-out | Rechazan solicitudes si se alcanzan los límites por dirección, sesión, dominio o sistema, si el dominio es demasiado reciente o de antigüedad desconocida, o si figura en la lista de bloqueo. | Solicitantes; efecto: se deniega un servicio gratuito durante horas o días. Un administrador puede liberar una dirección; las consultas a través de la página de contacto llegan a una persona. |
| Anomalías | Los patrones (muchos dominios desde una misma dirección, ráfagas de solicitudes, muchos rechazos, muchos opt-outs desde un mismo país, límite diario alcanzado) se registran y se comunican. Por sí solos no bloquean; los bloqueos resultan de los límites. | Solicitantes. |
| Bloqueo de inicio de sesión | Tras actualmente ocho inicios de sesión fallidos desde una misma dirección en 15 minutos, los inicios de sesión desde esa dirección se rechazan temporalmente. Además, todos los intentos de inicio de sesión, incluidos los correctos, se cuentan por cuenta y dirección IP (actualmente ocho), por cuenta en todas las direcciones (bastantes más, contra la adivinación distribuida) y por dirección IP (actualmente 80) en 15 minutos, al igual que los códigos del segundo factor (diez por cuenta en 15 minutos); por encima de ello, los intentos se rechazan. Por tanto, los intentos fallidos desde otra dirección ya no bloquean al titular de una cuenta. Las confirmaciones de contraseña (cinco por cuenta en 15 minutos), los correos electrónicos de restablecimiento (tres por dirección y hora, con una respuesta invariable), los registros (diez por dirección IP y hora) y los intentos de contraseña de un portal de clientes (diez por portal y dirección IP, 50 por portal en 15 minutos) se limitan del mismo modo. | Personas que inician sesión, se registran o abren un portal de clientes; efecto limitado en el tiempo, el restablecimiento de contraseña sigue siendo posible. |
| Umbral de reCAPTCHA | Rechaza envíos por debajo de una puntuación de Google; umbral por punto de uso (actualmente 0.7 para la comprobación y el opt-out). También se rechazan las respuestas para una acción distinta y los envíos para los que Google no responde en un plazo de tres segundos. | Personas que envían nuestros formularios; efecto: un nuevo intento o la vía a través de la página de contacto. |
| Protección colectiva (swarm) | Incluye automáticamente un dominio de enlace en una lista cuando se alcanzan umbrales mínimos; las capas de protección de los sitios web conectados envían a cuarentena los mensajes con dichos enlaces. | Remitentes de mensajes a páginas de Clientes. Efecto: el mensaje se retiene, no se elimina, y el titular del sitio web puede liberarlo. La decisión sobre el mensaje la toma el plugin del titular en el sitio web del titular, no nosotros. |
| Valores de comparación | «Mejor protegido que el X % de los sitios comprobados», solo a partir de totales de al menos 20 hosts. | Titulares de sitios web; sin efecto. |
Lo más próximo al Art. 22 es la capa de protección del plugin en las páginas de los Clientes, que retiene envíos automáticamente. Se trata de un tratamiento realizado por el titular del sitio web en su propio servidor (A.10). No elimina nada, sino que envía los mensajes a cuarentena, y el titular puede liberar cualquier mensaje. Ni allí ni en nuestro sistema se elaboran perfiles de visitantes; no existe ningún identificador de visitante que vincule un mensaje con otro.
8. Medidas técnicas y organizativas (Art. 32): descripción general
Esta sección constituye la descripción general conforme al Art. 30(1)(g) y (2)(d) RGPD. La versión detallada se encuentra en la página Medidas técnicas y organizativas. Cada una de las medidas siguientes está acreditada en el código o en la configuración. Las medidas aún no implantadas figuran en la misma sección (8.1), para que la descripción sea completa.
| Ámbito | Medida vigente |
| Cifrado en tránsito | HTTPS para el sitio web, la aplicación y las interfaces; HSTS; cookies de sesión y de recordatorio de sesión solo a través de HTTPS, HttpOnly, SameSite=Lax. |
| Control de acceso (autenticación) | Contraseñas solo como hash, las nuevas con al menos diez caracteres y como máximo 72 bytes; bloqueo de inicio de sesión tras intentos fallidos repetidos y límites de intentos por cuenta y dirección IP conjuntamente, por cuenta y por dirección IP, de modo que los intentos fallidos desde otra dirección no bloqueen al titular; límites de intentos también para confirmaciones de contraseña, restablecimiento de contraseña (con la misma respuesta y el mismo tiempo de respuesta), registros y contraseñas de portal; inicio de sesión en dos pasos (TOTP) con secreto cifrado, protección contra la reutilización de códigos y códigos de recuperación con hash; nuevo identificador de sesión en cada inicio de sesión, no se aceptan identificadores no emitidos por el servidor; «Mantener la sesión iniciada» no disponible para superadministradores, cada token válido una sola vez; cambiar la dirección de correo electrónico invalida un enlace de restablecimiento abierto; los dispositivos pueden revocarse de forma individual o todos a la vez; la lista de dispositivos solo contiene el hash del identificador de sesión. |
| Control de acceso (autorización) | Funciones por espacio de trabajo (propietario, administrador, lector); los permisos se comprueban frente al objeto, nunca frente a un identificador procedente del formulario; cuenta de prueba, «Fix it for me» y comprobaciones activas solo para propietarios y administradores; «Ver como el Cliente» limitado en el tiempo y bloqueado para acciones que modifican la cuenta; al finalizar se cierra la sesión por completo y solo se vuelve al área de administración con contraseña y segundo factor; las invitaciones solo son válidas mientras la persona que invita sea propietaria o administradora; las direcciones de webhooks y canales de chat se muestran a los lectores solo abreviadas al host; el nombre de host de un dominio verificado no puede modificarse. |
| Seguridad de la aplicación | Tokens CSRF; sentencias preparadas de base de datos; nuestra propia protección de formularios (trampa, comprobación de tiempo firmada); reCAPTCHA en los formularios públicos; limitación de frecuencia para soporte, comprobaciones e interfaces; solo una llamada a «Fix it for me» por espacio de trabajo a la vez, para que la cuota se respete también con solicitudes simultáneas; Content Security Policy con protección contra el encuadre (framing) que solo permite ejecutar scripts que lleven la autorización (nonce) de la respuesta correspondiente; dirección IP de cabeceras reenviadas solo desde nuestro propio proxy y solo de la entrada que este ha añadido; tokens de acceso enmascarados en el registro de páginas vistas. |
| Secretos | Claves de API, códigos de despliegue, secretos de conexión del plugin, códigos de un solo uso y contraseñas de portal solo como hash; credenciales de las cuentas de prueba cifradas asimétricamente, clave privada solo en el servidor de escaneo; webhooks firmados; eventos de Stripe solo con una firma válida. |
| Minimización de datos | La comprobación de entrega no almacena contenido ni direcciones de remitente completas; direcciones de destinatario en formularios solo como dominio; los ID de cuenta en direcciones de scripts se sustituyen; cifras del plugin solo de listas fijas; textos de error del envío de correo electrónico solo como categoría; señales de Telegram sin variables; imágenes de la comprobación con navegador con entradas enmascaradas; ninguna captura de pantalla tras un inicio de sesión. |
| Aislamiento del escáner | Cada comprobación en su propio contenedor: todas las capacidades de Linux eliminadas, sin escalada de privilegios, sistema de archivos de solo lectura, límite de memoria y de procesos, red propia; comprobación del destino frente a redes privadas y locales antes de la aceptación y en el escáner, también tras redirecciones; service workers bloqueados, conexiones WebSocket cerradas. Solicitudes del servidor web (prueba de control, herramienta de cabeceras, búsqueda de archivos, pulso, RDAP, certificados, webhooks y alertas de chat) solo en los puertos web habituales y solo exactamente a la dirección comprobada; webhooks y alertas de chat solo a través de HTTPS. |
| Almacenamiento | Capturas de pantalla fuera del directorio web, accesibles solo a través del informe; informes en direcciones aleatorias con noindex; directorio de copias de seguridad legible solo por el servicio. |
| Disponibilidad y recuperación | Copia de seguridad nocturna con comprobación del contenido, prueba de restauración semanal, alerta en caso de fallo; comprobación de componentes cada cinco minutos con señal y correo electrónico; latido externo; parada de emergencia para comprobaciones anónimas; contrapresión en caso de acumulación. |
| Trazabilidad | Registro de actividad para inicios de sesión, cambios, eliminaciones, accesos de soporte y aprobaciones; registro de errores con alerta. |
| Eliminación | Plazos de conservación en un único lugar del código, a partir de la misma configuración que los textos (sección 6); cadenas de eliminación para dominio, espacio de trabajo y cuenta, con las excepciones de la sección 6.4. |
| Derechos de los interesados | Exportación con un clic de todos los datos de la cuenta como archivo, basada en una lista de campos permitidos, sin secretos. |
| Organización | Área de administración solo para cuentas con derechos de superadministrador, bloqueada durante «Ver como el Cliente»; sistemas de desarrollo y de producción separados, el sistema de desarrollo tras una barrera de acceso adicional; traslado de los textos legales tras su aprobación mediante una herramienta que rechaza borradores y marcadores de posición. |
8.1 Medidas aún no implantadas
- Sin cifrado de la base de datos en reposo (medido el 11 de octubre de 2026). Las excepciones son las credenciales de las cuentas de prueba y el secreto del segundo factor, que están cifrados a nivel de campo.
- Conexiones internas no cifradas en su totalidad. Las conexiones dentro de nuestra red interna no están cifradas en su totalidad. Las credenciales de las cuentas de prueba solo circulan por ella como texto cifrado.
- Sin copia de seguridad en una segunda ubicación. Actualmente, las copias de seguridad se guardan en la misma ubicación que la base de datos y no están cifradas por separado; está prevista una copia cifrada en una segunda ubicación. Hasta entonces, protegen frente a una orden de eliminación errónea, no frente a la pérdida de la ubicación.
- Bastionado de la administración de servidores no finalizado. La seguridad del acceso administrativo a nuestros servidores aún no alcanza el nivel que pretendemos para la explotación; el bastionado continúa. No publicamos detalles porque ayudarían a un atacante; los facilitamos a una autoridad de control previa solicitud.
- Sin registro funcional de lecturas en el área de administración. Las acciones de escritura se anotan en el registro de actividad; quién se ha limitado a consultar qué solicitud de soporte o qué informe solo puede determinarse a partir del registro de páginas vistas (60 días).
- Sin registro permanente de eliminaciones. Lo que el proceso nocturno ha eliminado no queda registrado (sección 6).
- Sin un segundo punto de comprobación independiente. La sonda en una segunda ubicación no está configurada (A.6).
9. Delegado de protección de datos: evaluación conforme al Art. 37 RGPD
Resultado: A nuestro juicio, no existe obligación de designarlo. La evaluación forma parte de la revisión jurídica y se repetirá en cuanto cambie alguna de las circunstancias que se indican a continuación.
El Art. 37(1) exige la designación en tres supuestos.
- Letra a) (autoridad u organismo público): no es aplicable.
- Letra b) (actividades principales que requieran una observación habitual y sistemática de interesados a gran escala): nuestra actividad principal es la comprobación habitual y sistemática de sitios web y formularios, no la observación de personas. No creamos perfiles de visitantes, no utilizamos seguimiento y no vinculamos ningún mensaje con otro. La comprobación de entrega (A.1) hace pasar mensajes reales de visitantes por nuestro buzón, pero solo evalúa las cabeceras y los primeros 8 KB para la asignación y no almacena contenido; observa rutas de entrega, no personas. Las cuentas de clientes y los registros son accesorios a la actividad empresarial.
- Letra c) (tratamiento a gran escala de categorías especiales conforme al Art. 9 o de datos relativos a condenas e infracciones penales conforme al Art. 10 como actividad principal): no se cumple. Pueden aparecer categorías especiales de forma incidental en copias de correos electrónicos de formularios (A.1), en páginas tras un inicio de sesión (A.5) o en código pegado (A.7); la captación incidental no constituye una actividad principal.
El Art. 37(4) permite que el Derecho nacional añada otros supuestos. Estamos solicitando a un abogado que confirme si el Derecho polaco nos obliga a designarlo.
Desencadenantes de una nueva evaluación: la activación de la protección colectiva (swarm) con redes IP; una función que reconozca a visitantes a través de varios mensajes o sitios web; el almacenamiento de contenido de la comprobación de entrega; un Cliente cuyos formularios se refieran predominantemente a categorías especiales (salud, candidaturas de empleo) con la comprobación de entrega activada a gran escala; el primer empleado con acceso a datos de clientes. Sigue siendo posible una designación voluntaria; en ese caso, los Art. 37 a 39 se aplican en su totalidad.
Por separado: si se requiere una evaluación de impacto relativa a la protección de datos conforme al Art. 35 para determinadas actividades de tratamiento lo responde la página Evaluación de impacto relativa a la protección de datos. Su evaluación del umbral concluye que se requiere una EIPD para la protección colectiva (B.21) y para los estudios a la escala prevista (B.7), que realizamos nosotros, y que para la comprobación de entrega (A.1) se requiere en la constelación típica, como obligación del Cliente, al que prestamos apoyo en ello.
10. Puntos abiertos y medidas previstas
Los puntos siguientes están acreditados en el código, el esquema o la configuración, no son meras suposiciones. Describen la situación a la fecha de esta versión; la calificación es nuestra y no anticipa ninguna valoración jurídica. Están ordenados según su importancia para los interesados, no según la facilidad de su corrección. Las medidas previstas y su prioridad se exponen en la Evaluación de impacto relativa a la protección de datos.
| Punto abierto | Qué está acreditado | Relevancia |
| Proveedor de servicios de correo sin contrato documentado | Para Namecheap, Inc. (Private Email), Phoenix, Arizona, USA no están documentados el contrato, los lugares de tratamiento ni la base para la transferencia. Los correos electrónicos de la cuenta, las alertas y el buzón de control con mensajes reales de visitantes pasan por este proveedor. | Las disposiciones pertinentes son el Art. 28(2) y (4) y el capítulo V del RGPD. Está prevista su celebración y documentación antes del lanzamiento. |
| Bases para los servicios de chat y reCAPTCHA pendientes | Alertas a Telegram (sin decisión de adecuación), Slack, Discord, Microsoft Teams y Google Chat; reCAPTCHA sin solicitud de consentimiento. | Cuestiones abiertas para la revisión jurídica; hasta entonces, la información y la base no son definitivas. |
| El buzón de control puede retener mensajes en caso de incidencias | La eliminación se produce tras un procesamiento correcto; si la recogida falla, las copias permanecen hasta el siguiente proceso correcto. No hay ninguna advertencia cuando se acumula un retraso en el buzón durante un período prolongado. | Las copias contienen consultas reales de visitantes. |
| Sin copia de seguridad en una segunda ubicación, sin cifrado de la base de datos en reposo | Sección 8.1. Está prevista una copia cifrada de la copia de seguridad en una segunda ubicación. | Un único suceso en la ubicación afectaría al mismo tiempo a los datos y a la copia de seguridad; un soporte de almacenamiento robado sería legible. |
| Anomalías no resueltas sin plazo de conservación | Las anomalías con la dirección IP completa como clave solo se eliminan 90 días después de su resolución; lo que nunca se resuelve permanece. | Afecta al principio de limitación del plazo de conservación (Art. 5(1)(e)); la eliminación depende de la resolución manual. Está previsto un plazo de conservación fijo (medidas de la evaluación de impacto relativa a la protección de datos). |
| Tipos de error con mensaje de muestra sin plazo de conservación | El mensaje de muestra se almacena sin modificar hasta 2000 caracteres; el patrón depurado elimina direcciones y números, la muestra no. | Los mensajes de error pueden contener direcciones de correo electrónico, nombres de host o direcciones IP. |
| Inventario de scripts sin plazo de conservación propio | El inventario de scripts y los cambios de scripts se eliminan con el dominio (FE_DOMAIN_TABELLEN), también al eliminar el espacio de trabajo o la cuenta y en el proceso nocturno para huérfanos; no tienen un plazo de conservación propio. Contienen direcciones de scripts, direcciones de páginas y, en el caso de aprobaciones, la persona que aprueba y un motivo en texto libre. | Afecta al principio de limitación del plazo de conservación (Art. 5(1)(e)); el historial de cambios con las aprobaciones sigue creciendo mientras exista el dominio. |
| Suscriptores de portales revocados | Un portal revocado se bloquea, no se elimina; sus suscriptores permanecen hasta que se elimina el espacio de trabajo. | La finalidad (envío del informe) cesó con la revocación. |
| Listas de estudios sin plazo de conservación | Tras la publicación, los hosts y segmentos permanecen; los estudios nunca publicados conservan también sus datos brutos. | La promesa «los datos brutos se eliminan» solo se aplica a los estudios publicados. |
| Comprobaciones internas sin vía de eliminación | Las comprobaciones con el nivel de confianza «interno» que no tienen dominio ni informe (estudios y comprobaciones creados por el operador desde la línea de comandos) no están cubiertas por ninguna vía de eliminación; con ellas permanecen formularios, hallazgos y capturas de pantalla de sitios web de terceros. | Afecta al principio de limitación del plazo de conservación (Art. 5(1)(e)); afecta a personas que no saben nada de la comprobación. Calificado como riesgo alto en la Evaluación de impacto relativa a la protección de datos. |
| La prueba de control no se renueva | La prueba de control se comprueba una sola vez; no existe en el código ninguna vía por la que un dominio vuelva a perderla. | Los envíos de prueba activos, la búsqueda de archivos y el escaneo tras el inicio de sesión continúan tras un cambio de titular o de mandato. |
| Escaneo tras el inicio de sesión: transporte a la página del Cliente | Como dirección de inicio de sesión se permite http además de https, y los errores de certificado en la página del Cliente no detienen el inicio de sesión. | Las credenciales de la cuenta de prueba podrían interceptarse en el camino hacia la página del Cliente. |
| La eliminación depende de una franja horaria | El bloque diario solo se ejecuta si un proceso de estado se inicia entre las 03:00 y las 03:04. Si ese único proceso falla (base de datos inaccesible, servidor reiniciado), la eliminación y la copia de seguridad de ese día no se producen; no hay recuperación posterior. Lo eliminado no se registra de forma permanente. | En ese caso, los plazos de conservación se prolongan un día sin que nadie lo advierta. Una franja perdida no genera ninguna alerta; solo se comunica una copia de seguridad que se ejecuta y falla. La lista de configuración del área de administración muestra la fecha de la última copia de seguridad correcta. |
| Algunas eliminaciones dependen de la monitorización | El vaciado del buzón de control de la comprobación de entrega, la eliminación de incidencias, de notificaciones resumidas enviadas, de señales de swarm y de comprobaciones de clientes potenciales, y la depuración de copias residuales de cuentas de prueba en tareas se ejecutan en la parte de planificación del proceso de estado, que solo funciona mientras la monitorización esté activada en el área de administración; las asignaciones de la comprobación de entrega solo se eliminan mientras haya un buzón de control configurado. | Si la monitorización se desactiva de forma centralizada o se elimina el buzón, estos plazos de conservación se detienen sin que nadie lo advierta. |
| Punto de notificación y buzones sin plazo de conservación | Las notificaciones de vulnerabilidades y otros correos electrónicos entrantes se guardan fuera de la aplicación; no se ha fijado ningún plazo de conservación. | Las notificaciones pueden contener pruebas de terceros. |
| Durante la comprobación se leen los valores de campos ocultos | El escáner lee el valor de los campos de formulario ocultos hasta 24 caracteres y los atributos de datos hasta 60 caracteres para reconocer marcas de tiempo y tokens. En el mapa de campos y en los hallazgos solo se incluyen el nombre del campo, el tipo, la etiqueta y el resultado del reconocimiento, no el valor. | No hay laguna de almacenamiento; el valor solo se mantiene en la memoria de trabajo del contenedor de escaneo durante la comprobación. Un valor precumplimentado (por ejemplo, un número de cliente) se lee en el proceso, pero no se almacena. |
| Dominio remitente derivado en el resultado de autenticación | A.1. | En el caso de dominios personales de visitantes, datos personales procedentes de un mensaje real. |
| Bastionado de la administración de servidores no finalizado; conexiones internas no cifradas en su totalidad | Sección 8.1. El bastionado continúa; no publicamos detalles. | Un incidente de seguridad a nivel de servidor afectaría al mismo tiempo a la aplicación, la base de datos y las copias de seguridad. |
| Medición en el sistema de desarrollo | El esquema, el código y la configuración se midieron en el sistema de desarrollo. | El código y el esquema coinciden con el sistema de producción; la configuración puede diferir y debe comprobarse de nuevo allí antes del lanzamiento. |
11. Mantenimiento de este registro
El Art. 30 exige que el registro conste por escrito y se ponga a disposición de la autoridad de control cuando esta lo solicite. Para ello se necesita una persona responsable y una periodicidad con la que se coteje con el sistema, y no con su versión anterior.
- Responsabilidad: Lukas Wójcik, titular. Se revisa anualmente y cada vez que cambia una actividad de tratamiento.
- Hechos que obligan a actualizarlo: un subencargado nuevo o modificado, en particular la elección del proveedor de servicios de correo; una tabla nueva o un campo nuevo con datos personales; un cambio en los plazos de conservación o en las cadenas de eliminación de
cfg/fristen_lib.php o srv/cron_status.php; un nuevo canal de alertas o una nueva solicitud a un tercero; la activación de una función desactivada por defecto (protección colectiva con redes IP, sonda, dominios propios, programa de socios, pago contra factura, Spamhaus o Google Web Risk); un traslado a otros servidores.
- Procedimiento: cada afirmación aquí contenida procede del código, del esquema o de una medición. Una revisión que solo lee el texto no ha revisado nada: el esquema y las cadenas de eliminación se miden de nuevo, los marcadores de posición siguen siendo marcadores de posición, los puntos abiertos se cierran o se mantienen con su justificación.
- Relación con otros documentos: este registro no sustituye a la Política de privacidad, al Contrato de encargo del tratamiento, a las Medidas técnicas y organizativas ni a la lista de Subencargados del tratamiento. Cuando difieran de este registro, la diferencia constituye un hallazgo.
- Los cambios en este documento se recogen en la página Cambios en los documentos contractuales.