Sub-Processor Register

All third-party processors that handle personal data on behalf of Standard Intelligence Limited. Customers are notified of changes to this list at least thirty days before a new sub-processor is engaged, unless the change is required by law or to address an active security incident.

The data controller (the customer) authorises the use of these sub-processors under the terms of our Data Processing Agreement.

Active sub-processors

LinkedIn controller-to-controller note. LinkedIn Marketing Solutions Ireland UC is the data controller for the LinkedIn Ads platform; SI's use of LinkedIn Conversions API is a controller-to-controller transfer of hashed conversion data for ad attribution rather than a strict Art 28 processor relationship. We include it in this register for full transparency about every external recipient of personal data, even where the recipient is itself a controller of the receiving system.

Data residency invariant. Every sub-processor in the production data path is EU/UK hosted. One position to call out:

AI inference (LLM classification) — EU-hosted. All customer-data AI inference is processed within the EU; no customer personal data is transferred outside the EU on the inference path. Inputs are user-authored free-text AI-system descriptions — not intended to contain personal data, but as free-text under customer control they may include it; any personal data present is covered by SI's DPA + SCCs and processed under zero-retention. The inference sub-processor is one of: Mistral AI (EU, France — already engaged for embeddings) or Anthropic Claude served from an EU region via a cloud provider (AWS Bedrock or Google Vertex). The inference payload contains only the AI-system profile fields; SI account identifiers (user, email, tenant) are not sent to the inference provider. Customers can elect to disable LLM features at the tenant level.

Internal tools (not sub-processors)

These services hold Standard Intelligence's own data only (staff accounts, source code, CI artefacts, or SI-authored content) and do not act on customer personal data. They are listed for transparency.

DSAR cascade (GDPR Article 17)

Erasure requests cascade to every sub-processor holding identifiable personal data. The handler for each:

Neon — soft-delete users row, pseudonymise audit_events via erasure_salt (docs/system/database.md §GDPR erasure pattern).

Zitadel — user deletion via Zitadel Admin API; ID-token claims invalidated on next request.

Stripe — customer object deletion via API; payment-method tokens revoked.

HubSpot — contact deletion via DELETE /crm/v3/objects/contacts/{contactId}.

Resend — no contact store; transactional logs auto-expire per Resend retention.

Sentry — events keyed by request ID (no PII); user-scoped events purged via Sentry API where applicable.

LinkedIn Marketing Solutions Ireland UC — LinkedIn Conversions API events sent via POST /rest/conversionEvents are stored by LinkedIn for attribution and reporting; LinkedIn does not currently expose a public per-event delete API on the conversion data. The hashed email used as the conversion key ages out per LinkedIn Marketing Solutions retention. When SI receives an erasure request we (a) stop sending further LinkedIn CAPI events keyed to that email (so no new attribution rows are written), and (b) record the erasure in our DSAR audit trail. Visitors may exercise their LinkedIn-side rights directly via LinkedIn Privacy Center; we surface that route in our DSAR response when the requester also has a LinkedIn account.

Mistral, Anthropic, Neo4j Aura, Sanity, Vercel (analytics is a per-request hash with no persistent identifier — nothing to purge), Plausible (cookieless analytics with no PII), and Inngest do not store identifiable personal data in the production data path and therefore are not in the cascade chain. The DSAR runbook covering these handlers is tracked separately (see docs/system/observability.md and the open follow-up issue on the customer-trust workstream).

Review cadence

This register is reviewed at each release-planning gate and whenever a new sub-processor is added or a region change is announced by an existing one. The next scheduled review aligns with the R3 gate.

Change log