Marie Wang, CISSP, CC shares her experiences of how training and awareness can successfully resonate with the organization to improve cybersecurity readiness, as well as the challenges when it doesn’t.
Disclaimer: The views and opinions expressed in this article belong solely to the author and do not necessarily reflect those of ISC2.
An employee reached out after failing a simulated phishing test. Not to ask if they were in trouble, but to ask what they had missed and how to catch it next time.
That message mattered more to me than the test result. Most people can't recall a single detail from their last security awareness training, but they can tell you exactly what happened the time they almost clicked something suspicious, or the time a colleague did. This article is about why that's true and what it means for how we build security culture.
The Reach-Out Is the Signal, Not the Failure
It would be easy to read that phishing test result as a gap to close. I read it as a culture working the way it was supposed to. The employee didn't hide the click or wait to be found out they came forward, on their own, right away.
Research on cyber incident reporting backs this up more strongly than I expected. A recent vignette study of over 800 employees found that psychological safety was the strongest predictor of whether someone reported a cyber incident, a stronger predictor than the standard behavioral variables researchers usually rely on, like perceived control or subjective norms. The reasoning holds up against what I've seen: people don't decide whether to report based only on whether they know how. They decide based on what they believe will happen to them if they do.
The alternative is well documented, too. Surveys on organizational reporting behavior have found that over half of employees admit they've avoided reporting a cybersecurity mistake out of fear of repercussions. Every one of those unreported mistakes is a blind spot, a phishing click, a misconfiguration, a shortcut under deadline pressure, that the organization only learns about later, if at all, usually at a worse moment than the first one.
Borrowing ‘Just Culture’ From Industries That Learned This the Hard Way
Aviation and healthcare didn't arrive at non-punitive reporting by choice; they arrived at it after punitive systems kept failing them. The framework they landed on, known as ‘just culture,’ draws a clear line: honest mistakes and reckless or willful acts are not the same thing and only the latter should carry consequences. The logic is blunt but proven: punishing people for honest errors doesn't eliminate errors, it just teaches people to hide the ones they can get away with hiding. A system built that way loses the very information it needs to find and fix the problem underneath.
I saw a version of this early in my career, on a helpdesk. Credential sharing was a recurring problem; end users would share logins with each other simply to get past slow access provisioning. The immediate response was always procedural: reset the shared password, flag the policy violation, move on. But the underlying friction stayed the same, so the workaround kept resurfacing with different people. Over time, the organization eventually moved to a self-service platform with SSO, making it far easier for staff to reset their own access without needing to borrow someone else's. The lesson wasn't really about the credential sharing itself, it was that punishing the workaround changed nothing until the friction driving it was actually removed.
That's the trap of what I'd call a Dr. No security posture: a function that blocks, tightens, and controls every avenue, on the theory that fewer paths mean fewer risks. It often produces the opposite. People don't stop needing to get their work done; they just stop telling you how they're doing it. Zero trust has an important, narrow place, verifying access, segmenting systems, assuming breach at the architecture level. The question worth asking is what happens when that same ‘trust nothing’ posture gets applied wholesale to people and culture, rather than to systems. Amy Edmondson's research on team performance offers a useful counterpoint here: the best-performing teams in her studies reported more errors than average, not fewer, not because they made more mistakes, but because they were safe enough for those mistakes to be visible instead of hidden. Safety, in her framing, isn't the absence of error. It's the condition under which error becomes something you can actually see and fix.
What Safety Surfaces That Fear Hides
An example from application security shows what that visibility is actually worth. A developer bypassed standard SDLC practice, deploying a change after the validation window had closed, in order to save time. The change itself had a record, just not inside the standard CI/CD pipeline where it should have lived. Working backwards, we found it wasn't a malicious shortcut; it was a documentation gap and approval to bypass had actually been given, informally, in a chat message. Because the environment was safe enough for that to surface without blame, application security was able to use it as a case study to improve secure coding practices going forward, a gap that would have stayed invisible without that safety.
The same dynamic shows up in a domain that didn't exist in most of our awareness programs a few years ago: AI governance. When we opened a standing forum for staff to ask the AI governance team about new tools before adopting them, one question was simple, could a specific third-party AI-enabled tool be used for a work task. Rather than trying it first and finding out later, the employee asked. That question triggered our intake process, checking the tool against our AI register, reviewing what data it would touch and confirming whether it needed a formal risk review before approval. The tool was ultimately approved for that use case. What stood out to me wasn't the approval, it was that the employee asked at all, rather than defaulting to shadow AI. That only happens when people believe asking is safer than assuming.
The Connective Tissue
Maybe my experiences have culminated in me sitting across GRC, security awareness, application security and AI governance now, but the pattern shows up the same way in every one of those domains. The technical outcome and the human relationship aren't separate tracks, they're the same track. Research on information security culture backs this up directly, studies across Germany, the U.K., and the U.S. have found that organizational attitudes, sense of responsibility and communication quality are direct predictors of whether employees report phishing at all. The ‘soft’ side of the business isn't adjacent to the technical risk picture. It's often the load-bearing wall.
People in GRC and awareness roles are often the actual human point of contact between a staff member and a possible incident, the person someone messages when they're not sure, when they made a mistake, or when they just want to ask a question before doing something risky. That relationship is not a nice-to-have sitting alongside the technical controls. It's frequently the thing that determines whether the technical controls ever get the information they need to work.
Building It on Purpose
None of this happens by accident. If you want the reach-out, the message after the failed phish test, the developer explaining the informal approval, the employee asking before adopting a tool, you have to build the conditions for it deliberately:
- Make it explicitly, repeatedly okay to say "I'm not sure," "I need help," or "I made a mistake." Say it out loud, more than once, from leadership as well as from the security team. Back it up with behavior that reinforces the message, not just the words.
- Separate honest error from reckless or willful action in how you actually respond, not just in your policy language. A just culture only works if people can predict, in advance, which category their situation will fall into.
- When friction drives a workaround, fix the friction. Punishing the workaround without addressing the reason it exists guarantees it comes back.
- Give people a specific, low-barrier place to ask; a forum, a person, a channel, before they act, not just a place to confess afterward.
Awareness isn't a training event. It's a culture built one memorable moment at a time. The moments that build it are the ones where someone chose to speak up because they believed it was safe to.
Marie Wang, CISSP, CC, is a GRC, security awareness and application security leader in pharma and life sciences. Her work spans risk governance, secure-by-design practices and AI risk frameworks, building programs that enable innovation rather than slow it down.
