Data Security Statement

General information notice. This statement describes the security measures we have in place. It is provided to help you make an informed decision about entrusting us with your data. It is not a warranty or contract.

1. Encryption

All data exchanged between your browser and our servers is encrypted using TLS 1.2 or higher. The padlock you see in your browser’s address bar confirms this. We do not accept plaintext (HTTP) traffic; all traffic is automatically upgraded to HTTPS.

Data at rest is encrypted as well:

• Our PostgreSQL database (hosted on Railway) uses disk-level encryption.
• User passwords are never stored in plaintext — they are hashed by our authentication provider Clerk using industry standard one-way hashing algorithms (bcrypt with per-user salts).
• Card details are never stored in our systems. They are sent directly from your browser to Stripe’s PCI-compliant infrastructure.

2. Authentication

Authentication is handled by Clerk, a SOC 2 Type II audited identity platform.

• Passwords are hashed with bcrypt using a per-user salt; we never see your plaintext password.
• Sessions are managed using short-lived JSON Web Tokens (JWT) signed with a rotating secret. Tokens expire automatically and must be refreshed.
• Failed sign-in attempts are rate-limited at the network edge to mitigate brute-force attacks.
• Password resets require email confirmation; we never send a new password by email.

3. Payment security and PCI compliance

We do not handle card data ourselves. All payments are processed via Stripe, which is certified to PCI-DSS Level 1 — the most stringent level of payment-card industry compliance.

• Card numbers, CVV codes, and expiry dates are entered into a Stripe-hosted iframe or redirect; they never touch our servers.
• We only ever see a one-way reference token (the Stripe Payment Intent ID), the amount paid, and a 4-digit suffix of the card so you can recognise it on receipts.
• Stripe Radar provides real-time fraud screening on every transaction.

4. Access control

We follow the principle of least privilege:

• Only the teacher (the sole staff member) has administrative access to the booking system.
• Each student account can only see its own bookings, package credits, and personal data. Server-side authorisation checks (“BOLA” protections) are enforced on every API endpoint to prevent any user from reading or modifying another user’s data.
• Database credentials and API keys are stored as environment secrets in Railway; they are never committed to source code or shared in chat.
• Production deployments require approval; we do not give shell access to third-party developers.

5. Application security measures

• Helmet HTTP headers — we set a strict Content Security Policy, X-Frame-Options, Strict-Transport-Security, and other modern security headers on every response.
• Input validation — every API request is validated against a Zod schema before being processed. Malformed or unexpected input is rejected with a clear error.
• Rate limiting — sensitive endpoints (sign-in, password reset, booking creation) are rate-limited to mitigate abuse and brute-force attacks.
• SQL-injection protection — we use the Prisma ORM, which uses parameterised queries by default. Raw SQL is never built from user input.
• XSS protection — React escapes user content by default; we use dangerouslySetInnerHTML only for static, server-side JSON-LD data.
• Dependency monitoring — we monitor our npm dependencies for known vulnerabilities and patch promptly.

6. Hosting and infrastructure

Our application and database are hosted by Railway in EU/UK regions. Railway provides automated daily backups, encrypted at rest, with point-in-time recovery available.

Static assets and the public website are served via a CDN with DDoS protection at the edge.

7. Email security

Transactional email (booking confirmations, reschedule notices, receipts) is sent via Resend. Our sending domain is configured with SPF, DKIM, and DMARC records to prevent spoofing of emails appearing to come from us.

8. Breach notification

In the unlikely event of a personal-data breach, we commit to:

• Notifying the UK Information Commissioner’s Office (ICO) within 72 hours, as required by Article 33 of the UK GDPR.
• Notifying any affected individuals directly and without undue delay where the breach is likely to result in a high risk to their rights and freedoms (Article 34).
• Publishing a clear summary of what happened, what data was affected, and what we are doing about it.

9. Reporting a vulnerability

If you believe you have found a security vulnerability in our website or systems, please email hello@bournemouthmusicschool.com with the subject line “Security report”. We will acknowledge your report within 5 working days. Please give us a reasonable time to investigate and remediate before any public disclosure.

10. Third-party security pages

Our key processors maintain their own security and compliance documentation:

• Stripe security & PCI compliance
• Clerk security and SOC 2
• Resend security
• Railway security

11. Contact

For security questions, data-protection enquiries, or breach reports, email hello@bournemouthmusicschool.com.