A contact plan is a one page document naming who to reach, in what order, over which channel, when your usual chat and email are not available. Keep a copy outside those systems, test it twice a year with a short call out, and update it whenever people change roles.
Why you need one
Most teams coordinate through one chat tool and one email system. Both usually depend on the same identity provider and the same internet connection. Meta's account of its 2021 outage notes that its own internal tools were affected by the loss of DNS and that it had to send people onsite. You do not need that scale to learn the lesson: coordination tools are dependencies too, and they can fail together with the thing you are trying to fix.
What goes on the page
| Section | Contents |
|---|---|
| Roles | Incident lead, technical lead, communications owner, scribe, each with a named backup |
| Contact methods | Mobile phone numbers, personal email if policy allows, a messaging app on a separate provider |
| Order | Who calls whom first, and how long to wait before the next attempt |
| Meeting point | A video bridge from a provider separate from your main stack, or a phone conference line |
| Customer channel | Where updates go if your status page is also affected |
| Escalation | Who to call if the lead does not answer in a stated number of minutes |
| Last tested | Date and result |
Respect privacy. Collect personal numbers voluntarily, store them with access control, and explain how they will be used. Check your employment and privacy rules with your own advisers.
Build it in four steps
- Choose the roles first, then fill names. A role with a backup survives vacations and departures.
- Add an alternate meeting channel hosted separately from your main identity provider. Test that people can join without their usual single sign-on.
- Print or store the page where it opens without your corporate login, such as encrypted files held by several people, and make sure nobody depends on a single copy.
- Run a ten minute drill. At an unannounced time, trigger the plan and measure how long it takes to reach every role.
Customers and the public
If your status page is hosted on your own infrastructure, it may fail along with everything else. Our post on hosting your status page away from your own infrastructure covers that. Prepare short template messages in advance, including the first update, and keep them with the plan. Our post on what to say to customers during an outage can help with wording.
Keep it small and current
A long plan will not be read. One page, roles and numbers, tested. Put an owner and a review date on it, and update it when onboarding or offboarding anyone who appears on it. Stale phone numbers are the usual reason a drill fails.
A worked example: a drill that found three problems
This example is hypothetical. A team runs its first unannounced drill. At a set time, the incident lead tries to reach the five roles on the plan using just the page.
| Role | Method on the page | Result | Time to reach |
|---|---|---|---|
| Technical lead | Mobile phone | Reached | 2 minutes |
| Communications owner | Mobile phone | Number out of date | Not reached |
| Scribe | Messaging app on a separate provider | Reached | 4 minutes |
| Security owner | Mobile phone | Voicemail; backup reached | 9 minutes |
| Customer support lead | Personal email | Read after 40 minutes | 40 minutes |
The drill found three problems: a stale number, a person with no backup who was unreachable, and a channel that is too slow for urgent contact. Each fix is small: update the number, name a backup, and add a phone call as the first method for urgent roles. A drill of ten minutes produced a better plan than a month of editing the document in the abstract.
Step by step: the quarterly ritual
- Pick an unannounced time, ideally within working hours at first. Inform one executive so no one is surprised.
- The incident lead opens just the plan and starts a clock.
- Contact each role by the first listed method, then the next after a stated wait.
- Record who was reached, how and how long it took.
- Join an alternate call bridge and confirm that people can enter without their usual sign in.
- Debrief for fifteen minutes and fix what failed.
- Update the "last tested" line and share the new copy.
Handling privacy and people
Personal phone numbers are personal data. Ask for them voluntarily, explain the purpose, limit who can see the page and delete numbers when people leave. Avoid expecting people to use personal accounts for work content. Use the alternate channel for coordination, and keep sensitive details out of it. Check policy with your own advisers where employment rules vary.
Think about time zones and rest. A plan that depends on one person for every incident burns people out. Add an on call schedule that spreads the load, and write down how handover works. Our post on oncall rotation design covers rotation options.
What to include for customers and partners
Add a short section on external contacts: your key vendors' emergency numbers, your insurer or advisers if you have them, and the people at major customers who should hear from you first. Keep it short. The point is to know whom to call without searching.
Template messages
Prepare three short messages in advance and store them with the plan:
| Message | Purpose | Key content |
|---|---|---|
| First notice | Tell people you know about the problem | What is affected, that you are investigating, when the next update comes |
| Update | Show progress | What you know, what you do not, next update time |
| Resolution | Close the loop | What happened in plain words, what you changed, how to reach you |
Avoid guessing about cause in the first notice. Our post on incident or outage wording helps with the words.
Try it yourself
Open the zero day watch demo and look at how an alert reaches the right place with context. Compare that with your own contact plan: how would the right person learn of a problem if chat were unavailable?
Click through it at your own pace, or open it full screen.
Quick check
Is a group chat on a personal app acceptable?
That depends on your policy and the data involved. Many teams use a separate provider for coordination alone, and keep sensitive details out of it.
How often should we test the plan?
Twice a year is a reasonable start, plus after any change to the on call team.
Who should own the plan?
Name one owner, often the head of engineering or operations, and a backup. The owner is accountable for the quarterly test and for updating the page after any change.
Sources
Last reviewed: 19 October 2026.
