Acuerdo de Tratamiento de Datos (DPA) — Statuo

Anexo a los Términos y Condiciones del Servicio — Rev. 4 — Última actualización: 7 de septiembre de 2026

Revisión sustancial: para los Clientes ya registrados entra en vigor el 7 de octubre de 2026, fecha indicada en el preaviso por e-mail (30 días completos desde el 7 de septiembre de 2026, como exige el art. 3.2 de los Términos); hasta entonces sigue siendo vinculante la Rev. 3.1.

Traducción de cortesía. En caso de discrepancia, prevalece la versión italiana (statuo.io/dpa).

1. Partes y roles

El presente acuerdo (el "DPA") se celebra entre el Cliente (según se define en los Términos del Servicio), en calidad de responsable del tratamiento, y Apdsoftware de Carlo Zuffetti (apdsoftware.it), NIF-IVA IT03835250162 (el "Proveedor"), en calidad de encargado del tratamiento con arreglo al art. 28 del RGPD.

El DPA se aplica únicamente a los datos personales que el Proveedor trata por cuenta del Cliente en la prestación del Servicio Statuo. Para los datos de la cuenta del Cliente, el Proveedor actúa como responsable independiente (véase la Política de Privacidad).

2. Objeto, duración, naturaleza y finalidad del tratamiento

• Objeto: monitorización de uptime de los Sitios Monitorizados, envío de avisos, publicación de páginas de estado.
• Duración: igual a la duración de los Términos del Servicio, más el período de conservación posterior a la terminación previsto en el art. 8.
• Naturaleza: recogida, registro, conservación, consulta, transmisión, supresión, en forma electrónica y automatizada.
• Finalidad: exclusivamente la prestación del Servicio según las configuraciones establecidas por el Cliente.

3. Categorías de interesados y de datos (Anexo 1)

Interesados: empleados y colaboradores del Cliente; usuarios finales del Cliente cuyos datos de contacto se añadan como canales de notificación; personas cuyos datos aparezcan en las URL o en los nombres de los Sitios Monitorizados.

Categorías de datos: datos de destino de los canales de notificación configurados por el Cliente (direcciones de e-mail, identificadores de chat de Telegram, URL de los webhooks de Slack y Microsoft Teams — que identifican el espacio de trabajo y el canal de destino); denominaciones y URL atribuibles a personas físicas; datos técnicos de los controles (resultados, latencias, marcas de tiempo); el contenido de los avisos enviados a los canales configurados, que indica la denominación del Sitio Monitorizado y los datos del evento concreto (causa de la interrupción, duración, fecha de caducidad del certificado TLS o del dominio). El Servicio no requiere ni prevé datos de categorías especiales (art. 9 RGPD); el Cliente se compromete a no introducirlos.

4. Obligaciones del Encargado

El Proveedor se compromete a:

a) tratar los datos solo según instrucciones documentadas del Cliente — las instrucciones se consideran impartidas mediante la configuración del Servicio en el panel — salvo obligaciones legales, en cuyo caso informará al Cliente cuando esté permitido;

b) garantizar que las personas autorizadas al tratamiento estén vinculadas por la confidencialidad;

c) adoptar las medidas de seguridad del art. 32 del RGPD, descritas en el Anexo 2;

d) asistir al Cliente, teniendo en cuenta la naturaleza del tratamiento, en la respuesta a las solicitudes de los interesados (arts. 15-22 RGPD) y en las obligaciones de los arts. 32-36 RGPD, incluida — cuando se solicite — la información necesaria para las evaluaciones de impacto (EIPD) y las consultas previas;

e) notificar al Cliente sin dilación indebida, y en todo caso dentro de las 48 horas desde su conocimiento, toda violación de datos personales, facilitando la información útil para la notificación del art. 33 RGPD;

f) poner a disposición la información necesaria para demostrar la conformidad y permitir, con un preaviso razonable mínimo de 30 días y a cargo del Cliente, verificaciones documentales; las auditorías in situ se limitan a una al año y se realizan sin comprometer la seguridad de los demás clientes.

4-bis. Obligaciones y garantías del Responsable

