Red Team Assessment Services: What You Are Buying and How It Is Measured

A red team assessment is not a penetration test with a bigger invoice. It is an experiment with one independent variable: whether a competent adversary pursuing a stated objective against your live environment is seen, understood and stopped before reaching it. That sentence contains the whole discipline, and it also contains the reason most engagements fail to produce anything you can act on. If the objective is vague, the experiment has no success condition. If the detection side is not instrumented, the result measures your logging gaps rather than your defences. If nobody defined what counts as "detected", the report ends up as a narrative of clever things an operator did - interesting, unverifiable, and impossible to compare with next year. This guide is about turning that narrative into an instrument: objectives you can grade, rules of engagement that keep the exercise lawful, a five-stage detection model with four ratios you can put in front of a board, a time-to-detect number that does not flatter itself, and a closure criterion that stops the finding quietly returning.

A red team assessment answers one question, and it is not "are we vulnerable"

Ask a room what a red team does and the answers converge on attacking things. Ask what question the attack is supposed to answer and the answers scatter. The useful definition is narrower: a red team tests whether your organisation can detect and respond to an adversary who is actively trying not to be detected. Vulnerability discovery is a side effect. If the team finds a way in and nobody notices for three weeks, that is the finding - the way in is almost incidental, because the way in will be patched or not, while the blindness persists.

That framing changes what a good outcome looks like. A red team that fails to reach its objective while your analysts watch it fail, chase it off two hosts and write a clean incident timeline is a success, and it should be reported as one. A red team that reaches the payroll database in four hours because a service account held domain administrator rights is a failure of the defence even though the operator had a very good day. Buyers who do not internalise this reward the wrong behaviour: they read the report for the dramatic path and skip the detection timeline, which is the only part describing their organisation rather than the operator's skill.

There is a scope implication that gets missed too. Because the test is about detection and response, the in-scope surface is whatever an attacker would plausibly touch on the way to the objective: identity provider, endpoints, cloud control plane, email, VPN and edge devices, the service desk, and often the people who hold credentials. An engagement that lists "the external IP range" as its scope has quietly redefined itself as an external penetration test. That is a legitimate purchase. It is not this one.

Two honest caveats belong at the front rather than in the appendix. First, one campaign is a sample of one: your defences are tested on the day, by these operators, against these objectives. It supports statements about what happened, not about general resilience, and anyone presenting it as a rate or a score is overselling. Second, red teaming measures the ability to detect activity it actually generated. Silence is not evidence of control. The team not being caught can mean the controls worked, or that telemetry never left the host, or that nobody was watching that queue at 03:00 on a Sunday. Separating those three is most of the analytical work, and it is the part the sales pages leave out.

Red team versus penetration test: the difference is the question, not the effort

The comparison tables all say the same thing in different fonts: a penetration test finds vulnerabilities in a defined scope, a red team pursues an objective across whatever scope the objective requires. That is correct, and it is not the useful distinction. The useful one is that a penetration test is coverage-led and a red team engagement is goal-led, and the two produce different kinds of evidence.

A penetration test answers "what is wrong with this system?", and its quality is judged by whether the tester worked the agreed surface exhaustively and proved what they found. Its unit of output is the finding, with a proof of concept and a fix. You can count findings, rank them and close them. A red team answers "would we know?", and its quality is judged by whether the path was realistic and whether the measurement of the response was honest. Its unit of output is a path with a detection trace. Paths are not countable the way findings are; you can only be precise about what was attempted and what was observed.

The practical consequence for a budget conversation is that the two are not substitutes and the order matters. Running a red team before the basics are closed spends a five-figure sum to learn that an unpatched VPN concentrator lets someone in - a fact a penetration test establishes for a fraction of the cost, with a fix attached. The right sequence is coverage first, then detection: close the exploitable surface through penetration testing, then ask whether the residual paths are visible. If your organisation cannot yet answer "do we have endpoint telemetry on 95 per cent of laptops?", a red team is measuring the missing 5 per cent.

