What replay and purple teaming require after a TIBER-EU test
The replay and purple teaming are two mandatory learning exercises that must both take place within ten weeks of the end of active testing. The replay walks the red team and blue team through each scenario step by step, and purple teaming covers topics the control team, red team and blue team choose together. Under Delegated Regulation (EU) 2025/1190 Article 12(5), the TLPT technical standards require both exercises no later than ten weeks after active testing ends, and the 2025 TIBER-EU update made purple teaming mandatory for every test. For a tested entity, that ten-week window is the first hard date in the closure phase, and it runs in parallel with the reports that must be finished in the same period.
The replay is a structured review, not a debate about who was right. For each scenario, the red team explains what it did and what it observed, the blue team explains what it detected, missed or misread, and both sides discuss what more the red team could have achieved and what remediation would have stopped it. Purple teaming then goes wider. The topics can run from a table-top discussion of a business continuity decision to a technical walkthrough of a proof of concept, and they often include issues that could not be tested during active testing, alternative scenarios and anticipated remediation measures. Ask your control team to agree the topic list in writing before the session, so that each topic has a named owner and a clear output.
The hard part is usually people and timing, not the agenda. Red teams are paid to find paths and blue teams are judged on how their controls perform, so each side may arrive guarded, and the session needs a facilitator who keeps it on evidence. The blue team report is also normally still being drafted when the replay should start. Decide early who owns each finding, which findings the replay will use as its baseline, and how the outcomes will flow into the test summary report and remediation plan. Confirm with your test manager and threat intelligence provider how the exercises fit the calendar, because the ten-week deadline is fixed while the report content may still be moving.
Which scenarios, teams and topics fall inside the exercises
The replay and purple teaming draw on the same people and the same test record as the active testing that precedes them. The cards below set out who sits in each exercise and which scoping decisions change how much work the exercises involve.
Control team and test manager roles
The control team is the small group that knows the test exists and steers it, and it is the only party that can see the full scenario set alongside the red team's activity. The TIBER Cyber Team and the test manager at the authority supervise the exercises rather than running them, so they confirm that the replay covers every scenario and that purple teaming topics are agreed jointly. Check early who holds the control team role, since the 2025 framework renamed the White Team to the Control Team and its members must be named in the test documentation.
Blue team participants and their reports
The blue team is the tested entity's defensive staff, including the people who detected or missed each step of the red team's activity. In the replay, they explain what they saw, what they did and why, which makes them the main source for the blue team report. Ask which blue team members will attend each session, because a replay without the analysts who handled the alerts produces a weaker record of detection gaps.
Red team and threat intelligence provider
The red team testers describe the attack paths they took and what more they could have achieved, which is the core of the replay. The threat intelligence provider joins to explain why each scenario was chosen and how it reflects the threats relevant to the entity. Confirm with the procured providers whether their testers and intelligence analysts will attend in person or remotely, and whether their participation is covered by the contracted scope.
Number of scenarios and flags tested
The replay walks through each scenario step by step, so the number of scenarios and the flags tested during active testing set the length and depth of the exercise. Scenarios that reached more flags or ran across more systems take longer to replay and generate more follow-up topics for purple teaming. Ask the test manager for the scenario list and flag map before scheduling, so the replay agenda matches what was actually tested.
Issues that could not be tested
Some concerns raised during scoping may not have been tested during active testing, for example because of safety limits or production constraints. The purple teaming exercise is the place to discuss them, using table-top discussions or technical walkthroughs rather than live attacks. Agree on a written list of untested issues with the control team early, since each one will need a named owner and a clear reason for its inclusion as a purple teaming topic.
Business continuity exercises as topics
Purple teaming topics may include business continuity exercises, which test whether recovery and continuity procedures hold up when the scenarios that the red team exercised actually occur. Adding them increases the number of stakeholders who must attend, including business continuity and operational managers outside the security function. Confirm early whether these exercises are in scope and who in the organization owns the continuity plans they will test.
How an authority checks replay and purple teaming
This table sets out what the test manager and TIBER Cyber Team check for each learning exercise, the evidence they typically ask for, and the findings that most often delay closure. Read it as a checklist for preparing the record before the authority reviews it, since the same questions apply to the replay and to purple teaming.
| Check | What the authority verifies | Evidence to have ready | Common finding |
|---|---|---|---|
| Timing | Both exercises take place within ten weeks of active testing ending, as Delegated Regulation (EU) 2025/1190 Article 12(5) requires for DORA TLPT | Dated calendar invitations, session start and end times, and the date active testing formally ended | Replay held after the ten-week window, or purple teaming scheduled late to wait for the blue team report |
| Replay timing | The replay ran once the blue team report was substantially drafted, so both sides could compare their accounts | Draft status of the blue team report on the replay date, and version history | Replay run before the blue team had a draft, leaving the record one-sided |
| Replay coverage | Each scenario was walked through step by step, including what more the red team could have achieved and the potential remediation | Scenario-by-scenario walkthrough notes and a list of scenarios covered against the test plan | Scenarios skipped without explanation, or walkthroughs that only restate the red team report |
| Purple teaming topics | Topics were jointly identified by the control team, red team and blue team, and the format suits the subject | Topic selection record showing who proposed each topic and who agreed to it | Topics chosen by one party alone, or a list copied from the framework without local input |
| Purple teaming substance | The session engaged with the chosen topics, whether table-top discussion or technical walkthrough, and addressed issues not tested during active testing where relevant | Agenda, attendance list, minutes, and any proof-of-concept or walkthrough material discussed | A session held only as a formality, with attendance recorded but no discussion of remediation or untested issues |
| Follow-through | Replay and purple teaming findings feed into the test summary report and the remediation plan | Cross-reference table mapping each finding to a remediation action, owner and status | Findings from the exercises absent from the remediation plan, or recorded as agreed without an action |
| Reference point | The ECB's TIBER-EU Purple-Teaming Guidance describes how the exercise is run, and the authority checks the record against it | Copy of the guidance used by the team, with notes on any local adaptation agreed with the authority | Teams unfamiliar with the guidance, or local changes not documented and approved |
Running the replay and purple teaming step by step
This sequence turns the blue team's findings and the red team's narrative into a joint learning record, then into concrete inputs for the test summary report and remediation plan. Both exercises must finish within ten weeks of the end of active testing, so planning starts before the reports are final.
Schedule both exercises inside the ten-week window
The test manager and the control team set dates for the replay and the purple teaming sessions, both within ten weeks of the end of active testing. The replay is best held once the blue team report is substantially drafted, so the blue team can speak to its own detection and response record. Participants, the red team and blue team leads, and the control team confirm attendance in writing. The step is complete when the dates, attendees and a named facilitator are recorded in the test plan file and the authority has been informed.
Assemble the replay inputs
The red team gathers its attack narrative, the timeline of each scenario and the flags it reached, while the blue team brings its draft report, alert records and any case timelines from its detection tooling. The control team checks that both sides are working from the same scenario list and the same timestamps. Where detection data lives in a case management or SIEM platform, the team exports the relevant timelines in advance. The output is one agreed pack per scenario, ready for walkthrough.
Walk through each scenario step by step
The red team and blue team go through each scenario in sequence, with the red team describing each action and the blue team stating what it saw, what it alerted on and what it did. The discussion covers what more the red team could have achieved had the attack continued, and which gaps allowed that. Each scenario ends with agreed remediation options, recorded against the blue team's findings. The control team confirms that every scenario was covered, and the facilitator closes each one only when both sides have accepted the record.
Record potential remediation for each finding
For every gap raised in the replay, the team writes a short entry with the affected control or capability, the observed behavior, the proposed remediation and an owner. The entries distinguish fixes the entity can make directly from those that need a broader program change. Blue and red team members review the wording so the record matches what happened during active testing. The output is a replay log that is complete for all scenarios and can be traced back to specific scenario steps.
Agree purple teaming topics with all three teams
The control team, red team and blue team jointly choose the purple teaming topics, drawing on the replay log. Candidate topics include issues that could not be tested during active testing, vulnerabilities identified, alternative scenarios and their consequences, proofs of concept, anticipated remediation measures and business continuity exercises. Each topic is given a format, whether a table-top discussion or a technical walkthrough, and a named lead. The output is an approved topic list that the control team signs off before sessions begin.
Run the purple teaming sessions
The control team facilitates the sessions, with the red team demonstrating techniques and the blue team testing detection, response and recovery responses live or in discussion. Sessions are run within the same ten-week window as the replay. Each session produces notes on what was demonstrated, what the blue team could detect or block, and what changed in understanding. The session is complete when the lead confirms that the agreed topic was covered and that outstanding questions are logged.
Capture outputs in a single record
The control team or test manager consolidates the replay log, purple teaming notes and any proofs of concept into one record for the test. Each item is tagged with its source scenario or topic, its owner and its status. Sensitive material stays within the controls agreed for the test, consistent with how the red and blue team reports are handled. The check is that every replay gap and purple teaming outcome has either a traceable entry or a documented reason for exclusion.
Route findings into the summary and remediation plan
The findings from the replay and purple teaming feed directly into the test summary report and the remediation plan. The entity's owners translate each agreed remediation into an action with a named owner, and the control team checks that every replay and purple teaming finding is either addressed or explained. The output is a cross-reference table linking each finding to its remediation action, ready for the test summary report and remediation plan. Confirm with the test manager how the authority expects this linkage to be presented.
How the replay and purple teaming feed the closure deliverables
The replay and purple teaming are where the closure deliverables get their substance. Findings from both exercises feed directly into the test summary report and the remediation plan, so the tested entity should treat them as inputs to those documents rather than as a formality that ends the test. The replay walks through each scenario step by step, and it goes further than the blue team report. The blue team report records what the defenders saw, detected and did. The replay adds what the red team could have achieved had the defenders not stopped it at that point, and it lets the blue team question the red team's choices in real time. Remediation ideas raised in the replay are the ones most likely to be carried into the remediation plan, so the control team should capture them in a form that can be traced later. Ideally the replay happens once the blue team report is substantially drafted, which gives the discussion a shared factual base. Each scenario discussion should produce a note on what the red team could have achieved and what would have stopped it.
Purple teaming is the place to address issues that active testing could not reach. The control team, red team and blue team choose its topics together, and these can include matters the test could not exercise, vulnerabilities identified during testing, alternative scenarios and their consequences, proofs of concept, anticipated remediation measures and business continuity exercises. The format can range from a table-top discussion to a technical walkthrough, so the control team should choose the format that fits each topic. Before the session, confirm with the test manager which topics are in scope and which require the authority's approval, because a proof of concept against live systems is a different decision from a discussion of one. Topics that the entity intends to fix should be written down with an owner and a proposed measure, since those become the entries the test summary report and remediation plan must account for.
Both exercises must finish within ten weeks of the end of active testing, which makes their scheduling a closure-phase decision with fixed deadlines. Ask the control team to confirm the dates for the replay and purple teaming early, and to agree who attends for the tested entity, including the people who will own remediation actions. The authority will later review how the findings were reflected in the test summary report and remediation plan, and the 360 degree feedback gathers input from the participants on the same material. Once the remediation plan is approved, the signed attestation confirms the test was carried out, so the record of decisions made in these exercises should be complete enough for the authority to follow the chain from observation to remediation. Confirm the exact requirements, including the Article 12(5) timing in Delegated Regulation (EU) 2025/1190 and any national additions, with the authority running the test.
Evidence that shows the replay and purple teaming were completed
A TIBER-EU closure record is only as credible as the paper and system trail behind it. The cards below cover the artifacts an authority or assessor will ask for, and they connect because each one ties a session back to a scenario, a participant and a remediation item. Keep them current during the test, not reconstructed afterward.
Replay record per scenario
Keep one record for each scenario walked through in the replay, showing which red team steps were reviewed, what blue team detection and response looked like at each step, and what more the red team could have achieved. Record the potential remediation discussed for each gap. Check that every scenario in the scope specification has a record, and that the replay took place once the blue team report is substantially drafted, as the framework expects.
Purple teaming agenda and topic record
Keep the agenda and the record of how the control team, red team and blue team jointly chose each topic. Topics can range from table-top discussions to technical walkthroughs and may include issues that could not be tested during active testing. Note the format chosen for each topic and why it was chosen, so an assessor can see the selection was joint and not one-sided.
Attendance and participants by role
Record who attended each replay and purple teaming session, identified by role (control team, red team, blue team, threat intelligence provider, test manager) rather than only by name. Role-based attendance shows that the required parties were present for each exercise. Confirm with the authority how it expects attendance to be recorded and how long those records must be kept.
Session notes and walkthrough outputs
Capture notes, diagrams, screenshots and walkthrough outputs from each session, with a date and author for every entry. These outputs feed directly into the test summary report and the remediation plan, so each finding should be traceable to a session. Keep the working files separate from the final reports so that edits to the notes can be audited.
Action lists linked to remediation items
Maintain an action list where every item from the replay or purple teaming points to a remediation item, an owner and a due date. An action that cannot be traced to a remediation entry is a common gap in closure evidence. Review the list before the test summary report is drafted so that no finding is dropped between the exercises and the final documents.
Dated records for the ten-week window
Keep timestamped records showing the date active testing ended and the dates the replay and each purple teaming session took place. Together they prove both exercises fell within the ten-week window that the framework and the DORA TLPT standards set. Store these in a system with an audit trail so that dates cannot be changed silently.
What the replay and purple teaming cost in money and effort
This table lists each cost component of the replay and purple teaming, who carries it, whether it is one-time or recurring, and what drives it up. Use it to frame a quote request, since no price or duration is published and every figure depends on the agreed scope.
| Cost component | Who carries the cost | One-time or recurring | What drives it |
|---|---|---|---|
| Blue team and control team staff time | Tested entity, internal staff | One-time per test | Number of blue team members, depth of the blue team report draft, and how many scenarios need walkthrough preparation |
| Red team sessions | Red team provider, billed under its contract | One-time per test | Number of scenarios replayed step by step and the number of purple teaming topics agreed with the control team |
| Threat intelligence provider participation | Threat intelligence provider, billed under its contract | One-time per test | Whether the provider joins replay or purple teaming sessions or only supplies input from the targeted threat intelligence report |
| Facilitation and coordination | Tested entity or its implementation partner, depending on contract | One-time per test | Who facilitates the sessions, how many topics run as table-top discussions versus technical walkthroughs, and the length of the agreed programme |
| Lab reproduction for technical walkthroughs | Tested entity or implementation partner, under written scope | One-time per test, reusable if the lab is kept | Whether a proof of concept or alternative scenario must be rebuilt in a test environment before it can be shown |
| Detection tooling for walkthrough evidence | Tested entity, through licences or self-hosted open-source platforms | Licences recur; self-hosted deployment is mostly one-time setup plus ongoing operation | Existing SIEM and case management licences, and whether DFIR-IRIS, OpenSearch Security Analytics or Wazuh already run in the environment |
| Preparation for the next test cycle | Tested entity | Recurring between tests | Whether detection rules, case records and lessons from purple teaming are maintained so the next test starts from a known baseline |
How self-hosted tools support the walkthroughs
DFIR-IRIS is an incident response case management tool that can be self-hosted inside the organization's own infrastructure. During a replay, each scenario can be tracked as a case, so the red and blue teams have one record to walk through rather than scattered notes. The case holds the assets involved, the indicators of compromise, the tasks assigned to each person and the evidence collected.
- Case records: Each case keeps assets, IOCs, tasks and evidence together, with a full audit trail of who changed what.
- Consolidated timeline: The tool builds an investigation timeline from the case data, which helps the teams check the order of attacker steps against what the blue team saw.
- Evidence handling: Evidence entries are logged with SHA-256 verification and chain of custody, so the record of artifacts stays consistent.
- Triage of alerts: Alerts from SIEM, EDR and REST sources can be triaged into cases, which shows how a detection became (or did not become) a case.
- Report generation: Reports are generated from case data, which gives the test summary inputs drawn from records rather than memory.
DFIR-IRIS is licensed under LGPL-3.0-or-later. Confirm the license terms with your legal team before modifying the source code. Check that the case records and audit trail meet your document retention rules for highly sensitive test material.
OpenSearch Security Analytics runs detectors over ingested logs from hosts, network devices and cloud services. Detectors use prepackaged or custom Sigma rules, so the team can test whether a red team technique would have produced a match. During purple teaming, the control team can compare the scenario steps against the rules that fired and the rules that stayed silent.
- Detector matches: Detectors match ingested logs against Sigma rules, showing which techniques were visible to the blue team.
- Findings: Each match is recorded as a finding with the rule, log type and severity, which supports a clear review of coverage.
- Alerting channels: Alerts can be sent to channels such as Slack or email, so the team can confirm that notifications reached the right people.
- Correlation graph: The correlation engine links findings across log types, which helps show multi-step activity that single rules would miss.
- Custom rules: Teams can write custom Sigma rules for scenario-specific behavior discovered during the replay.
OpenSearch Security Analytics is licensed under Apache-2.0. Confirm which log sources the blue team has onboarded and which techniques lack rules before the session, so the discussion focuses on real gaps. Check the documented detector and rule behavior for your OpenSearch version.
Wazuh decodes collected logs and compares each event against its ruleset. In a walkthrough, the blue team can show which red team actions produced alerts, at what time and with what mapping, and where the monitoring stayed quiet. The ruleset includes over 3,000 built-in rules and decoders, and teams can add custom rules for the environment.
- Rule matches: Matching events are written to alerts.log and alerts.json, giving the team a file-level record for each alert.
- MITRE ATT&CK mapping: Alerts are mapped to MITRE ATT&CK, which helps the teams discuss coverage by technique.
- Forwarding to the indexer: Alerts are forwarded to the Wazuh indexer, where they can be reviewed in the dashboard during the session.
- Custom rules: Rules added for scenario-specific activity can be tested against the replayed events.
- Decoder review: Decoders show how raw logs were parsed, which helps explain a missed detection that was caused by a parsing gap.
Wazuh is licensed under GPL-2.0-only. Confirm the license obligations that apply if you modify or distribute the software. Check that the alert files and dashboard data are retained and access-controlled, because they reveal details of your detection gaps.
Where replay and purple teaming usually go wrong
Both learning exercises are mandatory and both sit on a fixed clock: they must happen within ten weeks of the end of active testing and feed the test summary report and remediation plan. The gaps below tend to appear in the same places, so each card pairs a failure with the check that catches it before the window closes.
Replay held before the blue team report
Teams often run the replay as soon as active testing stops, while the blue team still has detection data to pull and no draft to compare against. The replay works best once the blue team report is substantially drafted, because the blue team can then walk through what it saw and what it missed for each scenario. Check that the replay date follows the blue team draft and that both teams have the scenario records in front of them.
Purple teaming with no recorded topics
Purple teaming becomes a formality when the session runs without topics agreed in advance by the control team, red team and blue team. Topics can range from table-top discussions to technical walkthroughs, so the fix is a written topic list agreed before the session, covering issues that could not be tested during active testing and any proofs of concept. Keep the list and the decisions taken in the session as a record.
Findings not traced into the remediation plan
Replay and purple teaming produce observations that often stay in meeting notes rather than reaching the remediation plan. Each finding should be logged with an owner, the scenario it came from and the remediation measure it supports, so it can be carried into the test summary report. Ask the control team to confirm that every item from both exercises has a matching line in the plan before the plan is submitted.
Missing attendance by role
A session can be held on time and still fail if the people who own the decisions are absent. The red team, blue team and control team each contribute something different, and a replay without the people who ran the detection or response work leaves gaps the exercise was meant to close. Set attendance by role in the invitation, record who attended, and confirm that the control team and blue team leads are present for the whole session.
Late scheduling that breaks the window
The ten-week limit runs from the end of active testing, and scheduling is often left until the blue team report is finished. Each week of delay compresses the time left for the findings to reach the test summary report and remediation plan. Agree dates for both exercises during the closure preparation, name a fallback date for each, and confirm with the test manager which date will be counted as the completed exercise.
Weak handling of session material
Replay and purple teaming sessions often produce detailed attack paths, vulnerability details and detection gaps, which makes the session material highly sensitive. Notes, slides and recordings are frequently shared by email or left on shared drives with wider access than the test requires. Restrict access to named participants, store the material in an access-controlled location with an audit trail, and confirm the handling rules with the test manager before the first session.
Questions buyers ask about the replay and purple teaming
How much effort do the replay and purple teaming exercises take?
Effort depends on how many scenarios the test covered, how far the blue team report has progressed, and how many purple teaming topics the control team, red team and blue team agree to cover. The replay walks through each scenario step by step, so a test with more scenarios needs more working sessions. Purple teaming can range from a table-top discussion to a technical walkthrough, and the cost moves with that format. Ask your authority and your test provider to break the effort down by scenario and by topic in writing before the closure phase starts. The effort is largely a one-time cost for this test cycle, although the lessons feed the remediation plan, which carries its own work.
Can we run the replay and purple teaming without outside help?
The entity runs these exercises with its own control team and blue team, but external providers may join certain sessions depending on the procurement and the test set-up. The red team testers take part in the replay because they know what they attempted, so the tested entity cannot run the replay without them. Whether an outside firm can facilitate, document or prepare materials is a question for your authority and your contract. Any outside help you bring in to prepare systems, collect logs or organize evidence is a separate scope from the TIBER-EU exercises themselves. Confirm the exact roles with your authority before you assign work.
What is the time window for the replay and purple teaming?
Both exercises must take place within ten weeks of the end of active testing. The replay is ideally held once the blue team report is substantially drafted, so the blue team has its account of detection and response ready to compare against the red team's actions. Purple teaming follows the replay inside the same ten-week window. Plan backward from the end of active testing and book the control team, red team and blue team calendars early, because the window is fixed and a missed session cannot be recovered later. Confirm your authority's interpretation of the window and any internal deadlines it sets for the blue team report.
What does the work need from our internal staff?
The work needs staff who know the detection and response tooling, the affected business services, and the decisions made during the test. The control team coordinates the exercises, the blue team explains what it saw and how it responded, and the people who own remediation should attend the sessions where fixes are discussed. Senior staff should expect to commit time across the two exercises, and their availability will decide whether the schedule holds. A useful step is to name one owner for each scenario so that questions from the red team have a clear point of contact. Confirm role assignments and the expected attendance with your authority at the start of closure.
Can the replay and purple teaming be combined into one session?
The framework treats the replay and purple teaming as two separate exercises with different purposes, and both must take place within the same ten-week window. The replay reviews each scenario in order, while purple teaming covers topics the control team, red team and blue team choose together, such as issues that could not be tested, alternative scenarios or business continuity exercises. Some entities schedule the two on consecutive days or in the same week to reduce travel and calendar conflicts, but the content of each must still be delivered. Confirm with your authority whether a combined schedule is acceptable and how the outputs should be recorded for each exercise.
What will the authority ask to see from these exercises?
The authority will expect evidence that both exercises took place within the ten-week window and that their findings reached the test summary report and the remediation plan. Useful records include the agenda for each session, attendance, the scenario-by-scenario notes from the replay, the purple teaming topics agreed by the three groups, and the actions each topic produced. Keep the records in the case management system you use for the test so they can be traced back to the blue team report. Ask your authority for its template and the level of detail it expects before the sessions begin, because the format of acceptable records varies by jurisdiction.
Primary sources for the replay and purple teaming
Start with the *TIBER-EU Framework* dated January 2025, which sets out the replay and purple teaming as mandatory closure-phase exercises. The framework is the document an adopting authority and the tested entity will treat as the reference, so the test manager, control team and blue team should each hold a copy and agree in writing which version governs the test. The ECB's announcement of 11 February 2025 explains why the update was made: it aligned the process steps with the deliverables and strict timelines of the DORA threat-led penetration testing standards and made purple teaming mandatory. Read the announcement first for the summary of changes, then the framework for the detail. Confirm with your national authority whether it has published its own implementation document that adds local rules on top of the European text.
For the binding timeline, go to Commission Delegated Regulation (EU) 2025/1190 on EUR-Lex, the DORA technical standard on threat-led penetration testing. Its Article 12(5) requires the replay and purple teaming no later than 10 weeks after active testing ends. Because a regulation is the legal instrument and the framework is guidance that implements it, a missed date is a compliance gap, not a documentation issue. Ask your authority and your red team provider to put the replay and purple teaming dates into the project plan at the start of the testing phase, counting back from the actual end of active testing. Note that the end date is set by the test manager, so agree it in writing before the red team starts reporting.
How DeployOpen prepares for replay and purple teaming
The sequence gives the control team, red team and blue team a documented, evidence-backed setting for the replay and purple teaming sessions that feed the test summary report and remediation plan. DeployOpen prepares the systems, records and materials; the tested entity and the authority own the outcomes.
Agree scope and deliverables in writing
Before any preparation starts, DeployOpen and the tested entity agree in writing which systems, evidence sources, session formats and deliverables fall within DeployOpen's role. The written scope sets the boundaries for the replay and purple teaming work. The quote follows from this scope, so the entity should confirm which activities are included and which remain with its own teams. The step is complete when both parties have signed the agreed scope.
Assemble the evidence trail from the test
DeployOpen gathers the case records, alert data, timelines and logs produced during active testing from the entity's own environment and tooling. This includes the material the blue team will need when it reviews each scenario step by step. The evidence is organized so that each scenario can be traced from red team action to detection, response and gap. The step is complete when the entity's control team confirms that the trail covers every scenario in scope.
Configure case and detection tooling for review
DeployOpen prepares the case management and detection platforms the entity runs, such as DFIR-IRIS for case records and the alerting sources in its SIEM or log analytics stack. Configuration covers access for the people who will attend, audit trail settings and the views needed to walk through alerts and correlations. Any change to production detection rules is agreed in advance and recorded. The step is complete when a test run confirms the reviewers can open each case and its evidence without changing the record.
Schedule sessions and keep the record
DeployOpen supports the entity in booking the replay and purple teaming sessions with the control team, red team and blue team, and keeps a written schedule of attendees, dates and the topics assigned to each session. Attendance and decisions are logged so the entity can show how the exercises were run. The entity confirms the dates with the authority, and the dates must fall within the ten weeks after active testing ends. The step is complete when the schedule and attendance log are filed with the test documentation.
Prepare walkthrough and topic materials
DeployOpen prepares the materials for the replay, covering each scenario's attack path, detection points and gaps in a form the red and blue teams can follow together. For purple teaming, it prepares material on the topics the control team, red team and blue team agree, which may range from table-top discussions to technical walkthroughs. The materials are reviewed by the entity before use. The step is complete when the control team approves the walkthrough pack for each session.
Prepare systems and test environments
DeployOpen readies the lab, staging or demonstration systems the sessions will use, such as proof-of-concept environments, reproduced alerts or business continuity exercise setups. Each environment is isolated from production, and access is limited to the named participants. Changes made for the sessions are recorded so they can be reversed. The step is complete when a dry run confirms each system behaves as described in the walkthrough pack.
Hand over outputs for the closing reports
After each session, DeployOpen collects the notes, decisions, open items and evidence produced, and passes them to the entity in an organized form. These outputs feed the test summary report and the remediation plan, which the entity owns. DeployOpen does not run the authority's assessment, issue reports or certify the attestation; those belong to the authority and the entity. The step is complete when the entity confirms receipt and records the handover.