El Cliente, como responsable del tratamiento, garantiza: (a) disponer de base jurídica idónea para los tratamientos encomendados al Proveedor; (b) haber facilitado a los interesados (incluidos sus propios Usuarios Finales) la información exigida por los arts. 13-14 RGPD; (c) que las instrucciones impartidas — también mediante la configuración del Servicio — son lícitas y no colocan al Proveedor en infracción del RGPD u otras normas; (d) que, cuando active un canal de notificación Slack o Microsoft Teams, actúa como responsable independiente frente a dicho proveedor y cumple las obligaciones enumeradas en el art. 5.4. El Cliente mantendrá indemne al Proveedor de las consecuencias del incumplimiento de dichas garantías.

5. Subencargados, destinatarios y fuentes

5.1. El Cliente autoriza con carácter general el recurso a los subencargados enumerados en el Anexo 2. El Proveedor comunicará con al menos 15 días de antelación toda incorporación o sustitución; en caso de oposición motivada, el Cliente podrá desistir del Servicio sin penalización.

5.2. El Proveedor impone a cada subencargado, por contrato, obligaciones equivalentes a las del presente DPA y sigue siendo responsable ante el Cliente de la actuación de los subencargados.

5.3. No son subencargados, y a ellos no se les aplican los arts. 5.1 y 5.2, los sujetos indicados en el Anexo 2 bajo "Otros destinatarios y fuentes":

a) Slack y Microsoft, para los canales Slack y Microsoft Teams. El canal lo activa el Cliente, que elige su propio espacio de trabajo y pega en el panel la URL del webhook — que es la credencial de entrega hacia dicho espacio de trabajo y pertenece al Cliente. El Proveedor no mantiene relación alguna, contractual o técnica, con Slack ni con Microsoft: entrega el aviso en la dirección que el Cliente le ha indicado. Frente a dichos proveedores es el Cliente quien actúa como responsable independiente;

b) IANA/ICANN y los registros de nombres de dominio. Son gestores de registros públicos que el Proveedor consulta para conocer la fecha de vencimiento de un dominio y de los que recibe una respuesta. Responden con arreglo a políticas propias y a la ley que les resulta aplicable, no a instrucciones del Proveedor, y actúan por tanto como responsables independientes.

5.4. De la calificación del art. 5.3, letra a), se deriva lo siguiente, de lo que debe hacerse cargo el Cliente y no el Proveedor:

a) la relación con Slack o Microsoft corresponde al Cliente, incluidos el eventual acuerdo de tratamiento de datos y el fundamento de la transferencia a Estados Unidos: el Proveedor no ha suscrito con ellos acuerdo alguno, no les impone las obligaciones del art. 5.2 y no presta garantías del Capítulo V del RGPD para esta entrega. Si el tratamiento exige un acuerdo con dicho proveedor, corresponde al Cliente tenerlo;

b) el Cliente indica a dicho proveedor entre los destinatarios en las informaciones que facilita a sus propios interesados con arreglo a los arts. 13-14 RGPD;

c) el Cliente se asegura de que el webhook indicado pertenezca a un espacio de trabajo del que dispone y de que los participantes del canal de destino estén legitimados para conocer el contenido de los avisos;

d) una vez entregado el aviso, la copia que permanece en el espacio de trabajo deja de estar a disposición del Proveedor: la conservación, los accesos y la supresión de esa copia siguen la relación entre el Cliente y dicho proveedor. El art. 8 (supresión al cesar el contrato) y la asistencia del art. 4.d se refieren a los sistemas del Proveedor, no al espacio de trabajo del Cliente. Para interrumpir la entrega, el Cliente elimina el canal del panel; para revocar el webhook debe actuar en Slack o Microsoft, donde el Proveedor no tiene acceso alguno;

e) el preaviso de 15 días y el derecho de oposición del art. 5.1 no operan respecto de Slack y Microsoft, que no son subencargados; queda a salvo que el Proveedor no responde de retrasos o entregas fallidas imputables a dichos proveedores (Términos del Servicio, art. 8.3).

El Cliente que no desee asumir lo anterior puede no activar los canales Slack y Teams y utilizar el canal de e-mail, entregado en la UE.

5.5. De la calificación del art. 5.3, letra b), se deriva que el Proveedor no puede imponer a IANA/ICANN ni a los registros las obligaciones del art. 5.2, ni obtener la supresión de lo que estos anoten de la consulta, y no presta garantías del Capítulo V del RGPD para estas comunicaciones. La decisión de consultarlos, en cambio, es del Proveedor, que la adopta para prestar el control de vencimiento del dominio: el Cliente puede excluirla desactivando dicho control en el Sitio Monitorizado concreto. Tampoco a estos sujetos les son aplicables el preaviso y el derecho de oposición del art. 5.1.