One more distinction providers blur because blurring it sells larger engagements: red teaming is not a phishing simulation with a follow-on exploitation attempt. Whether staff click is a useful control measurement, and it is a different measurement. A red team uses social engineering only where the objective requires it and only inside the rules of engagement, and reports the human result as one technique among many rather than as the headline. If a proposal's deliverable list is "phishing click rate plus a report", you are buying awareness testing with a red team label.

The perimeter you are testing is no longer the perimeter attackers use

Designing an exercise around a network edge is a habit from an era when the interesting entry points were internet-facing services. The published breach data has moved. Verizon's 2025 Data Breach Investigations Report, covering 22,052 incidents and 12,195 confirmed breaches, puts credential abuse at 22 per cent of initial access and exploitation of vulnerabilities at 20 per cent, with exploitation up 34 per cent year on year and edge devices and VPNs accounting for 22 per cent of that exploitation action - a near eightfold rise on the previous year, from 3 per cent. Verizon also measured the remediation response to those flaws: only about 54 per cent were fully fixed during the year, at a median of 32 days. Third-party involvement doubled to 30 per cent.

Read those four numbers together and the shape of a realistic exercise changes. Most entry is not a clever exploit against a web application; it is a valid credential used from an unexpected place, or an unpatched appliance that terminates trust at the edge, or a supplier whose access you inherited. So the interesting telemetry is identity and cloud control plane, not only network flow. An objective may be reachable without ever touching a payload: a device-code phishing flow that gets a user to authorise an OAuth application hands an attacker a token that survives a password reset, and every control built around password hygiene is irrelevant to it.

None of this makes the network irrelevant. Lateral movement still happens inside, and segmentation still fails. The point is narrower and practical: if objectives and detection measurement are built only around hosts and network sensors, the exercise will not test the paths most breaches actually take, and the report will be reassuring in exactly the way that is least useful. Name the initial-access families in scope, in the rules of engagement, before anyone starts.

An objective has to name a data class and an action

"Access the crown jewels" is the standard phrasing and it is not testable. Crown jewels is a label for a set of systems whose value is assumed, not a statement an operator can either satisfy or fail. The fix is mechanical: every objective becomes a data class plus an action plus a proof condition.

• Data class. Named concretely - customer payment records, employee salary table, source code for a named repository, tenant-wide mail flow, the backup catalogue. "Sensitive data" is not a class.
• Action. Read one record, read a thousand records, modify a record, execute code as a privileged identity, establish persistence that survives a reboot, or cause an externally visible effect. Reading one record is the cheapest proof and the least intrusive; asking to read everything converts a detection test into a data-protection incident.
• Proof condition. Agreed in advance and minimal - a hash, a screenshot of a single synthetic canary record, a filename listing. Not a copy of the dataset.
• Failure condition. What counts as blocked versus not reached in time versus abandoned for safety. Failures should be measurable too, or the exercise has no denominator.

The ladder matters because objectives differ enormously in difficulty and in what they test. "Read one payroll record" tests access control and logging on the HR platform. "Read a thousand" additionally tests volume-based anomaly detection, which is a different control and usually the one that actually fires. "Modify one record" tests integrity monitoring, which many organisations have on paper and nowhere else. "Persist for seven days" tests whether anyone runs a hunt at any point in the week, which is a test of process rather than technology and the one most likely to produce an uncomfortable answer.

The number of objectives is the single largest driver of cost, and it is also the variable buyers most often leave to the provider. Four objectives is a large exercise; two is normal; one well-chosen objective along a realistic path beats four shallow ones. Choose them by asking which single loss would hurt most next quarter, then asking what an attacker would need to do first - the prerequisites become the intermediate steps, and the path writes itself.

Rules of engagement: the document that makes the exercise lawful

Every provider mentions rules of engagement. Few buyers read them closely, and that is where engagements go wrong in ways that are expensive, embarrassing or criminal. The ROE is not paperwork attached to the contract; it is the instrument that converts an intrusion into an authorised test, and its absence is the difference between a report and a police statement.

