Security

Encryption

All traffic to Chirply is served over TLS 1.2 or higher. Data at rest in the primary database and in object storage is encrypted by the storage layer.

Third-party provider credentials and OAuth access tokens carry a second layer of application-level AES-256-GCM encryption, so a database disclosure alone does not yield working credentials for a customer's Twilio, Mailgun, Stripe, or Meta account.

Access control — tenant isolation

Separation between customer workspaces is enforced in the database with PostgreSQL row-level security, not in application code. Policies resolve access through audited SECURITY DEFINER helpers, and an automated suite asserts that every table carries RLS and that no privileged function is callable anonymously.

Access control — roles

Access within a workspace is role-based (owner, admin, member). The public API, the MCP server, and the in-app assistant enforce the same role requirements as the user interface, verified by an automated conformance test, so an integration can never do more than the person who authorised it.

Access control — staff

Administrative access to production is limited to named platform administrators. Staff access to a customer workspace for support is explicit, role-gated, and recorded in the workspace's own activity log.

Secret management

Runtime secrets are held in the hosting platform's secret store, are scoped per service, and are never present in the source repository or in build artefacts. Service-role database credentials are server-only and cannot be reached from browser code.

Pseudonymisation and minimisation

Session recordings mask every value a visitor types — including email addresses, phone numbers, and free text — in the browser before anything is transmitted; the masking is not a setting a site can switch off. Password, hidden, and file inputs are excluded outright, and canvas content is never captured.

Visitor tracking honours the browser's Do Not Track and Global Privacy Control signals, and, where a workspace has enabled consent management, collects nothing at all before the visitor has consented.

Resilience and availability

The application runs on a globally distributed edge platform with automatic failover between locations. The database is managed, replicated, and monitored by the provider.

Backup and restoration

The primary database is backed up continuously with point-in-time recovery. The recovery window is seven days. Customers who need a longer retrievable history should use the self-service workspace export or configure scheduled backups to their own storage.

Monitoring and incident detection

Every uncaught server and browser error in production is captured, grouped by cause, and triaged from an internal queue daily. Regressions reopen automatically when a previously resolved fault recurs after a deployment.

Secure development

Changes reach production only through an automated pipeline from the main branch. A full type check and unit suite gate every deployment, and a failing suite stops the release before anything is built. Direct manual deployment from a developer machine is prohibited by policy.

Vulnerability management

Dependencies are updated on a rolling basis and security advisories affecting them are actioned on discovery. Chirply does not currently hold a SOC 2 or ISO 27001 certification and does not claim one. Independent penetration testing has not yet been commissioned.

Deletion and retention

Closing a workspace starts a documented retention window after which its contents are deleted or anonymised. Workspaces can additionally set their own retention windows for tracking data, session recordings, call recordings, and message history, and can erase an individual person's records across every dataset on request.

Personnel

Everyone with access to customer data is bound by confidentiality obligations that survive the end of their engagement.