1.10 Shift Handover and 24/7 Operations

8-10 hours · Module 1 · Free

Operational Objective

SOC operations do not stop at 17:00. After-hours coverage — whether through on-call rotation, MSSP partnership, or follow-the-sun staffing — requires a structured handover process. Every shift transition is a potential gap: an incident that one analyst investigated for 3 hours is handed to the next analyst with "check the queue" and 30 minutes of re-investigation before they understand the context. The handover process eliminates this gap.

Deliverable: A shift handover template and procedure that transfers incident context, investigation state, and pending actions between analysts with zero information loss.

Estimated completion: 35 minutes

Figure 1.10 — Operational workflow from input through documented output.

The handover problem: context loss kills investigations

NE operates a hybrid coverage model: in-hours SOC staffing (08:00-18:00 UK) with BlueVoyant providing after-hours monitoring and Tier 1 triage. The handover occurs at 08:00 (BlueVoyant → NE morning shift) and 18:00 (NE evening → BlueVoyant overnight). Each handover transfers 3 categories of information:

Active incidents. Any incident not yet resolved — current severity, investigation state, evidence collected, containment actions taken, pending actions, and the analyst’s assessment of what to investigate next. The handover document uses the incident ID as the primary key and provides a 3-5 sentence summary per incident. The receiving analyst reads the summary and knows exactly where to pick up — no re-investigation of work already completed.

Pending alerts. Alerts in the queue that have not been triaged — the count, the highest-severity alert, and any alerts that the outgoing analyst started investigating but did not complete. The receiving analyst prioritises the pending queue based on the outgoing analyst’s notes.

Environmental context. Anything unusual about the environment: a planned maintenance window that will generate false positive alerts, a phishing simulation running this week that will produce expected phishing alerts, a vulnerability disclosure that may trigger scanning activity, or a supplier who reported a compromise that may affect NE through the supply chain.

Compliance Myth: "Our MSSP handles overnight so we don't need a handover process"

The MSSP handles overnight TRIAGE — they classify and escalate. They do not continue YOUR investigation. If an NE analyst spent 3 hours investigating an AiTM compromise before the 18:00 handover, BlueVoyant does not pick up that investigation — they monitor for new activity and escalate if the situation worsens. At 08:00, the returning NE analyst must resume the investigation. Without a handover document, that analyst starts from scratch. The handover process is between NE shifts AND between NE and the MSSP.

The handover meeting is 15 minutes maximum — timed. Each incident gets 2 minutes: the outgoing analyst summarises, the incoming analyst asks clarifying questions, and the handover document is updated with any additional context from the discussion. If there are more than 5 active incidents, the meeting extends to 20 minutes but never beyond — urgency forces conciseness.

Expand for Deeper Context

The handover document is stored in a shared location accessible to both NE and BlueVoyant — a Teams channel dedicated to SOC handovers. Each handover creates a new post with the date and shift transition (e.g., “2026-04-09 18:00 NE → BlueVoyant”). The post follows the template: Active Incidents (numbered list with summaries), Pending Alerts (count and priorities), Environmental Context (any notes), and Handover Analyst (name and contact for questions).

The handover quality is measured as part of the SOC metrics program (S11). The metric: “handover completeness score” — the percentage of active incidents that the receiving analyst can resume within 5 minutes of reading the handover document (vs requiring additional investigation to understand the context). Target: 95%. Incidents where the receiving analyst had to re-investigate due to an incomplete handover are flagged in the monthly SOC report as handover failures.

For on-call escalations (after-hours Severity 1-2 incidents that require NE analyst involvement), the handover is immediate: BlueVoyant calls the on-call analyst, provides a verbal briefing, and sends the incident link. The on-call analyst joins the Teams bridge within 15 minutes. The verbal briefing follows the same template as the written handover — active incidents, evidence state, containment actions, pending investigation steps.

Decision point

