| Service |
Purpose |
Company jurisdiction |
Where data is processed |
Transfer |
| Render |
Application hosting, database and disk |
United States |
EU — Frankfurt |
None required |
Evidence & details — Render →
- Legal entity
- Render Inc.
- What it does
- Application hosting, database and disk
- Company jurisdiction
- United States
- How we know
- Render Inc. is a US company (San Francisco, California). Stated from the vendor's own corporate identity and its DPA counterparty; there is no artifact in this repository that establishes it, and this field does not pretend otherwise.
- Where data is processed
- EU — Frankfurt, Germany
- How we know
- deploy-guide/DEPLOYMENT.md §2 instructs 'Region Frankfurt (EU) to match GDPR positioning', and the Postgres instance was CONFIRMED in the Render dashboard on 3 Aug 2026 (the security pack, §2). Postgres is the component that matters for residency because it is the only one that stores customer data.
- Verified on
- 2026-08-03
- Transfer mechanism
- EU hosting — no transfer required
- Region (summary line)
- EU (Frankfurt)
- Evidence file
- deploy-guide/DEPLOYMENT.md
- Evidence pattern
- Render
- Why this entry is here
- The deployment target. Not a code path — hosting is where the code runs, so the deploy guide is the artifact that proves it.
|
| Anthropic |
AI analysis of call transcripts |
United States |
United States |
EU SCCs |
Evidence & details — Anthropic →
- Legal entity
- Anthropic PBC
- What it does
- AI processing of call transcripts
- Company jurisdiction
- United States
- How we know
- Anthropic PBC, a Delaware public benefit corporation. Vendor corporate identity; no repository artifact establishes it.
- Where data is processed
- United States
- How we know
- lib.js requestedGeo: every analysis request sends inference_geo 'global' (or 'us' for a company that asks for US residency), so routing is Anthropic's global routing and is not pinned to the EU by Talqo. Corrected 29 Sep 2026: this said the call sets NO region parameter, which was true of DATA_FLOWS.md flow #1 when written and stopped being true when the geo receipt shipped. This is the one transfer outside the EEA and it is covered by SCCs. Stated plainly rather than softened: there is no EU processing on this path. The EU alternative is the Azure OpenAI entry below, which is opt-in per company.
- Verified on
- 2026-09-29
- Transfer mechanism
- Standard Contractual Clauses (EU SCCs)
- Region (summary line)
- US
- Evidence file
- lib.js
- Evidence pattern
- api\.anthropic\.com
- Why this entry is here
- The default analysis provider; the endpoint is called directly and receipted on every call.
|
| Azure OpenAI |
Alternative AI analysis, opt-in per company |
United States |
Customer-controlled |
Depends on your region |
Evidence & details — Azure OpenAI →
- Legal entity
- Microsoft Azure OpenAI
- What it does
- Alternative AI processing, opt-in per company and off by default
- Company jurisdiction
- United States
- How we know
- Microsoft Corporation, Redmond, Washington. Vendor corporate identity. Note that the EEA contracting entity for Microsoft Online Services is commonly Microsoft Ireland Operations Ltd; which entity Talqo contracts with has not been read from any agreement and is not asserted here.
- Where data is processed
- Customer-controlled — the customer's own Azure resource
- How we know
- lib.js 'ai_provider === 'azure'' routes to {company-resource}.openai.azure.com. Talqo owns no Azure resource, so the region is whichever one the customer created theirs in. EU IS ACHIEVABLE and is stated as a requirement at onboarding (Regional-EU or EU Data Zone), but a Global deployment can route outside the EU — so this row does NOT claim EU processing. It must be verified per configured endpoint hostname, by the customer, on their own tenant.
- Verified on
- 2026-08-19
- Transfer mechanism
- Depends on the region you deploy in — EU deployment needs no transfer; a non-EU deployment is covered by SCCs
- Note on the transfer mechanism
- Corrected 19 Aug 2026. This cell said 'EU hosting — no transfer required' while THIS SAME ROW declines to claim EU processing, because the deployment is the customer's own Azure resource and a Global deployment can route outside the EU. So the cell asserted no transfer for a path the row itself says may transfer. It was written when the row read 'EU — customer-controlled deployment', and survived the split that made the row honest. Caught by a second review the same day, one row above a transfer_note complaining about exactly this pattern on Microsoft 365 — the note named the defect class and did not look next door.
- Region (summary line)
- Customer's own Azure resource
- Evidence file
- lib.js
- Evidence pattern
- ai_provider === 'azure'
- Why this entry is here
- Per-company opt-in. Talqo owns no Azure resource; the deployment is the customer's.
|
| Microsoft 365 |
Inbound email to @talqo.dk addresses |
United States |
EU — Denmark |
None required |
Evidence & details — Microsoft 365 →
- Legal entity
- Microsoft Corporation — Exchange Online (Microsoft 365)
- What it does
- Inbound email for @talqo.dk, including hello@ — prospect enquiries and anything a prospect chooses to send us, which can include a call transcript
- Company jurisdiction
- United States
- How we know
- Microsoft Corporation, Redmond, Washington. Vendor corporate identity. As above, the EEA contracting entity may be Microsoft Ireland Operations Ltd; not read from any agreement, not asserted.
- Where data is processed
- EU — Denmark (Exchange Online, current geography); committed geography EU/EFTA
- How we know
- Read via the tenant admin’s authenticated session in the Microsoft 365 admin centre, 19 Aug 2026: Settings -> Org settings -> Organization profile -> Data location. Exchange Online shows CURRENT geography Denmark and CONFIRMED (committed) geography European Union / EFTA; Teams, SharePoint, OneDrive and Exchange Online Protection read the same. TWO FIELDS, TWO MEANINGS, and the row states both: 'current' is where the data sits today, 'committed' is what Microsoft undertakes to honour — the current location can move within the committed geography without notice, so the committed geography is the one a reviewer should rely on. EU/EFTA is broader than the EU: it also permits Norway, Iceland and Liechtenstein (EEA) and Switzerland (not EEA, but covered by an EU adequacy decision), so no Chapter V transfer arises anywhere inside it. GOES STALE IF: Microsoft migrates the tenant, or a different committed geography is requested. Re-read the same card to refresh. PROVENANCE, stated because this file has been burned by unattributed evidence: the reading is the operator's; no automated check can see an admin centre, and DNS cannot answer this question at all.
- Kind of evidence
- admin-center reading
- Verified on
- 2026-08-19
- Transfer mechanism
- EU/EFTA hosting — no Chapter V transfer required
- Note on the transfer mechanism
- Correct again by decision rather than by luck. This cell read 'EU hosting — no transfer required' even while data_processing_location said NOT VERIFIED — asserting no transfer while declining to say where processing happened. It is now backed by the admin-centre reading. Note the company remains US-incorporated: Chapter V is about where data goes, not where the parent is domiciled, so US ownership alone does not create a transfer.
- Region (summary line)
- US company · EU (Denmark) processing
- Evidence kind
- dns
- Evidence record
- talqo.dk MX -> talqo-dk.mail.protection.outlook.com; apex SPF v=spf1 include:spf.protection.outlook.com -all
- Evidence checked on
- 2026-08-18
- Why this entry is here
- THE ONLY ENTRY WITH NO CODE PATH, and it declares that rather than faking one. Talqo does not call Exchange Online; mail arrives there. Until 19 Aug 2026 this entry cited talqo-site/subprocessors.json — ITSELF — as its evidence_file, with a pattern that appears in this very note. It passed the reconcile guard tautologically: the one entry not backed by code was the one entry proving itself. evidence_kind 'dns' now says so out loud, and the guard refuses any entry that cites this file as its own evidence. NOTE THE TWO EVIDENCE KINDS, which answer two different questions: evidence_kind ('dns') labels evidence_record, the MX and SPF that prove Exchange Online RECEIVES our mail — that is what makes it a subprocessor at all. data_processing_location_evidence_kind ('admin-center reading') labels the separate residency evidence. Flipping the first to 'admin-center reading' was briefly done and was wrong: it relabelled the DNS record as something it is not. Verified against DNS on 18 Aug 2026. For INBOUND mail the MX record is not merely evidence of the integration, it IS the integration: mail addressed to talqo.dk is delivered there by the record itself.
|
| Resend |
Outbound transactional email |
United States |
EU — eu-west-1 |
EU SCCs |
Evidence & details — Resend →
- Legal entity
- Resend
- What it does
- Transactional email — user invitations, password-reset messages, the demo/support relay notification, and the weekly audit export
- Company jurisdiction
- United States
- How we know
- Resend, Inc., a US company. Vendor corporate identity; transfers are covered by SCCs auto-incorporated in its terms.
- Where data is processed
- EU (eu-west-1, Ireland) for the sending path — see the stated limit
- How we know
- DNS, re-checked 19 Aug 2026: send.talqo.dk MX is feedback-smtp.eu-west-1.amazonses.com and its SPF is 'v=spf1 include:amazonses.com ~all'. Resend sends through Amazon SES, and the endpoint provisioned for this domain is in eu-west-1 (Ireland). THE LIMIT, stated because the evidence does not reach further: this establishes the SES sending and feedback region. It does NOT establish where Resend's own API and control plane process a message before handing it to SES, which DNS cannot show. Anyone needing that answer must get it from Resend rather than from this file.
- Verified on
- 2026-08-19
- Transfer mechanism
- Standard Contractual Clauses (EU SCCs)
- Sending domain
- send.talqo.dk
- Region (summary line)
- EU (eu-west-1 sending infrastructure)
- Evidence kind
- runtime
- Evidence file
- lib/mailer.js
- Evidence pattern
- api\.resend\.com/emails
- Evidence record
- Production logs: 'mail_configured' at every boot, and 'mail_sent' events with provider message ids (17 and 19 Aug 2026). Plus DNS: send.talqo.dk feedback MX feedback-smtp.eu-west-1.amazonses.com and a DKIM key at resend._domainkey.talqo.dk
- Evidence checked on
- 2026-08-19
- Why this entry is here
- RE-ADDED 19 Aug 2026, hours after being wrongly removed the same day, and the round trip is the lesson. The removal rested on the belief that MAIL_API_KEY was unset and no mail had ever been sent. It is set, and mail has been sent. The proof is in the application's own log vocabulary: server.js emits 'mail_configured' ONLY in the else-branch of isSandbox(), so that line is literally unreachable when the key is missing, and 'mail_sent' with a provider id can only come from a real 200 from api.resend.com. Independently confirmed without log access by probing production: POST /auth/forgot for an unknown address returns the non-sandbox body, and that branch is chosen by MAIL_API_KEY alone. THE STANDING RULE THIS ESTABLISHES: an environment-dependent fact may never be asserted from reading code. The code shows what CAN happen; only the running system shows what DOES. Resend receives recipient addresses, reset links, the free text of a support message, and the weekly export attachment containing access-log emails and IP addresses.
|