Incident response
Internal workflow we use to classify, respond to, and follow up on security and availability incidents. This is an outline of our process, not a guarantee of specific timelines or outcomes.
Last updated: March 2025
Scope
- Security incidents: Suspected or confirmed unauthorized access, data breach, abuse, or vulnerability affecting customer data or system integrity.
- Availability incidents: Outage or severe degradation of the service affecting customers.
Classification
| Severity | Description | Example |
|---|---|---|
| Critical | Active breach or full service outage | Confirmed unauthorized access to customer data; platform unavailable to all users |
| High | Significant security issue or major partial outage | Vulnerability under active exploitation; major feature unavailable |
| Medium | Isolated finding or limited degradation | Single-tenant issue; elevated error rates in one region |
| Low | Minor issue, no or limited customer impact | Non-sensitive config exposure; brief connectivity blip |
Internal response workflow
The following steps are used internally. Response times and ownership depend on team availability and severity.
- Detection and reporting — Incidents are reported via support, monitoring alerts, or responsible disclosure. All reports are logged and triaged.
- Triage — Severity is assigned based on impact and scope. Critical and High incidents are prioritized; an owner is assigned.
- Containment — Actions to limit impact (e.g. revoke access, disable a feature, failover) are taken as appropriate. Evidence is preserved where relevant for later analysis.
- Remediation — Root cause is addressed and a fix is deployed. Deployment is verified.
- Recovery — Service is restored; data integrity and access are confirmed where applicable.
- Post-incident — Internal post-mortem is conducted. Customer communication is sent when required by impact or contract. Follow-up actions are tracked to completion.
Escalation
Critical / High: The triage owner escalates immediately to the designated incident lead (on-call or engineering lead). If the incident lead is unavailable, escalate to the next defined backup. Critical incidents are escalated to leadership when customer data or full outage is confirmed. All escalations are logged with timestamp and reason.
Medium / Low: Handled within the team; escalate to incident lead if impact grows, if a customer is blocked, or if the fix requires cross-team coordination. Document escalation path in runbooks so on-call knows who to contact.
Customer communication
Critical / High: Affected customers are notified as soon as practicable after containment, with a brief description of the incident and impact. Updates are provided until the incident is resolved. A summary or post-incident report may be offered where appropriate.
Medium / Low: Communicated via status page or support as needed. Formal notification is used when customer data or contractual commitments (e.g. SLA) are affected.
Responsible disclosure
Security researchers can report vulnerabilities via supportwith the subject line "Security – Responsible disclosure". Please include a description, steps to reproduce, and impact. We acknowledge reports and respond based on severity. We ask for reasonable time to address issues before public disclosure and do not pursue legal action against researchers who report in good faith.