Version 1.0. Effective [[VERIFY: set this to the calendar date this page actually goes live, on the day of the deploy, and set the matching row in the changelog table at the foot of this page to the same date. This is deliberately NOT pre-filled. The 14-day subprocessor notice period in DPA section 6.5 runs from this date, so a date guessed in advance either starts the clock before the list is public or backdates a contractual notice. It is the one placeholder on this page that a deploy cannot resolve by itself.]]
How to read this page
Not every third party we work with is a subprocessor of your data, and treating them as one flat list would be misleading in both directions. We separate them into four groups.
- Group A: infrastructure subprocessors, engaged for every customer. These process personal data on your behalf whenever you use the Services. You cannot switch them off while remaining a customer. Section 6 of the DPA applies to all of them.
- Group B: integrations you switch on. These only receive data if you configure them. Some are subprocessors of ours because we hold the relationship with the vendor; others are recipients you choose and contract with yourself, where we cannot bind the vendor to processing terms. The distinction is stated for each entry and it matters, because it decides who is accountable for that vendor.
- Group C: website and corporate vendors. These touch our marketing website, our documentation site or our internal operations. They receive no customer product data. We list them because you are entitled to know who sees your data when you visit our site, not because they are subprocessors under the DPA.
- Group D: authorised for outbound mail but not in use for it. Neither of these sends any Site Qwality mail today, and we list them anyway because the wiring exists: each is authenticated on our sending domain or holds a live credential, so activating one would be a configuration change rather than a release. Naming them is the only way the 14-day notice in section 6.5 of the DPA can mean anything for a change that needs no deploy. Read the entries: one of the two does receive mail today, on the inbound side.
Group A: infrastructure subprocessors, engaged for every customer
| Vendor | What it does for us | Personal data it receives | Processing location |
|---|---|---|---|
| Amazon Web Services, Inc. | All compute, storage, database, queueing, content delivery, scheduling, outbound email and outbound SMS. | Everything the product holds: account and user records, monitor configuration including any credentials you configure on a check, check results, logs, metrics, traces, real user monitoring, session replay recordings, notification content and recipient addresses, and end-user IP addresses in the ingest gateway access logs. | United States (us-east-1) for all storage and all serverless compute. Content delivery serves from edge locations that include Europe; we do not enable access logging on those distributions. |
| Stripe, Inc. | Payment processing, subscription billing and card capture. | Customer name and email address, our account identifier, subscription and invoice records, and an affiliate referral identifier where present. Card details are entered directly into a Stripe-hosted element on Stripe’s own origin and are never seen by us. | United States |
| Stytch, Inc. | Authentication and identity: organizations, members, sessions, passwords, magic links, OAuth brokering for Google and GitHub, time-based codes, passkeys, SAML single sign-on, SCIM provisioning and machine-to-machine clients. Stytch also sends the magic-link and email-verification messages. | User email address, name, dashboard roles, session data, multi-factor factors (time-based-code secrets and passkey credentials), OAuth registrations, password credentials. | United States |
| Cloudflare, Inc. (Turnstile) | Bot mitigation on signup. Mandatory on email signup, optional on the social signup routes. | The signup visitor’s IP address and browser challenge signals, sent by the browser to Cloudflare and then verified by us server-side. | United States and the Cloudflare global network |
| Google LLC (PageSpeed Insights API) | Page-speed monitoring. Google fetches and renders the monitored URL on our request. | Every URL submitted for a page-speed check. A URL can itself carry personal data in its path or query string. | United States and the Google global network |
| Whoxy | WHOIS lookups backing domain-expiry monitoring. | Every monitored domain is sent. The response contains third-party registrant name, postal address, email address and phone number. | [[VERIFY: Whoxy processing location and legal entity]] |
| WhoisXML API, Inc. | Second WHOIS source for domain-expiry monitoring. | Same as Whoxy: the monitored domain out, a third-party registrant contact block back. | [[VERIFY: WhoisXML API processing location and legal entity]] |
| Zoho Corporation (Zoho Mail) | Inbound mail for every Site Qwality address, including support and the privacy contact. | Everything a person writes to us, plus the in-app support message body and the requester’s IP address, which is included in the support email. | [[VERIFY: which Zoho region hosts the siteqwality.com mailbox (zoho.com vs zoho.eu), since this determines whether inbound rights requests are processed in the US, the EU or India]] |
| Slack Technologies (Salesforce, Inc.): internal error alerting | Our own internal alerting. Application log lines at error level are posted to an internal channel. | Raw application log content. That can include a user email address bound to the request that failed, a monitored URL, or a monitored domain. | United States |
Outbound email and outbound SMS are sent through AWS, which is why no separate email vendor appears in this group. Two other email vendors are authorised on our sending domain without sending anything for us; they are in Group D, and one of them receives inbound mail addressed to that domain.
Group B: integrations you switch on
These receive data only if you configure them. The middle column is the part worth reading: it says whether we can bind the vendor to data protection terms on your behalf.
| Vendor | Our role | What it receives |
|---|---|---|
| Telegram Messenger | Subprocessor of ours. The bot that delivers your alerts is a Site Qwality bot using our token; you supply only a numeric chat id. We hold the relationship with Telegram, so we treat this as our subprocessing. | Alert content, which can name monitored hosts, incident detail and the people involved, delivered into a chat our bot has joined. [[VERIFY: Telegram processing location and legal entity for bot API traffic]] |
| Slack Technologies (Salesforce, Inc.): your workspace | Subprocessor of ours. We operate the Slack app; you install it into your own workspace through OAuth. We hold the app relationship, so we treat this as our subprocessing. | Alert content posted into your workspace. Processing location: United States. |
| PagerDuty, Inc. | Not our subprocessor. You choose the vendor, you hold the account, you supply the routing key and you can revoke it unilaterally. We have no contract with PagerDuty and cannot bind it to Article 28(3) terms on your behalf. | The alert payload, naming the monitor, the incident and its detail. Processing location is determined by your own PagerDuty account. |
| Atlassian (OpsGenie) | Not our subprocessor. Same reasoning as PagerDuty. | The alert payload. Processing location is determined by your own OpsGenie account. |
| Discord Inc. | Not our subprocessor. You create the webhook and paste in the URL, which is itself the credential. | The alert payload. Processing location is determined by your own Discord workspace. |
| Microsoft Corporation (Teams) | Not our subprocessor. You create the webhook. | The alert payload as an adaptive card. Processing location is determined by your own Microsoft tenant. |
| Google LLC (Google Chat) | Not our subprocessor. You create the webhook. | The alert payload. Processing location is determined by your own Google Workspace. |
| Mattermost, Inc. or a self-hosted Mattermost | Not our subprocessor. You create the webhook, and the instance is frequently one you run yourself. | The alert payload. Processing location is determined by you. |
| Pushover | Not our subprocessor. You hold the account and supply the credential. | The alert payload. Processing location is determined by your own Pushover account. |
| Pushbullet | Not our subprocessor. You hold the account and supply the credential. | The alert payload. Processing location is determined by your own Pushbullet account. |
| Any HTTP endpoint you supply | Not our subprocessor. The destination is entirely your choice and cannot be enumerated in advance. | The alert payload. Processing location is determined by you. |
Group C: website and corporate vendors
These do not receive customer product data. They are listed for transparency about our own site and operations.
| Vendor | What it does | What it receives | Processing location |
|---|---|---|---|
| Hostinger | Hosting for siteqwality.com, siteqwality.de and siteqwality.it. | Every marketing-site visitor’s IP address and request. No customer product data. | [[VERIFY: which Hostinger datacentre serves the marketing site, and Hostinger’s contracting entity]] |
| Netlify, Inc. | Hosting for docs.siteqwality.com. | Documentation-site request data and access logs. No customer product data. | [[VERIFY: Netlify processing location for docs.siteqwality.com]] |
| Google LLC (Analytics 4 and Google Ads) | Marketing analytics and advertising conversion measurement on the marketing site. | Visitor identifiers, IP address, page URL, referrer, and a conversion event on every “Start free” call to action. No customer product data. | United States and the Google global network |
| Microsoft Corporation (Clarity) | Session recording and heatmaps of every marketing page, on all three of our domains. | A full interaction recording of marketing-site visitors. No customer product data and no authenticated dashboard content. | United States and the Microsoft global network |
| PromoteKit | Affiliate and referral attribution. Loads on the marketing site and on the authenticated dashboard, and the referral identifier is mirrored into the payment processor’s customer record at signup. | A referral identifier tied to a visitor and subsequently to a paying customer. It does not receive monitoring, log, real user monitoring or replay data. | [[VERIFY: PromoteKit legal entity and processing location]] |
| theemaildelivery.com | Hosts the entire public contact form. On our contact pages it sits behind a click-to-load placeholder, so this vendor is contacted only once a visitor asks for the form. | Nothing at all unless a visitor presses the load button. After that: name, email address and free-text message of anyone who uses the form, plus their IP address, which this vendor receives the moment the frame loads rather than at submission. Field names, submission endpoint, storage and retention are under its control, and being a cross-origin frame it can also set its own cookies. | [[VERIFY: theemaildelivery.com legal entity and processing location]] |
| GitHub, Inc. | Source hosting for most of our repositories, including the infrastructure repository and the browser SDK. Three repositories have no remote at all and exist only on a company machine, so GitHub does not hold them: our marketing website, one ingest service and an internal scripts directory. Separately, GitHub is an identity provider an individual may choose at sign-in, brokered through Stytch rather than by us directly. | Commit author identities. No customer product data. | United States |
| Freshworks | Authenticated to send email as our domain. [[FOUNDER INPUT: whether Freshworks is actively used to email prospects or customers, on what legal basis, and in which tenant region. DNS authorisation exists on the root domain; no code integrates with it.]] | If in use, prospect and customer contact data and email engagement events. | [[FOUNDER INPUT: Freshworks tenant region]] |
| Ahrefs and Google Search Console | Site-verification records only. No data flows to them from any Site Qwality system. | None beyond the aggregate search performance data the provider already holds. | Not applicable |
[[VERIFY: confirm that the removal of LogRocket from the authenticated dashboard has shipped to production before this page is deployed. This page does not list LogRocket, and publishing it while the dashboard still loads LogRocket would make the list incomplete.]]
Nothing is missing from this page because it sits outside the code. The vendors above were derived from the code, the infrastructure and the DNS records, which is a method that cannot see a service nobody integrated. So we checked the categories that typically leave no trace in a repository: accounting, CRM, HR, e-signature, password manager and ticketing. None of them holds customer or employee personal data for us, and none of them is therefore listed above. The set on this page is the complete set of vendors that receive personal data in connection with the Services.
Group D: authorised for outbound mail but not in use for it
Both are email vendors authenticated on notifications.siteqwality.com, the subdomain our alert mail is sent from, and each could be switched on for sending by a configuration change rather than a release, so we would rather name them here than leave you to discover them in a DNS record. If either is ever activated for sending, that appears in the changelog first, with 14 days’ notice before it takes effect.
One of the two is not dormant. Mailgun operates the inbound mail exchangers for that same subdomain, so it receives mail today even though it sends none. The row below says so; an earlier draft of this page said “neither receives anything”, which was wrong.
| Vendor | What is wired | Personal data it receives | Processing location |
|---|---|---|---|
| Twilio Inc. (SendGrid) | Authenticated on our sending domain, and the sending code path is compiled into our mail service and selectable by a single configuration value. Outbound email is sent through AWS instead. | None today. If the provider were switched it would receive every alert email recipient address and message body. | United States |
| Mailgun Technologies, Inc. | Two things, and only the first is dormant. Outbound: authenticated on our sending domain by SPF and DKIM, with an API credential still configured on our mail service. No code reads that credential, so we send nothing through Mailgun. Inbound: the mail-exchange records for notifications.siteqwality.com point at mxa.mailgun.org and mxb.mailgun.org, and that subdomain is the From address of every alert email we send. Mail sent to that address is therefore delivered to Mailgun, not to us. |
Inbound mail addressed to our alert-sending domain. In practice that is replies to an alert, out-of-office auto-responders, and bounce or rejection notices misdirected to the From address instead of the return path. Such a message can contain the sender’s address, their signature and whatever they quoted from the alert, which can include a monitored host name and incident detail. We do not read this mailbox; we are disclosing that the mail arrives, not that we act on it. | [[VERIFY: Mailgun processing region and contracting entity. This is now a live inbound flow rather than dormant wiring, so the region matters for a transfer analysis and not only for completeness.]] |
Mailgun is marked for decommissioning in our infrastructure code, meaning the credential is to be revoked and the DNS records removed, including the mail-exchange records that currently route inbound mail to it. That has not happened yet. SendGrid carries no such marker; its authentication records are simply still in place. When either changes, it will be recorded in the changelog below.
Changelog
Every addition, replacement or removal is recorded here with the date it takes effect. Section 6.5 of the Data Processing Addendum gives you 14 days’ notice and a right to object.
| Effective | Version | Change |
|---|---|---|
| [[FOUNDER INPUT: publication date]] | 1.0 | First published as a standalone, versioned page. Replaces the four-vendor list previously embedded in section 6.2 of the Data Processing Addendum, which was materially incomplete and which named SendGrid as an active email provider when outbound email is sent through AWS SES. SendGrid and Mailgun are recorded here in Group D, authorised on the sending domain but sending nothing; Mailgun additionally receives inbound mail addressed to that domain, and its row says so. |
Questions or objections
Write to privacy@siteqwality.com. If you object to a new subprocessor on reasonable data protection grounds and we cannot resolve it, you may terminate the affected Services under the Agreement.