> ## Documentation Index
> Fetch the complete documentation index at: https://docs.turncall.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Compliance

> How TurnCall's controls map to GDPR and HIPAA, and what stays your responsibility

This page maps TurnCall's privacy and security controls to the GDPR and then to HIPAA, so a security review can see which requirement each one helps you meet and where the work is still yours.

<Warning>
  TurnCall holds no certification or attestation: not HIPAA, not SOC 2, not ISO 27001. Nothing here is legal advice. A self-hosted TurnCall is software you run, and whether your deployment complies is decided by how you run it and by your own counsel, not by this page. The controls help; they do not make a deployment compliant on their own.
</Warning>

What stays yours, in short: agreements with the vendors who hear your calls (DPAs, BAAs), the infrastructure TurnCall runs on, who can reach it, backups, the carrier's own recording copy, the call record (whose numbers and `metadata` are neither redacted nor deleted by retention), text conversations (which retention does not cover yet), and audio (which redaction does not cover yet). [What stays yours](#what-stays-yours) has the full list.

## The controls

| Control | What it does | Guide |
| - | - | - |
| **Redaction** | Replaces callers' PII (phone numbers, emails, card numbers, SSNs, IBANs by default) with `<ENTITY_TYPE>` in what a project stores or sends about its calls: the transcript, the event log, webhook events, post-call analysis and takeaways, tool invocations, logs and spans. Not in the call record itself: its numbers and `metadata` are kept as they were. Detection runs inside your deployment. The agent, call-init and tool webhooks are never redacted. Opt-in per project. | [Redaction](/guides/redaction) |
| **Caller numbers off spans** | `PIPECAT_TRACE_INCLUDE_PII` defaults to `false`, so the call span's caller and called numbers are left off unless you opt in. It covers only those attributes: for a project without redaction, the STT and LLM spans carry the transcript and the model's input and output, so a number the caller says still reaches your tracing backend. A redacting project's spans are redacted too. | [Observability](/guides/observability) |
| **Retention** | How long a project keeps its calls' recordings, transcripts and events, per project and per agent. A janitor deletes what has expired. Unset, everything is kept. The call record itself (numbers, `metadata`, times) is never deleted by retention. | [Retention](/guides/retention) |
| **Recordings** | Every voice call is recorded to your own storage (local disk or S3). There is no setting that turns recording off; to keep audio briefly, set `recordings_days` (1 day is the shortest). | [Retention](/guides/retention#what-each-kind-covers) |
| **Audit log** | Every change made through the API to agents, credentials, phone numbers, API keys and project settings, keyed by the API key that made it. Append-only, kept until the operator's `AUDIT_LOG_RETENTION_DAYS`. | [Audit log](/guides/audit-log) |
| **Self-hosting** | TurnCall runs in your cloud, against your Postgres, Redis and object storage. Call data goes only to the providers, carrier, storage and endpoints you configure; no TurnCall service receives it. | [Kubernetes](/guides/kubernetes) |
| **Encrypted project credentials** | A project's provider keys, and a phone number's own Twilio auth token, are encrypted at rest with Fernet (AES-128-CBC with an HMAC-SHA256 tag) under `CREDENTIAL_ENCRYPTION_KEY`, and no read returns them. API keys are stored as an HMAC-SHA256 hash keyed with `API_KEY_HASH_SECRET`, never as the raw key. | [Project credentials](/guides/providers#project-credentials) |
| **Signed webhooks** | Webhook events, call-init requests and tool webhooks (when the tool has a `webhook_secret`) carry an HMAC-SHA256 signature over the timestamp and body. The signing secrets are stored unencrypted (see the limits below). Inbound carrier webhooks are verified: Telnyx's Ed25519 signature always; Twilio's signature unless no Twilio auth token is configured anywhere (neither `TWILIO_AUTH_TOKEN` nor a number's own account); WhatsApp's `X-Hub-Signature-256` when `WHATSAPP_APP_SECRET` is set. | [Signature verification](/guides/server-events#signature-verification) |

Some limits of these controls matter to a review:

* **Redaction is not anonymisation or de-identification.** Recall is the detector's: spelled-out numbers and misheard names are missed, and `PERSON` and dates are not in the default. Redacted data is still personal data, and redacted PHI is still PHI.
* **The call record is kept raw, and kept.** `GET /v1/calls/{id}` returns the caller's and called numbers and the call's `metadata` as they were, whether or not the project redacts, and retention never deletes the call record. Only deleting the project removes it, at the purge.
* **A call live when redaction is turned on is partly raw.** The transcript lines stored before the change stay as they were, in the transcript read and in that call's `call.ended`.
* **Only project credentials are encrypted by TurnCall.** Call data (recordings, transcripts, events, analysis) is stored as it is, so encrypt your database, volumes and bucket at rest. These secrets are stored unencrypted ([#338](https://github.com/kobikis/turncall/issues/338)): webhook subscriptions' signing secrets, a phone number's call-init `server_url_secret`, and in an agent's config its `server_url.secret`, MCP servers' `headers` and `env`, `llm.api_key`, static AWS keys in `config.aws` and a tool's `webhook_secret`. Anyone with a database dump or backup can read them, and with a signing secret can sign a forged event or call-init request that your receivers accept. Keep provider keys in project credentials, and protect dumps and backups as you would the secrets.
* **Twilio and WhatsApp webhooks can go unverified.** With no `TWILIO_AUTH_TOKEN` and no phone number bringing its own Twilio account, TurnCall accepts Twilio's voice and SMS webhooks without checking their signature ([#337](https://github.com/kobikis/turncall/issues/337)). Without `WHATSAPP_APP_SECRET`, it accepts WhatsApp's the same way ([#339](https://github.com/kobikis/turncall/issues/339)). Set both in production.
* **TurnCall does not refuse an `http://` webhook URL** ([#340](https://github.com/kobikis/turncall/issues/340)). Use `https://` for webhooks, call-init and tools, and serve the API over TLS (the Helm chart's Ingress does).

## GDPR

Article numbers refer to Regulation (EU) 2016/679. You are the controller for your callers' data, or a processor for your customer; either way, these controls support obligations that remain yours.

| Control | Articles | How it helps |
| - | - | - |
| Redaction | Art. 5(1)(c) data minimisation; Art. 25 data protection by design and by default | Personal data the conversation carried is kept out of what is stored and sent after the call: transcripts, analysis, webhook events to your other systems, logs and traces. The call record's numbers and `metadata` are not minimised. Detection is local, so redaction adds no processor. |
| Caller numbers off spans | Art. 25(2) data protection by default; Art. 5(1)(c) | The call span's numbers reach a tracing backend (often a third party) only by a deliberate choice. What the caller says reaches it on the STT and LLM spans unless the project redacts. |
| Retention | Art. 5(1)(e) storage limitation | Recordings, transcripts and events are deleted after a period you set, per kind, and the call record says what was deleted and when. The call record itself, with the caller's number and the call's `metadata`, is not deleted by retention. |
| Recordings (short retention) | Art. 5(1)(c), 5(1)(e) | Audio is the hardest data to minimise; a short `recordings_days` limits how long it exists. |
| Audit log | Art. 5(2) accountability; Art. 24 responsibility of the controller | A record of which key changed what, when, so you can show how agents, credentials and settings (redaction, retention) were configured over time. |
| Self-hosting | Art. 28 processors; Art. 44 to 49 transfers to third countries | TurnCall is not a processor of your call data, and you choose the region it runs in. Your providers still are processors (see below). |
| Encrypted project credentials | Art. 32(1)(b) confidentiality of processing systems | A database dump or backup does not expose the provider keys kept in project credentials, which reach your callers' data. The keys are not personal data, and this is not encryption of personal data under Art. 32(1)(a): see the limits above. |
| Signed webhooks | Art. 5(1)(f) integrity and confidentiality; Art. 32(1)(b) | Your receivers can tell an event signed with their secret from one that is not, while the secret has not leaked (it is stored unencrypted). TurnCall rejects forged Telnyx webhooks, and forged Twilio and WhatsApp webhooks once a Twilio auth token and `WHATSAPP_APP_SECRET` are configured. |

Not covered by any control here:

* **Erasure on request (Art. 17).** There is no route that deletes one call or one caller's calls. Retention deletes by age, and never the call record. `DELETE /v1/chat/sessions/{id}` only ends a chat session: its messages stay. Deleting a project deletes its recordings at once and the rest of its data at the purge (`PROJECT_PURGE_RETENTION_DAYS` after the delete, 30 days by default; `0` turns the purge off, and the deleted project's data is then kept). Answering an individual's erasure request is yours, in your database and storage, and at your providers and carrier.
* **Access requests (Art. 15).** The API reads a call's record, transcript, events and recording by call id; finding every call of one person is yours.
* **Records of processing (Art. 30), DPIAs (Art. 35), breach notification (Art. 33 and 34)** and **telling callers** they are being recorded and how their data is used (Art. 13) are yours.

## HIPAA

Section numbers refer to 45 CFR Part 164: the Security Rule (Subpart C) and the Privacy Rule (Subpart E). If you handle protected health information (PHI) on behalf of a covered entity, you are its business associate; TurnCall, as software you run, is not.

| Control | Provisions | How it helps |
| - | - | - |
| Redaction | §164.502(b) and §164.514(d) minimum necessary | Limits the PHI that reaches your webhook consumers, logs and tracing backend. It does not de-identify: the default types do not cover all the identifiers §164.514(b)(2) lists (names, dates and geographic data among them), and recall is not complete. |
| Caller numbers off spans | §164.502(b) minimum necessary | The call span's caller and called numbers stay out of traces unless you choose otherwise. For a project without redaction, the STT and LLM spans still carry what the caller said. |
| Retention | §164.310(d)(2)(i) disposal (in part) | Expired recordings, transcripts and events are deleted from TurnCall's database and storage. The call record (the caller's number, the call's `metadata`) is not. HIPAA sets no retention period for PHI itself; your policy and state law do. Backups and replicas are yours to expire. |
| Recordings (short retention) | §164.502(b) | Keeps call audio, which redaction does not touch, for as short a time as you choose. |
| Audit log | §164.312(b) audit controls; §164.308(a)(1)(ii)(D) information system activity review | Records changes through the API to agents, credentials, phone numbers, API keys and project settings. It does not record changes to webhook subscriptions, tools, knowledge bases, campaigns or the suppression list, though subscriptions and tools decide where call data is sent; nor who read a call, transcript or recording. Entries name an API key, not a person. If you rely on the log as Security Rule documentation, §164.316(b)(2)(i) asks for six years: leave `AUDIT_LOG_RETENTION_DAYS` unset or set it to at least 2192. |
| Self-hosting | §164.308(b)(1) and §164.314(a) business associate contracts | No TurnCall service stores or receives PHI, so there is no BAA with TurnCall to sign for the engine. You still need one with every vendor that does (see below). |
| Encrypted project credentials | §164.312(a)(1) access control; §164.312(d) person or entity authentication | Protects the keys that authenticate TurnCall to your providers. It is not encryption of ePHI at rest (§164.312(a)(2)(iv)): that is your database's and bucket's. |
| Signed webhooks | §164.312(c)(1) integrity; §164.312(e)(2)(i) integrity controls; §164.312(d) | Your receivers can verify that an event was signed with their secret and not altered in transit. That proves it came from TurnCall only while the secret, stored unencrypted, has not leaked. Transmission encryption (§164.312(e)(2)(ii)) comes from using HTTPS, which TurnCall does not enforce. |

Access control (§164.312(a)(1)): API keys are scoped to a project and carry a role (`admin`, `developer`, `viewer`), and settings such as redaction, retention and the audit log need an admin key. A key is not a person, so unique user identification (§164.312(a)(2)(i)) needs one key per person or service.

## What stays yours

* **Agreements with your vendors.** Redaction never applies to what the agent hears: your STT, LLM and TTS providers receive the caller's raw audio or words, and post-call analysis, takeaways and knowledge base embeddings send text to your LLM and embedding providers. A DPA (GDPR) or BAA (HIPAA) with each, and with your carrier (Twilio, Telnyx, your SIP trunk, Meta for WhatsApp), your cloud and your tracing backend, is yours. Your own call-init and tool servers receive raw values too. Running the LLM yourself (Ollama, or any OpenAI-compatible endpoint) removes one vendor; STT and TTS still go to the provider you choose.
* **The infrastructure.** Encryption at rest of Postgres, Redis, volumes and the bucket; TLS at your ingress; network policy; patching; and the database owner, who can drop the audit log's trigger.
* **Access control.** Who holds admin keys, the platform key (`PLATFORM_API_KEY`), `CREDENTIAL_ENCRYPTION_KEY` and `API_KEY_HASH_SECRET`, and who can reach the database and storage directly.
* **The call record.** Its numbers and `metadata` are kept as they were, not redacted, and retention never deletes it. Keep personal data out of `metadata` if you can, and remove records yourself when you must.
* **Backups.** Retention deletes from the live database and storage, not from your backups, snapshots or replicas. Backing up, restoring and expiring them is yours.
* **The carrier's recording copy.** TurnCall records calls itself. If your carrier records them too, TurnCall deletes a Twilio copy it was told about, on an account it holds credentials for; any other copy stays with your carrier until you delete it there or turn carrier recording storage off. See [Retention](/guides/retention#what-it-does-not-touch).
* **Text conversations.** SMS, WhatsApp and Chat API conversations are redacted (stored redacted once a session ends) but not covered by retention yet. Neither are campaign targets, the suppression list, knowledge base documents or eval scenarios. Deleting a chat session keeps its messages.
* **Audio.** Redaction is text only in this release: the recording is not bleeped. Keep it briefly with `recordings_days`.
* **Logs and webhook deliveries** that already left the server, in your log pipeline and at your webhook receivers.
* **Callers' rights and notices**: erasure and access requests, recording-consent and AI-disclosure notices, breach notification, and your own risk analysis.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.