Who should security leaders hold accountable when training is measured only by completion rates?

Why This Matters for Security Teams

Completion rates are easy to report, but they are a weak proxy for risk reduction. When leaders judge a security awareness programme only by attendance or quiz completion, they can mistake administrative success for operational improvement. That gap matters because training is often used to justify control maturity, audit readiness, and budget decisions. If the metric does not show changed behaviour, it does not show reduced exposure. NIST’s control guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces the need for organisations to implement security awareness and role-based training as part of a broader control environment, not as a standalone checkbox.

The real accountability question is therefore not whether people finished a course, but whether the people responsible for the programme can demonstrate that it changed decisions, reduced unsafe actions, and addressed the risks most likely to matter in their environment. That puts responsibility on security leadership, GRC owners, and the programme sponsor, not on employees who are simply measured against a flawed metric. In practice, many security teams encounter the weakness of completion-only reporting only after a phishing event, credential misuse, or policy breach has already shown the training had little operational effect.

How It Works in Practice

A more credible training model starts with risk segmentation. Different roles face different threats, so the programme should map content to job function, data access, and likely attack paths. For example, finance teams may need stronger phishing and payment fraud awareness, while developers need secure coding and secrets handling guidance. Security leaders should then define outcome measures that relate to behaviour, such as reduced click-through on simulations, fewer policy exceptions, faster reporting of suspicious activity, or lower rates of repeat mistakes.

This approach is consistent with the broader direction of security governance in CISA insider threat mitigation guidance, which treats awareness as part of a prevention and detection strategy rather than a one-time event. It also fits the intent of the CIS Critical Security Controls, where security awareness is one component of a layered defence model. In practice, leaders should require the following:

• Risk-based training assignments tied to role, system access, and incident history.
• Behavioural metrics such as reporting rates, repeat failure rates, and simulation outcomes.
• Manager accountability for teams with persistent unsafe patterns.
• Regular refresh cycles that reflect current threat activity, not annual compliance alone.
• Evidence that training content changes when risk changes.

Where possible, the programme should connect learning outcomes to telemetry from email security, EDR, ticketing, and incident response. That gives security leaders a practical view of whether training is influencing decisions in the real workflow. These controls tend to break down in large, decentralised organisations with weak telemetry, because completion data exists while behaviour data is fragmented across disconnected systems.

Common Variations and Edge Cases

Tighter measurement often increases programme overhead, requiring organisations to balance richer evidence against reporting complexity and privacy constraints. There is no universal standard for this yet, so current guidance suggests using the least intrusive metrics that still demonstrate whether the programme changes behaviour. Some organisations will be able to measure simulation response quality, while others may only have access to incident trends, policy exceptions, or manager attestations.

The main edge case is where training is delivered to satisfy contractual or regulatory expectations, but the workforce has limited exposure to the threats that the course describes. In those environments, completion may be necessary for governance, but it is not sufficient for assurance. Another common issue is over-assigning accountability to individual staff when the root cause is poor control design, unclear procedures, or insecure defaults that training cannot reasonably fix. This is especially true for cloud, engineering, and high-privilege environments where process weakness drives most failures.

For AI-assisted or automated workflows, the accountability question becomes more nuanced. If employees use AI tools to draft content, analyse data, or execute tasks, the programme should also address safe use, verification, and escalation rules. That intersection is still evolving, and best practice is changing faster than many awareness programmes can keep up with. Security leaders should therefore hold programme owners accountable for proving that content, targeting, and measurement reflect current risk, not just that the course was completed.

Related resources from NHI Mgmt Group

• What should security leaders do when training takes too much effort to maintain?
• How should security teams measure human risk programmes beyond training completion?
• Why do completion rates fail as audit evidence for security awareness programmes?
• How should security teams measure security culture without relying on training completion?