Humility and the Reporting Culture — Why People Don't Report the Click

This module adapts the CEO course's humility module to the one executive whose entire function runs on other people's willingness to confess. A CEO who is not told the truth makes worse strategy. A CISO who is not told the truth has no detection layer, because the first sensor in most incidents is a human being who clicked, misconfigured, or noticed something odd and decided whether to say so.

FRAMEWORK Executive humility, for the technology leader, is three things a colleague could observe: accurate self-assessment of what you and your program actually know; openness to corrective information, especially the kind that embarrasses your own architecture; and acknowledgment of expertise in others — the claims processor who knows how the fraud emails really look, the engineer who knows which control is theater. It is not deference on risk, not saying yes to the business, and not a softer tone of voice.

The module explains why blame reduces reporting, why the compliance research says the levers you control most directly matter least, and how to build the Information-Environment Stack — five mechanisms that make bad news travel faster.

In the Effectiveness Equation — Traits × Behaviors × Organizational Context × Current Moment — this module changes the Behaviors term. The reporting culture you produce is a set of behaviors people copy. The Two-Sentence Test and the Risk Corollary depend on it: you cannot say "I was wrong about that risk" if nobody told you the control failed.

A security program is only as good as the worst thing someone was willing to tell you; humility is how you find out sooner.

Every control you buy sits behind a human decision to report. The click, the shared password, the firewall rule that opened a port — each is known to someone before it is known to you, and the interval between those two moments is where breaches become expensive. Humility, in the operating sense defined here, is the executive behavior that shortens the interval.

RESEARCH FINDING The anchor study is Edmondson (1996), and it is counterintuitive on purpose. In eight nursing units across two hospitals, with 146 respondents, units with stronger team climates and more active nurse-manager coaching showed higher detected drug-error rates — the correlation between manager coaching and detected errors was r = .74, and with intercepted errors r = .71. Edmondson's interpretation is that the better-led units were not more dangerous; they were more willing to report and discuss errors. The study is small, correlational, in healthcare rather than security, and the error rates come from reporting systems that are themselves shaped by climate — which is the paper's point. What it supports: a low incident count is ambiguous, and a security leader must read reporting numbers with the reporting climate in mind. What it cannot support: any specific ratio, or that coaching causes reporting.

RESEARCH FINDING Edmondson (1999, from the CEO library) formalized the construct. In 51 teams at one US office-furniture manufacturer, with surveys of 427 team members and 135 external observers, team psychological safety — a shared belief that the team is safe for interpersonal risk taking — was associated with learning behavior (seeking feedback, discussing errors, experimenting), which predicted team performance; leader coaching was an antecedent. Single company, cross-sectional, and the author says causality cannot be established. But it names the mechanism a CISO needs: people discuss errors when it is safe to.

RESEARCH FINDING Two CEO-library studies describe what happens when it is not safe. Milliken, Morrison and Hewlin (2003) interviewed 40 employees across industries: 85% recalled at least one occasion on which they felt unable to raise an important issue with a superior; the dominant reasons were fear of being labeled negatively and of damaging relationships, then perceived futility and fear of retaliation; and 74% of those who stayed silent said colleagues who knew of the same issue also stayed silent. Detert and Edmondson (2011), across four studies — 190 interviews at a high-tech firm, 185 executive-education participants, 265 online and MBA respondents, and a three-wave study of 116 executive MBAs — identified five "implicit voice theories": the boss will take it personally; you need solid data or a solution first; don't bypass the boss; don't embarrass the boss in public; speaking up damages careers. These beliefs predicted silence over and above personality and context, and persisted even where the environment was objectively safe. INTERPRETATION Map the five theories onto a phishing click and you have the reporting problem in full: "I need to be sure it was malicious before I bother the SOC"; "reporting my own click makes me look careless"; "my manager will hear." The employee who clicked has every reason to wait.

RESEARCH FINDING Cram, D'Arcy and Proudfoot (2019) is the largest synthesis of what predicts security-policy compliance: a meta-analysis of 95 papers across 17 antecedent categories. The strongest predictors were value-oriented — attitude, personal norms and ethics, and normative beliefs. Punishment and rewards, the levers management controls most directly, were among the weakest; training and perceived usefulness fell in the middle. The underlying studies are largely survey-based, measure intention more often than behavior, and yield correlational effect sizes. What it supports: sanctions are a weak instrument, and a punitive phishing program spends on the lever the evidence rates lowest. What it cannot support: that removing sanctions raises compliance, or anything about reporting specifically, which the meta-analysis did not measure.

