Red team engagements fail more often for organizational reasons than technical ones. The operators find a path, the report is thorough, and twelve months later very little has changed. That outcome is avoidable, and avoiding it is mostly about decisions made before the engagement starts.
Decide What Question You Are Asking
The most common scoping failure is an objective that sounds meaningful and is not. "Assess our security posture" gives operators no way to know when they have succeeded and gives you no way to interpret the result.
A good objective is specific, unambiguous and connected to something the business cares about. Reach the payment processing environment. Retrieve a marker record from the customer database. Obtain domain administrator privilege. Demonstrate access to the source code repository.
Pick one or two, not six. A red team that pursues six objectives is running a penetration test with worse coverage.
It is also worth asking whether a red team is what you need at all. If your external systems are unpatched and your internal network is flat, operators will take the easy route and you will learn something a penetration test would have told you for considerably less. Red teaming rewards maturity; without it, the exercise mostly confirms what you already suspected.
Keep the Circle Small
The people who know an exercise is running behave differently, whether or not they intend to. That is not a criticism of them; it is human.
The circle should be a senior security leader and an executive sponsor. They hold the authorization letter, they are the escalation path, and they have authority to stop the exercise. Nobody in security operations should know.
This creates a genuine tension, because the operations team may spend real effort investigating what turns out to be an exercise. That effort is not wasted, it is the measurement, but it should be acknowledged afterward. Teams that discover they were tested and then find out four people knew and said nothing tend to take it badly, and the sponsor's handling of the debrief matters as much as the technical result.
Write Rules of Engagement That Anticipate Problems
The rules of engagement exist for the moments when something unexpected happens, which is why they should be written before rather than during.
- Authorization in writing, held by the operators and by the sponsor, naming who authorized what.
- Explicit exclusions: systems that must not be touched, techniques that are prohibited, and a hard boundary on what actions on the objective may involve. Reaching a database is proven with a marker record, never with real customer data.
- A stop condition and who can invoke it, reachable outside business hours.
- An escalation path for genuinely critical findings. If operators discover an active intruder, or an exposure that cannot wait until the report, they need a route to tell you immediately.
- A detection policy. Decide in advance what happens if the team is caught: continue, reset, or convert to a purple team. Deciding this under pressure produces worse choices.
Give It Enough Time
Four to eight weeks is the usual range. Compressing an engagement into a week does not produce a faster version of the same result; it produces a different and less honest one, because operators forced to move quickly are noisier than real attackers and your detection results look better than they should.
Reconnaissance frequently occupies the first week or more and generates nothing visible. That is not slow progress. It is the phase where a real adversary also spends most of their effort, and skipping it is what makes an exercise unrealistic.
Plan the Remediation Before the Findings Exist
This is the step most often skipped and most responsible for engagements that change nothing.
Before the exercise starts, agree who owns remediation, what capacity they have, and when the retest is. Booking the retest in advance is the single most effective mechanism available, because it converts a report into a deadline.
Expect the findings to be structural. Red team remediation is rarely a list of patches; it is tiered administration, segmentation, credential hygiene and detection engineering. Those take quarters, not sprints, and a team without allocated capacity will not do them regardless of how good the report is.
Use the Debrief Properly
The technical report matters less than the conversation about it.
Run the debrief with the operators and the defending team together, walking the timeline: here is what we did, here is when you saw it, here is what you did next, here is what you missed and why. Done well, this is the most valuable few hours of the engagement, and defenders generally find it energizing rather than demoralizing, provided leadership frames it as a measurement rather than a judgment.
The follow-on that works best is a purple team exercise using the missed techniques as its starting point, so the detection team can build and validate coverage immediately. Then repeat the red team later to verify the improvement held.
The Underlying Point
A red team is the only exercise where an intelligent adversary actively tries to defeat what you built. That makes it uniquely honest and uniquely uncomfortable, and both of those are the point.
Organizations that get value from it are the ones that treat the result as information rather than as a verdict, and that arrive at the engagement having already decided what they will do with what they learn.
To discuss scoping a red team engagement, get in touch.
Frequently asked questions
What makes a good red team objective?
Specificity and business meaning. Reach the payment processing environment, obtain a marker record from the customer database, gain domain administrator privilege. A good objective is unambiguous about success and connects to something leadership cares about. Vague objectives like assess our security produce vague engagements and reports nobody acts on.
Who should know the exercise is running?
As few people as possible: typically a senior security leader and an executive sponsor. They hold the authorization letter, act as the escalation path, and can stop the exercise. The security operations team must not know, because their unprompted response is precisely what is being measured. Every additional person who knows degrades what the exercise can tell you.
How long should a red team engagement run?
Four to eight weeks is typical. Real adversaries are patient, and compressing the exercise into days forces operators to move faster and louder than an actual attacker would, which makes the detection results misleadingly favorable. Reconnaissance alone frequently occupies the first week or more, and that is time well spent.
What should we do if the red team is detected early?
Treat it as a good result and decide deliberately what happens next. Common options are to continue and see whether the response actually contains the activity, to reset to a new starting position and continue, or to convert the remainder into a purple team exercise. Decide the policy during scoping rather than in the moment.
How do we make sure the findings actually get fixed?
Agree before the engagement who owns remediation, allocate capacity for it, and schedule a retest. The most common failure is an excellent report delivered to a team with no time to act on it. Booking the retest at the same time as the engagement is the simplest mechanism that reliably works, because it creates a deadline.