Security

Last updated: 8 August 2026

How HACCP Hyve is hosted, who can reach what, and what happens to your data. Every statement on this page describes what is running today. Where a control is not in place, this page says so.

Hosting and data location

  • The application runs on Vercel in the European region (Paris).
  • Data is stored in PostgreSQL on Supabase, on the Pro plan, in a European region.
  • The database is reached only from our own server-side code through Prisma. Supabase's public data API is closed.

Encryption

  • Everything is served over HTTPS. Strict Transport Security is set for two years, covers subdomains and is submitted for preloading, so a browser will not fall back to plain HTTP.
  • Traffic between the application and the database runs over TLS.
  • Database storage is encrypted at rest by Supabase.
  • Our own off-site database dumps are encrypted with AES-256, the key derived with PBKDF2, and written so that only their owner can read them.

Browser and application hardening

  • A Content Security Policy is enforced on every response, allowing only our authentication, payment and training video providers. It has been enforced since 28 July 2026, after three weeks in report-only mode with no violations.
  • Violations still report to an endpoint of ours, so a regression shows up instead of passing quietly.
  • The site cannot be placed in a frame: X-Frame-Options is DENY and frame-ancestors is none.
  • Referrer-Policy is strict-origin-when-cross-origin, and MIME type sniffing is switched off.
  • Camera and location access are disabled by policy. The microphone is allowed on our own origin only, for spoken entries in the daily records.

Access control

  • Every page and every server action begins by checking the signed-in person's role. Nothing renders first and checks afterwards.
  • The roles are company admin, location manager, department head, assistant department head, employee, and our own platform admin. A location manager sees one site. A department head sees one department.
  • Below company admin, nobody can act on a person at an equal or higher role, and nobody can raise anyone, themselves included, above what their own role is allowed to assign.
  • Every identifier the browser sends is checked against the caller's company and scope before anything is written.
  • Permanent deletion is limited to our platform admin role, and it requires the company name, or the word DELETE, to be typed out.

Tenant isolation

  • Every query that returns company data carries a company filter, applied through one shared helper rather than rewritten on each page.
  • Scoping fails closed. A location manager with no site assigned matches nobody, never the whole company.
  • Row level security is on for every table, with no policies, which closes those tables to Supabase's public API. A check script reports any table left open and exits with an error.
  • Cross-tenant attempts are covered by tests: writing into another company's site, reading another site's team, acting above your own role, and reaching another company's records.
  • Those tests run against a real PostgreSQL database rather than mocks, and the suite has to pass before a release goes out.

Authentication

  • Sign-in is handled by Clerk, with email and Google sign-in. The application never sees or stores a password.
  • Employees join through a personal invite link. The link is a random token, it stops working once the account exists, and lookups are limited to ten a minute from one address.
  • Removing an employee ends their access on their next request while keeping the training record the company needs for an inspection. It can be undone.
  • A shared venue screen signs in with one venue code. The code and the session token behind it are stored only as SHA-256 hashes, the cookie is http-only and secure, wrong codes stop after five attempts and are then delayed by up to fifteen minutes, and the comparison is timing-safe.
  • A venue screen is not a person and cannot reach any page in the management app, because each of those pages asks a signed-in user for a role and a screen has none.

Payments

  • Payments run through Stripe. Card details never reach our servers and are never stored in our database.
  • Checkout and the billing portal are hosted by Stripe.
  • Stripe webhooks are verified against a signing secret before anything is applied.
  • Each webhook event is claimed by its id, so a repeated delivery changes nothing. If a handler fails, the claim is released and the request returns an error, so Stripe delivers again instead of the retry being read as a duplicate.

Backups and recovery

  • Supabase takes automated daily backups on the Pro plan, confirmed on 8 August 2026.
  • We take our own full logical dumps as well, schema and data, kept outside the hosting account so they survive the loss of the project or of the account itself.
  • The last twelve dumps are kept and older ones are removed.
  • A restore was tested on 16 July 2026 into a separate PostgreSQL cluster. Row counts and certificate numbers matched production.
  • Point-in-time recovery is not enabled. That was a decision taken on 17 July 2026, and it is the reason the recovery point below is measured in a day rather than in minutes.
  • We commit to a recovery point of 24 hours and a recovery time of 24 hours. The elapsed time of the tested restore was not recorded, so we commit to the figure we are certain of rather than a faster one.

Availability

  • We stand behind 99.5% availability in a calendar month, measured on the application being reachable.
  • Service credits are not part of the standard terms. An enterprise agreement can add them.
  • Vercel and Supabase publish their own availability commitments. The figure above is ours, and it is not a restatement of theirs.

Monitoring and logging

  • Changes to people, roles, training assignments, venue screens, subscriptions and company settings are written to an audit log recording the company, who acted, what they did, which record, and when.
  • The audit log is readable by our platform admin role, and a company's own entries can be produced on request.
  • Runtime logs are held by Vercel for the retention its plan provides.
  • Content Security Policy reports arrive at their own endpoint, rate limited per address.
  • A version endpoint reports the commit, environment and region that is serving, so a release can be confirmed from outside the app.

Subprocessors

Five providers process data on our behalf. This is the same list as in our Data Processing Agreement.

  • Vercel, application hosting, European region
  • Supabase, PostgreSQL database, European region
  • Clerk, authentication and identity
  • Stripe, payment processing
  • Resend, transactional email

We tell customers before a subprocessor is added or replaced, and a customer can object.

Voice entry for the daily records is offered only where it is switched on for a deployment. Where it is on, a short audio clip goes to Google Cloud Speech-to-Text to be turned into text, and the audio itself is not stored. Any customer whose deployment has it on is told, because it adds a sixth processor.

Data residency and transfers

  • Production data for European customers is stored in the European Union and served from Paris.
  • Where a subprocessor is established outside the European Union, the transfer runs under an adequacy decision or Standard Contractual Clauses.
  • We handle personal data under the GDPR, and for customers in Japan under the Act on the Protection of Personal Information.

Deletion and export

  • A company admin exports the full training register as a CSV file at any time, without asking us.
  • Certificates and the daily record book download as PDF.
  • One person can be erased on request. Their account with our authentication provider, their training and exam records, and the audit entries describing them are all removed.
  • A whole company can be erased on request. That removes every user, site, department, exam result, certificate, notification and audit entry, together with the accounts at our authentication provider and the customer record at Stripe.
  • We complete a verified erasure request within 30 days, and normally within five working days.
  • Certificate records are kept for five years after issue so a company can show an inspector its history, unless erasure is requested sooner.

Certifications

We hold no ISO 27001 certification and no SOC 2 report, and no third party has audited these controls. What is on this page is built into the product and can be checked against it. If your review requires a certified vendor, say so early and we will tell you plainly whether we can meet it.

Reporting a vulnerability

Write to privacy@haccphyve.com with what you did and what you saw. We confirm receipt within two working days.

  • Tell us first, and give us time to fix it before telling anyone else.
  • Please do not run automated scans against the live site, and do not read, change or keep anyone else's data.
  • We will not pursue anyone who follows those two points in good faith.

Related documents

IT teams running a formal review can ask for our completed security questionnaire at privacy@haccphyve.com.