Evitrus security whitepaper
This document is a short overview for vendor security questionnaires. It describes how the managed Evitrus cloud on evitrus.io is built and operated today. It is not a SOC 2 report and not an ISO 27001 certificate.
1. Product
Evitrus is an evidence platform. Exporters that run inside the customer boundary push normalized Evidence Events to the managed cloud, which correlates those events into Changes, supports incident timelines, and maps activity to compliance packs (for example SOC 2 CC7/CC8). Customers remain in control of what their exporters send.
2. Cloud and residency
The production service is the managed cloud on *.evitrus.io, with an EU data residency commitment for hosted databases described in Security & residency. Workloads run on Kubernetes. Identity, sessions, and overlays live in Postgres. Evidence Events and the organisation audit log are written to an append-only event store in the same EU cluster. Transactional email is delivered by Lettermint in the European Union. Optional metrics from Datadog or Prometheus are pulled on demand with the customer’s own credentials and are not stored as Evitrus’s system of record.
3. Encryption
Public HTTPS endpoints are protected with TLS in transit. Data-store volumes use provider-managed encryption at rest. Customer-managed keys (CMEK) are not available in the current product; the intended path is described in the residency documentation.
4. Authentication and authorization
Human users sign in with email and password. Organisations may optionally enable OIDC SSO and SCIM provisioning. Machines authenticate with tenant API keys (evt_…) that are scoped to ingest. Authorization is fine-grained RBAC (resource.action) rather than checks against role names, and the tenant id is always derived from the credential rather than taken from the client.
5. Isolation and integrity
Every read and write is logically multi-tenant. The evidence store is append-only: each event is sealed with a contentHash so later overlays cannot quietly rewrite the body. Organisation overlays such as assignments and enrichments live in Postgres and leave sealed event bodies unchanged.
6. Secrets
API keys are stored hashed (SHA-256); only prefixes are shown in the UI after creation. Deploy secrets are injected through cluster secret management and CI secrets, and are not committed to git. Customer exporter keys never leave the customer boundary except as Bearer tokens presented to ingest.
7. Logging and audit
Each organisation has an activity audit log that can be exported as CSV or JSON. Platform operators retain API and deploy-pipeline logs for operations and incident investigation, under privileged access.
8. Backups and availability
Backup posture, RPO/RTO targets, and restore expectations are described in Backup & availability. The figures there are current operating targets for the managed cloud, not a contractual high-availability commitment.
9. Supply chain
Dependencies in the Go and npm repositories are updated on an ongoing basis. Container images are built in CI and pinned by digest in deploy overlays. Static analysis and secret scanning run in GitHub as configured per repository. SBOM, Cosign, and SLSA attestations are on the roadmap and are not claimed for the current service.
10. Penetration testing and certifications
No independent penetration-test report has been published yet. An external test is planned before broader general-availability sales. Evitrus does not yet hold a SOC 2 Type I/II report or an ISO 27001 certificate; organisational ISMS work is underway and can be discussed under NDA. In-product compliance packs map customer evidence to control frameworks and are not an attestation of Evitrus’s own programme.
11. Operations
| Question | Answer (2026-08) |
|---|---|
| Production customers | Closed beta |
| Engineering team size | Small founding team |
| Production access | Designated operators only; there is no standing admin access for every engineer |
| Change review | Pull requests with squash-merge to main; automated deploys pin image digests |
| On-call | Best-effort during beta; a formal rotation accompanies paid SLAs |
Contact: security@beneke-consulting.com (see Security contact).