Look for repeated manual probes, one-off scripts, findings that only a senior tester can reproduce, and tests that disappear when a person changes team or leaves. Those are indicators that the programme has expertise, but not durable coverage. The fix is to convert repeatable judgement into shared automation.
When AppSec Knowledge Is Trapped in Individuals
The signs usually show up in delivery behaviour, not in job titles. Teams keep rediscovering the same issues, the testing approach depends on one or two people, and quality drops when those people are unavailable. In practice, that means the programme has expertise somewhere, but not enough shared method to make it repeatable.
A useful way to read this is that AppSec is functioning as a specialist service rather than a durable capability. Knowledge may be real, but if it lives mainly in personal memory, private scripts, or ad hoc judgement, it will not survive turnover, scaling, or parallel delivery.
Operational Signs the Knowledge Has Not Been Externalised
The clearest sign is repetition without accumulation. If teams keep finding the same classes of defects, using the same manual probes, or rebuilding the same one-off checks for each project, the organisation is not converting lessons into reusable controls. That is a process problem, not just a people problem.
Another indicator is dependence on specific authorship. When findings can only be produced by one senior tester, or only understood by the person who wrote the script, the work is not portable. The OWASP ASVS is useful here because it pushes teams toward defined, repeatable verification requirements instead of personality-driven testing.
A third sign is inconsistency across teams or releases. If the same application family gets different test depth depending on who is assigned, or if a control exists only when a particular expert remembers to apply it, the organisation is missing a standardised baseline. That is where OWASP SAMM helps, because it frames AppSec as a maturity problem that should move from individual effort to managed practice.
What Breaks When AppSec Stays Person-Dependent
Person-dependent AppSec creates brittle coverage. Coverage becomes tied to availability, memory, and informal habits, so the control weakens under leave, reassignment, surge demand, or delivery pressure. The programme may look active, but its assurance is uneven and hard to defend.
It also creates a hidden knowledge-transfer risk. If remediation logic, threat assumptions, or test design live in private notes or local tooling, other engineers cannot verify them, improve them, or reuse them safely. The result is not just slower delivery, but a narrower security feedback loop.
The broader consequence is false confidence. Leaders may think AppSec exists because experts are present, when in fact the capability is too concentrated to scale. For a durable baseline, the team should be able to point to shared requirements, shared checklists, and shared evidence that survive personnel changes.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, OWASP SAMM and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V1 — Encoding and Sanitization | AppSec testing must be repeatable across core web security checks. |
| Recommendation — Standardize verification checks so any qualified tester can reproduce expected results. | ||
| OWASP SAMM | S1 — Governance | SAMM fits because the issue is maturity and repeatability, not one-off testing skill. |
| Recommendation — Build shared security practices that survive staff changes and scale across teams. | ||
| NIST SP 800-53 Rev 5 | SA-11 — Developer Testing and Evaluation | Developer testing must be defined and repeatable rather than dependent on a single expert. |
| Recommendation — Define security test expectations so coverage is consistent and auditable. | ||
Practitioner Guidance
What to verify: Ask whether a second competent tester can reproduce the same result from the written process, not from tribal knowledge. If they cannot, the control is still person-bound even if it works today.
What good looks like: Repeatable findings map to shared test cases, shared standards, and shared automation, with clear ownership for maintenance. The senior person should improve the system, not be the system.
Common mistake: Treating a strong individual contributor as proof of programme maturity. High-quality manual work is valuable, but it is not durable coverage until it can be transferred, repeated, and audited without the original expert.
Practitioner takeaway: If AppSec quality falls apart when one person leaves or is unavailable, the organisation has expertise, not capability; the real milestone is when judgement becomes a documented, reusable control.
Related resources from NHI Mgmt Group
- When does a short-lived API key still create material risk?
- Why do ServiceNow tickets and knowledge bases leak secrets so easily?
- What are the signs that AppSec is still operating as a late-stage gate rather than part of the development workflow?
- What are the signs that an AppSec platform is still functionally fragmented?