As part of Cybersecurity Awareness Month, Llewellyn Willemse, CISSP shares his experiences and thoughts on rethinking organizational approaches towards awareness of cybersecurity issues – both technical and nontechnical.
Disclaimer: The views and opinions expressed in this article belong solely to the author and do not necessarily reflect those of ISC2.
Cybersecurity awareness is often discussed as though it is something the security team provides to the rest of the organization. Employees complete annual training, learn how to identify phishing emails, are reminded not to reuse passwords and are encouraged to report anything suspicious.
All of those things matter. But over the course of my career, working across cybersecurity, infrastructure, projects, operational environments and more recently advisory work, I have increasingly come to believe that this definition of awareness is too narrow.
Cybersecurity awareness is not simply an end-user skill. It is an organizational capability. What it means to be security-aware should depend on the decisions a person is responsible for making.
An employee does not need to understand the architecture behind Conditional Access to recognize an unexpected authentication prompt. A manager does not need to know how to configure a firewall to understand that allowing a third party into the environment introduces risk. An executive does not need to investigate an incident personally but does need enough understanding to make informed decisions about risk, investment and priorities.
Likewise, cybersecurity professionals need something from the other side of that equation: enough organization awareness to explain technical risks in terms the organization can understand and act upon.
The Same Awareness Does Not Fit Every Role
One of the simplest cybersecurity habits I value is asking:
- Does this make sense?
- An unexpected MFA prompt appears on your phone. Does that make sense?
- A supplier suddenly asks for banking details to be changed. Does that make sense?
- A third party asks for access they have never needed before. Does that make sense?
- An administrator is asked to bypass a security control because it is preventing somebody from completing a task. Does that make sense?
The answer may be yes. But asking the question creates something valuable: a pause between the request and the action.
People do not always need enough technical knowledge to identify exactly what the threat is. Sometimes they simply need enough awareness to recognize that something does not fit the expected context and know what to do next.
That same principle becomes more important as responsibility increases.
Consider a request to provide a third-party vendor with access to organizational systems. From a purely technical perspective, the question may appear straightforward: what access do they require and how do we provide it?
In practice, I have found that the more important questions often come afterwards.
Why is the access required? What information or systems become accessible? Is the vendor using a managed device? How will authentication be controlled? How long should the access exist? Who owns the relationship? Who has the authority to accept any residual risk?
Different people in that process need different forms of cybersecurity awareness.
The employee working with the vendor needs to understand that access should not simply be granted because somebody asks for it. The technical team needs to understand the implications of the access method they implement. The manager responsible for the relationship needs to understand that convenience may introduce risk. Leadership may ultimately need to decide whether that risk is acceptable.
Security awareness therefore cannot stop at teaching the employee to identify phishing.
Technical Knowledge Does Not Remove the Need for Judgment
Technical teams are sometimes treated as though cybersecurity awareness is primarily for everyone else.
My own experience has taught me the opposite.
As an engineer, I am often in the position where I can make the requested technical change. The more important question is whether making it changes something beyond the immediate task.
I have seen this repeatedly in identity and access work. An organization can build increasingly sophisticated restrictions around who may access a resource, from where and using which devices. Technically, those controls may work exactly as designed.
Then reality arrives.
A legitimate user has a device that does not meet the expected condition. A contractor needs access from outside the normal environment. An organization process depends on an exception. A temporary arrangement lasts considerably longer than originally anticipated.
In one recent identity project, I worked with an access model that technically did exactly what it was intended to do. Access was restricted to a known set of approved devices so the immediate requirement was met.
But it was also clear that the approach was transitional. The more devices and exceptions that needed to be maintained manually, the less sustainable the control would become. The long-term answer was not simply to keep extending the exception list. The underlying device-management and compliance model needed to mature so the access control could scale with the environment.
Nothing was technically broken. That was precisely the point. A configuration can function perfectly and still deserve another question:
What does this decision change?
The awareness required from a technical professional is not only knowing how to implement a control. It is recognizing when the task has moved beyond implementation and into risk.
Is This Actually My Decision?
This is a question I have learned to ask more often.
Technical professionals are frequently in the unusual position of being able to implement changes whose risks they do not have the authority to accept.
Suppose a legitimate organization requirement conflicts with a security recommendation. The engineer can explain the technical implications. The security professional can assess the risk. But whether the benefit justifies the residual risk may belong to a manager, system owner or executive.
Being able to make the change does not automatically mean I should be the person deciding whether the resulting risk is acceptable. Awareness therefore includes understanding the limits of your own authority. This matters because organizations can accumulate risk without ever explicitly deciding to accept it.
A temporary exception is made. Then another. A workaround remains in place because everybody becomes accustomed to it. A control is relaxed because an urgent requirement takes priority and nobody later revisits the original decision.
Eventually, the organization may have a very different security posture from the one its policies describe. Nobody necessarily made one obviously reckless decision. The individual decisions may each have been understandable. They simply stopped asking whether those decisions still made sense together.
Managers Make Cybersecurity Decisions Too
Management decisions frequently have security consequences even when nobody labels them as cybersecurity decisions.
A deadline is brought forward. A vendor needs urgent access. A process is considered too restrictive. A system cannot be upgraded because the organization cannot tolerate the interruption. An exception is requested because the normal control is inconvenient.
Each decision may be entirely reasonable. Requirements are real and cybersecurity cannot exist independently of them. But the decision should be made with an understanding of the resulting risk.
This is where awareness at management level becomes important. Managers do not need to become cybersecurity specialists. They do need enough awareness to recognize when an operational decision changes the organization's exposure and when specialist advice or formal risk acceptance is appropriate.
Without that awareness, cybersecurity teams can implement controls while the organization unintentionally undermines them through ordinary day-to-day decisions.
Policies Are Necessary, But They Do Not Make Decisions
I believe strongly in well-defined policies, standards and procedures. They create consistency, establish expectations and provide a basis for accountability. I have also written and worked with enough policies to know that the document itself is often the easy part.
The difficult part begins when somebody must apply it to a situation that does not fit neatly into what was written.
Artificial intelligence (AI) has made this particularly obvious. It is relatively easy to write a policy stating that sensitive information should not be placed into unapproved AI systems, that AI-generated output should be validated or that AI should not become the unquestioned authority behind significant decisions.
The harder problem is what happens in everyday work:
- Does the employee recognize that the information they are about to provide is sensitive?
- Does the manager understand why a seemingly useful AI service may introduce a data-handling concern?
- Does the technical team know what controls are available?
- Does leadership understand when the decision has moved beyond convenience and into risk acceptance?
In one recent policy exercise, I was involved in developing guidance that was detailed, structured and technically sound. The problem was that it was not necessarily practical for the engineers expected to use it in everyday work. We eventually moved toward shorter, more practical guidance.
That was a useful reminder for me. A technically correct policy can still fail to create useful awareness if the people expected to follow it cannot translate it into the decision in front of them.
The objective is not merely to produce a correct document. The objective is to help somebody make a better decision.
Executives Need Decision Awareness, Not Technical Training
The same principle applies at executive level.
I would not expect an executive to understand every technical detail behind an identity platform, vulnerability, network architecture or security incident. That would be an unreasonable use of their time.
I would expect them to understand enough to make the decisions that only they can make.
- What could happen?
- How likely is it?
- What would the impact be?
- What would it cost to reduce the risk?
- What happens if we choose not to?
Those are wider organization and operational questions expressed through cybersecurity.
This is particularly important because some risks cannot be eliminated. Organizations routinely accept risk because remediation is impractical, disproportionately expensive or conflicts with a legitimate operational requirement.
The important distinction is whether the risk was consciously accepted by someone with the appropriate authority or simply accumulated through a series of technical and operational decisions.
Security Professionals Have An Awareness Responsibility Too
There is another side to this discussion that cybersecurity professionals should not ignore.
It is easy for us to talk about cybersecurity awareness as though the solution is for everyone else to understand security better. I do not think that is enough.
If I explain a risk to a team or organization leader entirely in technical terminology and they cannot understand the decision I am asking them to make, I have not necessarily communicated effectively simply because my technical analysis was correct.
Cybersecurity professionals need broader organizational awareness. We need to understand what the organization is trying to accomplish, what constraints it operates under and why somebody might reasonably choose a different balance between risk and operational need than we would.
Our responsibility is not merely to identify risk. It is to make that risk understandable enough that the appropriate person can make an informed decision. That requires judgment, communication and sometimes the humility to recognize that security is one consideration among several.
From Awareness Training to Organizational Awareness
None of this diminishes the importance of traditional awareness training.
Employees should recognize phishing. They should question unexpected authentication prompts. They should understand appropriate information handling and know how to report suspicious activity.
But completion rates tell us only part of the story. A more meaningful assessment of cybersecurity awareness would look across the organization.
- Do employees recognize when something does not make sense?
- Do technical teams recognize when an implementation decision creates broader risk?
- Do managers recognize when organization decisions have security consequences?
- Can executives understand the risks they are being asked to accept?
- And can cybersecurity professionals translate technical concerns into decisions those people can reasonably make?
An organization in which everyone has completed the same awareness training is not necessarily a security-aware organization.
A security-aware organization is one in which people understand the cybersecurity implications of the decisions they are responsible for making and know when the decision has become bigger than their role.
Cybersecurity awareness should therefore not be measured only by asking:
“Do our employees know what to look for?”
We should also be asking:
“Do our people, technical teams, managers and leaders understand the security decisions they are expected to make?”
And perhaps, just as importantly:
“Do they know when the decision is no longer theirs to make?”
Llewellyn Willemse, CISSP, has 18 years of experience in mining, critical infrastructure, enterprise security and IT. He has held specialist, management and governance roles focused on security systems, infrastructure, cyber risk and business-aligned security strategy. His cybersecurity work spans governance, risk, compliance, security operations and enterprise resilience.