RESEARCH FINDING Ashenden and Sasse (2013) interviewed five CISOs in depth. The CISOs described their own obstacles as "a perceived lack of power, confusion about their role identity, and their inability to engage effectively with employees." Five UK interviews — illustrative, not generalizable. What it supports: the reporting problem is partly a relationship the CISO has failed to build, in the CISOs' own account.

RESEARCH FINDING The humility evidence is from the CEO library. Ou, Tsui, Kinicki, Waldman, Xiao and Song (2014, from the CEO library), in 63 private Chinese companies with data from 328 top-team members and 645 middle managers, defined CEO humility as self-awareness, openness to feedback, appreciation of others, low self-focus and self-transcendent pursuit, and found it associated with empowering leadership and top-team integration. Ou, Waldman and Peterson (2018) found in 105 US software and hardware SMEs that CEOs rated more humble by their teams had more integrated teams, associated with more ambidextrous strategy and better performance. Owens and Hekman (2012), from 55 leader interviews, induced three observable behaviors — admitting limits and mistakes, spotlighting others' strengths, modeling teachability — with two contingencies: humility works only from a leader perceived as competent and sincere, and it appears less effective under extreme threat or time pressure. Owens and Hekman (2016), across 607 participants in 161 teams, showed leader humility spreads by contagion. All correlational or team-level except the 2016 program; none is about security leaders.

RESEARCH FINDING Two archival studies show reporting behavior is observable and priced at the firm level. Higgs, Pinsker, Smith and Young (2016) found over 2005–2014 that firms with board-level technology committees were more likely to report breaches, plausibly because they detect and disclose more. Amir, Levi and Livne (2018) found that attacks firms withheld and that were later exposed were associated with an equity decline of approximately 3.6% in the month of discovery, against 0.7% for firm-disclosed attacks. INTERPRETATION The same logic runs inside the firm: the click withheld and discovered later costs more than the click reported.

Where the evidence is weak

Nothing here measures the reporting climate inside a security function directly. Edmondson (1996) is about drug errors in eight units; the silence literature is not security-specific; the humility studies are about CEOs and teams; Cram et al. (2019) measures compliance intention, not reporting. The Information-Environment Stack is a FRAMEWORK no study tests. That a humble technology leader gets bad news faster is an inference the evidence supports strongly and no study has tested at CISO level.

Humility, defined for someone whose job is to say no

Nobody hires a CISO to be modest. FRAMEWORK Executive humility, for the technology leader, is three behaviors.

Accurate self-assessment — of the program, not just the person. What does your detection actually cover? Which controls on the board slide are substantive and which are symbolic? A CISO who says "we have MFA everywhere" when they mean "on the systems we know about" has failed the first test, and the failure is not modesty but arithmetic.

Openness to corrective information — wanting to hear the thing that contradicts your architecture, from the people least likely to bring it. The engineer who says the EDR agent is not on the finance file server. The claims supervisor who says her team shares a login because the workflow tool times out. The pen-tester who found what your own review missed.

Acknowledging expertise in others — treating the people closest to the work as sensors rather than as risks. The Ashenden and Sasse (2013) CISOs described themselves as unable to engage with employees; this behavior is the correction.

What it is not

INTERPRETATION Humility is not deference on risk. A humble CISO still says "No — and here is what would change my answer"; humility is about the accuracy of the price, not the softness of the delivery. It is not saying yes: the vCISO who grants the client's owner an MFA exception because the owner was insistent is conflict-avoidant, which is the Overuse Ladder's empathy rung. And it is not lack of confidence. The Owens and Hekman (2012) contingency cuts both ways: a visibly weak program cannot buy credibility with candor, and a strong one cannot keep it without candor.

Why blame reduces reporting

INTERPRETATION Put the silence research and the compliance research together and the mechanism is clear.

