Skip to main content
This page is a summary of Cymph’s security posture for security reviewers, architects and procurement teams. It covers both deployment models; where they differ, the difference is called out.

​
Deployment models

Cymph is delivered as a managed cloud tenant or as a self-hosted deployment. Both are dedicated single-instance deployments running the same product — neither is a shared multi-tenant service. What differs is who operates the infrastructure. Deployment models has the full responsibility split. A self-hosted deployment has no runtime dependency on Cymph: it does not call home for licensing, updates or telemetry — see Architecture for the full service inventory.

​
Trust boundaries

A deployment has exactly one externally exposed entry point: the nginx service, which terminates TLS and reverse-proxies to the application. The web application, API, embedding service and database are bound to an internal network only — none of them is published on the host — so every request that reaches the application has passed through TLS termination. There is no second, unencrypted path in. See Networking for the inbound and outbound specifics. Outbound, Cymph connects only to the integration endpoints you configure and to an AI provider if one is enabled. Semantic search embeddings are generated by a service inside the deployment, so playbook content is not sent anywhere for search to work.

​
Tenant and data isolation

Each customer deployment — managed or self-hosted — is a separate instance with its own database. There is no shared data store across customers. Within a deployment, Cymph uses logical data isolation: users and organisations share the instance while their data remains segregated. The isolation boundary is the workspace. Playbooks, executions, assets, integrations and presets all belong to a workspace, and access is determined by workspace membership:
  • Every user has a private individual workspace that nobody else can be added to.
  • Every organisation has a default workspace that all members join automatically, and which they leave automatically when they leave the organisation.
  • Organisation admins can create additional workspaces with independently managed member lists, so a subset of the organisation can work in isolation from the rest.
Workspaces covers the model in full, including how membership is managed. Organisation membership is a separate axis: a user belongs to one organisation at a time, and their role within it determines what administrative actions they can take and how widely they can share playbooks.

​
Encryption

In transit. All browser and API traffic is served over HTTPS. In a self-hosted deployment you supply the certificate and key and TLS is terminated at nginx — see TLS certificates; in a managed tenant Cymph provisions and renews them. Connections from the application to PostgreSQL can additionally require SSL, and are configured to do so whenever the database is not on the same host as the application. At rest. Sensitive integration data — the credentials, tokens and endpoint secrets you enter when configuring a SIEM, SOAR platform, ticketing system or repository — is encrypted before it is stored, using key material generated at random when the deployment is created. In a self-hosted deployment that key material (CYMPH_ENCRYPTION_KEY and CYMPH_ENCRYPTION_IV) is generated on your host and never leaves it. See Data protection for what this means for backups and key custody.

​
Authentication and authorisation

Accounts authenticate with a password plus optional TOTP multi-factor authentication, or through an external identity provider. Authorisation is role-based at the organisation level and membership-based at the workspace level. See Authentication & access control.

​
Auditability

Administrative and product activity is recorded and reviewable in the application, with actor, target and metadata per event. See Audit & logging.