The legal basis differs by jurisdiction and the details matter to lawyers, not to operators, but the shape is constant. In the United States, the Computer Fraud and Abuse Act at 18 U.S.C. 1030 criminalises unauthorised access, and the defence is authorisation by the party that owns or operates the system - which is why the ROE names specific asset owners, not "the company". In England and Wales, the Computer Misuse Act 1990 has no statutory authorisation defence, so the protection comes from documented consent by the system owner plus a scope that stays inside it. Elsewhere the pattern repeats with different statutes. The practical rule: the person with the authority to consent must sign for each asset class, and if you do not own the asset, you need the owner's written permission.

Two clauses are worth arguing about specifically. The first is stop authority. In a well-run engagement, a stop is not a negotiation: the word goes out, operations cease within a stated interval, and the debrief establishes what happened before anything resumes. If your ROE says the provider "will consider" a stop request, the exercise is not under your control.

The second is the engagement letter carried by the operators. A one-page document naming the client, the dates, the scope, a 24-hour phone number and a verification phrase, on letterhead, in the pocket of whoever is on site or on the phone at 02:00, is what prevents a police call from becoming an arrest. It costs nothing and it is routinely missing. Ask to see the template during procurement; the answer tells you a great deal about the provider.

The control group, the secrecy problem, and the ways an exercise goes wrong

Someone inside the organisation has to know the exercise is happening, and the size of that circle is the central design tension. Too small and the control group cannot authorise a stop, cannot answer a deconfliction call, and cannot tell a real incident from the test. Too large and the exercise leaks: an analyst mentions it in a standup, the service desk is warned to "expect unusual activity", and the detection measurement becomes a test of acting rather than of detection.

The working pattern is three to five people, chosen by role rather than seniority: the engagement sponsor who can authorise a stop, the head of security operations or a duty manager on rotation, a legal or compliance contact for incidents, and a communications contact if the exercise may become visible. Each has a 24-hour number, each knows the code word, and none of them is on the detection team that is being tested. Where an organisation has in-house threat detection, the person who would normally investigate must be outside the circle, which sometimes means the sponsor is the CISO and the tested team is told nothing at all.

The deconfliction protocol deserves a rehearsal rather than a paragraph. Fifteen minutes with the control group, the provider's lead and the duty officer, walking through "what do you do if an analyst says they have found a live intruder", is the cheapest risk reduction available in the whole engagement. In regulated sectors the same rehearsal is often a supervisory expectation, because the alternative - a genuine intrusion misread as the test - is how an exercise hides a breach.

Threat intelligence comes before tradecraft

The techniques an adversary emulation uses should be chosen because someone relevant to your sector actually uses them, not because they are the ones the operator is fluent in. That is what the threat-intelligence phase exists for, and it is the phase most often compressed into a paragraph of boilerplate about "advanced persistent threats".

A useful target package answers four questions. Who targets organisations like yours - named clusters where attribution is good, sector-level patterns where it is not. What initial access do those clusters use, with the specific techniques rather than the marketing names. What do they do after entry, and in what order - because the second hop is where detection usually exists and the first is where it is missing. And which of your assets match that profile, which turns general intelligence into a scope decision.

The output is a technique list with a rationale per entry, and it should be short. A realistic emulation of a financially motivated intrusion might exercise fifteen to twenty-five ATT&CK sub-techniques out of the 479 the Enterprise matrix now carries, and be better for it: depth in the paths that matter beats breadth across the matrix. Shallow coverage of everything is what benchmark suites do, and it produces a number that measures nothing in particular.

Two habits keep this phase honest. Write the technique list down before the active phase and publish it in the report, so the client can see what was chosen and why, and argue with it. And keep a small number of wildcard techniques outside the list - the corridor moments where an operator sees an unexpected opening - reported separately, because they are valuable findings but not part of the measured denominator.

Detection is the deliverable: the five-stage measurement model

Every provider promises to test detection and response. Almost none describes a model precise enough to be audited, which is why two proposals can both say "we measure detection" and mean entirely different things. The model worth insisting on has five stages and a denominator for each.

This structure converts a narrative into arithmetic, and the arithmetic is what makes year-on-year comparison possible. A worked example, using invented but realistic numbers, shows why the denominator matters more than the percentage:

