Security

How ProvenBatch keeps your data safe, how we test it, and how to tell us if you find a problem.

Published 10 September 2026 · Updated 26 September 2026

1. What this page is

1.1 This page describes the security controls that are running in ProvenBatch today, how we test them, and how to tell us about a problem. It is a plain description of how the service is built, not an audit result. We would rather name what is actually running than imply anything we have not done.

1.2 David Biley trading as ProvenBatch is the operator. Questions about this page go to support@provenbatch.co.uk.

2. Reporting a security issue

2.1 Email support@provenbatch.co.uk. Please tell us what you saw, where, and when. We will acknowledge within 2 working days, so you’ll hear back from a person within that time. We do not publish a fix-by date, but we will keep you updated while we look into it.

2.2 Please do not test the live Service without our prior written permission. Our Acceptable Use Policy forbids unauthorised security testing, including probing for vulnerabilities. This page is the channel for a finder to tell us, not an invitation to probe. A machine-readable copy of the same contact is at /.well-known/security.txt, on both this site and the app.

3. Controls that are in place

Each of the following is running today. None of them is a claim about a future control.

  • Every business’s data is walled off from every other business. This is enforced inside the database itself, not only in the app. A signed-in customer of one business cannot see or change another business’s records. Staff support is an exception: a platform admin can open a default 60-minute, read-only session into one business, and a reason is stored. Staff can also ban an account or reset its MFA; those actions are logged. See “How we test” below.
  • Your business data is stored in UK data centres (London). Your account, your business records and the files you upload are stored with Supabase in London (eu-west-2). Some processing happens outside the UK. This is not a complete list. Photos, PDFs and pasted recipe or menu text you ask the app to read, conversations with the in-app assistant, and supplier-product names a daily recall-watch job sends so we can explain an FSA match, go to Anthropic in the United States; some text the app already holds is sorted by TypeSafe AI in the United States, through Cloudflare; receipt scan-in email is received by a Cloudflare Email Worker; feedback you choose to send goes to our issue tracker on GitHub in the United States, which also runs our scheduled background jobs; and payments (Stripe), email (Resend), our support mailbox (Google Workspace) and website delivery (Cloudflare) use global providers that may process data outside the UK. The Privacy Policy and Sub-processor List give the detail and the legal safeguard for each.
  • Uploaded files are private to your business. Receipts, photos and other files you upload are kept in private storage, and each business can only reach its own files. They are shared only when you choose to: an inspection code you give an environmental health officer lets them view your food-safety records, including evidence photos, until it expires or you revoke it; and a screenshot you attach to feedback is shown in our private issue tracker, as the Privacy Policy explains.
  • Admin access to ProvenBatch requires two-factor authentication. Our admin console will not accept a sign-in that has not completed a second factor. Every member of our code repository’s organisation must also use two-factor authentication.
  • Functions that touch customer data check who is calling. Functions that touch customer data identify the caller themselves before they do any work, rather than trusting the network alone.
  • Code changes go through automated security checks before they land. Before a change can land through the ordinary landing process, automated checks scan it for passwords or keys that have been included by mistake, and check the packages in our committed lockfiles against public lists of known high-severity vulnerabilities. A change that fails these checks is stopped.
  • Admin writes are audit-logged. Changes made through the admin console are written to an audit log.
  • You can export your data at any time, and you can ask us to delete your account. An export is available while the account is active and while it is in Archive. You can ask us to delete the account by emailing support. We do not run an automatic timed purge today.
  • Database advisors are checked weekly. A scheduled job reads the database security and performance advisors on both the live and staging databases. It raises a GitHub issue and emails us when findings change or an error-level finding appears.
  • There is a public status page. A status page is at /status. It currently says there are no known incidents.

4. How we test

4.1 Business separation. We first tested on 26 September 2026 (on staging) that one business cannot access another’s data. That check ran on staging. It is not a test of production, and it does not claim production matches staging.

4.2 Before they land. The automated checks in section 3 run on code changes before they can land through the ordinary landing process.

4.3 Every week. A scheduled job reviews the database’s own security advisors each week and raises a GitHub issue and emails us when findings change or an error-level finding appears.

4.4 We don’t publish the details of these tests, because they would help someone trying to attack the service rather than protect you.

5. Cyber Essentials: in progress

5.1 We’re working towards Cyber Essentials, the UK government-backed security certification. We do not hold it yet. We will not display a badge or say we have it until the certificate is issued. When it is, we’ll add the certificate details to this page.