What signs show that red teaming and pentesting are being used for the wrong purpose?

When the scope is wrong, the test answers the wrong question

red teaming and pentesting are being used for the wrong purpose when the engagement is framed as proof of one decision, but the team is actually asked to produce a different kind of evidence. A penetration test can prove exposure paths and control failure; a red-team exercise can prove whether detection, triage, and response hold under pressure. If those aims are blurred, the result may be technically sound but operationally useless.

The clearest sign is a mismatch between the deliverable and the decision owner’s real need. If leaders need to know whether a control is exploitable in practice, then a resilience-style exercise will not answer that. If they need to know whether the organisation can detect and contain an attack, then a vulnerability-oriented report alone is not enough. The wrong purpose usually shows up as “good findings” with no decision value.

This is why outcome framing matters before the work starts. The right test design defines what success looks like, what evidence must be produced, and what question the sponsor will use the result to answer. Without that, teams often optimise for noise, drama, or volume of findings instead of the specific control or response question the business actually has.

How misuse shows up in practice

Misuse usually becomes visible through the language of the request and the shape of the report. Phrases like “find everything,” “see what you can get away with,” or “make it realistic” often signal that the sponsor has not defined whether they want exploitability, detection quality, response readiness, or control validation. The work then drifts toward whatever is easiest to demonstrate rather than what is most decision-relevant.

Another warning sign is when the exercise rewards theatrical compromise over actionable coverage. If the report focuses on one dramatic path but does not explain how common control failures were tested, the engagement may have been treated as a proof-of-skill event instead of a governance input. That is especially common when red teaming is commissioned but the organisation really needed a control assessment, or when pentesting is commissioned but the organisation really needed a response rehearsal.

It is also a misuse signal when no one can state what would change after the engagement. If the output will not change a remediation priority, a control investment, a monitoring rule, or an operational playbook, then the exercise may have been run for reassurance rather than for risk reduction. NIST Cybersecurity Framework 2.0 is useful here because it forces the conversation back to govern, identify, protect, detect, respond, and recover outcomes.

Choosing the right form of test for the decision

Use a pentest when the question is, “Can this weakness be exploited here, under these conditions?” Use red teaming when the question is, “Would we notice, contain, and respond if an adversary tried?” Those are different security questions, and they require different scoping, rules of engagement, and success criteria. A report that mixes them without saying so is often a sign the sponsor wanted multiple answers from one exercise.

If the organisation is testing AI agents or delegated tool use, scope discipline matters even more. An exercise about red teaming AI agents for identity abuse is not the same as a general application test, because privilege, delegation, and tool access can be the real attack surface. Likewise, a procurement or vendor-selection exercise should not be mistaken for a security validation exercise just because it mentions red teaming in the requirements. the AI security platform buyer's guide helps distinguish evaluation of tools from evaluation of live control effectiveness.

Good practice is to define the target decision first, then choose the method that can actually support it. That usually means separate exercises for exploitability, detection coverage, and response readiness when each question matters. Combining them is possible, but only when the sponsor accepts that the result will be broader and less precise than a single-purpose test.

Practitioner Guidance

What to prioritise: Ask the sponsor to name the decision that will be made from the result before any testing starts. If they cannot say whether they need exploitability proof, detection validation, or response validation, the engagement scope is already at risk of being misused.

What to verify: Check whether the rules of engagement, success criteria, and report template all point to the same outcome. A mismatch between those three is a strong indicator that the exercise will produce interesting output but poor operational value.

Common mistake: Treating a red-team win as if it automatically proves control quality, or treating a pentest finding as if it automatically proves readiness. Those are related but not interchangeable claims.

Decision rule: If the sponsor wants to change a remediation priority, use the engagement to validate exploitability and control failure. If the sponsor wants to change monitoring or incident response, use a scenario-driven exercise that measures visibility, escalation, and containment.

Practitioner takeaway: The test is being used for the wrong purpose when its evidence cannot support the decision that justified the spend, because that is when security work becomes performance instead of control validation.

Related resources from NHI Mgmt Group

• What do security teams get wrong about continuous pentesting and red teaming in fast-changing environments?
• What are the signs that AI pentesting is being used in the wrong phase?
• Why do secrets stay dangerous even when they are no longer actively used?
• What do enterprises get wrong about AI red teaming maturity?