Red team and blue team test reports: TIBER-EU requirements

What TIBER-EU red team and blue team test reports must show

An entity that has just finished active red team testing must produce two reports on fixed deadlines. The red team test report records the attack from the attacker's side: which flags were reached, which attack paths worked, which failed, what the testers did, and where the defenders' actions were observed. The blue team test report records detection and response from the defender's side, mapping each attack step to the detected actions and the log entries behind them. The two are kept separate because they answer different questions. One shows what the attackers could do, the other shows what the organization saw and did about it. Comparing them is the point of the exercise, which is why the blue team maps its actions against the red team's. The red team report goes to the control team within four weeks of the end of active testing, and the control team passes it to the blue team and the test manager at the authority.

The risk these reports address is simple to state and easy to get wrong. A finding that is never written down cannot be fixed, and a finding written without evidence cannot be verified or prioritised for remediation. The red team report must carry vulnerabilities with criticality, root cause analysis and prioritised remediation recommendations. The blue team report must carry the evidence collected, root cause analysis and lessons learned. Ask the control team early which log sources, retention periods and case records will support each attack step, and confirm that the blue team can export a timeline of events and detections in the form the framework expects.

The work is usually hard for two reasons. First, log retention gaps: if logs from hosts, network devices or cloud services were rotated or never forwarded during the test window, the blue team cannot show what it detected, and the report shows a gap that looks like a failure even when the defenders acted. Second, scattered attack records: red team actions, blue team alerts and administrator changes often sit in different tools with different timestamps. Before the test ends, confirm that clocks are synchronized, that audit logs on key platforms are enabled at a level that captures the relevant events, and that someone owns the consolidation. Both reports are highly sensitive, so agree in advance who may access them and how they will be retained and destroyed. The test manager may ask for machine names and IP addresses to be removed, so keep an unredacted master copy under the entity's own control.

How the two reports move from testers to the test manager

The sequence moves the red team's findings to the control team first, so the blue team can compare its own detections against those actions before it writes its report. The test manager then decides whether both reports are complete, which starts the clock for the closing documents.

Close active testing and start the report clock
Active testing against the flags ends, and the red team stops injecting attack activity into the tested environment. The red team and the control team agree on the end point so that the report deadlines can be counted from it. The output is a recorded end date for active testing, which both reports use as their reference point. Confirm the agreed end date in writing before the red team starts writing.
Red team delivers its test report to the control team
The red team writes its report covering targeted functions and systems, each scenario, flags reached and not reached, successful and unsuccessful attack paths, deviations from the plan, leg-ups granted and blue team actions observed. It also lists vulnerabilities with criticality, root cause analysis and prioritized remediation recommendations. The report goes to the control team within four weeks of the end of active testing. The step is complete when the control team confirms receipt.
Control team passes the red team report onward
The control team, which sits on the tested entity's side and coordinates the test, forwards the red team report to the blue team and the test manager at the authority. The control team controls who sees the document and records each recipient. Because the report is highly sensitive, the handover should use the access and distribution rules the entity has agreed for the test. The output is a distribution record showing both recipients received the report.
Blue team maps its actions to the red team's
The blue team reads the red team report and compares it against its own monitoring and response activity. For each attack step, it lists the detected attack actions and the matching log entries, and it notes where no detection occurred. This comparison is why the blue team needs the red team report before it finalizes its own. The blue team owns this analysis, and the control team checks that the mapping covers every attack step.
Blue team delivers its test report
The blue team completes its report with a timeline of events and detections, evidence collected, an assessment of the testers' findings, root cause analysis, lessons learned and topics for purple teaming. The report is due no later than ten weeks after the end of active testing and comes before the replay and purple teaming exercises. The control team sends it to the test manager, and the step is complete when delivery is recorded.
Test manager assesses both reports for completeness
The test manager checks whether each report contains the information the framework requires. At the test manager's request, sensitive details such as machine names and IP addresses may be removed before the reports are shared more widely. Gaps are returned to the author for correction. Confirm with the authority how it records this review and whether it issues a written confirmation.
Test manager's assessment starts the eight-week clock
Notification from the test manager that both reports contain the required information starts the eight-week deadline for the test summary report and remediation plan. The tested entity and the authority should record this notification date, because the next deadline depends on it. This closes the report stage and passes the work to the next closure step.

