1. The short version
Voxa is established in the United Kingdom. Our database and our application compute are both hosted in London, so platform data (accounts, profiles, identity evidence, study records, rewards and submissions to Voxa-hosted studies) stays in the United Kingdom by default.
Three things can take personal data outside the UK: a small number of supporting providers with US operations, a researcher located abroad receiving participant data, and a participant or researcher accessing the service from abroad. Each has a documented mechanism below.
Where a transfer is not covered by UK adequacy regulations, we use an approved safeguard, complete a transfer risk assessment, and apply supplementary measures where the assessment calls for them.
2. The mechanisms we rely on
| Mechanism | When we use it |
|---|---|
| No transfer | Processing that stays within the United Kingdom. This covers the database, application compute, identity evidence and Voxa-hosted study submissions. |
| UK adequacy regulations | Transfers to a country the UK Government has found to provide an adequate level of protection, including the EEA. No further safeguard is needed. |
| UK International Data Transfer Agreement (IDTA), or the EU Standard Contractual Clauses with the ICO's International Data Transfer Addendum | Transfers to a provider or researcher in a country without adequacy. Which of the two we use depends on the counterparty's existing paperwork; both give equivalent protection. |
| EU Standard Contractual Clauses | Transfers subject to the EU GDPR, for example data about participants in the EEA. Module One for controller-to-controller sharing with researchers; Module Four for processor-to-controller release of Voxa-hosted study submissions. |
| UK Extension to the EU-US Data Privacy Framework | Where a US provider is certified under the Framework and the certification covers the relevant data, we may rely on it instead of clauses. |
| Article 49 derogations | Only in genuinely exceptional cases, for example where a transfer is necessary to establish or defend a legal claim. We do not use derogations for routine processing. |
3. Provider transfers
| Route | Data | Mechanism |
|---|---|---|
| Supabase: database hosting | All platform records. | Hosted in London; no routine transfer. Support access from the United States is covered by clauses in the provider agreement, with access limited, logged and granted only on request. |
| Vercel: application hosting | Request data and data in transit through the application. | Functions pinned to London; no routine transfer. Edge-delivered static assets contain no personal data. US support access covered by clauses. |
| Resend: transactional email | Recipient name, email address and message content. | Transfer to the United States under approved clauses. Content is limited to what the message needs. |
| PayPal: researcher checkout, participant account linking and payouts | Researcher funding amounts and references; a participant's PayPal account identifier, verified email address, payout amounts and references. | PayPal is an independent controller for its regulated payment activity and applies its own transfer safeguards. We never receive PayPal sign-in details or raw card data. |
| IPinfo: network classification | A public IP address only. | Only where configured. Transfer to the United States under approved clauses. No account, profile or study data is sent, and we store the classification and a one-way hash rather than the address. |
| Malware scanning endpoint | An uploaded identity document or verification video, sent once. | Only where configured. Must be covered by an approved safeguard, and the provider contract must expressly permit processing identity documents and verification video. |
4. Transfers to researchers
Making participant demographic, screening and performance data available to a researcher is a controller-to-controller transfer. Where the researcher's organisation is outside the UK and EEA and not covered by adequacy, that transfer is made under Module One of the EU SCCs together with the UK Addendum, incorporated in full into the Researcher Terms. The Annex I and Annex II particulars are set out in section 16 of those terms.
Releasing submissions from a Voxa-hosted study to a researcher is a further, processor-to-controller transfer, made under Module Four of the EU SCCs with the UK Addendum, incorporated into the Voxa-Hosted Study Terms for Researchers. The Annex particulars are in section 10 of those terms.
Because holding submissions makes us a processor, we restrict our own data-collection tools to researchers established in the United Kingdom, the European Economic Area, Argentina, Canada, Israel, Japan, New Zealand, South Korea and the United States. That list reflects adequacy findings and, for the United States, the Data Privacy Framework and our own assessment. We may change it if the legal position changes.
Researchers are separately responsible for onward transfers of the study data they control, and must tell participants about those transfers in their own privacy notice.
5. Transfer risk assessment
Before relying on clauses for a route, we assess whether the law and practice of the destination country would undermine the protection those clauses give. We look at the nature and sensitivity of the data, the volume and frequency, the likelihood of government access in practice, the provider's transparency reporting and its record of challenging requests, and the technical measures in place.
Where an assessment identifies residual risk we apply supplementary measures: encryption in transit and at rest, encryption of identity evidence with keys held by us, pseudonymisation so that a recipient receives identifiers rather than names, strict minimisation of what is sent, and contractual commitments to notify and challenge government access requests.
The highest-sensitivity data we hold, identity documents and verification video, never leaves the United Kingdom unless a scanning endpoint is deliberately configured, and it is deleted as soon as a reviewer records a decision.
6. Government access requests
If we receive a legally binding request from a law enforcement or government body for personal data we hold, we will check that the request is valid and properly served, and will challenge it where there are reasonable grounds to do so.
We will notify the affected person or, where we act as a processor, the relevant controller, unless we are legally prohibited from doing so. In that case we will seek a waiver of that prohibition and will disclose whatever we lawfully can.
We do not give any government or authority direct, unfettered or bulk access to our systems, and we do not disclose personal data voluntarily to a public authority in the absence of a valid legal compulsion.
7. Asking for the safeguards
You can ask us for a copy of the transfer safeguards we rely on for a particular route, or for a summary of a transfer risk assessment. We may redact commercially confidential or security-sensitive detail, and we may provide a summary rather than the full agreement where the provider's contract requires it.
Use the Contact page and choose Privacy and data rights. Signed-in users can also use Account & privacy to update preferences, download an account export or request deletion.
8. Changes
Transfer law changes more often than most areas of data protection. We review this document whenever we add a provider, change a hosting region, or an adequacy decision or approved clause set is amended, and we update it here with a new effective date.