Security is the foundation.

Multiple independent layers protect your data at every stage: in transit, at rest, and at the point of access.

Encryption in transit

Every byte of data moving between your devices and our infrastructure is encrypted using TLS 1.3, the latest and most secure transport protocol.

Encryption at rest

All stored data, including voice recordings, transcriptions and workspace metadata, is encrypted at rest using AES-256. Your data is unreadable without the correct keys, even at the storage layer.

TLS 1.3

We enforce TLS 1.3 across all connections. This ensures forward secrecy, faster handshakes, and protection against known downgrade attacks.

Row Level Security

Our Postgres database enforces Row Level Security policies, ensuring that every query is scoped to the authenticated user's permissions. Data isolation between tenants is enforced at the database level, not just in application code.

Data residency

Choose where your data lives. We support configurable data residency so your organisation can meet regional compliance requirements including GDPR. Your voice data, recordings and metadata stay in the region you choose.

Secure payments via Stripe

All billing and payment processing is handled by Stripe, a PCI DSS Level 1 certified payment processor. We never store card numbers, CVVs or sensitive payment credentials on our servers.

Role-based access control

Fine-grained permissions let workspace owners control exactly who can do what. From room access to admin settings, every action is gated by role. Assign Owner, Admin or Member roles, and audit every change.

Multi-factor authentication

Add a second layer of protection to every account. whoot. supports TOTP-based multi-factor authentication, so even if a password is compromised, unauthorised access is blocked.

Automated backups

Your data is continuously backed up with point-in-time recovery. Automated daily backups are retained and encrypted, ensuring business continuity and protection against data loss.

Built for regulated industries.

From financial services to healthcare operations, whoot. is designed to meet the security expectations of the most demanding environments.

Found something? Tell us.

whoot. carries messages people rely on in an emergency, so we would far rather hear about a weakness from you than discover it during an incident. This policy sets out how to report one, what we commit to in return, and the protection you have for testing in good faith.

What we commit to

Acknowledgement within two working days

Every report is acknowledged by a person, with a reference, within two working days of receipt. Reports arriving out of hours that describe an active exploitation are paged to the on-call engineer immediately.

Triage within five working days

We confirm whether we can reproduce the issue, assign a severity, and tell you what we found. Anything that could expose one organisation's data to another, or bypass authentication, is treated as critical regardless of how difficult it looks to exploit.

Remediation targets by severity

Critical, immediately and within 24 hours. High, within 7 days. Medium, within 30 days. Low, within 90 days or the next planned release. Where a fix depends on a third party we tell you the mitigation in place and the expected date.

Credit where you want it

We are happy to credit reporters by name in the resolution notice, or to keep your report anonymous. We will agree public disclosure timing with you rather than impose it.

In scope

Out of scope

• Denial-of-service, load or volumetric testing of any kind
• Social engineering of whoot. staff, customers or their recipients
• Physical attacks against offices or personnel
• Sending SMS, voice or email to anyone who has not consented to receive it
• Automated scanning that generates alert or message traffic for a customer
• Reports produced solely by a scanner, with no demonstrated impact

Safe harbour

If you act in good faith and within this policy, whoot. will not bring or support legal action against you, will not report you to law enforcement, and will treat your testing as authorised for the purposes of the Computer Misuse Act 1990. If a third party brings action against you for research conducted within this policy, we will make that authorisation clear.

What to include

• The affected URL, endpoint or application screen
• What an attacker could achieve, in one sentence
• The steps to reproduce, including any account you used
• Any proof-of-concept request or payload, as text rather than a video where possible