Data Processing Agreement (DPA) — Statuo

Annex to the Terms and Conditions of Service — Rev. 4 — Last updated: 7 September 2026

Substantive revision: for Customers already registered it takes effect on 7 October 2026, the date stated in the e-mail notice (a full 30 days from 7 September 2026, as required by art. 3.2 of the Terms); until then Rev. 3.1 remains binding.

Courtesy translation. In case of any discrepancy, the Italian version prevails (statuo.io/dpa).

1. Parties and roles

This agreement (the "DPA") is entered into between the Customer (as defined in the Terms of Service), acting as data controller, and Apdsoftware of Carlo Zuffetti (apdsoftware.it), VAT IT03835250162 (the "Provider"), acting as data processor under art. 28 GDPR.

The DPA applies only to personal data the Provider processes on behalf of the Customer in supplying the Statuo Service. For the Customer's account data the Provider acts as an independent controller (see the Privacy Notice).

2. Subject matter, duration, nature and purpose of processing

• Subject matter: uptime monitoring of the Monitored Sites, sending of alerts, publication of status pages.
• Duration: equal to the duration of the Terms of Service, plus the post-termination retention period under art. 8.
• Nature: collection, recording, storage, consultation, transmission, erasure, in electronic and automated form.
• Purpose: exclusively the provision of the Service according to the configurations set by the Customer.

3. Categories of data subjects and data (Annex 1)

Data subjects: employees and collaborators of the Customer; the Customer's end users whose contact details are added as notification channels; persons whose data appears in the URLs or names of the Monitored Sites.

Categories of data: delivery details of the notification channels configured by the Customer (e-mail addresses, Telegram chat identifiers, Slack and Microsoft Teams webhook URLs — which identify the destination workspace and channel); names and URLs attributable to natural persons; technical check data (results, latencies, timestamps); the content of the alerts sent to the configured channels, which states the name of the Monitored Site and the details of the individual event (outage cause, duration, TLS certificate or domain expiry date). No special-category data (art. 9 GDPR) is required or envisaged by the Service; the Customer undertakes not to enter any.

4. Obligations of the Processor

The Provider undertakes to:

a) process data only on the Customer's documented instructions — instructions are deemed given through the configuration of the Service in the panel — save for legal obligations, in which case it will inform the Customer where permitted;

b) ensure that persons authorized to process the data are bound by confidentiality;

c) adopt the security measures under art. 32 GDPR, as described in Annex 2;

d) assist the Customer, taking into account the nature of the processing, in responding to data subjects' requests (arts. 15-22 GDPR) and with the obligations under arts. 32-36 GDPR, including — where requested — the information needed for impact assessments (DPIA) and prior consultations;

e) notify the Customer without undue delay, and in any event within 48 hours of becoming aware, of any personal data breach, providing the information useful for notification under art. 33 GDPR;

f) make available the information necessary to demonstrate compliance and allow, with reasonable notice of at least 30 days and at the Customer's expense, documentary verifications; any on-site audits are limited to once a year and conducted so as not to compromise the security of other customers.

4-bis. Obligations and warranties of the Controller

The Customer, as controller, warrants: (a) that it has an appropriate legal basis for the processing entrusted to the Provider; (b) that it has provided data subjects (including its own End Users) with the notices required by arts. 13-14 GDPR; (c) that the instructions given — including through the configuration of the Service — are lawful and do not place the Provider in breach of the GDPR or other rules; (d) that, where it enables a Slack or Microsoft Teams notification channel, it acts as an independent controller towards that provider and complies with the obligations listed in art. 5.4. The Customer shall hold the Provider harmless from the consequences of any breach of these warranties.

5. Sub-processors, recipients and sources

5.1. The Customer gives general authorization to the sub-processors listed in Annex 2. The Provider will give at least 15 days' notice of any addition or replacement; in case of reasoned objection, the Customer may withdraw from the Service without penalty.

5.2. The Provider imposes on each sub-processor, by contract, obligations equivalent to those of this DPA and remains liable towards the Customer for the sub-processors' performance.

5.3. The parties listed in Annex 2 under "Other recipients and sources" are not sub-processors, and arts. 5.1 and 5.2 do not apply to them:

a) Slack and Microsoft, for the Slack and Microsoft Teams channels. The channel is enabled by the Customer, who chooses its own workspace and pastes the webhook URL into the panel — that URL is the delivery credential for that workspace, and it belongs to the Customer. The Provider has no relationship, contractual or technical, with Slack or with Microsoft: it delivers the alert to the address the Customer has given it. Towards those providers it is the Customer that acts as an independent controller;

