SOC Staffing and Shift Models Guide: Coverage, Rotas and Analyst Retention

A security operations centre that looks fully staffed on an organisation chart can still leave the alert queue unwatched at 3am on a Sunday, because one round-the-clock seat needs several people once leave, training, sickness and rest rules are counted. Staffing decisions decide what the SOC can actually see and act on: hours of coverage, how alerts are handled out of hours, how knowledge passes between shifts and whether experienced analysts stay. The NCSC's SOC guidance calls finding the right people likely one of the biggest constraints, and notes that a 24/7 SOC needs significantly more staff than a business-hours team with on-call. This guide covers coverage options, sizing, shift patterns, on-call, handover, structure, retention and outsourcing, for SOC managers and CISOs building a rota.

Key takeaways

• Decide coverage from risk, not prestige. Business hours with on-call, extended hours, 24/7 in-house, follow-the-sun and outsourced overnight are all legitimate; the right one depends on threat profile, regulatory duty and whether the rest of IT can act out of hours.
• One 24/7 seat is roughly five people. A year has 8,760 hours; one full-time analyst is available for well under a quarter of them once leave and training are subtracted.
• Design rotas around fatigue rules. UK HSE guidance recommends forward-rotating shifts, no more than two or three night or long shifts in a row and a 12-hour cap, reduced to 8 hours for night or monotonous work; UK law requires 11 hours' daily rest.
• Handover is a control, not a courtesy. Open cases, in-flight containment and pending decisions must pass between shifts in writing and in person, with one named owner for every open item.
• Retention is designed in. Rotation between triage, hunting, detection engineering and response, a visible career path and a sustainable alert load keep analysts; isolating people in narrow triage work drives them out.

Coverage models and how to choose

NIST SP 800-61 Rev. 3 notes that incident handlers may be on staff, under contract (for example a managed security service provider running an outsourced SOC) or available when needed, and that multiple teams in a large organisation should operate as one coordinated federation. The NCSC adds that most SOCs outsource some operations, that a 24/7 SOC is less effective if the IT teams it depends on only work 9 to 5, and that an existing 24/7 IT team can perform initial triage of high-priority out-of-hours alerts before escalating.

Decision guidance: start from three questions. What is the realistic cost of an attacker having eight unobserved hours (look at your own incident history and at when your out-of-hours alerts actually fire)? Can anyone outside the SOC act on an alert at night, such as an infrastructure on-call who can isolate a server? Do regulators or customers require continuous monitoring? If the answers are "low, no, no", business hours with on-call and automated containment for a few high-confidence detections is defensible. If any answer is "high" or "yes", plan for 24/7 detection, in-house or hybrid. See the MDR Guide and the Co-Managed SOC and SOC-as-a-Service Guide.

Sizing the team: the arithmetic of a 24/7 seat

There is no authoritative ratio of analysts to alerts or endpoints: NIST SP 800-61r3 does not set one, and the NCSC advises sizing the team from the threat profile and SOC scope, expecting several iterations. What can be calculated precisely is how many people one continuously staffed seat needs. The figures below are a worked example, not a benchmark.

Two continuously staffed seats in this example need about eleven analysts before any team lead, detection engineer or threat hunter is counted. A lone night analyst should never be the only person able to approve containment. Also allow for:

• Peak seats: extra day-shift analysts when alert volume and user activity peak, sized from your own hourly alert distribution.
• Non-queue work: detection engineering, hunting, purple team exercises and tooling. If these are only done "when the queue is quiet", they are never done.
• Vacancies: MITRE's guidance on SOC staffing advises planning for turnover and building a hiring pipeline, because vacancies take months to fill.
• Escalation tiers: incident handlers and a duty manager on call, sized to how often they are actually paged.

Small organisations should be honest about the numbers: a team of three cannot run 24/7 shifts without breaching rest rules, and should instead buy overnight coverage or accept business hours plus on-call. For broader SOC design, see the SOC Guide.

Shift patterns and fatigue rules

The UK Health and Safety Executive's good practice guidelines for shift design (with more detail in its publication HSG256, Managing shift work) are a sound basis for SOC rotas even outside the UK. Its main points: offer a choice between fixed and rotating shifts but avoid permanent night shifts; rotate either quickly (every two to three days) or slowly (every three to four weeks), and rotate forward (day, evening, night); cap shifts at 12 hours including overtime, reducing to 8 hours for night work or work that is demanding, monotonous or safety-critical; limit runs of work to five to seven days and long, night and early shifts to two or three in a row; allow two full nights' sleep when switching between day and night; and include regular free weekends.

