Safeguard
Security Guides•

How to measure whether secure coding training worked

Attendance is not learning. Practical measures for secure coding training: lab results, repeat-finding rates, review behavior and what to avoid counting.

Safeguard Security Team
3 min read

Measure training by what changes in code and review behavior, not by attendance. Useful signals are lab completion, a repeat of the same bug class in new findings, review comments that cite the training, and how quickly a team fixes a known pattern. Treat each as a trend, not a score.

Why attendance misleads

A full room tells you people came. It says nothing about whether they can fix an injection flaw next week. Attendance still belongs in your records, especially if training is a compliance control, but it is not the outcome.

Signals worth tracking

Lab completion and fix quality. Did the learner's fix pass the test that proved the exploit? That is direct evidence of skill, collected during the session.

Delayed check. Seven to fourteen days later, ask a short question that requires applying the idea to a new snippet. Retention fades quickly, so a delayed check shows what stuck.

Repeat findings. If your scanners and reviews show the same bug class recurring, training on that class did not land, or did not reach the right people. Look at the trend per team, not per person.

Review behavior. Count review comments that flag the bug class you taught. A rise after a workshop is a good sign.

Time to fix. For the taught pattern, track how long findings stay open. Faster closure suggests confidence.

Voluntary uptake. Number of people who join the next optional event, or ask for a lab on a new topic.

What to avoid

Do not rank individuals by quiz scores in public. It discourages honest mistakes. Do not treat a drop in findings as proof without checking whether scanning changed. Do not set targets so tight that teams stop reporting.

A simple dashboard

Keep it to four numbers per quarter: participation by role, lab pass rate, repeat finding rate for taught classes, and median time to fix those classes. Review it with team leads and ask what they would change.

Link to the next session

If a bug class keeps returning, schedule a targeted lab for that team rather than repeating general training. Use findings from your own repositories as lab material.

Evidence for auditors

Keep the roster, syllabus, completion records and the delayed check results. Our guide to what to record under PCI DSS 6.2.2 lists a practical evidence set.

Quick check

Is a quiz enough?

A quiz shows recall. Pair it with a hands-on fix and a look at real findings over time to see whether behavior changed.

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.