Notice how differently those five numbers behave. Telemetry coverage is a procurement and engineering problem, and it is fixed by enabling logging and paying for ingestion. Rule coverage is a detection engineering problem. Triage is a staffing and queue-design problem. Interpretation is a training and playbook problem. Containment is the sum of all of them. A report that gives only "we were detected on 3 of 18 techniques" collapses four distinct problems into one sentence and tells the reader nothing about which budget line to move.

If the numbers look worse than a competitor's published case study, that is usually because the competitor chose the denominator. Ask any provider what they will use. A provider who cannot answer in terms of exercised techniques will produce a percentage calculated against whatever makes the story read well, and you will have no way to tell.

How to measure time-to-detect without fooling yourself

Time-to-detect is the number everyone quotes and almost nobody defines. Two exercises can both report "mean time to detect: 27 minutes" while one measured from the moment an alert appeared and the other from the moment an attacker first authenticated. The first number is about the SOC's queue. The second is about the organisation's exposure. They differ by hours or weeks, and the gap between them is the interesting finding.

Define four timestamps per event and report them separately. T0, the operator's own action time, taken from their timestamped log - not from memory, and not rounded. T1, the first record of that activity arriving in your platform. T2, the alert being generated. T3, a human acknowledging it. T4, containment or revocation taking effect. Then time-to-detect is T2 minus T0, time-to-acknowledge is T3 minus T0, and time-to-contain is T4 minus T0. Each one answers a different question about a different team.

Then handle the techniques that were never detected, which is where the arithmetic gets quietly dishonest. If 18 techniques were exercised and 3 produced an acknowledgement, the mean over those 3 is a measurement of your best case, not your average. Techniques that were never detected are not missing data to be discarded; they are censored observations, and the correct reporting is explicit: detected at a median of 41 minutes, n equals 3; undetected within the 21-day window, n equals 15. If you must produce a single figure for a board pack, label it as a median over the detected subset and put the denominator next to it. A median with n printed beside it survives scrutiny. A bare mean invites a question you cannot answer.

Two further distortions are worth designing against. The first is the alert that fires after the objective: if the objective was reached at 14:20 and the alert fired at 16:05, that is a detection but it is not a control, and averaging it with a pre-objective detection hides the difference. Report pre-objective and post-objective detections as separate populations. The second is the retrospective alert: a detection rule that fires during the report-writing week because one was written after the exercise is not a detection, it is a remediation result, and it belongs in the closure register with its own retest date.

One methodological nicety, and it is the difference between a serious engagement and a marketing one: agree the measurement method in the ROE. Which timestamps, taken from which system of record, over which population, reported how. If that clause is missing, the numbers in the report are a literary device.

What a red team cannot tell you

The most expensive misunderstanding in this market is treating "we were not detected" as either a clean bill of health or a damning verdict. It is neither; it is an ambiguous observation with at least four explanations, and the report's value depends on which one the evidence supports.

• Nothing was there to see. The technique left no trace because a log source was missing, not because a control was absent. This is instrumentation debt, and it is the most common explanation in organisations that have bought detection tooling but not tuned ingestion.
• There was a trace, and no rule. Telemetry existed, nobody had written an analytic for that technique. Fixable in days, and it is the cheapest kind of finding.
• There was an alert, and no attention. The queue was deep, the shift was short, or the alert was scrolled past. A staffing and design problem, invisible in any percentage that counts alerts generated.
• The control worked. The technique was blocked outright, or a detection fired and the response contained it. This is the only case that supports a positive statement about capability.

Beyond that ambiguity, three limits are structural. One campaign is a sample of one: it cannot establish a detection rate, and statements like "we catch 80 per cent of attacks" are not derivable from it. Operator skill is a confounder: a stronger team produces findings closer to your ceiling, a weaker one produces findings closer to their own competence, and the report cannot separate the two. And your defences are not static - an exercise in March describes March, while the environment changes every patch cycle, which is why the result has a shelf life measured in months rather than years.

The honest use of the result is comparative and directional: this year against next year, objective by objective, technique by technique, with the same measurement method. That is a defensible basis for a decision about where to spend. A single exercise presented as a verdict is not.

Instrumentation debt: the finding that outranks every other finding

When a technique produces no telemetry, the exercise has not measured a control failure. It has measured the absence of a sensor, and the remediation is not a detection rule but a data source. This deserves its own section in the report because it inverts the usual priority order: the loudest finding is often not the most valuable, and a missing audit log is worth more than a missed detection.

