Security Overview

This page describes how LaunchSafe builds and operates: the controls we hold ourselves to across the company and the products we are building. It is a summary rather than the full control set. Customers and prospects under NDA can request our security documentation and questionnaire responses at hello@launchsafe.com.

Architecture and tenancy

Our systems run on managed cloud infrastructure in hardened private networks. Each customer's data is logically isolated and scoped by tenant on every read and write, enforced in the data layer rather than only in application code. The products are built to run in a dedicated environment or inside your own VPC, so code and runtime data never leave their network boundary.

Encryption

Traffic is encrypted in transit with TLS 1.2 or above, with HSTS on our public endpoints. Data at rest is encrypted with AES-256. Secrets and credentials live in a managed secrets store, are encrypted with rotated keys, and are never written to logs or source control.

Access control

• Single sign-on and multi-factor authentication for customer accounts, with role-based access.
• Least privilege internally: production access is granted by role, time-bound, reviewed quarterly, and requires MFA.
• Every production access event is logged and retained for 12 months.
• Access is revoked as part of offboarding on the day someone leaves.

Secure development

• Code review is mandatory. Nothing reaches main without a second pair of eyes.
• Static analysis, dependency scanning and secret scanning run on every pull request, and the build fails on new high-severity findings.
• Environments are separated. Production data is never copied into development or staging.
• Infrastructure is defined as code and changes follow the same review path.
• We run our own products against our own platform before we ship them.

Monitoring and response

Application, infrastructure and audit logs are centralised, with alerting on anomalous authentication, privilege change and data-egress patterns. We maintain a written incident-response plan with defined severities, on-call ownership and post-incident review. Incidents affecting customer data are notified as set out in the Data Processing Agreement.

Vulnerability management

We patch on a risk-based schedule: critical issues in our own code or dependencies within 7 days, high within 30 days, and the rest at the next scheduled release. We commission independent third-party penetration tests annually and after significant architecture changes. Anyone can report an issue under our Vulnerability Disclosure Policy.

Resilience

Data is backed up daily, encrypted, and restores are tested. We target a recovery point objective of 24 hours and a recovery time objective of 8 hours for the core platform. Availability commitments are in the SLA and live status is at status.launchsafe.com.

People

Everyone at LaunchSafe passes a background check where the law allows, signs a confidentiality agreement, and completes security and privacy training at induction and annually. Sub-processors are reviewed before onboarding and at renewal; the current list is in the DPA.

Model security

Customer code and runtime data are not used to train or fine-tune our models, inference runs under zero-retention terms, and prompts and outputs are treated as customer data. Agent actions that are intrusive or destructive sit behind an explicit approval gate. See AI / Responsible Use.

Compliance

We are building to a SOC 2 Type II control set and support GDPR and UK GDPR obligations through our DPA. Email hello@launchsafe.com for our current certification status, reports and security questionnaire responses.