b) IANA/ICANN and the domain name registries. They operate public registers that the Provider queries to obtain a domain's expiry date and from which it receives an answer. They answer under their own policies and the law applicable to them, not on the Provider's instructions, and therefore act as independent controllers.

5.4. From the qualification under art. 5.3(a) the following follows, and it is for the Customer — not the Provider — to take it on:

a) the relationship with Slack or Microsoft rests with the Customer, including any data processing agreement and the basis for the transfer to the United States: the Provider has signed no agreement with them, does not impose on them the obligations under art. 5.2 and provides no Chapter V GDPR safeguards for this delivery. If the processing requires an agreement with that provider, it is for the Customer to have one;

b) the Customer lists that provider among the recipients in the notices it gives its own data subjects under arts. 13-14 GDPR;

c) the Customer ensures that the webhook provided belongs to a workspace at its disposal and that the members of the destination channel are entitled to see the content of the alerts;

d) once the alert has been delivered, the copy remaining in the workspace is no longer within the Provider's control: retention, access and deletion of that copy follow the relationship between the Customer and that provider. Art. 8 (deletion on termination) and the assistance under art. 4.d concern the Provider's systems, not the Customer's workspace. To stop delivery the Customer deletes the channel from the panel; to revoke the webhook it must act on Slack or Microsoft, where the Provider has no access;

e) the 15 days' notice and the right of objection under art. 5.1 do not operate for Slack and Microsoft, which are not sub-processors; it remains the case that the Provider is not liable for delays or failed deliveries attributable to those providers (Terms of Service, art. 8.3).

A Customer unwilling to take on the above may refrain from enabling the Slack and Teams channels and use the e-mail channel, delivered within the EU.

5.5. From the qualification under art. 5.3(b) it follows that the Provider cannot impose on IANA/ICANN or on the registries the obligations under art. 5.2, nor obtain the deletion of whatever they record of the query, and provides no Chapter V GDPR safeguards for these communications. The decision to query them, by contrast, is the Provider's, taken in order to supply the domain expiry check: the Customer may rule it out by switching that check off on the individual Monitored Site. The notice and right of objection under art. 5.1 do not apply to these parties either.

6. Transfers outside the EU

