Política de Privacidad

Última actualización: 27 de mayo de 2026

Esta versión es una traducción. La versión inglesa (privacy.en.md) es la versión controlante. Esta versión española se pone a disposición de las personas usuarias hispanohablantes. En caso de discrepancia entre las versiones lingüísticas, prevalece la versión inglesa — salvo para las cuestiones reguladas exclusivamente por el derecho alemán de los telemedios, el derecho alemán de consumo o el derecho alemán de contratos, donde la formulación alemana es la auténtica.

1. Introducción

Este aviso describe cómo Uptimia («nosotros», «nos» o «nuestro»), operada por JJ Online GmbH, trata sus datos personales en relación con https://uptimia.com (el «Sitio web») y el servicio de monitorización Uptimia (el «Servicio»), conforme a los artículos 13 y 14 del RGPD y a la legislación de protección de datos equivalente. Se facilita a título informativo; cuando el tratamiento dependa de su consentimiento, dicho consentimiento se recaba por separado. En cuanto a los términos que rigen su relación contractual con nosotros, véanse nuestras Condiciones del Servicio.

Recopilación directa e indirecta (Art. 13 y Art. 14 RGPD). La mayor parte de los datos personales descritos en el § 3 nos los facilita usted directamente cuando crea una cuenta, configura monitores o utiliza de otro modo el Servicio. En los casos en los que un dato concreto se recopila de un tercero — en particular:

metadatos del método de pago devueltos por Stripe o PayPal en relación con su suscripción;
payloads de Instant Payment Notification (IPN) de PayPal recibidos de PayPal en relación con cada transacción, que pueden incluir campos de contexto transaccional (moneda de liquidación, estado del pagador, estado de confirmación de dirección) no facilitados originalmente por usted;
atributos de identidad devueltos por Google o GitHub a través de la página de inicio de sesión alojada por Auth0 cuando opte por iniciar sesión mediante una conexión social (y los tokens asociados emitidos por Auth0);
normalización de direcciones, resultados de validación de NIF-IVA y otros metadatos de generación de facturas devueltos por easybill en relación con la emisión de su factura (cuando easybill devuelve un campo — como una dirección postal normalizada o un indicador de validez del NIF-IVA del sistema VIES de la UE consultado a través de easybill — que no fue literalmente tecleado por usted, ese campo se recopila de forma indirecta);

— el tercero que es la fuente de ese dato se identifica en la entrada correspondiente del § 5 (Servicios de terceros) más adelante, en cumplimiento de nuestra obligación del Art. 14 (2)(f) RGPD de identificar la fuente. Fuera de esos flujos específicos, ningún dato personal que conservemos sobre usted como titular de cuenta proviene de un tercero.

2. Responsable del tratamiento

A los efectos del RGPD (Art. 4 (7)) y de la legislación de protección de datos equivalente, el Responsable del tratamiento de sus datos personales como titular de cuenta Uptimia es:

JJ Online GmbH (que opera Uptimia)

Schönhauser Allee 163, 10435 Berlín

Alemania

Registrada en: Amtsgericht Charlottenburg, HRB 235074 B

USt-IdNr.: DE351060880

Representada por: Andrius Gecius, Geschäftsführer (Director General)

Teléfono: +49 151 12032902

Correo — general / Aviso Legal: admin@uptimia.com

Correo — privacidad y solicitudes de los interesados: privacy@uptimia.com

La identificación completa del prestador exigida por el § 5 DDG figura en nuestro Aviso Legal (inglés) / Impressum (alemán).

Nota sobre los roles. Cuando usted utiliza Uptimia para monitorizar recursos que opera, usted actúa como Responsable del tratamiento respecto de los datos personales que su monitorización toca — direcciones IP de visitantes capturadas por los scripts RUM que despliega, datos del cliente final capturados en las capturas de pantalla de la monitorización de transacciones, payloads de respuesta de comprobaciones autenticadas que incluyen información de usuarios. En ese escenario Uptimia actúa como Encargado del tratamiento para usted, regido por nuestro DPA — véase el § 7 más adelante.

Esta Política describe nuestro tratamiento como Responsable de sus propios datos como persona usuaria del Servicio. La relación como Encargado del tratamiento se describe en el § 7 y en el DPA.

3. Información que recopilamos

Recopilamos las siguientes categorías de datos personales sobre las personas usuarias del Servicio.

Datos de cuenta

Identidad: dirección de correo electrónico, contraseña (almacenada como hash bcrypt; los hashes heredados se actualizan en el primer inicio de sesión exitoso), nombre completo, un token opaco de reanudación de cuenta
Dirección postal: calle, código postal, ciudad, estado, país, zona horaria
Identificación empresarial: nombre de la empresa, número de identificación fiscal a efectos del IVA, moneda, región de facturación (código ISO de dos caracteres)
Contacto: número de teléfono, correo electrónico de notificación, etiqueta personalizada de remitente para correo saliente
Metadatos de red: la dirección IP desde la que se registró y la dirección IP desde la que inició sesión más recientemente
Fechas del ciclo de vida: fecha de registro, fecha de última actividad, inicio de la suscripción, fecha de renovación de la membresía, fecha de renovación del crédito de SMS
Seguridad: estado de la autenticación de doble factor, preferencia de notificación por correo de inicio de sesión, marca temporal del último intento fallido de inicio de sesión, contador de intentos fallidos, puntuación heurística interna de riesgo (orientativa; véanse el § 8 y la nota de conservación en el § 11)
Preferencias operativas: estados de opt-in de alertas por correo y por SMS, estado de baja, banderas de incorporación, días «no alertar», su ventana horaria de alertas
Marketing / ciclo de vida: el código UTM o de fuente de referencia de la URL a través de la cual nos alcanzó por primera vez

Datos de facturación

Metadatos de las facturas, importes, referencias y referencias a los PDF almacenados
Metadatos del método de pago (tokens de Stripe / PayPal / tarjeta de crédito — nunca vemos el número de tarjeta completo)
En caso de pago vía PayPal, el payload de Instant Payment Notification de PayPal recibido en relación con la transacción

Datos de autenticación y sesión

Cookies de sesión según se enumeran en nuestra Política de Cookies § 4
Registros de auditoría de inicios de sesión con doble factor — usuario, marca temporal, dirección IP, user-agent — generados cada vez que supera un reto 2FA
Registros de solicitud de restablecimiento de contraseña — generados a demanda cuando solicita restablecer su contraseña
Claves API personales que cree para el acceso programático al Servicio — almacenadas únicamente como hashes unidireccionales; véase el § 12
Contador de intentos fallidos de inicio de sesión y marca temporal del último fallo en su registro de usuario

Canales de doble factor. Cuando habilita la autenticación de doble factor, el código de un solo uso se entrega bien por correo electrónico (a través de nuestro encargado de correo transaccional — AWS SES, véase el § 5.2) bien generado localmente por una aplicación autenticadora TOTP en su dispositivo (Google Authenticator, 1Password, Authy o equivalente). No enviamos códigos 2FA por SMS y no transmitimos su número de teléfono a ningún proveedor de SMS en el flujo 2FA. Cuando usted habilita por separado la función de alertas por SMS para alertas de monitorización, ese flujo está documentado en el § 5 y en el § 7 (Twilio).

Configuraciones de monitor que usted crea

Cuando crea un monitor, la configuración se almacena en nuestra base de datos de la aplicación y se reenvía a la red de sondas en el momento de la ejecución. Las configuraciones pueden contener datos personales:

Comprobaciones HTTP autenticadas: la URL, las credenciales HTTP de autenticación (credenciales Basic y/o cabeceras de petición personalizadas, que pueden llevar bearer tokens o claves API), cualquier cuerpo POST que suministre y los patrones de contenido esperado que configure
Monitores de transacciones: los selectores CSS y las expresiones XPath utilizados para dirigir el recorrido, junto con los valores literales (incluidas credenciales de prueba) que el recorrido envía en cada paso

Las credenciales y secretos que suministra en las configuraciones de monitor se conservan bajo cifrado a nivel de columna con sobre (envelope encryption) con claves gestionadas por separado, según se describe en el § 12.

Resultados de comprobaciones

Generados por nuestra red de sondas en cada comprobación:

Tiempo de actividad / HTTP: tiempos por fase, estado, tipo de error y el cuerpo de respuesta devuelto por la URL monitorizada (los cuerpos de respuesta se conservan durante 7 días y luego expiran automáticamente, conforme al § 11)
SSL: emisor del certificado, fechas de validez y cualquier error relacionado con el certificado que se observe
Dominio / WHOIS: registrador, servidores de nombres, fechas del ciclo de vida y la respuesta WHOIS completa
Velocidad: tiempos de carga, desglose por recurso, puntuaciones de PageSpeed
Transacción: estado por paso, duración y una captura de pantalla almacenada de la página en cada paso (la captura puede incluir datos personales visibles en pantalla en el momento de la captura)
Real User Monitoring (RUM): únicamente métricas agregadas — tiempo de carga de página, páginas vistas, número de errores JavaScript, origen geográfico, navegador y clase de dispositivo. No se recopilan Core Web Vitals (LCP / INP / CLS / TTFB) (por alcance de producto)
Virus / malware: el estado devuelto por el proveedor de detección de malware; no se conserva ningún payload escaneado
Agente de servidor: métricas de CPU, memoria, disco y red transmitidas por el agente que despliega en sus propios servidores. Estas métricas describen la salud de un servidor, no de una persona física. Son, no obstante, vinculables a usted como titular de cuenta porque el agente está registrado contra su cuenta Uptimia y, por esa vinculación, las tratamos como datos personales de usted como titular de cuenta durante la vigencia de la relación contractual — tratadas con base en el Art. 6 (1)(b) RGPD (contrato). El agente no transmite identificadores de cliente final desde el servidor monitorizado (no listas de procesos, no nombres de cuentas de usuario, no variables de entorno); las categorías enumeradas arriba son exhaustivas.

Los plazos de conservación para cada una de las categorías anteriores se rigen por el § 11.

Configuraciones de canales de notificación

Cuando configura un canal de alerta (Slack, Discord, Twilio SMS, Meta WhatsApp Cloud, PagerDuty, Atlassian Statuspage, Microsoft Teams, Mattermost, Telegram, X, webhooks genéricos), almacenamos las credenciales del canal y los registros de contacto que suministre. Cada uno se reenvía al canal elegido en cada alerta.

Doble rol de los canales de alerta. Los canales de alerta transportan dos categorías diferentes de datos bajo dos caracterizaciones de rol diferentes, y el mismo tercero (Slack, Twilio, etc.) viste ambos sombreros:

Registros de contacto y credenciales del equipo de operaciones — los números de teléfono, identificadores de espacios de trabajo y canales de Slack, claves de integración de PagerDuty, tokens de bot de Telegram, URL de webhook, etc. que usted suministra, más el propio payload de alerta cuando va dirigido a su propio equipo de operaciones. Estos registros identifican a su personal (sus ingenieros de guardia, su personal de respuesta a incidentes), no a los visitantes de sus sitios web monitorizados. Para este tramo Uptimia es Responsable del tratamiento respecto del flujo de datos de canales de alerta, y los terceros de los canales de alerta son los prestadores de servicios propios de Uptimia; la base jurídica es el Art. 6 (1)(b) RGPD (ejecución de su contrato de suscripción — la entrega de alertas es la prestación contratada) y el Art. 6 (1)(f) RGPD (interés legítimo de usted, titular de cuenta, en ser notificado). Estos flujos se inventarían en el § 5 como parte del conjunto de relaciones de Uptimia como Responsable.
Datos de cliente final / visitante que puedan aparecer incidentalmente en un payload de alerta — p. ej., cuando usted ha redactado un paso de monitorización de transacciones cuyo mensaje de fallo contiene un identificador de cliente final, o cuando un extracto del cuerpo de una respuesta de comprobación autenticada expone datos personales de uno de sus visitantes y se incluye en el resumen de la alerta. Para ese componente incidental Uptimia actúa como Encargado del tratamiento para usted (el Responsable del tratamiento), el tercero del canal de alerta pasa a ser Subencargado del tratamiento para ese tramo, y el flujo cae bajo el inventario de subencargados del DPA Anexo C.5. Este componente es el que aborda el § 7 más adelante.

Las dos caracterizaciones coexisten porque el evento de alerta es un único mensaje que transporta ambos tipos de contenido. El análisis de relación como Responsable del § 5 rige el tramo de los registros de contacto y credenciales y el tramo de la alerta dirigida a su equipo de operaciones; el análisis del rol como Encargado del § 7 rige únicamente el tramo de los datos de visitante incrustados.

Datos de soporte

Cuando nos contacta, recibimos y almacenamos el contenido de la interacción junto con los identificadores de contacto que suministre:

