What a Red Team Report Contains

A penetration test report is a catalogue. A red team report is a story. If you receive a severity table and little else, the exercise has been misunderstood or misdelivered.

The attack narrative

The core of the document: what happened, in order. Reconnaissance and what it revealed. The routes considered and why one was chosen. The initial access attempt: what worked, and what failed first. What was found inside. How the objective was reached, or where the team was stopped.

Written so that someone who was not there can follow it. It is the section that gets read aloud in a board meeting, and the one that changes minds, because it describes your organisation.

Every step in it should be reproducible from the document alone: the action taken, the system or the role it was taken against, the time it happened, and the artefact that proves it happened. A narrative your engineers cannot walk back through is an anecdote about the engagement.

The detection timeline

The deliverable people underestimate, and often the most valuable page.

Every action the team took, mapped against what your side saw: logged and alerted, logged but silent, or invisible. With timestamps on both, so a delay is visible as a delay.

This converts "our monitoring is good" into a list of specific techniques that produced nothing. It is also the only part that measures your response, not just your tooling. An alert that fired at 02:14 and was acknowledged at 09:30 needs a different fix from one that never fired.

Ask for each action to be mapped to a MITRE ATT&CK technique. Your detection team can then take the timeline straight to the rule set and check coverage technique by technique. See what the exercise tells you about detection.

Two practical things decide whether the timeline can be built at all. Agree the clock first: operator logs stamped in IST against platform logs stamped in UTC produce a reconciliation in which your response appears to precede the attack by five and a half hours. Fix the timezone and the time source in the rules of engagement, and have both sides stamp the same way.

Then preserve your own evidence while the exercise is still running. If the work happens in one month and the report lands in the next, the logs needed to answer "did we see it?" may have rolled over, and "we saw nothing" becomes unprovable in either direction. Export the window covering the exercise for every source in scope, including the ones you expect to be silent.

If the detection timeline is not in the proposal, it will not be in the report. Ask before signing. See what a red team engagement costs, where it is one of the five comparison questions.

Findings, written to be fixed

The narrative explains; the findings section is what engineering works from. Each one is conventional: what the weakness is, where, the evidence, and the specific remediation.

Expect a mixture. That is the point. A red team usually surfaces a handful of technical flaws alongside process and human findings: a service desk that resets a password on a convincing phone call, a door held open, a monitoring rule scoped to the wrong log source. The non-technical ones are frequently the cheapest to fix and the hardest to hear.

Give every finding an owner and a route before the report is circulated. Technical findings go to a backlog that already exists. Detection findings go to whoever owns the monitoring rules, as a rule change with a test attached. The process and human findings go to a service desk manager, a facilities lead or a process owner in HR, none of whom holds a security backlog to put them in. That is where red team findings die: not rejected, just never filed anywhere that gets reviewed.

Names, evidence, and what leaves with the provider

The report should describe roles and procedures, never individuals. "The service desk reset a password after one call" is a finding. Naming the agent who took the call turns the document into an HR file and buys silence on the next exercise. Put the rule in writing alongside the consent and authorisation terms: see social engineering assessments and consent.

Then ask what the team collected. A red team that reached its objective has held credentials, session material, screenshots of live systems and, if phishing was in scope, the contents of real mailboxes. The report should state what was captured, what is retained as evidence, what was destroyed and on what date. Settle retention, destruction and the confirmation you get in the contract, because once the report is delivered you have nothing left to negotiate with.

What should not dominate it

CVSS scores. They describe a technique's severity in the abstract, and a red team's finding is usually the chain: three individually moderate things that together reached the objective. Scoring each link separately understates all of them.

A report that leads with a severity distribution is a penetration test report with a red team's name on the cover.

The draft, and what you may change in it

You should see a draft, and the contract should say what you may alter. Correcting facts is legitimate: a host misidentified, a control described as absent when it was disabled for a migration, an internal team named wrongly. Removing a finding is not, and a provider who agrees to it is selling a document instead of an assessment. See choosing a red team provider.

The debrief is part of the deliverable

The most useful hours of the engagement are usually the joint session: the red team and your defenders walking the timeline together. Here is when we did that. Did you see it? What did it look like on your side? Why did that rule not fire?

It is cheap, it is often left out of proposals, and it is where the detection improvements actually get designed. Ask for it explicitly.

Who gets which version

The finished report is the most sensitive document your organisation will hold this year: a working set of instructions for getting in, verified against your live environment by someone who succeeded. Decide the distribution list before it is written, keep it short, and agree how it is transmitted and where it is stored.

In practice you need three readerships served from one document. The board reads the narrative and a timeline summary. Engineering reads the findings. The monitoring team reads the timeline in full. If a group company or a managed provider sat inside the scope, they see the portion that concerns them and not the route through the rest of your estate. Ask whether the provider keeps a copy, in what form, and for how long.

What the report proves to a board and to an auditor

To a board, it proves behaviour. A severity count says the organisation has weaknesses, which every board already assumes. A timeline showing an alert that fired and sat unacknowledged until the morning proves how the organisation behaves at two in the morning, and no dashboard answers that.

To a regulator, be precise about what the document carries. Under the RBI Directions issued on 31 July 2026, ¶151 sets the cadence you file against for commercial banks: vulnerability assessment at least every six months and penetration testing at least every twelve months, for information systems that are critical and / or sit in the DMZ with a customer interface. On red teaming, ¶162 says red teams may be used, and no instrument sets a red-team frequency. So the report sits beside that file as evidence of how your controls actually performed, and the cadence obligations stay their own programme. See red teaming under the RBI Directions 2026.

Two paragraphs shape the deliverable itself. ¶156 has you consider the qualification, professional expertise, credentials and competency of the firm and of the assigned personnel at every selection, appointment, engagement and renewal, and that is far easier to evidence when the report names who did the work and in what role. Where you engage a CERT-In empanelled auditor, ¶159 brings CERT-In's audit policy guidelines into the supervisory relationship.

If the same firm also runs your VA/PT, settle that report format in the contract and not at delivery. ¶157 requires reasonable assurance for each area assessed to be provided explicitly in the VA/PT audit report, and requires the point to be raised at the time of empanelling, or of selecting and awarding the contract.

When the report will tell you nothing

If you already know there is no central logging for the systems in scope, the timeline will read "invisible" on nearly every line and you will have paid a red team to write down what you could have told them on day one. Build the collection first, then buy an exercise that can surprise you.

Then what

Unlike a penetration test, there is rarely a clean retest: the objective was achieved by one route, and the fix changes the terrain; it does not close a finding. What usually follows is detection work, verified through a purple team exercise, and a repeat engagement later against a different objective.