The check is mechanical and does not require a red team. Pick twenty sub-techniques that matter for your environment, and for each one ask a single question: which system records this, and how quickly does that record arrive where an analyst could query it? Write the answers in a grid - technique, expected log source, actual log source, latency, retention. The cells that come back empty are the debt. In most organisations the grid finds the same four holes: cloud control-plane audit logs turned off for cost or forgotten at account creation, identity provider sign-in logs inside a retention window shorter than the investigation habit, endpoint telemetry on servers that were imaged years ago and never re-onboarded, and network appliances that log only to local disk.

Do this before buying the exercise. A red team that runs on top of undiscovered instrumentation debt spends its budget producing a list of blind spots you could have written yourself in an afternoon, and the detection ratios it reports will be dominated by the holes rather than by the tuning.

Handling real data you were never meant to see

Any exercise with an objective involving a real dataset will eventually touch real data, and the difference between a professional engagement and a liability is decided before it happens. Three controls cover it: canaries, minimal proof, and a delete order.

Canaries first. The client inserts synthetic records into the target system - a named customer that does not exist, a salary row for an invented employee, a file with a known hash - and the objective is expressed against those. The operator then proves access by producing the canary's identifier rather than the customer's data. This is not a workaround; it is a more rigorous proof, because a canary is verifiable and a copied record is only evidence that someone copied a record.

Where a real record is unavoidable, the ROE should specify what may be retained: the field names and a hash, never the values, never a screenshot that includes a person's details, and never a copy outside the client's environment. If an operator finds personal data in a place it should not be, that is itself a finding, and the response is to stop touching it and report the location rather than to explore the exposure. Data you were authorised to reach is still data you are not authorised to keep.

The delete order is the last clause and the one to actually verify. A stated date, a named person on each side, a written confirmation, and for regulated clients a certificate of destruction. Ask at procurement how the provider stores findings during the engagement: a shared drive with screenshots of payroll tables is common and indefensible.

Purple team replay and the closure criterion

The report is not the end of the engagement; it is the specification for the next two months of engineering. This is where most programmes lose the value they paid for: findings are triaged into a ticket queue, some are fixed, most are not, and eighteen months later the same path works exactly as it did. The fix is to define closure before the exercise starts, so that a finding cannot be closed by a status update.

A detection gap is closed when four things exist. A rule, deployed in the detection pipeline, not drafted in a document. A test that replays the recorded activity against the rule - ideally the recorded telemetry from the exercise itself, so the test is evidence rather than a guess. A measured result: the rule fires, within a stated latency, on the replayed data. And an owner with a date, plus an expiry review, because rules rot as environments change.

The measurable output of the purple phase is therefore not a slide. It is a delta: telemetry coverage moving from 72 to 89 per cent, rule coverage from 54 to 77 per cent, and - once the same techniques are replayed - a time-to-acknowledge that has a number with an n beside it. That is what you can put in front of a risk committee, and it is the only kind of claim that survives a follow-up question.

Assumed breach, continuous validation, and when you do not need a red team

A full red team is the most expensive way to answer a detection question and, for some organisations, the wrong instrument. The alternatives are not lesser versions of the same thing; they answer narrower questions well and cost a fraction.

There is a maturity sequence worth respecting. An organisation with no inventory cannot scope an objective; one with no identity logging cannot measure initial access; one without an incident response plan cannot be tested on response, only on improvisation. Each of those gaps is cheaper to close than an exercise is to run. The exception is the regulated entity on a statutory clock, which has to run the exercise regardless and is well advised to build the prerequisites in parallel rather than sequentially.

Continuous validation is the trend that makes the most sense of the market. Annual events produce a point measurement and a thick report; a monthly replay of twenty techniques against a rule set produces a trend line, and the trend line is what tells you whether the last two sprints of detection engineering actually changed anything. The annual exercise then becomes the deep, realistic campaign that the routine cannot replace - sample of one, but a rich one.

What a red team engagement costs and how the price is built

