SOC Shift Handoff

Why Shift Handoff Matters and What It Should Cover

Shift handoff is the structured transfer of operational responsibility from the outgoing SOC shift to the incoming shift.
In a 24x7 SOC, shift changes happen 2-3 times per day. If handoff is sloppy, three things break: (1) Active investigations stall — the incoming analyst has no idea what was checked or what remains. (2) Alerts are re-triaged unnecessarily, wasting 30+ hours of analyst time per week. (3) Critical context (IOC hits, pivot points, attacker TTPs already identified) is lost — see Incident Response for the full IR framework.

The Handoff Brief — What to Cover in 10 Minutes

1. Active Incidents

For each open incident, the outgoing analyst must communicate:

Item	Required Detail
Ticket ID	For tracking
Severity	Critical / High / Medium / Low — any changes during this shift?
Summary	One-liner: “Host A infected with malware X, 15 minutes into containment.”
Actions taken	What has been done? Host isolated? C2 blocked? Evidence captured (see Digital Forensics & Live Response)?
Actions pending	What still needs to happen? Memory analysis? Lateral Movement Response check?
Key findings	IOCs found (IPs, domains, hashes, commands). TTPs identified.
Evidence location	Where are the forensic images, log extracts, screenshots?
Stakeholders involved	Who has been notified? Legal, management, client?

2. Open Alerts

Item	Detail
Alert type	Phishing, malware, anomalous auth, scan, etc.
Status	Triaged, investigating, escalated, false positive
If false positive	Why? (e.g., “Approved pentest”, “Known application behavior”)
If investigating	What’s been checked, what’s still pending
Time until SLA breach	How long until this alert exceeds its SLA?

3. External Context

Item	Detail
Ongoing threat intel	Any new intel received during the shift? Zero-day alerts?
Infrastructure changes	Maintenance windows, deployments, firewall changes?
Special events	Penetration test in progress? Audit? Red team exercise?
Escalation contacts	Who is on call for management, legal, engineering?

Shift Handoff Template

Quick Reference Card

SHIFT HANDOFF — [DATE] [SHIFT] → [SHIFT]
==========================================
Outgoing analyst:             Incoming analyst:
                              @15 min overlap:
                              Communications check:

ACTIVE INCIDENTS:
### [TICKET-ID] — [SEVERITY] — [SUMMARY]
  Actions taken:
  - 
  Still needed:
  - 
  Key IOCs:
  - 
  Evidence:
  - 

### [TICKET-ID] — [SEVERITY] — [SUMMARY]
  ... (repeat for each active incident)

OPEN ALERTS:
Priority | Alert Type | Status | Time to SLA deadline
---------|------------|--------|---------------------
HIGH     | Phishing   | Investigating | 2h remaining
...

EXTERNAL CONTEXT:
- Threat intel:
- Infrastructure:
- Special events:
- Escalation contacts:

HANDOFF COMPLETE:
Outgoing signature:            Incoming signature:

The 5 Most Common Handoff Failures

Failure	Impact	Prevention
”It’s in the ticketing system”	Incoming analyst must re-read every ticket note to understand current state	Verbally summarize each active ticket. The ticketing system is the record, not the handoff.
”We’re investigating X — no other info”	Incoming analyst doesn’t know what’s been tried or ruled out	Document what has been checked (data sources reviewed, queries run, systems examined).
”The alert was F/P” without explaining why	Next analyst on the same alert wastes time re-validating	Always document the F/P reason: rule tuning issue, known-good process, authorized scan.
No IOCs transferred	Incoming analyst starts lateral movement checks from scratch	IOC list must be verbally communicated and documented in the ticket.
Assumed shared context	”You know that C2 IP we were tracking” — incoming analyst has no idea	Never assume context. Every shift brief is a fresh summary.

When Handoff Goes Bad — Real-World Scenario

Bad Handoff:
Outgoing: "The phishing alert — we checked it, it's probably nothing."
Incoming: [opens ticket, finds no notes, no IOCs, no evidence path]
Result: 20 minutes re-triaging a confirmed phishing URL that was already identified.

Good Handoff:
Outgoing: "Ticket 472 — phishing alert. User clicked link in 'Invoice Overdue' email.
Actions taken: URL submitted to URLScan.io — screenshot shows fake Microsoft login page.
Domain registered 3 days ago. SPF fail. 4 other users received same email — check proxy logs.
Still needs: Inbox rule check on the user's account. Confirmed no credentials entered.
Evidence: Email in phish-sandbox/shift-oct-25/"
Incoming: [understands state, starts from pending actions]
Result: 2 minutes to transfer, immediately productive.

Tier-Specific Handoff Considerations

Tier 1 → Tier 2

When Tier 1 hands off to Tier 2 (escalation), include:

Raw evidence: Screenshots, log extracts, command outputs
Timeline: When the incident started, when each action was taken
User impact: Is the user locked out? Affected? Not yet contacted?
Pivot paths: What other systems or users might be affected?
Questions unanswered: What the analyst could not determine

Tier 2 → Tier 1

When Tier 2 returns a resolved incident to Tier 1 for closure:

Root cause: A clear one-line explanation of what happened
Actions taken: All containment, eradication, and recovery steps
IOC list: All IPs, domains, hashes, and commands associated with the incident
Post-recovery monitoring instructions: What to watch for in the next 48-72 hours

Shift-to-Shift

Between same-tier shifts (Tier 1 → Tier 1 or Tier 2 → Tier 2), the handoff template above covers all needs. The key additional requirement: flag any change in the risk posture or threat landscape during the shift.

Digital Handoff Log

Maintain a running digital handoff log in the SIEM or a shared document that records:

[HANDOFF LOG]
2026-05-23 17:00 — @alice → @bob
- TKT-472: Phishing, user clicked, contained. Pending: inbox rule check.
- TKT-473: F/P — rule 1024 triggered on approved vulnerability scan.
- Intel: CISA alert AA24-123A — new LockBit variant targeting healthcare.
- Infrastructure: Firewall rule change 10.0.0.0/8 egress block — deployed 16:45.

This log is searchable, auditable, and serves as the permanent record of every shift transition.

SOC Analyst Skills — step-by-step soc analyst skills response procedures
Active Directory Compromise Response — detection and response for T1558 techniques
Business Email Compromise Response — detection and response for T1566, T1114, T1098, T1586 techniques