Telling People
18 items · source
Prepared in advance
- Verify a status page exists, or that not having one is a deliberate decision.
- Verify the status page is not hosted on the infrastructure it reports on.
- Verify you can update it from a phone.
- Verify templates exist for the common cases: degraded, down, resolved, security incident, data incident.
- Verify a breach notification template exists and has been read by whoever would send it.
- Verify you have a way to email all affected users that does not depend on the application being up.
- Verify the list of who else must be told is written down — business customers with contractual terms, an insurer, a processor, an authority.
During
- Verify the first update goes out before customers ask, even when it says only that you are investigating.
- Verify updates continue on a stated cadence, and that the cadence is kept even when there is nothing new.
- Verify you say what is affected and what is not, so unaffected users stop worrying.
- Verify you do not speculate about cause or scope before you know.
- Verify support has the same information as the status page, so customers do not get two stories.
- Verify one person owns external communication, so two versions do not go out.
After
- Verify a resolution notice goes out, and that it is not the last anyone hears.
- Verify a public write-up follows for anything significant, with what happened, what you changed, and no blame directed at a named person.
- Verify affected users are told individually where they were individually affected.
- Verify what you promised in the write-up is tracked to completion — see
08-learning-and-drills.md. - Verify a security incident write-up is reviewed before publication by someone thinking about liability as well as honesty.
# Telling People ## Prepared in advance * [ ] Verify a status page exists, or that not having one is a deliberate decision. * [ ] Verify the status page is not hosted on the infrastructure it reports on. * [ ] Verify you can update it from a phone. * [ ] Verify templates exist for the common cases: degraded, down, resolved, security incident, data incident. * [ ] Verify a breach notification template exists and has been read by whoever would send it. * [ ] Verify you have a way to email all affected users that does not depend on the application being up. * [ ] Verify the list of who else must be told is written down — business customers with contractual terms, an insurer, a processor, an authority. ## During * [ ] Verify the first update goes out before customers ask, even when it says only that you are investigating. * [ ] Verify updates continue on a stated cadence, and that the cadence is kept even when there is nothing new. * [ ] Verify you say what is affected and what is not, so unaffected users stop worrying. * [ ] Verify you do not speculate about cause or scope before you know. * [ ] Verify support has the same information as the status page, so customers do not get two stories. * [ ] Verify one person owns external communication, so two versions do not go out. ## After * [ ] Verify a resolution notice goes out, and that it is not the last anyone hears. * [ ] Verify a public write-up follows for anything significant, with what happened, what you changed, and no blame directed at a named person. * [ ] Verify affected users are told individually where they were individually affected. * [ ] Verify what you promised in the write-up is tracked to completion — see [`08-learning-and-drills.md`](08-learning-and-drills.md). * [ ] Verify a security incident write-up is reviewed before publication by someone thinking about liability as well as honesty. 18 items · https://github.com/FarzamHabibi/pre-production-checklist · CC BY 4.0