The most common red team mistake we see in scoping is asset-based framing. "Test our cloud environment." "Test our internal network." "Test our SaaS." Those are pentest scopes, not red team objectives. The result is a red team that produces pentest-style findings while burning a red team budget.
Red teams are scoped by objective. The objective is what a real adversary would chase. Here are five objective patterns we use repeatedly, the kind of engagement each produces, and when each makes sense.
Data exfiltration of a specific dataset
The objective: "Get a copy of the customer PII table from the production database, deliver it to an attacker-controlled endpoint, without alerting the SOC."
What this tests: the entire path from internet-exposed surface to the data, plus the detection and response controls that should fire along the way. Network monitoring, EDR, cloud audit logs, DLP, anomaly detection on database queries.
When to scope this: you have a specific high-value dataset (customer PII, source code, financial records, medical records) and the question is whether your existing controls would catch the path.
Trade-off: gives a binary success/fail signal at the end. Less useful for measuring detection quality along the path; the SOC may catch the exfiltration but miss the foothold and the lateral movement that led to it.
Privilege escalation to a named account
The objective: "Compromise the AWS root account for the production org" or "Become Domain Administrator without using a known-vulnerable path."
What this tests: identity-and-access controls, escalation paths in cloud and AD, the trust chain between identity providers, the blast radius of compromised admin tooling (Jenkins, ArgoCD, Terraform Cloud).
When to scope this: post-migration to cloud, or after a major IAM redesign, or before a SOC 2 fieldwork window where the auditor will ask about privileged access controls.
Trade-off: success criterion can be unclear (is partial privilege escalation a success?). Define what "compromise" means in writing during scoping.
Persistent foothold across reboot and remediation
The objective: "Establish persistent access to the production environment that survives a routine security operations response (alert investigation, EDR reinstall, AD reset of suspected accounts)."
What this tests: depth of the response process. Most SOCs are good at responding to individual alerts. Few are good at confirming an environment is clean after a response. This objective surfaces the difference.
When to scope this: mature SOC, second or third red team engagement, board concern about resilience to a sustained adversary.
Trade-off: hardest objective to scope safely. Requires explicit RoE around what "persistent access" means and how the engagement ends. Always pair with a designated trusted contact who can call abort.
SaaS tenant takeover via supply chain
The objective: "Compromise the production tenant of the company's primary SaaS dependency (e.g., the company's own AWS org, GCP project, GitHub Enterprise org, Workday tenant, Salesforce org) by entering through a third-party integration."
What this tests: the trust boundaries your team has accepted with third parties. Vendor risk turned into a real attack path. OAuth app abuse, MCP server compromise, integration platform takeover.
When to scope this: your security review process passes vendors but does not test what they could do if compromised. This is now most security review processes.
Trade-off: scope must include the third-party integrations you actually use. Engagement involves coordinating with vendors. Some vendors are uncooperative; document this as a finding.
Detection-and-response performance against a named technique set
The objective: "Execute every technique from MITRE ATT&CK tactic TA0008 (Lateral Movement) against the production environment. Document which fired, which alerted, which were missed, and the mean time from execution to alert."
What this tests: SOC tooling coverage and tuning. The deliverable is a coverage map, not a story.
When to scope this: you bought a new SIEM or EDR, you need to validate it works, or you are due for a tuning sprint. Often paired with a purple-team workshop.
Trade-off: more like a BAS engagement at scale than a traditional red team. Useful but lacks the narrative impact of a goal-based engagement for board reporting.
Common scoping mistakes
Patterns we see in scoping calls that produce worse engagements:
- "Test everything." Unbounded scope, infinite budget required, no useful conclusion at the end.
- "Make sure you do not break anything." Defines failure but not success. The engagement defaults to safe-but-shallow exploration.
- "We want a clean report." Red teams that produce clean reports are red teams that did not try. If the result is foreordained, it is theater, not exercise.
- Scope that excludes the most likely paths. "Test our cloud but not phishing the helpdesk." "Test our network but not the contractor laptops." These are the paths a real adversary uses.
What a well-scoped engagement looks like
Three sentences that define the engagement at intake:
- Objective: One concrete outcome. "Exfil a copy of customers.db to attacker-controlled S3."
- Success and failure criteria: What counts as objective met. What ends the engagement (success, failure, abort).
- Boundaries: What is explicitly out of scope. Subsidiaries, contractor systems, specific data classifications.
Everything else is methodology and rules-of-engagement detail. Get those three sentences right and the engagement runs itself.
"The shift from 'test our environment' to 'reach customer PII and tell us what we missed' changed how we interpreted the result. We stopped arguing about whether findings were valid. We started arguing about what to fix first." — CISO at a US fintech, November 2025
If your team is preparing for a red team
Spend the prep call defining the objective. Get the executive sponsor to commit to the objective in writing. Define what success and failure look like before the engagement starts, not after the report lands. The engagement will be more useful, and the result will be defensible regardless of outcome.