Conversaciones del widget de chat HelpCanvas — el widget de chat se carga en el sitio de marketing (https://uptimia.com) y, cuando ha iniciado sesión, en la superficie de la aplicación. Cada conversación se almacena como el hilo de mensajes propiamente dicho, su nombre de visualización y dirección de correo electrónico (cuando los proporciona) y los metadatos técnicos que HelpCanvas registra sobre la sesión (marcas temporales, User-Agent del navegador, dirección IP, URL de la página en la que se inició la conversación). HelpCanvas es un producto de JJ Online que funciona sobre la propia infraestructura UE de JJ Online (véase el § 5.7 más adelante); la conversación no sale de la UE y no se comparte con ningún tercero que no sea ya un subencargado para HelpCanvas.
Correspondencia por correo electrónico a nuestras direcciones funcionales — admin@uptimia.com (general), privacy@uptimia.com (privacidad y solicitudes de los interesados) y cualquier otra dirección funcional a la que escriba. Recibimos y almacenamos las cabeceras del correo (su dirección de remitente, nuestra dirección de destinatario, marcas temporales, message-id), el cuerpo del mensaje y cualquier adjunto que decida enviar. El correo entrante y saliente se procesa a través de AWS SES eu-central-1 (véase el § 5.2) y se almacena en la propia infraestructura de correo UE de JJ Online.

Categorías. Identificadores (nombre, dirección de correo electrónico), contenido de texto libre (su mensaje y cualquier adjunto) y metadatos técnicos (marcas temporales, IP, User-Agent, contexto de la página para el widget de chat; cabeceras SMTP para el correo).

Base jurídica. Art. 6 (1)(b) RGPD cuando la correspondencia se refiere a la ejecución del contrato del Servicio que tiene con nosotros (p. ej., una consulta sobre una funcionalidad en una cuenta de pago); Art. 6 (1)(c) RGPD cuando la propia correspondencia es el cumplimiento de una obligación legal (p. ej., responder a una solicitud de un interesado al amparo de los Arts. 12 a 22 RGPD); Art. 6 (1)(f) RGPD para consultas entrantes de potenciales clientes y otros corresponsales con los que no tenemos contrato, siendo el interés legítimo responder a las comunicaciones entrantes dirigidas a nuestras direcciones funcionales publicadas.

Destinatarios. Internos: miembros de JJ Online GmbH que gestionan la cola pertinente de soporte, facturación o privacidad. Subencargados externos: AWS SES eu-central-1 para el transporte de correo (§ 5.2); el stack de la aplicación HelpCanvas funciona sobre la propia infraestructura UE de JJ Online y no introduce un destinatario tercero (§ 5.7 y § 11 «Conversaciones de soporte alojadas en HelpCanvas»). Ningún contenido de soporte se comparte con terceros más allá de lo necesario para entregar el correo o para tramitar su solicitud específica (por ejemplo, cuando nos pide reenviar una consulta de facturación a Stripe, lo haremos siguiendo su instrucción).

Conservación. Duración del asunto de soporte más 3 años naturales anclados al final del año, conforme a la fila Correspondencia de soporte del § 11, con base en el Art. 6 (1)(f) RGPD leído junto con el plazo regular de prescripción (regelmäßige Verjährungsfrist) de los §§ 195 + 199 BGB. La conversación en la plataforma HelpCanvas y la correspondencia por correo se someten a la misma conservación; véase el § 11 «Conversaciones de soporte alojadas en HelpCanvas» para el análisis de plataforma de registro.

Metadatos de petición del lado del servidor leídos en cada petición

Su dirección IP (utilizada para limitación de tasa y defensa contra abusos)
La cadena User-Agent de su navegador (utilizada para validación de integridad de sesión; se hashea en la comprobación de integridad por sesión)

La dirección IP se persiste en su registro de cuenta únicamente como los valores de registro e inicio de sesión más reciente descritos en «Datos de cuenta» arriba; en lo demás se lee de manera transitoria y no se conserva. La cadena User-Agent no se conserva más allá de la comprobación de integridad de sesión hasheada.

Si facilitar esta información es obligatorio (Art. 13 (2)(e) RGPD)

Estamos obligados por el Art. 13 (2)(e) RGPD a informarle de si la provisión de sus datos personales es un requisito legal o contractual y de qué ocurre si decide no proporcionarlos:

Exigidos por la ley. Su nombre, dirección de facturación, NIF-IVA cuando proceda y los datos de las transacciones deben conservarse para cumplir con las obligaciones fiscales y contables alemanas (§ 147 AO, § 257 HGB; § 14 UStG para el contenido de las facturas con IVA). Sin ellos no podemos facturarle legalmente.
Exigidos por contrato. Su correo electrónico, contraseña, identificador del método de pago de facturación y las configuraciones de monitor que envíe son necesarios para operar el contrato del Servicio bajo el Art. 6 (1)(b) RGPD. Sin ellos no podemos prestar el Servicio.
Exigidos para el acceso a la cuenta y la seguridad. Su dirección IP, user-agent, marcas temporales de inicio de sesión y estado 2FA se tratan bajo el Art. 6 (1)(f) RGPD para mantener su cuenta segura.
Voluntarios. Las preferencias de opt-in de marketing, los campos opcionales del perfil y los comentarios quedan a su discreción; no proporcionarlos no afecta a su acceso al Servicio.

Categorías especiales de datos personales (Art. 9 RGPD)

No tratamos a sabiendas categorías especiales de datos personales en el sentido del Art. 9 (1) RGPD — es decir, datos que revelen el origen étnico o racial, opiniones políticas, convicciones religiosas o filosóficas, afiliación sindical, datos genéticos, datos biométricos tratados para identificar de manera unívoca a una persona física, datos relativos a la salud o datos relativos a la vida sexual o las orientaciones sexuales de una persona física. Uptimia es un producto de observabilidad business-to-business; ninguna de las categorías enumeradas en el § 3 anterior (cuenta, facturación, autenticación, configuraciones de monitor, resultados de comprobaciones, configuraciones de canales de notificación, datos de soporte, metadatos de petición del lado del servidor) está diseñada ni destinada a capturar datos del Art. 9.

Le rogamos que no nos envíe datos de categorías especiales — por ejemplo, no los pegue en URL de monitor, cabeceras de monitor, cuerpos de petición, mensajes de prueba de canales de alerta o tickets de soporte, y no escriba recorridos de monitorización de transacciones que enruten datos de categorías especiales a través de Uptimia. Si, no obstante, nos los envía de forma inadvertida — por ejemplo en una descripción de soporte de texto libre — los tratamos como recepción inadvertida: no afirmamos ninguna base del Art. 9 (2) RGPD para tratarlos como datos de categorías especiales, no los utilizamos para fin alguno más allá de lo estrictamente inevitable para tramitar el ticket de soporte que nos los hizo llegar, y suprimiremos el campo en cuestión a petición sin perjuicio del resto del hilo de soporte. En la limitada medida en que el manejo del campo sea inevitable en los instantes entre la recepción y la supresión (p. ej., el agente lee el mensaje para entender la solicitud antes de redactarlo), nos amparamos en el Art. 9 (2)(f) RGPD (tratamiento necesario para la formulación, el ejercicio o la defensa de reclamaciones — aquí, la tramitación del ticket de soporte que a su vez descansa en el Art. 6 (1)(f) y en los §§ 195 + 199 BGB tal como se expone en el § 11 «Correspondencia de soporte») únicamente en la medida en que ese supuesto esté efectivamente activado. No nos amparamos en el Art. 9 (2)(e) RGPD (datos manifiestamente hechos públicos por el interesado): introducir información personal en un ticket de soporte privado no es una divulgación deliberada y dirigida al público en el sentido estricto del Art. 9 (2)(e) que exige la sentencia Lindqvist (TJUE C-101/01) y las directrices del CEPD, y no la tratamos como tal.

Cuando usted, como Responsable, despliega nuestro script RUM o nuestra monitorización de transacciones en una superficie que trata datos de categorías especiales de sus visitantes / clientes finales, esa es su propia decisión como Responsable y su propia responsabilidad bajo el Art. 9 RGPD; nada en nuestro Servicio o en el DPA le autoriza a enrutar datos de categorías especiales a través de Uptimia, y la declaración de categoría de datos del Anexo A del DPA presupone únicamente datos ordinarios de visitantes / clientes finales.

4. Cómo utilizamos su información

Utilizamos los datos que recopilamos para los fines expuestos a continuación. Conforme al Art. 13 (1)(c) RGPD, la base jurídica figura junto a cada finalidad.

Finalidad	Base jurídica (Art. 6 RGPD)
Operar, mantener y mejorar el Servicio y el Sitio web	Art. 6 (1)(f) — interés legítimo
Autenticarle, mantener su sesión, hacer cumplir la 2FA cuando la haya habilitado	Art. 6 (1)(b) — contrato
Ejecutar las configuraciones de monitor que crea y entregar los resultados de comprobaciones a su panel	Art. 6 (1)(b) — contrato
Entregar alertas a los canales que haya configurado (SMS, WhatsApp, Slack, Discord, Teams, Mattermost, Telegram, PagerDuty, Atlassian Statuspage, X, webhooks)	Art. 6 (1)(b) — contrato
Procesar pagos de suscripción y emitir facturas	Art. 6 (1)(b) — contrato
Mantener registros fiscales y contables	Art. 6 (1)(c) — obligación legal (§ 147 AO, § 257 HGB)
Detectar, prevenir y abordar el fraude, los ataques de fuerza bruta contra credenciales y el abuso del Servicio	Art. 6 (1)(f) — interés legítimo en la integridad de la cuenta
Ejecutar sus monitores contra los recursos que configura, desde la red multirregional de sondas	Art. 6 (1)(b) — contrato
Calidad de medida y operaciones de la red de sondas entre clientes — agregar resultados de sondas entre clientes para detectar anomalías del lado de la sonda, calibrar tiempos e identificar incidentes regionales que afecten a múltiples clientes; la salida es agregada y no produce señal a nivel individual	Art. 6 (1)(f) — interés legítimo en la calidad del servicio, la detección de anomalías de sondas y la fiabilidad de la plataforma. No afirmamos que la salida agregada sea «anónima» en el marco de tres pruebas del Dictamen 05/2014 sobre técnicas de anonimización del (antiguo) Grupo de Trabajo del Artículo 29 (singling-out, linkability, inferencia, todos derrotados); tratamos la agregación entre clientes como seudónima para el análisis de la base jurídica y la fundamentamos en el Art. 6 (1)(f) en consecuencia. Los informes de salida se publican únicamente con un umbral de agregación por región suficiente para evitar la reidentificación de la configuración de monitor de cualquier Responsable individual
Ejecutar el seguimiento de atribución de afiliados en el sitio de marketing (FirstPromoter — se dispara solo cuando la URL lleva `?via=`)	Art. 6 (1)(a) + § 25 Abs. 1 TDDDG (en vigor desde el 14 de mayo de 2024 como sucesor de la TTDSG) — consentimiento a través del banner de Datriva
Emitir comunicaciones transaccionales (cuenta, facturación, seguridad)	Art. 6 (1)(b) — contrato
Emitir notificaciones legalmente exigidas (actualizaciones de privacidad / condiciones bajo los Arts. 12 a 14, notificaciones de violación de la seguridad de los datos personales del Art. 34)	Art. 6 (1)(c) — obligación legal
Enviar comunicaciones de actualizaciones de producto a los titulares de cuenta existentes (lanzamientos de funcionalidades de Uptimia, actualizaciones relevantes para el servicio y anuncios sobre servicios similares de JJ Online)	Art. 6 (1)(f) RGPD en relación con el § 7 Abs. 3 UWG (Bestandskundenwerbung). Las cuatro condiciones acumulativas del § 7 Abs. 3 UWG se cumplen todas: (i) su dirección se obtuvo en el contexto de la venta de nuestros bienes o servicios (suscripción o registro de prueba); (ii) utilizamos la dirección únicamente para el marketing directo de nuestros propios productos y servicios similares; (iii) usted no se ha opuesto a este uso — una vez se oponga, todo correo posterior de este tipo cesa de inmediato; y (iv) usted fue clara y conspicuamente informado, tanto en el punto en que recabamos su dirección como en cada mensaje subsiguiente, de que puede oponerse en cualquier momento sin incurrir en costes superiores a las tarifas básicas de transmisión (Basistarif) — es decir, nada más de lo que el destinatario pagaría por enviar un mensaje estándar de vuelta por el medio de transmisión. La oposición bajo el Art. 21 RGPD es incondicional y se procesa a la recepción sin perjuicio para su contrato subyacente
Enviar comunicaciones de marketing a las que usted se haya suscrito	Art. 6 (1)(a) — consentimiento
Cumplir con obligaciones legales, responder a solicitudes lícitas	Art. 6 (1)(c) — obligación legal

Para cada finalidad basada en intereses legítimos, el resumen de la prueba de ponderación y su derecho de oposición bajo el Art. 21 RGPD se describen en el § 15. Una Evaluación del Interés Legítimo (LIA) para cualquiera de estas actividades está disponible a petición en privacy@uptimia.com.

5. Servicios de terceros que utilizamos como Responsable del tratamiento

Los servicios enumerados en esta sección tratan sus datos personales como titular de cuenta Uptimia bajo nuestras instrucciones como Responsable del tratamiento del Sitio web y del Servicio. Cuando, además, Uptimia actúa como Encargado del tratamiento en su nombre para datos personales de sus propios visitantes / clientes finales, los subencargados utilizados para ese rol distinto se enumeran en el § 7 y en el Anexo C del DPA.

La lista completa de Subencargados con direcciones, fechas del DPA y mecanismos de transferencia figura en el Anexo C del DPA. El resumen a continuación es por transparencia bajo el Art. 13 (1)(e) RGPD.

5.1 Pagos y facturación

Proveedor	Entidad legal	Ubicación	Función	Mecanismo de transferencia
Stripe	Stripe Payments Europe Ltd.	Irlanda (+ subprocesamiento US por Stripe, Inc.)	Procesamiento de pagos de suscripción, tokenización de tarjetas, detección de fraude	EU–US DPF + CCT de respaldo
PayPal	PayPal (Europe) S.à r.l. et Cie, S.C.A.	Luxemburgo (+ subprocesamiento US)	Pago alternativo en el checkout	EU–US DPF + CCT de respaldo
easybill	easybill GmbH	Alemania	Generación de facturas, archivado de facturas conforme a GoBD	n/a (solo UE)

5.2 Alojamiento e infraestructura central

Proveedor	Entidad legal	Ubicación	Función	Mecanismo de transferencia
OVH	OVH SAS	Francia	Alojamiento principal de la aplicación (dashboard, API, base de datos principal de la aplicación), red de sondas (región UE), base de datos de series temporales autoalojada	n/a (UE)
AWS — UE	Amazon Web Services EMEA SARL	Luxemburgo (eu-central-1 Frankfurt + S3)	Correo transaccional vía SES a destinatarios UE; almacenamiento de PDF de facturas y exportaciones en S3; red de sondas (regiones UE)	n/a (región UE Frankfurt)
AWS — US	Amazon Web Services, Inc.	EE. UU. (us-east-1 Virginia)	Correo transaccional vía SES a destinatarios no UE; red de sondas (regiones no UE)	EU–US DPF + CCT de respaldo

5.3 Red de sondas

La red de sondas de Uptimia está geográficamente distribuida entre nueve proveedores. Propiedad de diseño importante: las sondas procesan el resultado de la comprobación de forma transitoria en memoria + en tránsito y eliminan inmediatamente cualquier copia local tras reenviar el resultado a la infraestructura principal ubicada en la UE. No se persisten Datos Personales de Cliente en reposo en la capa de sondas.

Proveedor	Entidad legal	Ubicación	Mecanismo de transferencia
OVH	OVH SAS	Francia	n/a (UE)
GCore	G-Core Labs S.A.	Luxemburgo + regiones globales	n/a en regiones UE; CCT para no UE
DigitalOcean	DigitalOcean, LLC	EE. UU. + regiones	EU–US DPF + CCT de respaldo
Linode / Akamai	Akamai Technologies, Inc.	EE. UU. + regiones	EU–US DPF + CCT de respaldo
EDIS	EDIS Telekommunikation GmbH (operando como EDIS.at)	Klagenfurt, Austria	n/a (UE)
Scaleway	Scaleway SAS (Iliad Group)	Francia — regiones de sondas en Francia (París), Países Bajos (Ámsterdam) y Polonia (Varsovia); todas UE	n/a (UE)
AWS	como arriba (5.2)	UE + EE. UU.	n/a UE; DPF + CCT US
Contabo	Contabo GmbH	Alemania (sede en Múnich) — regiones de sondas en UE (Alemania, Austria, España, Portugal) y no UE (EE. UU., Reino Unido, Singapur, Japón, Australia, India)	n/a en regiones UE (Contabo GmbH es la entidad contratante UE); CCT para regiones no UE, con la propiedad de tratamiento efímero descrita en el § 7 (Anexo B.6 del DPA) como medida suplementaria que evita el almacenamiento persistente de Datos Personales de Cliente en hosts de sondas con independencia de la región
Vultr	Vultr Holdings, LLC (The Constant Company, LLC)	EE. UU. (Delaware) — 13 ubicaciones de sondas en EE. UU., Países Bajos, Alemania, Reino Unido, Australia, Japón	Sin certificación DPF — CCT + la propiedad de tratamiento efímero descrita arriba como medida suplementaria principal. Vultr suministra IaaS en bruto y no garantiza contractualmente una propiedad de ausencia de almacenamiento persistente para el uso específico de un cliente de sus servidores; la propiedad de tratamiento efímero es por tanto una medida técnica y organizativa a nivel de despliegue de JJ Online (sin persistencia a nivel de aplicación en discos de Vultr; los datos de entrada y salida de comprobaciones se mantienen únicamente en memoria y en tránsito; el binario de la sonda no escribe Datos Personales de Cliente en disco local) implementada por nosotros como Responsable, y documentada como tal en el Anexo B.6 del DPA. Verificamos periódicamente la propiedad — al menos trimestralmente y en cada cambio del binario de la sonda o de su configuración de despliegue — muestreando hosts de sondas, listando las escrituras en disco local contra una lista de denegación de rutas que el binario de la sonda tiene permitido tocar, y confirmando que no se han escrito Datos Personales de Cliente en disco; el registro de verificación forma parte del registro de pruebas regulares del Art. 32 (1)(d) que mantenemos y es presentable a requerimiento de la autoridad de control. El propio DPA de Vultr sigue siendo el DPA estándar del lado del proveedor y no se invoca para acreditar esta medida.

5.4 Autenticación

Proveedor	Entidad legal	Ubicación	Función	Mecanismo de transferencia
Auth0	Auth0 EMEA Limited (Okta Group)	Irlanda (+ subprocesamiento US)	Gestión de identidad, flujo de inicio de sesión, orquestación de conexiones sociales	EU–US DPF + CCT de respaldo

Sub-subencargados de conexión social de Auth0. Cuando opta por iniciar sesión con Google o GitHub en la página de inicio de sesión alojada por Auth0, Auth0 transfiere el flujo OAuth a esos proveedores. No existe integración OAuth directa entre Uptimia y Google o GitHub; Auth0 mantiene el DPA subyacente. Los proveedores son: Google Ireland Limited (con subprocesamiento US por Google LLC) y GitHub, Inc. (Microsoft Group).

Cookies durante el flujo de inicio de sesión. La página de inicio de sesión alojada por Auth0 establece sus propias cookies estrictamente necesarias en el dominio de Auth0 (no en uptimia.com) durante la autenticación. Estas cookies son necesarias para completar el inicio de sesión que ha solicitado y están exentas del consentimiento bajo el § 25 Abs. 2 Nr. 2 TDDDG. Los botones «Iniciar sesión con Google» e «Iniciar sesión con GitHub» en nuestras páginas de inicio de sesión y registro utilizan un patrón click-to-load: no se carga ningún script de Auth0, Google o GitHub, ni se realizan peticiones a esos proveedores, hasta que pulsa uno de esos botones; el detalle completo y la URL de privacidad de Auth0 / Okta figuran en nuestra Política de Cookies § 4.8.

5.5 Seguridad e inteligencia sobre amenazas

Proveedor	Entidad legal	Ubicación	Función	Mecanismo de transferencia
Google Web Risk API	Google Ireland Limited	Irlanda (+ subprocesamiento US)	Análisis de malware / phishing de URL monitorizadas — solo se envía la URL	EU–US DPF + CCT de respaldo
Google PageSpeed Insights	Google Ireland Limited	Irlanda (+ subprocesamiento US)	Análisis de rendimiento para el monitor de Velocidad — solo se envía la URL	EU–US DPF + CCT de respaldo

5.6 Integraciones de páginas de marketing

Proveedor	Entidad legal	Ubicación	Función	Mecanismo de transferencia
FirstPromoter	Igil Webs SRL	Rumanía	Atribución de afiliados en páginas de marketing de uptimia.com — se dispara solo cuando la URL lleva `?via=`; condicionado a su consentimiento mediante el banner de cookies de Datriva	n/a (UE)

5.7 Servicios cruzados internos de JJ Online (mismo Responsable — no Subencargados del Art. 28)

Los siguientes son operados por la propia JJ Online GmbH y no son Subencargados del artículo 28. Los cinco corren sobre la misma huella UE que la aplicación principal de Uptimia — OVH Francia (base de datos de la aplicación y servicios autoalojados) y, cuando se requiere almacenamiento de blobs, AWS Frankfurt eu-central-1 — bajo las mismas medidas técnicas y organizativas del Art. 32 descritas en el § 12. Ningún tratamiento de productos hermanos de JJ Online sale de la UE.

Banner CMP de Datriva — gestión del consentimiento de cookies en el sitio de marketing (https://datriva.com/cdn/banner/uptimia.js). Alojado en OVH Francia.
Widget HelpCanvas — soporte de chat en la aplicación en el sitio de marketing. La aplicación HelpCanvas y su almacén de mensajes están alojados en OVH Francia bajo el stack de JJ Online; las transcripciones de chat de HelpCanvas no salen de la UE.
Base de datos de series temporales autoalojada — almacenamiento de series temporales para métricas de monitorización, operado por JJ Online sobre infraestructura de OVH Francia.
Altcha — biblioteca de captcha por prueba de trabajo ejecutada localmente en la infraestructura de Uptimia; sin flujo de datos a terceros.
ErrorHawk (producto hermano) — fuera del ámbito de producción: el DSN está configurado únicamente en nuestro entorno interno de desarrollo, no en la infraestructura de producción de uptimia.com. No se reenvían Datos Personales de Cliente a ErrorHawk en producción. El propio stack de producción de ErrorHawk, cuando es relevante para otros productos de JJ Online, también corre sobre OVH Francia.

Divulgación a terceros — sin reventa, sin entrenamiento de IA, sin construcción de audiencias. No divulgamos sus datos personales a terceros para sus propios fines comerciales. Los servicios de terceros del § 5.1 a 5.6 tratan sus datos personales únicamente como nuestros encargados, según nuestras instrucciones documentadas, bajo acuerdos escritos de tratamiento de datos que prohíben contractualmente a cada encargado utilizar sus datos personales para cualquier finalidad más allá del servicio específico que prestan para nosotros. Los usos secundarios prohibidos incluyen, sin limitación:

Entrenamiento de modelos de inteligencia artificial, aprendizaje automático o modelos lingüísticos de gran tamaño — incluido el preentrenamiento de modelos de base, el fine-tuning, la extracción de embeddings, la indexación para generación aumentada por recuperación (RAG), la construcción de conjuntos de evaluación, o cualquier otra incorporación de sus datos personales a conjuntos de datos derivados o pesos de modelos, ya sea por el encargado o por cualquier tercero al que el encargado sublicencie en cadena
Publicidad, perfilado, construcción de audiencias similares (look-alike), segmentación publicitaria o enriquecimiento de segmentos de audiencia
Reventa, sublicenciación o sindicación de sus datos personales — ya sea de forma nominada, seudonimizada, hasheada o agregada — a contrapartes que actúen como data-brokers, redes analíticas o redes publicitarias
Cualquier otro uso secundario que no sea necesario para prestarnos el servicio contratado

Las restricciones del Art. 28 (3) en el acuerdo de tratamiento de cada encargado son el mecanismo de aplicación de las prohibiciones anteriores. Cuando los términos estándar o el DPA de un encargado no cubren adecuadamente estas prohibiciones, o bien negociamos términos modificados antes de darle instrucciones o bien no contratamos al encargado.

6. Otros destinatarios — fiscales, auditoría, jurídicos, M&A y solicitudes lícitas

Más allá de los encargados del día a día del § 5, en línea con el Art. 13 (1)(e) RGPD y las Directrices del CEPD sobre transparencia (WP260 rev. 01), también podemos divulgar datos personales a las siguientes categorías de destinatarios:

Categoría de destinatario	Cuándo	Base jurídica	Alcance
Autoridades fiscales (Finanzamt; equivalentes en otras jurisdicciones)	Declaraciones periódicas, auditorías de cumplimiento, solicitudes lícitas de información	Art. 6 (1)(c) — § 147 AO, § 257 HGB	Limitado a los datos transaccionales, de facturación y contables exigidos por la ley
Auditores externos (legales, voluntarios, due diligence del lado del comprador)	Auditoría anual, auditoría financiera o de seguridad voluntaria, due diligence previa a una adquisición	Art. 6 (1)(c) cuando obligatorio; en caso contrario Art. 6 (1)(f)	Bajo obligaciones escritas de confidencialidad profesional; minimizado al alcance del encargo
Asesoría jurídica (abogados, procuradores, notarios externos)	Defensa de reclamaciones, disputas contractuales, respuesta regulatoria, asesoría transaccional	Art. 6 (1)(f); confidencialidad profesional del § 203 StGB	Minimizado al alcance de la instrucción
Adquirentes potenciales y sus asesores (M&A, inversión, venta de activos, reestructuración)	Operaciones corporativas — salas de due diligence, contratos de compraventa de acciones, ventas de activos	Art. 6 (1)(f), interpretado de manera coherente con el Beschluss «Datenschutz im Asset Deal» de la DSK de 11 de septiembre de 2024 (que sustituyó y amplió el documento original de la DSK de 24 de mayo de 2019). En concreto, aplicamos la estructura fase por fase del Beschluss: en la fase de due diligence, los datos personales de clientes solo se ponen a disposición en principio en forma seudonimizada o agregada, limitándose la divulgación de datos identificativos a la estrecha excepción tardía del Art. 6 (1)(f) que el Beschluss reconoce (LOI firmada / negociaciones avanzadas, NDA en vigor, minimización a lo estrictamente necesario para las preguntas restantes de la due diligence del comprador, sin volcado amplio de la sala de datos); en la fase de cierre / transferencia, seguimos la vía de base jurídica que el Beschluss prescribe para la estructura de la operación de que se trate y, en particular, tratamos la venta de una base de datos de clientes como activo independiente como el supuesto más sensible que, según el análisis del Beschluss, exige generalmente o consentimiento o un proceso significativo de información y oposición previo a la transferencia, distinto del supuesto en el que las relaciones con clientes se transfieren incidentalmente como parte de una operación más amplia de venta de empresa en funcionamiento. En ambas fases, el alejamiento del Beschluss respecto de una pura Widerspruchslösung post-cierre hacia la información previa a la transferencia de los interesados afectados se refleja en la columna de salvaguardias	NDA escrito, minimización de la sala de datos, seudonimización o agregación durante la due diligence (con los datos identificativos liberados únicamente bajo la estrecha excepción tardía del Art. 6 (1)(f), sobre una base de necesidad de conocer y solo una vez cruzado el umbral LOI / negociación avanzada), e información previa a la transferencia de los interesados afectados conforme al Beschluss de 11 de septiembre de 2024 en lugar de un mero opt-out posterior a la transferencia — con el escenario de base de datos de clientes independiente gestionado por la vía de base jurídica más protectora que el Beschluss especifica para ese caso
Cuerpos y fuerzas de seguridad, tribunales, reguladores	Solicitud lícita — orden judicial, citación, investigación regulatoria	Art. 6 (1)(c) cuando vinculante; Art. 6 (1)(f) para la cooperación voluntaria verificada	Limitado al alcance de la solicitud específica; impugnamos solicitudes excesivas cuando la ley lo permite
Aseguradoras y administradores de siniestros	Reclamaciones de responsabilidad profesional, ciberseguro, responsabilidad comercial	Art. 6 (1)(f)	Minimizado a los datos personales necesarios para evaluar y tramitar la reclamación específica

Ninguno de estos destinatarios recibe datos personales de forma rutinaria o a escala; cada divulgación se desencadena por un evento específico.

7. Uptimia como Encargado del tratamiento para los datos de sus visitantes / clientes finales

Cuando utiliza Uptimia para monitorizar recursos que opera, surgen ciertos flujos de tratamiento en los que usted es el Responsable del tratamiento de los datos personales de sus visitantes o clientes finales y Uptimia es el Encargado del tratamiento actuando en su nombre:

Flujo	Qué datos personales fluyen a través de Uptimia
Comprobaciones HTTP autenticadas	Los cuerpos de respuesta de las URL que configura pueden contener nombres de usuario, direcciones de correo electrónico u otros datos personales de sus clientes finales — capturados en nuestras instantáneas de respuesta de comprobación (TTL de 7 días en el campo del cuerpo de respuesta)
Monitorización de transacciones	Las capturas de pantalla tomadas en cada paso de un script de transacción pueden incluir datos personales visibles en páginas autenticadas (p. ej., el nombre de un usuario con sesión iniciada en la barra de navegación) — almacenadas según el plazo de conservación expuesto en el § 11
Real User Monitoring (RUM)	Cuando despliega nuestro script RUM en las URL que seleccione, este envía de vuelta tiempos de carga de página, metadatos del navegador y del dispositivo, origen geográfico y eventos de errores JavaScript; las direcciones IP de los visitantes se truncan a /24 IPv4 y /48 IPv6 antes del almacenamiento; los eventos se persisten solo en forma agregada — no existe un registro por beacon de un visitante individual
Suscripciones a incidentes en página de estado	Las direcciones de correo electrónico que sus visitantes introducen para suscribirse a notificaciones de incidentes en una página de estado que opera a través de Uptimia

División Responsable / Encargado — el análisis de medios esenciales y no esenciales. El Art. 28 RGPD exige al Responsable determinar los fines y medios del tratamiento y al Encargado actuar conforme a las instrucciones documentadas del Responsable. Las Directrices 07/2020 del CEPD sobre los conceptos de Responsable y Encargado (¶ 38) trazan una línea nítida entre los medios esenciales — qué categorías de datos se tratan, qué categorías de interesados, duración de la conservación, destinatarios de los datos — que el Responsable debe determinar y los medios no esenciales — opciones de implementación técnica como algoritmo, formato, software, hardware — que el Encargado es libre de determinar. Somos el Encargado del tratamiento de los datos personales de sus visitantes / clientes finales sobre el siguiente análisis:

Los fines son suyos. Usted decide si despliega nuestro script RUM y en qué URL, si monitoriza un endpoint autenticado, si escribe un recorrido de transacción y si opera una página de estado pública que admita suscripciones de visitantes. Ninguna de esas operaciones de tratamiento se inicia hasta que usted la inicia.
Los medios esenciales son suyos. Su decisión de despliegue determina la categoría de datos (desplegar RUM = eventos de carga de página de sus visitantes; configurar monitorización de transacciones = capturas de pantalla del recorrido que usted programó); las categorías de interesados se determinan por quién visita sus sitios y por para quién programa el recorrido; el plazo de conservación se determina por su nivel de plan del Servicio (véanse el § 11 y la matriz por niveles de plan en uptimia.com); los destinatarios de los datos están limitados por el aislamiento de su cuenta y por los subencargados documentados en el Anexo C del DPA, a los que usted consiente al desplegar.
Los medios no esenciales son nuestros. El truncamiento de las direcciones IP de los visitantes a /24 IPv4 y /48 IPv6 antes del almacenamiento, la lógica de agregación que mantiene los eventos RUM fuera de tablas por beacon, la elección de infraestructura de almacenamiento ubicada en la UE (OVH Francia para la base de datos de la aplicación, AWS Frankfurt eu-central-1 para blobs de capturas de pantalla en S3) y la propiedad de tratamiento efímero de la capa de sondas son opciones de implementación técnica que tomamos como Encargado. Constituyen medidas técnicas y organizativas del Art. 32 RGPD — refuerzan su control sobre los medios esenciales en lugar de desplazarlo.

Sobre este análisis, los cuatro flujos anteriores son relaciones claras Responsable-Encargado del Art. 28. Nuestro DPA incorpora los términos Responsable-Encargado exigidos por el Art. 28 (3) RGPD; el despliegue del Servicio (despliegue del script, configuración del monitor, selección del nivel de plan), las instrucciones documentadas del DPA y el Resumen de Instrucciones de Tratamiento por cuenta descrito en el § 6.1(e) del DPA y en el Anexo A.8 constituyen conjuntamente sus instrucciones documentadas a los efectos del Art. 28 (3)(a) RGPD. El DPA se aplica automáticamente por referencia bajo el § 17.2 de las CGU de Uptimia cuando comienza a utilizar funcionalidades de monitorización que tratan datos personales de sus visitantes / clientes finales; no se requiere firma separada para que el DPA entre en vigor.

Art. 28 (9) RGPD — forma escrita / electrónica. El Art. 28 (9) RGPD exige que el contrato Responsable-Encargado conste «por escrito, inclusive en formato electrónico». Las Condiciones del Servicio de Uptimia en las que se incorpora el DPA son de por sí en formato electrónico, y el texto completo del DPA se publica en una URL estable y persistente en uptimia.com (actualmente https://uptimia.com/legal/dpa — la misma superficie canónica desde la que se publica esta Política de Privacidad) y es accesible para usted en el momento de la incorporación, tanto antes como durante su aceptación de las CGU. Su aceptación electrónica de las CGU — al registrarse, pagar o utilizar de otro modo el Servicio en una forma que active funcionalidades de monitorización que tratan datos personales de sus visitantes / clientes finales — constituye su firma del DPA a los efectos del Art. 28 (9) RGPD. La vía del «ejemplar firmado en contrafirma a petición» del párrafo siguiente es por tanto una concesión a las preferencias formales de aprovisionamiento, no una condición previa para la vigencia del DPA; el DPA es plenamente vinculante bajo el Art. 28 (9) sobre la sola base de la aceptación electrónica.

Instrucciones documentadas por cuenta. Puede solicitar el Resumen de Instrucciones de Tratamiento por cuenta en cualquier momento escribiendo a privacy@uptimia.com. El Resumen se genera a partir del estado de su cuenta en el momento de la solicitud y enumera, para su cuenta específica: los tipos de monitor activos, las URL y recursos que ha elegido monitorizar, su nivel de plan del Servicio y los plazos de conservación que de él se derivan, los canales de alerta que ha activado (y por tanto los Subencargados activos en su cuenta), la región de almacenamiento UE aplicable a sus datos y cualquier instrucción escrita posterior que hayamos aceptado de usted. Devolvemos el Resumen en cinco (5) días hábiles. El Resumen es documental — no modifica el DPA — y está destinado a respaldar su obligación del registro de actividades de tratamiento del Art. 30 (1) y la responsabilidad proactiva del Art. 5 (2) cuando trate datos personales de sus visitantes / clientes finales a través del Servicio. La generación autoservicio del Resumen en su panel está en el roadmap del producto; hasta entonces se aplica el proceso manual.

Ejemplar firmado del DPA. Cuando su proceso de aprovisionamiento, auditoría o regulatorio requiera un ejemplar firmado en contrafirma de nuestro DPA con el Resumen de Instrucciones de Tratamiento adjunto como Anexo A.8, lo formalizaremos a petición sin cargo. Contacte privacy@uptimia.com.

Subencargados del lado de visitantes. Los subencargados utilizados para el rol de Encargado se enumeran en el Anexo C del DPA. Constituyen un superconjunto de los subencargados del § 5 anterior. Las entradas adicionales del Anexo C.5 son los canales de alerta que usted configura (Slack, Discord, Twilio, PagerDuty, etc.), que se convierten en Subencargados únicamente en la medida en que el payload de la alerta incluya datos personales de visitantes / clientes finales suyos (según se expone en el § 3 «Configuraciones de canales de notificación — doble rol de los canales de alerta» arriba), y solo cuando habilita efectivamente el canal. Los mismos terceros también actúan como prestadores de servicios propios de Uptimia respecto de los registros de contacto y credenciales del equipo de operaciones y del componente de la alerta dirigida a su equipo de operaciones dentro del mismo flujo — ese tramo de relación como Responsable es el inventariado en el § 5, no aquí. El listado del Anexo C.5 es por tanto más estrecho que la lista canal por canal del § 5: es la proyección de rol como Encargado del mismo conjunto de terceros.

Salvaguardias técnicas para los flujos del rol de Encargado.

Las direcciones IP de visitantes en RUM se truncan a /24 (IPv4) o /48 (IPv6) antes de que el evento se escriba en almacenamiento; la dirección IP completa nunca se persiste
Los eventos RUM se persisten únicamente en forma agregada — no existe tabla por beacon, y no puede reconstruirse ningún visitante individual a partir de los datos almacenados
Las capturas de pantalla de transacciones y las instantáneas de respuesta de comprobación se almacenan en AWS S3 (Frankfurt) bajo nuestra cuenta; el acceso se controla por la autenticación de la cuenta de registro
Los nodos de sondas tratan los datos de entrada y salida de las comprobaciones solo efímeramente; no se persisten Datos Personales de Cliente en reposo en la capa de sondas
Las credenciales y secretos que suministra para que el Servicio pueda autenticarse contra sus recursos (credenciales HTTP Basic, cabeceras de petición personalizadas, credenciales de integración, valores literales de pasos de transacción) se conservan bajo cifrado a nivel de columna con sobre con claves gestionadas por separado, según se describe en el § 12

Consentimiento de los visitantes. Es su responsabilidad como Responsable del tratamiento obtener cualquier consentimiento requerido de sus visitantes antes de desplegar nuestro script RUM en su sitio web. Cuando el § 25 TDDDG o la legislación nacional UE equivalente exija consentimiento para el almacenamiento de información en el terminal del visitante o el acceso a la misma, sus visitantes deben recibir una oportunidad de consentimiento conforme al § 25 antes de que nuestro script RUM se cargue. Proporcionamos documentación sobre la integración de la activación condicional por consentimiento; la implementación es suya.

8. Perfilado y decisiones automatizadas

Esta sección divulga las actividades automatizadas que el Servicio opera y que cumplen la definición de perfilado del Art. 4 (4) RGPD, según exigen el Art. 13 (2)(f) y el Art. 15 (1)(h) RGPD — incluida la única actividad que cumple la definición de decisión automatizada del Art. 22 (1) RGPD.

Decisión automatizada de fraude en el pago durante el checkout (Art. 22 (1) RGPD). Cuando envía un pago, nuestro procesador de pagos evalúa la transacción frente a señales que incluyen método de pago, huella del dispositivo, dirección de facturación, dirección IP, historial de uso previo y patrones de aprendizaje automático extraídos del corpus de fraude más amplio del procesador, con el fin de producir una puntuación de riesgo de fraude. Una puntuación suficientemente elevada provoca que la transacción se rechace, se marque para revisión manual por el procesador o se enrute a verificación adicional como 3-D Secure. Se trata de una decisión exclusivamente automatizada que, al impedir que la compra se complete en tiempo real, tiene efectos sobre usted lo suficientemente significativos para caer dentro del Art. 22 (1) RGPD.

El análisis se divide aquí entre (i) la base jurídica del tratamiento subyacente de sus datos de pago (Art. 6 RGPD) y (ii) la puerta de entrada del Art. 22 (2) RGPD que autoriza la propia decisión automatizada. Siguiendo la lectura estrecha del CEPD del «necesario para el contrato» en sus Directrices sobre el artículo 22 (y la línea reforzada en los comentarios posteriores a la sentencia SCHUFA Holding (TJUE C-634/21, 7 de diciembre de 2023)), encabezamos con las bases legales y tratamos la necesidad contractual únicamente como respaldo.

Base jurídica del tratamiento subyacente — Art. 6 (1)(c) RGPD (principal). El tratamiento es necesario para el cumplimiento por parte del procesador de pagos de los requisitos de Autenticación Reforzada del Cliente (SCA) de la PSD2 (Directiva (UE) 2015/2366 y Reglamento Delegado (UE) 2018/389 de la Comisión), de los regímenes de prevención del blanqueo de capitales / lucha contra la financiación del terrorismo (Directiva (UE) 2015/849, en su versión modificada; el Reglamento AML de la UE; actos nacionales de transposición), y de la obligación contenida en las Directrices de la ABE EBA/GL/2017/17 sobre las medidas de seguridad para los riesgos operacionales y de seguridad de los servicios de pago de aplicar mecanismos de monitorización de transacciones que detecten transacciones de pago fraudulentas. Esas obligaciones legales vinculan directamente al procesador de pagos y se trasladan a nosotros como comerciante por cuya cuenta se opera el cribado; hacen que el tratamiento sea necesario para el cumplimiento de una obligación legal a la que Uptimia (a través del procesador) está sujeta en el sentido del Art. 6 (1)(c) RGPD.

Art. 6 (1)(f) RGPD — base alternativa para el interés residual del comerciante en la prevención del fraude. En la medida en que algún elemento del cribado vaya más allá de lo estrictamente exigido por el marco legal anterior y refleje nuestro propio interés como comerciante en prevenir el fraude card-not-present, los chargebacks y la apropiación de cuentas en el registro, nos amparamos en el Art. 6 (1)(f) RGPD. La ponderación del interés legítimo para este elemento residual se documenta en el § 15 («Resumen de la Evaluación del Interés Legítimo») y considera el interés como sustancial (pérdida directa por fraude + carga de gestión de disputas), los intereses del interesado como protegidos por las salvaguardias del Art. 22 (3) más abajo, y el tratamiento como proporcionado (señales por transacción, no conservadas como perfil).

Art. 6 (1)(b) RGPD — base de ejecución del contrato, solo respaldo. Cuando ni el encuadre legal ni el de interés residual cubran un elemento concreto del tratamiento, el cribado también es necesario para que podamos celebrar el tramo de pago del contrato que usted busca concluir con nosotros, respaldando el Art. 6 (1)(b). Lo listamos como respaldo porque compartimos la opinión del CEPD de que la «necesidad» del Art. 6 (1)(b) debe leerse de forma estrecha: el hecho de que el cribado antifraude sea operativamente indispensable no satisface por sí solo el test de «sin alternativa menos intrusiva», y las bases del Art. 6 (1)(c) y (f) anteriores son la narrativa más limpia.

Puerta de entrada del Art. 22 (2) para la propia decisión automatizada. El Art. 6 por sí solo no autoriza la decisión automatizada del Art. 22 (1); esa decisión necesita una puerta de entrada del Art. 22 (2) — (a) necesidad contractual, (b) Derecho de la Unión o del Estado miembro que la autorice y que establezca medidas adecuadas, o (c) consentimiento explícito. Nos amparamos principalmente en el Art. 22 (2)(b) RGPD: el marco SCA de la PSD2 (Directiva (UE) 2015/2366 leída con el Reglamento Delegado (UE) 2018/389 de la Comisión) y el marco AML / CTF citado arriba constituyen Derecho de la Unión autorizador que exige precisamente las decisiones de monitorización de transacciones tomadas en el checkout y que por sí mismo establece las salvaguardias adecuadas para el interesado (capítulo de protección del consumidor del Título IV de la PSD2; mecanismos de reclamación y revisión de la AMLD en las transposiciones nacionales; las salvaguardias del Art. 22 (3) RGPD del interesado aplicadas en paralelo). Las Directrices de la ABE citadas arriba operativizan ese régimen legal a través de expectativas supervisoras vinculantes sobre las decisiones de monitorización de pagos. Tratamos el Art. 22 (2)(a) RGPD (necesidad contractual) como puerta de entrada de respaldo del Art. 22 solo — activada si y en la medida en que una autoridad de control leyera de forma estrecha la puerta del Art. 22 (2)(b) — y no nos amparamos en el Art. 22 (2)(c) (consentimiento explícito), que no se prestaría libremente en un contexto de checkout de pago.

Sus salvaguardias bajo el Art. 22 (3) RGPD. Tiene derecho:

a obtener intervención humana en la decisión — escriba a privacy@uptimia.com identificando la transacción rechazada; enrutaremos el caso al equipo de revisión manual del procesador de pagos y a nuestro área de operaciones de facturación, ambos pueden anular el resultado automatizado sobre los hechos;
a expresar su punto de vista — puede aportar cualquier contexto que considere relevante (p. ej., contexto de viaje para un rechazo por IP extranjera, datos de facturación corregidos, prueba de titularidad de la tarjeta);
a impugnar la decisión — el resultado de la revisión manual es a su vez revisable por nosotros; si sigue insatisfecho, puede utilizar la ruta alternativa de checkout (Stripe ↔ PayPal) o solicitar una explicación escrita apta para reenviar a su emisor de tarjeta.
a recibir el código específico de motivo de rechazo y, cuando proceda, el nombre de la regla de Stripe Radar — a petición del Art. 22 (3), además de los pasos de revisión humana anteriores, le comunicaremos el código de motivo de rechazo devuelto por el procesador de pagos para su transacción y, cuando el rechazo haya sido impulsado por una regla específica de Radar que el procesador nos haya expuesto en el panel de comerciante (a diferencia de un rechazo del banco emisor), el nombre de esa regla. Esta es la divulgación por decisión de los motivos principales descrita en «Información significativa sobre la lógica aplicada» más abajo; hacemos explícito el compromiso aquí para que sea alcanzable desde la lista de salvaguardias del Art. 22 (3) sin tener que leer primero el párrafo de implementación de SCHUFA.

Responderemos a cualquier solicitud del Art. 22 (3) dentro del plazo del Art. 12 (3) RGPD (un mes, ampliable por dos meses adicionales en casos complejos previa notificación).

Información significativa sobre la lógica aplicada (Art. 15 (1)(h) RGPD; TJUE Asunto C-634/21 SCHUFA Holding, 7 de diciembre de 2023). La puntuación de riesgo de fraude la produce un modelo de aprendizaje automático de tercero mantenido por el procesador de pagos (Stripe Radar; el modelo equivalente de PayPal) y ajustado contra el corpus global de fraude de ese procesador. Los pesos internos de esos modelos no son publicados por el procesador y no se ponen a nuestra disposición bajo los términos estándar de comerciante — exponer los pesos permitiría a los defraudadores realizar ingeniería inversa del modelo, razón por la cual ningún procesador de pagos con tarjeta de relevancia divulga los pesos. No consideramos que esa ausencia derrote su derecho del Art. 15 (1)(h). SCHUFA Holding exige «información significativa sobre la lógica aplicada» suficiente para permitir al interesado comprender el procedimiento que condujo a la puntuación y, en su caso, impugnar la decisión específica en su caso — no el algoritmo en sí. Sobre ese estándar divulgamos, y a petición confirmaremos por escrito:

Los grupos principales de factores que el modelo evalúa — importe y moneda de la transacción; metadatos del método de pago (BIN de la tarjeta, país de emisión, marca, tipo de financiación); el resultado de la verificación AVS de la dirección de facturación; huella del dispositivo y del navegador; dirección IP, geolocalización de IP y discrepancia entre IP y país de facturación; resultados previos para la misma tarjeta o cuenta en el corpus global del procesador y en Uptimia (su historial con nosotros); señales de reputación a nivel de red y de listas de bloqueo; resultado 3-D Secure cuando esté disponible.
El motivo principal de su resultado específico. Si su transacción fue rechazada, el procesador devuelve un código específico de motivo de rechazo (por ejemplo do_not_honor, card_declined, fraudulent, lost_card, stolen_card, pickup_card, incorrect_cvc, expired_card) y, cuando el rechazo haya sido impulsado por una regla de Radar en lugar de por el banco emisor, el nombre de la regla que se activó (visible para nosotros en el panel de comerciante). Le trasladaremos ese código específico y, cuando esté disponible, el nombre específico de la regla a petición — esa es la divulgación de motivos principales exigida por SCHUFA Holding § 54 a § 59.
La vía de anulación que controlamos como comerciante. Un rechazo por fraude del lado del procesador no le cierra el acceso al Servicio. Podemos optar por aceptar una transacción que el modelo rechazó; escriba a privacy@uptimia.com identificando la transacción, aporte cualquier contexto que considere relevante (viaje, datos de facturación corregidos, prueba de titularidad de la tarjeta) y nosotros (a) escalaremos al equipo de revisión manual del procesador, que puede anular el modelo sobre los hechos, y (b) reintentaremos el cargo desde nuestro lado de comerciante tras la anulación, o utilizaremos la ruta alternativa de checkout (Stripe ↔ PayPal).
Significación para usted. Una puntuación suficientemente elevada o bien rechaza la transacción en el checkout, o bien dispara un step-up 3-D Secure, o bien enruta la transacción a revisión manual en el procesador. La puntuación no se conserva como un perfil en su registro de usuario; es una señal por transacción.

Límites antiabuso de tasa y puntuación de bots de registro (sin decisión del Art. 22). Separado del fraude en el pago, aplicamos decisiones automatizadas de limitación de tasa contra los endpoints de API y de registro basadas en patrones de petición, reputación de IP y antigüedad de la cuenta. El registro se condiciona además con Altcha, un reto de prueba de trabajo autoalojado ejecutado localmente en la infraestructura de Uptimia (sin flujo de datos a terceros). También se registra una puntuación heurística interna en su registro de usuario. Estas señales son orientativas únicamente — no existe lógica de autosuspensión o autorrechazo. Las cuentas se deshabilitan manualmente por un administrador tras revisión humana. El registro está limitado a 3 intentos cada 15 minutos por IP. La decisión es reversible escribiendo a privacy@uptimia.com.

Transparencia de perfilado para la heurística orientativa (Art. 4 (4), Art. 13 (2)(f), Art. 14 (2)(g), Art. 15 (1)(h) RGPD). La puntuación heurística orientativa en su registro de usuario es perfilado en el sentido del Art. 4 (4) RGPD aun cuando no se tome ninguna decisión exclusivamente automatizada que produzca efectos jurídicos o significativos similares sobre la base de ella (el Art. 22 (1) RGPD no se activa). Las obligaciones de transparencia bajo los Arts. 13 (2)(f) y 14 (2)(g) — y el correspondiente derecho de acceso a la «información significativa sobre la lógica aplicada» bajo el Art. 15 (1)(h) — no se limitan estrictamente, según la mejor lectura, al perfilado del Art. 22 (1); por tanto divulgamos, tanto aquí con antelación como a petición de acceso, las categorías principales de inputs que evalúa la heurística: tasa de intentos de registro o de inicio de sesión desde la misma IP y el mismo dominio de correo en una ventana definida; presencia de la IP en listas de reputación internas y externas bien conocidas (p. ej., agregadores de listas de proxies abiertos / nodos de salida Tor / VPN conocidos); señales de antigüedad y estado de la cuenta (recién creada vs. de larga data, historial previo de tickets de soporte); similitud de patrón con huellas conocidas de abuso (tasa de fallos de prueba de trabajo vía Altcha, patrón de creación de monitores en los minutos posteriores al registro). A petición de acceso del Art. 15 (1)(h), divulgaremos adicionalmente la puntuación registrada en su cuenta, los principales contribuyentes a esa puntuación y la ausencia de cualquier regla de autodecisión asociada a ella.

Su derecho de oposición bajo el Art. 21 RGPD. Conserva el derecho de oponerse a cualquier perfilado que se apoye en nuestros intereses legítimos (Art. 6 (1)(f) RGPD). Este derecho, sin embargo, no se extiende a la decisión de fraude en el pago descrita arriba en la medida en que esa decisión descanse en la puerta de entrada del Art. 22 (2)(b) de Derecho de la Unión autorizador y en la base del Art. 6 (1)(c) de cumplimiento legal — ninguna de las cuales activa el Art. 21. Para el elemento residual del Art. 6 (1)(f) del cribado, el Art. 21 sí aplica, pero la ponderación del interés legítimo registrada en el § 15 prevalecería en la práctica sobre una oposición respecto de un intento de pago activo; para la propia decisión, sus salvaguardias son los derechos del Art. 22 (3) expuestos arriba.

9. Consentimiento de cookies — otorgamiento y retirada

El banner de cookies en uptimia.com lo opera Datriva (también un producto de JJ Online GmbH — utilizamos nuestra propia plataforma de gestión del consentimiento). Cuando utilizamos cookies o tecnologías comparables que requieren su consentimiento bajo el Art. 6 (1)(a) RGPD y el § 25 Abs. 1 TDDDG, el mecanismo de consentimiento y el mecanismo de retirada se rigen por las siguientes reglas.

Cómo obtenemos el consentimiento. En su primera visita al sitio de marketing, el banner de Datriva aparece antes de que se establezca cualquier cookie no esencial. El banner presenta las tres categorías que requieren consentimiento (Funcionales, Analíticas, Marketing) como opt-in únicamente — cada categoría está desmarcada por defecto. Puede aceptar todo, rechazar todo o aceptar un subconjunto granular con el mismo número de clics, coherentemente con el Art. 7 (2) RGPD y las Directrices del CEPD 05/2020 sobre el consentimiento. Las cookies estrictamente necesarias se establecen sin consentimiento sobre la base del § 25 Abs. 2 Nr. 2 TDDDG.

Retirada — tan fácil como darlo. El Art. 7 (3) RGPD exige que la retirada del consentimiento sea tan fácil como darlo. Conforme a las Directrices del CEPD 05/2020 sobre el consentimiento (§ 117), la paridad aquí significa el mismo medio y el mismo número de pasos que el opt-in original. Por tanto operamos una única vía de paridad del Art. 7 (3):

Enlace «Preferencias de cookies» en el pie del sitio de marketing (vía de paridad del Art. 7 (3)). Un enlace persistente «Preferencias de cookies» está presente en el pie de cada página de marketing. Al hacer clic en él se reabre el mismo banner de Datriva con sus ajustes actuales, donde puede apagar cualquier categoría — o rechazar todas las cookies no esenciales — en el mismo número de clics que necesitó para aceptarlas. Como el banner que gestiona la retirada es el mismo elemento de UI, en el mismo medio, con los mismos controles de conmutador que el banner que gestionó el consentimiento original, el mecanismo de retirada es idéntico al (no meramente «tan fácil como») mecanismo de otorgamiento. Esta es la forma más fuerte de paridad del Art. 7 (3) contemplada en las Directrices 05/2020 del CEPD sobre el consentimiento § 117 y es la que invocamos como nuestra vía de paridad.

Hay dos vías adicionales disponibles por comodidad pero no equivalentes al opt-in original y no se invocan para satisfacer la paridad del Art. 7 (3):

Correo electrónico a privacy@uptimia.com. Registraremos y tramitaremos la retirada manualmente dentro del plazo del Art. 12 (3) RGPD.
Borrar las cookies en su navegador. Esto también borra nuestro registro local de consentimiento, de modo que el banner reaparecerá en su siguiente visita; los pasos implicados no son equivalentes al mecanismo de opt-in original.

Efecto de la retirada. Las cookies no esenciales dejan de establecerse inmediatamente tras la retirada. La retirada no afecta a la licitud del tratamiento llevado a cabo antes de la retirada (Art. 7 (3) RGPD, segunda frase).

Para el inventario por cookie, véase la Política de Cookies.

10. Cookies

Utilizamos cookies y tecnologías de seguimiento similares. Nuestra Política de Cookies expone: (i) las cuatro categorías (Estrictamente Necesarias, Funcionales, Analíticas, Marketing — actualmente no utilizamos ninguna Funcional, ninguna Analítica y solo un tercero de la categoría Marketing y solo cuando llega vía ?via=), (ii) cada cookie específica y entrada de localStorage / sessionStorage con su proveedor y duración, (iii) los scripts de terceros, (iv) las bases jurídicas para cada categoría bajo el § 25 TDDDG y el Art. 6 RGPD, y (v) los mecanismos de consentimiento y retirada.

11. Conservación de datos

Conservamos los datos personales únicamente durante el tiempo necesario para los fines expuestos en esta política o según lo exija la ley. Conforme al Art. 5 (1)(e) RGPD aplicamos un análisis de limitación del almacenamiento por categorías en lugar de un único reloj uniforme. Las categorías siguientes cubren todos los datos personales que tratamos.

Categoría	Plazo de conservación	Base jurídica
Datos de cuenta y de acreditación contractual — nombre legal, correo electrónico de contacto, identidad de facturación, historial de pedidos y suscripciones, modificaciones contractuales, notificación de resolución, correspondencia sobre disputas	Duración de su cuenta + 3 años naturales después de la terminación (anclados al final del año)	Art. 6 (1)(f); § 195 + § 199 Abs. 1 BGB (formulación, ejercicio y defensa de reclamaciones)
Facturas, registros de pago, libros contables	De 6 a 10 años, según el tipo de documento, anclados al final del año natural — 10 años para libros, inventarios y cuentas anuales (§ 147 Abs. 1 Nr. 1 AO; § 257 Abs. 1 Nr. 1, Nr. 3 HGB leído con Abs. 4); 8 años para justificantes contables y registros de facturas del § 14b UStG (§ 147 Abs. 1 Nr. 4 y Nr. 4a AO tras la Bürokratieentlastungsgesetz IV, en vigor desde el 1 de enero de 2025; § 257 Abs. 4 HGB tras la BEG IV); 6 años para correspondencia comercial (§ 147 Abs. 1 Nr. 2 y Nr. 3 AO; § 257 Abs. 1 Nr. 2 HGB)	Art. 6 (1)(c); § 147 AO, § 257 HGB, § 14 UStG
Preferencias operativas — preferencias de notificación y comunicación, ajustes de UI, filtros guardados, layouts de dashboard, tokens de integración, claves API, archivos subidos	Duración de la relación contractual	Art. 6 (1)(b)
Eventos de autenticación y auditoría de seguridad — registros de inicio de sesión, eventos de doble factor, auditoría de IP, contadores de intentos fallidos	180 días	Art. 6 (1)(f); línea base BSI IT-Grundschutz
Puntuación heurística interna de riesgo orientativa (descrita en el § 3 «Seguridad» y en el § 8 «Límites antiabuso de tasa y puntuación de bots de registro») — un único entero orientativo por registro de usuario	Duración de su cuenta, recomputada en cada nueva señal de abuso y sobrescrita en sitio (no se conserva tabla histórica de puntuaciones); suprimida con la cuenta al final del proceso de anonimización de cuenta bajo la fila «Datos de cuenta y de acreditación contractual» anterior	Art. 6 (1)(f) (defensa antiabuso; no se toma ninguna decisión del Art. 22 (1) sobre la base de esta puntuación)
Registros de aplicación y de acceso — tráfico rutinario, registros de error	30 días	Art. 6 (1)(f) (integridad operativa)
Configuraciones de monitor que crea	Duración del monitor	Art. 6 (1)(b)
Datos de resultados de monitores — tiempo de actividad, SSL, dominio/WHOIS, velocidad, transacción, agregados RUM, virus/malware, métricas del agente de servidor	Hasta 13 meses, escalonado por plan (véase la matriz por niveles de plan en uptimia.com)	Art. 6 (1)(b); techo de utilidad para el cliente
Cuerpos de respuesta HTTP de uptime	7 días (autoexpiran)	Art. 6 (1)(b) (operativo únicamente)
Capturas de pantalla de transacciones	30 días	Art. 6 (1)(f); minimización de datos bajo el Art. 5 (1)(c) (pueden ser visibles datos personales en pantallas autenticadas)
Correspondencia de soporte	Duración del asunto de soporte + 3 años naturales (anclados al final del año)	Art. 6 (1)(f); § 195 + § 199 BGB
Registros de consentimiento de cookies	180 días para el registro de consentimiento + 12 meses de conservación del log de auditoría	Art. 7 (1) RGPD (prueba del consentimiento)
Copias de seguridad	Ventana rotativa de 14 días	Art. 6 (1)(f) (recuperación ante desastres)

Tras expirar el plazo anterior, los datos personales se suprimen o — cuando la supresión menoscabe la integridad de la auditoría — se anonimizan de modo que la reidentificación deje de ser razonablemente posible. La conservación legal (la segunda fila anterior) prevalece sobre la supresión anterior bajo el Art. 17 (3)(b) RGPD.

Comportamiento en la supresión de cuenta (Art. 17 RGPD). Cuando suprime su cuenta a través de Ajustes o por solicitud a privacy@uptimia.com, las integraciones de pago, las páginas de estado, los operadores y las sesiones activas se eliminan inmediatamente; las configuraciones de monitor y los ajustes de alerta entran en la cola de defensa de reclamaciones descrita en la primera fila anterior; su identidad de contacto y de acreditación contractual se anonimiza o suprime al final de esa cola, sujeto a la conservación legal exigida para facturas y libros contables. Las copias de seguridad envejecen conforme a la ventana rotativa de 14 días: durante esa ventana los datos no se tratan activamente y existen únicamente como una instantánea congelada de recuperación ante desastres. La combinación de una ventana rotativa corta, la ausencia de tratamiento activo durante esa ventana y el paso de re-supresión-tras-restauración descrito a continuación es coherente con la práctica establecida de las autoridades de control sobre copias de seguridad bajo el Art. 17 (1) / (3) RGPD. Mantenemos un registro interno de copias de seguridad que documenta los sistemas en alcance (base de datos de la aplicación, base de datos de series temporales, AWS S3 Frankfurt para capturas de pantalla de transacciones), la política de rotación, la ubicación de almacenamiento, los controles de acceso y el runbook de re-supresión. Si restauramos desde una copia de seguridad anterior a una solicitud de supresión, la supresión original se vuelve a aplicar a los datos restaurados en un plazo de 72 horas desde la finalización de la restauración — y, cuando la restauración devuelve al sistema al estado en línea para tratamiento activo, antes de que el sistema restaurado se abra al tráfico de usuarios — de modo que los datos personales suprimidos no se reintroducen en el tratamiento activo. El techo de 72 horas es el compromiso externo de auditoría; en operación normal, la repetición de la re-supresión corre como primer paso programado tras la restauración y se completa en minutos, no en horas. El registro de copias de seguridad consigna, para cada restauración de producción, (i) la marca temporal de finalización de la restauración, (ii) la marca temporal de finalización de la repetición del log de supresión, y (iii) la confirmación de que no se admitió tráfico de usuarios al sistema restaurado entre (i) y (ii).

Datos de visitantes tratados bajo el § 7 (rol de Encargado). Conservados conforme al DPA, generalmente según lo instruido por usted como Responsable. Los valores por defecto coinciden con la categoría equivalente anterior.

Conversaciones de soporte alojadas en HelpCanvas. HelpCanvas es un producto de JJ Online que funciona sobre la propia infraestructura UE de JJ Online (§ 5.7) — no una plataforma de tercero — de modo que JJ Online es el Responsable único de la conversación con independencia de en qué superficie se lea o escriba. La conservación sigue la fila Correspondencia de soporte anterior (duración del asunto de soporte + 3 años naturales anclados al final del año; Art. 6 (1)(f); § 195 + § 199 BGB). No existe una conservación separada de «plataforma de registro» a la que deferir.

12. Seguridad de los datos

Implementamos las medidas técnicas y organizativas adecuadas bajo el Art. 32 RGPD para proteger sus datos personales frente al acceso, divulgación, alteración o destrucción no autorizados. En la práctica:

TLS 1.2+ para todas las interfaces de cara al cliente y todas las comunicaciones con subencargados
Controles de acceso basados en roles que limitan el acceso a datos personales al personal que lo necesita; autenticación multifactor para todo el personal operativo
Obligaciones escritas de confidencialidad del personal
Cifrado en reposo a nivel de disco para la base de datos de la aplicación y la base de datos de series temporales en infraestructura UE; copias de seguridad cifradas bajo una clave gestionada por separado
Cifrado a nivel de columna (con sobre) para credenciales y secretos que suministra para que el Servicio pueda actuar en su nombre — véase el párrafo dedicado más abajo; las claves API personales se almacenan únicamente como hashes unidireccionales
Truncamiento de direcciones IP para eventos RUM (/24 IPv4, /48 IPv6) antes del almacenamiento
Aislamiento lógico por usuario en la capa de aplicación
Proceso de notificación de violación de la seguridad de los datos personales en 72 horas según el Art. 33 RGPD
Escaneo periódico de vulnerabilidades, monitorización de dependencias, revisión de código antes del merge

Credenciales y secretos que nos confía. Cuando suministra credenciales para que el Servicio pueda autenticarse contra sus recursos en su nombre — por ejemplo, credenciales HTTP Basic, cabeceras de petición personalizadas (incluidos bearer tokens y claves API), credenciales de integración para canales de alerta y valores literales configurados en pasos de monitorización de transacciones — esas credenciales se conservan bajo cifrado a nivel de columna además del cifrado a nivel de disco que aplica a la base de datos en su conjunto. Las claves de cifrado se gestionan por separado de la propia base de datos, de modo que el personal operativo con acceso a base de datos no puede leer las credenciales en claro. El descifrado ocurre únicamente en el punto en que la red de sondas ejecuta la comprobación contra el recurso que configuró, y el texto en claro se mantiene en memoria únicamente durante la ejecución de esa única comprobación. Las claves API personales que crea para el acceso programático al Servicio se almacenan como hashes unidireccionales; no conservamos copia en claro tras la emisión — si pierde una clave API personal, debe rotarla a través del panel.

Ningún método de transmisión por internet o de almacenamiento electrónico es completamente seguro. Si cree que su interacción con nosotros ya no es segura, contacte privacy@uptimia.com.

13. Sus derechos

Como Responsable establecido en la Unión Europea, estamos sujetos al RGPD bajo el Art. 3 (1) para todo nuestro tratamiento, con independencia de dónde se encuentre el interesado. Los derechos siguientes se aplican por tanto a toda persona cuyos datos personales tratamos, no solo a residentes UE/EEE/Reino Unido/Suiza.

Tiene los siguientes derechos:

Derecho de acceso (Art. 15 RGPD) — solicitar una copia de los datos personales que conservamos sobre usted
Derecho de rectificación (Art. 16 RGPD) — solicitar la corrección de datos inexactos o incompletos
Derecho de supresión (Art. 17 RGPD) — solicitar la supresión, sujeto a las excepciones del Art. 17 (3) (en particular: obligación legal bajo el § 147 AO / § 257 HGB para facturas)
Derecho a la limitación del tratamiento (Art. 18 RGPD)
Derecho a la portabilidad de los datos (Art. 20 RGPD) — recibir sus datos en un formato estructurado, de uso común y legible por máquina
Derecho de oposición (Art. 21 RGPD) — oponerse al tratamiento basado en nuestros intereses legítimos, incluido el perfilado; la oposición al marketing directo es incondicional
Derecho a no ser objeto de decisiones automatizadas (Art. 22 RGPD) — existe una decisión del Art. 22 (1) en el checkout (cribado de fraude en el pago); el tratamiento subyacente descansa principalmente en el Art. 6 (1)(c) RGPD (cumplimiento legal SCA PSD2 + AML/CTF) con el Art. 6 (1)(f) cubriendo el interés residual del comerciante en la prevención del fraude, y la propia decisión del Art. 22 (1) se autoriza bajo la puerta de entrada de Art. 22 (2)(b) RGPD de Derecho de la Unión autorizador (con el Art. 22 (2)(a) tratado únicamente como respaldo). Proporcionamos las salvaguardias del Art. 22 (3) (intervención humana, expresión de punto de vista, impugnación, además de la divulgación del código de motivo de rechazo y del nombre de regla de Stripe Radar descrita en el § 8). Todas las demás actividades automatizadas del § 8 son perfilado sin decisión exclusivamente automatizada de efecto significativo asociada. Detalles en el § 8.
Derecho a retirar el consentimiento (Art. 7 (3) RGPD) — cuando nos amparemos en su consentimiento, retírelo en cualquier momento sin que ello afecte a la licitud del tratamiento previo
Derecho a presentar una reclamación ante una autoridad de control (Art. 77 RGPD) — el Art. 77 (1) le ofrece tres foros alternativos: la autoridad de control de (i) su residencia habitual, (ii) su lugar de trabajo o (iii) el lugar de la supuesta infracción. Véase el § 15 más abajo para las autoridades competentes y el directorio de autoridades de control del EEE.

Para ejercer cualquiera de estos derechos, contacte privacy@uptimia.com. Bajo el Art. 12 (3) RGPD responderemos en el plazo de un mes desde la recepción de una solicitud completa, ampliable por hasta dos meses adicionales para solicitudes complejas o numerosas; cuando ampliemos, le informamos de la ampliación y de la razón dentro del primer mes, según exige el Art. 12 (3).

Vías operativas de cumplimiento.

Derecho de acceso (Art. 15 RGPD) y derecho a la portabilidad de los datos (Art. 20 RGPD) — exportación de datos de cuenta. Hasta que esté disponible el autoservicio, la exportación se genera y devuelve manualmente a petición por correo a privacy@uptimia.com. Internamente mantenemos un procedimiento operativo estándar (SOP) escrito para SAR (Subject Access Request) que apunta a un tiempo de entrega de trabajo de cinco (5) a diez (10) días hábiles para una cuenta normal, holgadamente dentro del techo legal de un mes del Art. 12 (3). La exportación se entrega como un único archivo ZIP que contiene archivos JSON estructurados por categoría de datos — perfil de cuenta, historial de facturación, configuraciones de monitor (las credenciales se muestran como huellas unidireccionales, nunca en texto plano; véase el § 12), resúmenes de resultados de comprobaciones, índice de correspondencia de soporte, registro de consentimiento de cookies — vía un enlace de descarga de tiempo limitado. Un endpoint autoservicio /api/v1/me/export está en el roadmap del producto; hasta que se entregue, el SOP manual es la garantía operativa.
Derecho de supresión (Art. 17 RGPD). La supresión de cuenta es autoservicio desde la página de Ajustes (con confirmación de contraseña) y desencadena la tarea programada de purga descrita en el § 11; los registros fiscales y contables sobreviven conforme al § 11 / § 147 AO / § 257 HGB. Cuando prefiera una gestión humana, escriba a privacy@uptimia.com.
Derecho de rectificación (Art. 16 RGPD). La mayoría de los campos de cuenta son editables por el usuario en la página de Ajustes; para campos no editables por el usuario (p. ej., el nombre de facturación en documentos fiscales ya emitidos), escriba a privacy@uptimia.com.
Derecho a la limitación (Art. 18 RGPD) y derecho de oposición (Art. 21 RGPD). Escriba a privacy@uptimia.com identificando el tratamiento que desea limitar u oponer. La oposición al marketing directo se procesa a la recepción sin razonamiento adicional (Art. 21 (2) y (3) RGPD).
Derecho a retirar el consentimiento (Art. 7 (3) RGPD). Para cookies, véase el § 9 (enlace «Preferencias de cookies», única vía de paridad conforme a las Directrices 05/2020 del CEPD § 117). Para cualquier otro tratamiento basado en consentimiento, escriba a privacy@uptimia.com.

Todas las solicitudes se tramitan gratuitamente. Cuando una solicitud sea manifiestamente infundada o excesiva, podremos cobrar un canon administrativo razonable o negarnos a actuar conforme al Art. 12 (5) RGPD.

Verificación de identidad. Nuestro enfoque de verificación de identidad es proporcionado a la solicitud, según exigen el Art. 12 (6) RGPD y las Directrices 01/2022 del CEPD sobre los derechos de los interesados — Derecho de acceso (§ 64 ss.). En el caso normal, verificamos la identidad confrontando la dirección remitente de su solicitud contra la dirección de correo registrada en su cuenta Uptimia y, para acciones realizadas desde dentro de la aplicación, confiando en su sesión autenticada (contraseña + 2FA cuando la haya habilitado). Cuando esta confrontación es suficiente para disipar la duda razonable, no solicitamos información adicional — pedir documentos de identidad en cada solicitud rutinaria vulneraría por sí mismo el principio de minimización del Art. 5 (1)(c) RGPD. Cuando tengamos duda razonable específica bajo el Art. 12 (6) RGPD — por ejemplo, cuando la solicitud llegue desde una dirección distinta a la registrada, cuando la cuenta haya cambiado recientemente de manos o se haya actualizado su correo de contacto, cuando la solicitud se refiera a categorías sensibles como registros de autenticación o señales de fraude en el pago, o cuando la acción solicitada sea irreversible (exportación completa de datos, supresión de cuenta) — podemos aplicar una o más comprobaciones proporcionales adicionales: confirmación desde la dirección de correo registrada, finalización de una acción desde el panel autenticado o un código de un solo uso entregado a través de su canal 2FA configurado. No pedimos documentos de identidad emitidos por las autoridades, copias de documentos de identidad ni verificación con «selfie» — esas medidas serían desproporcionadas para un producto B2B de observabilidad cuya vinculación de cuenta es a una dirección de correo electrónico, no a una identidad del mundo real, y son incompatibles con la advertencia de las Directrices 01/2022 del CEPD § 73 frente a la recogida rutinaria de documentos de identidad. Si tras las comprobaciones proporcionadas persiste duda razonable sobre su identidad, conforme al Art. 12 (6) RGPD, solicitaremos la mínima información adicional estrictamente necesaria para resolver esa duda, y le diremos exactamente qué estamos solicitando y por qué.

14. Privacidad de los menores

El Servicio no está dirigido a menores de 16 años, y no recopilamos a sabiendas datos personales de menores de 16 años. Si tenemos conocimiento de que hemos recopilado datos personales de un menor de 16 años sin el consentimiento verificable de los padres, los suprimiremos lo antes posible.

Aplicamos 16 años como nuestro suelo global para el tratamiento basado en consentimiento, con independencia de cualquier umbral nacional inferior bajo el Art. 8 (1) RGPD — y somos conscientes de que varios Estados miembros han ejercido el Wahlrecht del Art. 8 (1) a la baja, incluidos España en 14, Francia en 15 e Italia en 14. El suelo de «16 globalmente» es por tanto un estándar deliberado y autoimpuesto que es más protector que los umbrales nacionales mínimos aplicables en esos mercados, y aceptamos como política que somos auditables frente a él: si en algún momento empezáramos a dirigirnos directamente a alguno de esos mercados de umbral inferior, seguiríamos aplicando el suelo de 16 en lugar de descender al mínimo nacional, y cualquier cambio de esa postura sería en sí mismo un cambio material a esta Política divulgado bajo el § 17. Nuestro enfoque de verificación es proporcionado a un servicio que no está dirigido a menores, en el sentido contemplado por el Art. 8 (2) RGPD. No recopilamos fecha de nacimiento en el registro — Uptimia es un producto de observabilidad business-to-business, la superficie de registro está orientada a administradores técnicos (nombres de servidor, URL de monitor, canales de alerta) y pedir a cada titular de cuenta una fecha de nacimiento crearía por sí mismo un problema de minimización desproporcionado al riesgo. En su lugar nos amparamos en la combinación de: (i) el Servicio no está dirigido a menores, ni se comercializa a menores, ni está diseñado para menores; (ii) los titulares de cuenta se autoidentifican como personas usuarias profesionales por el acto de configurar monitores, aceptar suscripciones de pago o firmar las Condiciones del Servicio; (iii) cuando, sobre la base de una cuenta o de una interacción de soporte, tengamos duda razonable de que un titular de cuenta tiene menos de 16 años — por ejemplo, correspondencia de soporte que indique afirmativamente que la cuenta está operada por un menor — pedimos al titular de cuenta que confirme por escrito que tiene 16 años o más, y suprimimos la cuenta si no se obtiene confirmación. Este es el modelo de «servicio no dirigido a menores, con supresión por duda razonable» que el lenguaje de proporcionalidad del Art. 8 (2) RGPD contempla para servicios B2B.

Cuando despliega nuestro script RUM en un sitio web dirigido a menores, esa es su propia decisión bajo el Art. 8 RGPD y su propia responsabilidad como Responsable.

Padres, madres o tutores que crean que un menor ha enviado datos personales pueden contactar privacy@uptimia.com para su supresión inmediata.

15. Regímenes aplicables, autoridad de control principal y transferencias transfronterizas

Regímenes aplicables

RGPD UE. Como Responsable establecido en Alemania, el Reglamento (UE) 2016/679 aplica bajo el Art. 3 (1) a todo nuestro tratamiento con independencia de dónde se encuentre el interesado.
UK GDPR. No dirigimos nuestro Servicio a interesados en el Reino Unido. El análisis del ámbito territorial de las Directrices 3/2018 del CEPD § 2.1 / § 2.2 se basa en una lectura acumulativa de los marcadores nombrados — moneda, dominio de nivel superior, idioma como señal de país, mención de clientes locales, campañas de marketing específicas por país, teléfono o dirección locales dedicados, condiciones de entrega — y la conclusión se alcanza examinando los marcadores en conjunto, no descartando ninguno individualmente. En una lectura acumulativa de esos factores, ninguno apunta al Reino Unido: nuestros precios se listan en EUR (y, cuando aplica, USD), no en GBP; nuestro dominio es uptimia.com sin superficie .co.uk; no publicamos páginas de aterrizaje UK, ni casos de estudio UK, ni testimonios de clientes residentes en UK, ni campañas de marketing específicas para UK, ni publicidad geo-segmentada a UK; no realizamos SEO en idioma UK ni producción de contenido segmentada a UK; y el Sitio web se publica en inglés porque el inglés es el idioma controlante de nuestra documentación y producto (el inglés, según el análisis de las Directrices 3/2018, no es señal de país cuando no se empareja con ninguno de los otros marcadores anteriores). Sobre esos hechos consideramos que el Art. 3 (2)(a) UK GDPR no se activa: los interesados UK que se registran en el Servicio lo hacen alcanzando uptimia.com mediante búsqueda orgánica en idioma inglés y no porque les hayamos ofrecido el Servicio en el Reino Unido en el sentido del Art. 3 (2)(a). Tampoco «monitorizamos el comportamiento» de interesados UK en el sentido del Art. 3 (2)(b) — el script RUM que despliega el Responsable corre sobre los propios visitantes del Responsable en los propios sitios web del Responsable y se trata conforme a las instrucciones del Responsable, no dirigido por nosotros hacia ninguna población UK. Si pese a todo se considerara que el Art. 3 (2) UK GDPR aplica a registros incidentales UK, nuestro tratamiento también satisface la exención del Art. 27 (2)(a) UK GDPR como ocasional (sin operaciones UK estructuradas, sin actividad de captación UK, sin motion de customer-success UK) y de bajo riesgo (sin datos de categorías especiales, sin perfilado a gran escala, sin monitorización a escala de interesados UK). Reevaluaremos esta posición y nombraremos un representante UK si empezamos a dirigirnos al Reino Unido — por ejemplo añadiendo precios en GBP, un dominio o subdirectorio .co.uk, casos de estudio o testimonios UK, páginas de aterrizaje o comparación específicas UK, captación de pago geo-segmentada UK o producción de contenido en idioma UK. Los interesados UK que interactúen con el Servicio conservan su derecho legal a presentar una reclamación ante la Information Commissioner's Office (ICO) en https://ico.org.uk bajo el Art. 77 UK GDPR; cooperaremos con cualquier consulta de la ICO en cuanto a su fondo con independencia de nuestra posición sobre el ámbito territorial.
Otras jurisdicciones (CCPA / CPRA, LGPD, PIPL y regímenes extraterritoriales similares). Actualmente no tratamos datos personales de consumidores de California, interesados brasileños, interesados chinos u otros interesados no-EEE / no-Reino Unido / no-Suiza a una escala o en una configuración que active los umbrales para la aplicación extraterritorial de la California Consumer Privacy Act (en su redacción modificada por la California Privacy Rights Act), la Lei Geral de Proteção de Dados brasileña (LGPD), la Personal Information Protection Law china (PIPL) o regímenes de privacidad no-UE comparables. En particular, estamos por debajo de los umbrales de ingresos US y de consumidores de California para la aplicabilidad de la CCPA / CPRA bajo Cal. Civ. Code § 1798.140(d). Monitorizamos nuestra exposición bajo cada uno de estos regímenes según evolucione nuestra base de clientes y actualizaremos esta Política y designaremos representantes locales o agentes designados (p. ej., un agente de solicitudes verificadas US bajo el § 999.312 CCPA Regulations; un encarregado (DPO) bajo el Art. 41 LGPD — señalando que la propia LGPD no contiene equivalente al Art. 27 RGPD, y cualquier obligación de representación local en Brasil surgiría por separado bajo el derecho corporativo brasileño (en particular Art. 1.134 del Código Civil brasileño y Art. 146 § 2 de la Ley 6.404/1976), no bajo la LGPD como tal; un representante local PIPL bajo el Art. 53 PIPL) si y cuando se crucen los umbrales.
LPD suiza. Aplica bajo el Art. 3 (1) LPD cuando nuestras actividades tienen efecto en Suiza. El análisis de targeting aquí refleja la misma disciplina de lectura acumulativa aplicada arriba para el Reino Unido: la cuestión es si los factores nombrados de marcador de país, tomados en conjunto, apuntan a Suiza — no si cada factor individual puede descartarse por sí solo. En una lectura acumulativa, ninguno de ellos lo hace: no operamos un dominio .ch, ni precios en CHF, ni páginas de aterrizaje suizas, ni campañas segmentadas a Suiza; y el Sitio web se publica en inglés, no como señal de país suiza, sino como nuestro idioma controlante de documentación. El Art. 14 Abs. 1 LPD exige a un Responsable privado domiciliado en el extranjero designar un representante en Suiza cuando trate datos personales de personas en Suiza y el tratamiento cumpla acumulativamente cuatro condiciones: (a) el tratamiento esté relacionado con la oferta de bienes o servicios o con la observación del comportamiento de esas personas; (b) sea extenso (a gran escala); (c) sea regular; y (d) presente un alto riesgo para la personalidad de los interesados (hohes Risiko für die Persönlichkeit der betroffenen Personen). El umbral no se cumple en nuestros hechos: los interesados suizos que se registran en el Servicio alcanzan uptimia.com mediante búsqueda orgánica en idioma inglés de manera incidental a nuestras operaciones UE, no a través de una oferta suiza por nuestra parte — por lo que la condición (a) no se activa — y el volumen no es ni extenso dentro de la condición (b) ni regular dentro de la condición (c) según se entienden esos términos en la guía del FDPIC; tampoco consideramos cumplida la condición (d), pues el Servicio no presenta, sobre los hechos de nuestro tratamiento suizo incidental típico, un alto riesgo para la personalidad de los interesados. El incumplimiento de cualquiera de las cuatro condiciones acumulativas es suficiente por sí solo; sobre nuestros hechos las condiciones (a) a (d) fallan cada una independientemente. (Nótese que alto riesgo es tanto la condición de nombramiento de representante del Art. 14 Abs. 1(d) como, por separado, el desencadenante de una Evaluación de Impacto sobre la Protección de Datos bajo el Art. 22 LPD — son obligaciones independientes adheridas al mismo elemento fáctico, y tratamos el análisis EIPD del Art. 22 LPD por separado.) Reevaluaremos y nombraremos un representante suizo si empezamos a dirigirnos a Suiza (una superficie .ch, precios CHF, casos de estudio suizos, publicidad segmentada a Suiza) o si nuestro tratamiento suizo pasa a ser a gran escala y regular.

Autoridad de control principal

Nuestra autoridad de control principal bajo el mecanismo de ventanilla única del RGPD es la Berliner Beauftragte für Datenschutz und Informationsfreiheit (BlnBDI):

Alt-Moabit 59-61 10555 Berlín, Alemania Sitio web: https://www.datenschutz-berlin.de

Las personas residentes en el EEE pueden reclamar, a su elección bajo el Art. 77 (1) RGPD, ante la autoridad de control de (i) su residencia habitual, (ii) su lugar de trabajo o (iii) el lugar de la supuesta infracción — o ante la BlnBDI directamente como autoridad principal. El directorio de autoridades de control del EEE está en https://edpb.europa.eu. Las personas residentes en el Reino Unido pueden reclamar ante la Information Commissioner's Office (ICO) en ico.org.uk bajo el Art. 77 UK GDPR. Las personas residentes en Suiza pueden notificar al Federal Data Protection and Information Commissioner (FDPIC / EDÖB) en edoeb.admin.ch bajo el Art. 49 LPD. Las personas interesadas residentes en España pueden además presentar una reclamación ante la Agencia Española de Protección de Datos (AEPD) (Art. 77 RGPD), que se tramita en cooperación con la autoridad principal mediante el mecanismo de ventanilla única (Arts. 56 y 60 RGPD).

Resumen de la Evaluación del Interés Legítimo

Para cada finalidad basada en el Art. 6 (1)(f):

Señales de seguridad de cuenta (su IP de registro, su IP de inicio de sesión más reciente, su contador de intentos fallidos, su registro de auditoría de doble factor y una puntuación heurística interna de riesgo) — nuestro interés en proteger su cuenta frente a credential stuffing, ataques de fuerza bruta y abuso del registro, ponderado frente a la naturaleza limitada y vinculada a la cuenta de las señales; los intereses del interesado están protegidos por los controles de acceso y por el hecho de que los datos están vinculados a una relación contractual.
Mejora del servicio y operaciones de la red de sondas — tratamiento seudonimizado o agregado únicamente; sin perfilado individual.
Monitorización agregada de la calidad de medida del lado del servidor — sin identificación individual.
Comunicaciones de actualizaciones de producto a titulares de cuenta existentes (§ 7 Abs. 3 UWG Bestandskundenwerbung) — nuestro interés de retención en mantener informados a los clientes de pago sobre cambios de producto que afecten a lo que compraron, ponderado frente a la carga de marketing impuesta al destinatario. El cumplimiento de las cuatro condiciones acumulativas del § 7 Abs. 3 UWG se trata como salvaguardia principal: (i) la dirección recopilada en el contexto de la venta de nuestros bienes o servicios; (ii) el contenido limitado al marketing directo de nuestros propios productos y servicios similares; (iii) el destinatario no se ha opuesto; y (iv) el destinatario fue clara y conspicuamente informado (klar und deutlich) del derecho de oposición tanto en el punto de recopilación como en cada mensaje subsiguiente, sin costes superiores a las tarifas básicas de transmisión (Basistarif). La oposición bajo el Art. 21 RGPD es incondicional y se procesa a la recepción sin razonamiento adicional.
Respuestas a consultas de no clientes — responder a consultas entrantes de visitantes que nos contactan (preguntas de ventas, peticiones de partnership, preguntas de soporte fuera de una cuenta activa) se fundamenta en la expectativa razonable de que responderemos a la dirección que han utilizado para escribirnos.

Una LIA completa para cualquiera de estas actividades está disponible a petición en privacy@uptimia.com.

Decisiones automatizadas (Art. 22 RGPD)

Una decisión automatizada en el ámbito del Art. 22 (1) RGPD opera en el punto del cribado de fraude en el pago durante el checkout, descrita en el § 8. La puerta de entrada del Art. 22 (2) en la que nos apoyamos es principalmente Art. 22 (2)(b) RGPD — el marco SCA de la PSD2 (Directiva (UE) 2015/2366 leída con el Reglamento Delegado (UE) 2018/389 de la Comisión) y el marco AML/CTF citado en el § 8 constituyen Derecho de la Unión autorizador que exige precisamente las decisiones de monitorización de transacciones tomadas en el checkout y que por sí mismo establece salvaguardias adecuadas para el interesado; el Art. 22 (2)(a) RGPD (necesidad contractual) se activa únicamente como respaldo, coherentemente con la lectura estrecha del CEPD del «necesario para el contrato». Proporcionamos las salvaguardias del Art. 22 (3) RGPD en plenitud: un derecho significativo a la intervención humana por parte del equipo de revisión manual del procesador de pagos y por nuestra área de operaciones de facturación, un derecho a expresar su punto de vista, un derecho a impugnar el resultado y — añadido el 2026-05-27 — la divulgación a petición del Art. 22 (3) del código específico de motivo de rechazo y, cuando proceda, el nombre de la regla de Stripe Radar (véase el cuarto guion del Art. 22 (3) en el § 8). El contacto para cualquier solicitud de este tipo es privacy@uptimia.com; respondemos dentro del plazo del Art. 12 (3) RGPD. La puntuación heurística interna en su registro de usuario descrita en el § 8 es un input orientativo para la revisión humana, no una decisión automatizada.

Notificación de violación de la seguridad de los datos personales (Art. 33–34 RGPD)

En caso de una violación de la seguridad de los datos personales que entrañe un riesgo para sus derechos y libertades, notificaremos a la BlnBDI sin dilación indebida y, cuando sea posible, en un plazo de 72 horas tras tener conocimiento de la violación (Art. 33 RGPD). Cuando la violación entrañe un alto riesgo, también notificaremos a las personas usuarias afectadas sin dilación indebida bajo el Art. 34 RGPD.

Mecanismo de notificación. Correo electrónico directo a la dirección registrada en su cuenta, con un asunto que identifique el mensaje como notificación de violación de la seguridad de los datos personales del Art. 34 RGPD. Adicionalmente mostramos un aviso en producto en el panel autenticado en su siguiente sesión. Cuando la notificación directa supondría un esfuerzo desproporcionado bajo el Art. 34 (3)(c), emitiremos una comunicación pública en el Sitio web.

Transferencias internacionales de datos

Transferimos datos personales a destinatarios fuera del EEE únicamente como parte de la operación normal de los servicios de terceros enumerados en los §§ 5 y 7. Los siguientes destinos no-EEE están implicados:

Destino	Destinatario(s)	Mecanismo
EE. UU.	Stripe, Inc. (subprocesamiento Stripe); PayPal, Inc. (subprocesamiento PayPal); Amazon Web Services, Inc. (SES destinatarios no UE, red de sondas regiones no UE); DigitalOcean, LLC (red de sondas); Akamai Technologies, Inc. (red de sondas); Vultr Holdings, LLC (red de sondas); Contabo GmbH (red de sondas — regiones de sondas ubicadas en EE. UU.; la entidad contratante es Contabo GmbH en Múnich, el tratamiento ocurre físicamente en la infraestructura US de Contabo); Okta, Inc. (subprocesamiento Auth0); GitHub, Inc. (conexión social Auth0); Google LLC (subprocesamiento Web Risk, PageSpeed; conexión social Auth0); Mattermost, Inc. (alertas, si se configura); PagerDuty, Inc. (alertas, si se configura); Microsoft Corporation (subprocesamiento de alertas Teams, si se configura); Slack Technologies, LLC (Salesforce Group) (subprocesamiento de alertas Slack, si se configura); Discord, Inc. (subprocesamiento de alertas Discord, si se configura); X Corp. (alertas X, si se configura); Twilio, Inc. (subprocesamiento SMS); Meta Platforms, Inc. (subprocesamiento WhatsApp Cloud)	EU–US Data Privacy Framework (Decisión de Ejecución (UE) 2023/1795) cuando el destinatario esté certificado DPF, con CCT (Decisión de Ejecución (UE) 2021/914) mantenidas como respaldo automático. Vultr no está certificada DPF — CCT + la propiedad de tratamiento efímero en la capa de sondas (véase el § 5.3) son las medidas suplementarias invocadas. Contabo está contratada a través de su entidad UE (Contabo GmbH, Múnich), por lo que el análisis CCT aplica al tramo de tratamiento físico en regiones no-UE de Contabo; la misma propiedad de tratamiento efímero en la capa de sondas (Anexo B.6 del DPA) es la medida suplementaria invocada para regiones no-UE de Contabo. X Corp. no está actualmente certificada DPF — CCT + medidas suplementarias; solo se activa si configura X como canal de alerta.
EAU	Telegram FZ-LLC (alertas, solo si configura Telegram)	Sin decisión de adecuación para los EAU, y Telegram FZ-LLC no ofrece un mecanismo estándar de transferencia del Art. 46 RGPD (sin oferta publicada de CCT, sin plantilla de DPA, sin materiales de evaluación de impacto de la transferencia). Nos amparamos por tanto, como Responsable que inicia la transferencia cuando una alerta se despacha, en la derogación del Art. 49 (1)(b) RGPD — la transferencia es necesaria para la ejecución del contrato entre usted (titular de cuenta, como interesado) y Uptimia: al configurar Telegram como su canal de entrega de alertas elegido en los ajustes del canal de alertas, ha hecho de la entrega de la alerta a su chat de Telegram un elemento objetivamente necesario del servicio de monitorización que ha contratado. La base del Art. 49 (1)(b) cubre los datos personales propios del titular de cuenta (su ID de usuario Telegram, el ID del canal/bot que proporcionó, el payload de alerta dirigido a usted). Cuando enrute alertas a un grupo o canal de Telegram que incluya destinatarios que no sean partes en su contrato con Uptimia, esos destinatarios están fuera del alcance de la base del Art. 49 (1)(b) — utilice un acuerdo Responsable-a-Responsable propio (p. ej., obtenga el consentimiento explícito del Art. 49 (1)(a) de esos destinatarios antes de añadirlos, o enrute la alerta a través de un intermediario con el que tengan una relación establecida) y no se apoye en la cobertura del Art. 49 (1)(b) de Uptimia para ese tramo. Las medidas suplementarias que aplicamos por nuestro lado son cifrado en tránsito (HTTPS a la API de bots de Telegram), minimización del payload (el evento de alerta contiene únicamente metadatos del incidente — nombre del monitor, cambio de estado, marca temporal; no transmitimos datos personales de cliente final de sus visitantes), y el canal es opt-in (configurable on, configurable off). Coherentemente con las Directrices 2/2018 del CEPD sobre derogaciones del artículo 49 § III, tratamos la invocación del Art. 49 (1)(b) como ocasional y necesaria: se activa únicamente en cuentas que han configurado afirmativamente Telegram, los datos transferidos se minimizan a lo estrictamente requerido para la entrega de la alerta, y reconsideraremos la base si las alertas Telegram pasan a ser un flujo estructuralmente repetitivo para una cuenta dada más allá de lo necesario para ejecutar su contrato. Recomendado únicamente para paging del equipo de operaciones; no incluya en scripts datos personales de cliente final en payloads de alerta de Telegram.
Australia (con tratamiento ulterior en EE. UU.)	Atlassian Pty Ltd (alertas Statuspage y páginas de estado públicas, solo si configura Statuspage como canal de alerta o superficie de página de estado)	Sin decisión de adecuación para Australia. Statuspage la opera Atlassian sobre infraestructura US (AWS), por lo que surge una transferencia a EE. UU. en paralelo con la transferencia al Responsable australiano. Nos amparamos en el Data Processing Addendum publicado de Atlassian y en las CCT UE (Decisión de Ejecución (UE) 2021/914) cubriendo los flujos del Responsable australiano y del subencargado US, junto con la lista de Sub-Processors de Atlassian (que monitorizamos en cada revisión de política) para la cadena ulterior. Medidas suplementarias: TLS 1.2+ en cada alerta saliente / evento de página de estado, minimización del payload de alerta/página de estado a metadatos del incidente (una alerta o publicación en página de estado es estado del incidente, temporización y resumen; no se requieren datos personales de cliente final en un evento de Statuspage), y el canal / superficie de página de estado se activa únicamente bajo su configuración. Usted asume el análisis de riesgo del lado del Responsable por elegir Statuspage como canal de alerta o superficie pública de estado.

Para el régimen paralelo UK GDPR, aplicamos el UK International Data Transfer Agreement y el UK Addendum a las CCT UE (ICO marzo de 2022) para clientes UK incidentales. Para el régimen LPD suizo, aplicamos las CCT UE aprobadas por el FDPIC con el addendum específico suizo.

Se mantiene en archivo una Evaluación de Impacto de la Transferencia por destinatario para cada destinatario US y para la fila Atlassian (Australia + ulterior US). Copias disponibles en privacy@uptimia.com. La fila Telegram (EAU) no descansa en el Art. 46 RGPD — en su lugar descansa en la derogación del Art. 49 (1)(b) RGPD, con el alcance operativo expuesto en la tabla anterior. La invocación del Art. 49 se registra en una entrada del Art. 30 (1)(e) RGPD en nuestro registro de actividades de tratamiento (cuenta por cuenta, dado que la base se activa solo en cuentas que han configurado afirmativamente el canal) en lugar de en una TIA de mecanismo de transferencia, que es el formato de las Directrices 2/2018 del CEPD para la invocación del Art. 49.

Datación de versión del estado DPF. El estado de certificación DPF de cada destinatario US identificado arriba se verifica a la fecha de Last updated: de la cabecera de esta Política. Las certificaciones DPF pueden ser concedidas, suspendidas o retiradas entre revisiones de política — X Corp., por ejemplo, ha aparecido y desaparecido de la lista activa más de una vez desde que el marco entró en vigor bajo la Decisión de Ejecución (UE) 2023/1795. Volvemos a verificar la lista DPF en cada revisión de política; en el intervalo, las CCT (Decisión de Ejecución (UE) 2021/914) se mantienen como respaldo automático para cada destinatario US, con independencia del estado DPF actual, de modo que ninguna transferencia depende jamás únicamente de un estado que no acabemos de re-verificar. El módulo CCT seleccionado por destinatario, las medidas suplementarias y las copias de la Evaluación de Impacto de la Transferencia por destinatario están controlados por versiones internamente y se reemiten cuando cambian los hechos subyacentes.

Mecanismos de resolución de disputas DPF — sus derechos frente al destinatario. Los destinatarios certificados bajo el EU–US Data Privacy Framework están obligados, como condición de certificación, a cumplir con los Principios DPF, a proporcionar un mecanismo de recurso independiente sin coste para el interesado (cada organización certificada designa uno — habitualmente TRUSTe, BBB EU Privacy Shield, JAMS, AAA-ICDR, el panel de Autoridades UE de Protección de Datos para datos de RR. HH. u otro proveedor aprobado) y, como opción vinculante de último recurso, a participar en arbitraje vinculante ante el Panel DPF bajo el Anexo I de los Principios DPF. Están sujetos a las facultades de investigación y ejecución de la Federal Trade Commission de EE. UU. (o, para ciertos sectores, del Departamento de Transporte de EE. UU.), y a la supervisión del Departamento de Comercio de EE. UU. Puede invocar estas vías directamente contra el destinatario certificado si cree que ese destinatario ha incumplido sus compromisos DPF respecto de sus datos personales — habitualmente presentando primero una reclamación ante el destinatario, escalando luego al mecanismo de recurso independiente designado en el registro de certificación DPF del destinatario en https://www.dataprivacyframework.gov, y en última instancia remitiendo el asunto a la FTC o invocando el arbitraje del Panel DPF. El destinatario está obligado a identificar el mecanismo de recurso independiente aplicable en su propio aviso de privacidad y en su entrada de certificación DPF en dataprivacyframework.gov; recomendamos consultar la entrada de certificación del destinatario para la designación vigente. Nada en este párrafo desplaza su derecho a presentar una reclamación ante su autoridad de control UE/EEE competente bajo el Art. 77 RGPD ni a ejercer los recursos judiciales bajo los Arts. 78 y 79 RGPD — esos recursos permanecen disponibles en paralelo con las vías DPF.

Delegado de protección de datos

Hemos evaluado los criterios del Art. 37 (1) RGPD y del § 38 Abs. 1 BDSG. El § 38 Abs. 1 BDSG exige la designación de DPD sobre tres bases independientes: (a) la base de plantilla — 20 o más personas ocupadas de forma permanente en el tratamiento automatizado de datos personales (umbral elevado de 10 a 20 por la 2. DSAnpUG-EU de 20 de noviembre de 2019, en vigor desde el 26 de noviembre de 2019); (b) la base EIPD — tratamiento sujeto a una evaluación de impacto sobre la protección de datos bajo el Art. 35 RGPD con independencia de la plantilla; y (c) la base de transferencia comercial o investigación — tratamiento comercial de datos personales con el fin de transferencia, transferencia anonimizada o investigación de mercado u opinión, de nuevo con independencia de la plantilla. No cumplimos ninguna de las tres bases. Sobre (a), no alcanzamos el umbral de 20 personas. Sobre (b), nuestro tratamiento no está sujeto a una EIPD: no aparece en la lista del Art. 35 (4) de la BlnBDI de operaciones de tratamiento que requieren EIPD, y nuestra propia autoevaluación del Art. 35 (1) — pequeño servicio B2B de observabilidad, sin datos de categorías especiales como actividad principal, sin monitorización sistemática a gran escala de personas físicas en su vida privada, sin decisión automatizada con efectos jurídicos o significativos similares fuera del estrecho flujo de fraude en el pago descrito en el § 8 (que a su vez se autoriza bajo la puerta de entrada de Derecho de la Unión autorizador del Art. 22 (2)(b), con el Art. 22 (2)(a) únicamente como respaldo) — concluye que ninguna operación individual de tratamiento alcanza el desencadenante del Art. 35 (1) «entrañe probablemente un alto riesgo». Sobre (c), no tratamos comercialmente datos personales con el fin de transferencia a terceros, para transferencia anonimizada, o para investigación de mercado u opinión; el Servicio es una herramienta de observabilidad de pago, no un negocio de data-broker, de alquiler de listas o de panel de investigación. No estamos por tanto obligados a designar un DPD. Las cuestiones relativas a nuestro tratamiento de datos personales pueden dirigirse a privacy@uptimia.com; Andrius Gecius (Geschäftsführer) es el punto de contacto responsable.

16. Enlaces a otros sitios web

El Servicio puede contener enlaces a sitios web de terceros. No tenemos control y no asumimos responsabilidad alguna por las prácticas de privacidad o el contenido de esos sitios web. Le animamos a leer la política de privacidad de cualquier sitio web que visite.

17. Cambios en esta política

Podemos actualizar esta Política de Privacidad de vez en cuando. Cuando lo hagamos, actualizaremos la fecha de Last updated: en la parte superior de este documento y subiremos la versión. Para cambios materiales — en particular cualquier cambio que afecte a la base jurídica del tratamiento, a las categorías de destinatarios de sus datos personales o a las transferencias internacionales — le daremos aviso prominente (como una notificación por correo electrónico) con al menos 30 días de antelación a la entrada en vigor del cambio.

No pierde ningún derecho, ni concede ninguno nuevo, por continuar utilizando el Servicio.

18. Contacto

Para preguntas, inquietudes o para ejercer sus derechos bajo esta política, contacte con el Responsable identificado en el § 2:

JJ Online GmbH (que opera Uptimia)

Schönhauser Allee 163, 10435 Berlín

Alemania

Teléfono: +49 151 12032902

Correo — general: admin@uptimia.com

Correo — privacidad y solicitudes de los interesados: privacy@uptimia.com

Para asuntos del rol como Encargado del tratamiento (datos de sus visitantes / clientes finales que fluyen a través de Uptimia), véase el DPA.

#1. Introducción

#2. Responsable del tratamiento

#3. Información que recopilamos

#Datos de cuenta

#Datos de facturación

#Datos de autenticación y sesión

#Configuraciones de monitor que usted crea

#Resultados de comprobaciones

#Configuraciones de canales de notificación

#Datos de soporte

#Metadatos de petición del lado del servidor leídos en cada petición

#Si facilitar esta información es obligatorio (Art. 13 (2)(e) RGPD)

#Categorías especiales de datos personales (Art. 9 RGPD)

#4. Cómo utilizamos su información

#5. Servicios de terceros que utilizamos como Responsable del tratamiento

#5.1 Pagos y facturación

#5.2 Alojamiento e infraestructura central

#5.3 Red de sondas

#5.4 Autenticación

#5.5 Seguridad e inteligencia sobre amenazas

#5.6 Integraciones de páginas de marketing

#5.7 Servicios cruzados internos de JJ Online (mismo Responsable — no Subencargados del Art. 28)

#6. Otros destinatarios — fiscales, auditoría, jurídicos, M&A y solicitudes lícitas

#7. Uptimia como Encargado del tratamiento para los datos de sus visitantes / clientes finales

#8. Perfilado y decisiones automatizadas

#9. Consentimiento de cookies — otorgamiento y retirada

#10. Cookies

#11. Conservación de datos

#12. Seguridad de los datos

#13. Sus derechos

#14. Privacidad de los menores

#15. Regímenes aplicables, autoridad de control principal y transferencias transfronterizas

#Regímenes aplicables

#Autoridad de control principal

#Resumen de la Evaluación del Interés Legítimo

#Decisiones automatizadas (Art. 22 RGPD)

#Notificación de violación de la seguridad de los datos personales (Art. 33–34 RGPD)

#Transferencias internacionales de datos

#Delegado de protección de datos

#16. Enlaces a otros sitios web

#17. Cambios en esta política

#18. Contacto