Sub-processors

Register approved: 25 August 2026

TriageFit is operated by TriageMethod Ltd, a company registered in Ireland. To run the Service we use the sub-processors below. Each one appears here because a production code path uses it, and each entry states where the processing runs no more firmly than we can enforce or verify: where a region is pinned in our code or configuration, the table says so, and where a provider operates globally, the table says that instead.

This is the current list referenced by our data processing agreement. When we engage a new sub-processor or materially change what an existing one does for us, we update this page and give organisation billing contacts notice by email before the change takes effect, as the agreement sets out.

  • Google Cloud (Vertex AI)

    What it does
    Runs the AI models behind the coaching itself: replies, programme adjustments and retrieval over our own knowledge base. The member context sent for a reply can include health data the member has shared with their coach.
    Where it runs
    EU only. The application refuses to start an AI request against a non-EU region.

  • Neon

    What it does
    Hosts the PostgreSQL database holding accounts, coaching records, billing references and organisation rosters.
    Where it runs
    EU (Frankfurt).

  • Vercel

    What it does
    Hosts and runs the application, its server-side routes and its scheduled jobs.
    Where it runs
    Application compute is pinned to Frankfurt.

  • Stripe

    What it does
    Processes payments: checkout, subscriptions, invoices, refunds and payouts. Card details are entered with Stripe and are never stored by TriageFit.
    Where it runs
    Global provider; no single processing region is pinned.

  • Resend

    What it does
    Delivers the Service's email, including seat invitations, billing notices and coaching messages.
    Where it runs
    Global provider; no single processing region is pinned.

  • Upstash

    What it does
    Holds rate-limit counters and short-lived payment-webhook idempotency keys. No coaching or health content is stored there.
    Where it runs
    EU (Frankfurt).

  • Sentry

    What it does
    Receives error telemetry for monitoring and alerting, scrubbed of known identifying and health fields before it leaves the application. Session replay is disabled.
    Where it runs
    EU (Germany).

  • Cloudflare R2

    What it does
    Stores files members upload, such as progress photos, wearable exports and documents.
    Where it runs
    EU jurisdiction.

  • Google (Google Analytics 4 and Search Console)

    What it does
    Consent-gated website analytics with IP anonymisation, and site-level search performance reporting for the administrator.
    Where it runs
    Global provider; no single processing region is pinned.

AI tools we build with

Our engineering uses AI coding assistants, largely from Anthropic and OpenAI, to write, review and improve the software behind TriageFit. They are development tools rather than parts of the running Service, which is why they are not in the table above: neither vendor sits in a request path, and the AI coaching a member receives is generated by Google Cloud Vertex AI in the EU, listed above with everything else that runs the product.

One qualification belongs with that, because “we use AI development tools” and “AI development tools never touch production data” are different claims and only the first is true without conditions. Engineering and support work sometimes has to read or repair live records, during a data fix or an investigation into an incident, and an assistant used for that work sees what the engineer running it sees. That access is limited to the records the work needs and carries the same confidentiality obligation as any other staff access to the production database. It is maintenance of the Service under our data processing agreement, not a transfer of your people's data to a model vendor for their own purposes.

Services that are not sub-processors

Two services are reached by the product without processing personal data on our behalf, so they are recorded here with the reason rather than left as a gap for your reviewer to find.

YouTube. Exercise demonstrations are YouTube videos. The player is not loaded until a member taps play, so opening an exercise contacts Google not at all, and every video address is rewritten to YouTube’s no-cookie domain before it reaches the page. When a member does tap play, Google receives what any embedded player receives from a browser: the IP address, the browser user-agent, and which video was asked for. Our referrer policy sends the site address only, so the page the member was on, and therefore which exercise they were working through, is not passed along with it. We send Google no account identifier, no coaching content and no health or training record, and the request comes from the member’s browser rather than from our servers. Google decides its own purposes for what it does receive, which makes it an independent controller for the play rather than a sub-processor for us. YouTube is the only video provider we embed, and our content security policy permits no other.

Have I Been Pwned. When a member sets or changes a password we check it against the public breach corpus. The check hashes the password on our own servers, sends only the first five characters of that hash, and compares the returned list in our own process. The password, the full hash, the member’s identity and their email address never leave the application, which is the design of that API. No personal data is transferred, so the service is not a sub-processor.

Questions

For anything this page does not answer, including a diligence questionnaire your organisation needs completed, write to info@triagemethod.com. The rest of the procurement pack lives at security and data flows.