Security

Security is a first-class concern in everything we build and in how we run our own business. This page summarises the technical and organisational measures we rely on, and explains how to report a vulnerability if you find one.

1. Infrastructure

Production workloads run on an enterprise-grade hyperscale cloud in EU regions. We use hardened managed platform services rather than self-managed virtual machines, to minimise the attack surface and inherit the cloud provider's controls. Secrets are stored in a dedicated secret-management service, never committed to source control, and never written to application logs.

2. Encryption

All traffic is encrypted in transit using TLS 1.2 or newer with modern cipher suites. HSTS is enabled on our public domains. Data at rest is encrypted using AES-256.

3. Access control

Access to cloud resources is federated through a central identity provider with multi-factor authentication enforced for all identities. Least-privilege role assignments apply at the resource boundary; there are no long-lived admin credentials. Customer engagement data is scoped per-engagement and access is reviewed when an engagement ends.

4. Secure development

Every change to our code ships through a reviewed pull request with automated checks: dependency vulnerability scanning, static analysis, unit and integration tests, and a preview build. Branch policies prevent direct pushes to protected branches. Deployments to production require explicit human approval.

5. Monitoring & response

Production services emit structured logs and metrics to a centralised observability backend. Synthetic critical-path checks run on a regular cadence and page on failure. Cloud-provider security alerts are triaged on receipt.

6. Data retention & deletion

We only hold the data we need to deliver the engagement. At the end of an engagement, customer data is deleted or handed back according to the instructions in the statement of work, and in any event no later than the retention window set out in our Privacy Policy.

7. Customer-delivered software

Software we build for customers inherits these defaults by construction: encrypted transport, managed identities for service- to-service calls, secrets in a managed vault, no long-lived credentials in code, dependency scanning in CI, and infrastructure-as-code so configuration is reviewable. Specific posture is reviewed and documented per engagement.

8. Responsible disclosure

If you believe you have found a security issue in any Cermus property or in software we delivered, please contact us through the legal inquiry form and select a subject line starting with [Security]. Include the steps to reproduce, the impact, and any supporting proof-of-concept. We aim to acknowledge within two business days and to keep you informed until the issue is resolved. We do not pursue legal action against good-faith researchers who:

• do not access, modify, or retain data beyond what is strictly necessary to demonstrate the issue;
• do not run denial-of-service or social-engineering attacks;
• give us reasonable time to remediate before disclosing publicly.

This page describes our current posture and may be updated as our infrastructure evolves. The date at the top of this page indicates the most recent revision.

To report a vulnerability or ask about our security posture, please use our legal inquiry form.