Data Security

1. Data Protection Overview

We implement multiple layers of security to protect your data throughout its lifecycle - from the moment you enter it to when it's stored and processed.

1.1 Encryption Standards

• In Transit: All data transmitted via TLS 1.3 (HTTPS)
• At Rest: AES-256 encryption for stored data
• Passwords: bcrypt hashing with salt (we never store plain text passwords)
• API Communications: Encrypted end-to-end

1.2 Infrastructure Security

• Hosting: Vercel (SOC 2 Type II compliant)
• Database: Supabase (SOC 2 Type II, ISO 27001)
• DDoS Protection: Enterprise-grade mitigation
• Firewalls: Web Application Firewall (WAF) protection

2. Access Controls

2.1 User Data Isolation

We implement Row-Level Security (RLS) at the database level, ensuring:

• You can only access your own projects and data
• Other users cannot see or access your information
• Even our team has limited access to user data

2.2 Authentication

• Secure session management with automatic timeouts
• Server-side session validation (not just client-side JWT decode)
• IP-based lockout after repeated failed login attempts
• Secure password requirements with bcrypt hashing
• Two-factor authentication (TOTP) is planned for a future release. We will update this page when it becomes available.

2.3 Administrative Access

Administrative access to user data is granted on a least-privilege basis and only for specific operational purposes:

• Authorised personnel and contractors, where required for operations that cannot run automatically (responding to verified data subject requests, handling support escalations, investigating reported security issues)
• Trusted infrastructure providers (Supabase, Vercel, Stripe, Resend, Sentry, RevenueCat, Anthropic) operating under their respective Data Processing Agreements

All administrative access uses multi-factor authentication and is logged.

Audit Trail

Sensitive actions on the platform (account changes, data access, role changes, payment events) are recorded to an append-only audit log at the database level. The log is structurally write-once: there are no policies on the table that allow rows to be modified or deleted after they are written.

3. Data Storage & Backups

3.1 Storage Location

• Primary data stored in EU/UK data centers
• Redundant storage across multiple availability zones
• GDPR-compliant data residency

3.2 Backup & Recovery

• Automated daily backups
• Point-in-time recovery capability
• Encrypted backup storage
• Regular backup testing

4. Application Security

4.1 Secure Development

• Automated security checks on every build (21 build-blocking checks)
• Dependency vulnerability scanning via GitHub Dependabot and npm audit
• Regular security updates and patches
• OWASP security guidelines compliance
• Server-side error monitoring via Sentry, with technical diagnostic data only (no personal content or photos sent off platform)

4.2 Input Validation

• Server-side schema validation for all API inputs (Zod)
• Parameterised database queries (no raw SQL string concatenation)
• Protection against Cross-Site Scripting (XSS)
• CSRF token protection on browser-cookie-authenticated mutations
• Tiered rate limiting on API routes (auth, admin, AI, upload, general)
• Idempotency keys on payment and other state-changing v1 API routes
• File-type verification by magic bytes on uploads (not just extension)

4.3 Web Application Security Headers

Every response from Havnwright sets a strict set of HTTP security headers:

• Content Security Policy (CSP): Restricts which sources can load scripts, styles, images, frames, and connections. Allowlist includes only the services we actually use (Stripe, Supabase, Anthropic, Sentry, Cloudflare Turnstile, Google Analytics, Vercel).
• Strict-Transport-Security (HSTS): Forces all traffic to use HTTPS for one year, including subdomains.
• X-Frame-Options: Prevents the site from being embedded in third-party iframes (clickjacking protection).
• X-Content-Type-Options: Prevents MIME-type sniffing attacks.
• Referrer-Policy: Limits what referrer information is sent to other sites.
• Permissions-Policy: Restricts use of sensitive browser APIs (camera, microphone, geolocation) to what the application actually needs.

5. AI & Third-Party Security

5.1 AI Processing (Quote Extraction)

When you use AI features to extract quote data:

• Documents processed in real-time, not stored by AI provider
• Your data is NOT used to train AI models
• AI provider (Anthropic) maintains SOC 2 compliance
• AI processing is optional - manual entry always available

5.2 Third-Party Integrations

All third-party services we use are vetted for:

• Security certifications (SOC 2, ISO 27001)
• GDPR compliance
• Data Processing Agreements
• Regular security reviews

6. Your Security Responsibilities

Help us keep your data secure:

7. Incident Response

7.1 Our Commitment

In the event of a security incident, we will:

• Investigate and contain the incident immediately
• Notify affected users within 72 hours (as required by GDPR)
• Report to the ICO if required by law
• Provide guidance on protective steps you should take
• Implement measures to prevent recurrence

7.2 Reporting Security Issues

If you discover a security vulnerability:

• Email: security@havnwright.com
• Machine-readable disclosure terms: /.well-known/security.txt
• Please provide detailed information about the issue
• Do not exploit the vulnerability, publicise it, or share it with third parties before we have had a reasonable opportunity to respond
• We aim to acknowledge reports within 5 business days

8. Compliance & Certifications

8.1 Regulatory Compliance

• UK GDPR (UK General Data Protection Regulation)
• Data Protection Act 2018
• PECR (Privacy and Electronic Communications Regulations)

8.2 Infrastructure Certifications

• Supabase: SOC 2 Type II, ISO 27001, HIPAA
• Vercel: SOC 2 Type II, ISO 27001
• Anthropic: SOC 2, responsible AI practices

9. Contact

For security-related inquiries:

• Security Issues: security@havnwright.com
• Privacy Concerns: privacy@havnwright.com
• General: info@havnwright.com