Build a security emergency contact list your team can use fast
For non-technical teams who need a practical contact list before a security incident happens. You will leave with a single, shared document that names the right people, the right vendors, and the exact numbers, emails, and account details to use during an emergency.
TL;DR — Build one shared contact list that answers three things during an incident: who can approve decisions, who can change systems, and who must be notified. The most common fix is to stop relying on personal address books and instead create one shared document with named roles, direct phone numbers, backup contacts, and the account IDs your vendors will ask for. Reading time: ~5 min
Goal
When you are done, you will have a single shared emergency contact list that your team can open quickly during a security incident, with current names, roles, phone numbers, email addresses, backup contacts, vendor support details, and the account information needed to get help without delays.
Prerequisites
- Access to your shared document tool, such as Google Docs, Microsoft Word Online, Notion, or your company wiki
- Permission to view your company billing/admin pages for key services, or access to the person who has that permission
- A list of the systems you use: website host, domain/DNS provider (DNS = the service that points your domain name to the right system), email provider, identity provider (identity provider = the login system your staff use), payment provider, and any cloud platform
- The names of your internal decision-makers: owner, operations lead, legal/privacy contact, and technical lead or agency contact
- A phone capable of receiving test calls or SMS messages
- 30-60 minutes to collect and verify contact details
Steps
Step 1: Create one shared document in a place the right people can open
Use your normal shared document tool and create a document named exactly:
Security Emergency Contact List
If your tool supports sharing, give access to these people:
Owner or executive approver
Operations lead
Technical lead or software agency primary contact
Legal/privacy contact
Customer support lead
What you should see when this succeeds: the document exists, and at least two people besides you can open it without requesting access.
Step 2: Paste a ready-to-use template into the document
Copy and paste this section exactly into the document:
## Internal contacts
| Role | Primary person | Mobile phone | Work email | Backup person | Backup phone | Notes |
|---|---|---|---|---|---|---|
| Executive approver | | | | | | Can approve shutdowns, public statements, emergency spend |
| Operations lead | | | | | | Coordinates internal actions |
| Technical lead / agency | | | | | | Can change hosting, app, DNS, email settings |
| Legal / privacy | | | | | | Handles breach notification decisions |
| Customer support lead | | | | | | Prepares customer response |
## Vendor and platform contacts
| Service | Provider name | Support URL | Support phone | Support email | Account ID / customer number | Contract owner |
|---|---|---|---|---|---|---|
| Domain / DNS | | | | | | |
| Web hosting / cloud | | | | | | |
| Email provider | | | | | | |
| Identity provider / SSO | | | | | | |
| Payment provider | | | | | | |
| CDN / WAF | | | | | | |
| Backup provider | | | | | | |
## Critical account details
| System | Admin login URL | Account owner | MFA method | Billing contact | Notes |
|---|---|---|---|---|---|
| Domain / DNS | | | | | |
| Hosting / cloud | | | | | |
| Email | | | | | |
| Identity provider | | | | | |
## Escalation order
1. Executive approver
2. Operations lead
3. Technical lead / agency
4. Legal / privacy
5. Vendor support
## Last reviewed
Date:
Reviewed by:
Next review date:
What you should see when this succeeds: your document contains three tables and an escalation order section.
Step 3: Fill in internal people first
Open your HR directory, company contacts, or team chat profile pages and enter literal values for each person. Use direct mobile numbers, not only office lines.
Use this format in each phone cell:
+1 555 010 1234
Use this format in each email cell:
name@company.com
What you should see when this succeeds: every row in the "Internal contacts" table has both a primary person and a backup person.
Step 4: Collect vendor support details from each provider dashboard
For each service you use, open the provider dashboard and copy the support URL, support phone, support email, and account ID into the table. In your provider's dashboard, look for pages similar to these:
Billing → Account details
Settings → Account
Support → Contact support
Admin → Organization
Examples of the exact values to copy when present:
Support URL: https://provider.example/support
Support phone: +1 800 555 0199
Support email: support@provider.example
Account ID / customer number: acct_123456789 or Customer #456789
What you should see when this succeeds: every service row has at least a provider name, support URL, and account ID/customer number.
Step 5: Add admin login URLs and MFA details for critical systems
For your domain/DNS, hosting, email, and identity provider, add the exact admin login page and how multi-factor authentication works for that account.
Use values in this format:
Admin login URL: https://dash.example.com/login
MFA method: Authenticator app on Jane's company phone
Billing contact: billing@company.com
Do not paste passwords or recovery codes into this contact list.
What you should see when this succeeds: the "Critical account details" table shows where to log in and who owns each account.
Step 6: Add a simple call order so nobody guesses during an incident
Paste this flow into the document under "Escalation order":
View as text
[Incident Found]
|
| 1. call / message
v
[Operations Lead] ---- 2. approve? ----> [Executive Approver]
|
| 3. engage
v
[Technical Lead/Agency] ---- 4. contact ----> [Vendors]
|
| 5. notify
v
[Legal/Privacy]Then replace the role names in your table with real names if your team is small enough that role-only wording will slow people down.
What you should see when this succeeds: anyone reading the document can tell who to contact first, second, and third.
Step 7: Test the list with a 10-minute verification drill
Send this exact message by chat, email, or SMS to each primary contact and one backup:
This is a security emergency contact test. Please reply with: RECEIVED.
If your vendors offer phone support, call the listed number and confirm it reaches the right support line for your account type.
What you should see when this succeeds: your internal contacts reply "RECEIVED," and the vendor phone numbers or support URLs are valid.
⚠️ If you discover that only one person has access to a critical system such as DNS, hosting, or email admin, treat that as an operational risk. Add a backup admin before an incident happens, or your response may be delayed.
Step 8: Set a review date so the list stays usable
At the bottom of the document, fill these fields with literal values:
Date: 2026-10-30
Reviewed by: Your Name
Next review date: 2027-01-30
Then create a calendar reminder titled exactly:
Review Security Emergency Contact List
What you should see when this succeeds: the document has a next review date, and a calendar reminder exists.
Verify it works
Run these checks end to end:
- Open the document in a private/incognito browser window using an account that should have access.
- Confirm every row in "Internal contacts" has a primary and backup person.
- Confirm every row in "Vendor and platform contacts" has a support URL and account ID/customer number.
- Send the test message below to at least two people:
This is a security emergency contact test. Please reply with: RECEIVED.
- Open one admin login URL from the "Critical account details" table and confirm the page loads.
Expected result: the document opens for the right people, the listed contacts respond, support links work, and no critical row is blank.
Common pitfalls
Only listing names, not roles
Mistake: the list says "Jane" and "Mark" but not what they can approve or change.
Symptom: during an incident, people waste time asking who can authorize downtime, customer notices, or vendor calls.
Fix: add the exact role labels shown in the template, especially "Executive approver," "Operations lead," and "Technical lead / agency."
Using shared inboxes without a direct phone number
Mistake: the list only contains addresses like support@company.com or help@vendor.com.
Symptom: urgent messages sit unread, especially outside business hours.
Fix: add one direct mobile number for every internal primary contact and backup contact.
Forgetting the account ID or customer number
Mistake: the support URL is listed, but the account identifier is blank.
Symptom: vendor support asks for the account number before they can help, and the call stalls.
Fix: open the provider dashboard and copy the exact value from Billing, Account, or Organization pages into the table.
Storing passwords in the contact list
Mistake: someone pastes admin passwords, recovery codes, or secret keys into the document.
Symptom: the document becomes a security risk and may need to be rotated if over-shared.
Fix: remove secrets from the document and leave only the admin login URL, account owner, and MFA method.
No backup contact for DNS, hosting, or email
Mistake: one person is the only admin for a critical service.
Symptom: if that person is unavailable, you cannot change records, reset access, or contact support quickly.
Fix: add a backup person in the contact list and grant them admin access in the provider dashboard.
Never reviewing the list after staff or vendor changes
Mistake: the document is created once and forgotten.
Symptom: phone numbers bounce, former staff are still listed, or support links point to old systems.
Fix: set a 90-day calendar reminder titled Review Security Emergency Contact List and update the "Last reviewed" section each time.
This article was written by an AI system and published pending human review. Verify anything you intend to act on.
Have a project in mind?
Get an instant AI price estimate for it, or talk directly to our team.
One email a month on what we learn building with AI