6. Transferencias fuera de la UE

Los datos se tratan predominantemente en infraestructura situada en el Espacio Económico Europeo (Hetzner en Alemania para el core y la base de datos, con copias de seguridad continuas y un standby de recuperación ante desastres en Google Cloud, siempre en territorio de la UE — Bélgica). Son excepciones: la entrega de notificaciones vía Telegram (activada solo por elección del Cliente); y la ejecución de los controles de monitorización desde la ubicación estadounidense de Google Cloud, que trata la URL y el resultado del control exclusivamente en memoria — incluso cuando un control incluye la verificación de una palabra clave en la página, el contenido se lee solo para la comparación y nunca se escribe en disco ni en los logs — sin conservación alguna de datos en el sistema fuera del EEE. Para estos dos casos la transferencia se basa en decisiones de adecuación (incluido el Data Privacy Framework UE-EE. UU., cuando sea aplicable) o en Cláusulas Contractuales Tipo.

Constituyen asimismo una excepción los canales de notificación Slack y Microsoft Teams, activados solo por elección del Cliente: si el Cliente configura un canal de este tipo, el asunto y el cuerpo del aviso se transmiten a la URL del webhook que el propio Cliente ha indicado — hooks.slack.com (Slack Technologies, grupo Salesforce, Estados Unidos) o webhook.office.com / logic.azure.com (Microsoft). No se transmiten ni los datos de contacto de los demás canales ni el historial de los controles. El destinatario es el espacio de trabajo elegido por el Cliente, frente al cual es el Cliente quien actúa como responsable independiente (art. 5.3, letra a): la transferencia a Estados Unidos se rige por tanto por la relación entre el Cliente y dicho proveedor, y no por garantías prestadas por el Proveedor, que no ha suscrito acuerdo alguno con Slack ni con Microsoft. Lo que el Cliente debe hacer en consecuencia se enumera en el art. 5.4. El Cliente que prefiera evitar la transferencia puede no activar los canales Slack y Teams y utilizar el canal de e-mail, entregado en la UE.

Constituye una excepción adicional la emisión de los certificados TLS para las páginas de estado con dominio personalizado: si el Cliente configura un dominio propio, se transmite únicamente el nombre de dominio a Let's Encrypt (Internet Security Research Group, Estados Unidos) para solicitar el certificado. No se transmiten datos de contacto, ni datos de los controles, ni ningún otro dato personal; el nombre de dominio, por la naturaleza misma de la emisión de un certificado público, se publica en cualquier caso en los registros públicos de Certificate Transparency. El Cliente que prefiera evitar esta transferencia puede no configurar un dominio personalizado y utilizar la dirección estándar de la página de estado en el dominio del Proveedor.

Constituye, por último, una excepción el control de vencimiento del dominio de los Sitios Monitorizados, activo de forma predeterminada en los planes que lo prevén y desactivable por el Cliente en cada Sitio concreto: para conocer la fecha de vencimiento, se consulta únicamente el nombre de dominio del Sitio Monitorizado ante el registro competente para ese TLD. No se transmiten datos de contacto, ni datos de los controles, ni ningún otro dato personal. El canal depende del TLD:

• allí donde el registro publica un servicio RDAP — todos los dominios genéricos (.com, .net, .org, .shop, .cloud y similares) y una parte de los dominios nacionales — la consulta viaja por HTTPS, cifrada; para los dominios genéricos, el registro competente suele encontrarse fuera del EEE;
• allí donde el registro no publica un servicio RDAP — en primer lugar .it, pero también muchos otros dominios nacionales europeos — el Servicio recurre al protocolo WHOIS clásico en el puerto 43, que no prevé cifrado: el nombre de dominio viaja por tanto en claro hasta el servidor del registro, que para los .it es el de Registro.it (IIT-CNR, Pisa), es decir, dentro del EEE. Es la única excepción al cifrado en tránsito declarado en el Anexo 2.

La lista de los registros dotados de RDAP se descarga íntegra, por HTTPS, de IANA/ICANN (Estados Unidos): ese paso no transmite dato alguno del Cliente. Únicamente en el caso del WHOIS clásico se envía a IANA el nombre del TLD (por ejemplo it) para que indique el servidor del registro — nunca el nombre de dominio del Sitio Monitorizado. La respuesta del registro es un extracto del registro público de nombres de dominio y puede contener los datos que el propio registro publica sobre el titular: el Servicio conserva solo los datos técnicos (registrador, fechas, servidores de nombres, estado) y descarta el resto.

