Subprocessors

This document has two separate parts, and they are deliberately not merged.

Part 1, the Subprocessor Register, lists the providers Nucleus HQ itself engages to run the platform. Nucleus HQ chooses these providers, contracts with them, and instructs them.

Part 2, the Customer-Enabled Integrations Schedule, lists providers a customer can choose to connect using the customer's own account. The customer is the controller of the data sent to that provider. For most of them the customer also supplies their own credentials, and Nucleus HQ has no relationship with the provider at all. Google Calendar is the exception, because Nucleus HQ operates the OAuth application through which the customer connects. Two providers, Cloudflare and Resend, appear in both parts: Part 1 covers the platform's own use of them, and Part 2 covers a customer supplying their own Turnstile keys or their own Resend sending key, which runs on the customer's account rather than Nucleus HQ's. Part 2 sets out the differences. Nothing in Part 2 is a Nucleus HQ subprocessor relationship.

Nucleus HQ keeps both parts current. A provider is not published in Part 1 unless it is actually used in production.

Part 1. Subprocessor Register

These four providers, and no others, are engaged by Nucleus HQ as subprocessors, meaning they process customer personal data on Nucleus HQ's instructions. Nucleus HQ separately operates an OAuth application with Google for the optional Google Calendar integration. That is not a subprocessor relationship and it is described in Part 2.

What each provider does, in plain terms

Contabo

Contabo provides the servers that run Nucleus HQ. The application, the PostgreSQL master database and the per-tenant databases, the system journal, and local backup staging all sit on that infrastructure. Because it hosts the databases, Contabo can technically hold every category of master and tenant data described in the Privacy Policy, together with request logs.

Where your data is stored. Nucleus HQ's servers are located in the United Kingdom, in a data centre in Portsmouth.

Who we contract with. The hosting provider is Contabo GmbH, Welfenstrasse 22, 81541 Munich, Germany (registered at the Local Court of Munich, HRB 180722). Nucleus HQ has concluded a signed written data processing agreement with Contabo GmbH under Article 28, concluded on 14 July 2026.

Who operates the data centre. Under that agreement, Contabo GmbH engages Contabo UK Ltd, 7 Bell Yard, London WC2A 2JR, United Kingdom, as its sub-processor for the operation of the Portsmouth data centre.

Transfers. Your data is stored in the United Kingdom and the data centre is operated by a United Kingdom company. Contabo GmbH is established in Germany, so its personnel may access the systems in order to provide and support the service. Germany is within the European Economic Area, and the United Kingdom recognises the EEA as providing an adequate level of data protection, so this access does not require Standard Contractual Clauses.

Backups. In addition to the encrypted backups Nucleus HQ takes and stores in Cloudflare R2, Contabo's own automated server backup is enabled. This means Contabo holds its own copies of the server, including the databases. The period Contabo keeps those copies for is set by Contabo, not by Nucleus HQ: Contabo keeps a rolling set of the ten most recent daily backups, so approximately the last ten days. Because these are whole-server images, they include our databases. This means that when data is deleted from the live system, a copy can persist in Contabo's own server backups for up to about ten days before it ages out.

Cloudflare

Cloudflare does two distinct jobs.

• Network and security. DNS, TLS, WAF and routing. Turnstile bot verification on public forms, which receives a Turnstile token and request verification data.
• Object storage. Cloudflare R2 is where uploaded tenant files are stored, and where encrypted database backups are stored. File metadata lives in the tenant database. The file objects themselves live in R2. Encrypted backup archives are held in R2 as well.

If a customer uploads a file to Nucleus HQ, the file object goes to Cloudflare R2. The same is true where the uploader is not the customer: if a customer publishes a form with a file upload question and a visitor attaches a file to it, that file object also goes to Cloudflare R2.

Where a customer supplies their own Turnstile keys for their forms, that verification runs on the customer's own Cloudflare account and is described in Part 2. Turnstile widgets Nucleus HQ provisions automatically for a customer's domain are created under Nucleus HQ's own Cloudflare account and stay within this Part 1 relationship.

Stripe

Stripe handles payments. Its role is wider than subscription checkout alone. Stripe is used for:

• Subscription checkout and the billing portal.
• Stripe Connect commerce, including paid bookings, paid courses, product purchases, and payments a customer takes through a form it publishes, all sold or collected by a customer from that customer's own buyers and respondents.
• Communications wallet off-session top-ups and auto-reload.
• The usage ledger, together with webhook and billing identifiers.

Stripe can therefore receive billing identifiers, customer and subscription identifiers, checkout and connected-account data, and payment status.

No card number, expiry date or CVC ever reaches Nucleus HQ. Card details are entered directly with Stripe on Stripe-hosted surfaces. Nucleus HQ does not receive, store or process them, and it does not store card last four digits or expiry dates either.

Resend

Resend sends email. Its role is wider than transactional email and invites alone. Resend is used for:

• Platform and tenant transactional email.
• Workspace invites.
• Nucleus HQ website enquiry notifications.
• Course purchase and learner access email, including receipts and access links.
• Campaign email.

Resend can receive the recipient address, name, subject line, HTML body, reply-to address and delivery metadata.

Where a customer supplies their own Resend API key, their workspace's email is sent on the customer's own Resend account and is described in Part 2.

Data protection terms, locations and safeguards

Nucleus HQ has a written data processing agreement in force with every provider on this register. Each one is on record and none of the claims below is aspirational.