Legal limits apply on top. In the UK, workers are entitled to 11 consecutive hours' rest between working days, a 20-minute break when working more than six hours, and 24 hours' uninterrupted weekly rest (or 48 hours per fortnight). A night worker (someone regularly working at least three hours in the night period, by default 11pm to 6am) must not average more than 8 hours' work in 24 hours over the reference period, usually 17 weeks, and cannot opt out of that limit. Check local working time rules with HR.

On-call design for out-of-hours alerts

Where nights are covered by paging rather than a staffed seat, the paging rules become part of the detection design. The NCSC suggests that high-priority alerts can notify an on-call analyst directly. Google's Site Reliability Engineering guidance, which also notes that night shifts harm health, offers concrete benchmarks for sustainable on-call: on-call should take no more than 25 per cent of an engineer's time, a single-site rotation needs a minimum of eight people (six per site for two sites) so that each person is on call about one week in eight or less, and paging alerts should be actionable and tuned towards one alert per real incident.

• Page only on P1 and selected P2 alerts: anything else waits for the morning queue. Review the paging list monthly against what actually woke people up. The triage priority model is in the Alert Triage Guide.
• Primary and secondary: a secondary on-call catches pages the primary misses and provides a second opinion before disruptive containment.
• Response targets: agree acknowledgement and response targets per priority, and set them so a sleeping analyst can meet them.
• Pre-approved actions: document what the on-call analyst can do without waking a manager, such as isolating a workstation or disabling a user session, and what needs approval, such as shutting down a production server. NIST SP 800-61r3 notes that leadership may need to decide high-impact actions.
• Compensation and recovery: pay or time off in lieu for on-call, and protected rest after a night callout so the analyst is not back on shift at 8am. UK daily rest rules still apply.
• External dependencies: confirm that infrastructure, cloud and identity teams also have on-call cover; an analyst who cannot reach anyone with change rights can only watch.

Shift handover

MITRE lists passing information from one shift to another as part of communication within the SOC, and NIST SP 800-61r3 asks that each incident's status, indicators, actions and next steps are tracked. Typical dropped items are a half-completed containment action or a rule muted "until morning".

1. Write before you talk: the outgoing shift updates every open case in the case management tool, so the record, not the conversation, is authoritative. Case tools such as Microsoft Defender XDR keep comments, status changes and handovers in the incident activity log.
2. Use a fixed handover template: open incidents with owner and next action; alerts escalated and awaiting response; containment in progress; temporary exclusions or suppressions applied this shift and when they expire; tooling or log source outages; expected events (changes, pen tests); anything the outgoing shift is unsure about.
3. Overlap shifts: build 15 to 30 minutes of paid overlap into the rota for a verbal walk-through of high-priority items.
4. Transfer ownership explicitly: every open P1 or P2 item gets a named incoming owner; "the night shift" is not an owner.
5. Review handovers: the SOC lead samples handover notes weekly and checks them against what happened next.

For follow-the-sun teams, hold handovers in the case tool with a short call, and agree one time zone (usually UTC) for every timestamp; CISA's incident response playbook asks for timelines in UTC for the same reason. See the SOC Runbook Template for documenting procedures.

Roles, tiers and structure

Traditional SOCs use tiers: Tier 1 triages, Tier 2 investigates, Tier 3 hunts and handles complex incidents. The NCSC's operating model guidance warns against isolating analysts in narrow tasks, which can lead to triage fatigue, poor job satisfaction and weaker security, and encourages rotation across threat intelligence, content development and incident handling while keeping specialisms. MITRE's second edition also discusses tierless SOC models.

Document roles and authorities so that analysts know what they may do (CSF 2.0 GV.RR-02), and provide role-based training for incident responsibilities (PR.AT-02). The NICE Workforce Framework for Cybersecurity (NIST SP 800-181 Rev. 1) gives a common vocabulary of work roles and task, knowledge and skill statements that helps with job descriptions, recruiting and training plans. The NCSC also advises that SOC staff actions are auditable, using least-privilege privileged accounts. SOC analysts hold powerful access to EDR consoles, SIEM data and response automation, so their accounts and any automation credentials belong in PAM and are reviewed like other privileged identities. See the SOC Analyst Career Guide for skills and progression.

Analyst retention

MITRE's strategy on staff is summarised as "Hire AND Grow Quality Staff": pay fair market value, build a sense of belonging and an inclusive workplace, offer career progression, accept that turnover is a reality and capture institutional knowledge before people leave. Practical levers:

• Sustainable load: track alerts per analyst-hour and backlog age; a permanently overflowing queue is a staffing or tuning problem, not a motivation problem. See the Alert Fatigue Reduction Guide.
• Time off the queue: protect a fixed share of each analyst's week for detection engineering, hunting, automation or study, and do not cancel it whenever the queue grows.
• Visible progression: publish what moves an analyst from first-line triage to investigation, engineering or hunting, mapped to NICE work roles or your own competency framework.
• Humane rotas: follow the HSE guidance, publish rotas well in advance, allow swaps and give choice between fixed day and rotating patterns where possible.
• Automation of drudgery: use SOAR and AI assistance for enrichment and repetitive closures so analysts spend time on judgement. See the SOAR and Security Automation Guide and the AI SOC Guide.
• Knowledge capture: runbooks, detection documentation and case notes written so a new hire can follow them, which also reduces the cost of each departure.

Outsourcing and shared responsibility

NIST SP 800-61r3 says responsibilities transferred to a provider should be clearly defined in the contract, including information flows, coordination and the provider's authority to act for the organisation, and warns that providers often hold privileged access, so insider risk and provider compromise must be considered. Include providers in incident planning and exercises (CSF GV.SC-08).

• Define the boundary: which alerts the provider triages, which it escalates, and which actions it may take without asking (for example isolating a workstation but not a server).
• Escalation contacts: a tested out-of-hours call tree on the customer side; a provider that escalates to an unanswered mailbox is no coverage at all.
• Context feed: give the provider asset criticality, privileged account lists, change calendars and known benign activity, and keep them current.
• Access control: provider accounts use MFA, least privilege, named users rather than shared logins, and are reviewed regularly (SP 800-53 PS-7 and SA-9).
• Measure the provider: time to escalate and escalation precision.

Rolling out a new rota or coverage model

1. Baseline: measure alert volume by hour of day and day of week, out-of-hours incidents over the last year, and current overtime and leave usage.
2. Choose the model: apply the coverage decision questions above and agree the risk position with the CISO.
3. Size and consult: calculate people per seat with real contract terms; consult staff and HR on patterns and check working time rules.
4. Pilot: run the new rota for one rotation cycle with a named fallback (overtime cover or provider support) and track handover issues and missed pages.
5. Review and roll back if needed: keep the previous rota documented so it can be reinstated if coverage gaps or fatigue problems appear.

Measuring staffing health

• Coverage gaps: hours per month where a planned seat was empty or on-call was not reachable.
• Time to triage by hour of day: if night-time P1 and P2 triage is much slower than daytime, the coverage model is not working.
• Pages per on-call shift: and the share that were actionable. Rising non-actionable pages mean tuning is needed.
• Overtime and rest breaches: hours of overtime and any breaches of the rota's own rest rules.
• Handover defects: open items found without an owner or next action after a shift change.
• Retention: voluntary leavers per year and time to fill vacancies, compared with your own previous years.

See the Security Operations Metrics Guide for metric definitions.

Common failure patterns

• Paper 24/7: the SOC is advertised as 24/7 but nights are one analyst who also covers IT support, or an on-call phone nobody tests.
• Night analyst without authority: the out-of-hours analyst sees the attack but has no pre-approved actions and no one to call with change rights, so containment waits for morning.
• Verbal-only handover: details live in a conversation, the outgoing analyst goes home, and an in-flight containment step is never finished.
• Everyone on the queue: no protected time for engineering or hunting, so noise never falls and experienced staff leave.
• Outsourced and forgotten: a provider is contracted for overnight monitoring but never given asset context or a working escalation path. See the Top 10 SOC Challenges.

Framework mapping

Practitioner checklist

• Write down the coverage model and the risk reasoning behind it, signed off by the CISO.
• Calculate people per staffed seat from real contract, leave and training figures, and round up.
• Check every rota against HSE shift design guidance and local working time law before publishing.
• Define the paging list, response targets and pre-approved out-of-hours actions.
• Confirm that infrastructure, cloud and identity teams have reachable on-call cover.
• Use a written handover template with a named owner for every open P1 and P2 item, plus paid overlap.
• Protect a fixed share of analyst time for engineering, hunting or training.
• Put SOC analyst and automation accounts under PAM with regular access review.
• Contract outsourced coverage with a clear boundary, authority to act and a tested escalation tree.
• Review coverage gaps, night-time triage times, pages per shift and attrition quarterly.

Standards and references

• NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• NCSC: Building a Security Operations Centre, Designing an operating model
• MITRE: 11 Strategies of a World-Class Cybersecurity Operations Center
• HSE: Good practice guidelines for shift work design
• GOV.UK: Night working hours
• GOV.UK: Rest breaks at work
• NIST: SP 800-181 Rev. 1, Workforce Framework for Cybersecurity (NICE Framework)
• Google: Site Reliability Engineering, Being On-Call

Related NHI Mgmt Group resources: SOC Guide · MDR Guide · Alert Triage Guide · SOC Analyst Career Guide · Security Operations Metrics Guide