What breaks when security testing stays dependent on one expert?

Why This Matters for Security Teams

When security testing depends on one expert, the organisation usually loses more than speed. It loses repeatability, auditability, and the ability to prove that a test actually covers the systems in scope. That matters because security findings are only useful when they can be recreated, validated, and tracked over time. The NIST Cybersecurity Framework 2.0 places clear emphasis on governance, identification, protection, detection, response, and recovery, all of which depend on more than individual memory or tribal knowledge.

In practice, a single tester may know where the undocumented services live, which log sources are noisy, and which compensating controls are fragile, but that knowledge often never becomes a durable process. The result is that coverage drifts as systems change, while management still believes testing is current. This is especially dangerous in environments with frequent releases, mixed cloud and on-premises assets, or inherited tooling from acquired businesses. In practice, many security teams encounter the real gap only after a control failure or incident has already exposed it, rather than through intentional validation.

How It Works in Practice

Security testing becomes resilient when the knowledge behind it is converted into standard methods, shared runbooks, and evidence-based workflows. That means the organisation can describe what is tested, how scope is selected, what tools are used, and how exceptions are approved. Without that structure, one expert’s personal approach becomes the de facto control, which is hard to defend during assurance reviews and even harder to scale across business units.

A practical operating model usually includes a few core elements:

• Defined test objectives tied to risk, such as identity abuse, exposed services, misconfiguration, or application weaknesses.
• Version-controlled procedures so testing steps can be repeated by another analyst without guessing the original intent.
• Shared detection logic and validation criteria so results can be compared across time and teams.
• Centralised evidence capture so findings, false positives, and exceptions are traceable.
• Cross-training and peer review so critical coverage is not lost when a specialist is absent.

This is where security teams often benefit from aligning testing with the same discipline used in broader assurance and engineering. For example, NIST SP 800-53 treats control assessment as a repeatable activity, not a one-person craft. Likewise, guidance from CISA reinforces that prioritisation should be based on observable risk and exploitation evidence, not only on specialist intuition. If the organisation uses offensive testing, the ATT&CK knowledge base from MITRE ATT&CK can help standardise what techniques are in scope and how detection gaps are documented.

These controls tend to break down when testing is embedded in bespoke scripts, undocumented lab assumptions, or a single person’s workstation because the organisation cannot independently reproduce the same result.

Common Variations and Edge Cases

Tighter standardisation often increases upfront process overhead, requiring organisations to balance consistency against the flexibility experts need for novel threats. That tradeoff matters because some environments genuinely need specialist judgment, especially where legacy platforms, safety-critical systems, or highly bespoke cloud controls make automation unreliable.

Best practice is evolving rather than fully settled for emerging areas such as AI-assisted testing and autonomous validation. In those settings, the question is not whether one expert is smart enough, but whether the testing method is transparent enough to survive turnover, peer review, and change. If a tool generates scans, findings still need human validation, and if a person designs the test, the rationale should be captured so another analyst can rerun it later.

Identity and privilege also become an issue when the specialist alone controls admin credentials, scan exclusions, or production access. That creates an operational concentration risk as well as a security one. Shared access should therefore be paired with role-based approvals, logging, and periodic review so the testing capability remains usable without concentrating authority in one person. Where teams operate across regulated or fast-moving environments, the durable answer is usually documented process plus distributed competence, not heroics.

Related resources from NHI Mgmt Group

• What breaks when chatbot security testing is not in place?
• What breaks when AI security testing is done only in scheduled red team exercises?
• What breaks when an agentic coding tool stays below its security floor?
• What breaks when security tools only see one layer of agent activity?