Designing SOC On-Call Rotations for Security Coverage Without Burnout

The most important design decision in SOC on-call is defining what requires immediate response outside business hours. Most alerts that fire during the day do not require waking an analyst at 3 AM.

Tier 1: Immediate response (page immediately, regardless of hour). Active intrusion scenarios where delay enables further damage:

• Active ransomware encryption in progress (EDR behavioral detection of mass file modification)
• Confirmed data exfiltration in progress (DLP alert with active connection to external destination)
• Privileged account compromise with active session (admin login from impossible geography after credential theft)
• Production system critical failure with security implication (database unreachable, potentially due to ransomware or DoS)
• Active physical security breach with digital system access (badge reader compromise correlated with account access)

Tier 2: Urgent response (page within 1 hour, acceptable to wake analyst). High-confidence detections with significant but not immediately catastrophic impact:

• Confirmed initial access (phishing link clicked, malware executed, C2 beacon established)
• Privilege escalation on a production system by a non-privileged account
• Multiple failed authentication attempts followed by successful login (brute force success indicator)
• New persistence mechanism established on a critical server (scheduled task, registry run key)
• Critical vulnerability scanner finding an actively exploited CVE on an internet-facing system

Tier 3: Deferred response (investigate at start of next business day, no on-call page). Detections that are important but do not require immediate action:

• Single failed authentication events (without success follow-on)
• Cloud security posture management findings (new misconfiguration)
• Non-critical vulnerability discoveries
• Behavioral anomalies that require investigation but have no active intrusion indicator
• DLP policy violations without confirmed exfiltration

Tier 4: Informational (no page, queue for daytime review). Low-fidelity signals, informational events, and findings that require daytime investigation context:

• Threat intelligence matches on non-critical assets
• Successful authentications from unusual but not anomalous locations
• Configuration drift detections

Document the tier assignment for each detection rule in the SIEM. On-call pages should only fire for Tier 1 and Tier 2 detections. Tier 3 and 4 detections create tickets but do not page.

Alert thresholds for on-call should be different from daytime thresholds. On-call alerts must have higher confidence requirements because the cost of a false positive page is significantly higher -- an analyst woken unnecessarily at 2 AM is impaired for the rest of the night and potentially the next workday.

On-call suppression rules. Configure the SIEM to suppress on-call pages for alert types that have high false positive rates at night but are manageable during the day. Common candidates:

• User authentication anomalies for accounts known to have users in multiple time zones (the anomaly detection model may not account for legitimate international travel)
• Scheduled maintenance windows (automated maintenance tasks that trigger detections should be suppressed during their known maintenance window)
• Backup and replication jobs that generate unusual network traffic during off-hours (common source of false on-call pages)

Enrichment before paging. For Tier 2 detections, configure automated enrichment that runs before the page fires. SOAR playbooks that:

1. Confirm the asset is production (not dev/test)
2. Verify the user exists and is active
3. Check whether the activity occurred within a change window
4. Cross-reference the source IP against threat intelligence

Enrichment that downgrades a Tier 2 detection to Tier 3 (for example, confirming the failed logins are from a known IT tool) suppresses the page without manual analyst intervention.

Correlation requirements for on-call pages. Require multiple corroborating signals before paging on-call for behavioral detections. A single behavioral indicator without corroboration should not page. Two corroborating indicators should escalate to a Tier 2 page. Three or more corroborating indicators should trigger a Tier 1 page. Implement this as a correlation rule that aggregates related alerts before paging.

Post-page false positive tracking. Track every on-call page's outcome: was the page genuine (Tier 1 or Tier 2 confirmed finding) or a false positive (page woke the analyst but the investigation found no real activity)? Target: fewer than 30% of on-call pages should be false positives. False positive rate above 30% indicates the threshold calibration needs adjustment.

On-call analysts need a clear escalation path for incidents that exceed their authority or capability. An on-call analyst should never be the only option for a major incident at 3 AM.

Define the escalation path before it is needed. The escalation path must be documented and all parties must have agreed to be in the path. An escalation path that relies on an analyst knowing to call a specific manager at home without that manager's agreement is not a real escalation path.

Primary on-call. The first-level responder. Responsible for initial triage, Tier 1 and Tier 2 response, and escalation decisions. Expected to acknowledge within 15 minutes and initiate investigation.

Secondary on-call (escalation). A senior analyst or security manager who is paged when: the primary on-call cannot be reached within 30 minutes (failure to acknowledge), the incident is confirmed P1 severity, the incident requires containment decisions above the primary's authority (blocking a production network segment, disabling an executive's account), or the investigation is beyond the primary's expertise.

Incident commander (executive escalation). For confirmed P1 incidents -- active data breach, confirmed ransomware, critical system compromise -- the SOC manager or CISO must be notified. This is not a technical escalation; it is an executive notification that enables the organization to begin parallel workstreams (legal, communications, business continuity). Define the P1 notification criteria explicitly so the on-call analyst knows when to make this call.

External escalation: IR retainer. If the organization has an IR retainer, the on-call runbook should include the retainer provider's emergency contact number and when to use it. Typically: when the incident scope exceeds the internal team's forensics capability, when the incident requires 24/7 sustained investigation beyond what the rotation can support, or when the incident involves nation-state actors or advanced persistent threat activity.

