Security overview

Last updated: 22 May 2026

Pro-cess is built and operated in the United Kingdom by the same team that runs a UK service business on it. Every design decision below comes from "would we trust our own customer data with this?". If you're a buyer evaluating Pro-cess for your organisation and have specific security questions, email [email protected] and we'll come back to you the same working day.

Hosting and data residency

Production lives on Amazon Web Services in London (eu-west-2). All primary copies of your data sit in the UK.
Daily backups replicate to a UK-based disaster-recovery target (Stablepoint) and an hourly off-site mirror in Germany (Hetzner, EU). No customer data leaves the EU/UK without your tenant's explicit opt-in to a US-based integration.
Our staging environment runs in Germany and never holds production customer data.

Encryption

In transit: all traffic is encrypted with TLS 1.2 or TLS 1.3. We actively reject TLS 1.0 and 1.1 at both the Cloudflare edge and our application load balancer.
At rest (database): the production database is encrypted at rest with AES-256, using AWS KMS-managed keys.
At rest (backups): the S3 backup bucket uses AWS server-side encryption (AES-256). The AWS Backup vault uses a separate KMS key.
Integration tokens (Stripe Connect, Xero, QuickBooks, Google Calendar, etc.) are encrypted at the application layer before being written to the database. A database backup is useless without our application key.
Passwords are hashed with bcrypt (Laravel default cost).
Session cookies are encrypted, marked Secure, HttpOnly, and SameSite=Lax.

Multi-tenant isolation

Every tenant-owned record carries a tenant_id column. Our application enforces a global "fail-closed" query scope, so the only way to read another tenant's data is to be authenticated as that tenant.
The fail-closed behaviour means that if our authentication layer ever fails, all queries return zero rows by default - never another tenant's data.
Cross-tenant routes (such as the Tender Portal's subcontractor marketplace) are explicitly modelled as cross-tenant and audited separately from the main tenant scope.

Backups and disaster recovery

The production database is captured by AWS RDS automated backups with 7 days of point-in-time recovery, plus hourly AWS Backup snapshots retained for 2 days and daily snapshots retained for 30 days.
We additionally dump the database every hour into the encrypted S3 bucket described above (30-day retention) and mirror that dump to two separate UK and EU off-site locations.
Backup freshness is monitored automatically; an alert fires to our on-call team if any backup is more than 30 hours stale.
Your maximum acceptable data loss (RPO) is one hour against the hourly dumps, or five minutes against the RDS point-in-time recovery window.

Authentication and access

Two-factor authentication is available to every user, using TOTP apps such as Google Authenticator or 1Password, with recovery codes generated at setup.
Failed login attempts are rate-limited by both email and IP. Concurrent sessions are tracked, and changing your password terminates every other active session.
Super-admin access to the underlying platform is restricted to a small number of named individuals, with every administrative action recorded in an immutable audit log.
Tenant impersonation by Pro-cess support staff is logged with the originating user, IP address, and a hard block on impersonating other super-admins.

Payment security

Pro-cess never stores card numbers, CVVs or full bank-account numbers on its own infrastructure. Card payments use Stripe Elements hosted in an iframe; direct debit setup uses GoCardless's hosted flow; in-person card terminals route through SumUp's hosted checkout.
This puts Pro-cess in the lowest PCI DSS scope (SAQ-A) as a "card-not-present, hosted-redirect" merchant.
All payment webhooks (Stripe, GoCardless, Twilio, Telegram) are signed by the upstream provider and verified by us in constant time, with a five-minute replay window and a 30-day event-id deduplication cache.

Application security headers

Strict Content Security Policy with no inline-eval, object-src 'none', and explicit allowlists for Stripe, Google Maps and our own font CDN.
HTTP Strict Transport Security with one-year max-age and includeSubDomains.
X-Frame-Options SAMEORIGIN, X-Content-Type-Options nosniff, Referrer-Policy strict-origin-when-cross-origin.
Permissions-Policy locks camera, microphone, payment and other powerful browser features off by default.

Audit trail

Material changes to customer, contract, order, schedule and resource records are written to an append-only audit log capturing the previous and new values, the acting user, IP address and user agent. Platform-administrator actions (creating, suspending or cancelling tenants, credit adjustments, feature-flag changes, impersonation) are written to a separate administrative audit log with the same immutability guarantees.

Vulnerability management

Every code change is scanned by an automated security pattern scanner before it ships, blocking commits that match known dangerous patterns (raw SQL with user input, missing tenant scope, unescaped HTML in templates, dangerous file extensions in uploads).
The dev box runs unattended-upgrades for OS security patches with a controlled restart window so production-impacting reboots never happen unannounced.
Dependencies are pinned and reviewed; framework patch updates are applied within their support window.

Sub-processors

For the full list of every third-party service Pro-cess uses to deliver the platform, including data category and hosting region, see our Sub-processors page. We give at least 30 days' notice before adding a new sub-processor.

Reporting a vulnerability

If you've found a security issue in Pro-cess, please email [email protected] with reproduction steps. We acknowledge reports within one working day. Researchers who follow coordinated-disclosure conventions are welcome to credit themselves on this page after a fix has shipped.