1.1 Defining Mission and Scope

Defining Mission and Scope

A red team without a defined mission and documented scope boundaries cannot deliver consistent, defensible value to the organization it serves.

Building a Mission Statement That Actually Guides Decisions

Before a red team can execute a single engagement, it must answer a deceptively simple question: why does it exist? The mission statement is not a formality or a box to check during program setup. It is the primary decision-making tool that every team member will reference when planning an operation, escalating a finding, or explaining the program’s value to a skeptical executive. A well-constructed mission statement has four distinct components, each serving a different function.

The first component is purpose: the problem the team exists to solve. Common purposes include validating that security controls work as designed, testing how well the incident response team detects and responds to adversary behavior, discovering unknown vulnerabilities before real attackers find them, and providing realistic scenarios that train defenders to recognize and react to threats. The purpose statement should be specific enough to guide prioritization decisions. “We exist to improve security” is not a purpose; “we exist to validate detection and response capability against the threat actors most likely to target this organization” is.

The second component is stakeholders: who the team serves and what those stakeholders need. Executive leadership needs risk posture visibility and assurance that security investments are working. Security operations needs realistic challenge scenarios and feedback on detection gaps. Compliance functions need documented evidence that controls meet regulatory requirements. Business units need enough engagement to understand what threats could affect their operations without so much disruption that it interferes with productivity. Because different stakeholders have different expectations, the mission statement must account for all of them while making clear how the team balances competing demands.

The third and fourth components are value proposition and success criteria. The value proposition distinguishes the red team from other security functions: penetration testing finds what is vulnerable, vulnerability scanning inventories exposures, and audit verifies documentation. The red team does something different: it emulates adversary behavior to test the whole system, not just individual components. Success criteria convert that value proposition into measurable outcomes. Detection rate improvements, response time reductions, risk exposure metrics, and post-exercise remediation rates are all legitimate measures. Without success criteria, the program cannot demonstrate progress and will struggle to defend its budget.

The difference between a mission statement that functions as a decision-making tool and one that functions as organizational wallpaper comes down to specificity and testability. A vague mission statement reads: “The red team exists to support the organization’s security program.” An actionable one reads: “The red team exists to emulate the behavior of financially motivated threat actors targeting payment systems, validate whether detection and response capabilities can identify and contain attacks before data exfiltration occurs, and provide quarterly assurance to the Risk Committee that control investments are functioning as designed.” The latter version tells operators what to prioritize, tells stakeholders what to expect, and defines a standard against which the program can be evaluated. When a new engagement request arrives, the team with the actionable mission statement can answer immediately whether it fits the mandate; the team with the vague one cannot. Authorization documents that use this level of specificity also serve a secondary function: when a stakeholder later challenges whether the red team should be testing a particular environment, the written mission provides the answer without requiring a political argument.

Scope: The Boundaries That Give the Mission Meaning

A mission statement defines why the team exists. Scope documentation defines where, what, and how it operates. These are separate concerns, and conflating them creates confusion during engagements. Scope documentation should be explicit, written, and reviewed by legal counsel before any testing begins.

Technical scope specifies the categories of testing the team is authorized to conduct: network penetration, physical security assessments, social engineering campaigns, application security testing, or wireless and radio frequency testing. This list is not just a menu of capabilities; it is a statement of what the organization has accepted risk on. Organizational scope identifies which business units, geographic locations, subsidiaries, third-party vendors, and cloud environments are within bounds. Operational scope defines how testing is conducted: announced versus unannounced, full-scope versus targeted, assumed-breach scenarios where the attacker starts with a foothold already established, continuous operations versus periodic campaigns, and whether production systems or isolated test environments are the target.

Two additional elements complete the scope framework. Explicit exclusions document systems that must never be tested, actions that are always prohibited regardless of the engagement type, and techniques that require special approval before use. These exclusions protect critical systems, preserve legal standing, and establish accountability when something goes wrong. Standing authority describes what the team can do without seeking additional approval for each engagement: pre-authorized techniques, default rules of engagement, and baseline access permissions. Standing authority reduces administrative friction for routine operations while ensuring that significant escalations still go through a formal approval process.

