Join our Newsletter — 33% off our NHI Course
Home› Guides› Burnout in Security Teams: Recognition, Prevention and Recovery
Guide Security Careers

Burnout in Security Teams: Recognition, Prevention and Recovery

PDF for newsletter subscribers · free to read online

← All guides
By NHI Mgmt Group, edited by Lalit Choda Updated 12 November 2026 14 min read
On this page

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 dimensionHow it shows in security teamsOperational consequence
ExhaustionAnalysts closing alerts on first glance; engineers no longer volunteering for on-call swaps; frequent short absencesTrue 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 businessFindings not escalated; weaker relationships with IT and engineering owners
Reduced professional efficacyDetection backlog grows; runbooks go stale; people stop learning new toolingCoverage 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 areaSecurity-specific driverTypical 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 closeToil 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 changesGive responders authority to suppress or retire noisy detections through a reviewed process
SupportSingle experts for identity, cloud or forensics; no mentor for new analystsSkills matrix with named deputies; pairing; budget for training time
RelationshipsBlame 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 requestWritten service catalogue stating what the team does and does not own
ChangeTool migrations, reorganisations and outsourcing announced without consultationInvolve 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:

  1. 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.
  2. Separate paging from queueing: only alerts that need action within the hour page out of hours. Everything else waits for business hours.
  3. 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.
  4. 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.
  5. 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.

MetricSourceWarning signal
Toil share by roleTime tagging sample, quarterlyAbove the agreed cap for two consecutive quarters
Out-of-hours pages per on-call shiftPaging platformRising trend, or nights disturbed for most of a rotation
Alert-to-action ratioSIEM or SOAR case dataMost alerts closed without action for a given rule set
Queue ageTicketing systemOldest items growing month on month (vulnerabilities, access requests, detection backlog)
Leave taken and carried overHR, aggregatedLarge unused leave balances in the security team compared with other functions
Voluntary leavers and regretted leaversHR, aggregatedLeavers clustered after audit seasons, reorganisations or long incidents
Single points of failureSkills matrixAny 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.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.

TeamMain burnout riskMost effective levers
One to three peopleEvery role held by one person; permanent informal on-callWritten 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 fifteenDuty and project work mixed; one expert per domainDaily or weekly duty rotation; toil cap; pairing to create deputies; alert ownership
Large or multi-site SOCShift work, repetitive triage, limited progression for tier 1Follow-the-sun to remove night shifts where possible; structured progression from triage to engineering; automation team funded from the toil budget
Security leadershipAccountability without authority; constant availabilityNamed 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

FrameworkReferenceRelevance
NIST CSF 2.0GV.RR-01Leadership fosters a risk-aware culture that is continually improving
NIST CSF 2.0GV.RR-03Adequate resources allocated commensurate with roles and responsibilities
NIST CSF 2.0GV.RR-04Cybersecurity included in human resources practices
NIST CSF 2.0PR.AT-02, ID.IM-03Training for specialised roles; improvements identified from operational processes
NIST SP 800-53 Rev. 5PM-13Security and privacy workforce development and improvement
HSE Management StandardsSix areasStress risk assessment structure for security teams in Great Britain
EU Framework Directive 89/391/EECEmployer risk assessment dutyPsychosocial 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

Related NHI Mgmt Group resources: Incident Responder Wellbeing · Alert Fatigue Reduction Guide · Building a SOC from Scratch Guide · Cybersecurity Careers Guide · MDR Guide

PDF for subscribers

Take this guide with you

Every section, table and checklist in one PDF, with links to the sources and related guides. Subscribe to our weekly NHI & AI Identity Journal and we’ll email you a download link.

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Researched and written by the NHI Mgmt Group editorial team using AI tools, under the editorial direction of Lalit Choda. Facts are drawn from the sources listed on this page and checked by our automated quality process. Last updated 12 November 2026. Spotted an error? Use our contact page.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM and Agentic AI security. nhimg.org

PDF Downloads for Newsletter Subscribers

Get the guide

Enter your details and we’ll email you a download link.

The full guide is free to read online. The PDF is a thank you for subscribing.

Fill in all fields marked * and tick the PDF box to continue.