Security & Trust

How we protect your inspection data and keep your account secure.

1. Overview

SiteVoice is a voice powered inspection platform handling sensitive construction and business data. We take a defence in depth approach: data is encrypted in transit, accounts are protected by modern authentication, and every company's data is isolated from every other. This page summarises the technical and organisational measures we use to keep your data safe. For details of how we process personal data, see our Privacy Policy and Data Processing Addendum.

2. Encryption

  • In transit: all traffic between your browser and our servers is encrypted using HTTPS/TLS. Audio and photos are uploaded over secure connections.
  • At rest: inspection media is stored in Cloudflare R2, and account and inspection data in a managed PostgreSQL database, both with encryption at rest provided by our infrastructure.

3. Authentication & Access

  • Password hashing: passwords are hashed with bcrypt (12 salt rounds). We never store plaintext passwords.
  • Short lived tokens: JWT access tokens expire after 15 minutes and are rotated on refresh. Refresh tokens are stored in httpOnly cookies (kept out of reach of page scripts), and are valid for 7 days, or 30 days with "Remember Me".
  • Account lockout: accounts are locked for 15 minutes after 5 failed login attempts to frustrate brute force attacks.
  • Role based access: permissions are governed by company defined roles, including contractor "trade lead" roles scoped to specific site and trade pairs, so people only see what they should.

4. Tenant Isolation

SiteVoice keeps every customer company as a separate tenant. Every data query is scoped by company, and identifiers are validated against the caller's company before use, so one company can never access another's sites, inspections, or media. Trade lead scope is computed per company, with no leakage between companies.

5. Application Security

  • CSRF protection: all state changing requests require a valid CSRF token, compared in a way that resists timing attacks.
  • Rate limiting: authentication endpoints (login, registration, password reset, token refresh) are rate limited to slow abuse.
  • Security headers: we use Helmet with a Content Security Policy and related HTTP security headers to mitigate common web attacks.
  • Webhook verification: inbound payment webhooks are verified against their cryptographic signatures before being processed.

6. Data Storage

Account and inspection data is held in a managed PostgreSQL database. Inspection photos and media are stored in Cloudflare R2 (S3 compatible object storage). Shared report links use random tokens and can be disabled at any time. Treat them like any other sensitive URL.

7. Payments

Payment processing is handled entirely by Stripe. We never store your full card number, expiry date, or CVC on our servers. Those details remain with Stripe, a PCI DSS Level 1 certified payment provider.

8. Subprocessors & Data Residency

We rely on a small set of vetted subprocessors to deliver the Service, including OpenAI and Deepgram (speech to text), Stripe (payments), Resend (email), and Cloudflare (storage). SiteVoice is designed for UK organisations. Where data is transferred outside the UK, those transfers are protected by appropriate safeguards such as Standard Contractual Clauses and the UK International Data Transfer Addendum. A full subprocessor list and transfer details are in our Data Processing Addendum.

9. Compliance

SiteVoice is built to help UK construction teams meet their record keeping obligations under the Building Safety Act 2022, with audit trails and activity logging throughout. We process personal data in accordance with the UK GDPR and the Data Protection Act 2018. See our Privacy Policy for the full picture.

10. Reporting a Vulnerability

If you believe you've found a security vulnerability in SiteVoice, we want to hear from you. Please email hello@sitevoice.app with the details and steps to reproduce. We ask that you give us a reasonable opportunity to investigate and address the issue before any public disclosure, and that you avoid accessing or modifying other users' data during your testing.