The trouble usually starts long before the incident review. Someone quietly notices that a critical system still depends on a shared admin account, or that customer data is being copied into an unvetted analytics workspace, or that a third-party integration is far more privileged than anyone remembers. They mention it in a hallway aside, maybe drop it in a Slack thread, and then stop. The risk is obvious, but so is the unwritten rule: do not be the person who makes this a “thing” unless you are ready to own it forever. On paper, the company has all the right policies. In practice, the culture says “don’t tell anyone.”
This Wednesday “Headline” feature from Bare Metal Cyber Magazine looks directly at that gap between stated values and lived behavior. It treats disclosure culture as a core part of your security architecture, not as a soft HR concern or a side effect of personality. Over the next few years, as environments get more distributed and dependencies less controllable, your real advantage will not come from yet another scanner. It will come from how quickly your people feel safe raising uncomfortable truths, and how reliably those signals turn into action rather than career risk.
For security and technology leaders, this is not a theoretical debate. A culture that punishes bad news guarantees late surprises with regulatory, contractual, and reputational cost. A culture that rewards early reporting still has incidents, but they are smaller, more contained, and less shocking. The shift from “don’t tell anyone” to “report early, fix faster” is ultimately a leadership decision: how you respond when someone surfaces an ugly issue, how you design the pipes that carry that signal, and what you choose to measure and celebrate. That is where the rest of this article will stay focused.
The Unspoken “Don’t Tell Anyone” Rule
In most organizations, the strongest security policy is not the one in the handbook; it is the one enforced by stories. People remember what happened to the engineer who raised a critical issue just before a big launch, or the analyst who flagged a risky vendor a week before contract renewal. Maybe that person was thanked in public but quietly sidelined, or buried in remediation work with no help. Those stories spread faster than any awareness campaign. They teach a simple lesson: you are safer keeping quiet, or raising issues only when consensus is already forming around them. The result is a shadow policy of silence that coexists with all your official “see something, say something” language.
This shadow policy shows up in small behaviors. A developer softens the language in a risk register entry so it does not “sound alarmist.” A product manager waits a sprint or two before logging a security concern, hoping it will resolve itself or become someone else’s problem. A cloud engineer sends a private message rather than opening a ticket, just to see how worried security really is. None of this looks like malice or negligence. It is self-preservation in an environment where the cost of being associated with a problem feels higher than the cost of leaving it partially hidden.
Leaders often underestimate how quickly the culture learns from their reactions. One combative response in a post-incident review, one executive who demands to know “who approved this” before understanding the context, one instance where early reporters are treated as convenient scapegoats, and the message is clear. Over time, people learn that you will tolerate risk more readily than you will tolerate discomfort. The official channels remain, but they are used as a last resort, not as a first line of defense. If you want a culture of disclosure, you have to start by acknowledging that this unspoken rule exists—and that it is the default state unless you actively replace it.
Why Smart People Sit on Bad News
When you talk to the people closest to the systems, very few of them are reckless. They see the risks. They understand the blast radius of that shared key, that overprivileged service account, that unpatched internet-facing app. The problem is not awareness; it is calculus. Reporting early often feels like volunteering for a second job with unclear support, unclear end date, and very clear visibility when things go wrong. Smart, ambitious people have learned to conserve their political and emotional energy for issues that leadership clearly cares about. Everything else gets parked in a personal notebook, a mental backlog, or a quiet side conversation.
The friction points are usually structural. Reporting channels are slow, noisy, or opaque, so a high-signal concern gets dropped into the same ticket queue as routine hygiene work and languishes there for weeks. Thresholds are fuzzy, so people are never sure whether a finding is “big enough” to justify escalation, especially if it might derail a roadmap commitment. Ownership models are muddled, meaning that whoever logs the issue risks becoming the de facto long-term owner, even if they lack authority to fix the underlying system. Add in performance frameworks that reward on-time delivery and smooth status reports, and the rational choice is to avoid being the source of disruptive truth.
Leaders also underestimate the social and political cost of making others look bad. An engineer who raises a risk in a shared system is, in practice, pointing toward someone else’s technical debt or design decision. A risk manager who highlights gaps in a high-profile transformation may be seen as attacking a favorite program. In organizations where relationships and perception matter as much as outcomes, people quickly learn that “making waves” can stall careers. To change this behavior, you have to treat it as a design problem, not a character flaw. The goal is to build systems, incentives, and norms where the safest move for a smart professional is to report early, not to sit on bad news.
Psychological Safety as a Security Control
Psychological safety can sound like a soft concept until you map it directly to time-to-discovery and time-to-containment. In environments where people believe they will be punished, humiliated, or quietly sidelined for surfacing issues, signals arrive late and heavily filtered. In environments where raising a concern is seen as doing your job well, signals arrive earlier and in richer detail. That difference shows up in hard numbers: how many issues are caught internally versus by customers, regulators, or external researchers, and how often you are genuinely surprised by the shape of an incident. Treating psychological safety as a security control means seeing these dynamics as part of your threat model, not as side effects of individual personalities.
The mechanics are concrete. Blameless post-incident reviews change the conversation from “who is at fault” to “what allowed this outcome.” Safe-harbor language in policies tells people that if they report issues promptly and honestly, the organization will focus first on fixing the problem, not on punishing the messenger. Separating “finding” from “owning” makes it clear that the person who raises a concern is not automatically stuck with the entire remediation journey. Over time, these practices build a muscle memory: when someone spots something off, the expected move is to say it out loud, log it in the system, and trust that the machinery around them will help.
For leaders, the hard part is consistency, especially under pressure. It is easy to talk about blamelessness until a disclosure threatens a key launch, an executive pet project, or public reputation. Those are the moments when people watch your reactions most closely. If you stay curious instead of combative, protect the people who told you the truth, and focus scrutiny on the system rather than the individual, you are quietly rewriting the organization’s stories about what happens to truth-tellers. Over months and years, that becomes a durable security asset: a steady flow of early, honest signals from the people who see the risk first.
Building the Pipes for Early Reporting
Culture sets expectations, but plumbing determines whether signals actually move. Many organizations tell people to “raise issues early” and then give them a maze of fragmented channels: email security, file a Jira ticket, mention it in stand-up, drop it in Slack, log it in GRC, or “just talk to your manager.” Each of those paths has different visibility, latency, and follow-through. The result is predictable: important concerns get bounced around, duplicated, or lost. If you want a culture of disclosure to survive contact with reality, you need clear, simple pipes for early reporting, paired with a predictable experience for the person sending the signal.
A good starting point is a small set of well-defined intake paths tuned to different types of issues: one for product and application security concerns, one for infrastructure and platform hygiene, one for vendor and third-party risk, one for suspicious behavior or potential incidents. These can be surfaced through tools people already use—a chat bot that turns a concern into a ticket with the right metadata, a simple form that routes to the correct triage queue, an option in your incident management platform for “early signal / concern” alongside “active incident.” The key is that when someone uses one of these paths, they know what will happen next: who will triage it, within what timeframe, and how they will be kept in the loop.
Routing and visibility matter just as much as intake. If early reports disappear into a private inbox or a black-box queue, people stop trusting the system. Leaders should design for layered visibility: local teams see the items they own, central security sees cross-cutting patterns, and senior leadership gets a periodic view of high-severity signals and systemic themes. Lightweight status updates—“triaged,” “accepted,” “in remediation,” “risk accepted”—help reporters see that their concern is moving, even if they are not the owner. Over time, you are teaching the organization that when someone raises an uncomfortable truth, the pipes carry it somewhere useful instead of letting it evaporate. That is where culture and mechanics start to reinforce each other.
Metrics That Reward Early Signals
If you measure only outages, incidents, and audit findings, you are grading the fire department on how often the building burns, not on how often someone smells smoke and calls it in. A culture of disclosure needs metrics that make early signals visible and valuable. That starts by tracking how issues enter the system: time-to-report after first detection, the volume and diversity of internally discovered weaknesses, and the mix of sources—engineers, analysts, business teams, customer-facing staff, and even vendors. When leaders see regular, healthy reporting from across the organization, they can distinguish between “we have no problems” and “we have problems but no one is talking.” Those are very different risk positions.
Ratios tell a powerful story. The proportion of issues discovered internally versus those found by customers, external researchers, regulators, or auditors is a direct measure of how well your internal eyes are working. Likewise, tracking how often early reports materially change an outcome—a risky change rolled back before release, a vendor deal repriced because of security concerns, a configuration fixed before an attacker stumbles across it—helps connect disclosure behavior to real business and risk results. Leaders should be able to point to concrete examples where someone’s early call-out prevented something worse from happening later. That narrative reinforces the message more than any slide.
At the same time, you need to avoid vanity metrics that drive gaming or silence. Counting raw ticket volumes without context encourages noise. Measuring only the number of “critical” issues resolved can lead to severity inflation or under-reporting of borderline concerns. The most useful view combines quantitative trends with qualitative review: regular forums where leaders examine a small sample of early reports and ask what enabled them, what slowed them down, and how the system responded. Over time, the goal is simple: when people look at your dashboards and stories, it should be obvious that early, honest reporting is how individuals and teams earn trust, not how they lose it.
Leading When Disclosure Gets Painful
All of this sounds straightforward until disclosure collides with something existential: a major customer, a regulatory deadline, a flagship product launch, or a public reputation already under stress. These are the moments when leaders are tempted to manage optics first and truth second. A team surfaces a serious vulnerability days before a keynote announcement, or an internal investigation reveals that an exposure has been sitting in logs for months. The instinctive move is often to narrow the circle, soften the language, and look for ways to technically satisfy obligations with minimal embarrassment. Everyone watching learns the same lesson: early, full disclosure is risky when the stakes are high.
The alternative is uncomfortable but powerful. Leaders who are serious about a culture of disclosure act predictably in these moments. They thank the team that brought the issue forward, even when the timing is terrible. They ask for clear facts and uncertainties rather than hunting for culprits. They insist on honest timelines: what was known when, who had which information, where signals were missed or downplayed. When regulators, customers, or boards need to be informed, they ground those conversations in that same factual spine rather than in wishful thinking. It does not make the situation pleasant, but it makes it coherent—and it reinforces the message that truth-telling is not optional.
These high-stakes disclosures also surface hard trade-offs: whether to delay a launch, pause a migration, renegotiate a vendor relationship, or accept short-term reputational damage to avoid a bigger hit later. Leaders who involve the people closest to the systems in those decisions signal respect and shared ownership. Leaders who instead pressure teams to reframe or minimize the findings send the opposite message. Over time, your track record in these painful episodes becomes the real policy on disclosure. People remember not what you said about “transparency” at the all-hands, but what happened when someone’s early warning threatened a prized narrative. That memory will decide whether the next signal arrives early or never at all.
Where Leaders Go From Here
At its heart, this topic is about whether your organization treats uncomfortable truth as a liability or as an asset. A culture of “don’t tell anyone” does not just delay bad news; it actively reshapes your risk profile, turning manageable weaknesses into career-ending incidents and quiet design flaws into public crises. A culture of “report early, fix faster” does not eliminate mistakes or surprises, but it changes when you learn about them and how much room you have to maneuver. The same systems, tools, and frameworks can sit in either culture and produce radically different outcomes.
Closing the gap starts with seeing disclosure culture as part of your security architecture, not as background noise. The stories people tell about past truth-tellers, the friction in your reporting pathways, the metrics you put on dashboards, and the way you behave when disclosure gets painful all add up to a single, coherent signal: it is either safe and worthwhile to surface risk early, or it is not. When leaders back up their words with predictable reactions, clear pipes, and visible rewards for early, honest signals, they tilt the entire system toward faster learning and smaller shocks.
From here, the most useful moves are simple and direct. Ask your teams how safe they feel raising bad news before it is fully formed, and listen closely to the stories that come back. Trace a handful of recent issues from first detection to final decision and notice where signals slowed, softened, or died. Then decide, explicitly, how you want people to feel the next time they see something worrying. The organizations that make that decision on purpose—and keep honoring it when the stakes are high—will be the ones that learn faster than their attackers and competitors.