What each report must contain

The red team test report goes to the control team within four weeks of the end of active testing, and the control team passes it on to the blue team and the test manager. It records what the testers attempted and achieved against the targeted functions and systems, so the entity can see which attack paths worked, which flags were reached, and which vulnerabilities need remediation.

Scope and scenarios: the targeted functions and systems, plus a summary of each scenario the testers ran.
Flags: which flags were reached and which were not, with the successful and unsuccessful attack paths and the techniques used on each.
Deviations and leg-ups: every departure from the red team test plan and every leg-up the control team granted, so readers can tell which outcomes were earned and which were given.
Blue team actions observed: the defensive actions the testers saw during the test, recorded from the attacker's side.
Vulnerabilities: each finding with its criticality, a root cause analysis, and prioritised remediation recommendations.

Check that each vulnerability traces back to a specific attack path and that every leg-up is listed, because omitted leg-ups would overstate what the testers achieved.

How an assessor tests the two reports

This table compares six points an assessor checks when reviewing the red team and blue team reports, from content completeness to document handling. Read each row as a test: the approach describes what the test manager or independent assessor does, and the evidence column shows what the reader should have ready. The main takeaway is that traceability between the two reports is where gaps most often surface.

Test point	Assessor approach	Evidence requested	Common findings
Completeness against required content	Checks each required section of the red team report (targeted systems, scenario summaries, flags reached and not reached, deviations, leg-ups, vulnerabilities) and each blue team section (attack steps, detections, log entries, lessons learned) against the framework list	Section-by-section index or cross-reference table, with the framework contents list used as the checklist	Root cause analysis or prioritised remediation missing from findings; leg-ups and deviations not recorded
Timing against deadlines	Compares the red team report issue date with four weeks after the end of active testing, and the blue team report date with ten weeks, using the control team's transmission records	Dated transmission emails or document register entries showing delivery to the control team and onward to the blue team and test manager	Reports issued late without a documented agreement; dates unclear because the end of active testing was not recorded
Traceability from blue team logs to red team actions	Samples several attack steps and follows each detected action from the red team report to the blue team's mapped log entries and timeline	Mapping table linking each red team action to detected actions and log entries, with timestamps	Attack steps with no matching detection and no explanation; log references that cannot be reproduced from retained logs
Handling controls for highly sensitive documents	Reviews access lists, distribution records, storage location, retention rules and destruction records, and checks whether sensitive details were redacted at the test manager's request	Access control list, classification marking, distribution log, retention and destruction schedule, redaction record	Copies held outside the approved distribution list; machine names and IP addresses left in circulated versions without a request
Test manager assessment notification	Confirms that the test manager issued a written assessment of whether both reports contain the required information, and that the date is recorded	The written assessment notification with its date and the list of reports it covers	No notification on file, so the eight-week clock for the summary report and remediation plan cannot be tied to a date
Blue team assessment of red team findings	Checks that the blue team assessed each red team finding and recorded evidence, lessons learned and topics for purple teaming	Blue team assessment section, evidence register and list of proposed purple teaming topics	Findings listed without assessment; purple teaming topics not linked to specific gaps in the reports

How to handle both reports as highly sensitive documents

Both reports are highly sensitive because they map exploitable weaknesses and detection gaps in a live environment. The red team test report lists the attack paths that worked, the flags that were reached, and the vulnerabilities behind them. The blue team test report shows which attack steps were seen, which were missed, and which log entries support each finding. Read together, they give a reader a practical plan for attacking the entity's systems and for avoiding detection. Before testing starts, the control team should agree with the test manager who may receive each report, through which channels, and how copies are tracked. Those controls should be written down and applied to drafts, working files and email threads, not only to the final versions.

The organization must define four controls: who can access each report, how it is disseminated, how long it is retained, and how it is destroyed at the end of that period. Access should be limited to named people with a need to know, and the list should be reviewed as the control team changes. Dissemination rules should cover internal distribution, any copies held by the threat intelligence provider or red team testers, and how reports are shared with the board or auditors. Retention and destruction periods should come from the entity's own records policy and any requirement the authority sets. Confirm the retention and destruction terms with the authority in writing, because the framework does not fix them in the text this section relies on.

