What the conversation should produce.
- A signed statement of the exercise objective and scope.
- A rules of engagement document specifying knowledge, access, and prohibited techniques.
- A narrative report that distinguishes observed facts, hypotheses, and untested areas.
Choose a business objective rather than a vulnerability quota
A red team exercise should begin with a business question, not a checklist of systems to probe. The objective might be to understand whether an attacker could reach customer data, disrupt operations, or manipulate financial records. This focus shapes every subsequent decision, from scope to evaluation criteria. When the goal is a vulnerability quota, the exercise drifts toward finding any weakness, which produces noise rather than insight. A business objective forces the team to prioritise paths that matter to the organisation, and it gives leadership a clear lens through which to interpret the results. Without it, the exercise risks becoming a technical scavenger hunt that satisfies no one.
Define success as a useful answer to the agreed question. That answer may include a verified path, a defensive intervention or an important limit on what could be observed. Document which critical assets and dependencies matter to the scenario, and why they were selected. An objective does not by itself prevent scope changes; a named decision-maker and a change process are still needed. Keep areas outside the exercise visible so leadership can understand the result without mistaking a bounded investigation for a complete view of organisational security.
Agree the starting knowledge, access and exercise boundaries
The starting conditions of a red team exercise must be documented and agreed before any work begins. This includes what the team knows about the environment, what access they hold, and what techniques are permitted or prohibited. Ambiguity here leads to disputes after the fact, when a finding is challenged on the grounds that it relied on an unauthorised method or an assumption that was never validated. The agreement should cover physical access, social engineering, network probing, and any interaction with third parties. It should also specify what is off-limits, such as systems outside the agreed scope or techniques that could cause operational disruption.
Choose starting knowledge and access to match the question. An assumed-compromise exercise may deliberately begin with a supplied test account, while an external scenario may begin with less information. Neither is automatically more realistic or more valuable. Record the assumption so readers can distinguish what the team demonstrated from what it was given. Agree how unexpected conditions, including signs of an unrelated incident, will be escalated. The purpose is a controlled investigation whose conclusions remain understandable after the original participants have left the conversation.
Coordinate the control group, pause conditions and evidence handling
Name a control group or designated contacts with the authority and information needed to oversee the exercise. Their responsibilities should be clear to the participants who need to know, even where some defenders are intentionally unaware of the scenario. Agree conditions that require a pause, such as unexpected service impact, uncertain ownership of a newly encountered asset or signs of an unrelated incident. Record how the decision is communicated and who can approve a restart. Oversight must be workable in the actual operating environment, not just a contact list in the proposal.
Collect enough evidence to support the agreed question while avoiding unnecessary sensitive material. Record relevant timestamps, the source of each observation, the conditions under which it was obtained and any known gaps. Use agreed storage, access and retention arrangements for the assessment record and working notes. The control group needs sufficient visibility to govern the exercise; that does not mean every member should receive every piece of raw data. Evidence quality depends on context and traceability as well as careful handling of the material itself.
Evaluate detection, investigation and decision-making together
Where response is part of the objective, examine detection, investigation and decision-making as a connected chain. Record whether the expected telemetry was available, whether an alert appeared, what an analyst could see and which decision followed. A break in one stage does not make the original technical observation meaningless, but it changes the improvement needed. Avoid assigning a cause before checking the evidence. Missing context, unclear ownership and a technical collection problem can look similar in a high-level exercise timeline while requiring very different responses.
Use the reconstruction to test assumptions about how the organisation works. A deployed tool does not establish that its output reached the right person, and an acknowledged alert does not establish that investigation was possible. Ask what information was available at the time, rather than judging participants only with hindsight. An apparently ignored alert may reflect workload, routing, prioritisation or missing context. Discuss the contributing conditions with the relevant owners and record the uncertainty where the exercise cannot distinguish between them.
Reconstruct a useful narrative without overstating coverage
The output of a red team exercise is a narrative, not a list of vulnerabilities. A useful narrative explains how the objective was approached, what was observed, what was hypothesised, and what remains untested. It must distinguish between facts that were directly observed, conclusions that were drawn from those facts, and assumptions that were never verified. Overstating coverage is a common failure, often driven by the desire to present a more impressive result. But a narrative that claims more than the exercise delivered is not just misleading; it is dangerous, because it may lead leadership to believe the organisation is more secure than it is.
A disciplined narrative also acknowledges the limits of the exercise. It states clearly what was tested, what was not, and why. It does not present a single attack path as representative of the organisation's overall posture, nor does it imply that a successful path means failure. The narrative should be structured so that readers can follow the logic from objective to observation to conclusion, and so that they can identify where their own assumptions might differ. This transparency is what makes the exercise useful for decision-making, rather than merely a report to be filed.
Turn observations into owned improvements and a bounded retest
Observations only matter if they lead to owned improvements. Each finding should be assigned to a specific owner, with a clear description of what needs to change and why. The improvement should be tied to the business objective, not to the technical detail of the finding, because the point is to reduce the risk the exercise was designed to explore. Owners should be given the context of the full narrative, not just the isolated observation, so they can make informed decisions about the appropriate response. Without ownership, findings become a catalogue of problems that no one is responsible for solving.
A retest should answer a defined verification question. It may revisit a specific control change, a detection path or an agreed portion of the earlier scenario, depending on the improvement being claimed. Confirm scope, access and operating conditions again rather than assuming the original permissions still apply. State which variations and neighbouring dependencies remain untested. Repeating a scenario can be useful when the purpose is explicit; the limitation is treating a repeated success as proof that every possible path has been closed.
An assumed-compromise exercise around a sensitive workflow
Consider an illustrative organisation that wants to understand whether an unusual access request affecting a sensitive business workflow would be detected, investigated and escalated. The exercise begins with a supplied test identity and a representative test environment. The starting access is an explicit assumption, not an achievement claimed by the assessment. Business and technical owners agree the objective, the actions that are permitted and the evidence that can be collected. A designated control group can pause the work if the scenario encounters an unapproved dependency or affects normal operations.
- Agree what evidence would show the intended boundary was maintained, and what observation would justify further investigation. Use representative records so the question can be examined without collecting live sensitive data.
- Reconstruct the event with the detection and system owners. Separate an unavailable signal from an unhelpful alert or an unclear escalation, and record where the evidence cannot yet establish a cause.
- Give each agreed improvement an owner and define a specific follow-up check. Confirm the environment and permissions for that check rather than treating the original exercise as open-ended authorisation.
The scenario establishes a way to examine a specific trust and response question under stated assumptions. It does not demonstrate that an external attacker could obtain the supplied access, prove all sensitive workflows are protected or establish how every real incident would unfold.
Useful decision table for scoping a red team exercise
| Question | What to establish | Useful output |
|---|---|---|
| What business outcome are we testing? | The specific risk the exercise is designed to explore, not the systems to probe. | A one-page statement of the objective, signed by the business owner. |
| What knowledge and access does the team start with? | The exact starting conditions, so findings can be evaluated against them. | A written rules of engagement document, including prohibited techniques. |
| Who can pause the exercise and when? | The authority, the conditions, and the process for pausing or stopping. | A contact list and a pause decision log. |
Scroll the table horizontally on smaller screens.
Useful questions.
How do we know if the exercise was successful?
Success is measured against the business objective, not against the number of findings. If the exercise answered the question it was designed to explore, and the organisation has a clear record of what was observed and what remains untested, it was successful. A finding-rich exercise that fails to address the objective is not successful, and a finding-poor exercise that clarifies the organisation's risk posture may be.
Can a red team exercise prove our systems are secure?
No. An exercise can only show what happened during a limited period, under specific conditions, against a specific objective. It cannot prove the absence of vulnerabilities, the effectiveness of controls in all scenarios, or the resilience of the organisation to attacks it was not designed to explore. The value of the exercise lies in what it reveals about the organisation's understanding of its own risk, not in any claim of security.
Further reading: NIST SP 800-115: testing and assessment guidance. This independent resource provides background; no affiliation, certification or endorsement is implied.