Security & Trust

This page describes how we look after the data you trust us with — what controls we have in place today, what we're improving, and how to get in touch if you have a security concern or a request about your data.

We believe transparency is a security control in itself. Where we're not yet doing something, we'd rather tell you than hide it.

What's in place today

What we're working on

Where your data lives

We use a small number of trusted subprocessors to run the service. Each one is bound by contract to use your data only on our instructions.

Transfers outside the UK are protected by the UK International Data Transfer Addendum to the EU Standard Contractual Clauses, plus supplementary technical measures (encryption in transit and at rest). Where a subprocessor offers an EU-region deployment we'll move to it when reasonable.

Inherited compliance

We deliberately build on infrastructure providers that carry the certifications a small SMB couldn't realistically maintain in-house. That doesn't make us SOC 2 certified, but it does mean the layers our data sits on top of are independently audited.

Our own infrastructure isn't currently certified — we're a small team and the cost-to-customer of a formal audit doesn't pay off at our scale yet. The day we're large enough that it matters to a buyer, we'll engage an auditor. In the meantime we're glad to share evidence of any of the controls listed on this page, on request.

Compliance posture

The data lifecycle

From a single FRA engagement, here's where the data flows and when each piece is removed.

Audit & monitoring

We log enough to investigate an incident properly and we don't log so much that the logs themselves become a liability.

• Server access logs — every HTTP request to our application is logged with method, path, status code, IP. Retained 30 days by our host (Railway).
• Authentication events — sign-in, sign-out, password change, MFA enrollment — captured by Supabase Auth and visible in their dashboard.
• Database changes — Supabase Postgres has point-in-time recovery and write-ahead logging.
• Job-level state changes — every stage transition, every override, captured to our own job_overrides history. Visible inside the Hub's job detail panel.
• API auth failures — logged with the originating IP. Allows us to see brute-force attempts in soft-mode logs before enforcing.
• Email events — every send + delivery success/failure recorded by Resend with a unique ID.

Business continuity

Honest realism: we're a small operator, not a major SaaS. The realistic continuity plan looks like this.

• Backups — automatic point-in-time recovery on the Postgres database (7 days) and versioning on file storage are provided by Supabase. We don't currently take additional external backups, but we're considering a nightly export to off-provider storage in the next year.
• Single key person risk — currently one engineer (Marco). All credentials are in a password manager with a documented break-glass route. We acknowledge this is the biggest residual risk and would address it formally if the customer base expanded.
• Recovery time objective (RTO) — informally 4 hours for the Hub to be reachable again. We rely on Railway's hosting SLA for application-level outages and Supabase's SLA for data-layer outages.
• Recovery point objective (RPO) — informally 1 hour, bounded by Supabase's point-in-time recovery granularity.
• Vendor failure — if Supabase, Railway, Anthropic, Groq, or Resend disappeared overnight we'd have a real problem and we'd lean on our customer relationships for grace. We don't pretend that's enterprise-grade.

For evaluators & prospects

If you're considering white-labelling the platform or assessing it under a DPIA, supplier review, or other diligence process, please reach out and we'll happily walk you through:

• Architecture diagrams beyond the public System Map
• Specific subprocessor DPAs and SCC instruments
• Roadmap items not visible on this page (rate-limit thresholds, planned controls, deployment of Cyber Essentials)
• A short-form security questionnaire response (SIG-Lite-style) on request
• NDA-bound discussion of any control we've described less specifically here

We treat security diligence as a normal part of the sales conversation, not a hurdle. The earlier you raise concerns the easier they are to address.

Contact marco.fiore@cambsfiresafe.com with "Security diligence" in the subject and we'll respond within two working days.

How we handle a request

Data subject requests (access, correction, deletion)

Send an email to marco.fiore@cambsfiresafe.com explaining what you'd like. We'll verify it's really you (some basic identity check), then respond within 30 days — usually much faster for simple requests. Where we have a legal reason to retain something (e.g. records required under fire safety regulations or HMRC), we'll explain that in the response.

Reporting a vulnerability

If you've found a security weakness in any of our tools, please tell us privately rather than disclosing publicly. Email marco.fiore@cambsfiresafe.com with as much detail as you can share (URL, steps to reproduce, screenshots). We'll acknowledge within two working days and keep you updated as we fix it. We don't currently run a paid bounty programme but we'll happily credit you publicly if you'd like.

Suspected incident

If we discover a personal data breach that's likely to result in a risk to your rights and freedoms, we'll notify the Information Commissioner's Office within 72 hours and notify affected individuals without undue delay, as required by UK GDPR Article 33–34.

Roles and responsibilities

For everything in scope of this page:

• Marco Fiore is the operational data protection lead. Direct any data protection question, data subject request, or vulnerability report to marco.fiore@cambsfiresafe.com.
• The Information Commissioner's Office (ICO) is the UK supervisory authority. You can complain to them at any time, though we'd appreciate the chance to put things right first. Find them at ico.org.uk.

How this page is kept honest

The status pills above describe the actual state of the system, not aspirations. When we add a control, we move its pill to ✓ Live and update the last-reviewed date at the top. When we discover a gap, we add an ⌛ In progress pill so you know about it.

If you ever read something here that doesn't seem to match your experience, please flag it.