Every employee who clicks has, by Detert and Edmondson (2011), a set of learned rules about whether to say so, mostly learned somewhere else. A phishing simulation that publishes department results, a three-strikes policy, a manager told which of their people failed — each confirms the rules. The employee has a private fact (I clicked) and a public choice (do I tell?), and the organization has just made the public choice expensive.

Then add the executive's contribution, which Tourish and Robson (2006, from the CEO library) describe conceptually: the more committed a leader is to a course of action — "our awareness program works," "our architecture is sound" — the more they classify contrary information as noise. Employees read the signal. The result is an information environment both sides built and neither can see from inside.

The consequence is the Edmondson (1996) inversion applied to security. Your reported-click count falls. Your dashboard turns green. And your actual detection has moved from "a human tells us within minutes" to "the gateway logs it and someone eventually looks" — a change invisible in the metric that just improved.

The reported-to-detected ratio

FRAMEWORK The most useful number this module offers is the ratio of incidents reported by people to incidents detected by telemetry, tracked over time. If the gateway sees forty clicks on a lure in a month and eight are reported, the ratio is 0.2. If a policy change drives reported clicks to two while the gateway still sees forty, the ratio has fallen to 0.05 and your program has gotten worse while its headline number improved. Edmondson (1996) is the evidence that the count alone misleads; the ratio reads it correctly. Its denominator covers only what your telemetry sees — one more reason to want the numerator.

Why the levers you control matter least

INTERPRETATION Cram et al. (2019) is uncomfortable reading for anyone with a sanctions policy. The technology leader controls sanctions directly and norms only indirectly, through behavior — so the reporting culture is shaped less by the policy you write than by what people watched happen to the last person who reported. One punished messenger costs years. One visibly thanked messenger, in front of their manager, does more than a quarter of training modules. This is where humility stops being a nicety and becomes a control: the three behaviors above are the executive actions that move norms.

The Information-Environment Stack

FRAMEWORK Humility as a disposition is unreliable under pressure, and Owens and Hekman (2012) warn it is less effective in crisis — which is when a security function most needs it. So install it as mechanism. Five layers, built in order, each depending on the one below.

Near-miss reporting. A channel — one click, one message, no form — for "I think I did something" and "I noticed something," with an explicit statement that near-misses are wanted and a visible response to every one within a day. The near-miss is the cheapest information a program receives: the event happened, nothing was lost, the pattern is now known. Expect the count to rise; a rising near-miss count is the Edmondson (1996) signal of a healthier climate.

Blameless review. Every incident and near-miss reviewed for what the system allowed, not who failed. The rule is not "nobody is accountable"; it is "the reporter is not the subject of the review." Reckless or repeated conduct is handled separately, by management, and the boundary is stated in advance so that "blameless" does not become "consequence-free." The output is a change to a control or a default — and the reporter sees it.

Red-team standing. A person or contracted function whose job is to find what the program missed, with standing to present it to you unsoftened and, on a schedule, to your CEO or audit committee. The test is what happens when the findings embarrass your own architecture. If the answer is a smaller engagement next year, you do not have red-team standing; you have a vendor.

Engineer direct lines. Skip-level channels from the people who run the systems to the executive who owns the risk, with no agenda beyond "what would you fix, and what have you stopped mentioning?" — followed by visible action on something raised. Milliken et al. (2003) found the most-withheld issues concern competence and process failures. Those die in the layer between an engineer and a manager who owns the control.

The quarterly "what we got wrong." A short written account, from you, of the quarter's misses: the near-miss that should have been caught earlier, the control on the slide and not on the server, the risk you priced wrong. Sent to your CEO and, where the business allows, to the people whose reports made it possible. This is the top of the stack because it is the executive behaving the way the stack asks everyone else to behave — modeling how to grow, in Owens and Hekman's (2012) phrase. The engineer who watches the CISO write "I was wrong about that risk" learns what reporting costs here.

HYPOTHESIS A program with all five layers detects human-originated incidents earlier than an otherwise identical program without them, visibly in the reported-to-detected ratio within two quarters. Untested.

The fractional version

