Registro de Actividades de Tratamiento (art. 30 del RGPD)

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

Versión 1.2 · Última actualización: 29 de octubre de 2026

1. Cómo leer este registro

Este es el registro de actividades de tratamiento conforme al art. 30 del RGPD para formexposed. No es una política de privacidad ni publicidad. Su función es mostrar a una autoridad de control, a un Cliente que nos audita como encargados del tratamiento o a la siguiente persona que deba 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 verifica y monitorea formularios también debe estar abierto a la verificación.

Tres reglas guiaron su redacción.

  1. Medido, no meramente previsto. Una afirmación sobre campos de datos, plazos de conservación, destinatarios o garantías solo aparece cuando la respalda 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 de forma predeterminada se denomina «desactivado de forma predeterminada». Cuando no podemos demostrar algo, lo decimos.
  2. La conservación se indica dos veces. Una vez para cada actividad de tratamiento y otra en la sección 6 como visión global: qué ejecución nocturna elimina qué datos y a cuáles no alcanza. Un registro que afirma un plazo de conservación aplicable solo a parte de los datos es peor que uno que identifica el punto pendiente.
  3. Los puntos pendientes se indican en el texto, no en una nota al pie. La sección 8.1 enumera medidas aún no implementadas; 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 aparece 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 obtuvieron 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 la ejecución nocturna: el número que ve proviene del mismo ajuste que rige la eliminación. Los plazos de conservación fijados en el programa se indican como números.

Base de medición. El esquema, el código y la configuración se midieron el 11 de octubre de 2026 en el sistema de desarrollo, cuyo código y esquema coinciden con el sistema de producción. No indicamos cantidades de registros del sistema de desarrollo; contienen datos de prueba y no dicen nada sobre la operación en producción.

Omitido deliberadamente. Este registro no menciona nombres de host, direcciones de redes internas, puertos, nombres de usuario ni versiones de software de nuestros servidores. Estos detalles ayudan a un atacante y a ningún interesado. Por el mismo motivo, describimos los puntos pendientes de seguridad de nuestros propios servidores solo en términos generales (sección 8.1): indicamos el riesgo, no la vía para llegar a él. Proporcionamos los detalles a una autoridad de control previa solicitud.

Naturaleza jurídica. Este registro es la documentación que mantenemos conforme al art. 30 del RGPD para la autoridad de control; se publica voluntariamente. No forma parte de ningún contrato ni constituye declaración, garantía o acuerdo sobre la calidad frente a Clientes o terceros. Lo que debemos a los Clientes se rige por las Condiciones del Servicio, el Acuerdo de Tratamiento de Datos y sus anexos; respecto de estas obligaciones, prevalecen sobre este registro. El registro describe la situación a la fecha de esta versión. Clasificaciones 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 un tribunal; las medidas descritas como «previstas» son intenciones sin fecha comprometida.

2. La entidad y por qué este registro tiene dos partes

CampoEntrada
EntidadLW IT Solutions Company Lukas Wójcik, empresa individual inscrita en el registro mercantil polaco (CEIDG); propietario Lukas Wójcik
Direcciónal. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Poland
Identificadores fiscalesNIP 7252266190, VAT ID PL7252266190
Contactocontact@lukaswojcik.com; la ventana de soporte (signo de interrogación en la navegación); la página de contacto
Servicioformexposed: verificación, monitoreo 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 del RGPDNo aplica. La entidad está establecida en la Unión (Polonia).
Delegado de protección de datosNo designado. La evaluación conforme al art. 37 está en la sección 9.
Autoridad de control competentePrezes Urzędu Ochrony Danych Osobowych (UODO, la autoridad polaca de protección de datos), ul. Moniuszki 1A, 00-014 Warszawa
AlojamientoNuestros 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. Sin centro de datos de terceros ni proveedor de nube.

formexposed desempeña roles distintos frente a distintos grupos de personas. Confundirlos produce un registro que no es correcto para ninguno de ellos.

  • Responsable del tratamiento (parte B, art. 30, apartado 1). Nosotros mismos somos responsables del tratamiento de los datos de nuestros propios Clientes y los miembros de sus equipos (cuenta, inicio de sesión, facturación, soporte, registros), de los visitantes de nuestro propio sitio web, de las verificaciones sin cuenta (verificación gratuita, herramienta de encabezados, estudio, verificación de clientes potenciales) y de la prevención del abuso.
  • Encargado del tratamiento (parte A, art. 30, apartado 2). Para los datos personales de terceros que un Cliente introduce en el servicio o que surgen cuando prestamos un servicio para el Cliente, actuamos por cuenta del Cliente: copias de correos reales de formularios en la verificación de entrega, suscriptores del portal de clientes del Cliente, destinatarios de las alertas del Cliente, personas visibles de forma incidental en las páginas verificadas del Cliente, las credenciales de la cuenta de prueba del Cliente y el código de formulario que el Cliente pega. La base es el Acuerdo de Tratamiento de Datos, que se celebra con cada Cliente al registrarse.
  • Solo del 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 nos lleguen nunca (cuarentena, rescate de correos, desafío aritmético, configuración de conservación, contadores locales, grabador). No constituyen tratamiento por nuestra parte y, por tanto, no aparecen en ninguna de las dos partes. Aun así, las describimos al final de la parte A para que el límite sea visible.

La separación está integrada en el código, no solo en el texto: de un correo real de formulario, la verificación de entrega solo escribe en la base de datos la hora, la asignación y el resultado de autenticación; las capturas de pantalla de las verificaciones con navegador enmascaran los campos de entrada; las credenciales de las cuentas de prueba se cifran de modo que el servidor web ya no puede leerlas. Los detalles figuran en las entradas.

Las secciones 6 a 11 se aplican a ambas partes: conservación, decisiones automatizadas, medidas técnicas y organizativas, delegado de protección de datos, puntos pendientes y mantenimiento de este registro.

Ámbito de aplicación. Este documento es la parte del registro que se refiere al servicio formexposed. El tratamiento de la misma entidad para otros servicios se documenta en sus propios registros; la contabilidad general y la administración empresarial fuera del servicio no están cubiertas por esta parte.

3. Parte A – Art. 30, apartado 2: tratamiento por cuenta de Clientes

A.0 Partes intervinientes

CampoEntrada
Encargado del tratamientoLW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Poland; contact@lukaswojcik.com
Responsables del tratamientoLos Clientes de formexposed: empresas y agencias que tienen dominios en su cuenta y utilizan funciones en las que surgen datos de terceros. Con las agencias, el propio cliente de la agencia puede ser además responsable del tratamiento; la agencia actúa entonces como encargada frente a ese cliente y nosotros como subencargados.
Lista de responsables del tratamientoParte de este registro, conservada en formato electrónico (art. 30, apartado 3, del 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 propietario de cada espacio de trabajo con nombre, dirección de correo electrónico y empresa de la cuenta de cliente (dirección y número de IVA solo en Stripe) (users, workspaces, workspace_users), más los dominios del espacio de trabajo (domains). La proporcionamos como extracto a una autoridad de control previa solicitud.
Representantes y delegados de protección de datos de los responsablesNo existe un campo específico para ello en el sistema. Si un Cliente ha designado un representante conforme al art. 27 del RGPD o un delegado de protección de datos, puede notificárnoslos; conservamos la notificación junto con la lista de responsables del tratamiento.
Representante del encargado del tratamientoNo aplica (establecido en Polonia).
Delegado de protección de datosNo designado (sección 9).
InstruccionesLa instrucción se deriva del Acuerdo de Tratamiento de Datos y de la configuración que realiza el Cliente: el Cliente activa la verificación de entrega, configura destinos de alertas, almacena una cuenta de prueba y configura un portal de clientes. Sin esa acción, no tiene lugar el tratamiento correspondiente.
Medidas técnicas y organizativasLa sección 8 y la página Medidas Técnicas y Organizativas se aplican a cada actividad de tratamiento de la parte A. Las medidas especiales se indican en la entrada correspondiente.

A.1 Verificación de entrega – copia de control de correos de formularios

CampoEntrada
FinalidadComprobar si el correo electrónico del formulario de contacto del Cliente se envía efectivamente y cómo se autentica (SPF, DKIM, DMARC, alineación). Después de un envío de prueba activo aceptado, su copia debe llegar al buzón de control dentro de un tiempo de espera ajustable (actualmente 3 horas); de lo contrario, se genera la alerta «Correo de prueba no recibido». Los encabezados también se utilizan para determinar la autenticidad del correo del formulario, el servicio de correo utilizado y la dirección de envío para la verificación en listas de bloqueo.
Requisito previoPlan de pago, dominio verificado, activación por el Cliente. El Cliente incluye su propia dirección de control con un identificador (con la forma «delivery+identifier@…») 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 interesadosVisitantes del sitio web del Cliente que envían el formulario del Cliente; personas cuyos datos un visitante escribe en el mensaje; personal del Cliente que aparece como destinatario en los encabezados.
Categorías de datos personalesEn el buzón de control (en el proveedor de servicios de correo): la copia completa de cada correo de formulario, incluidas consultas reales con nombre, dirección de correo electrónico, número de teléfono y texto libre, hasta su eliminación. Leídos durante la recuperación: los encabezados y, como máximo, los primeros 8 KB del cuerpo. En la base de datos: hora de recepción, asignación al dominio y, cuando corresponda, a la ejecución de prueba (delivery_log); el último resultado de autenticación por dominio con los resultados SPF, DKIM y DMARC, alineación, dominio del remitente, dominios de firma y la dirección del servidor de correo de envío (campo de autenticación del dominio en domains). El contenido, el asunto y la dirección del remitente visitante no se escriben en la base de datos.
Nota sobre el dominio del remitenteSi un formulario incluye la dirección del visitante como remitente (una configuración incorrecta que la verificación busca descubrir), el resultado de autenticación contiene el dominio de esa dirección, no la dirección en sí. Cuando un visitante utiliza un dominio personal, esto también puede ser un dato personal. Se sobrescribe en la siguiente recepción.
FuenteEl formulario del sitio web del Cliente, mediante la copia oculta incluida por el Cliente.
Base jurídica (determinada por el responsable del tratamiento)Determinada por el Cliente. Nuestro texto sugerido para la política de privacidad del Cliente basa la copia en el art. 6, apartado 1, letra f), del RGPD (interés legítimo en recibir consultas de forma confiable). El Cliente informa a sus visitantes sobre este flujo de datos; el Acuerdo de Tratamiento de Datos lo obliga a ello.
DestinatariosEl proveedor de servicios de correo que opera 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 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 ha elegido menciona el dominio del remitente si no pertenece al sitio web (A.3, 4.1).
Tercer paísDepende 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ónDespués del procesamiento correcto, el correo electrónico se marca para eliminación y se elimina del buzón en la misma ejecución, incluso si no puede asignarse a ningún dominio. La recuperación se ejecuta con la tarea de estado cada cinco minutos mientras el monitoreo esté activado en el área de administración (srv/cron_status.php, cfg/zustellung_lib.php). Si falla la recuperación o la eliminación, el correo permanece en el buzón hasta la siguiente ejecución correcta. La misma recuperación elimina las asignaciones de delivery_log después de 180 días. El resultado de autenticación permanece mientras exista el dominio.
Qué demuestra la pruebaSolo la recepción, en el buzón de control, de la copia asignada a la ejecución de prueba concreta. No demuestra 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 organizativasSección 8. En particular: el contenido se evalúa solo en memoria; no se almacenan el cuerpo, el asunto ni las direcciones completas de los remitentes; eliminación independientemente de que la asignación haya tenido éxito.

La verificación de entrega es la única función mediante la cual nos llegan mensajes reales de los visitantes de nuestros Clientes. Por eso constituye tratamiento por cuenta del Cliente y no un servicio bajo nuestra propia responsabilidad, y por eso el tiempo que permanecen en el buzón es la medida real del riesgo: normalmente minutos; si la recuperación se interrumpe, hasta que vuelva a ejecutarse. Las copias no deberían 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 clientes e informe mensual a suscriptores

CampoEntrada
FinalidadUna 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 y 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 interesadosLos clientes de la agencia y su personal que solicitan el informe; personas que abren el portal.
Categorías de datos personalesSuscriptor: 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 confirmación (doble confirmación), 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 aparecen en el registro de visitas a páginas (B.2).
FuenteIngresados por los propios suscriptores en el portal.
Base jurídica (determinada por el responsable del tratamiento)El consentimiento del suscriptor, obtenido mediante un procedimiento de doble confirmación; la agencia es responsable del tratamiento. No escribimos a nadie que no se haya inscrito y confirmado por sí mismo.
DestinatariosLa 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ísMediante el proveedor de servicios de correo; véase la sección 4.
ConservaciónEjecución nocturna de eliminación (cfg/fristen_lib.php, parte «suscriptores del portal»): solicitudes nunca confirmadas, después 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 dejan de recibir informes, pero sus datos permanecen (sección 10). Los portales y suscriptores se eliminan 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 organizativasSecció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 clic en cada correo electrónico; el portal solo muestra el estado y las cifras principales, ningún hallazgo individual con evidencias.

A.3 Destinatarios de alertas del Cliente, personas que confirman su recepción y responsables asignados

CampoEntrada
FinalidadNotificaciones sobre fallas y cambios a los destinos que configura el Cliente para un dominio: correo electrónico, webhook, Slack, Discord, Microsoft Teams, Google Chat, Telegram. Por destino, de inmediato o recopiladas diaria o semanalmente, además de destinos solo para escalamientos. Cada notificación de problema se convierte en un incidente cuya recepción puede confirmar el destinatario mediante un enlace. Para los formularios monitoreados, el Cliente puede especificar una persona responsable y una fecha límite.
Categorías de interesadosPersonal y prestadores de servicios del Cliente que el Cliente ingresa como destino de alertas o designa como responsables; personas que confirman la recepción de un incidente. Los miembros del equipo con cuenta propia también aparecen en la parte B.
Categorías de datos personalesDestino de alertas: canal, dirección de destino (dirección de correo electrónico, dirección de webhook o chat, ID de chat de Telegram), eventos seleccionados, modo de entrega, secreto de firma para webhooks, última entrega y último error (alerts). Registro de entrega: destino, eventos, estado, error, hora (alert_log). Cola de resúmenes: líneas de notificación y enlace hasta la entrega (alert_queue). Incidente: título, líneas de notificación, enlace, identificador de confirmación de recepción, hora y nombre o dirección de correo electrónico de la persona que confirma la recepción según lo ingresado en el formulario o, en su defecto, la dirección del miembro con sesión iniciada (alert_incidents). Intentos de entrega de escalamientos por incidente y destino: número de intentos (como máximo cinco), horas del último y del siguiente intento y del éxito, referencia al correo electrónico 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 notificacionesDominio, evento, una breve explicación y un enlace a la página del dominio. Ningún contenido de mensajes de visitantes.
FuenteIngresados por el Cliente; la persona que confirma la recepción ingresa su propio nombre; el ID de chat de Telegram se crea cuando el destinatario pulsa «Iniciar» en el bot (B.32).
Base jurídica (determinada por el responsable del tratamiento)Determinada por el Cliente; por regla general, la organización de sus propias operaciones (art. 6, apartado 1, letra b) o f), del RGPD respecto del personal y los prestadores de servicios del Cliente).
DestinatariosLos operadores de los canales elegidos; véase 4.1. Alertas por correo electrónico mediante el proveedor de servicios de correo (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA).
Tercer paísSegú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ónRegistro de entrega después 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). Incidentes mientras no estén resueltos; los resueltos, 180 días después de su resolución (cfg/vorfall_lib.php, ejecución de escalamiento), junto con sus intentos de entrega de escalamientos. Destinos de alertas y asignaciones hasta que los elimine el Cliente o junto con el dominio.
Medidas técnicas y organizativasSección 8. En particular: webhooks firmados con un secreto independiente por destino; confirmación de recepción solo después de un clic (POST), para que las vistas previas de enlaces en programas de chat no activen nada; las alertas durante una ventana de mantenimiento solo se registran, no se envían.

A.4 Personas visibles de forma incidental en las páginas verificadas del Cliente y en capturas de pantalla