Published bands in 2026 are wide enough to be almost useless on their own: mid-market CREST providers quote roughly 20,000 to 72,000 for an assessment, firms targeting organisations of 100 to 1,000 staff publish 40,000 to 80,000 for two to six weeks, and size-based tables run from 25,000 to well past 150,000. The spread is not because providers disagree about value; it is because the unit of work differs. Understand the unit and you can price your own scope.

The unit is the operator-day, typically quoted between 2,500 and 5,000 each at the senior end. A two-operator, fifteen-day active phase is 30 operator-days, which at 3,000 is 90,000 before intelligence, reporting, replay and project management - and that is the arithmetic behind the scary numbers at the top of the tables. A single-operator, five-day assumed-breach exercise is five operator-days, which is why it costs a fifth as much and produces a narrower answer.

What to refuse to pay for: a red team whose scope is an IP range; a proposal with no threat-intelligence phase; a fixed price per vulnerability found, which rewards noise; unlimited retests offered as a marketing feature, when a single replay with a measured result is worth more; and a report delivered as a slide deck. If two quotes differ by a factor of three, the difference is almost always the active phase length and whether the purple phase is included - ask for both as separate lines and the comparison becomes honest.

Regulatory red teaming: DORA TLPT, TIBER-EU and the three-year clock

For financial entities in the European Union, threat-led penetration testing is no longer a discretionary maturity project. The Digital Operational Resilience Act requires, in Article 26(1), that identified entities carry out threat-led penetration tests at least every three years, and Article 26(2) is specific about the target: live production systems supporting critical or important functions, including those outsourced to ICT third-party providers. The regulatory technical standards in (EU) 2025/1190 applied from 8 July 2025, with no transitional credit for exercises run before that date, and the framework is aligned with TIBER-EU, the ECB's threat-intelligence-led red teaming methodology published in 2018.

The structural requirements are what separate this from a commercial engagement. There is a threat-intelligence phase that produces a targeted attack plan, reviewed with the entity; a red team phase conducted in production, with a minimum duration intended to be long enough for realistic tradecraft; and a replay and closure phase with the defenders. Independence rules mean the testers must not have provided certain other services to the entity, and the provider must satisfy the supervisor's qualification expectations rather than merely the client's procurement criteria. The output feeds an attestation, and Article 26(7) provides for mutual recognition between authorities of tests run in one member state.

Outside the EU the shapes rhyme rather than match: CBEST in the United Kingdom, run under Bank of England oversight for financial market infrastructure, and similar threat-led frameworks in other jurisdictions. If you are in scope for any of them, plan backwards from the cycle - an eighteen-month preparation, a nine-week threat-intelligence and red team phase, and a quarter for replay and attestation is a realistic shape, and it does not fit into a single budget year without planning.

One clarification worth making to colleagues: a DORA-compliant TLPT is not automatically a good red team, and a good commercial red team is not automatically compliant. The difference is documentary and structural - independence, threat intelligence, supervisory qualification, attestation - and both can be satisfied by one well-scoped engagement, provided the provider is qualified for the regulatory variant and the ROE is written to the standard rather than to the template.

Choosing a provider: the questions that separate operators from resellers

The market contains genuine adversary-emulation teams, penetration-test shops that have added a red team page, and brokers who sub-contract. The differences show up in how they answer five questions, none of which is about certifications.

1. "Show me a redacted report from an engagement like ours." Read the detection timeline and the measurement method. If the report contains no timeline per technique, or a single percentage with no denominator, the deliverable does not exist in written form yet.
2. "What will you do if we cannot detect you?" The answer should describe instrumentation debt and a validation procedure, not a promise to try harder.
3. "Who runs the exercise, and what did they do before this?" Named operators, with a discipline: malware development, cloud identity, physical, threat intelligence. A team that cannot name its people is brokering.
4. "Who writes the detections?" If the answer is "the client team" and there is no purple phase, you are buying a narrative. If it is the provider, ask for the rule format and a sample.
5. "Walk me through your last deconfliction." Good operators have a story about a challenge they answered at an awkward hour. Weak ones have a paragraph about communication protocols.