Technical and organisational measures that Nucleus HQ can evidence today: access controls, server hardening, and encryption of secrets, credentials, connection strings and database backups. The server volume itself is not encrypted at rest. Nucleus HQ states that plainly rather than implying a protection it does not have.

Providers that are not engaged

The following are stated so that nobody has to guess.

• No error-tracking provider. Nucleus HQ does not send data to an error-tracking service. There is no such integration and no such configuration.
• No analytics provider. Nucleus HQ does not send data to a third-party analytics service. There is no such integration and no such configuration.
• No AI provider engaged by Nucleus HQ. AI features run on the customer's own provider account. See Part 2.
• No voice provider. Voice usage appears as a priced line, but no voice provider is implemented, so none is engaged and none is named.
• No outbound webhook delivery provider and no third-party booking embed provider. Nucleus HQ engages no delivery vendor to send webhooks on its behalf, and no such vendor receives customer or visitor data. Nucleus HQ's own servers can, however, send an HTTPS request to a web address a customer names, where that customer has built an automation to do it. That address is the customer's own choice, is not a provider Nucleus HQ engages, and is described in Part 2.

If any of these changes, the provider is added to Part 1 and notice is given under the change notice below.

Coded sites and published pages

Customers can publish pages that Nucleus HQ serves. Those pages are served from Nucleus HQ's own infrastructure, and their assets are stored in Cloudflare R2. No additional subprocessor receives visitor data as a result of Nucleus HQ serving the page.

Nucleus HQ injects no third-party tools into a served coded site. If a coded site contains a third-party script, font, image or iframe, that is the customer's own choice, and the customer is the controller for it. The visitor's browser fetches that content directly from the third party the customer chose. Those third parties are the customer's responsibility, not Nucleus HQ subprocessors. The customer is responsible for disclosing that third party and for obtaining any consent it requires.

Nucleus HQ is processor for the hosting of the coded site, and for the lead capture that Nucleus HQ operates on it.

Change notice

Nucleus HQ gives notice before adding a new subprocessor to Part 1 where the customer agreement or applicable data protection law requires it. Moving a provider from Part 2 into Part 1 is a change of the same kind and is treated the same way.

Part 2. Customer-Enabled Integrations Schedule

Of the integrations in the table below, two are enabled today: tenant-supplied Turnstile keys, on one tenant's public form, and a tenant-supplied Resend sending key, on one tenant. No other integration in that table, including Google Calendar, is enabled by any tenant.

Each one is enabled by the customer, using the customer's own account. The customer is the controller of the data sent to that provider and of the purpose it is used for. The customer is responsible for their own account, for lawful use of the data sent to it, and for any notices their own data subjects require.

Customer-credential integrations: Twilio, the Meta WhatsApp Cloud API, OpenAI, Anthropic, tenant-supplied Cloudflare Turnstile keys and tenant-supplied Resend sending keys. The customer supplies their own API key or account credentials. Nucleus HQ does not engage these providers, does not contract with them for the customer's use, and does not pay them on the customer's behalf. For Turnstile and Resend, Nucleus HQ separately holds its own Part 1 subprocessor relationship with the same providers for the platform's own use; the customer-supplied use runs on the customer's account, not that relationship.

Platform-connected integration: Google Calendar. The customer connects their own Google account and controls their own calendar data. The connection is made through an OAuth application that Nucleus HQ registers and operates with Google, so here Nucleus HQ does hold its own relationship with the provider, governed by Google's API terms for operating that application. Nucleus HQ does not pay Google on the customer's behalf and does not contract with Google for the customer's own use of their Google account.

Destinations a customer names. A customer can build an automation whose action sends data to a web address the customer types in. There is no provider and no credential, so there is nothing to put in the table below. Nucleus HQ's own servers send an HTTPS request to the address the customer named, carrying the contact record the automation is about and the name of the event that triggered it. A contact record first created by a form on a coded site carries the cleaned copy of that first submission, and that travels with it. The request carries no answers to a questionnaire, quiz or survey, no uploaded files and no payment detail. Nucleus HQ Ltd has no relationship with the operator of that address, does not contract with them, does not pay them, and cannot name them. The customer chooses the address, is the controller of the data sent to it, and is responsible for telling its own data subjects about it. The address must be a public HTTPS one, and addresses inside a private network are refused.

None of these providers is on the subprocessor register. A provider belongs in Part 1 only where Nucleus HQ engages it to process customer personal data on Nucleus HQ's instructions. None of these is engaged on that basis. For the customer-credential integrations, Nucleus HQ has no relationship with the provider at all. For Google Calendar, Nucleus HQ operates the OAuth application, but Google does not process the customer's calendar data on Nucleus HQ's instructions, so Part 1 would still be the wrong place to list it.

How an integration becomes active

An integration in this schedule does nothing until the customer switches it on:

• The customer supplies their own credentials, API key or OAuth grant in their Nucleus HQ workspace.
• Nucleus HQ stores those credentials encrypted, and uses them only to carry out the actions the customer asks for through the feature.
• Data is exchanged with that provider only from the point of activation, and only the categories set out in the table above.
• The customer can disconnect the integration, after which Nucleus HQ stops sending data to that provider.

Because the account belongs to the customer, the terms, the data processing agreement and any international transfer mechanism with that provider are between the customer and that provider. Nucleus HQ does not sign them on the customer's behalf and does not represent that they exist.

Other customer-controlled tools

Beyond this schedule, customers may connect other external tools of their own, or import data from third-party systems they already use. The customer remains responsible for those external accounts, for lawful data use, and for any notices required for their own data subjects.