CampoEntrada
FinalidadLa verificación de los dominios de la cuenta del Cliente (escaneo, monitoreo, verificación activa) lee las páginas públicas del Cliente y toma capturas de pantalla de formularios. Lo que muestra la propia página puede referirse a personas que no tienen nada que ver con la verificación. Estos datos surgen de forma incidental; no son la finalidad de la verificación.
Categorías de interesadosPersonas cuyo nombre, fotografía o datos de contacto aparecen en la página verificada (persona de contacto junto al formulario, fotografías del equipo en la página de inicio, datos del aviso legal).
Categorías de datos personalesCapturas de pantalla: el área visible de la página de inicio, cada formulario visible como recorte y la imagen de la página posterior a 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 campos, tipos de campos, etiquetas de campos, indicadores de obligatoriedad y visibilidad, etiquetas de botones de envío (forms, campo «mapa de campos»); sin valores de campos. El escáner lee el inicio de los campos ocultos (hasta 24 caracteres) y de los atributos de datos (hasta 60 caracteres) solo durante la verificación para reconocer marcas de tiempo y tokens; solo se almacena el resultado. Hallazgos con evidencias (findings), resumen con títulos de páginas (scans). Para las verificaciones elegibles en cuentas de pago, un modelo local genera un plan de acción priorizado a partir de hallazgos seleccionados y metadatos del escaneo; su texto, idioma, estado y marca de tiempo se almacenan en el resumen del escaneo. Si aparece una dirección de correo electrónico en el formulario como destinatario, solo se almacena su dominio, nunca la dirección.
FuenteLas páginas públicas del dominio del Cliente, recuperadas por el escáner.
Base jurídica (determinada por el responsable del tratamiento)Determinada por el Cliente para el contenido de su propio sitio web. Para nosotros, el tratamiento forma parte de la verificación encargada.
DestinatariosEl Cliente; en el caso de agencias, su cliente mediante el portal o un informe de marca blanca; cualquier persona que reciba un enlace de informe (informes en direcciones aleatorias, no en motores de búsqueda). 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 clasificarlo; no recibe imágenes. Para las verificaciones de pago elegibles, el modelo local también recibe el nombre de host, el resultado global y la puntuación, el CMS, el tipo de formulario pertinente y la dirección de la página, cualquier plugin identificado y hallazgos seleccionados fallidos o no concluyentes para elaborar un plan de acción. La solicitud se mantiene temporalmente en la cola interna de trabajos y se elimina después de su recogida o mediante la limpieza programada de entradas con más de una hora de antigüedad.
Tercer paísNinguno.
ConservaciónResultados de verificaciones de un dominio durante como máximo 13 meses; permanece la última verificación completada por dominio (ejecución nocturna de eliminación, parte «resultados de verificaciones antiguos»). Los formularios, hallazgos, referencias de imágenes y archivos de imágenes se eliminan con el resultado de la verificación. Con el dominio, estos datos se eliminan de inmediato (cadena de eliminación en B.15; excepciones en la sección 6.4).
Límites del enmascaramientoLas capturas de pantalla de la verificación completa no enmascaran nada: muestran lo que la página muestra a cualquier visitante. Los campos de formularios están vacíos al recuperarlos porque el escáner no ingresa nada; los valores rellenados previamente serían visibles. No se toman capturas de pantalla detrás de un inicio de sesión (A.5). Las imágenes de las verificaciones con navegador enmascaran los campos de entrada (A.6).
Medidas técnicas y organizativasSección 8. En particular: las imágenes solo pueden recuperarse mediante el informe y un identificador de imagen ajeno devuelve «no encontrado»; informes con noindex; cada verificación se ejecuta en su propio contenedor aislado.

Los mismos datos surgen en las verificaciones sin cuenta (verificación gratuita, estudio, verificación de clientes potenciales). Allí no hay un Cliente por cuya cuenta actuemos; por tanto, estos casos aparecen en la parte B (B.5, B.7, B.8).

A.5 Credenciales de cuenta de prueba para el escaneo detrás del inicio de sesión

CampoEntrada
FinalidadLeer formularios que solo aparecen después de iniciar sesión (área de clientes, área de miembros). 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 especificadas. Aparte del formulario de inicio de sesión, no envía nada, no realiza ninguna prueba activa allí, no toma capturas de pantalla ni 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 previoDominio verificado, plan de pago, rol de propietario o administrador, confirmación expresa de que la cuenta es una cuenta de prueba. Como máximo cinco páginas, todas en el mismo dominio.
Categorías de interesadosLa persona a cuyo nombre esté la cuenta de prueba (idealmente nadie; el Cliente debería utilizar una cuenta funcional); personas cuyos datos aparecen en las páginas detrás del inicio de sesión.
Categorías de datos personalesNombre 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 la creó, horas, último resultado como código corto (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 detrás del inicio de sesión: estructura del formulario como en A.4, sin capturas de pantalla y sin cookies.
FuenteIngresados por el Cliente en la cuenta.
Base jurídica (determinada por el responsable del tratamiento)Determinada por el Cliente. El Cliente garantiza que tiene derecho a utilizar la cuenta de prueba.
DestinatariosNinguno. Ni el Cliente, ni soporte, ni la interfaz de programación pueden extraer las credenciales; la interfaz solo muestra la pista del nombre de usuario.
Tercer paísNinguno.
Protección de las credencialesEl 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 datos asociados para que un texto cifrado no pueda 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; nosotros tampoco podemos descifrarlo allí. El servidor de escaneo descifra solo para la ejecución, transmite las credenciales al contenedor de verificación aislado solo mediante la entrada estándar, elimina de inmediato la copia en el trabajo y no las escribe en ningún resultado, registro ni texto de error. En su trayecto al sitio web del Cliente, solo las protege el cifrado de ese sitio web; los límites de este transporte se establecen en la sección 10.
ConservaciónCredenciales almacenadas hasta que las elimina el Cliente. Al eliminarlas, el texto cifrado se sobrescribe con datos aleatorios de la misma longitud y la fila se elimina; se borran los trabajos en espera (fe_login_loeschen()). Con el dominio, la fila se elimina mediante una clave foránea. El servidor de escaneo borra las copias de los trabajos después de la ejecución; lo que quede (trabajo abortado, servidor de escaneo caído) se borra mediante la tarea de estado a más tardar después 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 vence después de 14 días.
Medidas técnicas y organizativasSección 8. En particular: cifrado asimétrico con claves separadas; lista de bloqueo de rutas de cierre de sesión y eliminación; sin capturas de pantalla detrás del inicio de sesión; función solo para planes de pago y dominios verificados; cada cambio en el registro de auditoría (sin credenciales).

Deliberadamente no hemos creado ninguna forma de almacenar credenciales del servidor, el área de administración del CMS o las cuentas de alojamiento del Cliente. 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 formularios configurados, verificaciones con navegador y prueba independiente

CampoEntrada
FinalidadSe recorre un formulario monitoreado en un navegador real (Chromium, WebKit o ambos) hasta el punto justo anterior al envío: cargar la página, realizar clics previos (como máximo cinco, nunca en un campo de entrada ni en un botón de envío), rellenar campos con valores reconociblemente sintéticos (como una dirección bajo la terminación reservada .invalid), avanzar en formularios de varios pasos. La verificación con navegador no envía nada; el envío está bloqueado técnicamente en el navegador. Además, mediciones de tiempos y comparaciones visuales del formulario.
Categorías de interesadosComo en A.4 (personas visibles en la página del formulario); personal del Cliente ingresado como responsable asignado (A.3).
Categorías de datos personalesConfiguració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 de falla, mensajes de error depurados, mediciones de red y tiempos, una imagen del formulario como JPEG de como máximo 32 KB con campos de entrada enmascarados (form_browser_runs). Observaciones por verificación (form_observations), series temporales (form_performance). Trabajos con una lista de destinos (campos «destinos» y «resultado» en scan_jobs).
Acceso de pruebaSi el Cliente ha almacenado una cuenta de prueba (A.5), la verificación completa también la utiliza para los recorridos de formularios configurados. Según el código medido, las verificaciones con navegador independientes entre dos verificaciones completas funcionan sin cuenta de prueba.
Prueba independienteSe prevé un segundo punto de verificación en otra ubicación, que realizaría una comprobación cruzada antes de una alerta. Recibiría el dominio, la configuración depurada y el identificador de trabajo, ningún dato ingresado por visitantes ni credenciales. Actualmente no está configurado (desactivado de forma predeterminada). Sin esta prueba no hay evidencia de una segunda ubicación; una alerta se basa entonces en nuestra propia medición.
FuenteConfigurados por el Cliente; resultados de recuperar la página del Cliente.
Base jurídica (determinada por el responsable del tratamiento)Determinada por el Cliente para el contenido de su sitio web y para las responsabilidades de su personal.
DestinatariosEl Cliente; cuando se configura una prueba, su operador (actualmente nadie).
Tercer paísNinguno.
ConservaciónResultados de ejecuciones con navegador, trabajos con navegador completados y series temporales después de 13 meses (ejecución nocturna de eliminación, partes «browser_runs», «browser_jobs», «form_performance»). Configuraciones hasta que se elimina el dominio (individualmente pueden cambiarse o desactivarse, no eliminarse); con el dominio se eliminan, junto con las ejecuciones, observaciones y series temporales, mediante claves foráneas.
Qué demuestra la mediciónTiempos y estados de nuestro navegador de verificación. No miden lo que experimentan los visitantes reales ni demuestran tasas de finalización ni consultas perdidas.
Medidas técnicas y organizativasSección 8. En particular: envío impedido técnicamente; solo direcciones del mismo dominio; imágenes enmascaradas; contenedor de verificación aislado.

A.7 «Fix it for me» – código de formulario pegado

CampoEntrada
FinalidadEl 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 verificació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 interesadosPersonas cuyos datos se encuentren de forma incidental en el código pegado (como una dirección de destinatario, nombres en comentarios o credenciales de un servidor de correo).
Categorías de datos personalesEl código pegado, como máximo 30,000 caracteres. En la base de datos, solo una entrada en el registro de auditoría (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.
FuentePegados por el Cliente.
Base jurídicaEjecución del contrato con el Cliente (art. 6, apartado 1, letra b), del RGPD) para el código en sí; para los datos de terceros contenidos incidentalmente en él, el Cliente determina la base.
DestinatariosNinguno. El modelo de lenguaje funciona en nuestro propio servidor de escaneo en la red interna; ningún servicio externo de IA, ni siquiera como alternativa de respaldo.
Tercer paísNinguno.
ConservaciónEl código no se almacena. Para la comprobación de sintaxis se crea un archivo temporal y se elimina inmediatamente después. La entrada del registro de auditoría se elimina después de 365 días.
Nota al ClienteEl código que contenga contraseñas, claves de API o datos personales debería limpiarse antes de pegarlo. No verificamos el contenido.
Medidas técnicas y organizativasSección 8. En particular: solo propietarios y administradores en planes de pago; el código pegado se transmite al modelo identificado como datos y nunca se ejecuta; sin carga a servidores de terceros.

A.8 Marca blanca y personas de contacto de la agencia

CampoEntrada
FinalidadLos informes, informes breves, registros de evidencias y el portal de clientes de una agencia (plan Business) aparecen bajo su marca y, a solicitud, bajo un subdominio propio de la agencia.
Categorías de interesadosPersonas de contacto de la agencia cuyo nombre o datos de contacto aparecen en la línea de contacto.
Categorías de datos personalesNombre de la empresa, sitio web, línea de contacto, nota al cliente, color de acento, apariencia, archivo de logotipo, interruptor de referencia a formexposed, dominio propio con identificador de verificación y estado de verificación (workspace_branding).
FuenteIngresados por la agencia.
Base jurídicaEjecución del contrato con la agencia (art. 6, apartado 1, letra b), del RGPD). Cuando la línea de contacto nombra a personal de la agencia, la agencia determina la base.
DestinatariosCualquier persona a la que la agencia entregue un enlace de informe, informe breve o portal.
Tercer paísNinguno.
ConservaciónHasta que la agencia los cambie; la marca y el archivo de logotipo se eliminan con el espacio de trabajo (fe_arbeitsbereich_daten_loeschen()). Un dominio propio cuya verificación DNS falla durante siete días se desactiva. El dominio propio está desactivado de forma predeterminada.
Medidas técnicas y organizativasSección 8.

A.9 Recuentos, indicadores de estado y errores de campos del plugin y la extensión

CampoEntrada
FinalidadUna 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 la configuración de formularios, consultas almacenadas por fuente y plazo de conservación. Opcional, desactivado de forma predeterminada: eventos de formularios y categorías de errores de campos por posición de campo. Estas cifras generan «Protección en cifras», el informe mensual, la alerta de silencio y los avisos sobre configuraciones riesgosas.
ClasificaciónLas cifras están diseñadas para no describir a ninguna persona. Las enumeramos en la parte A porque surgen de eventos en el sitio web del Cliente generados por sus visitantes; a nuestro juicio, son datos personales como máximo en casos límite (un sitio web con muy pocos envíos en un día determinado). La transmisión en sí (claves, versiones, host) está en la parte B (B.20).
Categorías de interesadosVisitantes del sitio web del Cliente que envían un formulario.
Categorías de datos personalesCifras diarias por host: bloqueados en total y por motivo, envíos, correos electrónicos 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 eliminadas y liberadas (plugin_stats). Estado: versiones de una lista fija de plugins de formularios, CAPTCHA y correo, indicadores de configuración 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 errores por posición de campo (form_metrics). Nunca: datos ingresados, nombres de campos, contraseñas, archivos, direcciones de correo electrónico, nombres, direcciones IP ni identificadores persistentes de visitantes.
FuenteEl plugin del sitio web del Cliente, mediante una interfaz de programación que utiliza el secreto de conexión del sitio web.
Base jurídica (determinada por el responsable del tratamiento)Determinada por el Cliente; el Cliente decide si activa los recuentos opcionales y cómo informa a sus visitantes.
DestinatariosEl Cliente. Los dominios de enlaces de mensajes bloqueados pasan a la protección colectiva (B.21).
Tercer paísNinguno.
ConservaciónCifras diarias, notificaciones de cambios y contadores de formularios después de 13 meses (ejecución nocturna de eliminación, partes «plugin_stats» y «form_metrics»). Los indicadores de estado se sobrescriben con cada informe. Todos los datos del plugin de un host se eliminan en cuanto ningún dominio del sistema se refiera ya a ese host (de inmediato al eliminar el último dominio; datos antiguos cada noche, parte «orphan_hosts»).
Qué demuestran las cifrasLo que contó el plugin. No demuestran tasas de finalización ni consultas perdidas.
Medidas técnicas y organizativasSección 8. En particular: aceptación solo con el par de claves vinculado del sitio web; solo se aceptan claves conocidas y números, 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 la extensión de TYPO3 tratan datos exclusivamente en el servidor del Cliente. No nos llegan y no tenemos acceso a ellos. El operador del sitio web es el único responsable; decide sobre la activación, los plazos de conservación y cómo informar a sus visitantes. Para este fin, el plugin sugiere párrafos para la política de privacidad del operador.

FunciónQué se trata localmenteConservación del lado del Cliente
CuarentenaEnvíos detenidos con motivo, que pueden liberarse por correo electrónico a la dirección del sitio web14 días
Rescate de correosEnvíos cuyo correo de formulario falló, para reenviarlos (activado de forma predeterminada)30 días
Desafío aritmético en lugar de reCAPTCHATarea aritmética en el navegador del visitante, sin servicio de terceros (desactivado de forma predeterminada)–
Configuración de conservaciónEliminación de consultas almacenadas en plugins de formularios después del plazo elegido por el operador (desactivada de forma predeterminada)según la configuración
Limitación de frecuenciaun identificador de corta duración derivado de la dirección IP, que no se nos transmitecorta duración
Contadores diarios localesValores de los contadores antes de la transmisióncomo máximo 14 días
Grabador para administradoresselectores técnicos y pasos de navegación en el almacenamiento de sesión del navegador de un administrador con sesión iniciada; no se leen los datos ingresados. Solo se transmite la configuración seleccionada (entonces A.6)como máximo 15 minutos
Ayuda para visitantespuede activarse por separado; no almacena borradores ni reenvía automáticamente–
Observación de nuevas reglas de spamlas coincidencias adicionales se cuentan localmente, sin activación automáticasiete días

