Privacy Policy

Jurisdiction: United Kingdom. Framework: UK GDPR and the Data Protection Act 2018. Governing law: England and Wales.

1. Who we are

Nucleus HQ is a multi-tenant, white-label CRM platform operated by Nucleus HQ Ltd, a company registered in England and Wales, company number 17343317, registered office 71-75 Shelton Street, Covent Garden, London WC2H 9JQ. We are based in the United Kingdom.

For platform account data, Nucleus HQ Ltd is the data controller. For tenant CRM data, each tenant is normally the data controller and Nucleus HQ acts as their processor. Section 5 explains this in full, including how it applies to course learners, booking visitors and people who submit a form on a site we host for a tenant.

You can contact us about privacy matters at: [email protected]. For commercial and support matters, use [email protected].

We are registered with the Information Commissioner's Office (ICO), the UK's data protection regulator, as a data controller, registration reference ZC200442.

2. Scope of this policy

This policy applies to all personal data processed through the Nucleus HQ platform, whichever host you access it on. That includes:

• the Nucleus HQ marketing website at nucleushq.app,
• the application on tenant subdomains such as hub26.nucleushq.app and on verified custom domains,
• marketing funnel pages published by tenants on the funnelsnucleuslive.org domain,
• coded sites that tenants build and we host and serve for them on an isolated origin,
• public booking pages, course pages and learner areas operated by tenants through Nucleus HQ.

Nucleus HQ operates in two distinct capacities, as controller and as processor, and your rights differ depending on which applies to you. Section 5 explains it in detail.

3. Data we collect

3.1 Platform account data

When a tenant administrator or team member creates or manages a Nucleus HQ account, we collect:

• name and email address of account holders and team members,
• hashed password credentials,
• workspace invitations, including the invited person's email address and the role they are invited to hold,
• billing contact information and the billing identifiers Stripe returns to us, such as a customer identifier, a subscription identifier and a payment status,
• usage logs, session records and access timestamps for security and audit purposes,
• custom branding assets, such as a logo and colour settings, uploaded by the tenant.

Team invitations may also be created, resent or revoked by your workspace's authorised API integrations, using an admin-level API key, as well as by signed-in team members.

We do not store your card details. Nucleus HQ never receives or stores a card number, a card expiry date, a CVC, or the last four digits of a card. Card data is entered directly with Stripe and stays with Stripe.

3.2 Authentication and account security data

To keep accounts secure we hold, in addition to your hashed password:

• your multi-factor authentication state, meaning whether multi-factor authentication is enabled on your account and when it was enabled,
• your multi-factor authentication secret, held in encrypted form,
• hashes of your single-use recovery codes, and the time at which a recovery code was consumed,
• hashes of your single-use emailed sign-in links. Signing in by email link is the default: we email you a link that is valid for fifteen minutes, works once, and is replaced if you request a new one. We store only a hash of the link token, never the link itself, and expired records are pruned automatically,
• authentication security events, meaning a record of security-relevant events on your account such as sign-in attempts, sign-in link requests and failures, multi-factor challenges and recovery-code use, with the time they occurred and, for security-relevant failures, the requesting IP address.

When you sign in with your password on a device we do not recognise, and you do not use an authenticator app, we email a one-time code to your account email address. The code stops working after 10 minutes. We store only a scrambled (hashed) copy, and delete it once it is used or during scheduled clean-up after it has expired.

We use this data solely to authenticate you, to let you recover access to your own account, and to detect and investigate suspicious activity. We do not use it for marketing or profiling.

3.3 API keys

Tenants can create API keys to connect Nucleus HQ to their own systems. For each key we store:

• a hash of the key, never the key itself in readable form,
• the last four characters of the key, so that you can tell your own keys apart in the interface,
• the scopes the key is permitted to use,
• who created it and when,
• when it was last used,
• whether and when it was revoked.

We also keep API audit records showing which key made which call, so that a tenant can see how their own integrations are behaving and so that abuse can be investigated.

3.4 Tenant CRM data

Tenants, meaning the businesses that use Nucleus HQ to manage their own customers, upload or generate data about their contacts through the platform. This can include:

• contact names, email addresses, phone numbers and notes,
• channel addresses, meaning the email address, phone number or messaging identifier used to reach a contact on a given channel,
• the full content of messages sent to and received from a contact, including the subject line and the body of an email, the body of an SMS or WhatsApp message where the tenant has enabled that channel, the direction of the message, its timestamp, its delivery status and the provider's message identifier,
• booking and calendar appointment records,
• lead source and campaign information,
• files and documents uploaded to contact records, as described in Section 3.5,
• segment membership, pipeline stage and custom field values,
• funnel activity and automation event logs.

Nucleus HQ does not determine the purposes for which this CRM data is used. That responsibility rests with the tenant. See Section 5.

3.5 Files and attachments

When a tenant uploads a file, for example a document attached to a contact record or an attachment on a course lesson, two things happen:

• the file metadata is stored in that tenant's database, meaning the file name, the file type, the size, who uploaded it, when it was uploaded, and what record it is attached to,
• the file itself is stored as an object in Cloudflare R2, Cloudflare's object storage service.

The same two things happen when someone other than the tenant uploads a file, which is the case where a visitor attaches a file to a form the tenant has published. Section 3.19 describes that.

A file can contain personal data about anyone the tenant chooses to put in it, or about the person who uploaded it. The tenant decides what to ask for and is the controller for it.