At 17:45, you are investigating a Severity 2 AiTM compromise. You have confirmed the compromise, collected SigninLogs and AuditLogs evidence, and identified 2 persistence mechanisms (MFA method + inbox rule). You have NOT yet contained (session revocation, MFA removal, rule deletion). Do you contain now (15 minutes before handover) or document the state and hand over to BlueVoyant?

Contain now. The attacker is active — every minute of delay is a minute of additional data access. Containment takes 5-10 minutes. You contain, document the containment actions in the handover, and hand over a contained incident to BlueVoyant for monitoring. Handing over an uncontained Severity 2 incident to overnight monitoring transfers the containment decision to a team that may not have the authority or context to execute it. The rule: never hand over an uncontained active compromise if you can contain it before the transition.

Try it: Write the handover document

Scenario: It is 17:50. You have 2 active incidents and 3 pending alerts. Write the handover document for the 18:00 BlueVoyant transition.

Incident 1: Severity 2 AiTM compromise of s.chen@northgateeng.com. Compromised at 09:17. Contained at 17:45 (sessions revoked, MFA method removed, inbox rule deleted). Evidence collected: SigninLogs (7 days), AuditLogs (7 days), OfficeActivity (7 days). Pending: assessment of which emails were accessed (MailItemsAccessed analysis not yet started). Post-containment monitoring: watch for new sign-ins from 203.0.113.42.

Incident 2: Severity 3 suspicious PowerShell on WS-NGE-FIN007. Alert at 16:30. Initial triage complete — encoded PowerShell command downloading a file from an external URL. Defender for Endpoint did not auto-isolate (confidence below threshold). Pending: decode the command, check the URL against TI, assess whether the file was executed. If the file executed, reclassify to Severity 2 and isolate.

Pending alerts: 3 Medium-severity alerts in the queue — 2 impossible travel (likely FP — both users are known travellers) and 1 new inbox rule creation (needs triage).

Environmental context: Phishing simulation running this week — expected phishing alerts from the simulation platform should be tagged “simulation” by BlueVoyant and not investigated.

The morning shift analyst reads the handover and sees: "Incident 2: Severity 3 suspicious PowerShell. Pending: decode the command." The analyst opens the incident and finds no notes about what the command downloads, where it was executed, or what process spawned PowerShell. They must re-investigate from the alert. What failed?

The handover template is inadequate — it should require more detail.

The outgoing analyst did not document their investigation progress in the incident. The handover summary says "initial triage complete" but the triage findings are not recorded anywhere — not in the Sentinel incident comments, not in the handover document, not in a working notes file. The failure is documentation during investigation, not the handover process itself. The fix: every investigation action and finding must be logged in the Sentinel incident comments in real-time. The handover document summarises what is in the incident comments — it does not replace them.

The incoming analyst should call the outgoing analyst for a verbal briefing.

BlueVoyant should have continued the investigation overnight.

Operational Artifact — Shift Handover Template

The handover template covers: Active Incidents (ID, severity, summary, evidence state, containment state, pending actions), Pending Alerts (count, priorities, any partial triage notes), Environmental Context (maintenance windows, simulations, supplier incidents), and Handover Analyst (name, contact, shift end time). Adapt for your organisation's coverage model — the template works for NE's hybrid model (in-house + MSSP) and for fully staffed 24/7 SOCs with shift rotations.

The on-call escalation at 02:00: NE’s worst-case handover scenario

At 02:14 on March 13, 2026, BlueVoyant’s overnight analyst detected a new AiTM sign-in from the attacker’s IP range — a 6th compromised account (a.patel@northgateeng.com) that was not identified during the previous day’s investigation. BlueVoyant followed the updated AiTM runbook: immediate escalation to NE’s on-call analyst (Rachel, who had led the investigation the previous day).

The escalation followed the on-call procedure: BlueVoyant called Rachel’s mobile at 02:17. The verbal briefing was 3 minutes: “New AiTM sign-in matching the Wave 5 pattern. Account: a.patel. IP: 203.0.113.47 (same subnet as yesterday). MFA satisfied by claim. Sign-in at 02:11. No containment executed — waiting for NE authorisation per the AiTM runbook.”

