Burnout in security teams: a manageable operational risk

When people talk about burnout in security teams, the conversation tends to stay on individual wellbeing: breaks, talks on stress, an extra perk or two. All of that has its place, but it misses the main point. An exhausted team detects less, makes more mistakes and loses the people who know the environment best. That is an operational risk, and like any other operational risk it can be identified, measured and treated with controls.

This article looks at burnout from the operations side: what causes it in day-to-day security work, which indicators show that the workload is unsustainable and which concrete controls reduce it. It does not replace the work of Human Resources or occupational health; it complements it from the place where the workload is created.

What burnout is and what it is not

The World Health Organization includes burn-out in the International Classification of Diseases, ICD-11, under code QD85. ICD-11 was adopted in 2019 and comes into effect in January 2022. The WHO describes it as a syndrome resulting from chronic workplace stress that has not been successfully managed, characterized by three dimensions:

• Feelings of energy depletion or exhaustion.
• Increased mental distance from one's job, or feelings of negativism or cynicism related to it.
• Reduced professional efficacy.

Two clarifications from the WHO matter for this approach. First, it does not classify burn-out as a medical condition but as an occupational phenomenon, in the chapter on factors influencing health status. Second, the concept refers specifically to the work context. In other words, its origin lies in how work is organized, and that is where the organization can act.

A caveat: team leads do not diagnose anyone. If someone shows signs of struggling, the path is a respectful conversation and a referral to whatever occupational health or HR channels the organization has. What does belong to operations management is acting on the workload and the conditions that create it.

For a management framework, ISO 45003:2021 provides guidance on managing psychosocial risks within an occupational health and safety management system. It covers factors such as workload and work pace, working hours, role clarity and available support. It is a useful reference for giving the topic an owner, an assessment and follow-up, like any other risk.

Why it is an operational risk

In a security team, attention is part of the control. An exhausted analyst is not just a person having a hard time: it is a detection control running below its design. The effects fall into four areas:

• Degraded detection. With hundreds of non-actionable alerts per shift, the team learns to close them quickly. The alert that matters gets lost in the noise or is dismissed out of habit.
• More errors. The chapter "Being On-Call" in Google's SRE book notes that stress pushes people toward intuition and shortcuts instead of method. In security, that means badly applied containment, unreviewed urgent changes or escalations that never happen.
• Turnover. Experienced security profiles are hard to replace. Every unplanned departure opens a period of reduced coverage while the next person is found, hired and trained.
• Loss of knowledge. Much of a security team's useful knowledge is not written down: what is normal on each system, which false positive keeps recurring, whom to call. When the person leaves, that knowledge leaves too.

That is why the risk should be in the department's risk register, with an owner, indicators and controls, not just in hallway conversations.

Operational causes, symptoms and controls

The causes that weigh most are usually in the way the team operates, not in the people:

• Volume of non-actionable alerts. Rules nobody tunes, duplicate sources and alerts on technical causes that do not indicate a real incident.
• Poorly designed on-call. Rotations with too few people, back-to-back shifts, no compensation and no rest after a night of incidents.
• Repetitive manual work. Enriching every alert by hand, checking the same five consoles, copying data between tools. The SRE book calls this toil: manual, repetitive, automatable and without enduring value.
• Role ambiguity. It is unclear who decides on containment, who communicates, what belongs to security and what to infrastructure. Whoever is most available ends up doing everything.

The diagram shows how causes, symptoms and controls relate, and where to act.

Controls that reduce the workload

Reduce noise

Review each detection rule periodically: how many alerts it produced, how many led to real action and how many were false positives. Rules that never lead to action are tuned, grouped or retired, with the decision recorded. The same criterion we use for availability alerts applies here: page on symptoms with impact, not on every anomaly. We cover it in alerting without fatigue using SLOs.

Sustainable on-call rotations

Google's SRE book suggests as a reference that on-call should not exceed 25% of a person's time and that a 12-hour shift should handle no more than two incidents, because each one requires analysis and follow-up. The exact numbers depend on context, but the principle holds: on-call load has a ceiling, it is measured and, if it is consistently exceeded, it is corrected with more people in the rotation, less noise or a redistribution of services. It also helps to define rest after nights with incidents and clear compensation.

Automate repetitive work

Enriching alerts with inventory, reputation or identity data, opening the ticket with full context and running pre-approved standard containment actions are candidates for automation. To choose where to start without losing focus, treat these tasks as a backlog with an owner and a cadence, as we explain in governing the automation backlog.

Clear roles

NIST's NICE Framework (SP 800-181 Rev. 1) describes cybersecurity work as task, knowledge and skill statements. Using it as a common vocabulary helps write down what each role does, what it decides and what is not its job, and spot people who are piling up tasks from several roles without anyone having decided so.

Blameless postmortems

After each significant incident, a written analysis that looks for contributing causes without blaming people. It reduces the fear of making mistakes, which is itself a source of stress, and turns each incident into a concrete improvement. Actions should be logged in the problem record, as we describe in problem management.

Training and shared knowledge

A training plan with protected time, up-to-date runbooks and rotating responsibilities reduces dependence on a few people. It is the best defense against knowledge loss when someone leaves or is away.

Workload indicators and related controls

For the risk to be managed, it needs indicators. The table proposes an initial set. The thresholds are illustrative: each organization should set its own from its baseline.

Indicator	How to measure it	Warning sign (illustrative)	Related control
Alerts per shift and share with real action	Detection tool and tickets	Most alerts are closed with no action	Rule review and tuning
Off-hours pages per person	On-call tool log	For example, more than two interrupted nights per week	Redesign of the rotation and paging criteria
Time on repetitive manual tasks	Time log by category for a few weeks	Above the agreed cap, for example 50%	Automation backlog
Overtime and postponed vacation	Aggregated HR data	Rising trend over several months	Workload redistribution or added staff
Knowledge concentration	Runbooks and systems only one person can handle	Critical systems that depend on one person	Cross-training and documentation
Overdue postmortem actions	Problem record	Actions that repeat from one incident to the next	Review by the department's risk committee

Two precautions when measuring. Use data aggregated by team, not individual rankings; the goal is to see the system's load, not to monitor people. And when you use HR data, agree with HR and with whoever manages personal data protection what can be used and at what level of detail.

How to govern it

1. Record the risk in the department's risk inventory, with an owner in security leadership.
2. Set the baseline for the indicators over one or two months before changing anything.
3. Agree on thresholds and ceilings for workload with management, HR and occupational health.
4. Prioritize controls based on the causes that weigh most in your baseline, not on the tool at hand.
5. Review quarterly the indicators together with those for detection and response, so that the team's workload is read as part of the control's performance.

If your team is moving from a traditional administration model to reliability practices, many of these controls are already part of that transition; we describe it in from administrators to SRE. Before defining indicators that use people's data or changing on-call conditions, validate the approach with HR, Legal and the data protection officer.