3.6 Technical and usage data

• IP addresses, browser type, requested page and basic device information, collected in our server logs and in our rate-limiting systems.
• Request metadata used to serve pages, to protect the platform against abuse, and to keep the service secure.

We do not operate any third-party analytics or error-tracking service on the platform. There is no analytics integration, no advertising pixel and no error-reporting provider configured on Nucleus HQ. The only usage measurement we carry out is the first-party widget analytics described in Section 3.10, and the internal audit and security records described elsewhere in this section.

3.7 Funnel page visitors

Tenants can publish marketing funnel pages, which we host and serve on their behalf at addresses under funnelsnucleuslive.org. If you visit one of these pages:

• We process your IP address and basic request metadata, meaning browser type, requested page and timestamp, in our server logs and rate-limiting systems. We use this solely to serve the page, to protect the platform against abuse and to keep the service secure. These logs are rotated automatically on a rolling storage limit. In practice they are held for a matter of days, not months, and they are never kept beyond 90 days. Section 8 sets this out in full.
• Funnel pages set no cookies and carry no Nucleus HQ advertising, analytics or tracking scripts. Where the tenant has added interactive elements, the page runs only the small functional scripts that make those elements work: countdown timers, popups and offer bars (section 3.21), embedded forms with bot protection (which work as described in section 3.19), product and basket elements (section 3.22), and the play button on a video element. A basket keeps your chosen product ids, options and quantities in your own browser's storage; it holds no name, price or identifier, and nothing about you is sent to Nucleus HQ or the business before you choose to check out. To show up-to-date prices, the page may ask Nucleus HQ for current product details; those requests carry no identifier and nothing about you is stored. Aggregate visit counting works as described in section 3.20.
• The content of each funnel page is created and published by the tenant, who is the data controller for that content and for their relationship with you. If a page displays images, fonts or video hosted by a third party, your browser requests those files directly and that third party will see your IP address. For a video, nothing is requested from the video host until you press play. Nucleus HQ does not control those third parties. The publishing tenant is responsible for the content they include.

If you have questions about a funnel page's content or the business behind it, contact that business directly. If you believe a funnel page hosted by us is abusive or unlawful, report it to [email protected].

3.8 Coded sites we host for tenants

Tenants can build a full website inside Nucleus HQ, a "coded site", and we host and serve it for them on an isolated origin. For a coded site we store, on the tenant's behalf:

• the HTML of each page and any custom head content the tenant has written,
• the builder data behind the page, meaning the structured record of how the tenant assembled it,
• the SEO data the tenant has set, such as titles, descriptions and social preview settings,
• any assets the tenant has uploaded for the site, held as objects in Cloudflare R2.

A coded site is customer-controlled. Nucleus HQ injects no tracking, no analytics and no scripts of its own into a coded site. Coded sites are served on a separate, isolated origin under a deliberately permissive content security policy, which means that a tenant is technically able to include external scripts, embeds and iframes of their own choosing in their site. If a coded site loads a third-party script, an embed, a font or an iframe, that is the tenant's own decision and the tenant is the controller for it. Your browser contacts that third party directly and that third party will see your IP address. Nucleus HQ neither selects nor controls those third parties.

Where a tenant builds a coded site that we host, the tenant chooses everything on it, including any third-party script the tenant adds. Nucleus HQ injects nothing into a coded site and adds no script of its own. The tenant is the controller for that content and for any third party it introduces, and the tenant is responsible for disclosing that third party and for obtaining any consent it requires.

If you have questions about what a coded site does with your data, or about anything that site displays, contact the business that publishes it. If you believe a coded site we host is abusive or unlawful, report it to [email protected].

3.9 Forms on coded sites and lead capture

A coded site can include a form that submits back to Nucleus HQ. When you submit one of those forms, we process on the tenant's behalf:

• your email address,
• your name, if the form asks for it,
• your phone number, if the form asks for it,
• any other answers the tenant's form collects and has mapped to their own custom fields,
• the IP address the submission came from, which we store with the submission.

What we then do with it:

• we create a contact record for you in that tenant's CRM, or update the existing contact record if the tenant already holds one for you,
• we store a cleaned copy of the submission payload against that submission,
• we make both available to the tenant inside their Nucleus HQ workspace.
• where the tenant has built an automation that does so, we also send a copy of that contact record, including the cleaned copy of the submission that first created it, from our own servers to a web address the tenant chose, as section 7.2 describes.

The tenant, not Nucleus HQ, decides what to ask you, why, and what they do with your answers afterwards. The tenant is the controller for that data and Nucleus HQ is their processor. Contact the tenant to exercise your rights over it. Section 5 explains this.

3.10 Chat concierge conversations and analytics

Our website offers a chat concierge widget, and tenants can add the same widget to their own Nucleus HQ pages on tenant subdomains and verified custom domains. If you use the chat:

• We process the messages you type and the replies you are shown, stored as the conversation so that it can continue, together with any details you choose to submit in the chat, for example a name, an email address or a phone number when you ask to be contacted.
• We record usage analytics about how the widget is used: the event type, for example widget opened or option picked, the identifier of the step or option involved, an anonymous session identifier, and a timestamp. Analytics events never contain your message text, your contact details or your IP address. The number of analytics events stored per conversation is capped at 500.
• Where a question you ask cannot be matched to an answer, the question text is stored as an unmatched question so that the workspace can improve its answers.
• The widget uses your browser's sessionStorage to hold the current conversation state, meaning an anonymous session identifier, the bot version and up to 100 recent messages, capped at 128,000 bytes. This storage is first party, is not used to track you across sites, and is removed when you close the tab or reset the conversation. Section 4.2 sets out browser storage in full.
• Conversations, analytics and unmatched questions are also deleted when the related chat session, chat bot or workspace is deleted. Section 8 sets out how long they are otherwise kept.

The concierge widget stores a small amount of information in your browser's sessionStorage so that a conversation you have started can carry on as you move between pages. We treat this as strictly necessary for a service you have specifically asked for, because it is written only once you open the widget, it exists only to run the conversation you started, and it is cleared when you close the tab.

Separately, we record usage analytics about the widget. Those events are recorded on our servers, not in your browser. They contain no message text, no contact details and no IP address, and they are capped. We rely on our legitimate interest in knowing whether the widget works.

On nucleushq.app, Nucleus HQ is the controller for chat conversations and analytics. On a tenant's pages, the tenant is the controller and Nucleus HQ processes the data on their behalf under our Data Processing Agreement. Contact that business with questions about their chat widget.

3.11 Public booking pages

Tenants can publish a public booking page so that you can book an appointment with them. When you book, we process on the tenant's behalf:

• your name,
• your email address,
• your phone number, if the tenant asks for it,
• your answers to any custom questions the tenant has added to their booking form,
• the start time of the appointment you choose,
• the IP address the booking was submitted from,
• a Cloudflare Turnstile verification token, which is used to confirm that the booking came from a person and not an automated script. Turnstile is a bot-verification service and is described in Section 7,
• a manage token, which is a unique, unguessable string we generate so that you, and only you, can return to reschedule or cancel your own booking without needing an account. Anyone who has the link containing the manage token can manage that booking, so treat the link as private.

After you book, we email you a confirmation that contains your manage link, and we email you if your booking is moved or cancelled. If the business books an appointment for you in their own dashboard and chooses to notify you, we send that confirmation too. These emails go only to the address given for the booking and are sent through the email provider described in section 7.

If the tenant charges for the booking, you are sent to Stripe to pay. Nucleus HQ never sees your card details. Stripe processes the payment through the tenant's connected Stripe account and returns a payment status and payment identifiers to us, which we store against the booking. While you are away at Stripe, your browser holds the manage token, the slot you chose and the confirmation message in sessionStorage so that the booking can be completed when you come back. That store is read and deleted on your return.

The tenant is the controller for your booking. Nucleus HQ is their processor.

3.12 Courses and learners

Tenants can publish online courses through Nucleus HQ, and people can enrol on those courses as learners. If you are a learner, you are not a Nucleus HQ account holder and you are not a member of the tenant's team. You are a distinct group of people, and this section is about you.

For a course, we store on the tenant's behalf:

• the course and lesson content the tenant has written, and any attachments they have added to it, held as objects in Cloudflare R2 with their metadata in the tenant's database,
• enrolments, meaning the record that links you to a course, when you were enrolled, and how you were enrolled,
• your progress, meaning which lessons you have opened, which you have completed and when,
• your name and email address, as supplied by you or by the tenant when you were enrolled,
• a hashed learner login token. When you are given access to a course, we generate a single-use access token and send you a link containing it. We store only a hash of that token, not the token itself. Anyone who has the link can use it, so treat it as private,
• a hashed learner session. Once you have signed in to the learner area, we set a __Host-nucleus_learner cookie so that you stay signed in for up to 30 days. We store only a hash of that session, not the session value itself.

Learner login and learner sessions exist so that you can get back into a course you have paid for or been granted. They are strictly necessary for the learner area to work at all.

The tenant that publishes the course is the controller of your learner data. Nucleus HQ is their processor. If you want a copy of your learner record, or you want it deleted, contact that business. Section 5 explains this.

3.13 Buying a paid course

If a tenant sells a course and you buy it, this is what happens to your data, step by step:

• 1. You are sent to Stripe to pay. Nucleus HQ never sees your card number, expiry or CVC. Stripe processes the payment through the tenant's connected Stripe account.
• 2. When the payment succeeds, Stripe tells us, and we read the email address and the name you gave Stripe for that purchase.
• 3. We create a contact record for you in that tenant's CRM, using that email address and name, if the tenant does not already hold a contact record for you. If they do, we update the existing one. This means that buying a course puts you into that business's CRM.
• 4. We create an enrolment linking you to the course you bought.
• 5. We mint an access token and store a hash of it, as described in Section 3.12.
• 6. We send you an email through Resend containing your receipt and your access link, so that you can reach the course.

We also store the purchase record itself, meaning what was bought, when, the amount, and the Stripe payment identifiers, so that the tenant has a record of the sale and so that the sale can be reconciled and refunded.

The tenant is the controller for all of the above. Nucleus HQ is their processor, and Stripe is a subprocessor. Section 7 lists our subprocessors.

3.14 The communications wallet and metered usage

Some communication features are metered, meaning a tenant pays per message or per minute rather than as part of a flat subscription. Metered features include SMS, voice and WhatsApp, where a tenant has enabled them with their own provider credentials. To support this, Nucleus HQ operates a communications wallet.

If you are a tenant using the wallet, we process:

