Subprocessors

Under Article 28(2) of the GDPR (and the equivalent UK GDPR provision), a processor must obtain the controller's general or specific written authorisation before engaging another processor (a "sub-processor"), and must inform the controller of any intended changes concerning the addition or replacement of sub-processors so the controller has the opportunity to object. This page, together with the corresponding clause in our DPA, is how we satisfy that transparency obligation.

We also publish this list because we think customers deserve to know exactly which third parties touch their data. Email verification is a service customers entrust with their contact lists; opaque vendor stacks make that trust hard to grant. Listing every Subprocessor by name, function, data category, and location is the minimum we can offer in return.

The list below reflects the Subprocessors actually in use as of the "Last updated" date at the top of this page. If a vendor is not on this list, we are not using it. If we add a Subprocessor in future, we will update this page and follow the notification procedure in Section 4.

We use Subprocessors where doing so lets us provide a better, faster, or more secure Service than we could provide alone — for example, by using a specialist email delivery provider for transactional mail instead of operating our own outbound mail infrastructure, or by relying on a CDN with global edge presence rather than serving every static asset from a single VPS. The goal in each case is to delegate a narrow function to a vendor that does it better than we would, while keeping the data footprint as small as the function requires.

Before engaging a Subprocessor that will process Personal Data, we evaluate the vendor against our security and privacy standards. At minimum we look at: whether the vendor offers a written Data Processing Agreement that meets the Article 28 requirements; what regions it operates in and what transfer mechanisms it relies on for cross-border data flows; what security certifications or attestations it holds; what its breach notification commitments are; and whether the data it would receive can be minimised (for example, by sending hashed identifiers instead of raw email addresses, or by scrubbing payloads before they are transmitted).

Where the vendor publishes a Data Processing Agreement, we execute it. Where the vendor relies on Standard Contractual Clauses for international transfers, those Clauses form part of the agreement we have in place. We impose on each Subprocessor obligations substantially equivalent to those we owe our customers under the DPA, including with respect to confidentiality, security, breach notification, and onward transfer.

We give customers thirty (30) days' advance notice before any new Subprocessor begins processing Personal Data, via email to the address on file and via a banner in the dashboard. During that window, customers may object as described in Section 4.

The following Subprocessors are currently engaged. For each, we state the function the vendor performs, the categories of Personal Data the vendor may process, the region where processing primarily takes place, and a link to the vendor's DPA or equivalent privacy resource. Where a vendor is multi-region, we list the regions our deployment is configured for.

Webdock

Function: Virtual Private Server (VPS) hosting. Webdock hosts the KillBounce application servers, the self-hosted PostgreSQL database, the Redis cache, and the Celery worker tier that processes bulk verification jobs.

Data category: All customer data submitted to the Service, including uploaded email lists, per-row verification results, account records, and operational logs. Webdock is the primary place where customer data physically resides at rest.

Location: European Union (Webdock infrastructure is operated from the EU).

Reference: webdock.io/en/legal/privacy.

Vercel

Function: Frontend hosting and edge delivery. Vercel hosts the KillBounce dashboard and marketing site and serves them through its global edge network.

Data category: Page metadata, request headers, and IP addresses required to route and serve frontend assets. The dashboard makes API calls back to our application servers on Webdock for any operation involving customer email lists; Vercel does not receive uploaded lists or verification results.

Location: Global edge.

Reference: vercel.com/legal/dpa.

Cloudflare

Function: Content delivery network, web application firewall, bot protection, and DDoS mitigation in front of the dashboard and API.

Data category: IP addresses, request headers, cookies, and request metadata necessary to filter abusive traffic and accelerate delivery. Where a request carries customer email-list content (for example, an API call submitting addresses for verification), that content traverses Cloudflare in transit; it is not persisted by Cloudflare beyond the operational logging windows described in their DPA.

Location: Global edge.

Reference: cloudflare.com/cloudflare-customer-dpa/.

Dodo Payments

Function: Payments processor and merchant of record for credit purchases. Dodo Payments handles card processing, invoicing, and indirect-tax collection (GST, VAT, sales tax) where applicable.

Data category: Billing-related data only — name, billing address, email address, and the payment instrument details submitted to Dodo Payments at checkout. We do not see, store, or process raw card numbers; that data is handled inside Dodo Payments' PCI-DSS-scoped environment.

Location: As determined by Dodo Payments' processing footprint.

Reference: dodopayments.com/legal.

