Baseline text pending counsel review
This text describes what the service actually does today and is published so that pilot participants can read it before providing personal data or payment. It has not yet been reviewed by a lawyer for the operator's jurisdiction.
Security
Last updated 14 September 2026
What the service does today to protect data, stated plainly. Items that are not yet in place are listed as such rather than implied.
Technical and organisational measures
| Area | Measure |
|---|---|
| Tenant isolation | PostgreSQL row-level security on every tenant table, compound tenant foreign keys, triggers that block tenant reassignment, and automated cross-tenant tests. |
| Encryption | TLS in transit; secrets, feedback tokens and webhook diagnostics encrypted at rest with versioned AES-256-GCM keys; passwords hashed with scrypt; session, API-key and unsubscribe tokens stored only as hashes. |
| Access control | Owner and manager roles enforced server-side; operator access limited to an allowlist and audited; no shared service credentials in browser code. |
| Authentication | Verified email before tenant access, single-use 30-minute sign-in links, optional Google sign-in with PKCE, rate-limited sign-in and reset, sessions revocable per device. |
| Integrity of inbound data | Every webhook is verified over raw bytes with timestamped HMAC signatures; duplicate events are idempotent; malformed and oversized bodies are rejected. |
| Minimisation and retention | Only the fields listed in the privacy notice are stored; the retention schedule is enforced daily by the worker; erased customers are anonymised rather than kept. |
| Logging | Structured logs redact customer email addresses and tokens; audit log for member, integration, export, deletion and billing changes; no session replay on customer pages. |
| Browser hardening | Content-Security-Policy, HSTS, frame denial, nosniff, referrer policy; customer pages are no-store, noindex and no-referrer; only strictly necessary cookies. |
| Availability | Durable job queue with retries and dead-letter review; idempotent sends; operator alerts for failed events; database backups are the operator's deployment responsibility (see runbook). |
| Incident response | Documented breach procedure with customer notification without undue delay and within 48 hours of confirming a personal-data breach affecting their data (doc 11 §7). |
Verification
- Automated tests cover tenant isolation (a user in one business cannot read, insert, update or delete another business's rows on every tenant table), webhook signature verification, idempotency, token expiry and single submission, review-gating equality for every rating, and the privacy tools (export, erasure, retention).
- Continuous integration runs linting, type checks, all test suites and a production-dependency vulnerability audit on every change.
Not yet in place
- Independent penetration test and third-party audit (SOC 2 or ISO 27001). CrownVouch is a pilot service and makes no certification claim.
- Multi-factor authentication for operator accounts (planned before public launch).
- Automated, tested database backups depend on the operator's deployment; the runbook describes the required procedure.
Report a vulnerability
Email [email protected] with steps to reproduce. We acknowledge reports within two business days, do not pursue good-faith researchers who avoid privacy violations, data destruction and service disruption, and credit reporters on request. A machine-readable version of this policy is at /.well-known/security.txt.