Security overview

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 security@pro-cess.co.uk 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 disaster-recovery target and an hourly off-site mirror in the EU. No customer data leaves the UK/EU 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 a dedicated 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.
• For online payments this keeps Pro-cess in the lowest PCI DSS scope (SAQ-A) as a hosted-redirect merchant. In-person payments run entirely on SumUp's own PCI-validated terminal and checkout, so card data never reaches us there either.
• Payment webhooks (Stripe, GoCardless) are signed by the provider and verified in constant time, with a five-minute replay window and a 30-day event-id deduplication cache. Other provider webhooks (Twilio, Telegram) are signature-verified with idempotent handlers.

Application security headers #

• A Content Security Policy that locks object-src to 'none' and restricts frame-ancestors, with an explicit allowlist for scripts, styles and connections (Stripe, Google Maps and our own font provider). We are moving remaining inline scripts onto nonces to tighten it further.
• 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 a dedicated audit log the application only appends to, 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 the same way.

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 security@pro-cess.co.uk 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.