The test manager may ask that sensitive details such as machine names and IP addresses be removed from either report. Confirm with the authority how that request is made, in what form, within what time, and how the redacted version is recorded and approved. Then decide how the entity will keep an unredacted master copy. That master should sit under the same access, retention and destruction controls as the originals, with a log of who opened it and when. A redacted copy that circulates without its master is a common source of confusion later, so label every version clearly and keep the mapping between them under restricted access.

Which self-hosted open-source tools produce blue team evidence

The blue team test report must map each attack step to detected actions and the log entries behind them. Four self-hosted open-source tools can supply that evidence, each covering a different layer of the environment. None of them writes the report; the blue team does, and the test manager checks it against the requirements.

OpenSearch Security Analytics

Security Analytics runs detectors that match ingested logs from hosts, network devices and cloud services against prepackaged or custom Sigma rules. Each match is stored as a finding with its rule, log type and severity, and a correlation graph links findings across log sources. For the report, the finding records give the detection side of each attack step. Check that your log sources feed the indexer with the fields your Sigma rules expect, and confirm the rule coverage against the red team's scenarios before the test starts.

Wazuh alerts and MITRE mapping

Wazuh decodes collected logs and compares each event against its ruleset, then writes matching alerts to alerts.log and alerts.json. Alerts are mapped to MITRE ATT&CK techniques, which lets the blue team line up detections with the red team's documented techniques. Under the Wazuh license, GPL-2.0-only, you must comply with its terms if you modify and distribute the software. Confirm that the built-in rules cover your endpoints and that custom rules are version-controlled, since the report will cite them.

Nextcloud admin_audit log

The admin_audit app writes additional event information to audit.log in the data directory, or to a path set with logfile_audit. For a test that touches file sharing or administration in Nextcloud, this log shows who did what and when, which supports the timeline of events both reports must contain. Confirm the log path and retention on your deployment, and forward the file to your central log store so it can be correlated with other sources. Nextcloud is licensed under AGPL-3.0-only, which applies to modifications you offer to users over a network.

OpenBao audit device logs

OpenBao audit devices keep a detailed JSON log of every API request and response, including errors. Most sensitive values are hashed with HMAC-SHA256, so the log can show which secrets were accessed and by which identity without exposing the secrets themselves. This helps the blue team confirm whether a credential or token use was observed. Confirm that audit devices are enabled before the active testing window opens, because requests are not retroactively logged. OpenBao is licensed under MPL-2.0, which requires source availability for modified MPL-covered files.

What producing both reports costs in money and effort

This table breaks down who is paid for each effort involved in producing the red team and blue team test reports, whether each cost is one-time or recurring, and what moves it up or down. Use it to build a written quote request, since no fixed figures for these components have been published in the framework.

Cost component	One-time or recurring	What drives it	How to keep it down
Red team report writing	One-time per test	Number of scenarios, flags and attack paths, and how many deviations from the plan must be explained	Ask the provider to keep a running log of actions and flags during active testing so the report is assembled, not reconstructed
Blue team log review and mapping	One-time per test	Volume of retained logs, number of detectors, and how many attack steps must be matched to log entries	Agree log retention and source coverage before testing starts, and keep detection rules documented as they are tuned
Control team coordination	One-time per test	Number of parties involved, frequency of status meetings, and approvals needed before sharing findings	Set a single coordination channel and fixed review dates in the initiation documents
SIEM or log platform licenses	Recurring, if commercial; none for self-hosted open source	Ingestion volume, number of hosts and cloud services, and vendor tier for alerting or correlation features	Self-hosted open-source platforms remove license spend but not staffing for deployment, tuning and maintenance; confirm feature needs before choosing
Secure storage and handling of sensitive reports	Recurring for storage and access controls, one-time for setup	Number of copies, classification rules, access review frequency, and retention and destruction obligations	Limit distribution lists, keep one controlled repository, and record access and destruction in writing
Test manager assessment cycle	One-time per test	Completeness of both reports on first submission, since the assessment starts the eight-week clock for the next deliverables	Use a checklist of required report contents from the framework before submission to reduce rework

Who writes, reviews and assesses the reports

Your organization owns the TIBER-EU test from the tested side. The blue team and the control team are the people who watch the environment, respond to the red team, and record what they saw. The blue team report is written by the blue team, and the control team passes both reports to the blue team and the test manager. Ownership of the log evidence stays with the entity, because the evidence must show what your own detection and response processes actually did during the test.

