Larry Marks, CISSP argues that many organizations still treat cybersecurity awareness as an annual training exercise. But awareness only becomes effective when managers reinforce it through day-to-day decisions, escalation expectations, reporting and accountability.
Disclaimer: The views and opinions expressed in this article belong solely to the author and do not necessarily reflect those of ISC2.
For many organizations, cybersecurity awareness still means an annual course, a completion percentage and a report showing that the requirement was met. That is necessary, but it is not enough.
Over the course of my career, I have seen organizations put too much emphasis on whether employees completed training and not enough on whether they actually understood the risk, recognized warning signs and knew what to do when something did not look right.
Training and awareness are not the same thing. Training can explain phishing, social engineering, credential theft, suspicious behavior, or escalation procedures. Awareness is demonstrated when someone encounters a real situation, recognizes the potential risk and makes the right decision. Management should therefore make understanding and behavior the objective, not simply completion.
One Size Does Not Fit All
One of the weaknesses in traditional awareness programs is the assumption that everyone should receive essentially the same training. One size does not fit all.
A trader faces different risks from someone in HR. A payment employee faces different threats from a help desk analyst. A privileged administrator presents a different risk profile from a contractor. Payment personnel should receive deeper awareness around social engineering, unusual payment instructions, impersonation, business email compromise and verification before money moves.
Help desk personnel need specialized training around identity verification, password resets, MFA bypass attempts, impersonation and requests for elevated access. HR personnel need awareness around employee information, payroll diversion, onboarding and offboarding, and identity fraud. Privileged personnel require enhanced awareness because their access can materially affect systems and operations.
Executives and traders increasingly need exposure to sophisticated impersonation, deepfake audio and video, and other AI-enabled attacks designed to create urgency or influence high-value decisions. Contractors should receive training based on the systems, information, and privileges they actually have.
Management should not ask whether everyone received the same training. It should ask whether each population received training appropriate to the risks it actually faces or creates.
Training Should Be Smaller, More Frequent, and More Relevant
Awareness should also be broken into shorter, specialized segments throughout the year rather than relying primarily on one large annual course.
A payment employee may need a short module based on a newly observed fraud technique. An executive may need to see a realistic deepfake. A privileged user may need additional training following an access-control issue. The same principle applies globally.
Localization should mean more than translating the same course. Different regions can face different fraud patterns, regulatory requirements, business processes, languages and cultural approaches to challenging or escalating suspicious activity. The more generic the training, the easier it becomes for employees to treat it as a compliance exercise. The closer it gets to what people actually do, the more useful it becomes.
Who Is a Developer Now?
AI introduces another complication: even our traditional employee categories are beginning to change. Who is a developer?
Historically, the answer was fairly straightforward. Developers worked in engineering, application development, or technology organizations. Generative AI is changing that distinction.
A trader can ask an AI tool to generate a script to analyze data or automate a process. An executive can use AI to develop an automated workflow or technical deliverable. A business analyst can generate code without having a formal programming background. None of them may call themselves developers, but they may be creating technology that introduces security and operational risk.
The security-awareness question can no longer simply be: “Is this person a developer?” A better question is: “Is this person creating, modifying, generating, or deploying code, automation, or technical logic that can affect systems, data, transactions, or business decisions?”
If the answer is yes, some level of developer-oriented security awareness may be appropriate. That does not mean giving every executive or trader a secure-coding course. Training should remain proportional to the activity and risk. But someone using AI to generate code should understand issues such as sensitive-data exposure, permissions, testing, validation, dependencies, vulnerabilities and what can happen when generated code does something other than what the person expected. Professional developers require much greater depth. Their awareness should include secure coding, vulnerability analysis, zero-day vulnerabilities, code review, dependency risk, excessive permissions, hard-coded credentials and appropriate testing of AI-generated code. They also need to consider when code effectively goes “rogue” – producing unintended or unsafe outcomes because of defects, compromised dependencies, malicious manipulation, unexpected interaction, or autonomous behavior.
For security-awareness purposes, developer is increasingly an activity and a capability, not simply a job title.
Training Content and Metrics Have to Follow the Risk
That change also affects what we are trying to measure. If we define awareness populations only through job titles, we may miss the people creating the risk.
The organization first has to identify the activity. Who is creating code? Who can authorize payments? Who can reset credentials? Who has privileged access? Who handles sensitive information? Who can create automated processes? Who is using AI to perform activities that previously required specialized technical knowledge? Training should then follow that risk.
The same should be true of the metrics. Management does not need 15 awareness KPIs that create the appearance of precision while hiding what is actually going wrong. I would rather see a small number of measures that identify meaningful failures. I would focus on four:
- Repeat failure concentration. Where are the same employees, roles, activities, business units, or regions failing repeatedly? A repeat failure may indicate something beyond training—poor process design, management pressure, unclear escalation, or inadequate controls.
- Escalation failure. Did someone recognize that something looked wrong but fail to report it, report it too late, or send it to the wrong place?
- Activity-specific scenario failure. Can someone make the correct decision in a realistic situation involving what that person actually does? A payment employee should not be tested the same way as a help desk analyst. Likewise, a trader who generates AI code may need a scenario that would never be appropriate for another trader who does not.
- Remediation effectiveness. After a failure was identified and targeted training provided, did the behavior change?
Completion rates and phishing click rates still have value. They simply should not be confused with measures of understanding. The purpose of awareness metrics should be to identify where people are making the wrong security decisions, why the failures are occurring and whether management is correcting the underlying cause.
Security Awareness Has Legs
Security awareness should not operate as an isolated program owned only by the security organization. It has legs. It affects vulnerability management and remediation, third-party risk, privileged access, secure development, incident response, business continuity and tabletop exercises.
Consider for example a newly discovered vulnerability. Developers may need to understand how the weakness was introduced. Administrators need to understand exposure and remediation. Help desk personnel may need to recognize suspicious symptoms. Managers need to understand the operational effect. A third-party compromise presents another set of awareness requirements involving vendor owners, technical teams, employees, and business management. Awareness should change when the risk environment changes.
Put Awareness into Tabletop Exercises
Tabletop exercises provide an opportunity to test whether awareness actually works. Tabletops often begin after the hypothetical incident has already occurred. I believe they should go further.
Did someone recognize the warning signs? Did that person know where to report the concern? Was the escalation timely? Did management understand its responsibility? Did a third party know what was expected? Did the business know how to operate while systems were being investigated or restricted? These are security-awareness questions as much as incident-response questions.
Management also needs to recognize a basic reality: even excellent security awareness cannot prevent every incident. The objective should be to reduce the likelihood of successful incidents, recognize them earlier, minimize their impact, improve response and ideally increase the length of time between successful events. Security awareness therefore contributes to resilience as well as prevention. Business leaders have to understand how to run their business when something still gets through.
Employees Come and Go
Organizations also cannot forget workforce change. Employees come and go. Contractors rotate. Managers change. People receive promotions and move into different positions. Access changes. Technology changes. AI gives people capabilities they did not have a year ago.
Someone who previously presented relatively little technology risk may suddenly be generating code, handling payments, managing a vendor, or receiving privileged access. Awareness therefore must be continuous and tied to onboarding, role changes, changes in access, new capabilities and evolving responsibilities. The workforce changes. Awareness must change with it.
Compliance May Not Reveal the Full Risk
Regulators and auditors may review whether an awareness program exists, whether training was completed, whether policies are current, and whether testing takes place. Those are important questions. But regulatory reviews may not always go deeply enough into the awareness metrics to identify every concentration of behavioral risk.
An organization could demonstrate very high completion while still having repeat failures in one business unit, weak escalation behavior, high-risk populations receiving inadequate specialized training, or AI users performing development activities that were never categorized as development.
Management should not rely on regulators to discover those weaknesses. Compliance should be the floor, not the analytical standard for determining whether security awareness is actually reducing risk.
Awareness Is Ultimately a Management Responsibility
Cybersecurity Awareness Month should therefore be about more than reminding people to complete another course. It should cause management to ask better questions.
Do people understand the risks associated with what they actually do? Are we identifying activities rather than relying only on job titles? Are high-risk populations receiving specialized training? Are repeat failures telling us something? Are employees being exposed to realistic deepfakes and AI-enabled threats? Do people generating code through AI understand the risks they are creating? Are awareness lessons incorporated into vulnerability management, third-party risk, remediation and tabletop exercises?
Most importantly, when something does not look right, does the employee know what to do – and does that employee believe management expects and supports the decision to act? After decades working in cybersecurity, technology risk, and governance, my view is straightforward:
Cybersecurity awareness is not demonstrated by completing a course. It is demonstrated by behavior.
A mature awareness program will not prevent every incident. But it should help 5the organization identify risk earlier, respond faster, reduce the impact, learn from failures and make the next successful incident more difficult. That is when security awareness becomes more than training. It becomes part of how management runs the business.
Larry Marks, CISSP is a cybersecurity, technology risk and enterprise governance professional with more than 35 years of experience across financial services, consulting and healthcare. He has held senior roles at BBVA, BDO, Brown Brothers Harriman and IBM, focusing on cybersecurity governance, operational risk, regulatory compliance and incident response. More recently, his work has expanded into AI governance, AI guardrails, emerging technology risk and AI model testing and evaluation.
