Incident Response
Updated April 16, 2021
note
Incident response at Mozilla is a bit of a moving target at the time of this writing. We expect to use whatever system becomes a broad standard, but in the mean time we'll follow the process below.
- Read about Firefox Incident Response for some background. We follow that model of incident command and classification of incidents
- Use this template for the response. Fill in what you can, delete sections that are not relevant.
- The normal work of responding to the incident follow the documentation in the first bullet point.
- Once the incident is resolved, have a post-mortem or root cause analysis(RCA) meeting to discuss what happened and how to avoid it in the future. Take notes in the incident document on the meeting and future action items.
- Add your incident to this list.
Generally that's where the documented process ends. This can lead to a failure to follow up on action items that come out of the incident. To avoid that, Mozilla accounts extends the process:
- File an epic in Jira with either a descriptive title or "Incident %DATE%".
0. Add a description linking to the incident document
0. Add the
incident
label - File tasks under the epic and assign to the appropriate people. Understand these tasks will sync to Github and be publicly viewable. If there are security concerns, file confidential bugs in bugzilla.
- It's worth recognizing the natural tension between good and perfect and understanding there will be diminishing returns here. If it would take six months of work to avoid a low severity incident it's not worth filing that action item. Document the option, but stay realistic when filing action items.
- Triage the items as part of the regular triage.