Credentials are worth checking but they are qualifications, not evidence of tradecraft: CREST for organisational accreditation, OSCP and OSEP for offensive fundamentals, CRTO and CRTE for red team and adversary emulation specifically, plus cloud provider certifications where the objectives live in a tenant. Professional indemnity insurance sized to the engagement is non-negotiable - an uninsured operator who locks an account at 03:00 is a problem with your name on it.

Red flags, in order of how often they appear: a proposal that leads with a tool, "we test everything" as a scope statement, no mention of a control group, unlimited retests as the headline feature, per-vulnerability pricing, and a fixed report delivered without the underlying logs. Any one is a reason to ask harder questions; three of them is a reason to look elsewhere.

The thirty days before the exercise

Most of what determines the value of an engagement is done before it starts, and almost all of it is within reach in a month. The list below is ordered by how much it changes the result, not by how easy it is.

• Write down what matters, as data classes. One page: customer records, financial records, source code, employee data, the backup catalogue. This is the input to every objective. Without it, the provider will pick objectives for you.
• Turn on the logs you have been avoiding. Cloud control-plane audit logging, identity provider sign-in and audit events, and the retention to cover the exercise plus ninety days. Ingestion cost is the usual objection; the alternative is paying for an exercise that cannot see the most common attack path.
• Check endpoint coverage and report the number. Percentage of laptops and servers reporting to the platform, with a date. If it is below 90 per cent, fix onboarding before buying the test.
• Confirm the incident response plan has an on-call rotation. A response test against a plan with no out-of-hours owner measures the plan's absence.
• Patch the edge. Appliances and VPN concentrators first - the sector data puts them at the centre of exploitation activity. A red team that walks through an unpatched VPN in the first hour has tested your patch process, which a vulnerability scan would have told you for less.
• Name the control group and get their numbers onto one page, with the duty officer rotation for the active weeks.
• Draft the ROE against the twelve clauses, then send it to legal and to the provider for redlines. Two weeks of review is normal; discovering a gap during the active phase is not.
• File third-party approvals. Cloud, SaaS and managed service providers, in writing, before the start date.
• Brief the sponsor on what a stop looks like and make sure they can exercise it without seeking agreement.

If the first three items cannot be completed, the honest recommendation is to spend the quarter on them and run an assumed-breach exercise instead - one that starts inside the perimeter, where instrumented coverage is better, and produces findings you can actually close.

What the report must contain

Judge the deliverable by its structure. A report built for decisions contains, in this order: an objective-by-objective verdict with the four ratios and the denominators; the attack narrative with timestamps; the detection timeline per technique, including the techniques that produced nothing and why; the instrumentation debt list with the specific log source for each gap; the closure register with an owner and a test identifier per item; the technique list with the threat-intelligence rationale; the ROE as an annex; and a data handling statement with the deletion date. A short executive summary sits on top for the people who will read nothing else, and it should carry the same denominators rather than a percentage and an adjective.

What it should not contain: a risk score for the organisation as a whole derived from one campaign, a comparison with unnamed industry peers, and recommendations phrased as "improve monitoring". Those three are the reliable markers of a report written to be filed rather than used.

The bottom line

Red teaming buys one thing when it is built correctly: a measured, comparable account of whether a realistic adversary would be seen, understood and stopped. That requires an objective you can grade, rules of engagement that make the work lawful and stoppable, a measurement model with denominators, a time-to-detect definition that counts what it could not see, and a closure criterion that is a rule plus a replay rather than a promise. Everything else in the market - the tooling, the branding, the length of the report - is scaffolding around those five things.

If you are commissioning an exercise, the highest-value hour you will spend is writing the objective and the measurement method, before you sign anything. If you are running one, publish the technique list and the ratios even where they read badly: an uncomfortable measurement with an n beside it is the only kind that changes a budget.

Our red team operations service is built on this model - scoped objectives, a written ROE with named stop authority, ATT&CK-mapped technique lists, and a detection ratio report you can compare year on year. If you would rather start narrower, an authorised penetration test plus the instrumentation grid will often find more per pound, and getting the SIEM right is the prerequisite that makes either exercise meaningful. When you are ready to scope one, tell us what you need to protect, or read up on incident response planning and blue team practice first - both will make the engagement cheaper.