• your wallet balance, meaning the credit currently held on your workspace,
• top-up payments taken through Stripe. A top-up can be taken off-session, meaning it is charged to the payment method you have already saved with Stripe, without you being present at a checkout page at that moment. Stripe holds and charges the payment method. Nucleus HQ never holds your card details,
• your auto-reload configuration, meaning whether auto-reload is on, the balance threshold at which it triggers, and the top-up amount to charge when it does,
• a transaction ledger, meaning a dated record of every credit and every debit on your wallet,
• usage debits, meaning, for each metered action, the usage type, the quantity, the unit price applied, the resulting charge and the charge identifier.

We use this data to run the wallet, to charge you correctly, to show you what you have spent, to prevent abuse of metered channels, and to keep the financial records the law requires us to keep. Wallet and usage records are financial records and are retained accordingly. See Section 8.

3.15 Enquiries you send to Nucleus HQ

If you contact Nucleus HQ through an enquiry form or the chat concierge on nucleushq.app, we process the details you give us. That can include:

• your name,
• your email address,
• your company name,
• your phone number,
• the note or message you write,
• the source of the enquiry, meaning where on the site it came from,
• the transcript of your chat conversation, where the enquiry came out of a chat with our concierge widget.

Two things then happen to it, and we want to be explicit about the second one because it is the one people do not expect:

• 1. We email it to ourselves through Resend, our email provider, so that a person at Nucleus HQ sees it and can reply to you.
• 2. We then copy it into the Nucleus HQ CRM, meaning our own workspace on our own platform, where it becomes a contact record and, where relevant, a lead. That record persists after your enquiry has been answered, and we may use it to follow up with you about your enquiry and about the service you asked about.

For enquiries you send to Nucleus HQ, Nucleus HQ is the controller. Our legal basis is our legitimate interest in responding to people who contact us and in pursuing enquiries about our own product, and, where we send you marketing you did not ask for, your consent. You can ask us to delete your enquiry record at any time by emailing [email protected], and we will do so unless we are required to keep it.

3.16 Platform and infrastructure records

To run Nucleus HQ as a platform, we also hold a small set of records at the platform level rather than inside any one tenant:

• provisioning requests, meaning the record of a workspace being requested and created, including who requested it and the details they supplied,
• custom-domain verification records, meaning the domain a tenant asked us to serve, the verification token issued, and whether and when verification succeeded,
• master audit events, meaning a record of significant administrative actions on the platform, including who performed the action, what they did, when, and the IP address they acted from,
• rate-limit buckets, meaning short-lived counters keyed to an identifier such as an IP address, used to stop abuse and brute force.

Nucleus HQ is the controller for these records. We use them to operate the platform, to secure it, and to investigate abuse and incidents.

3.17 Buying from a seller on their own external payment page

Some sellers take payment on a separate payment page of their own, outside Nucleus HQ, after you fill in a form on their funnel page. When a seller has switched this on, this is what happens to your data:

• 1. You fill in the seller's form. Your details are captured for that seller exactly as described in sections 3.7 and 3.9. Nothing extra is collected.
• 2. Your browser is then sent to the seller's own payment page. Nucleus HQ puts no personal data in that redirect, and never sees that page, your card details, or whether you paid.
• 3. Just before you leave, we set a __Host-nucleus_off_platform cookie on the seller's funnel domain. It is a signed, pseudonymous note linking your browser to the form you just submitted. It lasts up to 2 hours.
• 4. If you come back to the seller's thank-you page, the cookie is read once and deleted, your form submission is marked as returned, and a purchased-unverified label is added to your contact record in that seller's CRM. The label tells the seller to check their own payment records and follow up. Nucleus HQ does not verify the payment, and the label does not give anyone access to anything.
• 5. If you do not return, the cookie simply expires and nothing else happens.

The seller is the controller of this data and Nucleus HQ is their processor, as explained in section 5.

3.18 Contracts a business prepares, sends and asks you to sign

A business that uses Nucleus HQ can write a contract document inside the platform, record who it is intended for, send it to those people, and ask them to sign it electronically.

If a business records you as an intended signer, we hold your name and your email address, as that business entered them, and the contents of the document itself, which is written by that business and can contain anything they choose to put in it.

If that business sends the contract to you, we also hold a private one-time link created for you, the date and time it was sent, and whether our email provider reported it as delivered. The link is stored only in a scrambled form that cannot be turned back into the original. It stops working once it is used, once the business withdraws it, or after fourteen days, whichever comes first.

If you open that link, or sign or decline the contract, we record the contract as you were shown it, the date and time of each step, your IP address, and the browser and device information your browser sends. If you sign, we also store the signature image you draw. This record exists so that the business, and you, can later show what was signed, by whom, and when. It is a legal record, so it is written once and is not edited afterwards.

We do not use any of this to track you. The signing page sets no cookies, contains no advertising or analytics tools, and we do not build a profile of you or use your details to market anything to you. Opening a contract does not create an account and does not add you to any mailing list.

PDF copies of the document. The business can generate a PDF copy of the contract document from inside the platform while it is still a draft. Once everyone has signed, we generate one final PDF copy of the contract. It contains the document as it was signed, the name and email address of each signer, the signature images they drew, and the date and time the contract was completed. It is generated once and is not changed afterwards. Both kinds of PDF are held in our file storage, described in section 3.5. Files are stored in Western Europe, which is a different place from our databases in the United Kingdom. Section 7.3 explains both, and the transfer arrangements that apply.

