On-call handoff checklist for a security team

A good on-call handoff is a short, explicit conversation with a written note: what is open, what changed, what to watch and who has command. The one rule from Google's SRE incident chapter that matters most is that the outgoing person leaves only after the incoming person says yes.

Before the handoff

Prepare a written note, ideally in the same place every time. Keep it to one screen.

• Open incidents and their current state
• Anything suppressed, muted or deliberately ignored, with a reason and an expiry
• Changes shipped this week that could cause alerts
• Pending vendor or customer follow-ups
• Known noisy alerts and what you have already tried

During the handoff

The SRE chapter says to brief the incoming person first. If they are in another place, use phone or video, not only chat.

Then do the following.

1. Walk through open incidents, newest or most severe first.
2. State who is incident commander now and who will be after the handoff.
3. Ask directly: are you now in command?
4. Wait for a clear acknowledgment before dropping off the call.
5. Tell everyone working the incident who is leading.

After the handoff

The outgoing person stays reachable for a short, agreed window for questions. They should not have to, but a little overlap prevents small misunderstandings from becoming outages.

Common failure points

• Silent mutes. An alert muted for a quiet week that nobody remembered.
• Assumed knowledge. The note says "usual issue" and the new person has never seen it.
• Ambiguous command. Two people each believing the other has it.
• Handoffs in the middle of an action. Finish or explicitly transfer the action first.

Keep a living document

The same chapter calls the living incident document the commander's most important responsibility. It should be editable by several people, with the most important information at the top, and kept for the postmortem.

A template to copy

Keep a handoff note with fixed headings, so nothing depends on memory: open incidents, muted alerts and expiry dates, recent changes, watch items, contacts, and anything you wish you had been told. The last heading is surprisingly useful, because the outgoing person usually knows exactly what tripped them up.

Store each note where the next person will look, such as a pinned page or a dedicated channel, and keep older ones. After a few weeks the archive shows patterns: the same noisy alert, the same unanswered vendor ticket. Those patterns are your improvement backlog.

Quick check

Sources

• Google SRE book, Managing Incidents

Last reviewed: 19 October 2026.