A concrete scope framework in a written program charter might specify technical scope as including external network assessments, internal network assessments, web application testing, phishing simulations, and physical assessments of corporate office locations. Organizational scope would cover headquarters, all domestic subsidiaries, and third-party cloud environments owned by the organization, while explicitly excluding acquisition targets not yet integrated, international subsidiaries pending legal review, and any system classified as life-safety critical. Explicit exclusions would name production database servers containing customer payment data as requiring special approval before any testing, automated scanning of Internet-facing systems as requiring forty-eight hours advance notice to the operations team, and any activity that would generate external alerts to law enforcement or regulators as out of scope without prior legal review. Standing authority would specify that phishing simulations targeting employees may be conducted without a new approval cycle, provided they use only approved pretext categories and follow the existing notification protocol. This level of specificity prevents the two most common scope disputes: a business unit that claims the red team had no authority to test their environment, and an operator who believed an action was within scope when it was not.

Choosing a Mission Model That Fits the Organization

Four distinct mission models reflect different organizational maturities and objectives. The right choice depends on what the organization most needs to learn about its security posture, not on what the red team finds most technically interesting.

Adversary simulation emulates the behavior, tools, and techniques of real-world threat actors relevant to the organization’s industry and risk profile. The goal is to test whether detection and response capabilities can identify and contain a realistic attack before it causes significant damage. This model requires a mature security program on the defensive side: an organization with no SIEM, no EDR, and no incident response plan will not learn much from adversary simulation because the simulation will succeed too easily to generate useful feedback. Adversary simulation is best suited for organizations that have built foundational security capabilities and want realistic validation.

Control validation is more focused. Rather than running full attack chains, the team tests specific security controls to verify they work as designed. Can the email gateway block a particular category of phishing attachment? Does the endpoint detection tool fire on a specific technique? Does the network segmentation prevent lateral movement between business units? This model is well suited to compliance-driven environments where the organization needs to demonstrate that specific controls are operational. Vulnerability discovery prioritizes finding unknown weaknesses through creative exploration of the attack surface: misconfigurations, logic flaws, and overlooked exposures that scanners and audits miss. Training and exercises use realistic red team scenarios to develop defender skills, with the primary goal of building human capability rather than measuring current control effectiveness. Each model serves a legitimate purpose; the mission statement should make clear which model the team is operating under, and that choice should be revisited as the organization’s security maturity evolves.

Three factors drive the choice between these models. Security maturity is the most important: adversary simulation requires mature detection and response capabilities to generate useful feedback, while control validation and vulnerability discovery provide value even when foundational capabilities are still being built. A useful diagnostic question is whether the organization’s incident response team can describe, with specificity, how they would detect and respond to a common attacker technique such as credential dumping or lateral movement via pass-the-hash. If they cannot, adversary simulation will succeed too completely to produce differentiated learning. Stakeholder need determines which question the organization most urgently needs answered. An organization that has invested heavily in endpoint detection controls but lacks confidence in whether those controls fire on realistic techniques has a different priority from one that is mapping its attack surface for the first time. Compliance mandate may determine the model in regulated industries, since frameworks such as PCI DSS and DORA impose specific control validation requirements that must be addressed before discretionary simulation work can be scheduled. When these three factors point in different directions, the compliance requirement takes precedence in the short term, maturity determines what is achievable, and stakeholder need shapes how results are framed and communicated.

Key Takeaways

• Purpose drives decisions. A specific, written mission statement ensures every team member can answer why the program exists and what success looks like.
• Scope must be explicit and documented. Technical, organizational, and operational scope boundaries should be in writing, reviewed by legal counsel, and updated whenever the engagement context changes.
• Exclusions and standing authority both matter. Documenting what is off-limits protects the organization, while documenting pre-authorized activities reduces friction for routine operations.
• Mission model selection should match organizational maturity. Adversary simulation, control validation, vulnerability discovery, and training exercises each serve different needs, and the wrong choice wastes resources while generating misleading results.
• Success criteria make the mission accountable. Measurable outcomes tied to the mission statement allow the team to demonstrate progress, defend its budget, and continuously improve its contribution to the organization.

Sources: PTES – Physical Access Assessment & Pre-Engagement  ·  NIST SP 800-115 – Technical Guide to Information Security Testing  ·  ASIS International – Physical Security Professional (PSP)  ·  Sample Client Intake Questionnaire