Trust & security

Data isolation

• Each kitchen’s data is isolated at the database

  In place

  Every tenant table is protected by Postgres Row Level Security, so a query can only see the organization the signed-in user belongs to.

  Evidence: Nightly tenant-isolation test suite against a non-production copy of the schema (.github/workflows/tenant-isolation.yml, 08:00 UTC)

• Least-privilege roles

  In place

  Admin, chef, cook and server roles. Admins can narrow what each role may do; a server sees the menu and 86 board and nothing else.

  Evidence: Settings → Team → Permissions in the app

• Change history

  Partial

  Prep list edits keep a full history with who changed what. Analytics-warehouse access is audit-logged. There is no org-wide admin activity log yet.

  Evidence: Prep History in the app; BigQuery audit logs enabled 2026-08-22

Infrastructure

• Encrypted in transit and at rest

  In place

  TLS on every origin with certificates managed by Vercel. The database and file storage are encrypted at rest by Supabase.

  Evidence: Supabase security overview

• Browser hardening headers

  In place

  HSTS preload, a Content Security Policy that forbids framing, nosniff, and a strict referrer policy on both the app and this site. The app’s CSP is nonce-based with violation reporting.

  Evidence: Independent scan of app.heardapp.kitchen

• Data residency

  Partial

  The application and database run in US regions of Vercel and Supabase; internal analytics live in Google Cloud (Toronto). The region of a few monitoring and content vendors is still being confirmed, so we do not yet claim a single residency for every vendor.

  Evidence: Region column in docs/legal/subprocessors.md

Application

• Card data never touches Heard

  In place

  Billing runs on Stripe-hosted Checkout and Customer Portal. We store a customer id, never a card number.

  Evidence: Stripe row on the subprocessor list

• Your kitchen’s data does not train AI models

  In place

  Roux sends questions and the relevant recipes to the OpenAI API, which does not train on API traffic by default.

  Evidence: OpenAI: how API data is used

• Error monitoring without personal data

  In place

  Sentry runs with default PII collection off and a scrubber that removes email addresses and reduces user context to an opaque id.

  Evidence: sendDefaultPii: false + beforeSend scrub (src/lib/sentry-scrub.ts)

• Dependency vulnerability scanning

  In place

  Production dependencies are audited weekly at moderate severity and above; Dependabot opens update PRs weekly.

  Evidence: .github/workflows/security.yml (Mondays 09:00 UTC) and .github/dependabot.yml

• Recurring internal security audits

  In place

  Dated code and security audits are kept in the repo with findings and fixes; the database advisor baseline is recorded and re-checked.

  Evidence: docs/audits/ (latest 2026-09-02; security-specific 2026-08-20) and docs/security/2026-08-19-supabase-advisor-baseline.md

• Deferred risks are written down

  In place

  Findings we chose not to fix before a release are recorded with the owner, the impact and what would reopen them, not silently dropped.

  Evidence: docs/security/accepted-risks.md

• Third-party penetration test

  Not yet

  Not done. Trigger: the first customer contract that requires one.

Privacy & your rights

• Self-serve data export

  In place

  Any staff member can download everything tied to them as a file from Settings → Privacy.

  Evidence: Privacy policy, “Your rights”

• Self-serve account deletion

  In place

  Request deletion in Settings. Login and personal details are removed; the kitchen’s operational history stays but is no longer tied to a name.

  Evidence: Privacy policy, “Your rights”

• Access, portability and erasure requests

  In place

  A written runbook covers requests that arrive by email rather than through the app.

  Evidence: docs/legal/dsar-runbook.md

• Trackers stay off until you opt in

  In place

  Analytics and advertising scripts load only after consent. Each consent decision is logged and kept for 24 months.

  Evidence: Cookies & subprocessors (consent gating); retention table in docs/PRIVACY.md (24-month consent log)

Vendors

• Published subprocessor list

  In place

  Every provider that processes customer data, what it receives, and which ones your kitchen supplies itself.

  Evidence: Cookies & subprocessors

• Data processing agreements with vendors

  Partial

  Status is shown per vendor below. None has been confirmed and dated yet; most are self-serve acceptances in the vendor’s dashboard.

Monitoring & incidents

• Uptime monitoring

  In place

  Synthetic checks hit the production app every 10 minutes and alert the operator on failure.

  Evidence: Checkly checks declared in __checks__/ (app repo)

• Public changelog

  In place

  Every production release is published with what changed.

  Evidence: Changelog

• Incident response

  Partial

  Incidents are handled from a runbook and written up afterwards. There is no signed incident-response policy document yet.

• SOC 2 / ISO 27001

  Not yet

  No third-party certification. Trigger: a customer contract that requires it.

Disclosure

• Vulnerability disclosure

  In place

  Email admin@heardapp.kitchen with SECURITY in the subject. Acknowledgement within 48 hours, a status update at least weekly, and a target of 7 days to fix high-severity issues.

  Evidence: security.txt

Documents

• Privacy policy
• Terms of service
• Cookies & subprocessors
• security.txt

Subprocessors

Providers that process data to run Heard, and whether a data processing agreement is in place with each.

Contact

Security questions or a vulnerability to report: admin@heardapp.kitchen with SECURITY in the subject.