Most SOC mistakes at shift change are not detection failures: a temporary firewall block nobody removes, a regulatory clock nobody is watching, or a half-contained host that the night shift assumes the day shift finished. This template gives a security operations centre a standard handover procedure and record for every shift change, structured around the incident response lifecycle so that each open item carries its phase, owner and next action. It draws on the UK Health and Safety Executive's guidance on safety-critical shift handover, the NCSC's guidance on building a SOC and NIST SP 800-61 Rev. 3. It is written for SOC shift leads, analysts and incident managers, in-house or with a managed provider. Adapt the bracketed text before adoption.
How to use this template
- Replace text in square brackets, such as [Organisation], [Case Tool] and [Shift Lead], with your own names. "Must" is mandatory; "should" is recommended.
- Sections 3 to 7 are the handover record itself: one block per lifecycle phase, filled in by the outgoing shift and read back by the incoming shift. Keep the record in [Case Tool] or a shared, access-controlled page linked from every case, not in chat.
- Decision points are marked D1 to D4.
- Rota design, coverage models and staffing levels are covered in the SOC Staffing and Shift Models Guide; this template covers only the handover itself.
1. Scope and triggers
1.1 This procedure applies to every change of responsibility for the [Organisation] SOC queue: shift change, hand-off between follow-the-sun sites, transfer to or from an on-call analyst, and transfer between [Organisation] and its managed security provider.
1.2 HSE describes effective handover as three steps: the outgoing staff prepare beforehand, both sides exchange task-relevant information, and the incoming staff cross-check it as they take over responsibility. HSE also advises that handover is face to face, two-way, both verbal and written, and given the time it needs. [Organisation] adopts all of these.
| Handover type | When | Minimum format |
|---|---|---|
| Standard | Every scheduled shift change | Written record plus [10] minute verbal read-through |
| Extended | Any open incident at severity [High] or above, or a regulatory clock running | Written record plus [30] minute call including the [Incident Manager] |
| Cross-site or provider | Follow-the-sun or MSSP hand-off | Written record in the shared [Case Tool], video call, named acceptor on both sides |
| On-call | Out-of-hours transfer to a single analyst | Written record plus phone confirmation that the on-call analyst has read it |
D1: Hold the outgoing shift? If a Critical incident is mid-containment at handover time, the [Shift Lead] decides whether the outgoing analyst stays until a defined checkpoint. HSE identifies higher-risk handovers as a specific risk to plan for; an active containment is one.
2. Roles and contacts
| Role | Responsibility at handover | Named contact |
|---|---|---|
| Outgoing [Shift Lead] | Prepares and signs the record, leads the read-through | [Rota] |
| Incoming [Shift Lead] | Cross-checks, asks questions, accepts responsibility and signs | [Rota] |
| Case owners | Update each open case before the record is compiled | [Rota] |
| [Incident Manager] on duty | Joins extended handovers; owns decisions that span shifts | [Rota] |
| [SOC Manager] | Reviews handover quality weekly (section 8) | [Name] |
| Provider contact | Accepts or hands over items to [Organisation] where an MSSP is involved | [Name, portal] |
2.1 The record must list the on-call escalation contacts for the coming shift: [Incident Manager], [Identity Team], [Network Owner], [Cloud Owner], [Legal] and the provider's duty contact. The NCSC advises keeping escalation paths clear and contact records up to date. Use the Incident Response Contact and Call Tree Template.
3. Detection and triage
3.1 The outgoing shift records the state of the queue and of detection itself.
| Field | What to write |
|---|---|
| Queue state | Untriaged alerts by severity; oldest untriaged alert age; any alert breaching its [SLA] |
| Cases in triage | Case ID, one-line summary, current hypothesis, next step, owner after handover |
| Watchlist | Users, hosts, IPs, domains, service accounts or API keys under heightened watch, with reason, start date and end date |
| Detection health | Log sources silent or delayed, failed connectors, EDR coverage gaps, rules disabled or in test, with ticket numbers |
| Tuning in flight | Suppressions or exclusions added this shift, with expiry and approver |
| Threat context | New advisories, KEV additions or intelligence relevant to [Organisation] that the next shift should hunt for |
3.2 Every suppression and watchlist entry must carry an expiry date. Temporary changes without expiry become permanent blind spots. See the Alert Triage Guide.
3.3 Non-human identities need explicit mention: if a service account, token or API key is on watch because of unusual use, name its owner and the action expected if it fires again.
4. Containment
4.1 List every containment action in force, because these are the items most likely to be forgotten or undone.
| Field | What to write |
|---|---|
| Action | For example: host isolated in EDR, account disabled, sessions revoked, IP blocked at firewall, domain sinkholed, mailbox rule removed, key deactivated |
| Case and approver | Case ID and who approved the action |
| Applied at | Date, time and time zone |
| Review or expiry | When it must be reviewed or lifted, and by whom |
| Business impact | Users or services affected, and who to tell if it is lifted |
| Pending containment | Actions agreed but not yet done, with blocker (waiting for change approval, waiting for owner) |
D2: Lift or extend? Containment actions expiring in the coming shift must have an explicit decision recorded before handover; the incoming [Shift Lead] does not lift an action without the case owner or [Incident Manager].
5. Eradication
- Open eradication tasks: persistence still to remove, reimages scheduled, credentials and secrets still to rotate (including service account passwords, API keys and certificates), with the owning team and ticket.
- Hunts in progress: query or hunt ID, scope covered so far, what remains. Record the exact queries so the next shift can rerun them.
- Evidence in custody: images, memory captures and exported logs collected this shift, where they are stored and their hashes. Chain of custody passes with the record; see the Chain of Custody Form Template.
6. Recovery
- Systems returning to service: which, when, and any extra monitoring required for [30] days.
- Accounts re-enabled: which accounts and keys were restored and what to watch for.
- Open changes: changes by other teams that the SOC must watch (firewall migrations, identity provider changes, new log sources), which often cause false positives or blind spots.
7. Communication and notification
| Field | What to write |
|---|---|
| Running clocks | Any regulatory or contractual deadline: regime, start time of awareness, deadline, owner (for example GDPR Article 33's 72 hours, or a customer contract term) |
| Promised updates | Updates promised to stakeholders or customers, due time and content |
| External parties engaged | Provider, IR retainer, law enforcement, vendor support case numbers |
| Executive awareness | Who has been briefed, when the next brief is due |
D3: Escalate the handover? If any clock falls due in the coming shift, the handover becomes Extended (section 1) and the [Incident Manager] joins.
8. Post-incident review
8.1 At the end of the read-through, the incoming [Shift Lead] signs acceptance in the record with the time. Unresolved questions are written down with an owner; responsibility transfers only on signature.
8.2 The [SOC Manager] samples [five] handovers a week against this template and checks: every open case has an owner; every containment action has an expiry; every clock has an owner; the incoming shift acknowledged. The NCSC recommends recording triage and investigation actions so that periodic quality assurance can check alerts are not dismissed without good reason; handover records support that review.
8.3 D4: Handover-related incident. Where an incident review finds that an item was lost at handover, record it as a contributing cause in the Post-Incident Review and Root Cause Analysis Template and change this template.
Implementation guidance
Rollout. Phase 1: agree the record fields in sections 3 to 7 and build them into [Case Tool] as a structured handover form, so most fields fill from open cases. HSE advises involving end users when changing handover methods; let the shift leads design it. Phase 2: run the new form in parallel with the existing method for two weeks on one shift pattern, then compare missed items. Phase 3: adopt it for all shifts and provider hand-offs; rollback is returning to the old format while keeping the containment register, which is the highest-value element. Small teams with business hours plus on-call can use the On-call row only and a single daily record. Large or follow-the-sun SOCs should add a time-zone column to every time field and a shared view with the provider.
Read-through order. Run the verbal handover in the same order every time, highest risk first, so that a handover cut short still covers what matters:
- Live incidents at [High] or above: phase, owner, next action, next decision.
- Running clocks and promised updates (section 7).
- Containment actions in force and those expiring this shift (section 4).
- Detection health: silent sources, disabled rules, coverage gaps (section 3).
- Watchlist entries, including service accounts and keys on watch.
- Cases in triage and eradication or recovery tasks (sections 3, 5 and 6).
- Questions from the incoming shift, then signature.
Worked example of a containment entry. "Case [IR-0412]. Host [FIN-LT-223] isolated in EDR at 02:14 UTC, approved by [Incident Manager]. Review at 10:00 UTC with the case owner; finance user on loan laptop [LT-990]. Pending: reimage ticket [CHG-5521] awaiting desktop team. If lifted, tell [Finance Ops lead]." An entry like this can be acted on by someone who has never seen the case.
Choosing a format. A structured form inside the case tool keeps data current and searchable but needs configuration; a shared document is fast to adopt but drifts from case data. Teams with fewer than [20] open cases per shift can start with the document; above that, build the form.
Framework mapping.
| Area | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 |
|---|---|---|
| Incident handling across shifts | RS.MA-01 | IR-4 |
| Recording actions and preserving evidence integrity | RS.AN-06, RS.AN-07 | IR-5, AU-9 |
| Continuous monitoring | DE.CM-01 | SI-4 |
| Stakeholder notification | RS.CO-02 | IR-6 |
Metrics. Percentage of handovers with signed acceptance; containment actions past expiry with no decision; open cases without an owner after handover; handover-related contributing causes per quarter; average handover duration against the planned slot. More SOC measures are in the Security Operations Metrics Guide.
Common failure patterns.
- Handover by chat message only, with no read-back and no acceptance.
- Temporary blocks and suppressions with no expiry, still in place months later.
- Regulatory clocks tracked in one person's head.
- Silent log sources not passed on, so the next shift trusts an empty queue.
- Provider and in-house teams each assuming the other owns an item.
- Handover squeezed into the last two minutes of a tired night shift.
Standards and references
- NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
- HSE: Human factors, shift handover
- NCSC: Building a Security Operations Centre
- NCSC: Incident management in the SOC
- NIST: Cybersecurity Framework 2.0
- NIST: SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations
Related NHI Mgmt Group resources: SOC Staffing and Shift Models Guide · SOC Guide · SOC Runbook Template · Alert Triage Guide · Security Operations Metrics Guide