INTERPRETATION The vCISO or MSP leader has a harder version: the reporting culture belongs to the client, whose owner may be the person least willing to hear bad news. The stack still applies, scaled down — a near-miss channel to the MSP, a blameless review with the client's manager present, an annual pen-test reported to the owner in writing, a quarterly note on what the MSP got wrong. The last is commercially frightening and, in practice, valuable: a client told the truth about a miss trusts the next green dashboard more, not less.

Fictional composite. Harbor Point Business Services is a business-process and managed-services firm in Providence, Rhode Island, with $34M in revenue, 210 employees, and about 160 clients across the Northeast — registered investment advisers, two small broker-dealers, physician groups, law and accounting firms, a few regional retailers. Daniel Okafor is its CIO and CISO, a former network engineer who built the multi-tenant stack the firm runs its clients on and who leads a vCISO practice for around 40 of them.

Two years earlier, a tier-2 engineer had mis-scoped a firewall change on a client tenant, exposing a remote-desktop gateway for about three days before a routine scan caught it. The engineer received a written warning; the account manager told the client it was "a vendor-side configuration issue"; the engineer left within four months. The organization learned two things: configuration mistakes are career events, and clients are told a version. Near-miss reports afterward ran at two or three a quarter across 40 engineers making hundreds of changes a week. The dashboards were green.

Then, on a Thursday in March, Luis Ferreira, a tier-2 engineer nineteen months into the job, pushed a rule change on the tenant of Bramhall Securities, a 38-person broker-dealer and FINRA member. Forty-one hours later, reviewing logs for a different ticket, he saw brute-force attempts against a remote-desktop port that should not have been reachable. His change had opened it. He had, by his own account, about ten minutes of wanting to close the port quietly and say nothing. He closed the port, and then he messaged Daniel directly.

What Daniel did in the next 48 hours is the point. He thanked Luis in the message, then again at the next morning's stand-up in front of Luis's manager, and said why: forty-one hours of exposure with a report is a near-miss; forty-one hours with no report is a breach nobody knows about. He ran the review that afternoon with Luis present and with the rule that the subject was the change process, not the engineer. The review found no post-change external scan in the template, peer review skipped on "minor" rules with no definition of minor, and thirty days of client log retention — enough to see the attempts, not enough to be sure about the previous quarter. Three controls changed within two weeks. He then called Bramhall's managing principal and told him exactly what had happened, including the forty-one hours. The principal was angry for about ten minutes and then asked whether the same review would apply to his own staff. It did.

Over two quarters Daniel built the rest of the stack: a one-line near-miss channel in the engineering chat; blameless reviews with a stated boundary; an annual external pen-test whose lead presented to Harbor Point's CEO without Daniel in the room; monthly skip-levels with engineers; and a quarterly note to the CEO, later to the vCISO clients, titled "What we got wrong," which the sales team asked him not to send.

Near-miss reports went from three a quarter to nineteen. Reported phishing clicks doubled while detected clicks stayed flat — the ratio moved from roughly 0.2 to roughly 0.5. Two changes that would have exposed client data were caught by their own authors within an hour. One client questioned the quarterly note hard and stayed; two prospects cited it when they signed. Daniel's own read is that the program did not get more secure in those two quarters. It got more honest, which turned out to be the same thing measured later.

Take Harbor Point at the moment Luis Ferreira's message arrives.

The Technical CISO sees a configuration failure and fixes the configuration — thoroughly, quickly, personally. The change template gets a post-change scan by the end of the day. What the Technical CISO is less likely to do is the public thanks, the review with the engineer present, and the call that says forty-one hours out loud. The gain is a tighter control within hours. The cost is that the floor watches the CISO take the problem away from the person who reported it, and learns that reporting means losing ownership. The stack's bottom layer is never built because the leader is too capable to need it.

The Business-Risk CISO reads the event as a client-relationship and liability problem. The instinct is a well-managed disclosure: a controlled call, a written summary, an offer of a credit. Not wrong — Amir et al. (2018) suggest disclosure is priced better than concealment — but the Business-Risk CISO can run the external conversation well and leave the internal one untouched, treating the engineer's report as an input rather than the most valuable thing that happened that week. The gain is a retained client. The cost is a reporting culture that has not moved.

