Red teaming
Crown jewels first: how we scope a red team engagement
A useful red team exercise starts with business priorities, clear rules and a safe way to learn. Here is how to turn critical assets into a focused, responsible test.
JODOR Research · 28 October 2026 · 5 min read
A red team engagement is most useful when it tests a question the organisation actually needs answered. Before choosing tools or attack paths, stakeholders should agree what matters most, what is in scope and what must remain safe.
Start with the outcome, not the technique
Work with business and security owners to identify the services, information or decisions whose disruption or exposure would matter. Describe those priorities in operational terms: what must remain available, which access would create material risk, and what evidence would demonstrate that a control worked.
That conversation helps distinguish a red team exercise from a broad vulnerability scan. The objective is to evaluate how people, processes and technology respond to a carefully bounded scenario, not to maximise the number of findings.
Define the boundaries together
Document authorised systems, accounts, locations, testing windows, permitted methods and explicit exclusions. Identify who can pause the exercise, how urgent concerns will be escalated, and how the team will protect sensitive data encountered during testing. Where suppliers or shared services are involved, obtain the necessary approvals before including them.
Agree the rules of engagement before work begins. They should cover evidence handling, communications, safety constraints and the process for stopping or changing the test. A named business contact and a trusted emergency channel make it possible to act quickly if something unexpected occurs.
Make the result useful
The final debrief should connect observations to the original objective. Explain what the team attempted, what safeguards were effective, where detection or response could improve, and which recommendations deserve attention first. Separate confirmed observations from hypotheses and note limitations that affect interpretation.
Key takeaways
- Begin with business-critical outcomes and a specific learning objective.
- Agree scope, exclusions, safety controls and escalation routes in writing.
- Coordinate with system owners and suppliers before testing shared environments.
- Report the path and defensive lessons, not just a list of technical findings.
