The first hour of a serious incident is often lost not to the attacker but to finding the right people: the on-call engineer who does not answer, the CISO whose number is in the compromised address book, the retainer hotline nobody can locate at 2 a.m. Incident response plans usually name roles but rarely say who calls whom, in what order, how long to wait before moving on, or what to do when email and chat are in the attacker's hands. This template gives [Organisation] a ready-to-fill contact directory, an out-of-hours rota, a call tree with escalation timers, a verification step for every call and a log of who was reached. It is written for incident managers, SOC leads, IT operations and business continuity owners. It complements the Incident Response Plan Template, which sets severity levels, the escalation matrix and regulatory clocks; this page makes those decisions reachable.
How to use this template
- Fill it, then take it offline: replace every [bracketed] field. Keep the live copy in a system that does not depend on your corporate identity provider, plus a printed copy in each response kit and an encrypted copy on responders' personal phones, so it survives a ransomware or tenant compromise.
- Two people and two methods for every role: the UK NCSC advises always considering the risk of people being unavailable, with at least two contact methods and two or more people for each contact. Every row below has a primary, a deputy and at least one non-corporate method.
- Timers are part of the tree: each call has a wait time. If nobody answers within it, the caller moves to the next person without waiting for permission.
- Verify before you trust: during an incident, attackers may impersonate executives or responders. Every call in the tree includes a verification step (section 3.3).
- Section names follow the incident lifecycle: sections 1 to 8 match the phases of your incident response plan, so each phase shows who must be reached at that point.
- Review on a schedule: test the tree quarterly and update it on every joiner, mover and leaver in a listed role. Owner: [Incident Response Manager].
1. Scope and triggers
1.1 This call tree is activated when any of the following occurs: an incident is declared at [SEV1] or [SEV2] under the incident response plan; an alert or report meets the criteria in the Incident Severity Classification Matrix Template outside business hours; a supplier, regulator, law enforcement agency or researcher notifies [Organisation] of a suspected compromise; or a business continuity or crisis plan is invoked for a cyber cause.
1.2 Any member of staff who believes a serious incident is under way may start the tree at Level 1 by calling the [Security Operations on-call number]. Nobody is criticised for starting it in good faith.
1.3 Activation record (completed by the first caller):
| Field | Entry |
|---|---|
| Incident reference | [INC-YYYY-NNN] |
| Tree started by and time (UTC) | [Name], [YYYY-MM-DD hh:mm UTC] |
| Trigger | [What was seen or reported, by whom] |
| Initial severity | [SEV level and criteria met] |
| Corporate channels trusted? | [Yes] / [No: use out-of-band channels in section 4] |
2. Roles and contacts
2.1 Contact directory. Personal mobile numbers are held with the consent of the individual and used only for incident and continuity purposes.
| Role | Primary (name, mobile, alternative method) | Deputy (name, mobile, alternative method) | Authority |
|---|---|---|---|
| Security on-call (Level 1) | [Rota, see 2.2] | [Secondary on-call] | Triage, start tree, initial containment per playbook |
| Incident Manager or Commander | [ ] | [ ] | Declare incident, set severity, run the bridge. See the Incident Commander Role Guide |
| CISO | [ ] | [ ] | Approve major containment, brief executives |
| IT and cloud operations lead | [ ] | [ ] | Isolate systems, change network and cloud controls |
| Identity lead | [ ] | [ ] | Disable accounts, revoke sessions, tokens and keys |
| Executive decision maker | [CEO or COO] | [Named alternate] | Take critical services offline, approve external statements, ransom decisions |
| Legal counsel | [ ] | [External firm, 24/7 line] | Privilege, notifications, law enforcement contact |
| Data Protection Officer | [ ] | [ ] | Personal data breach assessment and regulator liaison |
| Communications | [ ] | [ ] | Staff, customer and media messages |
| HR | [ ] | [ ] | Insider cases, staff welfare, disciplinary steps |
| Business service owners | [Per critical service] | [ ] | Accept downtime, run manual workarounds |
| Scribe | [ ] | [ ] | Keep the decision log |
2.2 Out-of-hours rota. The NCSC advises documenting escalation contacts including out-of-hours details and how quickly escalation must happen. Keep the rota in the paging tool and in this table, with the handover time.
| Week starting | Primary security on-call | Secondary on-call | Duty Incident Manager | Duty executive |
|---|---|---|---|---|
| [YYYY-MM-DD 09:00 local] | [ ] | [ ] | [ ] | [ ] |
| [ ] | [ ] | [ ] | [ ] | [ ] |
2.3 External contacts (verify numbers from contracts or official sites, never from an email received during the incident):
| Party | 24/7 route | Reference needed when calling | Who may call |
|---|---|---|---|
| Incident response retainer | [Hotline] | [Contract or customer ID] | Incident Manager, CISO |
| Cyber insurer breach line | [Hotline] | [Policy number] | CISO, Legal |
| Cloud and SaaS providers | [Priority support route] | [Tenant or account IDs, support plan] | IT and cloud lead |
| Managed security provider | [Hotline] | [Customer ID] | Security on-call |
| Law enforcement and national CERT | [Reporting route] | [Organisation details] | Legal, CISO |
| Regulators | [Portal or line per regulator] | [Registration numbers] | DPO, Legal |
| Critical suppliers | [Security contact] | [Contract ID] | Service owner, Incident Manager |
3. Detection and triage
3.1 The call tree. Each level is started by the person named in the "Caller" column, in parallel where shown.
| Level | Caller | Calls | Wait before moving on | If no answer |
|---|---|---|---|---|
| 1 | Alert, staff report or third party | Primary security on-call (pager) | [5] minutes to acknowledge | Page secondary on-call; after [10] minutes call Duty Incident Manager |
| 2 | Security on-call | Duty Incident Manager | [10] minutes | Call Incident Manager deputy, then CISO |
| 3 (SEV1 and SEV2) | Incident Manager | CISO, IT and cloud lead, identity lead (in parallel) | [10] minutes each | Call each deputy; record gaps |
| 4 (SEV1) | CISO | Duty executive, Legal, DPO (in parallel) | [15] minutes | Call each deputy; for Legal, call external counsel line |
| 5 (as needed) | Incident Manager or Legal | Retainer, insurer, cloud providers, communications, HR, service owners | [15] minutes | Use alternative route in 2.3 |
3.2 Timers are a ceiling. The PagerDuty open incident response documentation, for example, recommends a five-minute escalation timeout on the reasoning that someone who cannot acknowledge in that time probably cannot respond, and keeps a primary and a backup on call at all times. Set your own values in the brackets and configure the paging tool to match.
3.3 Verify every call. Before acting on instructions or sharing details, the person called confirms the caller's identity by calling back a number from this directory (never a number given on the call), or by a challenge phrase agreed in advance and held only in the offline copy. Face or voice recognition is not proof: in the Arup deepfake fraud a finance worker made 15 transfers after a video call with a deepfaked CFO, and it was only uncovered when the worker contacted head office directly. See the Deepfake-Resistant Identity Verification Guide.
3.4 What to say on the first call: who you are; incident reference; what was seen and when (UTC); current severity; whether corporate channels are trusted; where the bridge is; what you need from them.
4. Containment
4.1 Decision authority must be reachable. The NCSC advises that escalation must reach people with the authority to make critical decisions, such as taking a critical system offline, that deputies are named, and that you identify situations where the technical team can act without waiting for approval. Record those pre-approved actions here:
| Pre-approved action | Who may take it without further approval | Who must be told, and within |
|---|---|---|
| Isolate an endpoint or server via EDR | Security on-call | Incident Manager, [30] minutes |
| Disable a user or service account, revoke sessions and tokens | Security on-call, identity lead | Account owner and Incident Manager, [30] minutes |
| Block an IP range, domain or OAuth application | Security on-call | Incident Manager, [60] minutes |
| Take an internet-facing service offline | Incident Manager with CISO | Duty executive and service owner, immediately |
| Shut down a production site or core platform | Duty executive | Board chair, Legal, immediately |
4.2 Out-of-band channels. If corporate email, chat or telephony may be monitored or unavailable, switch to the channels below. The NCSC advises considering secure or alternative communications and planning for network, email or phone outages. See the Out-of-Band Communications Plan Template.
- Bridge: [Out-of-band conference number and PIN], always available, not provisioned through the corporate identity provider.
- Messaging: [Pre-created out-of-band group], membership limited to roles in section 2.
- Fallback: mobile voice calls using the directory; in-person meeting point [location].
5. Eradication
5.1 During eradication, specialist contacts are often needed outside business hours: the identity provider's support, a hardware vendor, a domain registrar. Before an eradication window starts, the Incident Manager confirms that each required contact in 2.3 has been reached and is available for the window, and records it in the call log (section 8).
5.2 If a credential reset or key rotation will lock out people in the call tree (for example a tenant-wide password reset), notify those contacts through the out-of-band channel first and give them the recovery route.
6. Recovery
6.1 Service owners in section 2 are called before each restoration step so they can test and accept the service. Calls follow the same verification and logging rules.
6.2 For incidents longer than one shift, the Incident Manager sets a handover schedule. At each handover the outgoing role holder briefs the incoming one on open actions and who has and has not been reached, and the scribe records the change of role holder.
7. Communication and notification
7.1 Notification decisions are made by the roles in section 2, not by whoever answers the phone. Calls to regulators, law enforcement, insurers and customers are made only by the "Who may call" role in 2.3. Regulatory deadlines and their triggers are set in the incident response plan; record the awareness time in the call log because many clocks start from it.
7.2 Staff cascade. For incidents that affect many staff (for example loss of email), team leaders cascade a short, approved message to their teams by phone or text. Each leader confirms completion to [Communications] within [60] minutes. See the Incident Communication Plan Template for message content.
8. Post-incident review
8.1 Call log. Every call attempt is recorded by the caller or the scribe:
| Time (UTC) | Caller | Called (name, role) | Method | Outcome | Verified by | Time to reach |
|---|---|---|---|---|---|---|
| [ ] | [ ] | [ ] | [Pager, mobile, out-of-band app] | [Reached / no answer / wrong number] | [Callback / challenge phrase] | [minutes] |
8.2 After every activation and every test, review: who could not be reached and why; numbers that were wrong; time from trigger to Incident Manager, to CISO and to decision maker; whether pre-approved actions were used; whether anyone acted on an unverified call. Feed the findings into the post-incident review and update the directory within [5] working days.
Implementation guidance
- Populate from HR and contracts, then confirm with each person: ask every listed person to confirm their numbers and consent, and to save the bridge number and security on-call number in their phone.
- Configure the paging tool to match: escalation policies, timers and the rota in 2.2 should be identical in the tool and this document. Test that pages reach phones on silent or do-not-disturb.
- Distribute offline copies: printed and encrypted copies to every role holder, version-numbered, with old copies destroyed on update.
- Test quarterly: run an unannounced out-of-hours call tree test (contact only, no technical work) and record time to reach each level. When testing generates pages, follow your paging tool's override process so the on-call knows it is a test.
- Exercise it in scenarios: include a "corporate email compromised" condition and an impersonation inject in tabletop exercises. See the Tabletop Exercise Guide.
- Measure: track time to acknowledge at Level 1, time to reach a decision maker, share of contacts reached on the first attempt, and directory accuracy (wrong or stale entries found per test). Aim for every SEV1 decision maker reachable within [30] minutes.
- Keep it current: link the directory to joiner, mover and leaver processes for every role listed, and re-verify after any reorganisation.
Framework fit: the template supports NIST SP 800-53 Rev. 5 IR-8 Incident Response Plan, IR-4 Incident Handling, IR-6 Incident Reporting, IR-7 Incident Response Assistance, IR-3 Incident Response Testing, IR-2 Incident Response Training and CP-2 Contingency Plan; NIST CSF 2.0 GV.RR-02, ID.IM-04, RS.MA-01, RS.CO-02 and RS.CO-03; and ISO/IEC 27001:2022 Annex A 5.24 Information security incident management planning and preparation and 5.26 Response to information security incidents.
Standards and references
- NIST: SP 800-61 Rev. 3 Incident Response Recommendations and Considerations
- NIST: SP 800-34 Rev. 1 Contingency Planning Guide for Federal Information Systems
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NCSC: Cyber incident response processes
- NCSC: Incident management collection
- PagerDuty: Incident Response Documentation, Being On-Call
Related NHI Mgmt Group resources: Incident Response Plan Template · Out-of-Band Communications Plan Template · Incident Commander Role Guide · Crisis Management Guide