Stop Measuring Cybersecurity Training by Who Clicked Complete

A hundred percent training completion rate is an administrative achievement. It tells me people opened a course, clicked through it, and satisfied a requirement. It doesn't tell me what they'll do when a suspicious message arrives, a production system starts behaving strangely, or an executive asks whether an incident can wait until Monday.

That distinction is the beginning of a serious cybersecurity education program. The objective isn't to make everybody sound like a security analyst. It's to give people the judgment and practiced behavior their jobs actually require. NIST's revised guidance on cybersecurity and privacy learning programs treats education as a life-cycle effort tied to risk, behavior, evaluation, and improvement, rather than a single annual event (Merritt et al., 2024).

I start with the decisions people make, not a list of subjects an instructor happens to enjoy teaching. A finance employee may need to recognize a change-of-bank-details scam and know how to verify it through an independent channel. A system administrator may need to recognize when a privileged access exception has become routine. An incident commander needs to distinguish facts from assumptions while making decisions under pressure. Those are three different educational problems.

A generic course can introduce common concepts, but it cannot substitute for practice in the context where the decision occurs. I would map each audience to a small number of consequential tasks, the errors likely to occur, and the evidence that would show competent performance. This is instructional design with an operational purpose, not an exercise in decorating slides.

The NIST Cybersecurity Framework 2.0 helps organize the program around business risk and governance rather than treating training as an isolated compliance item (National Institute of Standards and Technology, 2024). Its functions also suggest the range of behaviors worth teaching: preventing avoidable exposure, recognizing indicators, reporting incidents, and supporting recovery. Nobody needs to memorize the framework to benefit from those ideas.

It's easy to teach somebody the definition of phishing. It's harder to help them respond correctly when a believable request arrives from a compromised business account, uses familiar language, and appears during a hectic workday. The test isn't whether they can repeat a definition; it's whether they can pause, verify, and report without making the problem worse.

For technical teams, the same distinction is even more important. A SOC analyst can identify every phase of an incident-response diagram and still struggle to preserve evidence while coordinating a containment decision. NIST's updated incident-response guidance emphasizes preparation across governance, technology, and organizational processes (Nelson et al., 2025). Training should therefore include the authority to act, the people who must be called, and the tradeoffs between collecting evidence and stopping damage.

I like exercises that put a realistic decision in front of the learner and then make the consequences visible. A tabletop can be effective if the participants actually have to choose, rather than recite what a plan says they would choose. A cyber range can be valuable if the exercise teaches a defined skill, not merely because the lab looks impressive. For both, a short debrief that identifies why decisions were made is more useful than a theatrical scorecard.

An effective program usually needs a common foundation and several role-specific tracks. The foundation covers reporting, authentication, handling sensitive information, and the responsibilities everyone shares. Role-specific work addresses the real risks of development, infrastructure, procurement, executives, operational technology, and security operations.

Software engineers need more than an annual reminder not to reuse passwords. They need to understand how design choices, dependencies, code review, testing, and release processes influence security. NIST's Secure Software Development Framework provides a useful organizing structure for incorporating security practices into software production (Souppaya et al., 2022). An engineer should leave a session knowing which development decision changes, not merely having heard another lecture about vulnerabilities.

Industrial and operational-technology personnel require a different treatment again. Safety, availability, maintenance windows, vendor dependencies, and physical process consequences change what an acceptable response looks like. NIST's OT security guide emphasizes those distinctive constraints (Stouffer et al., 2023). Teaching someone to pull the plug on a suspicious system without understanding the process it controls can create a different and potentially more serious problem.