Everyone Knew. Nobody Said Anything.

How silence, workplace pressure and the fear of being wrong can turn a visible warning into a cybersecurity incident.

It is not the silence of ignorance. It is the silence of people who have noticed something, questioned it privately, perhaps even discussed it with a colleague, but ultimately decided not to say anything.

Someone notices that a process is being bypassed.

Someone else realises that an access permission does not make sense.

An engineer spots a recurring anomaly. A security analyst has concerns about an exception that keeps getting renewed. An employee receives a request that feels unusual but assumes the sender knows what they are doing.

Nobody is entirely comfortable.

But nobody wants to be the person who raises an alarm that turns out to be nothing.

And sometimes, nobody wants to be the person who challenges a senior colleague, delays a project, or asks a question that everyone else seems to consider unnecessary.

So work continues.

Until it doesn't.

In a busy office, someone notices a critical process being bypassed, hinting at a deeper issue that could compromise the operation's integrity. They ponder whether this is an isolated incident or part of a larger trend. Another team member questions an illogical access permission, fearing it could lead to unauthorized access and security risks. An engineer identifies a recurring data anomaly, feeling urgency to investigate despite project pressures. Similarly, a security analyst is concerned about unjustified exceptions that could lead to vulnerabilities.

An employee receives an unusual request but hesitates to act, reflecting a culture prioritizing conformity over inquiry. As days pass, discomfort with the status quo grows, but fear of raising false alarms or challenging authority leads to inaction. This reluctance creates a cycle where concerns are ignored for productivity's sake, leaving issues unresolved.

Eventually, a critical failure or security breach occurs, revealing the consequences of inaction. The organization realizes the need for vigilance, open communication, and a culture encouraging questions. This experience highlights the importance of proactive engagement and accountability, shaping future processes and organizational culture.

The problem is not always that nobody noticed

When we discuss cybersecurity incidents, we often focus on the technical failure: the vulnerability that remained unpatched, the excessive privilege that went unnoticed, the suspicious activity that triggered an alert too late.

But there is another question worth asking.

What if someone noticed the problem before it became an incident?

Not every security incident involves an obvious warning that someone ignored. Sometimes the evidence is incomplete, the signals are ambiguous, or the risk only becomes clear in hindsight. But in other situations, the warning exists long before the damage.

The challenge is getting someone to act on it.

People do not make decisions in isolation. They work within hierarchies, deadlines, team cultures and expectations. They observe what gets rewarded, what gets dismissed, and what happens to colleagues who challenge established decisions.

Over time, these experiences shape behavior.

If raising concerns repeatedly leads to embarrassment, blame or being labelled difficult, people learn to become selective about what they say.

If deadlines consistently matter more than security reviews, exceptions begin to feel normal.

If senior people dismiss uncomfortable questions, others may stop asking them.

Nobody needs to announce that speaking up is unwelcome. The culture can communicate that message on its own.

How silence becomes a security risk

Imagine a team preparing to launch a new service.

During the final review, an engineer notices that a particular access permission is broader than necessary. It is not immediately clear whether the configuration creates an exploitable vulnerability, but it deserves investigation.

The launch is already behind schedule. The project team is under pressure. The issue appears small, and the engineer assumes someone more senior has probably considered it.

They decide not to raise it.

Another team member has a similar concern but sees no reason to reopen a discussion that appears settled.

The service launches.

Perhaps nothing happens. Perhaps the permission is corrected during routine maintenance.

Or perhaps an attacker eventually discovers that the excessive access creates an opportunity to move beyond the system they initially compromised.

The incident may later be described as a permissions failure.

Technically, that description may be correct.

But it may not tell the whole story.

The deeper question is whether the organization had an opportunity to examine the risk earlier, and whether its working environment made that conversation possible.

This is a hypothetical example, but the pattern illustrates an important distinction: a technical weakness can be the immediate cause of an incident without being the only condition that allowed it to persist.

The fear of being wrong

One reason people remain silent is that speaking up requires them to accept a particular kind of risk.

If they raise a concern and it proves unfounded, they may feel they have wasted everyone's time.

If they challenge a decision made by an experienced colleague, they may worry about appearing incompetent.

If they escalate an issue to management, they may fear being seen as someone who creates problems rather than solves them.

Yet remaining silent can feel safer because its consequences are less immediate.

This is a subtle but important imbalance.

The discomfort of speaking up happens now. The potential cost of staying silent may arrive months later, when the original decision is difficult to reconstruct, and the people involved have moved on.

Humans are not always good at weighing immediate social discomfort against a future risk that may never materialize.

Cybersecurity teams understand uncertainty as part of risk assessment. But organisations must also recognise how uncertainty affects the people expected to report risk.

A person does not need to be certain that something is wrong to raise a reasonable concern.

They need to know that the concern will be taken seriously enough to investigate.

When silence looks like agreement

There is another complication: silence is easily misinterpreted.

A manager presents a decision in a meeting. Nobody objects. The decision moves forward.

It is tempting to interpret the absence of objections as agreement.

But a quiet room does not necessarily represent a shared understanding of the risk.

Some people may lack enough information to challenge the decision. Others may disagree but believe their objections will make little difference. Some may simply be waiting for someone with greater authority to speak first.

When everyone waits for someone else to raise the issue, a concern can disappear without ever being resolved.

This matters in cybersecurity because risk frequently crosses organisational boundaries. An engineering team may understand the technical weakness. A business team may understand the operational pressure. A security team may understand the potential consequences.

If nobody brings those perspectives together, the organisation may have all the information it needs to ask the right question and still fail to ask it.

The danger is not simply that people remain silent. It is that decision-makers mistake that silence for assurance.

What should security leaders do differently?

Telling employees to speak up is not enough. If the environment makes speaking up costly, a reminder to be courageous will have limited impact.

Organisations need to make raising concerns a normal part of doing good work.

That starts with how leaders respond to inconvenient information. A person who reports a potential weakness should not have to prove that an incident is imminent before the concern receives attention.

It also means distinguishing between a reasonable security exception and an undocumented workaround that becomes permanent. Risks should have clear owners, explicit acceptance decisions, and review dates.

Teams need practical escalation routes when concerns are dismissed, or deadlines threaten to override necessary security checks.

And when an incident occurs, investigations should examine not only what failed technically, but also what people knew, what they communicated, what prevented action, and whether the organization made it difficult to challenge a decision.

The goal is not to eliminate disagreement or treat every concern as a crisis.

It is to create an environment where uncertainty can be discussed before it becomes an emergency.

The question worth asking

A strong security culture is not one in which everyone agrees, nobody makes mistakes, and every warning turns out to be correct.

It is one in which people can question a decision without being treated as disloyal, report a concern without being dismissed as alarmist, and admit uncertainty without losing credibility.

Because sometimes, the most important security control is not another tool, another policy, or another alert.

It is the ability of a person to say, “Something doesn't look right, and the willingness of an organization to listen.

When a security incident occurs, we often ask what the organization failed to detect.

Perhaps we should also ask something else:

Who felt they couldn't speak, and what made them feel that way?

Because sometimes, everyone knew something was wrong.

Nobody said anything.

And the organization mistook silence for safety.

Forged in Security — Exploring the human decisions, organizational behaviors and real-world events behind cybersecurity risk