Data is processed predominantly on infrastructure within the European Economic Area (Hetzner in Germany for core and database, with continuous backups and a disaster-recovery standby on Google Cloud, always within the EU — Belgium). Exceptions: notification delivery via Telegram (enabled only at the Customer's choice); and execution of monitoring checks from Google Cloud's US location, which processes the URL and check outcome in memory only — even when a check includes a keyword match against the page, the content is read only for the comparison and never written to disk or logs — with no data storage on the non-EEA system. For these two cases the transfer is based on adequacy decisions (including the EU-US Data Privacy Framework, where applicable) or Standard Contractual Clauses.

A further exception is the Slack and Microsoft Teams notification channels, enabled only at the Customer's choice: if the Customer configures such a channel, the subject and body of the alert are transmitted to the webhook URL the Customer has provided — hooks.slack.com (Slack Technologies, Salesforce group, United States) or webhook.office.com / logic.azure.com (Microsoft). Neither the details of the other channels nor the history of the checks are transmitted. The recipient is the workspace chosen by the Customer, towards which it is the Customer that acts as an independent controller (art. 5.3(a)): the transfer to the United States is therefore governed by the relationship between the Customer and that provider, and not by safeguards given by the Provider, which has signed no agreement with Slack or Microsoft. What the Customer must do as a result is listed in art. 5.4. A Customer who prefers to avoid the transfer may refrain from enabling the Slack and Teams channels and use the e-mail channel, delivered within the EU.

Another exception is the issuance of TLS certificates for custom-domain status pages: if the Customer configures its own domain, the domain name alone is transmitted to Let's Encrypt (Internet Security Research Group, United States) to request the certificate. No contact details, no check data and no other personal data are transmitted; the domain name is in any case published in the public Certificate Transparency logs, as an inherent part of issuing a public certificate. A Customer who prefers to avoid this transfer may refrain from configuring a custom domain and use the standard status page address on the Provider's domain.

One further exception is the domain expiry check on Monitored Sites, enabled by default on the plans that include it and switchable off by the Customer on each individual Site: to obtain the expiry date, the domain name of the Monitored Site alone is queried against the registry responsible for that TLD. No contact details, no check data and no other personal data are transmitted. The channel depends on the TLD:

• where the registry publishes an RDAP service — all generic domains (.com, .net, .org, .shop, .cloud and the like) and some country-code domains — the query travels over HTTPS, encrypted; for generic domains the responsible registry is usually located outside the EEA;
• where the registry does not publish an RDAP service — .it first and foremost, but also many other European country-code domains — the Service falls back to the classic WHOIS protocol on port 43, which provides no encryption: the domain name therefore travels in clear text to the registry's server, which for .it is Registro.it's (IIT-CNR, Pisa), hence within the EEA. This is the single exception to the encryption in transit declared in Annex 2.

The list of registries offering RDAP is downloaded in full, over HTTPS, from IANA/ICANN (United States): that step transmits no Customer data. In the classic WHOIS case only, the TLD name (for example it) is sent to IANA to obtain the registry's server address — never the domain name of the Monitored Site. The registry's response is an extract from the public domain name register and may contain the data the registry itself publishes about the registrant: the Service retains only the technical data (registrar, dates, nameservers, status) and discards the rest.

IANA/ICANN and the registries are public sources the Provider queries and from which it receives an answer: they answer under their own policies, not on the Provider's instructions, and act as independent controllers (art. 5.3(b)). For these communications the Provider gives no Chapter V GDPR safeguards and is not in a position to obtain the deletion of whatever the registry records of the query (art. 5.5).

A Customer who prefers to avoid these communications may switch off the domain expiry check on the individual Monitored Site; the rest of the monitoring is unaffected.

7. Assistance and costs

Ordinary assistance under art. 4.d is included in the fee. Extraordinary, disproportionate or repetitive requests may be billed at an hourly rate communicated to the Customer in advance.

8. Termination and deletion

Upon termination of the Service, the Provider retains the data for 30 days to allow export from the panel, after which it permanently deletes it from active systems; backup copies are overwritten according to the rotation cycle within a further 30 days. Upon request, the Provider certifies deletion in writing.

9. Liability

Claims based on this DPA are subject to the limitation of liability under art. 9 of the Terms of Service, to the maximum extent permitted by law. Each party's liability towards data subjects under art. 82 GDPR, and the recourse regime provided therein, remain unaffected and cannot be contractually derogated.

10. Final provisions

For anything not provided herein, the Terms of Service apply. In case of conflict between the DPA and the Terms, the DPA prevails for data-protection matters. Italian law; Court of Bergamo.

Annex 1 — Details of processing

As per art. 3 of this DPA.

Annex 2 — Security measures, sub-processors, other recipients and sources

Technical and organizational measures (art. 32 GDPR):

• Encryption in transit (TLS 1.2+) on all communications, including probes. Single declared exception: the domain expiry check, where the responsible registry does not publish an RDAP service (as is the case for .it), falls back to the classic WHOIS protocol on port 43, which provides no encryption; in that case the domain name of the Monitored Site alone travels in clear text, and nothing else (art. 6). The Customer may switch off the domain expiry check on the individual Monitored Site.
• Authentication with hashed passwords (bcrypt) and signed tokens.
• Application-level multi-tenant isolation: every query is bound to the agency's identity.
• Internal endpoints not publicly exposed; server access exclusively via SSH keys; firewall with minimal ports.
• Daily encrypted backups with rotation and periodic restore testing.
• Automatic security updates on the infrastructure; system logs retained max 12 months.
• Minimization principle: the Service requires neither special categories of data nor end-user data beyond notification contact details.

Authorized sub-processors:

(Paddle is not a sub-processor: for payments it acts as an independent controller in its capacity as merchant of record.)

Other recipients and sources (not sub-processors — art. 5.3):

(This second table is not a list of sub-processors and the entries in it do not operate as general authorization under art. 5.1: they operate as information on the recipients of the alerts and on the sources the Service queries. Neither the 15 days' notice under art. 5.1 nor the obligation under art. 5.2 to impose equivalent obligations by contract applies to them.)

(Let's Encrypt (ISRG) remains in the first table because, unlike a domain name registry, it issues a certificate at the Provider's request: it performs an activity on the Provider's behalf, rather than answering a query against a public register it operates for its own purposes.)

Execution: the DPA is deemed accepted by the Customer upon acceptance of the Terms of Service at registration.