IANA/ICANN y los registros son fuentes públicas que el Proveedor consulta y de las que recibe una respuesta: responden con arreglo a políticas propias, no a instrucciones del Proveedor, y actúan como responsables independientes (art. 5.3, letra b). Para estas comunicaciones el Proveedor no presta garantías del Capítulo V del RGPD ni está en condiciones de obtener la supresión de lo que el registro anote de la consulta (art. 5.5).

El Cliente que prefiera evitar estas comunicaciones puede desactivar el control de vencimiento del dominio en el Sitio Monitorizado concreto; el resto de la monitorización no se ve afectado.

7. Asistencia y costes

La asistencia ordinaria del art. 4.d está incluida en la cuota. Las solicitudes extraordinarias, desproporcionadas o repetitivas podrán facturarse a una tarifa horaria comunicada previamente al Cliente.

8. Terminación y supresión

Al cesar el Servicio, el Proveedor conserva los datos durante 30 días para permitir su exportación desde el panel, tras lo cual los suprime definitivamente de los sistemas activos; las copias de seguridad se sobrescriben según el ciclo de rotación dentro de otros 30 días. A petición, el Proveedor certifica por escrito la supresión.

9. Responsabilidad

A las reclamaciones basadas en el presente DPA se aplica la limitación de responsabilidad del art. 9 de los Términos del Servicio, en la máxima medida permitida por la ley. Queda a salvo la responsabilidad de cada parte frente a los interesados conforme al art. 82 RGPD, así como el régimen de repetición allí previsto, no derogables contractualmente.

10. Disposiciones finales

Para lo no previsto, se remite a los Términos del Servicio. En caso de conflicto entre el DPA y los Términos, prevalece el DPA en las materias de protección de datos. Ley italiana; Tribunal de Bérgamo.

Anexo 1 — Detalles del tratamiento

Según el art. 3 del presente DPA.

Anexo 2 — Medidas de seguridad, subencargados, otros destinatarios y fuentes

Medidas técnicas y organizativas (art. 32 RGPD):

• Cifrado en tránsito (TLS 1.2+) en todas las comunicaciones, incluidas las sondas. Única excepción declarada: el control de vencimiento del dominio, allí donde el registro competente no publica un servicio RDAP (es el caso de .it), recurre al protocolo WHOIS clásico en el puerto 43, que no prevé cifrado; en ese caso viaja en claro únicamente el nombre de dominio del Sitio Monitorizado, y nada más (art. 6). El Cliente puede desactivar el control de vencimiento del dominio en el Sitio Monitorizado concreto.
• Autenticación con contraseñas con hashing (bcrypt) y tokens firmados.
• Aislamiento multi-tenant a nivel de aplicación: cada consulta está vinculada a la identidad de la agencia.
• Endpoints internos no expuestos públicamente; acceso a los servidores exclusivamente mediante claves SSH; firewall con puertos mínimos.
• Copias de seguridad diarias cifradas con rotación y pruebas periódicas de restauración.
• Actualizaciones de seguridad automáticas en la infraestructura; registros de sistema conservados máx. 12 meses.
• Principio de minimización: el Servicio no requiere categorías especiales de datos ni datos de usuarios finales más allá de los contactos de notificación.

Subencargados autorizados:

(Paddle no es subencargado: para los pagos actúa como responsable independiente en su calidad de merchant of record.)

Otros destinatarios y fuentes (no subencargados — art. 5.3):

(Esta segunda tabla no es una lista de subencargados y su mención no vale como autorización general con arreglo al art. 5.1: vale como información sobre los destinatarios de los avisos y sobre las fuentes que el Servicio consulta. No operan por tanto ni el preaviso de 15 días del art. 5.1 ni la obligación del art. 5.2 de imponer por contrato obligaciones equivalentes.)

(Let's Encrypt (ISRG) permanece en cambio en la primera tabla porque, a diferencia de un registro de nombres de dominio, emite un certificado a solicitud del Proveedor: desarrolla una actividad por cuenta suya, no responde a una consulta sobre un registro público que gestiona con fines propios.)

Suscripción: el DPA se entiende aceptado por el Cliente junto con la aceptación de los Términos del Servicio en el momento del registro.