Security statement

ECGT Ready handles compliance data, so security has to be built in rather than bolted on. This page is a plain-English summary of how we protect customer data today, with an honest note where a control is not yet in place.

1. Hosting and data residency

• Application hosting with Vercel. The server functions run in Frankfurt, and the edge network answers a visitor from the location nearest to them.
• The browser that opens the pages of an audit runs with Render, in Frankfurt.
• Database, auth, storage: Supabase, region eu-central-1 (Frankfurt).
• Email delivery: Resend, with the sending domain pinned to contact.ecgtready.eu.

2. Encryption

• In transit: TLS 1.2+ end to end. HSTS enabled on the apex domain.
• At rest: managed by Supabase (AES-256) and Vercel for any cached assets.
• Secrets: stored in Vercel project environment variables, never in the repo.

3. Authentication and authorisation

• Supabase Auth, hashed passwords, MFA available to every user.
• Sign-in is email + password. Magic links are admin-issued only, not public.
• Database protected by row-level security (RLS) policies, with explicit GRANTs per role; default deny.
• A bot check by Cloudflare (Turnstile) protects the sign in and sign up pages.
• Service-role keys live only in server-side Vercel env vars, never shipped to the browser.

4. Backups and recovery

• Daily backups of the production database by Supabase, kept 7 days.
• Stored files (pictures of pages, uploaded documents) are not part of these backups.

5. Logging and monitoring

• Audit log for admin and account-sensitive actions.
• Vercel observability for HTTP errors and latency.
• Supabase logs for database, auth, and storage events.

6. Vulnerability management

• Every deployment is type checked in TypeScript strict mode, and a build with an error is not released.
• Dependencies are reviewed and updated by hand.
• Manual security review on the auth and billing surfaces before each major release.

7. Responsible disclosure

Found a vulnerability? Please email contact@ecgtready.eu with details and a way to reach you. Do not test against accounts that are not yours, do not exfiltrate user data, and give us a reasonable window to fix before publishing. We do not run a bounty programme yet but we publicly thank good-faith reporters with their consent.

Machine-readable contact at /.well-known/security.txt.

8. Incident response

On detection we triage severity, contain the issue, notify affected customers without undue delay, and notify the CNPD within 72 hours where required by GDPR Article 33. A post-mortem is shared with affected customers within 14 days of resolution.

9. Subprocessor security

Each subprocessor is reviewed for relevant certifications, data residency, and SCC posture before onboarding. The list is published at /legal/subprocessors.

10. What we are still building

• Public status page (planned alongside first paying customer).
• SOC 2 / ISO 27001 - not in scope at solo founder stage; we follow the controls without holding the certification.
• Independent penetration test - planned before first enterprise customer.
• Point in time recovery, a copy of the backups outside our database provider and a regular restore drill (not in place today, a recovery would use the daily backups of section 4).
• Automated dependency scanning (not in place today).