A.11 Protección de formularios (formconfirmed)

CampoEntrada
FinalidadEvaluación de los envíos realizados mediante 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 llenado, campo trampa, solicitudes acumuladas; a solicitud 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 interesadosVisitantes de los sitios web del Cliente que abren una página con un formulario protegido o lo envían.
Categorías de datos personalesDirecció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 llenado, campo trampa llenado sí/no, identificador del navegador en el registro del servidor web; solo con la revisión del contenido activada, el texto del mensaje (solo en la memoria de trabajo).
OrigenNavegador del visitante (tarea, token de verificación); servidor del Cliente (solicitud de verificación y, en su caso, texto).
DestinatariosEl Cliente (puntuación, acción, motivos). Ningún otro; ningún subencargado para este tratamiento.
Tercer paísNinguno.
ConservaciónIdentificador convertido en hash, 1 hora; tokens de verificación usados, 11 minutos como máximo; resultados de 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, sin almacenamiento.
Medidas técnicas y organizativasSecció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 y transferencias a terceros países

La siguiente tabla enumera los destinatarios que nosotros mismos contratamos y que pueden recibir datos de la parte A. La lista vinculante y continuamente actualizada es la página Subencargados del Tratamiento; si difiere de esta tabla, es un hallazgo, no una cuestión de formato.

DestinatarioQué recibeTercer paísBaseEstado
Namecheap, Inc. (Private Email), Phoenix, Arizona, USABuzón de control de la verificación de entrega (A.1); envío de correos de alerta (A.3), confirmaciones e informes a suscriptores del portal (A.2)Lugar de tratamiento aún por verificar; véase la página «Subencargados del Tratamiento»Acuerdo de Tratamiento de Datos; base de transferencia aún por verificarPendiente. El contrato pertinente, los lugares efectivos 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 hasta que se configure el buzón)Hasta que se configure el buzón, correo general entrante a direcciones de nuestro dominio; no las copias de la verificación de entrega, que solo llegan con registros MX que apunten directamente al buzón (A.1)EE. UU.por verificar: certificación en el Marco de Privacidad de Datos UE-EE. UU. o cláusulas contractuales tipoEn uso; base pendiente.
Nuestro propio servidor de escaneo con un modelo de lenguaje localEstructura de formularios para clasificación y hallazgos seleccionados con metadatos de escaneo para planes de acción en cuentas de pago (A.4), código pegado (A.7), acceso de prueba descifrado solo durante la ejecución (A.5)–Operado por nosotros, no un terceroEn uso.
Prueba independiente en una segunda ubicaciónDominio, configuración depurada, identificador de trabajo (A.6)según la ubicaciónpor determinar antes de su puesta en marchaNo configurada.

Alojamiento: sin terceros. 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 nos trasladamos a un centro de datos o proveedor de nube, este párrafo debe reescribirse.

4.1 Canales de alerta elegidos por el Cliente

Además de los destinatarios que contratamos, hay canales que el Cliente elige para sus alertas (A.3). Nuestro servidor inicia la transmisión; el Cliente determina el destino y el proveedor. Elegir un canal no nos exime de nuestras propias obligaciones como encargados del tratamiento. El rol, el contrato y las garantías necesarias para terceros países deben determinarse para cada proveedor; para los servicios de chat, esto aún no se ha completado (cuestión pendiente para la revisión jurídica).

CanalQué se envíaSede del proveedor
Correo electrónicoDominio, evento, explicación, enlace; a la dirección ingresadamediante Namecheap, Inc. (Private Email), Phoenix, Arizona, USA
Webhook a una dirección elegida librementeEvento como JSON (dominio, eventos, líneas, enlace, marca de tiempo), firmado con el secreto del destinodeterminada por el Cliente
Slack, Discord, Microsoft Teams, Google Chatla misma notificación como mensaje de chat a la dirección de webhook ingresadaprincipalmente EE. UU.
Telegramdestino elegido por el Cliente; enviamos el mensaje mediante nuestro bot al ID de chat vinculadofuera 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 visitante. Las notificaciones llevan dominio, evento y enlace.

5. Parte B – Art. 30, apartado 1: tratamiento bajo nuestra propia responsabilidad

Responsable del tratamiento de todo lo contenido en esta parte: LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Poland, 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. La forma en que los interesados ejercen sus derechos se describe en la página Acceso, Supresión y sus Demás Derechos; los titulares de cuentas pueden descargar sus datos por sí mismos como archivo (Configuración).

Cuando nos basamos en intereses legítimos (art. 6, apartado 1, letra f), del RGPD), indicamos el interés y el motivo por el que un medio menos intrusivo no es suficiente. 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

CampoEntrada
FinalidadOperación y seguridad del sitio web y de la aplicación: entrega, resolución de problemas, detección de ataques y sobrecarga.
Categorías de interesadosToda persona que abre una página de formexposed.com o form.exposed, incluidos visitantes de páginas de Clientes cuyo navegador carga la imagen de nuestra insignia (B.18), destinatarios que abren un enlace de informe o de confirmación de recepción y sitios web cuyo plugin llama a nuestra interfaz.
Categorías de datos personalesDirección IP completa, hora, dirección solicitada, código de estado, bytes transferidos, página de referencia (referente), identificador del navegador (user-agent).
Dónde se almacenaRegistros de acceso del proxy frontal y del servidor web como archivos en el servidor web, no en la base de datos.
FuenteEl navegador o programa que realiza la solicitud.
Base jurídicaArt. 6, apartado 1, letra f), del RGPD. Interés: operación segura y sin interrupciones. Ponderación: sin la dirección completa no pueden vincularse solicitudes repetidas del mismo remitente ni repelerse ataques; una dirección truncada no permite esta distinción. Los registros no se combinan con otros datos y se eliminan después de un periodo corto.
DestinatariosNinguno.
Tercer paísNinguno.
Conservación14 días: rotación diaria con 14 generaciones y posterior sobrescritura (servicio de rotación de registros del sistema, no la ejecución nocturna de eliminación de la aplicación).
Medidas técnicas y organizativasSección 8.

B.2 Registro de visitas a páginas de la aplicación

CampoEntrada
FinalidadSeguridad y detección del abuso (quién solicita qué y con qué frecuencia), trazabilidad del acceso a cuentas, estadísticas simples de uso sin servicio de analítica.
Categorías de interesadosTodos los visitantes del sitio web y usuarios de la aplicación en visitas reales a páginas (sin solicitudes en segundo plano ni envíos de formularios).
Categorías de datos personalesDirección IP completa, el país derivado de ella al escribirla (base de datos geográfica local, sin consulta a un tercero), ID de cuenta para usuarios con sesión iniciada, dirección solicitada y página de referencia (tokens de acceso contenidos en ellas, como los de enlaces de informes o portales, enmascarados), identificador del navegador y el tipo de dispositivo, sistema operativo y navegador derivados de él, idioma, hora (access_logs). Durante «Ver como Cliente» (B.14) no se establece ningún ID de cuenta para que las visitas a páginas del soporte no aparezcan en el registro del Cliente.
FuenteLa solicitud del navegador.
Base jurídicaArt. 6, apartado 1, letra f), del RGPD. Interés: prevención del abuso 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.
DestinatariosNinguno. Los titulares de cuentas reciben sus propias visitas a páginas en la exportación de datos.
Tercer paísNinguno.
Conservación60 días (cada noche entre las 03:00 y las 03:05, srv/cron_status.php, ajuste «registro de visitas a páginas»).
Medidas técnicas y organizativasSección 8. La dirección IP solo se toma de un encabezado de reenvío si la solicitud proviene de nuestro propio proxy frontal, y entonces solo la entrada agregada por ese proxy; de lo contrario, cualquiera podría indicar su origen a voluntad.

B.3 Cookies y almacenamiento en el navegador

CampoEntrada
FinalidadAlmacenamiento técnicamente necesario: sesión, protección contra la falsificación de solicitudes entre sitios (CSRF), recuento de límites para verificaciones sin cuenta, inicio de sesión, mantener la sesión iniciada a solicitud, visualización clara u oscura.
Categorías de interesadosVisitantes y usuarios de formexposed.com.
Categorías de datos personalesCookie de sesión bpid (identificador de sesión; termina al cerrar el navegador; HttpOnly, SameSite=Lax, Secure mediante HTTPS). Cookie bp_remember solo después de elegir «Mantener mi 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 locales de visualización de los operadores. Para los límites, se forma un hash a partir del identificador de sesión; el identificador en sí no se almacena.
No se instalaNinguna cookie de analítica, publicidad o seguimiento. El programa de socios (B.33) funciona sin cookie. La imagen de la insignia en páginas de Clientes no instala ninguna cookie (B.18). reCAPTCHA puede instalar cookies de Google cuando se envía un formulario protegido (B.23).
Base jurídicaAcceso al dispositivo terminal: estrictamente necesario para el servicio solicitado por el usuario (§ 25, apartado 2, punto 2, de la TDDDG, Ley alemana de Protección de Datos de Telecomunicaciones y Servicios Digitales; art. 399, apartado 3, de la PKE, Ley polaca de Comunicaciones Electrónicas (Prawo komunikacji elektronicznej)). Tratamiento: art. 6, apartado 1, letra b), del RGPD (cuenta) y letra f) (seguridad, límites).
DestinatariosNinguno.
Tercer paísNinguno.
ConservaciónSesión; 30 días para el token de recordar sesión. La ejecución nocturna elimina los tokens de recordar sesión vencidos de la base de datos (remember_tokens); al cerrar sesión, cambiar la contraseña y revocar un dispositivo, de inmediato.
Medidas técnicas y organizativasSección 8.

B.4 Verificación gratuita sin cuenta – aceptación, límites y vigilancia del abuso

CampoEntrada
FinalidadCualquier persona puede solicitar la verificación de 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 verificació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 dominios muy recientes, lista de bloqueo y exclusión, solo direcciones públicas. Los patrones llamativos se registran y se comunican al operador. Los límites por dirección IP, por sesión y para todo el sistema, contados por separado, también se aplican a la verificación desde el plugin sin cuenta (un plugin con un par de claves vinculado se cuenta por sitio web en lugar de por dirección) y a la exclusión (B.30); la herramienta gratuita de encabezados (B.9) tiene sus propios límites por dirección IP y día y para todo el sistema.
Categorías de interesadosPersonas que inician una verificación, una solicitud de la herramienta de encabezados o una exclusión; servidores en los que está instalado un plugin.
Categorías de datos personalesRegistro de cada solicitud: origen (verificación, plugin, herramienta de encabezados, exclusión), dirección IP completa, hash del identificador de sesión, host verificado, país de la dirección IP, aceptada o rechazada con 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, descripción breve, horas de detección y resolución, persona que 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, vencimiento, primera visita, número de visitas (reports). Antigüedad del dominio en caché obtenida de la consulta al registro (domain_age_cache).
FuenteLos datos ingresados por la persona; su solicitud; consulta al registro (RDAP) para la antigüedad del dominio.
Base jurídicaEjecución de la verificación solicitada: art. 6, apartado 1, letra b), del RGPD (uso de la verificación gratuita conforme a las Condiciones del Servicio); subsidiariamente, letra f). Límites y vigilancia: art. 6, apartado 1, letra f). Interés: evitar que el servicio se utilice como herramienta contra sitios web de terceros o como cañón de spam. Ponderación: sin vinculación a la dirección y la sesión, no podrían aplicarse los límites; el plazo de siete días es tan corto como el límite más largo que se cuenta a partir de él.
DestinatariosGoogle (reCAPTCHA al enviar, B.23). Para la antigüedad del dominio, el escáner consulta el servicio de redirección RDAP rdap.org, que reenvía al registro responsable; solo se transmite el nombre de dominio. Cuando se produce una anomalía, el operador recibe una señal mediante Telegram sin ninguna variable (sin host ni dirección). El informe puede verlo quien tenga su enlace aleatorio.
Tercer paísEE. UU. mediante reCAPTCHA (B.23).
ConservaciónRegistro 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 vencen después de 30 días; la ejecución nocturna elimina entonces el informe, el trabajo, el resultado de la verificación, los formularios, los hallazgos y las imágenes (fe_reports_aufraeumen()). Un administrador puede liberar manualmente entradas de una dirección; esto elimina su registro de las últimas 24 horas.
Medidas técnicas y organizativasSección 8. Detención de emergencia para todas las verificaciones anónimas en el área de administración; control de contrapresión que no acepta nuevas verificaciones gratuitas cuando hay una acumulación de trabajos.

B.5 Verificación de sitios web de terceros mediante rastreador

CampoEntrada
FinalidadVerificación de seguridad de formularios de contacto públicos: protección contra el spam y el abuso, características de protección de datos y accesibilidad, scripts de terceros incorporados, comportamiento después del rechazo en el banner de cookies, visualización móvil. Se aplica a las verificaciones 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 verificación de clientes potenciales (B.8). Para los dominios verificados de una cuenta actuamos por cuenta del Cliente (A.4).
Comportamiento del rastreadorIdentificador propio con referencia a la página del rastreador; lee robots.txt antes de la verificación y se detiene si una regla de prohibición abarca la página de inicio (también si robots.txt no es accesible o hay un error del servidor); las reglas de prohibición para subrutas individuales no se observan por separado. El pulso de formularios, la recuperación de la prueba, la herramienta de encabezados y la búsqueda de archivos expuestos no leen robots.txt. Como máximo ocho páginas públicas por verificación, además de hasta tres páginas con un clic en «Rechazar» en el banner de cookies, hasta tres páginas en vista de celular, pruebas activas para dominios verificados y hasta cinco páginas detrás de un inicio de sesión (A.5); las páginas se cargan sucesivamente, no en paralelo; solo direcciones públicas, sin redes internas, las redirecciones se vuelven a comprobar; la lista de bloqueo y la exclusión se comprueban antes de la aceptación y por segunda vez en el escáner. Pasivo: sin prueba de control, no se envía nada para los Clientes (excepción: verificaciones internas de nuestros propios dominios de prueba y demostración, B.6).
Categorías de interesadosOperadores de los sitios web verificados (cuando son personas físicas, como empresarios individuales); personas visibles de forma incidental en las páginas verificadas.
Categorías de datos personalesComo en A.4: direcciones y títulos de páginas, estructura de formularios (nombres de campos, tipos y etiquetas, sin valores de campos), medidas de protección, 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 aparece una dirección de destinatario en el formulario, solo su dominio (scans, forms, findings, scan_screenshots).
FuentePáginas accesibles públicamente.
Base jurídicaArt. 6, apartado 1, letra f), del RGPD. Interés: realizar la verificación de seguridad solicitada; alertar a los operadores de sitios web sobre debilidades que pueden perjudicar a sus visitantes. Ponderación: solo se lee lo que ve cualquier visitante, en un alcance reducido y sin enviar nada; el operador puede excluir permanentemente su dominio en cualquier momento sin prueba. La información del art. 14 del RGPD se proporciona mediante la página del rastreador, la exclusión y la Política de Privacidad; si esto es suficiente conforme al art. 14, apartado 5, letra b), es una cuestión pendiente para la revisión jurídica.
DestinatariosQuien inicia el informe y cualquier persona a la que entregue 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). Los avisos de vulnerabilidades a partir de versiones de plugins nunca aparecen en informes anónimos.
Tercer paísNinguno.
ConservaciónAnónimo: 30 días (B.4). Verificación de clientes potenciales: 90 días (B.8). Estudio: hasta la publicación (B.7). Dominio en una cuenta: como máximo 13 meses, permanece la última verificación; de inmediato con el dominio. Verificaciones 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 eliminan después de cada ejecución.
Medidas técnicas y organizativasSección 8. En particular: contenedor de verificación separado 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