Rachel authorised containment from her phone: “Revoke sessions for a.patel immediately. I will connect to the VPN and verify containment within 15 minutes.” BlueVoyant executed the session revocation at 02:22 — 11 minutes from detection to containment, at 2 AM, with the primary analyst working remotely.

Rachel connected to VPN at 02:30, verified the session revocation, checked a.patel’s AuditLogs for persistence mechanisms (one MFA method registered at 01:45 — removed), and updated the Sentinel incident. At 02:50, she posted the after-hours update to the handover channel: “INC-2026-0227-001 update: 6th account compromised (a.patel). Contained at 02:22. MFA method removed. No inbox rules or OAuth apps created. Recommend expanding the investigation scope tomorrow to check all accounts that received Wave 5 phishing but were not in the original 5 confirmed compromises.”

The 08:00 handover the next morning transferred a contained incident with clear next steps — Tom picked up the scope expansion investigation without any re-investigation of Rachel’s overnight work. The on-call procedure worked because: the runbook authorised BlueVoyant to escalate (not investigate), the verbal briefing followed the handover template (incident ID, what happened, what has been done, what needs to happen next), and the handover document captured the overnight actions for the morning shift.

The after-action review identified one improvement: the on-call analyst should have a pre-authenticated VPN session on their mobile device (always-on VPN profile) to eliminate the 13-minute delay between phone call and VPN connection. This was implemented the following week — Rachel can now access Sentinel from her phone within 2 minutes of an escalation call.

Measuring handover quality

The SOC metrics programme tracks handover quality using a single metric: “resume time” — how many minutes does the incoming analyst need to reach the same investigation context as the outgoing analyst? The target: 5 minutes or less for any active incident.

The measurement: after each handover, the incoming analyst records the time they opened the first active incident and the time they felt confident to make the next investigation decision. The difference is the resume time. Resume times over 10 minutes are flagged as handover failures — the outgoing analyst’s documentation was insufficient.

NE’s average resume time: 4.2 minutes (measured over Q1 2026). The fastest handover: 1 minute (a contained Severity 2 with “monitor for new activity, no action required” — the incoming analyst confirmed the containment and moved to the pending queue). The slowest: 18 minutes (the INC-2026-0227-001 initial handover failure described above). After implementing the structured handover template, no resume time has exceeded 8 minutes.

The handover template is maintained as a Teams channel post template — the outgoing analyst clicks ‘New Post,’ selects the ‘SOC Handover’ template, and fills in the structured fields. The template enforces completeness: mandatory fields (Active Incidents, Pending Alerts, Environmental Context) must be populated before the post can be submitted. Optional fields (Ongoing Investigations, Upcoming Maintenance Windows) provide additional context when relevant. The template was designed by Priya to minimise handover preparation time while maximising information transfer — the average handover document takes 8 minutes to write and covers all active work completely.

The handover process is included in every new analyst’s onboarding. During the first week, the new analyst observes 2 handovers (08:00 and 18:00), then conducts 2 supervised handovers with the SOC lead reviewing the handover document before submission. By the end of week 1, the analyst has delivered 2 handover documents that met the quality standard. This practice-based onboarding is more effective than reading the handover SOP — the analyst learns the format, the level of detail expected, and the common pitfalls (underdocumenting containment state, forgetting environmental context) through practice with feedback.

The handover quality metric is reported in the monthly SOC report alongside MTTD and MTTC — demonstrating that operational discipline (handovers, documentation, process adherence) is measured with the same rigour as technical performance (detection speed, containment speed). A SOC that detects fast but hands over poorly is only effective during single-shift incidents — multi-shift incidents require seamless context transfer, and the handover metric ensures this capability is maintained and improved.

You're reading the free modules of SOC Operations

The full course continues with advanced topics, production detection rules, worked investigation scenarios, and deployable artifacts. Premium subscribers get access to all courses.

View Pricing See Full Syllabus

← Previous