Skip to content
Data Processing

Sub
processors.

Last updated: 17 September 2026. Every third party that processes personal data on our behalf: what each one receives, where it processes it, and what makes the transfer lawful.

1. The Register

These are every third party that processes personal data on our behalf, one row per service rather than one per company — because the answers differ by service. Google runs our database in Belgium, our AI processing within the EU, and our sign-in system somewhere it will not tell us. Rolling those into a single line would hide the one that matters.

What each one receives was read out of our own code, not from what we intended to send. Where each one processes it was read from that provider's own published terms, and each row says which document and when. We would rather you check than take our word for it.

Cloud Firestore

Google Cloud

The database holding everything you enter into the product.

What it receives
  • — Assessment answers and scores
  • — Vendor records, incidents and essential-service mappings
  • — Evidence Vault metadata (the file itself is in Cloud Storage — see below)
  • — Support tickets and audit history
  • — Your account profile and organisation details
Where it processes
europe-west1 (Belgium)
Read off the Firebase console, and confirmed from the deployed bundle. The database was migrated out of europe-west2 (London) on 2026-09-17 and the London database has been deleted.

Cloud Storage

Google Cloud

Holds the evidence files you attach to a control, and nothing else.

What it receives
  • — The evidence documents you upload — the file itself, as you supplied it
Where it processes
europe-west1 (Belgium)
Read from the bucket's own metadata rather than from configuration, and re-read by the server before every upload: it refuses to store anything in a location it cannot name an EU member state for. europe-west2 (London) and europe-west6 (Zurich) are both refused by name, because both look European and neither is — London is the location the database itself had to be migrated off on 2026-09-17.

Cloud Run

Google Cloud

The application servers themselves.

What it receives
  • — Every request you make to the product, in transit
  • — Nothing is retained here — Cloud Run holds no database
Where it processes
europe-west1 (Belgium)
The region the service is deployed to, in cloudbuild.yaml.

Firebase Authentication

Google Cloud

Sign-in, and the identity your records are keyed to.

What it receives
  • — Your email address
  • — Your password, as a hash Google computes and we never see
  • — Your display name
  • — Sign-in records and timestamps
  • — The provider you signed in with, where you used Google
Where it processes
Not region-configurable — we cannot choose or confirm it
Identity Platform, which is Firebase Authentication's backend, appears in none of the four lists in Google's Data Residency terms (last modified 8 September 2026) — neither among services whose location a customer can set nor among those that hold no customer data at rest. Its own documentation has no data-residency or regionalization page.
Transfer safeguard
Personal data goes to Not disclosed by Google, protected by Standard Contractual Clauses, or an equivalent Google terms an "Alternative Transfer Solution".
Google Cloud Data Processing Addendum §4.1, which requires one or the other for any transfer not bound for a country the European Commission has found adequate.

Gemini models on Vertex AI

Google Cloud

The AI-assisted features — the evidence cross-mapper and the drafted narrative sections.

What it receives
  • — The text of documents you submit to an AI-assisted feature
  • — Your organisation name, industry, country and entity classification
  • — The control text those are compared against
Where it processes
EU multi-region, via the europe-west1 endpoint
Google's AI/ML Data Location terms cover this service for the models we use, and its per-model ML processing table (last updated 16 September 2026) records the EU commitment for every one of them. Note it is the EU multi-region, not Belgium specifically: a region name is not a jurisdiction.

Stripe Checkout and Billing

Stripe

Taking payment for a paid plan.

What it receives
  • — Your email address
  • — Our internal account id for you
  • — The plan tier you chose
  • — Your practice id, if you are a partner upgrading a client
  • — Card details go to Stripe directly from the checkout page and never reach our servers
Where it processes
United States, and onward "on a global basis"
Stripe DPA §6.1 and §6.2, read 2026-09-17 (DPA last updated 18 November 2025). The word "residency" does not appear in the document.
Transfer safeguard
Personal data goes to Stripe, LLC in the United States, protected by the Data Privacy Framework, the EEA Standard Contractual Clauses or the UK International Data Transfer Addendum, as applicable.
Stripe's Data Transfers Addendum, incorporated by its DPA's own "Data Transfer Mechanism" definition.

Resend

Resend

Sending transactional email — confirmations, password resets, notifications.

What it receives
  • — The email address a message is sent to
  • — Where a confirmation repeats a form back: the name, company and framework focus you typed
Where it processes
United States
Resend DPA §6.1, read 2026-09-17: "Company's primary processing operations take place in the United States". The word "residency" does not appear in the document.
Transfer safeguard
Personal data goes to the United States, protected by the EU Standard Contractual Clauses (Modules One and Two) and certification under the EU-U.S. Data Privacy Framework.
Resend DPA §6.2 and §11.1.

2. Transfers Outside the EU

4 of these 7 services process your data inside the European Union and raise no transfer question at all. The other 3 do leave it, each row above names the safeguard its transfer rests on, and you can ask us at support@vividrisk.ai for a copy of any of them.

What we will not do is round that up. A transfer under Standard Contractual Clauses is lawful; it is not the same thing as your data staying in Europe, and we are not going to let the first sentence stand for the second. So do not rely on this platform to satisfy a data-residency requirement or a GDPR Chapter V transfer obligation, even though the database itself is in the EU. If residency is a condition of your using us, write to us and we will tell you exactly where each of these stands rather than sell you a guarantee we cannot give.

3. When This Changes

We will update this page before a new subprocessor starts processing your data, not after. If you would like to be told directly rather than checking, write to support@vividrisk.ai and we will email you when a row changes. The date at the top is the last time the register was checked against the providers' own documents — not the last time this page was edited.

4. What This Page Is, and Is Not

It is not the data processing agreement — but there is one now. Where you use Vivid Risk to hold your organisation's assessment data, you are the controller and we are your processor, and Article 28 of the GDPR says that relationship must be governed by a contract covering specified terms. Our Data Processing Agreement is that contract. It is incorporated into the Terms of Service and applies automatically, so you do not need to sign anything; its Annex 2 is this same register. This page is the register on its own, for when that is all you need. For a countersigned copy, or to send us your own template, write to support@vividrisk.ai.

The same applies if you are a partner managing clients: your clients' data passes through the same services listed above, and we are a sub-processor in that chain. This page is the list you can hand them today.