CampoEntrada
FinalidadComprobar si un formulario de contacto acepta un envío sin protección, si CAPTCHA, trampa (campo trampa), token, validación de direcciones de correo electrónico y limitación de frecuencia surten efecto del lado del servidor y si pueden inyectarse encabezados.
Requisito previoPara los Clientes, solo para dominios para los que se ha proporcionado prueba de control (registro DNS, metaetiqueta, archivo o plugin conectado); además, el operador utiliza una herramienta interna de línea de comandos para crear verificaciones con el nivel «verificado» para nuestros propios dominios de prueba y demostración. Solo con el interruptor global activado y para un formulario clasificado de forma confiable como formulario de contacto general. Nunca para pedidos, reservas, registros, boletines, pagos, carga de archivos, campos obligatorios con datos personales reales ni dominios de autoridades públicas, instituciones sanitarias o educativas.
Categorías de interesadosPersonal del Cliente que recibe los correos de formularios.
Categorías de datos personalesEl envío de prueba no contiene datos personales: remitente «FormExposed Security Scanner», nuestra propia dirección de remitente o una dirección bajo .invalid, una línea de asunto identificada como prueba y un texto en el idioma de la página con referencia a la página del rastreador y a la exclusión y el número de verificación. Almacenados por nosotros: la respuesta de la página, hallazgos, una imagen de la página posterior (como en A.4).
AlcanceComo máximo cinco envíos por verificación (ajuste, predeterminado 5); periódicamente con la frecuencia de verificación del plan, diariamente en el plan más alto.
FuenteLa instrucción del Cliente.
Base jurídicaEjecución del contrato con el Cliente (art. 6, apartado 1, letra b), del RGPD); los envíos se realizan al propio formulario del Cliente. Para los destinatarios del lado del Cliente: la organización del Cliente.
DestinatariosEl Cliente (su correo de formulario).
Tercer paísNinguno por nuestra parte.
ConservaciónResultados como en A.4.
Medidas técnicas y organizativasSección 8. La inyección de encabezados solo se detecta, nunca se realiza con un destinatario real; la validación de direcciones de correo utiliza únicamente un dominio que no puede existir.

B.7 Estudio «Índice de seguridad de formularios»

CampoEntrada
FinalidadEstadísticas sobre la protección de 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 interesadosOperadores de los sitios web de la lista; personas visibles de forma incidental.
Categorías de datos personalesComo en B.5, solo de forma pasiva. Además, la lista: host, segmento, estado, trabajo (study_domains); estudio con título, país, totales de resultados (studies).
FuenteUna lista de sitios web públicos elaborada por el operador; las propias páginas.
Base jurídicaArt. 6, apartado 1, letra f), del RGPD. Interés: afirmaciones estadísticas sobre el estado de la seguridad de formularios. Ponderación: pasivo, con frecuencia limitada (pocos trabajos por ejecución), se aplican la lista de bloqueo y la exclusión, publicación solo como totales, los datos sin procesar se eliminan.
DestinatariosEl público, solo totales.
Tercer paísNinguno.
ConservaciónLos datos sin procesar (resultados de verificaciones, formularios, hallazgos, imágenes, trabajos) se eliminan al publicar (fe_studie_veroeffentlichen()). La lista de hosts con segmento permanece después; no existe plazo de conservación para ella ni para estudios que nunca se publican (sección 10). El operador decide qué listas se verifican y si los estudios se publican.
Medidas técnicas y organizativasSección 8.

B.8 Verificación de clientes potenciales (modo de captación para agencias)

CampoEntrada
FinalidadUna agencia (plan Business) verifica pasivamente el sitio web de un cliente potencial y recibe un informe breve bajo su marca y el informe pasivo. No contactamos a nadie; la propia agencia comparte el enlace.
Categorías de interesadosOperador del sitio web verificado; personas visibles de forma incidental; personal de la agencia que inicia la verificación.
Categorías de datos personalesComo en B.5, solo de forma pasiva. Además: espacio de trabajo, persona que inicia la verificación, host, identificador aleatorio del informe, hora (prospect_checks).
FuenteLos datos ingresados por la agencia; páginas públicas.
Base jurídicaArt. 6, apartado 1, letra f), del RGPD (nuestro interés en prestar el servicio y el interés de la agencia en un acercamiento fundamentado). Los roles de la agencia y de nosotros y las obligaciones de la agencia al compartir 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 hace una llamada telefónica, eso es mercadotecnia directa que requiere consentimiento conforme al art. 398 de la PKE y al § 7, apartado 2, de la UWG (Ley alemana contra la Competencia Desleal), incluso entre empresas. Esto es responsabilidad de la agencia; las Condiciones del Servicio la obligan en consecuencia.
DestinatariosLa agencia y cualquier persona a la que entregue el enlace.
Tercer paísNinguno.
ConservaciónEl informe y el resultado de la verificación vencen después de 90 días y la ejecución nocturna los elimina entonces (fe_reports_aufraeumen()); la entrada de la verificación se elimina después de 90 días en la ejecución diaria de protección colectiva a partir de las 04:00 (srv/cron_status.php). Con el espacio de trabajo, de inmediato.
Medidas técnicas y organizativasSección 8. Cuota mensual (ajuste, predeterminada 30); la misma página dentro de siete días devuelve el mismo informe; se aplica la exclusión.

B.9 Herramienta de encabezados sin cuenta

CampoEntrada
FinalidadCalificación gratuita (A+ a F) de los encabezados de seguridad de la página de inicio de un dominio. Dos solicitudes, sin navegador, sin formulario, sin envío.
Categorías de interesadosPersonas que utilizan la herramienta; operadores del dominio verificado.
Categorías de datos personalesRegistro de solicitudes como en B.4 (origen «headers», dirección IP, hash de sesión, host). Resultado: host, calificación, puntos, encabezados evaluados (header_checks).
Base jurídicaArt. 6, apartado 1, letra f), del RGPD, como en B.4 y B.5.
DestinatariosGoogle (reCAPTCHA, B.23).
Tercer paísEE. UU. mediante reCAPTCHA.
ConservaciónRegistro de solicitudes, 7 días; resultados, actualmente después de 90 días (ejecución nocturna de eliminación, parte «header_checks», ajuste «headers_keep_days»). Para los dominios de una cuenta, la calificación se vuelve a determinar diariamente y se almacena con el dominio.
Medidas técnicas y organizativasSección 8. Límites por dirección IP y día; se aplica la exclusión.

B.10 Cuentas de cliente

CampoEntrada
FinalidadOperar cuentas de cliente, espacios de trabajo y planes.
Categorías de interesadosClientes (empresas) y miembros de sus equipos con cuenta propia.
Categorías de datos personalesDirección de correo electrónico y forma normalizada, contraseña solo como hash, nombre (obligatorio), apellido y empresa (cuando se proporcionan); la aplicación no almacena dirección ni número de IVA, solo se proporcionan en Stripe (B.26); estado, idioma, modo de visualización, moneda, plan y estado de facturación, ID de cliente y suscripción de Stripe, final del periodo de facturación, cancelación al final del periodo, identificadores de confirmación y restablecimiento con vencimiento, nueva dirección de correo electrónico hasta su confirmación, hora de registro, último inicio de sesión y última dirección IP, hora de revocación de todas las sesiones, datos de dos factores (B.11), informe mensual activado/desactivado, hora del correo de recordatorio, activaciones mediante códigos, código de recomendación y referencia (users). Espacios de trabajo con nombre, horas, estado (workspaces); membresía con rol y fecha de incorporación (workspace_users).
FuenteRegistro y configuración por la persona; estado de facturación de Stripe.
Base jurídicaArt. 6, apartado 1, letra b), del RGPD (contrato). Última dirección IP: letra f) (seguridad de la cuenta).
DestinatariosStripe (B.26); proveedor de servicios de correo para correos de 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ísMediante Stripe y el proveedor de servicios de correo.
ConservaciónHasta que los elimina el titular de la cuenta. Al eliminarla, los espacios de trabajo propios del titular que nadie más utiliza se eliminan 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 de mayor antigüedad. Se eliminan las membresías, los tokens de recordar sesión, los dispositivos, las claves de API, los códigos pendientes de Telegram, los comentarios sobre informes (B.35) y la fila de la cuenta; primero se termina de inmediato en Stripe una suscripción de pago en curso, 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 establece en la sección 6.4. Las cuentas nunca confirmadas y en las que nunca se ha iniciado sesión se eliminan después de 30 días, salvo que otro miembro esté vinculado a su espacio de trabajo (ejecución nocturna de eliminación, parte «pending_accounts»). No se eliminan las cuentas inactivas. Si el contrato de la cuenta termina de otra forma, por ejemplo, mediante nuestra terminación, eliminamos la cuenta a más tardar 30 días después del final del contrato; actualmente esto se hace manualmente (compromiso del Acuerdo de Tratamiento de Datos).
Medidas técnicas y organizativasSección 8.

B.11 Inicio de sesión, dispositivos, segundo factor y registro de auditoría

CampoEntrada
FinalidadProteger cuentas: limitar los intentos de inicio de sesión y otros intentos de contraseña, mostrar y revocar dispositivos con sesión iniciada, inicio de sesión de dos factores, trazabilidad de cambios.
Categorías de interesadosTitulares de cuentas y miembros de equipos; personas que intentan iniciar sesión, registrarse o introducir la contraseña de un portal de clientes.
Categorías de datos personalesIntentos de inicio de sesión: dirección IP, dirección de correo electrónico ingresada, éxito, hora (login_attempts). Dispositivos: hash del identificador de sesión (nunca el identificador en sí), vínculo al token de recordar sesión, dirección IP, identificador del navegador y el navegador, sistema operativo y tipo de dispositivo derivados de él, horas de inicio de sesión, última actividad y revocación y, para «Ver como Cliente», el identificador de la persona de soporte (login_sessions). Tokens de recordar sesión para «Mantener mi sesión iniciada»: selector, verificador, vencimiento (remember_tokens). Dos factores: secreto cifrado, hora de activación, último intervalo temporal utilizado, códigos de recuperación solo como hash (en users). Registro de auditoría: cuenta, espacio de trabajo, acción, destino, detalles, dirección IP, país, hora (audit_logs). Contadores de intentos de inicio de sesión, segundo factor, confirmación de contraseña, restablecimiento de contraseña, registro y contraseñas de portales de clientes: una clave HMAC derivada de la finalidad y del ID de cuenta (para una dirección desconocida o un restablecimiento, la dirección de correo electrónico en minúsculas), la dirección IP, la cuenta y la dirección IP juntas o el ID del portal (también junto con la dirección IP), número de intentos, vencimiento; las direcciones de correo electrónico e IP no se almacenan allí en texto claro (tabla auth_attempt_buckets).
Base jurídicaArt. 6, apartado 1, letra b), del RGPD en relación con el art. 32 (lista de dispositivos, segundo factor) y letra f) (intentos de inicio de sesión, registro de auditoría). Interés: proteger las cuentas contra la toma de control, documentar cambios (art. 5, apartado 2). Ponderación: una dirección truncada no responde a la pregunta «¿fui yo?»; el registro de auditoría debe durar más que un conflicto que surja solo meses después.
DestinatariosNinguno. El titular de la cuenta ve sus dispositivos y recibe intentos de inicio de sesión, dispositivos y 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ísNinguno.
ConservaciónIntentos de inicio de sesión, 7 días; después de un inicio de sesión correcto, los intentos fallidos desde la misma dirección se eliminan de inmediato. Contadores de intentos al final de su ventana temporal (actualmente 15 minutos, una hora para restablecimiento de contraseña y registro); los vencidos se eliminan en el siguiente acceso y mediante la ejecución nocturna. Dispositivos, 90 días después del último uso o de la revocación (ejecución nocturna de eliminación, parte «sessions»), de inmediato con la cuenta. Los tokens de recordar sesión vencen después de 30 días. Registro de auditoría, 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 organizativasSección 8.

B.12 Prueba de celebración del contrato

CampoEntrada
FinalidadDemostrar qué versión de las Condiciones del Servicio, el Acuerdo de Tratamiento de Datos y la Política de Privacidad aceptó un Cliente o de cuál tomó conocimiento al registrarse, y que utiliza el servicio para su empresa.
Categorías de interesadosClientes.
Categorías de datos personalesPor documento: cuenta, documento, versión (hash del texto mostrado), ocasión, dirección IP, identificador del navegador, hora (legal_consents). La propia versión mostrada con texto completo, idioma, título y dirección, una vez por versión (legal_versions; no contiene datos personales).
Base jurídicaArt. 6, apartado 1, letras b) y f), del RGPD (prueba de celebración del contrato, defensa frente a reclamaciones).
DestinatariosNinguno. El titular de la cuenta recibe sus registros en la exportación de datos.
Tercer paísNinguno.
ConservaciónMientras exista la cuenta; después de eliminarla, cuatro años desde el consentimiento y posterior eliminación nocturna (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 hacia arriba. Si el derecho polaco sugiere otro plazo forma parte de la revisión jurídica.
Medidas técnicas y organizativasSección 8. Si falta cualquiera de los tres documentos, se cierra el registro de cuentas.

B.13 Invitaciones al equipo

CampoEntrada
FinalidadInvitar a otras personas a un espacio de trabajo.
Categorías de interesadosPersonas invitadas.
Categorías de datos personalesDirección de correo electrónico, rol, identificador de invitación, persona que invita, vencimiento, hora de aceptación (workspace_invites); el correo de invitación en la bandeja de salida (B.25).
FuenteIngresados por el miembro que invita.
Base jurídicaArt. 6, apartado 1, letra b), del RGPD respecto del Cliente; frente a la persona invitada, letra f) (interés del Cliente en involucrar a su equipo).
DestinatariosProveedor de servicios de correo (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA).
Tercer paísMediante el proveedor de servicios de correo.
ConservaciónUna invitación es válida durante 14 días y solo mientras la persona que invita sea propietaria o administradora del espacio de trabajo. Las invitaciones no aceptadas, después del vencimiento; 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 organizativasSección 8.

B.14 «Ver como Cliente» por soporte

CampoEntrada
FinalidadUn superadministrador ve la aplicación tal como la ve un Cliente para resolver una pregunta de soporte («a mí me falta el botón»).
Categorías de interesadosEl Cliente correspondiente; el superadministrador.
Categorías de datos personalesTodo lo que el Cliente ve en la aplicación. Se registra: una fila de dispositivo independiente con el identificador del superadministrador (login_sessions), inicio y final en el registro de auditoría (audit_logs).
Base jurídicaArt. 6, apartado 1, letra b), del RGPD (soporte como parte del servicio); alternativamente, letra f).
LímitesComo máximo una hora, después cierre completo de sesión. Terminar la vista también cierra completamente la sesión del superadministrador, incluida la sesión de la que provenía; solo regresa al área de administración iniciando sesión de nuevo con contraseña y segundo factor. Termina de inmediato si se rebajan los privilegios del superadministrador o se bloquea su cuenta. Se bloquea todo lo que modifique la cuenta del Cliente: contraseña, dirección de correo electrónico, segundo factor, dispositivos, suscripción, exportación, eliminación, transferencia. El área de administración está 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.
DestinatariosNinguno.
Tercer paísNinguno.
ConservaciónFila de dispositivo, 90 días; registro de auditoría, 365 días.
Medidas técnicas y organizativasSección 8.

B.15 Dominios, prueba de control y monitoreo

