Security & Data Handling

This page summarises the technical and organisational measures PlateProof (a trading name of Trades Office Limited) uses to protect customer data. It is written to be honest about our current posture as an early-stage product — we state what is in place today and what is on the roadmap, and we don’t claim certifications we don’t hold.

Hosting & data residency

The database, authentication and file storage run on Supabase, hosted in the EU. The application runs on Vercel in the EU (Dublin) region, co-located with the database. Customer data is processed and stored in the UK/EU region.

Tenant isolation

Every customer organisation’s data is isolated at the database level using PostgreSQL Row-Level Security. Queries are scoped to the signed-in user’s organisation membership, so one organisation cannot read or modify another’s records.

Encryption & browser hardening

Data is encrypted in transit (TLS 1.2+) and at rest by the managed infrastructure.

Every response carries security headers: HSTS (forced HTTPS), X-Frame-Options (anti-clickjacking), X-Content-Type-Options: nosniff, a strict Referrer-Policy, and a Permissions-Policylocking down device features we don’t use. A tuned Content-Security-Policy is being added next.

Authentication & access control

• Email + password authentication (Supabase Auth); passwords stored only as a secure hash.
• Sessions use HttpOnly, Secure, SameSite cookies with automatic rotation on refresh.
• Multi-factor authentication (TOTP) is supported at the authentication layer; in-app enrolment is on the roadmap.
• Authentication endpoints (login, signup, password reset) are rate-limited by the platform; Vercel provides edge / DDoS protection.
• The privileged service-role key is server-side only and never reaches the browser.
• Administrative access is restricted on a need-to-know basis (PlateProof currently operates as a sole-founder business).

Auditability & immutability

Key actions are written to an audit log. A signed allergen declaration and its supporting evidence are append-only and are not altered after sign-off — a correction is made by a fresh, re-signed declaration. This means records cannot be silently changed after the fact.

Public verification

The only public, unauthenticated data path is the scan-to-verify record. It is served by a single locked-down, read-only database function (SECURITY DEFINER, fixed search path, accessed only via an unguessable per-record token, with no caller identity) that returns only the approved, lean declaration fields. No table is exposed publicly.

Sub-processors

Three, listed in the Sub-Processors Policy: Anthropic (AI allergen identification, US — UK IDTA / EU SCCs), Supabase (database/auth/storage, EU-hosted) and Vercel (application hosting, EU). Customer data is not used to train general-purpose AI models.

Backups & recovery

Database backups and point-in-time recovery are managed by the infrastructure provider (Supabase).

Incident response

If we become aware of a personal-data breach affecting customer data, we contain and assess it, and notify affected customers without undue delay and within 72 hours of becoming aware, with the information needed for them to meet their own obligations. The customer, as controller, decides on any notification to the ICO or data subjects.

Responsible disclosure

Found a security issue? Please email security@plateproof.io. We’ll acknowledge it, work with you on a fix, and won’t pursue good-faith research.

On the roadmap

As we grow we plan to add in-app MFA enrolment, a tuned Content-Security-Policy, independent penetration testing, and a formal, externally-aligned control set. We’d rather state these as planned than imply they exist today.

Enterprise customers: we’re happy to complete a security questionnaire and discuss bespoke arrangements (audit, DPA, data-return on exit). Contact security@plateproof.io.