The Post-Breach CISO treats the near-miss as the breach they were hired to prevent. Centralize change approval, require sign-off on every rule, add a second reviewer. In a genuine post-breach turnaround this is right. Here it is the Overuse Ladder's rigor rung — the security review that ships nothing — imposed on a team that just demonstrated it will self-report. The cost is that the next engineer with a ten-minute window of wanting to say nothing does the math on the new process and says nothing.

The Regulated-Industry CIO/CISO asks the right first question — is this reportable, and what does the client's written supervisory procedure require? — and builds the review around the record. The gain is a defensible file for a FINRA member. The cost is a review written for an examiner rather than for engineers, in which the language of accountability quietly reintroduces the blame the review was meant to remove. The mature version holds both documents and knows they are different.

INTERPRETATION Daniel Okafor's response drew on all four and added the one thing none reaches for by default: he made the reporter the hero of the story, in front of the people who would decide whether to report next time.

FRAMEWORK Humility fails in both directions on the Overuse Ladder, and the technology executive is exposed to both.

Humility → excessive hesitation. The CISO who has learned to distrust their own numbers stops being able to state a position. Every board question gets "it depends"; every risk gets a range too wide to be a price; "Yes — and here is the risk, priced" never arrives. Owens and Hekman (2012) warn humility is less effective under time pressure; an incident is time pressure. The signal: incident calls where the executive asks questions for forty minutes and nobody has been told to isolate anything.

Empathy → conflict avoidance, dressed as humility. The leader who confuses openness with agreement. The client owner's MFA exception, the CFO's request to skip the vendor review, the engineering director's flat network — each accepted in the name of "acknowledging expertise in others." Acknowledging expertise is about information, not decision rights. The signal: an exception register that grows every quarter and is never reviewed.

"Blameless" → consequence-free. The security-specific rung. A blameless review is one in which the reporter is not the subject. It is not an organization where nobody is accountable for anything. Programs that lose this boundary produce a different silence: good engineers stop reporting because they have watched reckless ones report and nothing change. The signal: the same near-miss from the same source three quarters running.

Optimism → delusion, via the dashboard. The leader who never installed the stack: reported clicks fall, near-misses are rare, the pen-test is scoped to the systems the CISO trusts, and the board slide is green. Edmondson (1996) is why this is a failure mode rather than a success.

Early warning signs

• Near-miss reports are rare and stable in a function making hundreds of changes a week.
• Reported phishing clicks fell sharply after a program change, and nobody checked the telemetry.
• The last pen-test's scope was set by the executive whose architecture it tested.
• Engineers, asked what they have stopped mentioning, have an answer.
• The executive cannot name the last thing the program got wrong, unprompted.

1. What was the last thing an engineer or employee told you that contradicted your own architecture or program? How long after they knew it did you hear it, and what happened to them afterward?
2. Estimate your reported-to-detected ratio for last quarter. If you cannot, which number have you been managing instead?
3. Name a control that is on your board slide and, as far as you actually know, not fully on the servers. Who else knows?
4. When did you last thank someone publicly for reporting their own mistake? When was someone last disciplined for one? Which story does your organization tell?
5. Who has the standing to embarrass your architecture in front of your CEO? If nobody, is that because nobody is capable or because nobody is permitted?
6. Write the first three sentences of a "what we got wrong last quarter" note to your CEO. What did you leave out, and why? For the vCISO: which client has never been told about a miss, and what are you protecting?

• Executive humility for the technology leader is three observable behaviors — accurate self-assessment of the program, openness to corrective information, acknowledging expertise in others — and it is not deference on risk, saying yes, or self-deprecation.
• Blame reduces reporting through a known mechanism: learned implicit voice theories (Detert & Edmondson, 2011) confirmed by organizational sanctions, in a culture where most people already withhold important issues (Milliken et al., 2003).
• A low incident count is ambiguous; Edmondson (1996) found the better-led units reported more errors. Read reported clicks against telemetry with the reported-to-detected ratio.
• Sanctions and rewards are among the weakest predictors of compliance (Cram et al., 2019); norms are shaped by what people watch happen to reporters, which makes the leader's own behavior the strongest lever.
• Install humility as mechanism, not mood: near-miss reporting, blameless review with a stated accountability boundary, red-team standing, engineer direct lines, the quarterly "what we got wrong."