CampoEntrada
FinalidadEl servicio principal para los Clientes: mantener dominios en la cuenta, proporcionar prueba de control, verificar regularmente y detectar cambios. Esto incluye el pulso de formularios (una solicitud ligera sin navegador cada 10 a 30 minutos según el plan), la vigilancia diaria de DNS de correo y certificado, la fecha de vencimiento del dominio, listas de bloqueo, archivos expuestos, versiones visibles desde el exterior, inventario de scripts, cambios visuales del formulario, caídas de proveedores de CAPTCHA y correo y la vigilancia de vulnerabilidades de plugins de formularios.
Categorías de interesadosClientes y miembros de sus equipos; operadores de los dominios cuando son personas físicas.
Categorías de datos personalesDominio con host, identificador público, nota, etiqueta de cliente, tipo e identificador de prueba, frecuencia de verificación, monitoreo activado/desactivado, ventanas de mantenimiento, valor de consulta, identificadores para insignia, verificación de entrega y hook de despliegue, clave del plugin, estados y últimos resultados de las vigilancias (DNS, certificado, autenticidad del correo del formulario, listas de bloqueo, archivos expuestos, encabezados, versiones) (domains). Pulso por página de formulario (form_pulse). Vulnerabilidades a partir de versiones de plugins (vuln_hits). Inventario de scripts con dirección, hash, tamaño, aprobación con persona que aprueba y motivo (script_inventory, script_changes). Verificaciones como en A.4. Para los archivos expuestos, se almacenan ruta, gravedad y tipo, nunca el contenido.
Solicitudes a tercerosConsultas DNS (SPF, DMARC, MX, registro de prueba). Consulta a registros mediante RDAP según el directorio de 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 de correo y el nombre de dominio, sin datos 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; nosotros mismos realizamos la comparación con la versión instalada del plugin. Páginas de estado de Cloudflare, hCaptcha, Google Cloud, SendGrid, Mailgun y Brevo: no se transmite nada excepto la propia solicitud.
FuenteCliente; solicitudes a la página del Cliente; directorios públicos.
Base jurídicaArt. 6, apartado 1, letra b), del RGPD.
DestinatariosLos servicios mencionados no reciben datos personales de nuestros Clientes, en la medida en que los nombres de dominio y las direcciones de servidores de una empresa no sean datos personales; para empresarios individuales, el nombre de dominio puede ser un dato personal. Los miembros del espacio de trabajo ven el dominio.
Tercer paísLas solicitudes pueden llegar a servicios en terceros países (como consultas a registros, listas de bloqueo). Solo se transmite lo indicado en la fila «Solicitudes a terceros».
ConservaciónHasta que se elimina el dominio. fe_domain_loeschen() elimina entonces de inmediato resultados de verificaciones, formularios, hallazgos, imágenes, informes, trabajos, destinos y registro de alertas, incidentes, códigos de Telegram, entregas, pulso, vulnerabilidades y pruebas; mediante claves foráneas, formularios monitoreados, ejecuciones con navegador, cuenta de prueba y contadores de formularios; los datos del plugin del host si ningún otro dominio se refiere a él. También se eliminan el inventario de scripts del dominio y sus cambios de scripts; no tienen un plazo de conservación propio (sección 6.4). Resultados de verificaciones, como máximo 13 meses; permanece el último.
Medidas técnicas y organizativasSección 8. Vigilancias de archivos expuestos y versiones solo para dominios verificados, como máximo una solicitud por ruta, solo los primeros 8 KB; probar rutas de terceros sin que lo hayan solicitado sería una herramienta de ataque.

B.16 Alertas, incidentes y escalamiento hacia el titular de la cuenta

CampoEntrada
FinalidadInformar al Cliente sobre fallas y cambios, observar ventanas de mantenimiento, confirmar la recepción de incidentes y escalarlos. Cuando los destinos son terceros, actuamos por cuenta del Cliente (A.3); cuando se trata del propio titular de la cuenta, se establece aquí.
Categorías de interesadosTitulares de cuentas y miembros de equipos como destinatarios.
Categorías de datos personalesComo en A.3. Las notificaciones aparecen en el idioma del titular de la cuenta.
Base jurídicaArt. 6, apartado 1, letra b), del RGPD.
DestinatariosProveedor de servicios de correo; servicios de chat elegidos (4.1).
Tercer paísSegún el canal (4.1).
ConservaciónComo en A.3: registro de entrega, 90 días; notificaciones de resumen, 30 días después de la entrega; incidentes, hasta su resolución y después 180 días. Destinos de alertas con el dominio.
Medidas técnicas y organizativasSección 8.

B.17 Informe mensual a cuentas

CampoEntrada
FinalidadEl día 1 de cada mes a partir de las 08:00 (recuperación de envíos pendientes hasta el día 3), un correo electrónico por cuenta que abarca todos sus dominios: nivel, puntuación y cambio, alertas, bots bloqueados, envío de correo, valor comparativo.
Categorías de interesadosTitulares de cuentas activas con el informe mensual activado.
Categorías de datos personalesDirección de correo electrónico, idioma, cifras principales de los dominios.
Base jurídicaArt. 6, apartado 1, letra b), del RGPD (parte del servicio). Puede darse de baja en la configuración; puede desactivarse de forma centralizada.
DestinatariosProveedor de servicios de correo (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA).
Tercer paísMediante el proveedor de servicios de correo.
ConservaciónSin almacenamiento separado; el correo electrónico permanece en la bandeja de salida durante 30 días (B.25).
Medidas técnicas y organizativasSección 8.

B.18 Insignia y página pública de confirmación

CampoEntrada
FinalidadUn Cliente puede incorporar la imagen de una insignia en su sitio web y enlazarla a una página pública de confirmación. La insignia muestra «Protegido» solo si el dominio está verificado, el monitoreo está activo y la última verificación completada tiene como máximo 45 días de antigüedad y dio como resultado «Protegido» o «Parcialmente protegido»; en caso contrario, muestra de forma neutral «Verificación del formulario de contacto». La página de confirmación indica el nivel y la fecha, ningún hallazgo individual.
Categorías de interesadosVisitantes del sitio web del Cliente cuyo navegador carga la imagen; visitantes de la página de confirmación.
Categorías de datos personalesAl 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 ni escribe en el registro de visitas a páginas. La página de confirmación es una página normal (B.2, B.3).
Base jurídicaArt. 6, apartado 1, letra f), del RGPD. Interés: entregar la imagen y mantener una operación segura. Si el Cliente y nosotros somos corresponsables del tratamiento para la transmisión de la dirección IP del visitante, en el sentido de la jurisprudencia sobre contenido de terceros incorporado, y si se requiere un acuerdo conforme al art. 26, es una cuestión pendiente para la revisión jurídica. El Cliente recibe un texto sugerido para su política de privacidad.
DestinatariosNinguno.
Tercer paísNinguno.
Conservación14 días (registro del servidor web). La imagen se almacena en caché durante una hora. Cuando se desactiva la insignia, el identificador deja de ser válido.
Medidas técnicas y organizativasSección 8.

B.19 Registro de evidencias y sello de tiempo

CampoEntrada
FinalidadUn registro por dominio y mes (planes de pago): qué se verificó, con qué resultado, qué se notificó y qué cambió, como prueba para la responsabilidad proactiva, aseguradoras o auditorías de proveedores. Cada versión recibe un número de verificación; una página pública confirma dominio, periodo y cifras principales, 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 interesadosClientes; indirectamente, personas que puedan figurar en el registro como quienes aprueban o confirman la recepción.
Categorías de datos personalesDominio, mes, número de verificación, hash del contenido (SHA-512), resumen y datos del registro, respuesta de sellado de tiempo, autoridad de sellado de tiempo y hora, intentos fallidos (proof_docs).
Base jurídicaArt. 6, apartado 1, letra b), del RGPD.
DestinatariosLa autoridad de sellado de tiempo (predeterminada Certum, alternativa DigiCert) recibe solo el hash del registro, no su contenido. Público: cifras principales mediante 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ísSin transferencia de datos personales: un hash no permite inferir el contenido. La autoridad alternativa tiene su sede en EE. UU.
ConservaciónHasta que se elimina el dominio (fe_domain_loeschen()). El sello de tiempo no es un sello de tiempo cualificado conforme a eIDAS.
Medidas técnicas y organizativasSección 8.

B.20 Plugin y extensión: verificación, conexión y transmisión

CampoEntrada
FinalidadEl plugin de WordPress y la extensión de TYPO3 pueden solicitar una verificación (incluso sin cuenta), conectarse a una cuenta (la instalación cuenta como prueba de control con un clic en la cuenta), activar funciones de protección, comunicar cifras diariamente (A.9) y comunicar de inmediato errores de correo y el modo de mantenimiento.
Categorías de interesadosClientes; operadores de sitios web que utilizan el plugin sin cuenta.
Categorías de datos personalesPor host: versión del plugin y del CMS, número de verificaciones, 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 vencimiento (plugin_connect_tokens). Códigos de conexión masiva de una agencia como hash con prefijo, etiqueta, usos, persona que los crea (workspace_connect_codes). Registro de solicitudes con la dirección IP del servidor que llama (B.4). La clave del plugin es visible públicamente en el encabezado del sitio web; es un hash del secreto, y el propio secreto solo se almacena como hash y nunca se devuelve.
Base jurídicaArt. 6, apartado 1, letra b), del RGPD (cuenta); sin cuenta, letra f) (verificación solicitada, prevención del abuso).
DestinatariosNinguno.
Tercer paísNinguno.
ConservaciónLos datos de un host se eliminan en cuanto ningún dominio se refiere ya a él; la fila de un plugin sin cuenta, solo después de 90 días sin contacto (ejecución nocturna de eliminación, parte «orphan_hosts»). Códigos de un solo uso, un día después del vencimiento. Códigos de conexión masiva con el espacio de trabajo.
Medidas técnicas y organizativasSecció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 anteriores no vinculados se eliminaron.

B.21 Protección colectiva

CampoEntrada
FinalidadDefensa compartida contra el spam: los sitios web conectados comunican los dominios de enlaces de mensajes que su capa de protección ha detenido. Un dominio que aparece en al menos tres sitios web con al menos cinco coincidencias dentro de siete días se incorpora a una lista que se devuelve a todos los sitios web conectados; su capa de protección mueve los mensajes con dichos enlaces a la cuarentena, nunca los hace desaparecer.
Categorías de interesadosTitulares de los dominios de enlaces comunicados, cuando son personas físicas (como el operador de un sitio de spam bajo su propio nombre). No los remitentes ni los destinatarios de los mensajes: no se comunican direcciones, textos ni nombres.
Categorías de datos personalesSeñales: tipo, dominio, host que comunica, día, coincidencias (swarm_signals). Lista: tipo, dominio, número de sitios web y coincidencias, horas (swarm_list). Los grandes servicios, los dominios de nuestros Clientes y las excepciones establecidas por el operador nunca se incluyen en la lista.
Redes IPSe ha preparado el intercambio de redes IP (/24, /48). Está desactivado y el plugin no comunica ninguna; solo se activará después de una revisión jurídica, porque las direcciones IP son datos personales.
Base jurídicaArt. 6, apartado 1, letra f), del RGPD. Interés: proteger los formularios de todos los Clientes contra oleadas de spam. Ponderación: solo dominios, umbrales mínimos contra la manipulación de la lista, sin pérdida de mensajes, eliminación posible en cualquier momento.
DestinatariosTodos los sitios web conectados (la lista de dominios).
Tercer paísSegún la ubicación de los sitios web conectados; la lista también puede llegar a sitios web fuera del EEE. Solo constituye datos personales en casos límite (dominios de personas físicas). Aún debe determinarse la base de transferencia del capítulo V del RGPD para estos casos (cuestión pendiente para la revisión jurídica).
ConservaciónSeñales, 30 días (ejecución diaria de protección colectiva a partir de las 04:00, cfg/swarm_lib.php). La lista se recalcula diariamente; lo que deja de alcanzar el umbral sale de ella.
Medidas técnicas y organizativasSección 8.

B.22 Claves de API, interfaz de programación y servidor MCP

CampoEntrada
FinalidadAcceso de las propias herramientas del Cliente (API REST, Zapier, Make, servidor MCP para asistentes de IA) a los dominios, verificaciones e incidentes del Cliente.
Categorías de interesadosClientes que crean claves.
Categorías de datos personalesClave solo como hash, prefijo, etiqueta, horas de creación, último uso y revocación (api_keys). Llamadas por minuto (api_usage).
Base jurídicaArt. 6, apartado 1, letra b), del RGPD.
DestinatariosLa herramienta a la que el Cliente proporciona la clave; el Cliente la determina.
Tercer paísSegún la herramienta del Cliente.
ConservaciónClaves hasta su revocación, de inmediato con la cuenta; claves sin cuenta (datos antiguos), cada noche. Contadores de llamadas después de un día (se limpian ocasionalmente al realizar una llamada).
Medidas técnicas y organizativasSección 8.

B.23 reCAPTCHA y nuestra propia protección de formularios

CampoEntrada
FinalidadDefensa contra el acceso automatizado a nuestros propios formularios: verificación gratuita, herramienta de encabezados, exclusión, 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), verificació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 verificación gratuita, el registro, el inicio de sesión y “contraseña olvidada”.
Categorías de interesadosPersonas que envían estos formularios.
Categorías de datos personalesEn Google: dirección IP, datos del navegador y dispositivo, datos de comportamiento, cookies de Google. Con nosotros: la evaluación de Google (puntuación y acción) solo en el momento de la verificació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 llenado sí/no; ningún contenido.
MomentoEl script de Google se carga solo cuando se envía un formulario protegido, no cuando se abre 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 usa el formulario. En el sistema de desarrollo, reCAPTCHA está desactivado.
Base jurídicaArt. 6, apartado 1, letra f), del RGPD. Interés: protección contra bots, especialmente para la verificación gratuita, que de otro modo podría utilizarse contra sitios web de terceros. Si el acceso al dispositivo terminal requiere consentimiento conforme al § 25 de la TDDDG o al art. 399 de la PKE, aunque el script solo se cargue al enviar, es una cuestión pendiente para la revisión jurídica. Nuestra propia protección de formularios no coloca cookies, no almacena nada en el navegador y no genera ninguna huella digital; su propósito es sustituir a reCAPTCHA de forma permanente.
DestinatariosGoogle Ireland Limited; Google LLC. En nuestra propia protección de formularios, ninguno.
Tercer paísEE. UU. (solo reCAPTCHA). Base: certificación en el Marco de Privacidad de Datos UE-EE. UU. o cláusulas contractuales tipo; por documentar en detalle.
ConservaciónreCAPTCHA: sin almacenamiento con nosotros; en Google, según sus reglas. Nuestra propia protección de formularios: identificador convertido en hash, 1 hora; tokens de verificación usados, 11 minutos como máximo; resultados de verificación sin dirección IP, 30 días.
CaídaSi Google no responde dentro de tres segundos o responde de forma inutilizable, se rechaza el envío; también se rechazan un token vacío y una respuesta para una acción distinta de la del formulario. La verificación solo se omite cuando reCAPTCHA está desactivado. En nuestra propia protección de formularios, se rechaza un envío sin token de verificación válido; si el servicio no estaba disponible para la tarea, se permite.
Medidas técnicas y organizativasSección 8.

B.24 Soporte y formulario de contacto

CampoEntrada
FinalidadRecibir y responder consultas mediante la ventana de soporte y la página de contacto. Ambos utilizan la misma ruta y la misma tabla.
Categorías de interesadosPersonas que consultan, con sesión iniciada o sin ella.
Categorías de datos personalesCuenta (si hay sesión iniciada; entonces se aplica la dirección de la cuenta, no la ingresada), dirección de correo electrónico, motivo de una lista fija, texto de hasta 4,000 caracteres, estado, dirección IP completa, país, identificador del navegador, página de referencia (solo rutas propias), idioma, horas de recepción y respuesta (support_requests); entrada en el registro de auditoría (sin texto); acuse de recibo a la persona que consulta en la bandeja de salida (B.25), con el texto hasta 2,000 caracteres solo para remitentes con sesión iniciada, sin el texto para solicitudes realizadas sin iniciar sesión.
Base jurídicaArt. 6, apartado 1, letra b), del RGPD cuando la consulta se refiere a un contrato; en los demás casos, letra f). Dirección IP completa: letra f) (límite de tres consultas por hora y dirección, prevención del abuso).
DestinatariosProveedor 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ísMediante el proveedor de servicios de correo.
Conservación24 meses (ejecución nocturna de eliminación, parte «support»); manualmente antes. Cuando se elimina una cuenta, las consultas permanecen hasta el final del plazo de conservación (sección 6.4).
Medidas técnicas y organizativasSección 8. reCAPTCHA, nuestra propia protección de formularios, limitación de frecuencia.

B.25 Envío de correo electrónico (bandeja de salida)

