Common signs include developers continuing to make avoidable security mistakes, security reviews repeatedly catching the same issues, and teams treating security as a separate function rather than part of delivery. When training is not landing, you usually see weak follow through, poor retention of secure coding habits, and inconsistent application of guidance across teams.
What weak absorption looks like in day-to-day engineering work
When security training is actually landing, you should see fewer repeat findings, better self-review before code reaches security gates, and more consistent secure-by-default choices across squads. If those signals are absent, the issue is usually not awareness in the abstract, but whether the training changed how developers make routine design and implementation decisions.
A practical way to read the signal is to compare what happens before and after training. If the same classes of mistakes keep showing up in pull requests, design reviews, and remediation tickets, the team may have heard the guidance but not internalised it into habit.
- Developers keep reintroducing the same authentication, input-handling, or access-control mistakes.
- Security review comments are acknowledged but not reflected in later work.
- Fixes are applied narrowly to pass a review, then forgotten in the next feature.
- Different teams interpret the same guidance in different ways, which points to inconsistent understanding rather than isolated mistakes.
That pattern matters because training failure is often visible first in repetition, not in a dramatic incident. The more routine the miss becomes, the more likely it is that the training was too abstract, too detached from current code paths, or not reinforced by team-level practice.
Why repeat findings and inconsistent habits are the strongest warning signs
The clearest evidence that training is not being absorbed is repeated discovery of the same avoidable issue after the lesson should already be familiar. A one-off mistake is normal; repeated failure across similar components suggests the team does not yet have a working mental model for the control or the risk it addresses.
Another strong warning sign is when secure guidance is treated as a separate review activity rather than part of delivery. If developers only adjust behaviour when security is explicitly watching, the training has produced compliance behaviour, not durable engineering practice. NIST Cybersecurity Framework 2.0 is useful here because it frames security as an ongoing operating capability, not a one-time event.
For teams building software, the quality of absorption is usually best measured in work products: fewer recurring findings, stronger defaults in code templates, and less variance between teams handling the same problem. Where those outputs do not improve, training content may exist, but the organisation has not converted it into repeatable behaviour.
In software delivery contexts, training also fails when it is not reinforced by the engineering system itself. If secure patterns are not easy to apply in the build process, developers will revert to whatever is fastest. The NIST SSDF (SP 800-218) is a strong reference for aligning secure development practice with delivery workflows.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AT — Awareness and Training | Training absorption depends on workforce security awareness turning into routine engineering practice. |
| DE.CM — Continuous Monitoring | Repeated review findings and inconsistent habits are operational signals that training is not sticking. | |
| GV.OV — Oversight | Security training only works if leadership monitors whether teams actually apply it in delivery. | |
| Recommendation — Measure whether training changes developer behaviour and reinforce gaps through targeted follow-up. Track recurring defects and trend them to see whether security guidance is being retained. Tie training outcomes to oversight metrics that show whether teams are applying secure practices. | ||
| NIST SP 800-63 | IAL — Identity Assurance Level | Secure development often fails when engineers do not internalise identity and access requirements in implementation. |
| Recommendation — Verify that teams consistently apply identity-related requirements in code and review. | ||
| CIS Controls v8 | 17 — Security Awareness and Skills Training | This question is directly about whether training is changing developer behaviour. |
| Recommendation — Use recurring defect patterns to judge whether awareness training is producing durable skills. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Developer training often shows up in repeated mistakes around secrets, credentials, and secure handling. |
| NHI-03 — Least Privilege and Access Governance | Teams that do not absorb guidance often keep making avoidable privilege and access mistakes. | |
| NHI-10 — Lifecycle, Offboarding, and Exposure Reduction | Weak follow-through in training often appears as inconsistent lifecycle handling and remediation discipline. | |
| Recommendation — Audit whether teams repeatedly mishandle secrets and credentials after training. Check whether developers consistently apply least-privilege and access-governance guidance in delivery. Review whether teams follow through on remediation and lifecycle hygiene after security coaching. | ||
Practitioner Guidance
What to verify: Look for evidence that training changed behaviour, not just attendance. Review repeated findings by category, compare pull request quality before and after training, and check whether developers can explain the “why” behind the control rather than only reciting the rule.
Decision rule: If the same issue appears more than once after training, treat it as a reinforcement or design problem, not a knowledge-transfer win. Rework the training into team-specific examples, add better code examples, or change the workflow so the secure choice is the easiest choice.
What practitioners underestimate: Absorption often fails when guidance is too generic, too infrequent, or disconnected from the code paths developers actually touch. Practical examples tied to current services, libraries, and review findings usually outperform broad awareness sessions.
Practitioner takeaway: The best indicator that training has landed is not confidence or attendance, it is whether developers stop making the same avoidable mistakes without being prompted.
Related resources from NHI Mgmt Group
- Why does infrequent security training increase application risk for development teams?
- What are the signs that application security training is failing in fast-moving engineering teams?
- How should security teams reduce supply chain risk in GitHub-based development pipelines?
- How should security teams govern access to AI training data?
