---
{
  "title": "Red teaming",
  "summary": "Evaluate the organization’s ability to detect and respond to an agreed adversary scenario.",
  "topic": "offensive",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "units": [
    1
  ],
  "aliases": [],
  "sources": [
    {
      "title": "NIST: Technical Guide to Information Security Testing and Assessment",
      "url": "https://csrc.nist.gov/pubs/sp/800/115/final"
    }
  ],
  "published": "2026-10-02",
  "editorialVersion": 2
}
---

## The idea

Red teaming is an objective-based assessment that can examine people, processes, and technology under a defined threat scenario. It typically focuses on whether a realistic chain of activity can achieve an objective and how defenses respond, rather than listing every individual weakness. Scope and controls remain essential. Purple teaming involves collaborative learning between offensive and defensive practitioners, with emphasis on improving detection and response.

## In practice

An authorized exercise tests whether defenders recognize a simulated account compromise and coordinate a response, then reviews observations jointly.

## A common misunderstanding

A red-team engagement is not unrestricted permission to disrupt systems or collect sensitive material.

## Check your understanding

How does a red-team goal differ from a typical scan?

**Think it through:** It evaluates an agreed outcome and defensive performance across a sequence, not merely known technical weaknesses.

## Define an outcome and a threat hypothesis

A red-team exercise starts with an agreed question about organizational resilience. For example, can a simulated compromised contractor account reach a synthetic design document, and will defenders recognize and contain the sequence? The scenario should explain why the chosen access and behaviors are plausible. It should not claim to reproduce an entire real-world adversary merely because it uses the same technique labels.

The objective determines what evidence matters. Reaching the synthetic document may demonstrate a prevention gap. Whether an alert fired, an analyst investigated, and the response team acted reveals detection and response performance. These are related outcomes, but one does not establish the others. A blocked action can still provide valuable evidence about defensive visibility.

## Keep realism bounded

Exercises need safety controls, designated contacts, prohibited activities, and a way to distinguish exercise artifacts from genuine incidents. Using synthetic accounts and clearly identified test data helps keep evidence meaningful while limiting exposure. If an unexpected outage or real compromise appears, the agreed pause process should take precedence over completing the scenario.

A fictional engineering company might allow the exercise to use a prepared test identity with realistic permissions. This assumes an initial compromise rather than attempting every possible entry route. The assumption should be stated plainly in the report. It can make the exercise more useful by concentrating effort on the organization's ability to limit and detect subsequent actions.

## Review the sequence together

After the exercise, build a timeline that pairs test actions with defensive observations. An alert may exist but arrive too late, lack useful context, or never reach the right team. Conversely, defenders may act through a help-desk report that the technical team initially overlooked. Joint review turns these differences into concrete detection and response improvements.

For a tabletop version, write five simulated events and let a partner describe the evidence they would need to investigate each one. Compare expected and available telemetry. This develops threat-informed thinking without requiring intrusive activity or equating successful learning with the number of systems compromised.

## Keep exploring

- [[rules-of-engagement]]
- [[mitre-attack]]
- [[detection-engineering]]