Your copy of the signed contract. When the contract is complete, we email each signer a private link to download the final PDF. The link works for thirty days and can be used more than once during that time. It is stored on our side only in a scrambled form that cannot be turned back into the original, and the business can withdraw it. The download page sets no cookies and does not track you. If your link has expired, the business that sent you the contract can ask for a new one to be issued.

How long it is kept. If the contract is signed, declined, or cancelled by the business, the whole record is deleted six years afterwards. That period reflects the time limit for bringing a claim on a contract. If a contract is sent but is never signed, declined or cancelled, it stays until the business cancels or removes it, because an open contract has no end date to count from.

The business preparing the contract is the controller of this information. Nucleus HQ is their processor. If you want to know what is held about you, or you want it corrected or deleted, contact that business. Section 5 explains this. If a business removes a contract, everything described here goes with it.

3.19 Forms, questionnaires, quizzes and surveys a business runs on the platform

A business using Nucleus HQ can build questionnaires, quizzes and surveys and publish each one as a page on its own workspace address. If you fill one in, you are giving your answers to that business: the business is the controller of your responses, and Nucleus HQ Ltd processes them on the business's behalf.

What is stored when you submit a form: your answers, the date and time, your name, email address and phone number where the form asked for them and you chose to provide them, and, for quizzes, the score and outcome the business's own scoring rules produce. If the business has put a file upload question on the form and you attach a file, we also store the file itself, along with its name, its type and its size. If the business has put a payment question on the form and you pay, we also store a payment record: the amount, the currency, whether the payment succeeded, the date and time, and the identifiers Stripe gives that payment. We never see, receive or store your card number, its expiry date or its security code. Responses are stored in that business's isolated workspace database and are kept against the exact version of the form you saw, so later edits by the business never change what you submitted. The file itself is stored as an object in Cloudflare R2, Cloudflare's object storage service, in the same way as the other files described in section 3.5. Only people signed in to that business's workspace can open a file you upload. It is never attached to an email and it is never published on a public page.

While you are filling a form in, your answers are saved in your own browser on your device so you can leave and come back. Your answers are not sent to us until you press submit, and the saved copy is removed from your device once your submission succeeds. A file is different: if you attach one, it is uploaded as soon as you choose it, so that it is ready when you submit. A payment is different again. If the form asks you to pay, pressing submit saves your answers and then sends you to Stripe, the payment company the business uses, to enter your card details on Stripe's own page. Your response is held as unpaid until Stripe tells us the payment went through. The business is shown that it is unpaid until then, and the form's own thank you screen is only shown to you once Stripe confirms it. If you close the page at Stripe without paying, your response stays unpaid and no money is taken.

If the form asks for your email address and the business has switched on contact creation, submitting the form may create or update a contact record about you in that business's CRM workspace, in the same way as the site forms described in section 3.9. Surveys a business runs anonymously store no name, email or phone fields. If you pay through a form, we pass the email address you gave on the form to Stripe, so that Stripe can reach you about the payment, and we send you a receipt by email through Resend, our email provider, showing what you paid, to whom and when. We also email the business to tell them a payment has come in. Paying through a form does not by itself put you in the business's CRM; that happens only in the case described at the start of this paragraph. Where a contact record about you is created or updated in that way, the business can also have built an automation that sends a copy of that contact record to a web address the business chose, as section 7.2 describes. Your answers to the form, any file you attached and any payment detail are not part of what is sent that way.