Resend

Function: Transactional email delivery. Resend sends account-related email on our behalf, including verification emails, password resets, receipts, job completion notifications, security alerts, and Subprocessor change notices.

Data category: Recipient email address (the customer's account email) and the content of the transactional email being sent. We do not route customer marketing or campaign mail through Resend; it is used exclusively for KillBounce's own service messages.

Location: United States and European Union.

Reference: resend.com/legal/dpa.

Sentry

Function: Application error and performance tracking. Sentry receives exception traces and performance traces from the dashboard, API, and worker tier so we can diagnose and fix bugs.

Data category: Error metadata, stack traces, and sanitised request and response payloads. We configure Sentry to scrub email addresses and other identifying fields from payloads before they leave our infrastructure; what reaches Sentry is the shape of the error, not the underlying recipient data.

Location: United States and European Union.

Reference: sentry.io/legal/dpa/.

PostHog

Function: Product analytics, used to understand how the dashboard is used in aggregate (which screens are visited, where users get stuck, which features are adopted). PostHog is used only where product analytics is enabled.

Data category: Pseudonymous event data tied to an opaque user identifier. We do not send uploaded list contents or per-row verification results to PostHog. Where IP-level data is captured, we configure PostHog to mask it where supported.

Location: United States and European Union.

Reference: posthog.com/dpa.

Google (OAuth)

Function: Federated authentication, only when a user chooses to sign in with Google. Google is not engaged for any other purpose.

Data category: Basic OAuth profile fields returned by Google during sign-in — name, email address, and the stable OAuth identifier we associate with the KillBounce account.

Location: Global.

Reference: policies.google.com/privacy.

GitHub (OAuth)

Function: Federated authentication, only when a user chooses to sign in with GitHub. GitHub is not engaged for any other purpose.

Data category: Basic OAuth profile fields returned by GitHub during sign-in — username, name, primary email address, and the stable OAuth identifier we associate with the KillBounce account.

Location: United States.

Reference: GitHub Data Protection Agreement.

When we intend to engage a new Subprocessor or replace an existing one, we will update this page and provide at least thirty (30) days' advance notice before the new Subprocessor begins processing Personal Data on our behalf. Notice will be given by email to the address on the account and by a banner in the dashboard. We will state the name of the proposed Subprocessor, the function it will perform, the categories of Personal Data involved, and the location where processing will take place.

You may object to a proposed Subprocessor during the notice period by emailing privacy@getkillbounce.com with a reasoned objection grounded in data protection concerns. If we are unable to address the objection through reasonable accommodation (for example, by choosing a different vendor for the same function or by configuring the engagement so the objection no longer applies), you may terminate your account and receive a pro-rata refund of any unused credit balance attributable to the period after termination. This is broader than the standard refund rule in our Terms of Service; we have chosen it because customers should not be locked into a Subprocessor relationship they cannot accept.

In rare cases — for example, where we need to add a Subprocessor on short notice to respond to a security incident, a vendor outage, or a regulatory requirement — we may add the Subprocessor with shorter notice. Where that happens, we will explain the circumstances in the notification and extend the objection window accordingly.

Each of the Subprocessors listed above operates its own infrastructure and may, in turn, engage its own subprocessors (for example, the cloud providers on which it runs, the email delivery upstreams it relies on, or specialist security and abuse-prevention services). Those onward engagements are governed by the relevant Subprocessor's own agreement with its sub-subprocessors and its own DPA with us.

We do not separately list sub-subprocessors here, because doing so would result in a deeply nested vendor tree that is impractical to maintain and that is already addressed by the contractual chain. Each Subprocessor is contractually required to flow down obligations substantially equivalent to those we owe our customers, and each publishes its own DPA and (where applicable) sub-processor list. The references in Section 3 link to the canonical version of each vendor's sub-processor disclosure.

If you need a more detailed accounting of sub-subprocessors for a particular vendor (for example, to satisfy your own audit or vendor-due-diligence requirements), email privacy@getkillbounce.com and we will help you locate the relevant disclosure.

Questions about this list, requests to receive notice of Subprocessor changes by an alternative channel, or objections to a proposed Subprocessor should be directed to privacy@getkillbounce.com. For broader data-protection questions, our Data Protection Officer can be reached at dpo@getkillbounce.com. For the contractual framework governing our processing of Personal Data, see our Data Processing Addendum; for our broader privacy practices, see our Privacy Policy.