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

# Data protection

> Where Cymph data lives, how sensitive data is encrypted, and who holds the keys.

## Where data lives

|                   | Managed cloud tenant                | Self-hosted                            |
| ----------------- | ----------------------------------- | -------------------------------------- |
| Application       | AWS `eu-west-1` (Europe / Ireland)  | Your infrastructure                    |
| Database          | AWS managed PostgreSQL, same region | PostgreSQL container in the deployment |
| Search embeddings | Generated inside the deployment     | Generated inside the deployment        |
| AI processing     | Your provider, or none              | Your provider, or none                 |

Each deployment is a dedicated instance with its own database — there is no shared data store across customers. In a managed tenant, data stays in the EU. In a self-hosted deployment, data never leaves your infrastructure except over connections you configure: the integration endpoints you point at, your SMTP server, your identity provider, and an AI provider if you enable one.

## What Cymph stores

A deployment's PostgreSQL database holds playbooks and their contents, execution records, assets, presets, user accounts, organisations, workspaces and their membership, integration configuration, and audit logs. Application logs, static files and data files live alongside it on disk.

In a self-hosted deployment this maps to two Docker volumes, `cymph_db-data` and `cymph_api-data`. [Architecture](/deployment/self-hosted/architecture) breaks down what is in each. In a managed tenant the same data sits on managed AWS database and filesystem services.

## Encryption in transit

All browser and API traffic is served over HTTPS. Self-hosted deployments terminate TLS at nginx using a certificate you supply — see [TLS certificates](/deployment/self-hosted/tls-certificates). Managed tenants use certificates provisioned and renewed by Cymph.

Connections from the application to PostgreSQL can require SSL. In a self-hosted deployment this is off by default, because the bundled database runs on the same host over an internal Docker network — enable it if you place the database anywhere else. Managed tenants use a managed database reached over the network, with SSL required.

Outbound integration connections use whatever transport the target endpoint offers — for HTTPS endpoints, that traffic is encrypted end to end between Cymph and your system.

## Encryption at rest

Sensitive integration data is encrypted before it is written to the database. This covers the credentials and secrets you supply when configuring an integration — API keys, tokens, passwords and endpoint secrets for SIEMs, SOAR platforms, ticketing systems and repositories.

Encryption uses a key and initialisation vector held in the deployment's configuration (`CYMPH_ENCRYPTION_KEY` and `CYMPH_ENCRYPTION_IV`), generated at random when the deployment is created. Each deployment has its own.

**In a self-hosted deployment, you hold this key material.** It is generated on your host, stored in the deployment's environment file, and is never transmitted to Cymph. This means:

* Cymph cannot decrypt your integration credentials, and cannot recover them for you.
* Anyone with read access to the host's configuration files can read the key. Restrict access to the deployment directory accordingly.
* The key cannot be regenerated. Losing it makes existing encrypted data permanently unreadable.

<Warning>
  Key custody is the single most consequential operational detail in a self-hosted deployment. A database backup taken without `.env` and `db/secrets.txt` is not a complete backup — it restores, but its integration credentials cannot be decrypted. See [Backup & restore](/deployment/self-hosted/backup-restore).
</Warning>

Passwords are not stored recoverably; account recovery issues a reset rather than returning an existing password.

## Backups

**Self-hosted.** Backups are yours to run, and yours to protect. The recommended method is a Docker volume snapshot taken during a maintenance window, archived together with the deployment's configuration files. Because those files contain the encryption key and signing secrets in plaintext, a Cymph backup archive is itself sensitive material and should be stored encrypted with access restricted. The full procedure, including restore, is in [Backup & restore](/deployment/self-hosted/backup-restore).

**Managed cloud tenant.** Backups are taken and retained by Cymph, within the same AWS region as your tenant. There is nothing for you to configure or run.

## Deleting data

Users can delete their own account, which removes it from the platform — see [Delete your account](/settings/delete_account). When the last member of an organisation leaves, the organisation is deleted with them.

Removing a member from an organisation does not delete the playbooks they created: those are **transferred to the organisation's administrator**, so work does not disappear when someone leaves. This applies both to removals and to voluntary departures. See [Manage members](/administration/manage_members).

## Auditability

Administrative and product activity is recorded with actor, target and metadata per event, and is reviewable and exportable in the application. See [Audit & logging](/security/audit-logging).