Blue team report authorship: The blue team writes its report, mapping each attack step to detected actions and log entries, and records its own lessons learned and purple teaming topics.
Control team coordination: The control team manages the flow of the red team report to the blue team and the test manager, and keeps the test scope and leg-ups under internal control.
Log custody: Your staff decide retention periods, access lists and the handling rules for documents that carry machine names and IP addresses.
Remediation ownership: Your leadership accepts the findings and owns the remediation plan that follows the reports.

Confirm in writing who in your organization signs off each report and who may request the removal of sensitive details from it.

Where blue team reports usually fall short and how to close the gap

Blue team reports are judged on whether they map detections to the red team's actions, show when each event happened, and handle sensitive content with discipline. The gaps below are the ones that most often send a report back for rework, and each one has a fix the blue team can apply before the reporting deadline.

Logs not traced to attack steps

The blue team report must list, for each attack step, the detected attack actions and the matching log entries. Reports often describe detections in general terms without pointing to specific events. Before writing, build a table keyed to the red team's attack steps, and record the log source, event identifier and alert name for each one. Where a step produced no log entry, say so explicitly. Test a sample row by searching for the event in the original log store, so an assessor can follow the trail without guessing.

Timestamps and time zones drift

A timeline of events and detections only works if every source uses the same clock. Firewalls, cloud services, endpoint agents and SIEM ingestion pipelines often record time in different zones or with small offsets, which makes the sequence of attacker actions and detections look wrong. Check time synchronization on each source before the test, note the time zone used in the report, and normalize timestamps to a single standard in the timeline. State any residual offset that could not be corrected.

Detection rules never tested against the red team

Detection content that exists on paper is not the same as detection content that fired during the test. Teams often report coverage from a rule catalog without confirming that each rule matched the red team's actions. Map each Sigma or vendor rule to the technique it was meant to catch, then record whether it fired, fired late, or stayed silent. Rules that were never exercised should appear as open items for purple teaming rather than as confirmed coverage.

Drafting before the red team report arrives

The blue team report maps its actions against the red team's, so drafting it before the red team test report arrives means the mapping is built on assumptions. The red team report is due within four weeks of the end of active testing, and the blue team report within ten weeks. Use the intervening period to collect logs, export alert records and build the timeline, but hold the mapping and assessment sections until the red team's flags, attack paths and leg-ups are confirmed.

Unmanaged copies of sensitive reports

Both reports are highly sensitive. Copies sent by email, saved to personal drives or pasted into chat tools create records that nobody tracks and that are hard to destroy later. Set up one restricted repository with named access, audit logging of downloads, and a distribution list maintained by the test manager's process. Use the repository's own sharing controls rather than attachments, and keep a register of who received which version and when.

No written retention or destruction rule

Without a written rule, sensitive details such as machine names and IP addresses persist longer than anyone intended. The framework allows the test manager to request removal of those details, so the blue team should know who makes that request, how redactions are recorded, and when copies are destroyed. Write a short retention and destruction procedure that names the owner, the retention period agreed with the authority, and the method of destruction, and confirm it with the test manager before the report is issued.

Questions buyers ask about TIBER-EU test reports

How much effort do TIBER-EU red and blue team reports take to write?

The effort depends on how much activity the test produced, how well the logs and records were kept during active testing, and how many scenarios and flags were in scope. The red team report must cover each targeted function and system, every scenario summary, flags reached and not reached, attack paths, deviations from the plan, leg-ups granted and vulnerabilities with root cause analysis and remediation recommendations. The blue team report must map detected attack actions to log entries for each attack step, add evidence, root cause analysis and lessons learned. Most of this work is documentation of what already happened, so teams that kept a clean timeline during testing spend far less time on it. Ask your provider and the authority to confirm the expected length and format of each report before testing begins.

Can our organization write the blue team test report on its own?

Yes, the blue team is responsible for its own report, and the framework does not require an outside writer. The report must map the blue team's actions against the red team's, so the people who ran detection and response during the test need to be involved. Many organizations find that the hardest part is pulling together log evidence from several systems into one timeline. If your internal team lacks that capacity or experience, an implementation partner can help prepare log collection, evidence exports and timeline templates. The content and conclusions remain the organization's own, and the test manager at the authority judges whether the report is complete.

