Skip to content

Security

Your telemetry runs your incident. Full stop.

Ember reads your logs, alerts and traces to name the root cause and write the postmortem. It does not use that data to train shared models, and it never acts on production without a human. This page covers how data is handled, how access is controlled and where our compliance posture stands.

01Data handling

Processed for the incident, not for us

Your telemetry is ingested, analyzed, and stored to run your incidents. That is the only use. It does not train shared models and it does not train workloads for other customers.

Data use

Telemetry runs your incident, not our models

Your logs, traces, alerts and deploy events are processed to produce root-cause analysis and postmortem output. They are not used to train shared models or any other customer's workload. This is a contractual commitment written into your agreement.

Retention

Retention you control

Incident telemetry is retained for 90 days by default to support timeline replay and postmortem review. On Scale you can shorten the window or set a deletion trigger at incident close. Contact us to request early deletion at any time.

Access

Least-privilege access

No Ember employee has standing access to your incident data. Elevated access requires an explicit, time-bounded grant approved by a second party and reviewed on completion. All grants are logged.

Residency

US by default, EU on request

Incident data is stored in the United States by default. EU data residency is available on Scale. Bring-your-own VPC deployments keep data entirely inside your own perimeter.

02Encryption

TLS 1.2+ in transit, AES-256 at rest

In transit

TLS 1.2+ on every connection

All data moving between your infrastructure and Ember travels over TLS 1.2 or higher. TLS 1.3 is preferred and negotiated by default. There is no unencrypted path into the pipeline.

At rest

AES-256 at rest

Incident telemetry, analysis output, timelines and postmortems are encrypted at rest with AES-256 across all storage layers. Encryption keys are managed per-tenant.

03Access and identity

SSO, SCIM, audit logging, RBAC

Scale tier. Fine-grained control over who can see what, provisioned from your identity provider, with every access event on record.

SSO: SAML 2.0 and OIDC

Scale customers can enforce single sign-on via any SAML 2.0 or OIDC identity provider. Unenrolled users cannot access the console when SSO is required.

SCIM provisioning

Provision and deprovision users automatically from your identity provider via SCIM 2.0. Deprovisioned accounts lose access within minutes, not on the next sync.

Audit logging

Every access event, configuration change and approval is written to a tamper-evident audit log. Scale customers may export the log stream to their own SIEM in real time.

RBAC

Roles control what each member can view and do: viewer, responder, approver and admin. Responders can acknowledge and annotate; only approvers can approve drafted rollbacks.

04Deployment options

Managed cloud, your VPC, or your own models

Ember runs where your security team is comfortable. The default is managed cloud. On Scale you can run entirely inside your own perimeter or point the reasoning layer at model endpoints you control.

Ember-managed cloud

The default. Ember hosts and operates the pipeline. Telemetry is processed in isolated, single-tenant compute. No shared pools touch your data.

Self-hosted inside your VPC

Available on Scale. Deploy Ember's reasoning pipeline inside your own VPC or private perimeter. Telemetry never leaves your network and you control all storage.

Bring your own model endpoints

On Scale, point Ember at your own model endpoints, whether a self-hosted open-weights model or a private deployment on your cloud provider. The routing layer is one config change.

05Human approval

Ember never acts on production on its own

Drafts the fix. Waits for you to run it.

Ember produces a ranked root cause and a drafted rollback or fix with the exact commands. Nothing is executed automatically. On Team, a responder can approve a drafted rollback from Slack, but a person still runs the command. Every approval decision is written to the audit log with the actor, timestamp and incident ID. There is no configuration that enables autonomous production changes.

06Compliance

Where we stand

We state our compliance posture as it is. Where something is in progress, we say so and do not claim it is complete.

SOC 2 Type II

Our SOC 2 Type II audit is currently in progress with an accredited third-party auditor. We expect to share the completed report with customers once it is issued. In the meantime, customers who need current controls documentation may request it from security@emberoncall.com.

GDPR

Ember is designed to be aligned with the EU General Data Protection Regulation (GDPR) and the UK GDPR. Where your incident telemetry contains personal data, Ember acts as data processor and you remain the controller. We process that data only on your instruction and only for the purpose of running the incident.

A written Data Processing Agreement (DPA) is available to all customers and is required for regulated industries. Write to security@emberoncall.com to request a copy.

Sub-processors

We use a small number of sub-processors for compute, object storage and communications. The full sub-processor list is available on request. Customers on Scale receive advance notice before any new sub-processor is added, with a 30-day window to raise objections. Each sub-processor is assessed against our data handling requirements before use.

Data residency

Incident data is stored in the United States by default. EU data residency is available on the Scale tier. Customers who deploy Ember inside their own VPC hold data exclusively within their own environment and perimeter.

SOC 2 Type II (in progress)

Our SOC 2 Type II audit is underway with an accredited third-party auditor. We do not claim certifications we have not yet received. Customers who need current controls documentation may request it.

GDPR-aligned

Ember processes personal data found in telemetry only as a data processor on your instruction. You remain the controller. A Data Processing Agreement (DPA) is available to all customers and required for regulated industries.

Sub-processors

We use a small number of sub-processors for compute, object storage and communications. The current list is available on request. You will receive advance notice of any additions or changes.

07Responsible disclosure

Found a vulnerability? Tell us.

Report to security@emberoncall.com. We acknowledge within 24 hours, provide status updates every 30 days, and resolve confirmed issues within 90 days. Use the form below or email directly.

What to include

  • A clear description of the vulnerability and the affected component or endpoint
  • Reproduction steps or a proof-of-concept (no need to exploit, a demonstration is enough)
  • The potential impact as you see it
  • Your contact details so we can follow up

What to expect

  • Acknowledgement within 24 hours
  • Status update every 30 days while the issue is open
  • Resolution target of 90 days for confirmed critical and high findings
  • Credit in the fix notes if you would like it

Scope

In-scope: emberoncall.com and its subdomains, the Ember API and CLI, the dashboard and authentication flows. Out of scope: third-party services we do not control, social engineering, and physical security tests.

We ask that you do not access, modify or delete data that is not yours, and that you report privately before public disclosure. We will not pursue legal action against researchers acting in good faith under these guidelines.

Report a vulnerability

Questions about security or compliance?

Talk to us before you decide. We will walk you through data handling, deployment options and the controls your security team needs.