Sub-processors, ISMS Copilot API
Effective Date: 2026-07-26.
This list discloses the sub-processors ISMS Copilot (Better ISMS) engages to provide the ISMS Copilot API, the OpenAI-compatible developer endpoint at api.ismscopilot.com. In the API, the Customer is the Controller of the personal data it sends in Requests and ISMS Copilot is the Processor; the entities below that process Request Content are sub-processors.
Scope. This list covers the ISMS Copilot API only, and is distinct from the sub-processors for the ISMS Copilot chat product shown on the trust center home page and from the Partner Embed sub-processor list. One entity (Stripe) is listed for completeness as the billing vendor: it processes the Customer's own billing data for credit top-ups, not Request Content, and is not an Art. 28 sub-processor of Request Content. See the API DPA and API Terms of Service for the governing terms.
How the ISMS Copilot API processes your requests
Two processing modes, selected by the model alias you call.
- EU mode (
isms-fast-eu,isms-thinking-eu). Your Request is processed by Mistral AI in the EU (mistral-small-2603), with no transfer of AI-model processing outside the EEA and no persistent retention of your content. Call these aliases where you require EU-based processing. - Global mode (
isms-fast,isms-thinking), the default for the bare aliases. Your Request is first received by OpenRouter, Inc. (a United States company), a routing aggregator, and served by thez-ai/glm-5.2model on a closed set of three inference hosts: Together AI (US), Fireworks AI (US), and Inceptron AB (Sweden, EU). The OpenRouter hop and two of the three hosts are US-based, and the per-request inference region is not pinned. Calling a bare alias transfers your Request to and processes it in the United States (except where a Request is served by Inceptron in the EU).
Processing-region header. Every successful response includes an x-isms-processing-region header (eu or global) so you can confirm which processing mode served the Request and route or alert on it. It confirms the mode, not the physical inference region, and it arrives with the response (after processing).
Retention. ISMS Copilot does not store Request Content or model outputs as persistent customer records in its own API data layer. Processing of Request Content for inference is transient. On error paths, a provider error response may appear in operational logs or Sentry and may include prompt text. Sentry scrubs credential material from error telemetry. Free-text prompt content is not guaranteed to be stripped. On the global-mode path, OpenRouter is configured for zero data retention on zero-retention endpoints (no persistent retention of Request Content beyond serving the Request; transient in-memory caching may occur during processing). On the EU-mode path, Mistral processes under its EU zero-retention posture. Separately, ISMS Copilot retains usage and billing metadata (token counts, cost, model, timestamps, a key identifier, an account identifier) as an independent controller for metering, billing, fraud prevention, service security, and statutory accounting and tax obligations (DPA §7.2). Your content is not used to train any model.
Sensitive data. By default you must not send special-category (Art. 9) or criminal-offence (Art. 10) personal data through the API. The default prohibition is lifted only where you have established a lawful condition, notified ISMS Copilot in writing, and the parties have executed a written sub-processor addendum expressly covering the category (DPA §1.4).
Your controller responsibilities. You are the Controller of the content you send; ISMS Copilot processes it on your documented instructions as your processor. You are responsible for the lawful basis of the personal data you include in Requests, for not sending categories the Service does not permit, and for informing your own data subjects (including the applicable sub-processor, third country, and transfer mechanism by mode, DPA §6.4).
Your options. To keep your processing in the EU, call the -eu aliases. Use the x-isms-processing-region header to verify which mode served each Request. To object to the global-mode path on data-protection grounds, or to request the DPA, sub-processor list, or transfer-assessment information, contact privacy@ismscopilot.com.
Infrastructure and observability sub-processors (all API traffic)
| Sub-processor (legal entity) | Purpose | Data processed | Region / transfer |
|---|---|---|---|
| Fly.io, Inc. (US) | Compute hosting for the API backend | Request Content in transit and at process; not persisted | EU deployment. US-incorporated entity processes under SCCs. |
| Supabase, Inc. (US) | Database for the API metadata tables (private.api_*: API-key hashes, usage and credit ledger) | API-key SHA-256 hashes, usage and billing metadata; no Request Content | Data at rest in the EU (production project region). To the extent a US-incorporated entity can access EU-stored data, that access is treated as a transfer under SCCs. Sub-processor: AWS. |
Kong (API gateway for api.ismscopilot.com) | Authentication forwarding and rate limiting at the gateway | Request/response in transit; edge metadata | Managed-gateway component; where provided by Kong Inc. (US) as a managed service, under SCCs. |
| Functional Software, Inc. dba Sentry (US) | Error monitoring | Operational error fragments and pseudonymous identifiers. Sentry scrubs credential material. Provider error payloads can include prompt text, so Sentry may receive Request Content on error paths and is a Request Content sub-processor for those events. | EU ingest; US entity; SCCs. |
| Stripe, Inc. / Stripe Payments Europe, Ltd. (billing vendor, not a Request Content sub-processor) | Credit top-up billing | Customer billing data; no Request Content | EU (Stripe Payments Europe, IE) / US. |
AI model sub-processors (by mode)
The AI provider that processes a Request depends on the model alias you call. Alias selection determines the sub-processor.
| Mode | Model | Data-path AI sub-processor(s) (legal entity) | Residency / transfer | Retention posture |
|---|---|---|---|---|
EU (isms-fast-eu, isms-thinking-eu) | mistral-small-2603 | Mistral AI SAS (France) | EU (France). No transfer of AI-model processing outside the EEA. | Zero-retention EU path (no persistent retention beyond serving the Request). No training. |
Global (isms-fast, isms-thinking) | z-ai/glm-5.2 | OpenRouter, Inc. (US) = router/aggregator and the US importer that first receives Request Content; Together AI, Inc. (US), Fireworks AI, Inc. (US), and Inceptron AB (Sweden, EU) = the closed three-host inference set. | United States transfer for the OpenRouter hop and for US hosts. Pinned in code to the closed non-PRC three-host set (two US, one EU) with the account-level PRC-blocklist, so the Service is configured not to route Request Content to a PRC endpoint (a control based on the pin, blocklist, and documented provider footprints, not an absolute per-request physical-region attestation). The Art. 46 ground for the first hop is OpenRouter's own executed DPA/SCCs (Module Two; DPA §4.3). For onward US hosts, OpenRouter procures each host's transfer instrument under its onward-transfer obligation; Better ISMS's Art. 28(4) flow-down sits alongside that chain. The OpenRouter-to-Inceptron hop is intra-EEA. No host in this pin is EU-US Data Privacy Framework-certified, so the transfer rests on Art. 46 SCCs plus supplementary measures, not on any Art. 45 adequacy basis (DPA §4.4). OpenRouter does not pin per-request region. | Zero-retention (no persistent retention beyond serving the Request; transient in-memory caching only): OpenRouter account-level mandatory ZDR, with in-request ZDR flags, layered on each host's no-retention posture. No training. |
Global-mode routing
The global mode resolves z-ai/glm-5.2 through OpenRouter, pinned in code to a closed three-host set: Together AI (US), Fireworks AI (US), and Inceptron AB (Sweden, EU). The pin is code-enforced and is the disclosure boundary; it is never widened without a fresh sub-processor notice. It is layered on the OpenRouter account-level controls: mandatory Zero Data Retention (routing only to zero-retention endpoints), training-disallowed, publication-disallowed, closed allowlist, and a PRC-jurisdiction blocklist, plus in-request zero-retention flags. Within the pin, a Request can be served by any of the three hosts (including on failover). OpenRouter does not pin the per-request inference region.
No Data Privacy Framework anchor on this pin. The API global-mode host set for z-ai/glm-5.2 contains no EU-US Data Privacy Framework-certified host. The global-mode transfer therefore rests on Article 46 SCCs plus supplementary measures (zero-retention, no-training, closed pin, PRC-blocklist, TLS), not on Article 45 adequacy.
Global mode: no PRC-hosted inference
The global-mode path is configured not to route Request Content to a PRC endpoint. z-ai/glm-5.2 is an open-weights model of Chinese authorship; model authorship is separate from where the weights run. The weights are served only on the closed three-host set above (two US, one EU), and Z.AI's own first-party inference endpoint is blocked at the OpenRouter account level. This is a selection based on the providers' documented footprint and the account-level blocklist, not an absolute per-request physical-region attestation: OpenRouter does not provide per-request inference-region pinning. The model author does not receive Request Content when the open weights are served on those hosts, so it is not a sub-processor of Request Content. Model provenance (open-weights software of PRC authorship, hosted in the US/EU) is disclosed in DPA §3.3 and ToS §5.
Customers with model-sourcing restrictions in their own contracts or internal policies should review the applicable terms in the API DPA (§3.3) and API ToS (§5); to keep processing in the EU on an EU-authored model, call the -eu aliases (Mistral, EU).
Not sub-processors of Request Content (current configuration)
These are version-dependent statements tied to the current API configuration and change control, not permanent guarantees; a route or feature change updates this list.
- Anthropic, xAI (Grok), OpenAI, Google Gemini: the API routes Request Content only to Mistral (EU mode) and to
z-ai/glm-5.2via OpenRouter (global mode). It does not route to Anthropic Claude, xAI (Grok), OpenAI, or Google Gemini. Any such provider path present in the wider codebase is not invoked by the API and would require a sub-processor notice before any Request Content reached it. - Stripe: processes Customer billing data for credit top-ups only, not Request Content.
Change notification
New or replaced sub-processors for Request Content are announced via the account and this trust center at least 30 days before they take effect, per DPA §3.2. For an urgent security-driven replacement ISMS Copilot may act on shorter notice, but will notify promptly with reasons and preserve the DPA §3.2 objection-and-termination remedy. Customers may object per DPA §3.2; the immediately-actionable EU alternative is to call the -eu aliases.
Notes
- EU mode residency. EU for AI-model inference (Mistral, France) and for the metadata store at rest (Supabase, EU region). It is not literally EU end-to-end, because the infrastructure and observability providers (Fly.io, Supabase, Kong, Sentry) are US-incorporated (electronic-access transfer risk) and process under SCCs; no non-EU AI model provider is on the EU-mode path.
- Global mode. The first hop (Better ISMS to OpenRouter, US) is on OpenRouter's own executed DPA/SCCs (Module Two; DPA §4.3). Onward US hosts are Together AI and Fireworks AI, under OpenRouter's onward-transfer chain plus Better ISMS's Art. 28(4) flow-down. Inceptron AB is established in Sweden (EU); the OpenRouter-to-Inceptron hop is intra-EEA. There is no DPF adequacy anchor in this pin (DPA §4.4). Routing to a PRC endpoint is closed by the non-PRC host pin and the account-level PRC-blocklist.
- OpenRouter as a US importer. OpenRouter, Inc. is not a mere pass-through router: it is a US importer that first receives Request Content and maintains its own US-region hosting and request-metadata surface (DPA §4.6).
- Art. 28(2)/(4). Disclosure of the AI sub-processors is necessary but not sufficient; the DPA contains the Art. 28(4) flow-down obligation (DPA §3.4) and the international-transfer terms (DPA §4).
This API Sub-processor List is published by Better ISMS (ISMS Copilot). Data-protection questions: privacy@ismscopilot.com.