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).

Work backward from the mistakes that matter

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.

Teach the difference between recognizing and doing

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.

Build distinct tracks without building a bureaucratic monster

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.

Measure the behavior, not just the attendance

I would measure whether employees can recognize and correctly route important events, whether analysts can complete defined tasks, and whether leaders make better decisions during exercises. That might include reporting quality, escalation time, restoration decisions, or whether a developer actually uses an approved security review before a high-risk release. These measures need context; a sudden increase in reports may reflect better awareness rather than a worsening threat environment.

NIST SP 800-50 Rev. 1 discusses metrics and evaluation as part of program improvement (Merritt et al., 2024). The point isn't to create a complicated training dashboard. It's to identify where the learning program is changing behavior and where it is merely consuming time. If the same operational mistakes recur after three years of training, I'd look at incentives, workflows, and management decisions before blaming the learners.

There's also a governance question. An organization cannot credibly teach employees to report suspicious activity and then punish them for slowing down a transaction to verify it. Culture is what happens when the policy meets a deadline, an irritated manager, or an inconvenient customer. Training has to acknowledge that reality.

What a useful program delivers

The deliverable should be a curriculum mapped to real roles and risks, practical exercises, clear performance expectations, and a repeatable way to revise the program when systems or threats change. The material needs to work for the people using it, not just the people signing the training contract.

I work across technical security, operations, and education because those disciplines meet at the same place: somebody has to make a decision with imperfect information. If you're developing a cybersecurity curriculum, a professional training program, or an operational exercise, I'd rather start with what your people must be able to do than how many slides we can produce.

Interested in developing a cybersecurity learning program? Let's discuss the actual skills your people need.