What does the blue team and control team need to provide for the reports?

The blue team needs complete, time-stamped logs from hosts, network devices and cloud services, along with alert records showing what was detected and when. The control team coordinates the exchange of information between the red and blue teams and keeps the test manager informed, so it must hold a clear record of the timing of any leg-ups and deviations. Useful preparation includes:

Central log retention long enough to cover the full active testing period
Alert and case records linked to each attack step
A named owner for evidence collection and report review
A process for applying the test manager's request to remove machine names and IP addresses from the report

What happens if our organization misses the report deadline?

The red team test report is due within four weeks of the end of active testing, and the blue team test report no later than ten weeks after that point. A late report delays the replay and purple teaming exercises, which must follow the blue team report. It also delays the test manager's assessment, and that assessment starts the eight-week clock for the test summary report and remediation plan. Consequences for a late report are set by the authority and the national rules that apply to your entity, so confirm them in writing during initiation. If a deadline looks at risk, raise it with the test manager early rather than at the deadline.

Can the red team write the blue team test report?

No, each team writes its own report. The red team test report records the attack from the tester's side, while the blue team test report records detection and response from the defender's side. The blue team report must assess the testers' findings and map each attack step to the detections and log entries that the blue team observed, which requires the defenders' own knowledge of their systems. Red team testers may help explain attack techniques during the replay, but their involvement in writing the blue team report would undermine its value as an independent record. Confirm with your provider how questions between the teams are handled and documented.

Can DeployOpen write or certify our TIBER-EU test reports?

DeployOpen does not write the TIBER-EU reports for the tested entity, and it does not certify or approve them. DeployOpen prepares systems, logging, evidence collection and documentation support so that the organization can produce its own reports. Only the authority and its assessors judge whether the reports contain the required information, and the attestation that follows is issued through the authority process, not by DeployOpen. Our work on this topic is scoped in writing before it starts, and the scope should state which evidence and documentation tasks are included and which remain with your team.

Which logging tools help produce evidence for the blue team report?

Open-source platforms can capture the records that a blue team report needs, but the choice of tool does not decide whether a report is complete. OpenSearch Security Analytics matches ingested logs against Sigma rules, records findings with rule, log type and severity, and links related findings in a correlation graph. Wazuh decodes events, compares them against its ruleset, maps alerts to MITRE ATT&CK and writes alerts to alerts.json, which helps build the timeline. Application audit logs, such as Nextcloud's audit.log or OpenBao's JSON audit devices, can supply evidence for specific systems. Confirm that each source covers the full testing period and that its retention meets the authority's requirements.

How DeployOpen prepares logging and evidence for TIBER-EU reports

DeployOpen plans and builds the self-hosted logging, detection and audit trails that a TIBER-EU red team and blue team report draws on, inside the client's own infrastructure. The organization owns its controls and the report contents, and DeployOpen prepares the systems and records so the timeline and detections can be documented.

How we scope

We confirm which systems, log sources and cloud services fall within the targeted functions and flags agreed with the authority.
Each engagement is fixed-scope, with deliverables and timelines agreed in writing before any logging work starts.
We agree with the control team which log types must be retained so the blue team can map detections to each attack step.

How we build

We deploy self-hosted detection tooling such as OpenSearch Security Analytics or Wazuh, configured for the client's hosts, network devices and cloud services.
We load Sigma-based and custom detection rules and test that matches are recorded as findings with rule, log type and severity.
We enable audit logging on platforms such as Nextcloud and OpenBao so that API requests and administrative actions appear in the evidence trail.

How we hand over

We document the log retention, access controls and export steps so the blue team can produce a timeline of events and detections.
We prepare log extracts mapped to each attack step, ready for the blue team test report, with sensitive identifiers handled as the test manager requests.
We agree with the client how the reports are stored, shared and destroyed, given that both reports are highly sensitive.

How we support

Ongoing support, upgrades and continuous testing of the logging stack are available as retainers after the engagement closes.
We can help the client verify that detection rules and log pipelines still work before the next TIBER-EU or DORA threat-led test.
The client should confirm with its authority and independent assessors which evidence formats and retention periods they accept.

Red team and blue team test reports