CampoEntrada
FinalidadCorreos 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 del soporte, recordatorios del periodo de prueba y la configuración, notificaciones operativas a los operadores. Sin publicidad, sin correos a personas que no se hayan inscrito por sí mismas o no hayan sido ingresadas como destinatarias por el Cliente.
Categorías de interesadosDestinatarios de estos correos electrónicos.
Categorías de datos personalesDirección del destinatario, asunto, contenido completo, dirección de respuesta, finalidad, ruta de envío, estado, error, intentos, horas (mail_outbox). El contenido puede incluir enlaces de confirmación y restablecimiento con identificadores válidos.
Base jurídicaArt. 6, apartado 1, letra b), del RGPD; para notificaciones operativas, letra f).
DestinatariosNamecheap, Inc. (Private Email), Phoenix, Arizona, USA (envío); el titular de la cuenta ve sus correos enviados en la exportación de datos (sin contenido).
Tercer paísSegún el lugar de tratamiento del proveedor de servicios de correo; el contrato y la base de la transferencia aún deben documentarse (sección 4).
Conservación30 días (cada noche, srv/cron_status.php). Este plazo es deliberadamente el más corto de los registros: un registro de envío prolongado sería una colección de claves válidas. La tarea de estado comprueba cada cinco minutos si corresponde un nuevo intento.
EstadoEl envío de correo electrónico debe configurarse antes del lanzamiento. Hasta que se hayan definido el proveedor de servicios de correo, su sede y su base, los textos legales muestran un marcador.
Medidas técnicas y organizativasSección 8. Los correos fallidos se reintentan a intervalos crecientes y se abandonan después de un número máximo de intentos.

B.26 Pagos y facturación

CampoEntrada
FinalidadCelebrar y gestionar suscripciones (mensuales o anuales por anticipado), periodo de prueba de 14 días sin tarjeta con recordatorio tres días antes del final, pago contra factura para suscripciones anuales (desactivado de forma predeterminada), activaciones mediante códigos de proveedores de alojamiento y socios sin pago, facturación, conservación por motivos fiscales.
Categorías de interesadosClientes.
Categorías de datos personalesEn Stripe: dirección de correo electrónico, nombre, dirección de facturación, número de IVA, datos de pago, facturas; como metadatos, nuestro ID de cuenta y el plan. Con nosotros: ID de cliente y suscripción de Stripe, plan, estado, final del periodo, cancelación al final del periodo (users); eventos de Stripe recibidos solo con identificador, tipo, estado y horas, sin contenido (stripe_events); canjes de códigos de proveedores de alojamiento con cuenta, campaña y vencimiento (bundle_redemptions). Los datos de tarjetas nunca nos llegan.
FuenteEl Cliente en el proceso de pago de Stripe; eventos de Stripe.
Base jurídicaArt. 6, apartado 1, letra b), del RGPD; para la conservación por motivos fiscales, letra c).
DestinatariosStripe Payments Europe Limited (Ireland); Stripe, Inc. (USA). Para partes del procesamiento de pagos, Stripe actúa bajo su propia responsabilidad; la distribución precisa de roles forma parte de la revisión jurídica.
Tercer paísEE. UU. mediante Stripe, Inc.; base: Marco de Privacidad de Datos o cláusulas contractuales tipo conforme a las condiciones de Stripe.
ConservaciónCampos de facturación con la cuenta; una suscripción en curso se termina antes de eliminar la cuenta. Facturas y registros de facturación conforme a la legislación fiscal polaca durante cinco años desde el final del año en que venció el plazo de pago del impuesto; se conservan en Stripe y pueden recuperarse 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).
Medidas técnicas y organizativasSección 8. Los eventos de Stripe solo se aceptan con una firma válida; cada evento se procesa una vez.

B.27 Copias de seguridad

CampoEntrada
FinalidadRecuperación después de un error: eliminación indebida, migración dañada.
Categorías de interesadosToda persona cuyos datos estén en la base de datos.
Categorías de datos personalesVolcado completo y comprimido de la base de datos de la aplicación. Las capturas de pantalla y los archivos de logotipo se conservan fuera de la base de datos y no forman parte de esta copia de seguridad. Las credenciales de cuentas de prueba solo están contenidas en ella como texto cifrado (A.5).
ProcedimientoCada noche a las 03:00, después de la ejecución de eliminación, para que la copia de seguridad no incluya lo que acaban de eliminar los plazos de conservación. 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 copia más reciente en una base de datos desechable y la compara tabla por tabla. Si algo falla, se envían una señal y un correo electrónico a los operadores.
Base jurídicaArt. 6, apartado 1, letra f), del RGPD en relación con el art. 32, apartado 1, letra c).
DestinatariosNinguno.
Tercer paísNinguno.
Conservación14 días; los volcados anteriores solo se eliminan después de una nueva copia de seguridad correcta (cfg/backup_lib.php). Las supresiones que tienen lugar durante este tiempo solo llegan a la copia de seguridad cuando esta vence; si se restauran datos de una copia de seguridad, las solicitudes de supresión se aplican de nuevo después.
UbicaciónActualmente, las copias de seguridad se conservan en la misma ubicación que la base de datos y no están cifradas por separado; se prevé una copia cifrada en una segunda ubicación (secciones 8.1 y 10).
Medidas técnicas y organizativasSección 8.

B.28 Registro de errores y alerta de error

CampoEntrada
FinalidadEncontrar y corregir errores antes de que un Cliente los notifique. Los nuevos tipos de errores 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 interesadosUsuarios cuya solicitud causa un error; indirectamente, personas cuyos datos aparecen en un mensaje de error.
Categorías de datos personalesNivel, origen, mensaje, contexto como JSON, ID de cuenta de la sesión, hora (error_logs). Tipos de errores: huella, patrón (del que se han eliminado direcciones de correo electrónico, direcciones, números e identificadores), un mensaje de ejemplo sin alterar de hasta 2,000 caracteres, primera y última aparición, recuento (error_kinds).
Base jurídicaArt. 6, apartado 1, letra f), del RGPD (seguridad operativa, art. 32).
DestinatariosLos operadores por correo electrónico mediante el proveedor de servicios de correo: para un nuevo tipo de error, origen y texto sin procesar del mensaje hasta 400 caracteres (sin limpiar), además del correo de resumen diario; para una 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ísMediante el proveedor de servicios de correo.
ConservaciónRegistro de errores, 90 días (cada noche). Tipos de errores sin plazo de conservación (sección 10). La alerta de error está activada en el sistema de producción y desactivada en el de desarrollo.
Medidas técnicas y organizativasSección 8.

B.29 Señales operativas y monitoreo de estado

CampoEntrada
FinalidadDetectar caídas: cada cinco minutos, una comprobación de los componentes (página de inicio, base de datos, espacio en disco, señal de actividad del escáner, acumulación en la cola), página de estado, señal ante una falla y ante el restablecimiento, señal de actividad a un servicio externo de monitoreo para que se detecte incluso una caída completa; acumulación de trabajos antes del escáner.
Categorías de interesadosPor regla general, ninguno.
Categorías de datos personalesNinguno. Filas diarias por componente con el número de comprobaciones y el último error (system_status_logs), señal de actividad del escáner (scanner_heartbeat), cifras principales diarias sin referencia personal (daily_stats). Las señales a Telegram son frases fijas sin variables; la señal de actividad es una solicitud sin contenido.
Base jurídicaNo aplica, ya que no hay datos personales; por precaución, art. 6, apartado 1, letra f).
DestinatariosTelegram (frases fijas); el servicio externo de monitoreo (solo la solicitud); los operadores por correo electrónico.
Tercer paísTelegram fuera de la UE; no se transmiten datos personales.
ConservaciónFilas de estado, 400 días (cada noche).
Medidas técnicas y organizativasSección 8.

B.30 Exclusión – excluir un dominio

CampoEntrada
FinalidadCualquier persona puede excluir permanentemente cualquier dominio de las verificaciones sin prueba; el bloqueo surte efecto de inmediato para todas las vías de verificación (verificación gratuita, plugin sin cuenta, estudio, verificación de clientes potenciales, herramienta de encabezados) y también para dominios de Clientes de pago con prueba de control; su monitoreo en curso termina con la siguiente verificación programada. Se aplica al dominio y a su variante con www, no a otros subdominios. Solo nosotros lo levantamos, previa solicitud y con prueba. Para que pueda detectarse y revertirse el abuso (como un competidor que bloquea dominios de otras personas), el bloqueo se registra.
Categorías de interesadosPersonas que excluyen un dominio.
Categorías de datos personalesDominio, 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ídicaPara la exclusión, art. 6, apartado 1, letra f), del RGPD. Interés: dar efecto, de forma permanente y en todas las vías de verificación, al deseo de que un dominio no se verifique. Cuando la propia persona que excluye es un interesado, la exclusión da efecto al mismo tiempo a su oposición conforme al art. 21 (art. 6, apartado 1, letra c)). Para dirección, país e identificador del navegador, letra f) (detección del abuso).
DestinatariosGoogle (reCAPTCHA, B.23).
Tercer paísEE. UU. mediante reCAPTCHA.
ConservaciónDirección IP, país e identificador del navegador después de 12 meses (ejecución nocturna de eliminación, parte «optout_ip»). La exclusión en sí permanece de forma permanente para que surta efecto.
Medidas técnicas y organizativasSección 8. Muchos bloqueos desde un país en poco tiempo generan una anomalía (B.4).

B.31 Recordatorio después del registro

CampoEntrada
FinalidadUn único correo electrónico de dos a 14 días después del registro a cuentas confirmadas sin un dominio confirmado: «Agregar sitio web» o «Confirmar dominio». Sin oferta, sin precio, sin cambio a un plan superior; con la indicación de que no se enviará de nuevo. Días de semana de 09:00 a 18:00, como máximo 50 por ejecución.
Categorías de interesadosNuevos titulares de cuentas.
Categorías de datos personalesDirección de correo electrónico, idioma, hora de envío (campo «recordatorio enviado» en users), dominio y estado de confirmación.
Base jurídicaArt. 6, apartado 1, letra b), del RGPD (indicación para configurar la propia cuenta). Si el correo cuenta como comunicación sobre la relación contractual o como información comercial que requeriría consentimiento (art. 10 de la UŚUDE, Ley polaca sobre la Prestación de Servicios por Medios Electrónicos (ustawa o świadczeniu usług drogą elektroniczną); art. 398 de la PKE; § 7 de la UWG) es una cuestión pendiente para la revisión jurídica; el operador puede desactivarlo de forma centralizada.
DestinatariosProveedor de servicios de correo (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA).
Tercer paísMediante el proveedor de servicios de correo.
ConservaciónLa hora permanece mientras exista la cuenta; el correo electrónico, 30 días en la bandeja de salida.
Medidas técnicas y organizativasSección 8. La hora se establece antes del envío para que una interrupción no genere un segundo correo.

B.32 Bot de Telegram para alertas del Cliente

CampoEntrada
FinalidadSe vincula un chat de Telegram como destino de alertas: el Cliente recibe un enlace a nuestro bot con un código de un solo uso; cuando el destinatario pulsa «Iniciar», nuestro servidor lee el código de los nuevos mensajes al bot y almacena el ID del chat. Para ello no se necesita ningún punto de acceso abierto de nuestro lado (webhook).
Categorías de interesadosClientes y personas cuyo chat de Telegram se vincula.
Categorías de datos personalesCódigo de un solo uso, dominio, cuenta que lo crea, eventos, modo de entrega, ID del chat, horas (telegram_links); el ID del chat como destino (alerts). Telegram proporciona otros datos del perfil con el mensaje; solo se evalúan y almacenan el código y el ID del chat.
Base jurídicaArt. 6, apartado 1, letra b), del RGPD; para terceros como destinatarios, A.3.
DestinatariosTelegram.
Tercer paísFuera de la UE, sin decisión de adecuación; la elección la hace el Cliente (4.1). La base y el aviso son cuestiones pendientes para la revisión jurídica.
ConservaciónUn código es válido durante 30 minutos; las filas de vinculación se eliminan después de un día cuando se crea un nuevo código; los códigos pendientes, con la cuenta y el dominio. El ID del chat como destino, hasta que se elimina el destino de alertas o el dominio.
Medidas técnicas y organizativasSección 8.

B.33 Programa de socios y códigos de activación

CampoEntrada
FinalidadUna cuenta puede referir 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 se transmite en la dirección hasta el registro; no se instala ninguna cookie. Los proveedores de alojamiento y socios pueden emitir códigos que activan un plan durante un periodo sin pago; una semana antes del final, el Cliente recibe un recordatorio.
EstadoEl programa de socios está desactivado de forma predeterminada hasta que estén establecidas las Condiciones para Socios.
Categorías de interesadosSocios y Clientes referidos.
Categorías de datos personalesCódigo de recomendación, socio que refiere y hora de la referencia (en users); comisión con socio, Cliente, ID de factura de Stripe, importe, moneda, comisión, estado, horas (partner_commissions). Activación con plan, final, origen, recordatorio (en users); campañas y canjes (bundle_campaigns, bundle_redemptions).
Base jurídicaArt. 6, apartado 1, letra b), del RGPD (acuerdo de socios); para el Cliente, 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, letra c).
DestinatariosEl socio ve sus comisiones.
Tercer paísNinguno.
ConservaciónReferencia y activación con la cuenta. Las comisiones y los canjes no tienen plazo de conservación en el código; como registros contables, las comisiones están sujetas a conservación por motivos fiscales (sección 6.4).
Medidas técnicas y organizativasSección 8.

B.34 Punto de notificación de vulnerabilidades

CampoEntrada
FinalidadRecibir notificaciones de vulnerabilidades de formexposed, conforme a las reglas de la página Seguridad y de /.well-known/security.txt.
Categorías de interesadosPersonas notificantes; personas cuyos datos contiene una notificación como prueba.
Categorías de datos personalesDirección de correo electrónico, nombre, contenido de la notificación y archivos adjuntos, tal como los envía la persona notificante. La notificación nos llega por correo electrónico a la dirección indicada allí; la aplicación no la almacena.
Base jurídicaArt. 6, apartado 1, letra f), del RGPD (seguridad del servicio, art. 32); cuando una notificación contiene datos personales de terceros como prueba, igualmente letra f), con el objetivo de subsanar la vulnerabilidad.
DestinatariosProveedor de servicios de correo y, hasta que se configure el buzón, el reenvío del dominio en Namecheap (sección 4).
Tercer paísMediante el proveedor de servicios de correo y, hasta el cambio, el reenvío.
ConservaciónNo se ha establecido ningún plazo de conservación ni se aplica técnicamente (sección 10). El operador aún debe establecer el plazo; un enfoque evidente sería eliminar las pruebas de terceros una vez subsanada la vulnerabilidad y tratar la correspondencia como consultas de soporte.
Medidas técnicas y organizativasSección 8.

B.35 Comentarios sobre un informe

CampoEntrada
FinalidadRecibir 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 verificació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 interesadosPersonas que ven un informe, con sesión iniciada o sin ella.
Categorías de datos personalesCategoría y verificación de listas fijas, dirección de página de hasta 500 caracteres, texto de hasta 1,000 caracteres, idioma, hora, identificador del informe, verificación, host; identificador de cuenta si hay sesión iniciada; HMAC-SHA256 de la dirección IP con una clave secreta para el límite; estado, persona encargada, hora de atención (report_feedback). Registro de auditoría: cambios de estado y descargas de un caso de prueba. Sin dirección de correo electrónico ni dirección IP en texto claro.
Base jurídicaArt. 6, apartado 1, letra f), del RGPD (encontrar y corregir errores de detección; límite contra el abuso).
DestinatariosNinguno.
Tercer paísNinguno.
Conservación24 meses (ejecución nocturna de eliminación, parte «report_feedback»); la suma de comprobación de la dirección IP se borra después de 2 días (parte «report_feedback_ip»); de inmediato cuando se elimina una cuenta. Los casos de prueba descargados no contienen datos sobre la persona que informa.
Medidas técnicas y organizativasSección 8. Protección propia de formularios (trampa, tiempo firmado, CSRF), como máximo 5 notificaciones por hora y 20 por día por suma de comprobación, 10 por informe; solo legible por superadministradores.

6. Conservación – qué abarca la ejecución nocturna de eliminación y qué no

