1. Our Security Commitment
Security is foundational to Alva Health. We process sensitive health and financial data and take our responsibility to protect it seriously.
- Defence in depth: multiple overlapping security controls at every layer
- Least privilege: access restricted to the minimum necessary
- Encryption by default: all data encrypted at rest and in transit
- Continuous monitoring: automated alerting for anomalous behaviour
- Transparency: security incidents communicated promptly and honestly
2. Infrastructure Security
2.1 Hosting
The Alva website and platform is hosted on Vercel (frontend) with backend services and data processing within the EU where possible. All providers are subject to data processing agreements and security assessment.
2.2 Environment separation
We maintain separate development, staging, and production environments. No real user data is used in development or staging. Each environment has independent access controls.
2.3 Network security
- All traffic served over HTTPS with TLS 1.3
- HTTP Strict Transport Security (HSTS) enforced
- Content Security Policy (CSP) headers in place
- DDoS protection at infrastructure level
3. Data Encryption
| State | Standard | Applies to |
|---|---|---|
| Data in transit | TLS 1.3 | All user data · API communications · CGM data transmission |
| Data at rest | AES-256 | All personal data · health data · payment data |
| Database backups | AES-256 | All backups |
| Authentication tokens | HMAC-SHA256 | Session tokens · API keys |
4. Access Controls
- MFA required for all staff access to production systems
- Access to user health data restricted to minimum authorised personnel
- All staff access is role-based and audited
- Administrative access reviewed quarterly and revoked immediately on departure
- Privileged access management (PAM) for infrastructure access
- Annual data protection and security training for all staff with data access
5. Application Security
5.1 Secure development
- Security integrated into development lifecycle from design through deployment
- All code changes peer-reviewed before production deployment
- Dependency scanning for known vulnerabilities automated in CI/CD pipeline
- Static application security testing (SAST) applied to all releases
5.2 Authentication and session management
- Passwords hashed using bcrypt (minimum cost factor 12)
- Session tokens expire after inactivity
- Stripe handles all payment card data — we never store raw card details
- Stripe webhook payloads verified using Stripe-Signature headers
- Idempotency controls prevent duplicate payment processing
5.3 Input validation and injection prevention
- All user inputs validated and sanitised server-side
- Parameterised queries throughout to prevent SQL injection
- XSS protections applied across all pages
- CSRF tokens on all state-changing operations
6. Third-Party Security
| Provider | Certification |
|---|---|
| Stripe | PCI DSS Level 1 · SOC 2 Type II |
| PostHog | SOC 2 Type II · EU data residency available |
| HubSpot | SOC 2 Type II · ISO 27001 |
| Vercel | SOC 2 Type II |
| Sentry | SOC 2 Type II |
7. Vulnerability Management
We maintain a continuous vulnerability management programme:
- Automated dependency scanning on every code commit (Dependabot or equivalent)
- Weekly automated vulnerability scans of production infrastructure
- Critical vulnerabilities remediated within 24 hours of discovery
- High vulnerabilities remediated within 7 days
- Medium and low vulnerabilities tracked and remediated within 30 days
- Vulnerability register maintained and reviewed monthly
8. Penetration Testing
- Annual penetration testing by independent third-party security firm
- Scope: web application, API, mobile application, and infrastructure
- Findings reported to senior leadership and remediation tracked to closure
- Re-testing conducted after remediation of critical and high findings
- Penetration test reports available to enterprise customers and regulatory authorities on request
9. Disaster Recovery and Business Continuity
9.1 Backup and recovery
- Database backups performed daily with 30-day retention
- Backups encrypted at rest (AES-256) and stored in a geographically separate location
- Recovery time objective (RTO): 4 hours for core platform services
- Recovery point objective (RPO): 24 hours maximum data loss
- Backup restoration tested quarterly
9.2 Business continuity
- Documented business continuity plan reviewed annually
- Critical services identified and prioritised for recovery
- Incident escalation procedures documented and tested
- Key person dependencies identified and mitigated through documentation and cross-training
10. ISO 27001 and SOC 2 Roadmap
We are committed to achieving recognised security certifications as the business scales. Our roadmap:
| Certification | Target | Status |
|---|---|---|
| SOC 2 Type I | 2027 H1 | Planning — control framework being established |
| SOC 2 Type II | 2027 H2 | Dependent on Type I completion |
| ISO 27001 | 2028 | Planning — gap analysis to be conducted |
11. Incident Response
- Documented incident response plan maintained and reviewed annually
- GDPR breach notification within 72 hours to relevant supervisory authority where required
- Affected users notified without undue delay where high risk to rights and freedoms
- Breach register maintained (GDPR Article 33(5))
- Post-incident review conducted for all significant incidents
12. Responsible Disclosure
If you discover a security vulnerability, report it responsibly to: security@alva.health
Include: description of the vulnerability, steps to reproduce, supporting evidence. We will acknowledge within 48 hours and aim to resolve confirmed vulnerabilities within 30 days. Please do not publicly disclose until we have remediated.
13. Contact
Legal enquiries: legal@alva.health
Data protection / DPO: dpo@alva.health
General support: support@alva.health
Security issues: security@alva.health