What we do with your calls, precisely.

Doing diligence? The questions your reviewer is about to ask — retention, subprocessors, export, deletion, cancellation, ownership, accuracy, and what we do not have — are answered on the due-diligence page, and how often we are wrong is measured and published on the accuracy page.

Where your data lives

Everything Talqo stores runs on EU infrastructure in Frankfurt, Germany — application, database and file storage. No production data leaves the EU except where a subprocessor is listed on our subprocessors page, with its transfer mechanism named.

By default, calls are analysed by Anthropic, whose routing is global rather than pinned to the EU, under the EU’s Standard Contractual Clauses. That is the one transfer outside the EEA, and it is optional:

Your own Azure OpenAI

Run it on your own Azure OpenAI. Every analysis can run on your company’s own Azure OpenAI resource, in the EU region you choose, under your own agreement with Microsoft. We connect it with you.

Nothing goes to the default provider. Once your company is set to Azure, every analysis runs on your resource, and a request to any other provider is refused before it is sent.

No quiet fallback. If Azure is unavailable, the analysis fails and can be retried. It is never re-routed.

Your key stays yours. It is encrypted at rest with AES-256-GCM, decrypted only in memory at the moment of a call, and never returned by any API.

Transcripts are not kept

A transcript is processed and discarded. We keep the structured output — the deal read, the scores, the receipts — not the conversation.

A transcript waiting in the queue is auto-purged after 30 days, whether or not it was ever processed.

Our AI subprocessor, Anthropic, processes transcripts under a DPA and EU Standard Contractual Clauses. Anthropic retains them for up to 30 days (longer only if flagged for trust and safety review) and never uses them for training.

Every analysis treats the transcript as data, never as instructions: a sentence in a call that reads like a command is analysed as something someone said, not obeyed.

How credentials are held

• Customer passwords: PBKDF2-SHA512, 100,000 iterations, unique salt per user. We cannot read them.
• Nobody but the account’s owner ever knows their password, including their own administrator. Talqo emails an invite; the new user sets their own.
• A password is reset only by a single-use link, valid for an hour, that the person uses themselves. Changing your own password or sign-in email needs your current password.
• CRM and AI credentials — your HubSpot token, your Salesforce connection, your Azure key, the Teams certificate, your webhook secret: AES-256-GCM encrypted at rest, decrypted only in memory at the moment of a call, never returned by any API. If encryption fails, nothing is stored.
• Ingestion API keys: hashed (SHA-256). Shown once at creation and never again.
• Webhook signing secrets: generated by us, never chosen by you, shown once, and rotated automatically whenever the endpoint changes.
• Webhook deliveries go only to public https addresses — checked again at every delivery — never follow a redirect, and carry a timestamped signature, so a captured delivery can’t be replayed.

If you connect Microsoft Teams

Teams auto-ingestion is off until you connect it. Connected, it is the one pathway where a call reaches Talqo without a person pasting it, so here is what it reads and what it keeps.

• The connection is yours. You register an application in your own Entra tenant. We generate a keypair, hand you the public certificate to upload, and hold the private half AES-256-GCM encrypted at rest, never returned by any API. A credential is stored only after it has minted a real token against your tenant — an unverified connection is a promise, and this codebase does not make those.
• We subscribe per mapped rep, not per tenant. A Graph subscription exists only for a rep you have mapped to a Talqo user. A meeting organised by anyone else produces a notification we refuse to act on, and the refusal is logged rather than swallowed.
• A notification carries no content. Graph tells us a transcript exists; it does not send one. We fetch it over TLS with the credentials of the company that owns that subscription. A notification whose clientState does not match the value we set at subscribe time is rejected as a possible spoof, and one whose mapping now resolves to a different company is refused rather than fetched with the wrong tenant’s key.
• Speaker attribution is required. If your tenant has it switched off, Graph returns a transcript without speakers and we decline to ingest it. Without speakers we could attribute a sentence to the wrong person, and a receipt naming the wrong speaker is worse than no receipt.
• Nothing analyses itself by default. An ingested transcript lands in the same queue as a pasted one. It is analysed automatically only where you have switched that on for your company and the rep is mapped; otherwise it waits for a one-tap approve, and an admin decides whether it becomes a call at all. Rejecting it deletes the content immediately.
• Graph access runs inside your own Microsoft agreement — it adds no subprocessor to Talqo’s chain. We read from your tenant with credentials you issued, so Microsoft is processing there for you, under the agreement you already hold with it. A subprocessor is something we instruct on your behalf; here we instruct nothing. That is why Microsoft Graph does not appear on our subprocessor list and Azure OpenAI does — with Azure we send transcript content out and ask for analysis, which is sub-delegation whoever owns the resource.
• Then it follows the rule above. Analysed, the transcript is discarded and the structured output kept. Unanalysed, it is auto-purged after 30 days like anything else in the queue. Teams ingestion adds a door into that queue; it does not add a place transcripts are stored.

Disconnecting removes the credentials and drops the subscriptions we hold for your company. Calls already analysed stay yours, and stay deletable.

Who can see what

Access is scoped by role, and enforced on the server — not by hiding buttons. A rep sees their own calls. A manager sees their direct reports. An admin sees their company. No customer role reaches another company’s data.

Talqo’s own operator account can open a customer’s workspace, for support. Viewing it as one of your users starts a session that lasts at most an hour; its start is recorded, and so is its end when the operator signs out. We do not yet keep a tenant-wide log of every operator read — it is on the list below.

And nothing about a person is hidden from that person: every word a manager reads about a rep, the rep reads too. That is the mirror rule, and it is enforced in code and locked by tests.

What is written down

Every CRM write is audited: the field, the old value, the new value, who approved it, when, and — for the stage, the next step and the buyer’s figure — the quote that justified it. On Salesforce and HubSpot, any write can be undone for seven days, as long as nobody has changed the field since. Deletions are logged. Data-subject exports and erasures are logged.

Retention is set per company, and there is a dry run so you can see exactly what a purge would remove before it removes it.

If Talqo cannot read its database when it starts, it refuses to start rather than start empty, and writes nothing.

The app sends HSTS and a locked-down permissions policy on every response.

Your rights, and how to use them

Export or erase any individual’s data on request, from the admin panel, with the result logged. Erasing a person reaches everything Talqo holds about them — including queued transcripts and frozen quarterly reports — and a dry run lists all of it before anything changes. We support access, rectification, erasure, restriction and portability requests under GDPR. Contact hello@talqo.dk.

Reporting something

hello@talqo.dk. Tell us what you found and how to reproduce it. We will confirm receipt within one working day and tell you what we are doing about it.

In scope: talqo.dk and app.talqo.dk. When you test, use an account of your own and stop at the smallest proof that shows the problem. Please do not read, change or keep other customers’ data, do not attack availability, do not send anything to a customer’s CRM, and do not try to trick our staff or customers. Give us a reasonable time to fix it before you publish, and tell us if you would like to be credited.

If you keep to that, we will treat your report as help and we will not take legal action against you for it. The same details are in our security.txt.