Existe una eliminación automática y tiene un lugar. Una tarea de estado (srv/cron_status.php) se inicia cada cinco minutos mediante el crontab del servidor web, tanto en el sistema de producción como en el de desarrollo. Comprueba los componentes, recupera el correo de la verificación de entrega, programa verificaciones y envía alertas. Una vez al día, en la ventana de 03:00 a 03:04, elimina conforme a los plazos de conservación y después crea la copia de seguridad. Desde el 27 de septiembre de 2026, también llama a la ejecución de conservación de cfg/fristen_lib.php (fe_fristen_lauf()), cuyas partes se ejecutan independientemente entre sí: si una falla, las demás continúan y el error se registra en el registro de errores.

Prueba de que la ejecución funciona: 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 se crea en el mismo bloque inmediatamente después de la eliminación. La ejecución escribe un registro por tabla eliminada solo 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 se configuran en el área de administración, en los ajustes de conservación. La ejecución lee la misma configuración; por tanto, los textos siempre muestran el plazo después del cual se eliminan efectivamente los datos.

6.1 Cubierto por la ejecución diaria

DatosPlazo de conservación y desencadenanteLugar en el código
Registro de visitas a páginas (access_logs)60 díassrv/cron_status.php
Registro de auditoría (audit_logs)365 díassrv/cron_status.php
Registro de errores (error_logs)90 díassrv/cron_status.php
Bandeja de salida (mail_outbox)30 díassrv/cron_status.php
Tokens de recordar sesión de «Mantener mi sesión iniciada» (remember_tokens)después del vencimiento (30 días)srv/cron_status.php
Invitaciones no aceptadas (workspace_invites)después del vencimiento (14 días)srv/cron_status.php
Intentos de inicio de sesión (login_attempts); contadores de intentos (auth_attempt_buckets)7 días; contadores al vencer su ventana temporal (actualmente 15 minutos, una hora para restablecimiento de contraseña y registro), también en el siguiente accesosrv/cron_status.php
Registro de solicitudes de verificaciones sin cuenta (check_throttle)7 díassrv/cron_status.php
Códigos de un solo uso para conectar el plugin (plugin_connect_tokens)1 día después del vencimientosrv/cron_status.php
Anomalías resueltas (abuse_flags)90 días después de la resoluciónsrv/cron_status.php
Informes vencidos junto con resultado de la verificación, formularios, hallazgos, imágenes y trabajo (solo sin un dominio en una cuenta)anónimos, 30 días; clientes potenciales, 90 díasfe_reports_aufraeumen()
Registro de entrega de alertas (alert_log)90 díasfe_alert_log_aufraeumen()
Filas de estado (system_status_logs)400 díassrv/cron_status.php
Registros de consentimiento de cuentas eliminadas (legal_consents)una vez eliminada la cuenta y cuando el consentimiento tenga 4 años de antigüedadsrv/cron_status.php
Datos huérfanos de dominios eliminados: resultados de verificaciones, trabajos, datos de alertas, incidentes, códigos de Telegram, entregas, pulso, vulnerabilidades, pruebas, inventario de scripts y cambios de scriptsde inmediato en la siguiente ejecuciónfe_fristen_lauf(), partes «orphan_scans», «orphan_rows»
Datos de plugins de hosts sin dominio; fila del plugin sin cuentade inmediato; fila después de 90 días sin contactoparte «orphan_hosts»
Resultados de la herramienta de encabezados (header_checks)actualmente 90 díasparte «header_checks»
Resultados de verificaciones de un dominio con formularios, hallazgos, imágenes, informes y trabajos13 meses; permanece el último completado por dominioparte «old_scans»
Ejecuciones con navegador, trabajos con navegador completados, series temporales (form_browser_runs, scan_jobs, form_performance)13 mesespartes «browser_runs», «browser_jobs», «form_performance»
Contadores de formularios (form_metrics), cifras diarias de plugins y notificaciones de cambios (plugin_stats, plugin_changes)13 mesespartes «form_metrics», «plugin_stats»
Dispositivos con sesión iniciada (login_sessions)90 días después del último uso o de la revocaciónparte «sessions»
Invitaciones aceptadas30 días después de la aceptaciónparte «invites»
Solicitudes de soporte (support_requests)24 mesesparte «support»
Comentarios sobre informes (report_feedback)24 meses; suma de comprobación de la dirección IP, 2 díaspartes «report_feedback» y «report_feedback_ip»
Versiones PDF de informes en la caché (var/pdf)7 díasparte «pdf_cache»
Dirección IP, país e identificador del navegador en la exclusión (blocklist)12 meses; la exclusión permaneceparte «optout_ip»
Suscriptores del portal (client_subscribers)no confirmados, 30 días; dados de baja, 3 añosparte «subscribers»
Cuentas nunca confirmadas, junto con el espacio de trabajo30 días sin inicio de sesión, salvo que haya otro miembro vinculadoparte «pending_accounts»
Claves de API sin cuenta (datos antiguos)de inmediatoparte «api_keys»

6.2 Fuera de la ventana de las 03:00

DatosPlazo de conservación y desencadenanteLugar en el código
Copias en el buzón de control de la verificación de entregadespués del procesamiento, cada cinco minutosfe_zustellung_abholen()
Asignaciones de la verificación de entrega (delivery_log)180 días, en cada recuperaciónfe_zustellung_abholen()
Texto cifrado de cuentas de prueba en trabajos (scan_jobs)después de la ejecución, a más tardar después de una horaservidor de escaneo; fe_login_aufraeumen()
Incidentes (alert_incidents) con sus intentos de entrega de escalamientosmientras no estén resueltos; 180 días después de la resoluciónfe_vorfaelle_aufraeumen() en cfg/vorfall_lib.php
Notificaciones de resumen enviadas (alert_queue)30 días después de la entregacfg/kanal_lib.php
Señales de protección colectiva (swarm_signals)30 días, diariamente a partir de las 04:00cfg/swarm_lib.php
Verificaciones de clientes potenciales (prospect_checks)90 días, diariamente a partir de las 04:00srv/cron_status.php
Códigos de vinculación de Telegram (telegram_links)1 día, cuando se crea un nuevo códigocfg/kanal_lib.php
Contadores de llamadas a la API (api_usage)1 día, ocasionalmente al realizar una llamadacfg/agentur_lib.php
Caídas de proveedores resueltas (provider_incidents), caché de vulnerabilidades (vuln_cache)90 y 30 días, respectivamente; sin datos personalescfg/anbieter_lib.php, cfg/luecken_lib.php
Datos sin procesar de estudiosal publicarfe_studie_veroeffentlichen()
Copias de seguridad14 días, después de una nueva copia de seguridad correctacfg/backup_lib.php
Registros del servidor web14 díasrotación de registros del sistema

6.3 Al eliminar por el Cliente

  • Eliminar un dominio (fe_domain_loeschen()): resultados de verificaciones con formularios, hallazgos y archivos de imágenes, informes, trabajos, destinos de alertas, registro de entrega, cola de resúmenes, incidentes, códigos de Telegram, entregas, pulso, vulnerabilidades, registros de evidencias, el dominio de los portales de clientes con selección fija; mediante claves foráneas, formularios monitoreados con ejecuciones con navegador, observaciones y series temporales, cuenta de prueba, contadores de formularios; datos del plugin del host si ningún otro dominio se refiere a él. El inventario de scripts del dominio y sus cambios de scripts también se eliminan con él; no tienen un plazo de conservación propio (secciones 6.4 y 10). Los datos restantes sin dominio asociado del periodo anterior al 27 de septiembre de 2026 se borran mediante la ejecución nocturna (partes «orphan_scans», «orphan_rows»).
  • Eliminar un espacio de trabajo (fe_arbeitsbereich_daten_loeschen()): además, marca incluido el logotipo, portales de clientes incluidos los suscriptores, códigos de conexión masiva, verificaciones de clientes potenciales; más invitaciones y membresías.
  • Eliminar una cuenta: terminar 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 recordar sesión, dispositivos, claves de API con contadores, códigos pendientes de Telegram y la fila de la cuenta.
  • Eliminar una cuenta de prueba (fe_login_loeschen()): sobrescribir el texto cifrado, eliminar la fila, borrar los trabajos en espera.

6.4 Lo que no abarca la ejecución

Esta lista es la más importante. Identifica datos para los que no existe un plazo de conservación automático o que sobreviven a una eliminación.

DatosQué se aplicaEvaluación
Datos de cuenta incluida la última dirección IP (users)hasta que los elimina el titular de la cuenta; sin eliminación de cuentas inactivasdatos contractuales; falta una regla para las cuentas permanentemente inactivas sin suscripción
Registro de auditoría, visitas a páginas, registro de errores de una cuenta eliminadapermanecen con el ID de cuenta y la dirección IP hasta el final de su plazo de conservacióndeliberado (prueba de acciones incluso después de la terminación); el ID ya no apunta a una cuenta
Solicitudes de soporte de una cuenta eliminadapermanecen durante hasta 24 meses con el antiguo ID de cuentadeliberado; el ID no se borra
Registros de consentimiento de una cuenta eliminadahasta que el consentimiento tenga 4 años de antigüedad (contados desde el consentimiento, no desde la eliminación de la cuenta)deliberado (sección B.12)
Anomalías no resueltas con dirección IP (abuse_flags)hasta que alguien las resuelvapunto pendiente (sección 10)
Tipos de errores con mensaje de ejemplo sin alterar (error_kinds)sin plazo de conservaciónpunto pendiente (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 élpunto pendiente (sección 10)
Suscriptores de portales de clientes revocadoshasta que se elimina el espacio de trabajopunto pendiente (sección 10)
Claves de API y códigos de conexión masiva revocadoshasta que se elimina la cuenta o el espacio de trabajosolo hashes, prefijo y etiqueta; menor
Lista de hosts de estudios (study_domains), estudios nunca publicadossin plazo de conservaciónpunto pendiente (sección 10)
Verificaciones internas sin dominio y sin informe (resultados de verificaciones, formularios, hallazgos, capturas de pantalla)sin plazo de conservación; ninguna vía de eliminación los abarcapunto pendiente (sección 10)
Comisiones, canjes de códigos, eventos de Stripesin plazo de conservaciónrelevancia contable; plazo por establecer conforme a la legislación fiscal
Antigüedad del dominio en caché (domain_age_cache)sin plazo de conservaciónsolo nombre de dominio y fecha de registro
Resultado de autenticación del correo del formulario con dominio del remitentecon el dominio; se sobrescribe en cada recepciónvéase A.1
Exclusionespermanentesdeliberado; sin permanencia, ninguna exclusión surte efecto
Correos electrónicos en el buzón del punto de notificación y en el buzón generalsin plazo técnico de conservaciónpunto pendiente (sección 10)

6.5 Fuera de la base de datos

  • Las capturas de pantalla se conservan como archivos fuera del directorio web y se eliminan con su resultado de verificación (todas las vías de eliminación anteriores también eliminan los archivos).
  • Los archivos de logotipo de marca se eliminan al sustituirse y con el espacio de trabajo.
  • En el servidor de escaneo se crea por trabajo un directorio temporal con resultado e imágenes; se elimina después de cada ejecución, incluso después de un error.
  • Las copias de seguridad se conservan 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. Según nuestra evaluación, el servicio no toma ninguna decisión que produzca efectos jurídicos sobre una persona o le afecte significativamente de modo similar (art. 22, apartado 1, del RGPD). Sin embargo, existen evaluaciones automatizadas y bloqueos automáticos. Los enumeramos para que pueda comprobarse la clasificación.

MecanismoQué haceA quién afecta
Puntuación y dictamen de una verificaciónSuma ponderada de capas de protección faltantes (CAPTCHA, trampa, token, verificación de tiempo, CAPTCHA ineficaz, configuración expuesta conocida), de 0 a 100; a partir de ella, «Expuesto», «Parcialmente protegido» o «Protegido». El dictamen del sitio web sigue al peor formulario de contacto reconocido como tal por las reglas (no por el modelo de lenguaje); sin formulario de contacto no hay dictamen. Las ponderaciones pueden configurarse en el área de administración.Operadores de sitios web; para empresarios individuales, indirectamente una persona. El dictamen no tiene consecuencias jurídicas; es un hallazgo con evidencias e instrucciones.
Clasificación del tipo de formularioPrimero 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 confiable por las reglas). Los formularios clasificados por el modelo de lenguaje nunca se envían y no cuentan para la puntuación ni el dictamen.El Cliente y los destinatarios de sus correos de formularios; efecto protector: en caso de duda, no se envía nada.
Plan de acción priorizado en informes de pagoUn modelo de lenguaje local resume hallazgos seleccionados fallidos o no concluyentes y metadatos del escaneo como pasos breves numerados. Su texto se identifica como resumen de IA; los hallazgos individuales siguen siendo la referencia vinculante. No modifica ninguna puntuación del escaneo, dictamen ni configuración del sitio web.El Cliente u otro lector autorizado del informe, que decide qué pasos tomar.
InsigniaMuestra «Protegido» solo bajo condiciones fijas (B.18); en los demás casos, neutral.Cliente; sin efecto sobre visitantes.
Límites y bloqueos de la verificación gratuita, herramienta de encabezados y exclusiónRechazan 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 está en la lista de bloqueo.Solicitantes; efecto: se rechaza un servicio gratuito durante horas o días. Un administrador puede liberar una dirección; las consultas mediante la página de contacto llegan a una persona.
AnomalíasLos patrones (muchos dominios desde una dirección, ráfagas de solicitudes, muchos rechazos, muchas exclusiones desde un país, límite diario alcanzado) se registran y comunican. No bloquean por sí mismos; los bloqueos resultan de los límites.Solicitantes.
Bloqueo de inicio de sesiónDespués de actualmente ocho inicios de sesión fallidos desde una dirección dentro de 15 minutos, se rechazan temporalmente los inicios de sesión desde esa dirección. 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 sumando todas las direcciones (considerablemente más, contra intentos distribuidos de adivinar contraseñas) y por dirección IP (actualmente 80) dentro de 15 minutos, al igual que los códigos de segundo factor (diez por cuenta dentro de 15 minutos); a partir de ahí, se rechazan los intentos. Por tanto, los intentos fallidos desde otra dirección ya no dejan al propietario sin acceso a su cuenta. Las confirmaciones de contraseña (cinco por cuenta dentro de 15 minutos), los correos de restablecimiento (tres por dirección por hora, con respuesta sin cambios), los registros (diez por dirección IP por hora) y los intentos de contraseña de un portal de clientes (diez por portal y dirección IP, 50 por portal dentro de 15 minutos) se limitan de la misma manera.Personas que inician sesión, se registran o abren un portal de clientes; efecto limitado en el tiempo, sigue siendo posible restablecer la contraseña.
Umbral de reCAPTCHARechaza envíos por debajo de una puntuación de Google; umbral por punto de uso (actualmente 0.7 para verificación y exclusión). También se rechazan las respuestas para otra acción y los envíos para los que Google no responde dentro de tres segundos.Personas que envían nuestros formularios; efecto: un nuevo intento o la vía de la página de contacto.
Protección colectivaIncluye automáticamente un dominio de enlaces en una lista cuando se alcanzan los umbrales mínimos; las capas de protección de los sitios web conectados mueven los mensajes con esos enlaces a la cuarentena.Remitentes de mensajes a páginas de Clientes. Efecto: el mensaje se retiene, no se elimina, y el operador del sitio web puede liberarlo. La decisión sobre el mensaje la toma el plugin del operador en el sitio web del operador, no nosotros.
Valores comparativos«Mejor protegido que el X % de los sitios verificados», solo a partir de totales de al menos 20 hosts.Operadores de sitios web; sin efecto.

Lo más cercano al art. 22 es la capa de protección del plugin en las páginas de Clientes, que retiene automáticamente los envíos. Es tratamiento del operador del sitio web en su servidor (A.10). No elimina nada, sino que mueve los mensajes a la cuarentena, y el operador puede liberar cualquier mensaje. No se elaboran perfiles de visitantes allí ni con nosotros; 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 es la descripción general conforme al art. 30, apartado 1, letra g), y apartado 2, letra d), del RGPD. La versión detallada está en la página Medidas Técnicas y Organizativas. Cada medida siguiente está respaldada por el código o la configuración. Las medidas aún no implementadas están en la misma sección (8.1), para que la descripción sea completa.

