Security

This page sets out the practices we follow to keep CalProof and your data safe, the assurance artefacts we currently hold (and those we don't), and how to report a vulnerability if you find one.

CalProof is a trading name of Crocker Digital Ltd, registered in England and Wales under Company No. 17008789. Security questions should be sent to security@calproof.co.uk.

1. Our practices

1.1 Encryption in transit

Traffic uses modern TLS; TLS 1.1 and earlier are not accepted. We redirect HTTP to HTTPS at the edge and set HSTS with a one-year max-age and includeSubDomains.

1.2 Encryption at rest

The Postgres database, certificate storage, and authentication system are hosted by Supabase. Data at rest is encrypted using AES-256 by Supabase's underlying infrastructure on AWS in eu-west-2 (London). Backup snapshots are encrypted with the same key management.

1.3 Role-based access

We separate human and machine roles in the database. Application code uses a constrained role with no DDL privileges. Administrative access for the small number of people who need it is gated behind multi-factor authentication and is logged.

1.4 Row-level security on user-data tables

Every table that holds customer data has Postgres row-level security (RLS) enabled with policies that restrict reads and writes to the owning organisation. Policies are tested as part of our migration pipeline. There is no application path that bypasses RLS in normal operation; service-role operations are limited to scheduled jobs that are explicitly scoped by org_id and reviewed before deployment.

1.5 Audit log immutability

The audit log table has no DELETE path enforced by migration. Soft-delete on the parent organisation does not cascade to the audit log; the only way a row leaves the table is via the quarterly scheduled function that hard-deletes entries older than 7 years from their creation timestamp.

1.6 Secret management and rotation

API keys, service-role tokens, and signing secrets are stored in environment variables on Netlify and never in the repository. We rotate critical secrets at least annually and immediately on any signal that a secret may have leaked. Stripe webhook signing secrets and Supabase service-role keys are scoped to the smallest set of operations they need to perform.

1.7 Principle of least privilege

We give people and machines the least access they need to do their work. New engineering hires receive read-only production access by default and are escalated only when a role demands it. Sub-processor accounts are configured with the minimum permission set that the integration needs.

1.8 Dependency updates

We track upstream advisories using GitHub Dependabot and Snyk. Critical and high-severity advisories are patched within 7 days; medium-severity within 30 days. We pin dependency versions and run automated CI on every pull request before deployment.

1.9 Backups and recovery

Supabase performs daily Postgres backups with point-in-time recovery. Storage buckets are versioned. We test our restore process at least quarterly against a non-production project. We do not publish a formal RTO/RPO yet; in practice we can restore the database within an hour of declaring an incident.

1.10 Logging and monitoring

We use Sentry to capture errors and forward stack traces with no payload bodies. We use UptimeRobot for external availability checks. The audit log records all significant administrative actions inside the application.

2. Security scope today

CalProof is designed for SME calibration teams. CalProof helps you meet ISO 9001 and ISO 17025 record-retention obligations, though Crocker Digital Ltd is not itself ISO 27001 certified. Common enterprise-procurement artefacts — SOC 2 reports, an external penetration test summary, a formal bug bounty programme — are not currently held; multi-region failover is not implemented (primary region: Supabase eu-west-2, London). If any of these is a blocker for your evaluation, contact security@calproof.co.uk and we'll walk through what we do operate, what's planned, and what's available under NDA.

3. Reporting a vulnerability

If you believe you have found a security vulnerability in CalProof, please tell us. We will treat your report with the seriousness it deserves, and we will not pursue legal action against researchers acting in good faith.

• Email: security@calproof.co.uk
• Encryption: PGP key on request.
• What to include: a clear description of the vulnerability, steps to reproduce, the impact, the affected URL or endpoint, and any proof-of-concept material.
• Response time: we will acknowledge within 5 working days.
• Disclosure: we follow coordinated disclosure with a default 90-day window. We may agree a longer or shorter window with you depending on the severity and the time needed to deploy a fix.
• Out of scope: denial-of-service tests against the production environment, social-engineering of staff or customers, physical access attempts, and reports that consist solely of automated-scanner output without verified impact.

Please do not access another customer's data, do not modify or destroy data, and do not disrupt the service while testing. If you do those things, your report will be treated as an abuse incident regardless of the original intent.

4. Bug bounty

Vulnerability reports are welcome. We do not operate a public reward programme; meaningful reports may be acknowledged case by case — typically a thank-you in our release notes (with your permission) and, where appropriate, a token reward in line with the severity of the finding.

Please report any vulnerability you find via section 3 — we respond promptly and will tell you up front whether your report is in scope.

5. Contact

For all security correspondence, email security@calproof.co.uk. For general privacy questions, see our Privacy Policy.