Most work tells you how you did. A salesperson learns within weeks whether the approach is working. A chef finds out the same evening. Code either runs or does not. The information arrives quickly, it points at the thing you actually did, and you adjust.
Security does not work like this. Doing it well produces nothing happening. Doing it badly also produces nothing happening, for months or years, until one day it produces something very loud. The signal that tells you which situation you are in does not arrive on any useful schedule, and when it finally does, it arrives as a catastrophe rather than as a correction.
This is not a complaint about the field. It is a structural feature of it, and psychologists have a precise name for the problem.
Robin Hogarth and colleagues drew a distinction between two kinds of learning environment, set out in a 2015 paper in Current Directions in Psychological Science. In a kind environment, as they put it, "feedback links outcomes directly to the appropriate actions or judgments and is both accurate and plentiful." In a wicked one, "feedback in the form of outcomes of actions or observations is poor, misleading, or even missing."
Chess is kind. You lose, and the loss is caused by your moves. Weather forecasting is kind, which is why forecasters are unusually well calibrated. Emergency medicine is reasonably kind. The patient improves or does not, and it happens in front of you.
Security is wicked in almost every respect. The outcomes are rare, so there is little to learn from. They are delayed, often by years between a decision and its consequence. They are noisy, because whether you are attacked depends heavily on factors you do not control. And they are frequently invisible, since a breach that is never detected produces no feedback at all, which is a category of failure most fields do not have to contend with.
Daniel Kahneman and Gary Klein, who disagreed about most things regarding expert intuition, published a joint paper in 2009 setting out the conditions under which it can develop at all. Evaluating the likely quality of an intuitive judgment, they wrote, requires assessing both the predictability of the environment and the individual's opportunity to learn its regularities. Security reliably supplies neither.
This has an uncomfortable consequence that extends well beyond security.
In fields where feedback is poor, years of experience do not reliably produce better performance. This is well documented. A 2014 paper in American Psychologist examining expertise among psychotherapists concluded that "there is no demonstration of accuracy and skill that is associated with experience as a therapist," and attributed this directly to "therapists' lack of access to quality outcome information regarding their interventions." Anders Ericsson, reviewing the broader evidence in the Cambridge Handbook of Expertise and Expert Performance, noted that the length of training and professional experience of clinical psychologists is not related to their success in treating patients, and that in some domains, including the reading of certain medical images, accuracy declines with years of experience rather than improving.
The mechanism is not mysterious. Experience converts into skill through a loop: you act, you observe the result, you adjust. Remove the middle step and the loop does not close. What accumulates instead is confidence, which grows with time regardless of whether accuracy does.
For security this means something specific. An organization that has run the same way for ten years without an incident has not necessarily learned anything in those ten years. It has ten years of the same year.
Here is where the reasoning most often goes wrong, and it is a very human error rather than a technical one.
Most organizations treat the absence of a breach as confirmation that their approach is sound. It is the only available signal, so it gets read as a result. But an organization that has never been breached may have excellent practice, or may have had ordinary practice and good luck, and nothing in its own experience distinguishes those two situations.
This has a name. Outcome bias is the tendency to judge the quality of a decision by how it turned out, rather than by whether it was a sound decision given what was known at the time. A well-reasoned decision that ends badly gets marked down. A reckless one that happens to work gets marked up. The reasoning is the same in both cases; only the result differs.
It was first demonstrated in a 1988 study by Jonathan Baron and John Hershey. Participants read a description of a medical decision and rated its quality. The information available to the decision-maker was identical across conditions. Only the outcome differed. The ratings tracked the outcome rather than the reasoning.
A 2023 replication with nearly 700 participants found the effect substantially larger than the original, and found something more troubling. It persisted even among participants who had explicitly stated that outcomes should not be taken into account when evaluating decisions.
Knowing about the bias does not switch it off. Which means an organization cannot reason its way out of this by being careful. It has to build something.
This is the reframing that makes the rest of it useful.
Restore testing, incident response exercises, penetration tests, post-incident reviews, and near-miss reporting are usually taught as five separate items on a list of good practice. They are not five things. They are one thing, applied in five places: deliberately generating a signal where the environment does not supply one.
Testing a restore tells you today whether your backups work, instead of finding out during a ransomware incident. An incident response exercise tells you now whether people know their roles, instead of at three in the morning. A penetration test produces an attack you can learn from, on a schedule you chose, with a report at the end. A post-incident review converts one rare event into durable knowledge instead of letting it disappear into everyone's memory. A reporting channel turns near-misses, which are ordinarily invisible, into data.
Seen this way, none of these are chores that a diligent organization performs. They are the only mechanism by which a security programme can learn anything at all.
National frameworks have started saying this outright. The US Cybersecurity Framework, revised in 2024, includes among its outcomes that "improvements are identified from security tests and exercises." The UK's Cyber Assessment Framework devotes a principle to lessons learned, requiring that post-incident analysis examine "plausible, alternative circumstances," which is to say the things that nearly happened rather than only the things that did.
The best evidence for all of this comes from an area most organizations treat as a training exercise rather than a feedback question.
Two large studies have now examined simulated phishing programmes rigorously. A 2022 study followed more than 14,000 employees over fifteen months. A randomized controlled trial published in 2025 covered more than 19,500 employees across eight months and ten campaigns. Both reached the same conclusion about the training component: it does not work. The 2025 authors found "no significant relationship" between recent training and likelihood of failing a simulation, and concluded that such programmes "in their current and commonly deployed forms, are unlikely to offer significant practical value in reducing phishing risks." The 2022 study went further and found the embedded training could have "unexpected side effects that can make employees even more susceptible."
But the same 2022 study found something that did work, in the same organization, with the same people. When employees were given a straightforward way to report suspicious messages, they became, in the authors' words, a "collective phishing detection mechanism." Reporting allowed fast detection of new campaigns, the operational load was manageable, and participation held up over time.
Consider what separates those two results. The intervention that failed delivered feedback to the individual, often with an implicit reprimand attached. The intervention that succeeded built a feedback channel for the organization.
This matches what is known about feedback generally. A 1996 meta-analysis in Psychological Bulletin covering 131 studies found that feedback interventions improved performance on average, but that over 38% of measured effects were negative. Feedback made things worse more than a third of the time. The conditions under which it backfired were specific: when it drew attention to the person rather than the task, when it was normative or comparative, and when it was designed to praise or to discourage rather than to correct.
There is a well-known illustration of this problem in Daniel Kahneman's Thinking, Fast and Slow. Teaching flight instructors in the Israeli Air Force, he argued that rewarding good performance was more effective than punishing bad. An experienced instructor disagreed, and did so from direct experience. When he praised a cadet for a clean maneuver, the next attempt was usually worse. When he shouted at a cadet for a poor one, the next was usually better. In his observation, praise made pilots worse and criticism made them better.
The instructor had observed accurately and concluded incorrectly. An unusually good performance tends to be followed by a more ordinary one, and an unusually bad one is followed by a more ordinary one too, because in both cases some of what happened was luck rather than skill. Regression toward the average produced the entire pattern. The praise and the shouting had nothing to do with it.
What makes the story useful here is that the feedback was not missing. It arrived promptly, it was accurate as far as it went, and it confirmed the wrong conclusion every single time. This is the second kind of wicked environment: not the absence of a signal, but the presence of a misleading one.
The security version is familiar to anyone who has watched it happen. An employee clicks a simulated phishing email, receives a reprimand, and does not click the next one. The reprimand appears to have worked, and everyone involved becomes slightly more confident that this approach is correct. The same outcome would have occurred had nobody said anything, and in the meantime that employee has become less likely to report the next thing they notice.
The organization has not learned that punishment works. It has learned that it is difficult to tell.
The UK's National Cyber Security Centre reaches the same conclusion in plainer language. Its guidance on phishing states that "blaming users for clicking on links doesn't work," warns that "users who fear reprisals will not report mistakes promptly, if at all," and recommends measuring reports rather than clicks, on the grounds that metrics express an organization's values.
That last point is worth sitting with. The metric you choose is not a measurement of the feedback loop. It is the feedback loop.
Aviation built the system security has not.
The Aviation Safety Reporting System has been running since 1976. It is voluntary, confidential, and non-punitive, and it has collected over 2.3 million reports and issued more than 8,000 safety alerts. Its design details are the interesting part. Reports go to NASA, a scientific agency with no enforcement authority, rather than to the regulator. Identifying information is stripped. Filing a report within ten days provides a waiver of sanction for inadvertent violations, though not for deliberate ones, criminal offences, or accidents.
Every one of those choices exists to solve the same problem: people do not report things that will be used against them. The system is not built on the assumption that professionals are forthcoming. It is built on the assumption that they are not, unless the structure makes it safe to be.
Security has no equivalent. A group of researchers and practitioners proposed one in 2018, observing that "in cybersecurity, we do not have such a system, but we do have a lot of accidents." Nothing comparable has been built since.
There is one complication worth noting, and it comes from NASA itself. The agency cautions that because its reports are voluntary and uncorroborated, "the existence in the ASRS database of reports concerning a specific topic cannot be used to infer the prevalence of that problem." The most mature manufactured feedback system in the world explicitly disclaims the ability to measure rates.
That is not a failure of the system. It is a limit on what manufactured feedback can do. It solves the problem of having no information. It does not solve the problem of that information being representative. An organization that builds a reporting channel will learn about the incidents that get reported, which is an enormous improvement over learning about none, and is still not the same as knowing what is happening.
There is a version of competence that comes from doing something for a long time, and a version that comes from finding out how it went. In most work these arrive together and are easily mistaken for each other. In security they come apart, and the first can accumulate indefinitely without the second ever appearing.
Which suggests that the useful question about a security programme is not how experienced the people are, or how much has been spent, or how long it has been since anything went wrong. It is a narrower question, and an uncomfortable one: what does this organization actually find out, how often, and how did it arrange to find it out?
An organization that can answer that is learning. One that cannot is accumulating time, and will discover the difference on a day it did not choose.
