Security teams rarely burn out because of one bad incident; they burn out because ordinary weeks never stop, with pages at night, queues that never empty and the sense that any miss will be their fault. Chronic exhaustion shows up first as slower triage, skipped steps and quiet resignations, which makes it a detection and resilience problem, not only a people problem. This guide covers burnout across the whole security function: SOC analysts, detection engineers, vulnerability and identity teams, security engineers and their leaders. It focuses on the everyday drivers (on-call load, alert volume, toil, interruptions, unclear ownership) and on retention. Surge working during a major incident, legal rest rules and on-call rotation sizing are covered in the Incident Responder Wellbeing guide, which this page builds on rather than repeats.
Source note: WHO, HSE, EU-OSHA, Google SRE and Gartner points below are quoted or summarised from the sources listed in the references, as checked in November 2026. This is not medical or legal advice. Confirm against the official text before relying on it.
Key takeaways
- Burnout is a work design outcome. The WHO's ICD-11 describes burn-out as resulting from chronic workplace stress "that has not been successfully managed", and classifies it as an occupational phenomenon, not a medical condition, so the fix sits with how work is organised.
- Toil and interruptions are the measurable drivers. Manual, repetitive, automatable work and constant context switching drain capacity long before anyone says they are exhausted; cap toil and protect focus time.
- Alert quality is a staffing decision. Every low-value alert spends analyst attention, so detection tuning belongs in the workforce plan alongside headcount.
- Measure load, not people. Pages per shift, out-of-hours work, queue age, toil share and leaver rates show risk without asking anyone to disclose their health.
- Retention follows growth. People stay where their week includes engineering work, learning and a visible path forward, not only where they are thanked after incidents.
What burnout looks like in a security team
The ICD-11 definition gives three dimensions: "feelings of energy depletion or exhaustion", "increased mental distance from one's job, or feelings of negativism or cynicism related to one's job", and "reduced professional efficacy". Each has a recognisable form in security work, and each carries a security consequence, which is why leaders should treat early signs as operational signals.
| ICD-11 dimension | How it shows in security teams | Operational consequence |
|---|---|---|
| Exhaustion | Analysts closing alerts on first glance; engineers no longer volunteering for on-call swaps; frequent short absences | True positives closed as benign; slower mean time to acknowledge |
| Mental distance or cynicism | "Nothing we flag gets fixed"; disengagement from post-incident reviews; dark humour about users or the business | Findings not escalated; weaker relationships with IT and engineering owners |
| Reduced professional efficacy | Detection backlog grows; runbooks go stale; people stop learning new tooling | Coverage gaps; dependence on one or two experts |
These signs overlap with ordinary bad weeks. The difference is persistence. One noisy on-call week is not burnout; three months of it, with no change in sight, often is. Do not diagnose individuals. Instead, look for patterns across the team and change the conditions.
Why security work drives chronic stress
Security combines several features that occupational health guidance identifies as psychosocial risks. EU-OSHA lists excessive workloads, conflicting demands and unclear roles, little involvement in decisions, poorly managed change and harassment. The HSE Management Standards group the same ground into six areas. Mapped to security work:
| HSE Management Standards area | Security-specific driver | Typical fix |
|---|---|---|
| Demands ("workload, work patterns and the work environment") | Alert volume, out-of-hours pages, audit seasons stacked on project deadlines, vulnerability queues that grow faster than they close | Toil cap, alert tuning, queue ownership by system owners, managed service for out-of-hours |
| Control ("how much say the person has in the way they do their work") | Analysts cannot tune the rules that page them; engineers cannot refuse unsafe changes | Give responders authority to suppress or retire noisy detections through a reviewed process |
| Support | Single experts for identity, cloud or forensics; no mentor for new analysts | Skills matrix with named deputies; pairing; budget for training time |
| Relationships | Blame after incidents; friction with IT when security "creates work" | Blameless review practice; shared remediation targets with system owners |
| Role ("whether people understand their role") | Security team as catch-all for every risk, questionnaire and access request | Written service catalogue stating what the team does and does not own |
| Change | Tool migrations, reorganisations and outsourcing announced without consultation | Involve the team early; phase migrations; run old and new tools in parallel only for a set period |
Two features make security unusual. First, the work is asymmetric: success is invisible and a single miss is visible, which encourages over-checking and makes it hard to stop. Second, demand is set by attackers and by other teams' choices, so the team cannot easily control its own workload. Both are reasons to make capacity and load explicit and to share them with leadership.
Leaders are not immune. In February 2023 Gartner predicted that by 2025 nearly half of cyber security leaders would change jobs, with 25% moving into different roles entirely because of work-related stressors, and its analyst described burnout and voluntary attrition as "outcomes of poor organizational culture". Whatever the exact figure turned out to be, plan for key-person loss at the top as well. See the CISO Succession guide.
Toil, interruptions and focus time
Google's SRE book defines toil as work that is "manual, repetitive, automatable, tactical, devoid of enduring value, and that scales linearly as a service grows", sets a goal of keeping operational work "below 50% of each SRE's time", and warns that "Too much toil leads to burnout, boredom, and discontent." Security teams generate toil in the same way: manual enrichment of every alert, copy-and-paste ticket updates, recurring evidence requests, hand-built reports, manual access reviews and repeated vulnerability exceptions.
- Measure the share: for four weeks, ask each person to tag their time as toil, incident or engineering work in broad blocks. Rough data is enough to show where the week goes.
- Set a cap: adopt an explicit target, for example no more than half of each role's time on toil, and treat a breach of the cap like a breached service level: it triggers automation work or a scope change.
- Fund automation from the cap: the reclaimed time goes to enrichment playbooks, auto-closure of known benign patterns, evidence collection automation and self-service for common requests. See the Detection as Code Guide.
- Batch interrupts: the SRE chapter on interrupts recommends making ticket handling "a full-time role, for an amount of time that's manageable for a person", and says the primary on-call engineer "should focus solely on on-call work". Apply this to security: one person on triage or request duty per shift, everyone else protected for project work.
- Price context switching: the same chapter advises to "Assign a cost to context switches". Ban ad hoc direct messages for routine requests and route them to the queue owned by the duty person.
Alert load and on-call as burnout drivers
Noisy detection is the most common chronic stressor in security operations because it combines high volume, low reward and fear of missing the one real event. Treat alert load as a workforce metric, reviewed with the same seriousness as coverage. The tuning methods themselves are covered in the Alert Fatigue Reduction Guide; the people-side rules are:
- Give pagers to rules, not people: every paging detection has a named owner who receives its false positive rate monthly and must tune or justify it.
- Separate paging from queueing: only alerts that need action within the hour page out of hours. Everything else waits for business hours.
- Make retirement easy: a responder can propose suppressing or retiring a rule with a short written reason, reviewed within a week, so frustration has a constructive outlet.
- Cap out-of-hours load: track pages per on-call shift and nights disturbed per person per month; when a threshold is crossed, the fix is tuning, more people or a managed service, not asking for resilience.
- Compensate on-call fairly: agree time off in lieu or payment in advance, and make swapping easy and visible.
For teams too small to share on-call sustainably, compare in-house, co-managed and outsourced models in the Co-Managed SOC and SOC-as-a-Service Guide.
Measuring burnout risk without intruding
Measure the conditions that cause burnout, aggregated at team level, and pair them with a periodic survey. Never use these numbers to rank individuals.
| Metric | Source | Warning signal |
|---|---|---|
| Toil share by role | Time tagging sample, quarterly | Above the agreed cap for two consecutive quarters |
| Out-of-hours pages per on-call shift | Paging platform | Rising trend, or nights disturbed for most of a rotation |
| Alert-to-action ratio | SIEM or SOAR case data | Most alerts closed without action for a given rule set |
| Queue age | Ticketing system | Oldest items growing month on month (vulnerabilities, access requests, detection backlog) |
| Leave taken and carried over | HR, aggregated | Large unused leave balances in the security team compared with other functions |
| Voluntary leavers and regretted leavers | HR, aggregated | Leavers clustered after audit seasons, reorganisations or long incidents |
| Single points of failure | Skills matrix | Any critical skill held by one person |
For the survey, the HSE publishes a free Management Standards Indicator Tool with an Excel analysis tool, built around the six areas above. In Great Britain the HSE states that employers must assess the risk of work-related stress and act on it, and in the EU, EU-OSHA explains that the Framework Directive 89/391/EEC requires workplace risks, including psychosocial ones, to be assessed and controlled. Running the survey annually, with results shared and actions agreed with the team, also creates the record an inspector or auditor would expect.
Prevention: a phased programme
The phases below are NHI Mgmt Group recommendations.
- Baseline (month 1): collect the metrics above for the last two quarters, run the indicator survey, and list single points of failure. Share the results with the team before acting.
- Quick relief (months 1 to 2): retire or demote the noisiest paging rules, move routine requests behind a queue, and confirm on-call compensation. These changes cost little and show the team the survey led somewhere.
- Job design (months 2 to 4): introduce triage or duty rotations so most people have protected project time each week; set the toil cap; write the service catalogue that defines what the team owns.
- Capacity (months 3 to 6): close single points of failure by cross-training, pairing and documentation; decide on managed services for out-of-hours or specialist work; make the case for headcount with the load data.
- Growth (ongoing): agree individual development plans with protected learning time; rotate analysts into detection engineering, threat hunting or automation projects for part of each quarter.
- Review (every quarter): re-measure, publish the trend to the team and leadership, and roll back any change that increased load (for example a new tool that doubled triage time) rather than persisting with it.
Pilot job design changes with one team or shift first. If a duty rotation leaves gaps, adjust the rotation length before abandoning the model.
Decision guidance by team size
The levers below are NHI Mgmt Group recommendations.
| Team | Main burnout risk | Most effective levers |
|---|---|---|
| One to three people | Every role held by one person; permanent informal on-call | Written scope of what the team does not do; managed detection and response or retainer for out-of-hours; strict business hours for non-urgent work. See the MDR Guide. |
| Four to fifteen | Duty and project work mixed; one expert per domain | Daily or weekly duty rotation; toil cap; pairing to create deputies; alert ownership |
| Large or multi-site SOC | Shift work, repetitive triage, limited progression for tier 1 | Follow-the-sun to remove night shifts where possible; structured progression from triage to engineering; automation team funded from the toil budget |
| Security leadership | Accountability without authority; constant availability | Named deputy with real decision rights; board-agreed risk appetite so not every risk lands personally; protected leave with delegation |
Retention and recovery
- Stay conversations: ask people what would make them leave before they decide to. Common answers in security are no time to learn, unfair on-call, and no route out of triage.
- Career paths: publish how people move from analyst to engineer, hunter, architect or manager, and what each step requires. See the Cybersecurity Careers Guide.
- Recognition that reduces load: reward the person who automated a recurring task, not only the person who stayed up all night. Praising heroics teaches the team that overwork is the expectation.
- Returning after burnout: agree a phased return with HR and occupational health, start with project work rather than on-call, and review the conditions that led to the absence before the person returns to them.
- Exit data: run exit interviews through someone outside the reporting line and feed themes into the quarterly review.
- Hiring with honesty: describe the real on-call and alert load in job adverts and interviews. People who leave in the first year because the job was misdescribed add to everyone else's load. See the Cybersecurity Skills Gap and Hiring Guide.
Where identity fits
Identity operations generate a large share of security toil: manual access requests, recurring access reviews, password and MFA resets, and rotating service account credentials and API keys by hand. These tasks are repetitive, automatable and grow with the organisation, which is the SRE definition of toil. Automating joiner, mover and leaver flows and moving machine credentials to managed rotation removes work that otherwise lands on a small identity team or the SOC. See the Joiner-Mover-Leaver Guide and Credential Rotation at Scale.
Common failure patterns
- Wellbeing as a perk: resilience webinars and app subscriptions are offered while pages per shift keep rising. Individual support helps, but it does not change the demands that cause burnout.
- Measuring people instead of work: per-analyst closure counts become targets, which rewards closing alerts quickly over investigating them.
- Tool sprawl as a fix: a new platform is bought to reduce load but adds another console and migration without retiring anything.
- Survey without action: the team completes a stress survey, nothing changes, and the next survey response rate halves.
- Everything is security's job: without a service catalogue, the team absorbs questionnaires, access approvals and audit evidence for other functions.
- Leaders exempt themselves: the CISO and managers never take uninterrupted leave, signalling that nobody else should either.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RR-01 | Leadership fosters a risk-aware culture that is continually improving |
| NIST CSF 2.0 | GV.RR-03 | Adequate resources allocated commensurate with roles and responsibilities |
| NIST CSF 2.0 | GV.RR-04 | Cybersecurity included in human resources practices |
| NIST CSF 2.0 | PR.AT-02, ID.IM-03 | Training for specialised roles; improvements identified from operational processes |
| NIST SP 800-53 Rev. 5 | PM-13 | Security and privacy workforce development and improvement |
| HSE Management Standards | Six areas | Stress risk assessment structure for security teams in Great Britain |
| EU Framework Directive 89/391/EEC | Employer risk assessment duty | Psychosocial risks assessed and controlled like other workplace risks |
Practitioner checklist
- Collect toil share, pages per shift, queue age, leave balances and leaver data for the security team, aggregated.
- Run the HSE Indicator Tool or an equivalent survey annually and agree actions with the team.
- Assign an owner to every paging detection and review its false positive rate monthly.
- Separate paging from queueing so only urgent alerts reach people out of hours.
- Introduce a duty rotation so most people have protected project time each week.
- Set and track a toil cap, and use breaches to fund automation.
- Publish a service catalogue stating what the security team owns and what it does not.
- Name deputies for every critical skill, including the CISO.
- Publish career paths and protect learning time in every development plan.
- Report burnout risk metrics to leadership quarterly alongside detection and coverage metrics.
Standards and references
- World Health Organization: Burn-out an "occupational phenomenon": International Classification of Diseases
- HSE: What are the Management Standards?
- HSE: Management Standards Indicator Tool and downloads
- EU-OSHA: Psychosocial risks and mental health at work
- Google: Site Reliability Engineering, Eliminating Toil
- Google: Site Reliability Engineering, Dealing with Interrupts
- NIST: Cybersecurity Framework 2.0
- Gartner: Gartner Predicts Nearly Half of Cybersecurity Leaders Will Change Jobs by 2025
Related NHI Mgmt Group resources: Incident Responder Wellbeing · Alert Fatigue Reduction Guide · Building a SOC from Scratch Guide · Cybersecurity Careers Guide · MDR Guide