Emmi Incident Response Plan¶
| Version | 1.0 |
| Date | 2026-08-24 |
| Owner | Engineering |
| Review cadence | Annually, and after any SEV-1 or SEV-2 incident |
| Security contact | security@emmi.io |
1. Purpose and scope¶
This plan defines how Emmi detects, triages, responds to, and learns from security incidents. This plan commits to clear, published business-hours response SLAs and a simple, repeatable process.
In scope:
- Emmi's products and services, including the Snowflake Marketplace native app ("Climate Risk and Emissions by Emmi"), Emmi's data shares and Emmi's APIs and web applications.
- Emmi's cloud infrastructure (Snowflake, AWS, CI/CD pipelines, source-code repositories).
- Corporate systems (email, identity/SSO, collaboration tools such as Atlassian and Slack).
A security incident is any event that compromises, or credibly threatens to compromise, the confidentiality, integrity, or availability of Emmi systems or the data we process, including vulnerabilities discovered in our shipped software.
2. Reporting an incident¶
All reports, external and internal, go to security@emmi.io. This alias is monitored by the engineering team during business hours (AEST).
External reporters (customers, Snowflake consumers, security researchers) should include: what was observed, when, which product or system was affected, and any reproduction steps. We ask reporters not to publicly disclose an issue until we have had a reasonable opportunity to remediate it.
What reporters can expect:
- An acknowledgement within the SLA for the applicable severity (see Section 4); for anything that looks serious, within 4 business hours.
- A named point of contact (the Incident Commander) for the duration of the incident.
- Status updates at a reasonable cadence until the issue is resolved.
- Confirmation when the issue is remediated. We do not currently operate a paid bug-bounty program, but we credit good-faith researchers on request.
3. Severity levels¶
Severity is assigned at triage by the Incident Commander and may be revised as facts emerge.
| Level | Definition | Snowflake native app example |
|---|---|---|
| SEV-1 (Critical) | Confirmed or strongly suspected exposure of customer/consumer data; active exploitation of any Emmi system; complete loss of a production service; compromise of credentials or signing/deploy keys. | A vulnerability in EMMI_EMISSIONS_APP that could allow consumer data to be exposed outside the consumer's Snowflake account, or to another consumer. |
| SEV-2 (High) | A serious vulnerability with no evidence of exploitation; significant degradation of a production service; a security control failure that materially raises risk but has not been abused. | A high-severity CVE identified in the app's container image or a pinned dependency, with no known exploitation and no data exposure. |
| SEV-3 (Low) | Low-risk vulnerabilities, hardening gaps, or minor issues with limited practical impact; single-user or cosmetic issues with a security dimension. | A low-risk vulnerability in a dependency flagged by automated scanning (for example Dependabot or Trivy) that is not reachable in the app's execution path. |
4. Published response SLAs¶
SLAs are measured in business hours/days: Monday to Friday, 09:00 to 17:00 Australia/Sydney (AEST/AEDT), excluding VIC public holidays. In practice the team frequently responds faster, including outside these hours for SEV-1, but the commitments below are what we publish.
| SEV-1 (Critical) | SEV-2 (High) | SEV-3 (Low) | |
|---|---|---|---|
| Acknowledgement of report | Within 4 business hours | Within 1 business day | Within 2 business days |
| Triage and severity assessment | Within 8 business hours | Within 2 business days | Within 5 business days |
| Status-update cadence | At least once per business day | At least twice per week | On material change; at least fortnightly until closed |
| Mitigation / containment target | ASAP; within 48 hours of confirmation | Within 5 business days | Not usually required |
| Remediation target | Within 10 business days (permanent fix) | Within 30 days | Within 90 days, or next scheduled release |
Notes:
- Mitigation means the exposure is stopped (for example listing pulled, service disabled, credential revoked, access blocked) even if the underlying fix is not yet shipped.
- If a remediation target cannot be met (for example a fix depends on an upstream vendor), the Incident Commander records the reason, applies compensating mitigations, and communicates a revised date at the normal update cadence.
5. Response process¶
- Detect / report. Incident arrives via security@emmi.io, automated alerting (CI security scans, Dependabot, Snowflake account monitoring), or team observation.
- Triage and severity assignment. An Incident Commander is assigned; they confirm the facts, assign a severity per Section 3, and start the SLA clock for updates and mitigation.
- Contain. Stop ongoing harm: revoke credentials/keys, disable affected services or endpoints, pull or restrict the marketplace listing, block access paths. Preserve logs and evidence before destructive changes.
- Eradicate / remediate. Identify and fix the root cause: patch the code or dependency, rebuild and redeploy images, rotate any secrets that could have been exposed, verify the fix with tests and scans.
- Recover. Restore normal service, confirm systems are clean and behaving normally, monitor for recurrence, and close out communications with affected parties and reporters.
- Post-incident review. For every SEV-1 and SEV-2, a written review is completed within 5 business days of resolution, covering timeline, root cause, what worked, what didn't, and concrete follow-up actions (each with an owner). Follow-ups are tracked to completion in the engineering backlog. SEV-3 reviews are optional and lightweight.
6. Incidents affecting the Snowflake marketplace app¶
For incidents affecting "Climate Risk and Emissions by Emmi" on the Snowflake Marketplace, the following applies in addition to the general process:
- Consumer and Snowflake notification. If an incident affects, or may affect, app consumers, we notify affected consumers and Snowflake (via our Snowflake partner/marketplace contacts) without undue delay once the impact is understood. For SEV-1 this happens as part of initial containment, not after remediation.
- Ability to pull or restrict the listing. Emmi can remove or restrict the marketplace listing, and can stop distribution of an affected app version, as an immediate containment step.
- Patched releases follow the standard release-channel flow. A patched app version is deployed to the QA release channel first, verified there, and then promoted to the DEFAULT channel, where it passes through Snowflake's own automated security review before reaching consumers. We do not bypass this flow for security fixes; where speed is critical, containment (pulling/restricting the affected version) covers the gap while the patch clears review.
- Architecture context. The app runs entirely within each consumer's Snowflake account, has no external network egress, and consumer data never leaves the consumer's account. This materially limits the blast radius of most incident classes: many incidents reduce to "patch the app version" rather than "contain a data exfiltration".
7. Roles¶
| Role | Responsibility |
|---|---|
| Incident Commander (IC) | Assigned per incident from the engineering team. Owns triage, severity assignment, coordination of the response, the tracking ticket, and the post-incident review. |
| Communications Lead | Owns updates to reporters, affected customers/consumers, Snowflake, and internal stakeholders. In a small team this is usually the same person as the IC; for SEV-1 it should be a second person where headcount allows. |
| Leadership | Escalated to immediately for every SEV-1, and for any incident involving customer notification, legal/regulatory questions, or public communications. Leadership approves external statements and any decision to pull the marketplace listing. |
All engineers are expected to know this plan exists, know the reporting address, and be prepared to act as IC.
8. Document control¶
- Owner: Engineering.
- Location: This page is the canonical, published version of the plan.
- Review: Reviewed at least annually, and after any SEV-1 or SEV-2 incident (as part of the post-incident review).
- History: v1.0, 2026-08-24: initial published version.