ÁreaMedida implementada
Cifrado de transporteHTTPS para sitio web, aplicación e interfaces; HSTS; cookies de sesión y de tokens de recordar sesión solo mediante 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 después de intentos fallidos repetidos y límites de intentos por cuenta y dirección IP juntas, por cuenta y por dirección IP, para que los intentos fallidos desde otra dirección no dejen al propietario sin acceso; límites de intentos también para confirmaciones de contraseña, restablecimiento de contraseña (con la misma respuesta y tiempo de respuesta), registros y contraseñas de portales; inicio de sesión de dos factores (TOTP) con secreto cifrado, protección contra 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 mi sesión iniciada» no está disponible para superadministradores, cada token solo es válido una vez; cambiar la dirección de correo electrónico invalida un enlace de restablecimiento pendiente; los dispositivos pueden revocarse individualmente o todos a la vez; la lista de dispositivos solo conserva el hash del identificador de sesión.
Control de acceso (autorización)Roles por espacio de trabajo (propietario, administrador, lector); los permisos se comprueban respecto del objeto, nunca respecto de un identificador del formulario; cuenta de prueba, «Fix it for me» y verificaciones activas solo para propietarios y administradores; «Ver como Cliente» limitado en el tiempo y bloqueado para acciones que modifican la cuenta, su finalización cierra completamente la sesión, regreso al área de administración solo con contraseña y segundo factor; invitaciones válidas solo mientras la persona que invita sea propietaria o administradora; direcciones de webhooks y canales de chat mostradas a lectores solo abreviadas al host; el nombre de host de un dominio verificado no puede cambiarse.
Seguridad de la aplicaciónTokens CSRF; sentencias preparadas de base de datos; protección propia de formularios (trampa, verificación de tiempo firmada); reCAPTCHA en formularios públicos; limitación de frecuencia para soporte, verificaciones e interfaces; solo una llamada a «Fix it for me» por espacio de trabajo a la vez, para que la cuota también se mantenga con solicitudes simultáneas; Política de Seguridad de Contenido con protección contra incorporación en marcos que solo permite ejecutar scripts que lleven la autorización (nonce) de la respuesta correspondiente; dirección IP de encabezados reenviados solo de nuestro propio proxy y solo de la entrada que este agregó; tokens de acceso enmascarados en el registro de visitas a páginas.
SecretosClaves de API, códigos de conexión masiva, secretos de conexión del plugin, códigos de un solo uso y contraseñas de portales solo como hash; credenciales de cuentas de prueba cifradas asimétricamente, clave privada solo en el servidor de escaneo; webhooks firmados; eventos de Stripe solo con firma válida.
Minimización de datosLa verificación de entrega no almacena contenido ni direcciones completas de remitentes; direcciones de destinatarios 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 de envío de correo solo como categoría; señales de Telegram sin variables; imágenes de verificaciones con navegador con datos ingresados enmascarados; sin capturas de pantalla detrás de un inicio de sesión.
Aislamiento del escánerCada verificación en su propio contenedor: todas las capacidades de Linux retiradas, sin elevación de privilegios, sistema de archivos de solo lectura, límite de memoria y 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 después de redirecciones; service workers bloqueados, conexiones WebSocket cerradas. Solicitudes del servidor web (prueba de control, herramienta de encabezados, búsqueda de archivos, pulso, RDAP, certificados, webhooks y alertas de chat) solo en los puertos web habituales y únicamente a la dirección exacta comprobada; webhooks y alertas de chat solo mediante HTTPS.
AlmacenamientoCapturas de pantalla fuera del directorio web, recuperables solo mediante el informe; informes en direcciones aleatorias con noindex; directorio de copias de seguridad legible solo por el servicio.
Disponibilidad y recuperaciónCopia de seguridad nocturna con comprobación de contenido, prueba semanal de restauración, alerta ante fallas; comprobación de componentes cada cinco minutos con señal y correo electrónico; señal externa de actividad; detención de emergencia para verificaciones anónimas; control de contrapresión cuando hay acumulación de trabajos.
TrazabilidadRegistro de auditoría para inicios de sesión, cambios, eliminaciones, acceso de soporte y aprobaciones; registro de errores con alerta.
SupresiónPlazos de conservación en un solo lugar del código, 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 interesadosExportació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 Cliente»; sistemas de desarrollo y producción separados, el sistema de desarrollo detrás de una barrera de acceso adicional; transferencia de textos legales después de su aprobación mediante una herramienta que rechaza borradores y marcadores.

8.1 Medidas aún no implementadas

  • Sin cifrado de la base de datos en reposo (medido el 11 de octubre de 2026). Las excepciones son las credenciales de cuentas de prueba y el secreto de dos factores, 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 cuentas de prueba solo circulan allí como texto cifrado.
  • Sin copia de seguridad en una segunda ubicación. Actualmente, las copias de seguridad se conservan en la misma ubicación que la base de datos y no están cifradas por separado; se prevé una copia cifrada en una segunda ubicación. Hasta entonces, protegen contra un comando de eliminación incorrecto, no contra la pérdida de la ubicación.
  • Refuerzo de la administración del servidor incompleto. La seguridad del acceso administrativo a nuestros servidores aún no cumple el nivel que pretendemos para la operación; el refuerzo continúa. No publicamos detalles porque ayudarían a un atacante; los proporcionamos a una autoridad de control previa solicitud.
  • Sin registro funcional de lectura en el área de administración. Las acciones de escritura se registran en el registro de auditoría; quién solo consultó qué solicitud de soporte o qué informe solo puede determinarse a partir del registro de visitas a páginas (60 días).
  • Sin registro permanente de eliminación. No se registra lo que ha eliminado la ejecución nocturna (sección 6).
  • Sin segundo punto de verificación independiente. La prueba en una segunda ubicación no está configurada (A.6).

9. Delegado de protección de datos – evaluación conforme al art. 37 del RGPD

Resultado: Según nuestra evaluación, no existe obligación de designarlo. La evaluación forma parte de la revisión jurídica y se repetirá en cuanto cambie cualquiera de las circunstancias enumeradas a continuación.

El art. 37, apartado 1, exige una designación en tres casos.

  • Letra a) (autoridad u organismo público): no aplica.
  • Letra b) (actividades principales que requieren observación habitual y sistemática de interesados a gran escala): nuestra actividad principal es la verificación habitual y sistemática de sitios web y formularios, no la observación de personas. No creamos perfiles de visitantes, no utilizamos seguimiento ni vinculamos un mensaje con otro. La verificación de entrega (A.1) hace pasar mensajes reales de visitantes por nuestro buzón, pero evalúa solo los encabezados y los primeros 8 KB para la asignación y no almacena contenido; observa rutas de entrega, no personas. Las cuentas de cliente y los registros son auxiliares de la actividad empresarial.
  • Letra c) (tratamiento a gran escala de categorías especiales conforme al art. 9 o de datos relativos a infracciones penales conforme al art. 10 como actividad principal): no se cumple. Pueden aparecer categorías especiales de forma incidental en copias de correos de formularios (A.1), en páginas detrás de un inicio de sesión (A.5) o en código pegado (A.7); la captación incidental no es una actividad principal.

El art. 37, apartado 4, permite que el derecho nacional agregue otros casos. Estamos solicitando a un abogado que confirme si el derecho polaco nos obliga a designarlo.

Desencadenantes de una nueva evaluación: activación de la protección colectiva con redes IP; una función que reconozca visitantes a través de varios mensajes o sitios web; almacenamiento de contenido de la verificación de entrega; un Cliente cuyos formularios se refieran predominantemente a categorías especiales (salud, solicitudes de empleo) con la verificación de entrega activada a gran escala; el primer empleado con acceso a datos de clientes. Sigue siendo posible una designación voluntaria; entonces se aplican íntegramente los arts. 37 a 39.

Por separado: la página Evaluación de Impacto relativa a la Protección de Datos responde si se requiere una evaluación de impacto conforme al art. 35 para actividades de tratamiento individuales. Su evaluación de umbral concluye que se requiere una evaluación de impacto para la protección colectiva (B.21) y para los estudios a la escala prevista (B.7), y que la realizamos nosotros, y que para la verificación de entrega (A.1) se requiere en la configuración típica, como obligación del Cliente, a quien apoyamos en ello.

10. Puntos pendientes y medidas previstas

Los siguientes puntos están respaldados por el código, el esquema o la configuración, no son supuestos. Describen la situación a la fecha de esta versión; la clasificación es nuestra propia evaluación y no anticipa ninguna valoración jurídica. Se ordenan por su importancia para los interesados, no por lo fácil que sea corregirlos. Las medidas previstas y su prioridad se establecen en la Evaluación de Impacto relativa a la Protección de Datos.

Punto pendienteQué está demostradoImportancia
Proveedor de servicios de correo sin contrato documentadoPara Namecheap, Inc. (Private Email), Phoenix, Arizona, USA, no están documentados el contrato, los lugares de tratamiento ni la base de la transferencia. Los correos de 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, apartados 2 y 4, y el capítulo V del RGPD. Se prevén la celebración y documentación antes del lanzamiento.
Bases para servicios de chat y reCAPTCHA pendientesAlertas a Telegram (sin decisión de adecuación), Slack, Discord, Microsoft Teams y Google Chat; reCAPTCHA sin solicitud de consentimiento.Cuestiones pendientes para la revisión jurídica; hasta entonces, el aviso y la base no son definitivos.
El buzón de control puede conservar mensajes durante interrupcionesLa eliminación se realiza después del procesamiento correcto; si la recuperación falla, las copias permanecen hasta la siguiente ejecución correcta. No existe ninguna advertencia cuando se acumulan mensajes en el buzón durante un periodo prolongado.Las copias contienen consultas reales de visitantes.
Sin copia de seguridad en una segunda ubicación ni cifrado de la base de datos en reposoSección 8.1. Se prevé una copia cifrada de la copia de seguridad en una segunda ubicación.Un único evento en la ubicación afectaría a los datos y a la copia de seguridad al mismo tiempo; un medio de almacenamiento robado sería legible.
Anomalías no resueltas sin plazo de conservaciónLas 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.Se relaciona con el principio de limitación del plazo de conservación (art. 5, apartado 1, letra e)); la eliminación depende de la resolución manual. Se prevé un plazo fijo de conservación (medidas de la Evaluación de Impacto relativa a la Protección de Datos).
Tipos de errores con mensaje de ejemplo sin plazo de conservaciónEl mensaje de ejemplo se almacena sin alterar hasta 2,000 caracteres; el patrón depurado elimina direcciones y números, el ejemplo 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 propioEl 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 la ejecución nocturna para datos huérfanos; no tienen plazo de conservación propio. Contienen direcciones de scripts, direcciones de páginas y, para las aprobaciones, la persona que aprueba y un motivo de texto libre.Se relaciona con el principio de limitación del plazo de conservación (art. 5, apartado 1, letra e)); el registro de cambios con las aprobaciones sigue creciendo mientras exista el dominio.
Suscriptores de portales revocadosUn portal revocado se bloquea, no se elimina; sus suscriptores permanecen hasta que se elimina el espacio de trabajo.La finalidad (enviar el informe) cesó con la revocación.
Listas de estudios sin plazo de conservaciónDespués de la publicación, los hosts y segmentos permanecen; los estudios nunca publicados también conservan sus datos sin procesar.La promesa «los datos sin procesar se eliminan» se aplica solo a estudios publicados.
Verificaciones internas sin vía de eliminaciónLas verificaciones con el nivel de confianza «interno» que no tienen ni dominio ni informe (estudios y verificaciones creadas 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.Se relaciona con el principio de limitación del plazo de conservación (art. 5, apartado 1, letra e)); afecta a personas que no saben nada de la verificación. Evaluado como riesgo alto en la Evaluación de Impacto relativa a la Protección de Datos.
La prueba de control no se renuevaLa prueba de control se comprueba una vez; no existe ninguna vía en el código mediante la cual un dominio vuelva a perderla.Los envíos de prueba activos, la búsqueda de archivos y el escaneo detrás del inicio de sesión continúan después de un cambio de propietario o de encargo.
Escaneo detrás del inicio de sesión: transporte a la página del ClienteComo 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 cuentas de prueba podrían interceptarse en el trayecto a la página del Cliente.
La eliminación depende de una ventana temporalEl bloque diario solo se ejecuta si una tarea de estado comienza entre las 03:00 y las 03:04. Si falla esa ejecución (base de datos inaccesible, servidor reiniciado), no se realizan la eliminación ni la copia de seguridad de ese día; no hay recuperación posterior. Lo eliminado no se registra permanentemente.Los plazos de conservación se prolongan entonces silenciosamente un día. Perder una ventana no genera ninguna alerta; solo se informa de 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 correcta.
Algunas eliminaciones dependen del monitoreoEl vaciado del buzón de control de la verificación de entrega, la eliminación de incidentes, notificaciones de resumen enviadas, señales de protección colectiva y verificaciones de clientes potenciales, y el borrado de copias restantes de cuentas de prueba en trabajos se ejecutan en la parte del programador de la tarea de estado, que solo funciona mientras el monitoreo esté activado en el área de administración; las asignaciones de la verificación de entrega solo se eliminan mientras haya un buzón de control configurado.Si el monitoreo se desactiva de forma centralizada o se elimina el buzón, estos plazos de conservación dejan de aplicarse sin que nadie lo note.
Punto de notificación y buzones sin plazo de conservaciónLas notificaciones de vulnerabilidades y otros correos entrantes se conservan fuera de la aplicación; no se ha establecido ningún plazo de conservación.Las notificaciones pueden contener pruebas de terceros.
Se leen valores de campos ocultos durante la verificaciónEl escáner lee el valor de campos ocultos de formularios hasta 24 caracteres y atributos de datos hasta 60 caracteres para reconocer marcas de tiempo y tokens. Solo el nombre de campo, el tipo, la etiqueta y el resultado del reconocimiento pasan al mapa de campos y a los hallazgos, no el valor.No existe una laguna en materia de almacenamiento; el valor solo se mantiene en la memoria de trabajo del contenedor de escaneo durante la verificación. Un valor rellenado previamente (como un número de cliente) se lee en el proceso, pero no se almacena.
Dominio del remitente derivado en el resultado de autenticaciónA.1.Para los dominios personales de visitantes, datos personales procedentes de un mensaje real.
Refuerzo de la administración del servidor incompleto; conexiones internas no cifradas en su totalidadSección 8.1. El refuerzo continúa; no indicamos detalles públicamente.Un incidente de seguridad a nivel de servidor afectaría a la aplicación, la base de datos y las copias de seguridad al mismo tiempo.
Medición en el sistema de desarrolloEl 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 se mantenga por escrito y se ponga a disposición de la autoridad de control previa solicitud. Esto requiere alguien responsable de él y un intervalo en el que se contraste con el sistema, no con su versión anterior.

  • Responsabilidad: Lukas Wójcik, propietario. Se revisa anualmente y cada vez que cambia una actividad de tratamiento.
  • Eventos que requieren una actualización: un subencargado nuevo o modificado, en particular la elección del proveedor de servicios de correo; una nueva tabla o un nuevo campo con datos personales; un cambio en los plazos de conservación o las cadenas de eliminación en cfg/fristen_lib.php o srv/cron_status.php; un nuevo canal de alerta o una nueva solicitud a un tercero; activar una función desactivada de forma predeterminada (protección colectiva con redes IP, prueba independiente, dominios propios, programa de socios, pago contra factura, Spamhaus o Google Web Risk); un traslado a otros servidores.
  • Procedimiento: cada afirmación de este documento proviene del código, el esquema o 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 siguen siendo marcadores, los puntos pendientes se cierran o se mantienen con motivos.
  • Relación con otros documentos: este registro no sustituye la Política de Privacidad, el Acuerdo de Tratamiento de Datos, las Medidas Técnicas y Organizativas ni la lista de Subencargados del Tratamiento. Cuando estos y el registro difieren, la diferencia es un hallazgo.
  • Los cambios en este documento se enumeran en la página Cambios en los Documentos Contractuales.