Security

We’re a UK-based engineering team building Mecha Site to enterprise-grade standards from day one. Many controls below mirror SOC 2 Trust Services Criteria; we’re working towards SOC 2 Type II certification (target Q2 2027 — see Section 9).

• In transit: TLS 1.3 enforced on all customer-facing endpoints. HSTS preload submitted. Modern cipher suites only.
• At rest: all secrets, CMS credentials, MFA seeds, and complainant emails are encrypted with AES-256 (Fernet format) using versioned, regularly-rotated encryption keys.
• JWT signing: RSA PS256 (Probabilistic Signature Scheme, RFC 8017) with monthly key rotation and a 30-day overlap window for graceful client transition.
• Password hashing: Argon2id with cost parameters tuned to current OWASP guidance.
• Key management: RSA private keys stored encrypted in our database under a master key supplied via environment variable; no key material ever in source control.

• Multi-factor authentication available to all users; mandatory for all admin and platform-developer accounts. FIDO2 / WebAuthn passkeys preferred; TOTP supported as fallback.
• OAuth single sign-on via Google, GitHub, and other major providers with PKCE (RFC 7636).
• Session management: session pinning, idle and absolute timeouts, device fingerprint, ability to revoke individual sessions from your account.
• Account lockout after a configurable number of failed attempts; resolved either via verified email reset or admin unlock with audit log.

• Least privilege: staff get the minimum role needed for their function. Platform-admin actions require dual approval for irreversible operations (e.g., admin-initiated erasure).
• Layered authorisation at the API boundary: edge rate limiting, signed-token verification with role checks, and organisation-scoped data access on every request.
• API keys for programmatic access are scoped, hashed in storage, and revocable.
• Quarterly access reviews for staff with production data access (target Q3 2026 onwards).

• Append-only audit log recording every authentication, MFA, OAuth, password reset, erasure, DSAR, breach, complaint, and policy event. Retained for 6 years and never modified after write.
• Internal staff actions are independently logged with actor, target, reason, IP, and user-agent.
• Sentry for real-time error monitoring, with cross-layer secret scrubbing at the SDK level (no DSNs, tokens, connection strings ever leave the process).
• Per-category retention monitoring: each scheduled cleanup category has its own Sentry Crons check-in so a partial failure surfaces as an alert, not silent under-retention.

• Database: Neon Postgres in the UK (eu-west-2 region) — our primary store of personal data does not leave the United Kingdom.
• Application hosting: Render. Autoscaling, isolated per-environment.
• CDN + edge: Cloudflare for DDoS protection, DNS, and edge caching. Web Application Firewall on auth-sensitive routes.
• Object storage: Cloudflare R2 with EEA-resident buckets for all generated artefacts and DSAR exports.
• Secrets management: environment-variable injection from Render’s encrypted secret store. No secrets in source control (CI scans block any leak).

• Code review on every change before merge.
• Automated checks: type checking, linting, unit/integration tests, dependency vulnerability scanning (Snyk + GitHub Advanced Security), and a custom privacy-lint that fails CI on any unclassified storage write or PII manifest drift.
• Supply chain hardening: install-script execution disabled by default, blocking dependency-vulnerability audit in CI, and continuous third-party package monitoring.
• Migration safety: all database schema changes are generated, reviewed, and applied via promotion gates.

We maintain a written incident response plan covering detection, containment, eradication, recovery, notification, and lessons learned. We aim to:

• Detect production incidents within minutes via Sentry alerts.
• Notify the ICO within 72 hours of becoming aware of any personal-data breach posing risk to affected individuals (Art. 33).
• Notify affected individuals where the breach is likely to result in a high risk to their rights and freedoms (Art. 34), with the structured Article 34(2) elements (nature, DPO contact, likely consequences, mitigation measures).
• Run regular tabletop exercises (first scheduled Q3 2026, semi- annually thereafter).

Our breach-handling commitments are detailed at /legal/breach-notification.

• SOC 2 Type II: all five Trust Services Criteria (Security, Availability, Confidentiality, Privacy, Processing Integrity). Observation period begins Phase 6 of our compliance programme; audit target Q2 2027.
• Penetration testing: CREST-accredited semi-annual external pen-test programme aligned with our enterprise customer commitments; continuous vulnerability scanning via Snyk + GitHub Advanced Security in the interim.
• ISO 27001: assessed for applicability post-SOC 2.

• We’ll acknowledge within 2 working days, triage within 5, and keep you informed of remediation progress.
• We will not pursue legal action against researchers acting in good faith under reasonable scope (no destructive testing, no access to others’ data, no PII exfiltration).
• We do not currently operate a paid bug bounty; we will publicly credit reporters with permission once the issue is fixed.