How we protect your data

🌍Hosting and data residencyLive

TrainSync's static marketing site and application UI are hosted on Microsoft Azure Static Web Apps, EU West Europe region (Netherlands). The database and authentication backend run on Supabase, EU West region, on AWS Frankfurt (Germany). Authentication tokens are issued by Clerk, EU region.

All customer data resides in the EU. No data is transferred to non-EU jurisdictions in the normal flow of the application. GDPR-compliant hosting; standard contractual clauses apply where any cross-border transfer is required (currently none in standard operation).

🔐Authentication and access controlLive

• Authentication provider: Clerk (EU region). Email + password by default. Multi-factor authentication available.
• Session tokens: JWT-based, short-lived, refreshed via Clerk session.
• Role-based access control (RBAC): roles (planner, supervisor, trainer, user, admin) are encoded as JWT claims and enforced server-side via row-level security policies.
• SSO (SAML / OIDC): available on request via Clerk's enterprise tier. Available on request
• Password policy: minimum 8 characters, complexity rules configurable per tenant.
• Account lockout: after repeated failed attempts, governed by Clerk's policy defaults.

🏢Tenant isolationLive

TrainSync is multi-tenant by design. Each customer is a separate company_id. Isolation is enforced at the database layer using PostgreSQL row-level security (RLS) policies on every table that holds customer data.

Specifically:

• 11 application tables have RLS enabled, with policies referencing JWT claims via helper functions in the public schema
• Cross-tenant queries are physically impossible — a user authenticated as company A cannot read or write rows belonging to company B, even with direct REST API access
• The audit_log table is RLS-protected and append-only (no UPDATE or DELETE policies)

📜Audit trailLive

Every insert, update, and delete on 7 critical tables (people, trainings, sessions, enrollments, person_trainings, signature_documents, signature_steps) fires a database-level trigger that writes to the audit_log table.

Each audit entry captures: table name, record ID, action type, actor (resolved to internal person ID via Clerk's JWT sub claim), before/after JSON snapshots, IP address (where available), and a server-side timestamp.

The audit log is append-only at the policy layer. Even an admin user cannot modify historical audit entries through the application. RFC 3161 trusted timestamping is available on request for customers requiring it for regulatory submissions.

🔒EncryptionLive

• In transit: TLS 1.2+ enforced on all connections between client and Azure / Supabase / Clerk
• At rest: Supabase Postgres encrypts data at rest using AES-256 (AWS-managed keys)
• Backups: encrypted using the same standards as the live database

💾Backups and disaster recoveryDrafting

Supabase performs automated daily backups of the Postgres database. Point-in-time recovery is available within the retention window.

What we will document with each customer: a tested restore procedure, target recovery time objective (RTO), and target recovery point objective (RPO). We perform a restore drill before any production customer go-live.

Status: a documented backup/restore procedure with measured RTO is a Week 4 deliverable in our roadmap. Until then, we rely on Supabase's documented platform-level guarantees.

🤝Sub-processorsLive

The complete list of sub-processors is published in our DPA. In summary:

• Microsoft Azure — static-site hosting and CDN (EU West Europe, Netherlands)
• Supabase — Postgres database and authentication backend (EU West, AWS Frankfurt)
• Clerk — user authentication and session management (EU region)
• Plausible Analytics — privacy-friendly, cookieless website analytics (EU-hosted)
• Paddle — payment processing and Merchant of Record (planned Q3 2026, not active today)
• Resend — transactional email delivery (planned Week 2, not active today)

Customers are notified at least 30 days in advance of any sub-processor change.

🚨Incident responseDrafting

Today: incidents are handled directly by Louis Vangroenweghe as the operator. Customers will be notified within 72 hours of confirmation of any incident that affects their data, in line with GDPR Article 33.

What is being built: a formal incident response policy with severity levels, communication templates, post-incident review template, and a status page. This is a Week 4 deliverable.

Security or incident contact: security@trainsync.io

🔍Vulnerability managementDrafting

Today: dependency updates are applied as security advisories are issued. Supabase and Clerk patch their platform layers independently — TrainSync inherits those updates without action.

Planned: a third-party penetration test before the first paid customer go-live. We do not pursue SOC 2 or ISO 27001 certification at this stage because the cost (€30k–€50k per certification) is not justified pre-revenue. We will revisit once a customer's purchasing requirements warrant it.

📤Data export and deletionLive

Customers can export their data at any time in CSV or XLSX format. PDF export of signed records is in beta (Week 2 deliverable).

On contract termination, customer data is returned in machine-readable format on request and then deleted from our production systems within 30 days. Backups follow their own retention schedule (up to 30 days) after which the data is unrecoverable.

GxP training records may need to be retained for 5+ years per applicable regulation — see our data retention table in the privacy policy.

📋Validation and compliancePlanned

TrainSync is designed to support customer compliance with 21 CFR Part 11 (FDA) and EU GMP Annex 11. We do not self-certify, and we do not claim "Part 11 compliant" — that determination is made by the customer's QA team during validation.

The validation pack (URS, IQ, OQ, PQ scripts and traceability matrix) is in active drafting (Q3 2026 target). See the QA Pack page for the framework and what is available today.