NeuraVate Subprocessor Register

This register lists every third party engaged (or slated to be engaged) to process personal data on our behalf. Our Privacy Policy (privacy-policy, section 8.3), Consumer Health Data Privacy Policy (consumer-health-data-privacy-policy, section 5.3) and Terms of Service (terms-of-service, section 13) refer to it for the complete list.

Status values:

• ACTIVE — the vendor processes personal data in the live service today.
• PENDING-ACTIVATION — the vendor is selected and contracted-or-in-contracting, but not yet carrying production personal data; the row exists so activation is a notice event, not a surprise.
• NOT USED AT LAUNCH — a vendor for a feature the launch does not offer; no personal data goes to it.
• CONDITIONAL-candidate — under evaluation only; not engaged, no data flows. Listed purely so that nobody is surprised if it is ever adopted.

Change notification: we update this register before a new subprocessor touches personal data. Notice is delivered by updating this register (version bump), and the Privacy Policy is updated at the same time where the change affects it. Where an organisation customer has signed our Data Processing Agreement, it also gets 30 days' advance notice of any new subprocessor or material change, plus direct notice under that agreement's notice clause.

Source of truth: this register is the authoritative list. A vendor credential or outbound connection with no register row is a compliance defect, and we correct it.

Data-processing terms: the date on which we accepted each provider's data-processing terms is recorded in the last column of Section 2: Hetzner 2026-10-12, Backblaze 2026-10-12 and Stripe 2026-10-12; Cloudflare's terms have applied since our zone was created on 2026-07-15, Migadu's since our domain was added on 2026-06-09, and Resend's since our account was opened on 2026-07-08 (the exact date of that acceptance is not recorded).

Downstream delivery networks (via Expo): push delivery necessarily transits Apple Push Notification service (iOS devices) and Google Firebase Cloud Messaging (Android devices). These are the platform-required delivery networks for the respective devices — there is no alternative route to a device's push channel. They receive push tokens and notification payloads as part of Expo's routing and are covered by the Expo row above.

Conditional candidates (NOT active — no data flows today)

To prevent future confusion, the following are recorded as non-processors — they do not process user personal data on our behalf:

• GitHub / GitHub Container Registry (GHCR) — hosts our source code and container images. No user data is stored in or transits the repository or registry.
• Local development doubles — Mailpit (dev email catcher) and stripe-mock run only in local/dev environments against non-production data; they never see production personal data.
• Self-hosted infrastructure components — Keycloak, PostgreSQL, and the gateway and ingress software in front of them (Kong, Traefik) are our own workloads, deployed and operated by us on our own server. They are not third parties; the third party underneath them is the Hetzner row in Section 2.
• Apple (App Store) and Google (Google Play) — if a person gets the NeuraVate.ai app from their stores, they handle that person's download and store account under their own terms, as controllers in their own right; the app sends them no personal data, and they process none on our behalf. A pass a person adds to Apple Wallet from the app holds only their emergency link; Wallet keeps it on their phone and, if they use iCloud for Wallet, Apple keeps it in their iCloud account, for that person and not on our behalf.
• Stripe, in its independent-controller capacity — for card/payment-instrument data, Stripe determines its own purposes and means under its services agreement and is a controller in its own right, not our subprocessor. Stripe appears in Section 2 only for the processing it performs on our behalf (the printed-card order and payment records in our Stripe account).

Every new vendor (and every status promotion of an existing row) follows this protocol:

1. Before account creation / contracting: assess the vendor's security posture, certifications, breach history, data locations, and sub-subprocessor chain; confirm a GDPR Art 28 DPA with SCCs (or another valid Chapter V transfer mechanism) is available.
2. At account creation: execute the vendor's DPA/SCCs and record the execution date and mechanism in this register (the last column of Section 2). Unrecorded execution is a defect to be cured, not a normal state.
3. Before any production traffic: the register row must exist with ACTIVE or PENDING-ACTIVATION status, and, for an organisation customer under a Data Processing Agreement, the 30-day advance notice that agreement provides must have run. Register row first, data flow second — never the reverse.
4. On offboarding: the row moves to a REMOVED entry in the changelog, and return/deletion of personal data is obtained per the vendor DPA.

• Privacy Policy — slug: privacy-policy (recipients disclosure references this register)
• Consumer Health Data Privacy Policy — slug: consumer-health-data-privacy-policy (section 5.3)
• Terms of Service — slug: terms-of-service (section 13)
• Cookie Policy — slug: cookie-policy (consent precondition for any analytics candidate)