Security at Evelmo

Your data

You own your audit log data. Full stop. You can export everything — in both CSV and JSON — from your dashboard at any time, without needing a support ticket or a support conversation. CSV is optimized for human reading and downstream use (sharing with auditors, importing into spreadsheets). JSON preserves the full event structure, including sequence numbers and hash fields, for migration or machine use.

Only you and the org members you invite can read your audit events. Evelmo staff access to your logs is limited to production incident response, is logged, and is available to you on request. We do not train on, analyze, or share your data.

If Evelmo is ever shut down, you will receive 90 days notice, a final data export, and published format specifications so that you can migrate your audit trail to another system or self-host it. Your audit trail does not disappear because the company does.

How integrity works

Evelmo's core differentiator is that your audit log isn't just append-only — it's cryptographically verifiable. Here's how it works, in plain terms.

The hash chain

Every event you write is stored with a SHA-256 hash (leafHash) computed over its canonical JSON representation. Events are numbered with a strictly monotonically-increasing sequence number (seq), scoped to your organization. Writes happen inside a database transaction, so the sequence counter and the event insert are atomic — there are no legitimate sequence gaps under normal operation.

Together, these properties mean that any field-level tampering, deletion, reordering, or retroactive insertion of events leaves an arithmetic trace.

On-demand verification

You can verify your entire chain at any time by calling POST /v1/logs/verify. The response tells you whether every event hash and sequence number is consistent.

To keep the dashboard instant at any chain size, a background job runs every 60 seconds to check only what's new since the last verification, using a rolling-hash algorithm. This means the chain-health card on your dashboard loads in milliseconds whether you have 1,000 events or 100 million.

External tamper evidence

GET /v1/logs/tip returns the current state of your chain: the latest sequence number, its leaf hash, and the timestamp of the event it references. You can pin this tip externally — in your own systems, with a third party, or in any external immutable store — so that integrity can be verified independently of Evelmo's API.

What this detects today, and what's next

The current model detects field-level tampering, event deletion, event reordering, and retroactive insertion. It does not yet detect tail truncation (removal of the most recent events) or tampering by a malicious database operator — those require cryptographic signatures and external anchoring.

Our Phase 2 roadmap addresses both. We're implementing a Merkle-tree structure with Ed25519-signed tree heads, anchored externally to an immutable store (S3 with Object Lock). This follows the well-studied Certificate Transparency design and will give you independent cryptographic verifiability — you will not need to trust Evelmo's API to prove your log's integrity.

Availability and your critical path

Evelmo's SDK is non-blocking by default. evelmo.log() enqueues the event in-process and returns in microseconds. A background worker sends to the API with exponential-backoff retry and an auto-generated idempotency key per event. Your request path never waits on our network, and a short Evelmo outage is absorbed by the local buffer rather than surfaced to your users.

Concretely:

• Fire-and-forget default. log() resolves as soon as the event is buffered. Your handler's p99 latency does not depend on Evelmo's p99 latency.
• In-memory queue. Up to 10,000 events buffered per client by default. Flushed on a 1-second cadence.
• Exponential-backoff retry. 500 ms up to a 30-second cap, 5 attempts per event by default.
• Idempotent delivery. Every send carries an auto-generated Idempotency-Key, so a retry never pollutes the chain with a duplicate.
• Graceful shutdown. evelmo.flush() drains the queue on SIGTERM so buffered events don't get lost on a deploy.
• Visibility. onError and onDrop callbacks fire when an event is irrevocably lost, so you can alert your own monitoring rather than find out weeks later.

When back-pressure is the right tradeoff — typically financial, regulatory, or compliance-critical writes where losing the event is worse than blocking — pass { sync: true } to await the network call directly. That's opt-in, per call or per client, and it's explicit by design.

Full behavior and configuration in the docs.

Infrastructure

• Backend: Express on Google Cloud Run, deployed in us-central1.
• Database: MongoDB Atlas (replica set configuration to support transactional writes). Encrypted at rest; TLS in transit.
• Frontend: Next.js on Vercel.
• Authentication: Clerk (SOC 2 Type II certified).
• Secrets management: Google Secret Manager. No secrets in source or environment config.
• Transport security: TLS 1.2+ enforced on all public endpoints.

Currently, all production data is stored in us-central1. EU data residency is under evaluation based on customer demand — if this is a hard requirement for you, get in touch.

Operational posture

• Structured logging. Every request is tagged with a unique identifier, making incidents traceable end-to-end.
• Health checks. The service verifies database connectivity on every health probe; unhealthy instances are cycled automatically.
• Graceful shutdown. On deploy or scale-down, instances drain in-flight requests before exiting to prevent dropped writes.
• Incident response. Security-impacting incidents are reported to affected customers within 72 hours, in writing, with a documented remediation plan.

Access and personnel

Production access to Evelmo's infrastructure is currently limited to the founder. All access is logged. Credentials are rotated on a regular cadence. Multi-factor authentication is required on every service we use — cloud provider, database, frontend host, authentication provider, and secrets manager.

As Evelmo grows and takes on team members, this page will be updated to reflect expanded access controls and the processes that govern them.

Compliance

There are two separate compliance questions worth addressing directly.

Evelmo's own certifications

Evelmo is not yet SOC 2 Type II certified. SOC 2 Type I is planned for the coming months, with Type II to follow. We will update this page with status as we progress.

How Evelmo supports your compliance

Evelmo is built to provide the evidence your auditors need. The cryptographic integrity model, the retention controls, and the verification endpoint together cover the logging-and-monitoring requirements of:

• SOC 2 CC7.2 and CC7.3 (system monitoring and anomaly evaluation)
• HIPAA §164.312(b) (audit controls)
• GDPR Article 30 (records of processing activities)

Our standard Data Processing Agreement is published at evelmo.com/dpa — review it before requesting a counter-signed copy from privacy@evelmo.com. We'll evaluate BAA requests on a case-by-case basis for HIPAA customers, but we won't sign one until our HIPAA-specific technical safeguards are in place — we'll tell you honestly where we stand on your timeline. If HIPAA is a hard requirement, talk to us at security@evelmo.com before building against Evelmo.

Subprocessors

Evelmo relies on four third-party services to operate: Google Cloud (compute, secrets, scheduled jobs), MongoDB Atlas (database hosting), Vercel (frontend and edge delivery), and Clerk (authentication). Each has access only to the infrastructure-level data necessary for their role.

Full list with processing purpose, region, and DPA links on the subprocessors page. We notify customers at least 30 days in advance of any change.

Reporting a vulnerability

If you believe you've found a security issue in Evelmo, please email security@evelmo.com with a description of the issue and any reproduction steps. We commit to acknowledging every report within 48 hours.

We don't currently run a bug bounty program. Valid reports will be credited in a public acknowledgments list, with the reporter's permission.