The SOC Meaning Crisis
The SOC Meaning Crisis
By Julian Brownlow Davies | Meaning In the Signal, Week 7 | 5 May 2026
I have visited a reasonable number of security operations centres over the course of my career, in a reasonable spread of industries and geographies, and there is a particular quality to the good ones that I have come to recognise almost immediately upon walking in. It is not the technology - the screen density, the dashboard configuration, the tooling stack. It is the posture of the analysts. In the centres that are, in some meaningful sense, working, the analysts engage with the work. There is a quality of attention, of purposeful engagement with what the screen is showing them, that is hard to describe precisely but impossible to mistake once you have seen it.
In the centres that are not working - and I have visited rather more of those than I would prefer - there is a different quality altogether. The analysts are present. The screens are on. The alerts are flowing. But something is missing from the engagement: a quality of disconnection that I have, over time, come to identify as something considerably more serious than fatigue or boredom. It is the look of people who have learned, through accumulated experience, that what they do in response to what they see does not reliably change the outcome.
Martin Seligman, in a series of experiments conducted in the late 1960s that remain amongst the most cited and most uncomfortable findings in psychology, demonstrated that subjects who were repeatedly exposed to adverse stimuli they could not control eventually stopped attempting to escape those stimuli even when escape became possible. They had learned, empirically and correctly, that their actions did not matter - and that learning, once embedded, proved remarkably resistant to revision. He called this learned helplessness, and whilst his original experiments were conducted on dogs in laboratory conditions that would rightly face an ethics committee today, the subsequent body of research applying the concept to human performance in complex, ambiguous, high-stakes environments is both extensive and, applied to the modern SOC, rather troubling.
I consider the security operations centre one of the most important and one of the most underserved institutions in the industry. And I think we are, systematically and largely without realising it, inducing learned helplessness in the people who staff them.
The Alert Economy and What It Has Built
The modern SOC was designed around a detection problem. The task, as originally conceived, was straightforward in principle if difficult in practice: monitor the environment for signals indicating adversarial activity, triage those signals, escalate the credible ones, and close the noise. The analyst’s role was, in essence, to be the human in a human-machine loop - bringing judgement, context, and investigative capacity to the signals that automated detection could surface but not interpret.
That model was already under pressure a decade ago. What has happened since is not an incremental increase in the volume of alerts requiring human attention but something qualitatively different - a structural transformation in the relationship between signal and capacity that I described in the second essay in this series as a constraint shift. The bottleneck in security operations is no longer the ability to detect. It is the ability to comprehend: to determine, from an environment generating tens of thousands of findings across vulnerability management, threat intelligence, SIEM, EDR, cloud security posture management, and a lengthening list of additional sources, which of those findings actually matters, in this environment, to this organisation, this week.
The analyst sitting at a console in 2026 is not doing the job the SOC was designed for. They are doing something considerably harder: applying finite human cognitive capacity to an effectively infinite stream of technically valid signal, in an institutional environment that measures performance by throughput - tickets closed, alerts triaged, mean time to respond - rather than by the quality of the comprehension those metrics are supposed to proxy.
The research on what this does to people is not obscure. ESG and ISSA’s annual “Life and Times of Cybersecurity Professionals” study, which has tracked the wellbeing and working conditions of security practitioners for nearly a decade, has consistently found burnout rates in the industry that would be alarming in any other professional context, with SOC roles and incident responders disproportionately represented in the most severe categories. The specific causal mechanisms cited - sustained overload, unclear impact, limited agency - are the conditions that Seligman identified as generative of learned helplessness half a century ago, which should give us some pause about whether the interventions currently fashionable in the industry (more tooling, better playbooks, SOAR automation) are addressing the actual problem. Alert fatigue is not primarily a workload problem. It is a meaning problem - and treating it as the former, as most organisations do, leads to interventions that address the symptom whilst leaving the underlying condition entirely intact.
What Learned Helplessness Looks Like In a SOC Context
Seligman’s learned helplessness, applied to the SOC, does not look like analysts refusing to work. It looks considerably more subtle, and considerably more damaging, than that.
It looks like an analyst who has learned, through experience, that escalating a finding rarely produces a material change in the organisation’s posture. The finding gets documented. It enters a remediation backlog. The backlog is reviewed at the next change management window, or the one after that, or the quarterly risk review. Meanwhile the environment has changed, the vulnerability has either been exploited or hasn’t, and the analyst is already three hundred alerts further down the queue. The feedback loop that should tell the analyst whether their judgement was correct - whether this was the one that mattered, or wasn’t - either never arrives or arrives so attenuated by time and organisational complexity that it can no longer inform future decisions.
It looks like an analyst who has calibrated their escalation threshold not to the actual risk represented by a finding but to the threshold at which escalating is worth the cost - the pushback from engineering, the challenge from the CISO’s office, the implication that the alert was noise and the analyst should have known better. I have seen this calibration happen in organisations whose security leadership would be genuinely horrified if they understood it was occurring: a systematic, rational, unconscious adjustment of human behaviour in response to an environment in which the consequences of over-escalating (friction, criticism, wasted capacity) are more immediate and more personal than the consequences of under-escalating (a breach that may or may not be attributed to this decision, months from now, if at all).
It looks like a team that processes rather than investigates. Processing is the application of a triage workflow to an alert: categorise, document, close or escalate according to the decision tree. Investigation is the application of curiosity and analytical capacity to a question: what is this, what does it mean, what would an adversary do with it, and what do I need to understand about our environment to answer that question well? The first is a cognitive activity that can be automated, at least partially, because it is essentially rule-following. The second cannot, because it requires the kind of contextual reasoning - what do I know about this asset, this user, this pattern of behaviour, the threat actors relevant to this sector - that remains genuinely human. The tragic irony of the modern SOC is that the automation we have invested in to address the capacity problem has largely automated the investigation activity and left the processing activity to the analysts, precisely inverting what we should want.
The SOAR Problem: Automation Without Understanding
I want to dwell on SOAR for a moment, because I think it represents the most significant misapplication of the right idea in recent SOC history, and I include myself in having contributed to that misapplication in various advisory capacities over the years.
Security Orchestration, Automation and Response was conceived as a force multiplier for the analyst: take the repetitive, rule-based elements of alert triage and automate them, freeing the human to focus on the judgement-intensive work that automation cannot perform. This is a genuinely good idea, and SOAR platforms at their best deliver something like this - reducing mean time to respond on commodity alert types, enforcing consistent process hygiene across a large team, and allowing analysts to direct their attention to the cases that actually require it.
What SOAR has frequently become in practice is something more problematic: a system that automates not just the repetitive elements of triage but the comprehension step as well - replacing the analyst’s judgement with a playbook’s decision tree and measuring success by the proportion of alerts that close without human involvement. The metric sounds like efficiency. What it is, in many cases, is a formalisation of the failure to investigate: a process optimised for throughput that treats every alert as a classification problem rather than an intelligence problem, and closes cases at the rate the playbook permits rather than the rate that genuine understanding would support.
The concern I hold - and I acknowledge it is more empirical observation than formally published finding - is that automation reduces the investigative depth of analyst engagement with alerts over time, with particular consequences for the capability of more junior analysts who are in the earlier stages of building the contextual knowledge that good threat analysis requires. A junior analyst who spends their formative years running playbooks is learning a different set of skills than one who spends those years investigating alerts with guidance from experienced colleagues. We are, in the name of efficiency, building SOC teams that are increasingly skilled at running playbooks and decreasingly skilled at the investigative reasoning those playbooks were supposed to support.
The Throughput of Meaning, Not the Throughput of Alerts
The constraint, as I have argued throughout this series in various forms, is comprehension. In the SOC context, this means something specific: the rate at which an analyst can move from raw alert to a reasoned, contextualised understanding of what that alert represents for this environment, and what - if anything - should be done about it.
That rate is not primarily a function of tooling. It is a function of the analyst’s knowledge of the environment they are monitoring - the crown jewels, the attack paths, the adversary profiles relevant to the sector and geography, the history of the environment and what has and has not proven significant before. It is a function of the feedback systems that tell analysts whether their judgements were correct and why. It is a function of the organisational culture that surrounds the escalation decision: whether escalating an uncertain finding is treated as good security instinct or as an admission of failure.
There is a pattern I have observed - and which the broader literature on high-stakes decision-making under uncertainty documents in various professional contexts, from aviation to intensive care - in workers who operate under conditions where the right action is genuinely unclear and the consequences of being wrong are personal and immediate. An analyst who has learned that their judgement is consistently second-guessed, that the escalations they feel most confident in are most frequently dismissed, and that their performance is measured by metrics that do not reflect the quality of their analytical reasoning is an analyst who is, in Seligman’s terms, acquiring the empirical evidence they need to stop trying.
This is not a technology failure. It is a leadership failure, a measurement failure, and an institutional design failure - and it sits, in my view, at the intersection of everything this series has been arguing about the mismatch between where the industry has invested and where the actual constraint lies.
What the Meaning-Centric SOC Looks Like
I am going to stop short of a complete framework here, partly because that is the work of a later essay in this series and partly because the specific implementation varies considerably by organisation, maturity, and context. But I want to sketch the shape of what I consider a more defensible approach, because the argument I have been making implies a set of practical changes that are worth naming.
The first is a shift in what we measure. If meaning is the constraint, then throughput of meaning - the rate at which the SOC develops a contextualised, reasoned understanding of the threat environment - is the metric that matters. This does not fit neatly into a dashboard. It is harder to report to a board than mean time to detect or mean time to respond. But it is the thing that actually predicts whether the SOC will catch what matters, and the absence of a clean metric is not a reason to avoid measuring it.
The second is a deliberate investment in the contextual knowledge that makes comprehension possible. An analyst who knows which assets in the environment carry disproportionate strategic value, who understands the threat actor profiles most relevant to the organisation, and who has a working model of the most plausible attack paths in the environment is an analyst who can make a much faster, much more reliable triage decision than one who is reasoning from generic threat feeds and a configuration management database. Most SOC training programmes develop technical skills. Very few develop this kind of contextual knowledge, because it requires investment from the business in sharing information that security teams frequently do not have access to.
The third, and in some ways the most important, is attention to the feedback loop. The analysts who maintain their investigative engagement over time in high-volume environments are, in my observation, almost uniformly the ones who receive consistent, timely, specific feedback on whether their judgements were correct and why. The feedback loop that connects an escalation to its outcome - whether the finding was significant, what the remediation achieved, whether the adversary progressed or was contained - is what prevents the empirical accumulation of helplessness. Without it, the most talented analysts will, rationally and correctly, conclude that their judgement does not change outcomes. And they will be right.
The Cost We Are Not Counting
The industry counts the cost of breaches. It counts the cost of talent - the well-documented difficulty of hiring and retaining qualified security professionals in a market where demand has outpaced supply for the better part of two decades. What it does not count, at least not systematically, is the cost of the meaning deficit in human terms: the loss of investigative depth as experienced analysts disengage from the reasoning-intensive work, the accelerated attrition of precisely the people whose contextual knowledge is most valuable and least replaceable, and the quiet normalisation of a standard of practice in which processing replaces investigation and throughput replaces comprehension.
Those costs are real, and they compound. An analyst who leaves takes their environmental knowledge with them. An analyst who stays but disengages - who has learned, in Seligman’s terms, that the effort is not worth the outcome - is in some respects more costly still, because their presence provides an organisational reassurance that is not matched by the investigative capacity it implies.
The signal the SOC generates is abundant. The meaning it extracts from that signal is increasingly scarce. And the reason it is scarce is not, primarily, that we lack the technology to generate it. It is that we have built institutions, measurement systems, and incentive structures that systematically discourage the humans best positioned to provide it from doing the work.
The analysts in your SOC are making decisions under uncertainty, in high volume, with limited feedback, in an environment optimised for throughput rather than comprehension. If you were designing those conditions deliberately - to produce learned helplessness rather than investigative expertise - what, precisely, would you do differently?