On-call authority matrix. Define explicitly what the on-call analyst can do without escalation approval: blocking a user account, isolating an endpoint, blocking an IP at the firewall, taking a system offline. These pre-authorized containment actions enable the analyst to act without waiting for an escalation response during the critical containment window. Containment actions that require escalation (blocking a network segment, taking a production service offline) should be documented with the escalation contact information so the analyst knows who to call.

The rotation design determines how often each analyst is on call and how burdensome each on-call period is.

Rotation frequency calculation. Target: each analyst is on call for one week per month, maximum. This means:

• 4 analysts: weekly rotation (each analyst is on call one week out of four)
• 6 analysts: weekly rotation with some built-in buffer for vacation and sickness coverage
• 8+ analysts: consider a shorter on-call unit (3-4 days) to reduce burden per rotation

For teams smaller than 4 analysts with a weekly rotation, each analyst's on-call frequency exceeds the sustainable target. Options for small teams: (1) define a primary and secondary on-call with the secondary only paged for escalation, halving the primary's burden; (2) engage an MDR provider for overnight coverage to supplement internal on-call.

On-call unit length. One week is the most common on-call unit because it aligns with natural work cadences. Shorter units (3-4 days) reduce individual burden but increase handoff frequency. For teams where on-call burden is high (many pages per week), shorter units are better for burnout prevention even at the cost of handoff overhead.

Vacation and sick day coverage protocol. Define how coverage is handled when an on-call analyst is unavailable. Two patterns: (1) swap-based (analysts arrange swaps with each other, with manager notification), (2) permanent volunteer coverage (one analyst is designated as the coverage analyst for a given period and is compensated with reduced future on-call). Uncovered on-call periods are not acceptable -- they represent security gaps.

Overtime and compensation. On-call that produces more than three meaningful pages per week (resulting in lost sleep and impaired next-day function) should receive additional compensation, whether through on-call pay, compensatory time, or next-day flex time. Treating on-call as an uncompensated extension of employment creates attrition pressure. Be explicit about this expectation in team policies.

Measuring on-call burden prevents burnout from silently accumulating until analysts leave. Track these metrics per analyst per rotation period.

Pages received. Total number of on-call pages per week per analyst. Target: 0-3 per week is sustainable, 4-7 requires threshold review, 8+ is unsustainable and indicates immediate intervention is needed.

Mean time to sleep (MTTS) degradation. A proxy metric for sleep impact: the total number of on-call pages that occurred between 11 PM and 6 AM. This approximates the number of interruptions to sleep per on-call week. Target: fewer than 2 overnight pages per on-call week.

Median time to acknowledge (MTTA). The time from page sent to analyst acknowledgment. Consistently long MTTA (15+ minutes even for Tier 1 pages) indicates the analyst may be disabling or ignoring their pager -- a sign of burnout. Investigate high MTTA with the analyst before interpreting it as a performance issue.

On-call week subjective experience (survey). After each on-call week, ask the rotating analyst three questions on a 1-5 scale: (1) How disruptive was this on-call week to your sleep and personal time? (2) How confident were you in the resources available to handle on-call events? (3) Overall, how sustainable did this on-call week feel? Aggregate responses over time and track trends. Declining scores predict attrition.

Burnout early warning indicators. Beyond the metrics, watch for: analysts requesting off-call schedules more frequently than normal, declining participation in detection improvement discussions (disengagement), increased use of sick days following on-call weeks, or explicit statements about workload during 1-on-1 conversations. Act on early warning indicators before they escalate to departure.

Review and improvement cycle. Hold a monthly on-call retrospective: what pages were false positives (and can be suppressed or thresholds adjusted), what pages revealed missing runbooks, what escalations occurred and were they handled smoothly. The retrospective drives continuous improvement in both the alert quality and the on-call experience.

On-call analysts need mobile access to investigation tools without requiring a full workstation setup at 3 AM. The tooling requirement is different from daytime operations.

Mobile-accessible SIEM dashboard. The most common investigation starting point must be accessible from a phone or tablet. This typically means a SIEM with a responsive web UI or mobile app, with a pre-configured on-call dashboard that shows: the triggering alert details, the alert's runbook link, the affected asset's ownership information, and the one-click escalation path contact.

Pre-built investigation queries. On-call analysts should not be writing KQL or SPL queries from memory on a phone at 2 AM. Pre-build the investigation queries for each Tier 1 and Tier 2 alert type in the SIEM, accessible via saved search or investigation template. The runbook for each alert type should include a named link to the pre-built query.

Mobile-friendly runbooks. Runbooks that are 8-page PDF documents are not usable on-call. On-call runbooks should be accessible via a mobile-friendly URL (linked from the page notification), structured with the triage decision tree at the top, and optimized for single-handed reading on a phone screen.

One-click containment actions. For common containment actions (disable a user account, isolate an endpoint via EDR, block an IP at the firewall), configure SOAR playbook triggers accessible from the on-call notification or investigation dashboard. The analyst selects the action, confirms, and the SOAR executes the containment without requiring the analyst to log into multiple tools.

On-call paging platform. Use a purpose-built on-call management platform (PagerDuty, OpsGenie, VictorOps) that provides: escalation path management, acknowledgment tracking, rotation scheduling, and on-call override management for vacations and swaps. Do not manage on-call rotations via calendar and Slack DMs -- the lack of automated escalation and acknowledgment tracking creates coverage gaps.