Regulators now define a serious red team by outcome, not by an asset inventory. The European Central Bank's TIBER-EU framework requires tests that are, in its words, "tailor-made to simulate an attack on the critical functions of an entity and its underlying systems." The EU's DORA threat-led penetration testing standard, directly applicable across member states since 2025, makes financial entities document the specific critical or important functions in scope and run at least three attack scenarios spanning confidentiality, integrity, and availability. The lesson for any buyer, regulated or not, is the same: a red team is scoped by what an adversary should try to achieve, starting from the assets you cannot afford to lose.
Those assets are your crown jewels, and the outcomes are your objectives. Define both before you write the RFP and every downstream decision, budget, timeline, rules of engagement, and success criteria, follows cleanly. Skip that work and you buy activity instead of an answer to the one question that matters: can an attacker reach what you most need to protect, and would you catch them on the way?
The short answer: how to scope a red team by objectives and crown jewels
To scope a red team by objectives and crown jewels before your RFP, work through four steps in order:
Identify your crown-jewel assets: the systems, data, and business functions whose compromise would cause the most damage.
Translate each crown jewel into an objective and a flag: a specific, provable outcome that shows the asset was reached.
Choose a starting point for each objective: assumed breach, which begins from an internal foothold, or full-scope, which earns the foothold from outside.
Define success criteria and rules of engagement: so everyone agrees what "done" and "in bounds" mean before work starts.
The rest of this guide expands each step, hands you an objectives worksheet to attach to your RFP, and lists crown-jewel examples by sector so you can benchmark your own list.
Crown jewels and objective-based red teaming, defined
Crown jewels are the small set of assets whose loss, exposure, or disruption would do the most harm to your organization. They are rarely your whole estate. For most companies the crown jewels are a handful of things: the customer data store, the money-movement path, the source-code and build pipeline, the identity provider that unlocks everything else, and the one or two business functions that generate revenue. Crown jewel analysis is the exercise of naming that short list and ranking it by impact, so testing effort concentrates where a breach would be worst.
Objective-based red teaming, sometimes called threat-led red teaming, is an engagement scoped around reaching those crown jewels the way a real adversary would, rather than enumerating every vulnerability on every host. The team is given a set of objectives ("obtain and exfiltrate 10 records from the customer database," "authorize a payment from the treasury system") and works toward them using whatever realistic path the environment allows. This mirrors how national frameworks operate. The Bank of England's CBEST and the ECB's TIBER-EU both build the test around threat intelligence and an organization's important business services, not a flat scope document.
The difference between objectives and scope is worth stating plainly, because buyers conflate them. Scope is the boundary: which environments, domains, and systems the team may touch. Objectives are the goals: what the team is trying to achieve inside that boundary. A good RFP defines both. Objectives tell the team where to aim; scope tells them where to stop.
The four-step method to scope by outcome
Step 1: Identify your crown-jewel assets
Run a short workshop with the people who know where value and risk actually sit: security, engineering, and a business owner from each critical function. Ask a single question for each candidate asset: if an attacker fully controlled or exfiltrated this, what would it cost us in money, trust, safety, or regulatory exposure? Keep only the assets where the honest answer is "severe." A useful crown-jewel list is short, usually five to ten items, and ranked. If everything is a crown jewel, nothing is, and the red team has no way to prioritize.
Capture each one with its business owner, where it lives (which environment, cloud account, or network segment), and what already protects it. That context is what turns a name on a list into a testable target.
Step 2: Translate crown jewels into objectives and flags
An objective is the outcome an attacker would pursue against a crown jewel. A flag is the concrete, agreed proof that the objective was met. "Access the customer database" is vague and hard to grade. "Retrieve 10 specific records containing PII and place a benign marker file in the export bucket" is an objective with a flag: unambiguous, provable, and safe to demonstrate without real harm.
Write objectives in the attacker's voice, tied to impact, and make each one binary so the debrief is not a debate. Mapping each objective to the relevant tactics in MITRE ATT&CK helps here: it gives you and your provider a shared vocabulary for the techniques a scenario is meant to exercise, from initial access through exfiltration or impact.
Step 3: Choose assumed breach or full-scope for each objective
Every objective needs a starting point. Assumed breach hands the team a realistic internal foothold, for example a standard employee laptop or a low-privilege account, and measures how far they get and how fast you detect them. Full-scope makes the team earn that foothold from the outside, testing your perimeter and human layer along the way. Neither is better in the abstract; the right choice depends on the question the objective is meant to answer. We break the tradeoff down in Assumed Breach Engagements Explained, and you can mix models across objectives in one engagement.
Step 4: Define success criteria and rules of engagement
Success criteria state what counts as reaching an objective and what the team should do when they get there: capture the flag, stop, and document, rather than press on into live systems. Rules of engagement set the guardrails: the testing window, which production actions are off-limits, how to deconflict with a real incident, whether the blue team is blind or briefed, and who to call if something breaks. Locking these down before the RFP is what keeps an outcome-based test safe and legally clean.
Crown-jewel examples by sector
Use this table to pressure-test your own crown-jewel list. Each row pairs a common crown jewel with an example objective and flag, written the way a red team would receive it.
Sector | Crown-jewel asset | Example objective and flag |
|---|---|---|
Financial services | Payment and treasury systems | Authorize a test payment or stage a fraudulent transfer in a controlled account, and drop a marker in the transaction log |
Healthcare | Patient records (EHR) | Retrieve 10 designated test-patient records and place a benign marker file in the records export path |
SaaS | Multi-tenant production database | Read data across a tenant boundary you should not cross, and prove it with a marker record in a second tenant |
E-commerce | Customer PII and card data flow | Reach the cardholder data environment and exfiltrate a marked, non-sensitive canary record |
Manufacturing / OT | Production control network | Cross from IT into the OT segment and reach an engineering workstation, without touching a live process |
Any sector | Identity provider (SSO / IdP) | Obtain privileged control of the identity platform and mint a token for a crown-jewel application |
Notice that every objective ends in a provable flag and stops short of real damage. That is the discipline outcome-based scoping enforces: you learn whether the asset is reachable without ever putting it at risk.
The red team objectives worksheet
Attach a filled version of this worksheet to your RFP. It forces the decisions above into one page and gives every bidding provider the same brief, which makes proposals comparable and pricing accurate.
Worksheet field | What to fill in | Worked example |
|---|---|---|
Objective ID | A short label | OBJ-1 |
Crown jewel | The asset at stake | Customer database (PII) |
Business owner | Who owns the risk | VP Data |
Objective | The attacker outcome | Exfiltrate customer PII from production |
Flag | The provable proof | 10 marked test records plus a marker file in the export bucket |
Starting point | Assumed breach or full-scope | Assumed breach, standard employee laptop |
In scope | Environments the team may touch | Production web app, corporate identity, cloud account A |
Out of scope | Hard boundaries | Third-party payment processor, customer-owned data |
Success criteria | What "done" means | Flag captured, then stop and document |
Detection goal | What the blue team should catch | Alert on anomalous bulk export within 30 minutes |
Fill one row per objective. Three to five well-formed objectives usually give a red team enough to work with while keeping the engagement focused and affordable. If you want help sizing the effort and cost against your objectives, our guide to red team engagement cost breaks down the drivers.
Assumed breach or full-scope: match the start to the objective
The starting point you choose shapes what the engagement can tell you. Full-scope answers "can an outsider get in and reach the objective without being caught?" and exercises your perimeter and people. Assumed breach answers "once someone is inside, how far can they get and how fast do we detect them?" and puts more of the budget into the internal blast radius. The human layer matters either way: Verizon's 2025 Data Breach Investigations Report found the human element in 60 percent of breaches, and credential abuse as the initial access vector in 22 percent, which is exactly why full-scope engagements test phishing and identity while assumed breach starts from the stolen-credential reality most intrusions begin with.
For the broader question of when a red team, a penetration test, or continuous validation is the right instrument, see Red Team vs Penetration Test vs Continuous Validation. This guide stays narrow: defining the objectives and crown jewels that any of those instruments will be scoped around.
Rules of engagement to lock down before the RFP
Objectives tell the team where to aim. Rules of engagement keep the test safe, and they belong in the RFP so bidders price the same constraints. Settle these before you go to market:
Testing window and blackout dates: when work may run, and the days it must not.
Prohibited actions: no denial-of-service, no changes to live customer data, no touching a defined out-of-scope list.
Deconfliction: a named contact and a code word so a real incident is never mistaken for the test, and vice versa.
Blue-team visibility: blind (the defenders do not know) or briefed (a purple-team style exercise), decided per objective.
Data handling: how any sensitive data touched during the test is stored, reported, and destroyed.
Escalation and stop conditions: who can pause the engagement, and what triggers an immediate stop.
If you want a fuller treatment of boundaries, environments, and pre-engagement paperwork, our penetration test scoping guide covers the mechanics that apply to red teams too.
How Stingrai scopes red teams by outcome
Stingrai runs red team engagements the way this guide describes: crown jewels first, objectives and flags next, then a starting point and rules of engagement agreed with you before a single packet is sent. Our senior operators, holding certifications including OSCE3, OSEP, and CRTO, drive the adversary scenarios end to end, mapping each objective to real-world tactics and proving reachability with agreed flags rather than a vulnerability dump.
Where an objective centers on a web application, our autonomous testing agent Snipe extends the team's reach into the complex classes that matter most for crown-jewel data: IDOR, broken authorization, and business-logic flaws that let one user reach another tenant's records. Snipe runs both black-box and white-box testing and can gate pull requests so the same class of flaw does not return. The engagement evidence also supports your compliance program, giving you red team results you can put in front of a SOC 2, ISO 27001, or PCI DSS assessment. As a firm-level CREST-accredited provider founded in 2021, Stingrai scopes to your outcomes, and you can size an engagement against your objectives on our pricing page.
Frequently Asked Questions
How do I scope a red team by objectives and crown jewels before I write the RFP?
Work through four steps. First, identify your crown-jewel assets, the systems, data, and functions whose compromise would hurt most. Second, translate each into a concrete objective and a flag that proves the asset was reached. Third, choose a starting point for each objective, assumed breach or full-scope. Fourth, define success criteria and rules of engagement. Capture the result in a one-page objectives worksheet and attach it to the RFP so every provider bids the same brief.
What is crown jewel analysis in a red team?
Crown jewel analysis is the exercise of naming the short list of assets whose loss, exposure, or disruption would do the most damage, then ranking them by impact. It typically produces five to ten items, such as the customer data store, the payment path, the source-code pipeline, and the identity provider. The ranked list tells the red team where to concentrate, which is what makes an engagement outcome-based rather than a broad sweep.
What is objective-based red teaming?
Objective-based red teaming, also called threat-led red teaming, scopes an engagement around reaching defined crown jewels the way a real adversary would, rather than enumerating every vulnerability. The team is given goals, for example exfiltrating marked records or authorizing a test payment, and works toward them by any realistic path. National frameworks such as TIBER-EU and CBEST use this model, building tests around threat intelligence and an organization's critical functions.
What is the difference between red team objectives and scope?
Scope is the boundary: which environments, domains, and systems the team may touch. Objectives are the goals the team pursues inside that boundary. Objectives tell the team where to aim, and scope tells them where to stop. A strong RFP defines both, because objectives without scope invite scope creep and scope without objectives produces a checklist rather than an answer.
Should I choose assumed breach or full-scope for my red team?
It depends on the question the objective must answer. Full-scope makes the team earn a foothold from outside, testing your perimeter and human layer, and answers whether an outsider can break in and reach the objective. Assumed breach starts from a granted internal foothold and answers how far an intruder gets and how fast you detect them. You can mix both across objectives in one engagement.
What are red team flags?
A red team flag is the concrete, agreed proof that an objective was met. Instead of a vague goal like "access the database," a flag is specific and provable, such as retrieving 10 marked test records and dropping a benign marker file in the export path. Flags make the debrief binary: either the flag was captured or it was not, with no room for interpretation, and they let the team demonstrate reachability without causing real harm.
What should red team rules of engagement include?
Rules of engagement should cover the testing window and blackout dates, prohibited actions such as denial-of-service or changes to live data, a deconfliction contact and code word, whether the blue team is blind or briefed, how sensitive data is handled and destroyed, and the stop conditions that let anyone pause the test. Agreeing these before the RFP keeps the engagement safe, comparable across bidders, and legally clean.
Does Stingrai scope red teams by objective?
Yes. Stingrai's red team engagements start with crown jewel analysis, then objectives and flags, then a starting point and rules of engagement agreed with you up front. Senior operators drive the scenarios and prove reachability with agreed flags, and where objectives center on web applications the Snipe agent extends coverage into IDOR, broken authorization, and business-logic flaws. You can scope an engagement against your objectives on the Stingrai pricing page.
References
European Central Bank. TIBER-EU: European framework for Threat Intelligence-based Ethical Red Teaming. 2018, updated 2024. https://www.ecb.europa.eu/paym/cyber-resilience/tiber-eu/html/index.en.html. Defines threat-led red team tests scoped to an entity's critical functions and underlying people, processes, and technologies.
European Central Bank. TIBER-EU Guide: how to implement the framework for the DORA threat-led penetration testing of critical or important functions. 2025. https://www.bankingsupervision.europa.eu/ecb/pub/pdf/ssm.supervisory_guide202511.en.pdf. Sets out DORA's scope-specification and multi-scenario requirements for threat-led testing of critical or important functions.
Bank of England. CBEST Threat Intelligence-led Assessments. https://www.crest-approved.org/membership/cbest/. The UK regulator-led framework that builds red team assessments around threat intelligence and an organization's important business services.
Verizon. 2025 Data Breach Investigations Report. 2025. https://www.verizon.com/business/resources/reports/2025-dbir-data-breach-investigations-report.pdf. Analyzes breach data and reports the human element in 60 percent of breaches and credential abuse as the initial access vector in 22 percent.
MITRE. ATT&CK Knowledge Base. https://attack.mitre.org/. A curated matrix of adversary tactics and techniques used to map red team objectives to real-world attacker behavior.
Ready to scope a red team around your crown jewels? Talk to Stingrai's red team about turning your objectives into a focused, outcome-based engagement, or size the effort on our pricing page.
