Security Policy

1. Governance

• Security ownership: a named security lead in engineering, with executive sponsorship at the CEO level.
• Written policies: access, encryption, incident response, vulnerability management, and data retention are all covered by written internal policies reviewed at least annually.
• Training: every team member completes security training on hire and annually thereafter, covering phishing, credentials, data handling, and incident escalation.
• Background checks: conducted for all employees prior to access.

2. Infrastructure

• Primary hosting: DigitalOcean and Amazon Web Services (AWS), both certified to ISO 27001 and SOC 2 Type II.
• Regions: US-East, EU-Frankfurt, and — for select customers — dedicated regional deployments.
• Network isolation: production, staging, and development environments are logically isolated. Production is only accessible via bastion hosts requiring MFA + short-lived credentials.
• Edge protection: Cloudflare in front of every public endpoint — DDoS mitigation, WAF rules, rate limiting.

3. Encryption

• In transit: TLS 1.3 required on all external endpoints. HSTS preloaded. Modern cipher suites only.
• At rest: AES-256 for databases (Postgres), object storage, and backups.
• Key management: managed KMS with hardware-security-module-backed root keys. Automatic key rotation.
• Password storage: bcrypt with cost 12 (never MD5, SHA1, or plaintext).
• Sensitive fields: passport numbers, national IDs, and payment metadata are additionally encrypted at the application layer.

4. Access control

• Least privilege: employees have only the access needed for their role.
• MFA everywhere: mandatory for all production access, admin consoles, code repositories, and CI/CD.
• Just-in-time access: production access is time-boxed and audited. No standing SSH keys on servers.
• Session security: customer-facing session tokens rotate every 15 minutes with refresh; expire on inactivity.
• Customer-side controls: role-based permissions per module, TOTP-based 2FA (Google Authenticator, Authy, 1Password), IP allowlisting on Enterprise plans, and a complete audit trail available in-app.

5. Multi-tenant isolation

TravelBoost is multi-tenant. Every table in our database includes an agencyId column, and every application query filters by the current tenant’s agencyId before returning any row. This is enforced at the query layer, not just the application layer, and is covered by automated tests on every deployment. It is not possible for one agency’s users to access another agency’s data.

6. Application security

• Secure development: code reviewed by at least one other engineer before merge; automated security scans in CI/CD.
• Dependency management: Renovate + Dependabot for continuous vulnerability tracking; critical patches applied within 48 hours.
• Static analysis: SAST tooling flags common vulnerability patterns before deployment.
• Input validation: Zod schemas at every API boundary; no free-form SQL.
• Output encoding: React’s built-in JSX encoding + Content Security Policy headers.
• CSRF protection: synchroniser tokens on state-changing requests.

7. Monitoring and logging

• 24/7 log aggregation and anomaly detection across application, infrastructure, and network layers.
• Alerts on unauthorised access attempts, unusual data volumes, and configuration drift.
• Immutable audit trail of every user action (create, update, delete, login, export, permission change) available in-product and retained for 7 years by default.

8. Backups and disaster recovery

• Backups: continuous point-in-time database backups, retained for 30 days.
• Storage: object storage replicated across at least three availability zones.
• Restore drills: automated monthly, with an annual full disaster-recovery exercise.
• Recovery objectives: RPO ≤ 5 minutes, RTO ≤ 4 hours for the production application.

9. Vulnerability management

• Automated dependency scanning; critical CVEs patched within 48 hours, high within 7 days.
• Annual third-party penetration test of the production platform; findings tracked to closure.
• Public responsible-disclosure channel at [email protected]. We commit to acknowledging every report within 48 hours.

10. Incident response

• Documented incident-response playbooks covering detection, containment, eradication, recovery, and post-mortem.
• On-call rotation for security events, 24/7.
• Customer notification within 48 hours of confirmed personal-data breach affecting their data (in line with our DPA).
• Post-incident public write-ups on the system status page when an event affected multiple customers.

11. Data retention and deletion

We retain personal data only as long as needed to provide the Service and to meet legal obligations. Detailed retention periods are described in the Privacy Policy. On termination, Customer Data is deleted from active systems within 30 days and from backups within 90 days.

12. Vendors and sub-processors

All sub-processors handling Customer Data are contractually bound to security standards equivalent to those described here. See DPA Annex C for the current list.

13. Compliance

• GDPR / UK GDPR: full compliance for EEA / UK data subjects. Standard Contractual Clauses in place for transfers.
• CCPA / CPRA: compliance for California residents.
• PCI-DSS: we do not store cardholder data; all card processing is handled by PCI-DSS Level 1 certified providers (Stripe, PayPal).
• SOC 2 Type II: attestation planned; interim documentation available under NDA for Enterprise customers.

14. Report a security concern

If you believe you’ve found a security issue, contact us privately at [email protected]. Please include:

• A clear description of the issue;
• Steps to reproduce, if applicable;
• The URL(s) or endpoint(s) affected;
• Any relevant screenshots or logs;
• Whether you require a coordinated disclosure timeline.

We commit to acknowledging every report within 48 hours and to working in good faith on remediation. We do not take legal action against researchers who follow responsible-disclosure practices.