The form page uses Cloudflare Turnstile to block automated submissions (section 7 describes Cloudflare's role). Your IP address is used at the moment of submission to protect the service against abuse; it is not stored with your response. The form page sets no cookies.

If you want your response corrected or deleted, contact the business that ran the form. Our Data Processing Addendum explains how we assist businesses with those requests.

3.20 Visit counts and sales figures on funnel pages a business runs on the platform

Published funnel pages record aggregate visit counts: how many times a page was viewed and how many times it was submitted, per day. When a buyer starts a checkout from a product element on a funnel page, the resulting order is linked on our servers to the page and site it came from, after we verify that the page belongs to that site. The business can then see aggregate sales figures per page and per day: orders started, orders paid, and gross and paid revenue kept separate for each currency. These figures are built only from the order records we already process for checkout (section 3.22) and from the visit counts above; nothing new is collected from your browser for them. Analytics on these pages uses no cookies or similar storage, and no visitor identifiers, IP addresses or browser details are kept for it.

3.21 Countdown timers, popups and offer bars on funnel pages

Some funnel pages use countdown timers, popups or dismissible offer bars. To make these work, the page may store small values in your own browser: when your personal countdown ends, whether you have already seen a popup, and whether you dismissed an offer bar. These values stay on your device, are not sent to the business or to Nucleus HQ, and contain nothing that identifies you.

3.22 Buying a product from a tenant's shop

If a tenant sells a product through their shop and you buy it, this is what happens to your data, step by step:

• 1. You are sent to Stripe to pay on the tenant's connected Stripe account, whether you started from the tenant's shop, a payment link, or a product element on a funnel page the tenant publishes. If the page offers a basket, your chosen product ids, options and quantities wait in your own browser's storage until you check out, and the basket is cleared when you are sent to Stripe. Nucleus HQ never sees your card details.
• 2. When the payment succeeds, Stripe tells us and we store the order: what was bought, when, the amount and currency, and the Stripe payment identifiers. We later store the fulfilment status the tenant sets: fulfilled, shipped or cancelled.
• 3. If the product needs delivery, Stripe asks you for a delivery name and address at checkout and we store them on the order so the tenant can send your goods. The tenant sees them in their order screen, in the order notification email, and they appear on your receipt. We remove the name and address from the order 12 months after the order is fulfilled or cancelled; the rest of the order record stays for six years as a financial record. We do not ask for your phone number.
• 4. We send you a receipt email through Resend to the address you gave Stripe, and we send the tenant an order notification email. The email address you gave Stripe is used to send the receipt and appears in the tenant's email sending log, like every email sent through the platform; it is not stored on the order record.
• 5. Buying a product does not by itself create a contact record for you in the tenant's CRM. If the tenant already held a contact record for you and started the checkout for it, the order is linked to that record.
• 6. Refunds are issued by the tenant through Stripe and are recorded against the order automatically.

Delivery names and addresses are removed 12 months after an order is fulfilled or cancelled. The remaining order record is a financial record and is kept for six years. See the retention and deletion section.

4. Cookies and similar technologies

4.1 Cookies

Nucleus HQ does not set advertising or marketing cookies, and does not use third-party tracking or advertising pixels. The only cookies we set are the ones listed below, and they are needed to sign you in, keep you signed in, remember your language, keep your account secure, and confirm your return to a seller's funnel page from their external payment page.

This is the complete list of cookies Nucleus HQ sets. There are no others.

Notes that matter:

• We set no analytics, advertising or third-party tracking cookies. None. Not by default and not otherwise.
• We do not set a CSRF cookie. Cross-site request protection on Nucleus HQ uses signed OAuth state together with host and origin checks. No cookie is involved.
• Tenant routing does not use a cookie. Working out which workspace you are on is done from the host and request headers.
• Funnel pages served on funnelsnucleuslive.org set no cookies at all, in any category.
• Full detail, including how to manage cookies in your browser, is in our Cookie Policy.

4.2 Browser storage that is not a cookie

Some things are stored in your browser but are not cookies. We disclose them separately because they behave differently and because your browser controls them differently.

Neither of these is used to track you across sites, and neither is shared with a third party.

5. Our role as controller and as processor

5.1 Controller

Nucleus HQ is the controller, meaning we decide why and how the data is processed, for:

• platform account data of tenant administrators and team members (Section 3.1),
• authentication and account security data (Section 3.2),
• API key records and API audit records (Section 3.3),
• technical and usage data, server logs and rate-limit records (Sections 3.6 and 3.16),
• platform and infrastructure records, including provisioning, custom-domain verification and master audit events (Section 3.16),
• billing, wallet and metered usage records for our own tenants (Section 3.14),
• chat conversations on nucleushq.app itself (Section 3.10),
• enquiries you send to Nucleus HQ, including the CRM copy of them (Section 3.15).

This policy governs those activities.

5.2 Processor

Nucleus HQ is a processor, acting on the tenant's documented instructions, for everything a tenant puts into or generates inside their own workspace. That includes:

• tenant CRM data, including message content and channel addresses (Section 3.4),
• files uploaded to tenant records (Section 3.5),
• funnel pages and coded sites the tenant publishes, and the assets in them (Sections 3.7 and 3.8),
• form and lead-capture submissions made through a tenant's funnel page or coded site (Section 3.9),
• chat conversations on a tenant's own pages (Section 3.10),
• bookings made on a tenant's public booking page (Section 3.11),
• courses, enrolments, learner progress and learner access (Section 3.12),
• course purchases and the CRM contact a purchase creates (Section 3.13),
• product purchases (Section 3.22).

Our processor obligations are set out in our Data Processing Agreement.

5.3 What the tenant is responsible for

The tenant is the controller of that data and is responsible for:

• having a lawful basis for collecting and processing their contacts', visitors', bookers' and learners' data,
• providing their own privacy notice to the people they hold data about in Nucleus HQ, including their learners and the people who book with them,
• providing any privacy notice required for pages they publish through the platform, including funnel pages, coded sites, booking pages and course pages, and for what those pages contain,
• choosing and controlling any third-party script, embed, font or iframe they place on a coded site, and complying with cookie and e-privacy law for it. Nucleus HQ places none,
• responding to data subject rights requests from their own contacts, bookers and learners,
• ensuring their use of Nucleus HQ complies with applicable law.

5.4 If you are a contact, a booker or a learner

If you are a contact in a Nucleus HQ tenant's CRM, or you booked an appointment through a tenant's booking page, or you are a learner on a tenant's course, then that business is the controller of your data, not Nucleus HQ. Contact them directly to exercise your rights. If you cannot reach them, or you do not know who they are, write to [email protected] and we will help you identify the controller and pass your request on.

6. Our legal bases for processing

Where Nucleus HQ is the controller, we process personal data on the following bases under Article 6 of the UK GDPR.

• Contract, Article 6(1)(b). Processing necessary to provide the platform to you under our Terms of Service. This covers your account, your workspace, your billing and subscription, your wallet top-ups and the metered usage you incur.
• Legitimate interests, Article 6(1)(f). Security logging, authentication security events, rate limiting, fraud and abuse prevention, audit records, keeping the platform working, and responding to enquiries you send us. Where we rely on legitimate interests we have considered your rights and we do not use this basis for anything you would not reasonably expect.
• Legal obligation, Article 6(1)(c). Retaining billing, wallet and transaction records to meet financial reporting and tax obligations.
• Consent, Article 6(1)(a). Optional marketing communications, meaning the marketing emails you can choose to receive from us. We do not rely on consent for cookies, because we set no non-essential cookies. You can withdraw consent at any time, and withdrawing it does not affect processing that already happened.

Where necessary to obtain professional advice, arrange or maintain insurance, or establish, exercise or defend legal claims, we may share relevant personal data with our insurers, insurance brokers and professional advisers. We rely on our legitimate interests in protecting the business and handling claims, and such recipients are bound by professional or contractual duties of confidentiality.

Where Nucleus HQ is a processor, the legal basis is the tenant's to establish, not ours.

7. Subprocessors

7.1 The subprocessors Nucleus HQ engages

These four, and no others.

Cloudflare R2 is where uploaded files, coded-site assets, course attachments, contract documents and signer signature images actually live, and where encrypted database backups are stored.

7.2 Customer-enabled integrations, which are not our subprocessors

Some Nucleus HQ features connect to a third-party provider using the customer's own account. In every case the customer chooses to connect that account, decides what it is used for, and is the controller of the data sent to it. None of these providers is a Nucleus HQ subprocessor, because none of them processes that data on Nucleus HQ's instructions.

These connections come in three forms, and the difference matters.

Customer-credential integrations. For Twilio, the Meta WhatsApp Cloud API, OpenAI and Anthropic, the customer supplies their own API key or account credentials. Nucleus HQ does not engage those providers, holds no relationship with them for the customer's use, and does not pay them on the customer's behalf. Two providers can appear in both capacities. Cloudflare and Resend are Nucleus HQ subprocessors for the platform's own use, as Section 7.1 describes, and a customer can additionally supply their own Cloudflare Turnstile keys for bot verification on their public forms, or their own Resend sending key for their workspace's email. Where a customer does so, that verification or sending runs on the customer's own account with that provider, under the customer's own terms with them, and not on Nucleus HQ's instructions. Turnstile widgets that Nucleus HQ provisions automatically for a customer's domain remain part of Nucleus HQ's own Cloudflare relationship and are covered by Section 7.1.

Platform-connected integrations. Google Calendar works differently. The customer connects their own Google account and remains the controller of their calendar data, but the connection runs through an OAuth application that Nucleus HQ itself registers and operates with Google. Nucleus HQ is bound by Google's API terms for operating that application, so Nucleus HQ has its own direct relationship with Google in that limited respect. Nucleus HQ does not send the customer's calendar data to Google for Google to process on Nucleus HQ's instructions, which is why Google is not on the subprocessor register.

Destinations a customer names. The third form involves no provider at all. A business using Nucleus HQ can build an automation whose action is to send data to a web address that business types in, usually its own system or another tool it uses. There is no account to connect and no credential to supply: the business names an address, and our own server sends an HTTPS request to that address when the automation runs. Nucleus HQ Ltd has no contract with whoever operates that address, does not know who they are, and cannot list them, which is why no such address appears in any table on this page or on our subprocessors page. The business chooses the address, the business is the controller of what is sent there, and the business is responsible for telling you that it does it. What a request of this kind carries is the contact record the automation is about, of the kind described in section 3.4, together with the name of the event that set the automation off. Where that contact record was first created by a form on a coded site, it includes the cleaned copy of that first submission described in section 3.9, so the fields that site form asked for travel with it. It does not carry your answers to a questionnaire, quiz or survey, any file you uploaded, or any payment detail. The address has to be a public HTTPS one: addresses on a private network, on our own network, or on your own machine are refused.

Google Workspace data and Limited Use. Nucleus HQ's access to, and use of, information received from Google Workspace APIs, including the Google Calendar API, adheres to the Google API Services User Data Policy, including its Limited Use requirements. Nucleus HQ uses Google Calendar data only to provide and improve the calendar and booking features the connecting user has enabled: reading the user's busy and free times so that a booking page does not offer a slot when the user is unavailable, and creating, updating or removing the calendar events that a booking generates. Nucleus HQ does not transfer this data to others except as necessary to provide or improve those features, to comply with applicable law, or in connection with a merger or acquisition; does not use it for serving advertisements; and does not use it to develop, train, or improve generalised or non-personalised artificial intelligence or machine learning models. Nucleus HQ does not allow humans to read this data unless the connecting user has given consent to view specific data, it is necessary for security purposes such as investigating abuse, it is required to comply with applicable law, or the data has been aggregated and anonymised.

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. The others are listed so that you know what happens if one is turned on.

Nucleus HQ does not engage an AI provider. Any AI provider used through Nucleus HQ is the customer's own account, on the customer's own key.

7.3 Data processing agreements and international transfers

Every subprocessor above is engaged under a written data processing agreement.

• Contabo GmbH. Signed Article 28 data processing agreement, concluded 14 July 2026. Your data is stored in the United Kingdom. Contabo is an EEA company whose personnel may access the systems in order to support them, and that access relies on the UK's adequacy finding for the EEA. No Standard Contractual Clauses are required.
• Stripe Payments Europe, Limited. Data processing agreement in force, dated 18 November 2025, incorporated into Stripe's standard terms. Transfers are covered by that agreement, including its UK Addendum and Standard Contractual Clauses where they apply. Stripe acts as our processor and, for its own regulatory and compliance purposes, as an independent controller.
• Cloudflare, Inc. Data Processing Addendum version 6.4, dated 3 April 2026, incorporated into Cloudflare's standard terms. Transfers are covered by that addendum, including the Standard Contractual Clauses and the UK Addendum. The Cloudflare R2 bucket that holds uploaded files, coded-site assets, course attachments, contract documents, signer signature images and encrypted database backups was created with a Western Europe location hint, so those files are stored in Western Europe. That is a location preference rather than a contractual restriction: we have not applied Cloudflare's EU jurisdiction setting to the bucket, so Cloudflare is not contractually prevented from storing the data elsewhere.
• Resend. Data processing agreement signed 31 December 2025. Transfers are covered by that agreement.

Please note that these are two different places. Our databases are hosted in the United Kingdom (Portsmouth, Contabo UK Ltd). Uploaded files are stored in Western Europe (Cloudflare R2). Both positions are stated above exactly as they are.

Where a subprocessor processes personal data outside the UK, we rely on an appropriate transfer mechanism, such as the International Data Transfer Agreement or the UK Addendum to the EU Standard Contractual Clauses, or on an adequacy decision.

The maintained register is on our Subprocessors page.

8. How long we keep data

Where we can give a fixed period, we give it. Where the period depends on how long you keep using the service, we tell you what determines it instead of quoting a number we do not hold ourselves to. You can delete your data at any time, and you can ask us to delete it.

A tenant can delete their own data at any time, and deletion inside the platform cascades: deleting a chat session, a bot or a workspace deletes the records that hang off it. A course that has enrolments, or a product that has orders, cannot be deleted while that paid history exists, because financial records are kept for six years; it is archived instead, which removes it from normal use and keeps the enrolment and order records unchanged.

Deletion and backups. Our hosting provider, Contabo, also takes its own automated backup of the whole server, separately from the encrypted database backups we take ourselves. 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. Deletion therefore works through to backups on the backup cycle: our own routine encrypted database backups are held for 30 days remote and seven days local, and Contabo's whole-server backups are held for approximately ten days. So data you delete can persist in a backup for those periods before the backup itself expires. Separately, before a significant change or before a workspace is removed, we take a one-off encrypted dump of the affected database so that the change can be undone if something goes wrong. Those dumps are held on our own servers only, are never copied to remote storage, and are deleted automatically after 30 days. If you ask us to delete your data, that dump is not opened or used for any other purpose, and it expires on the same 30 day cycle.

9. Security

We implement appropriate technical and organisational measures to protect personal data, including:

• Encryption in transit. TLS 1.2 or higher on every connection to the platform.
• Encryption of secrets and backups. Credentials, API keys, multi-factor secrets, integration tokens, connection strings and database backups are held in encrypted form. Database backups are encrypted before they leave our servers and are stored encrypted. We do not claim that the underlying server volume is encrypted at rest, because it is not, and we would rather tell you precisely what we do than make a broad claim we cannot stand behind.
• Password hashing using industry-standard algorithms. We never store your password.
• Multi-factor authentication available on accounts, with recovery codes stored only as hashes.
• Tenant data isolation, so that each tenant's data is separated and a tenant cannot reach another tenant's data.
• Rate limiting on our public and authenticated API surfaces, including brute-force protection on authentication endpoints, and bot verification with Cloudflare Turnstile on public submission surfaces such as booking.
• Access controls limiting staff access to data on a need-to-know basis, with administrative actions recorded in master audit events.
• Regular security reviews and patch management.

If a personal data breach occurs that is likely to result in a risk to your rights and freedoms, we will notify the Information Commissioner's Office within 72 hours of becoming aware of it where we are the controller, and we will notify the affected tenant without undue delay where we are the processor.

10. Your rights under the UK GDPR

Where Nucleus HQ is the controller of your personal data, you have the right to:

• Access. Request a copy of the personal data we hold about you.
• Rectification. Ask us to correct data that is inaccurate or incomplete.
• Erasure. Request deletion of your data where there is no overriding reason for us to keep it.
• Restriction. Ask us to restrict processing in certain circumstances.
• Portability. Receive your data in a structured, commonly used, machine-readable format.
• Objection. Object to processing we carry out on the basis of legitimate interests.
• Withdraw consent. Where processing is based on consent, withdraw it at any time, without affecting processing that already took place.

To exercise any of these rights, email [email protected]. We will respond within one calendar month.

If Nucleus HQ is only the processor of your data, meaning you are a contact, a booker or a learner of one of our tenants, then send your request to that business. They are the controller. If you send it to us we will pass it to them and tell you that we have done so.

On closing a workspace, a tenant can export their data at any time. Tenant CRM data is retained while the workspace is deactivated, so that it can be restored if the tenant reactivates it, and it is deleted when the tenant asks us to delete it. Section 8 sets this out.

11. Right to complain

If you are unhappy with how we have handled your personal data, you have the right to lodge a complaint with the Information Commissioner's Office.

We ask that you contact us first, at [email protected], so that we can try to resolve your concern.

12. Changes to this policy

We may update this policy from time to time. We will notify account holders by email before any material change takes effect. The "Last updated" date at the top of this page always reflects the most recent version.