Active red team testing: TIBER-EU requirements and evidence

What active red team testing asks for and why the 12-week minimum matters

Active red team testing runs for at least 12 weeks against live production systems, with the goal of reaching the flags agreed in the scope. The 12 weeks are a minimum, not a target. They give the red team time to run every attack phase of each scenario and try to reach the flags, and they give the control team enough time to see whether the entity's staff detect the attacker. For a financial entity in a TIBER-EU or DORA threat-led test, the core question for the file is simple: can the entity show that the red team ran for the required period, against the systems in scope, and that every action is recorded? The risk this phase tests is dwell time: how long an attacker can operate inside the environment before staff notice, and what they do once they do. Because the test runs on production systems, that risk is measured on the same infrastructure customers and regulators depend on, which is why the framework treats the test as a controlled simulation with its own safeguards.

The hard part is consistency over the full period. Leg-ups are only allowed when the red team cannot progress, and each one must be provided by the control team, approved by the control team and test manager, and logged, so the record of what was given to the attacker must be complete when the test ends. Weekly update meetings require the red team to report progress to the control team and test manager, and that rhythm can slip over several months as people rotate and priorities shift. Logs are the thread that ties the phase together: every red team action feeds the replay with the blue team and the red team test report. Before the test starts, confirm with your test manager who keeps the leg-up register, how weekly minutes are stored, and which logs the testers must keep. Ask your provider to show how these records will be checked before the end of active testing, not after it.

Which systems, flags, teams and third parties sit inside active testing

Five decisions set the boundaries of active testing before the first attack step runs. Each one changes what the red team may touch, how the blue team responds and how much work the test requires. The scope specification document and the red team test plan record these boundaries, and the control team lead holds the decision on any change.

Critical functions and flags

The critical or important functions and the flags agreed in the preparation phase define what the red team must try to reach. Each flag should map to a business impact the entity can explain to its board, not to a generic system name. Check that every flag has a clear owner, a defined location and a stated way the red team proves it reached the flag. Vague flags make it hard to judge whether a scenario succeeded.

Production systems and dependencies

Active testing runs against live production systems, so the boundary must include the upstream and downstream services each flag depends on, such as identity providers, message queues and databases. Confirm which dependencies are in scope, which are excluded, and who can stop a dependency that becomes unstable. An outage caused by a dependency nobody listed is a scoping failure, not a testing result.

ICT third-party staff and infrastructure

Some flags run on infrastructure or accounts that an ICT third-party provider operates. Before testing, the entity must establish whether the red team may touch that provider's staff, tenants or hosted components, and obtain the provider's written agreement where its contract requires it. Ask each provider how it will detect and respond to the red team, and who on its side can confirm or suspend activity.

Control team roles

The control team supplies every leg-up, approves changes with the test manager and logs each decision. It also receives the red team's weekly progress reports and decides how to respond when staff detect the red team. Name a control team lead with authority to suspend testing, confirm deputies for absences, and agree how the team keeps the test secret from people outside it.

Blue team boundaries

The blue team defends the entity's systems without knowing the details of the attack plan, so its responses reflect normal operations. Define which detection and response staff are in the blue team, which tools they use for monitoring, and which actions they may take without consulting the control team. Document these limits so that a containment step does not end the test by accident, and so that the replay later reflects what staff actually saw.

Running the 12 weeks: from kickoff to restoration

This sequence keeps the active phase of a TIBER-EU test within its agreed window, makes every red team action traceable for the replay, and ends with the tested systems returned to a known clean state. Each step produces a record that the control team and test manager can check.

Confirm the 12-week window and scenario sequencing
Before the first action, the control team lead confirms the start and agreed end of active testing, and records which scenarios will run in parallel and which in sequence. The framework requires at least 12 weeks so the red team can run all attack phases and try to reach the flags, and each scenario must complete its in, through and out phases. The output is a signed schedule in the test plan file, showing the window, scenario order and the in, through and out dates for each scenario. Ask the test manager to confirm the schedule before any red team traffic reaches production.
Set up logging for every red team action
The blue team and the engineering team configure the log sources the test depends on, such as host, network device and cloud service logs, and confirm that the red team's actions reach the detection platform. Teams commonly use a SIEM or detection stack such as OpenSearch Security Analytics, Wazuh, osquery or Velociraptor, but the choice depends on the entity's own environment and should be confirmed with the vendor. Testers record each action with a timestamp, source, target and technique so it can be replayed with the blue team later. The output is a logging baseline document and a test-run action log that the control team reviews at the first weekly meeting.
Hold the weekly update meeting
Each week the red team reports progress to the control team and the test manager, covering which phases are complete, which flags remain open and which obstacles block progress. The control team lead chairs the meeting and confirms which actions were taken, which were detected and whether any scenario is drifting from the plan. The output is a meeting record listing decisions, open issues and any change requests, signed off by the test manager. The framework expects at least weekly meetings, and daily meetings are highly recommended during critical phases.
Approve and log any leg-ups
When the red team cannot progress, the control team may provide a leg-up beyond those in the plan. Each leg-up must be requested in writing, approved by both the control team and the test manager, delivered by the control team and logged. The log entry records the reason, the access or information provided, the approvers, the time given and the effect on the scenario, so that the red team test report can separate what the red team achieved alone from what it achieved with help. The output is a leg-up log entry for each request, and an unapproved leg-up is treated as a process failure.
Handle staff detection and possible suspension
When staff at the entity or at an ICT third-party provider detect the red team, the control team proposes measures to continue testing while keeping the test secret from those who do not need to know. The test manager validates the proposal before it is applied. In exceptional circumstances, the control team lead may suspend the test after consulting the test manager, and as a last resort testing may continue as a limited purple teaming exercise that counts toward the 12 weeks. The output is a detection record stating who detected the activity, when, the decision taken, the reasoning and the validation by the test manager. Confirm with the test manager in advance what counts as exceptional and who holds the authority to suspend.
Hold daily meetings during critical phases
During phases where the red team is close to a flag or where a detection event is open, the control team holds short daily meetings. The purpose is to keep the control team informed of the current state, approve any urgent leg-up and decide whether the test should continue as planned. The output is a short daily log showing the phase, current status, decisions made and the next check-in time. Daily meetings are highly recommended by the framework during critical phases, so the control team should agree in advance which phases count as critical.
Run restoration after the agreed end
After the agreed end of active testing, the control team lead informs the blue team, and the testers begin restoration. Restoration covers deleting or changing compromised credentials and keys, deactivating command and control channels, activating kill switches where used, and removing backdoors and any malware the red team placed. The control team then checks each item against the action log, so that every change the red team made is accounted for. The output is a signed restoration checklist, reconciled against the action log, that the test manager receives before the closure phase begins.

How an assessor tests active red team testing

This table compares each part of active red team testing against the approach an assessor takes, the evidence to prepare and the gaps that appear most often. Read each row as a question the assessor will ask, and use the evidence column as your preparation checklist before the closure phase begins.

Test area	Assessor approach and evidence requested	Common findings
Duration of active testing	Compare the agreed start and end dates with the minimum of 12 weeks in the approved plan. Request the calendar of active testing, any suspension records and the dated start and stop notices issued by the control team lead.	Calendar gaps or suspensions not counted, or start dates that do not match the first logged red team action.
Scenario completion (in, through, out)	Check that each scenario shows an in phase, a through phase and an out phase, whether run in parallel or in sequence. Request per-scenario progress records and the red team's status against each flag.	Scenarios stopped before the out phase, or flags marked reached without matching log entries.
Leg-up approval and logging	Confirm each leg-up was provided by the control team, approved by the control team and test manager, and logged with its reason. Request the leg-up register and the approval records.	Leg-ups given informally, approvals dated after delivery, or leg-ups missing from the register.
Weekly update and daily meeting records	Review minutes of weekly update meetings where the red team reported progress to the control team and test manager. Check whether daily meetings took place during critical phases and whether actions were tracked.	Missing weekly minutes, no attendance from the test manager, or open actions carried forward without owners.
Handling of staff detection	Check how detections by entity or ICT third-party staff were recorded, what measures the control team proposed to continue, and whether the test manager validated them while the test stayed secret.	Detection events not recorded, measures proposed without validation, or third-party staff involvement not identified.
Suspension decisions and limited purple teaming	Review any suspension, the consultation with the test manager and the reasoning for the decision. If testing continued as limited purple teaming, confirm the record shows it counted toward the 12 weeks.	Suspensions without documented consultation, or purple teaming time counted toward the minimum without a record.
Completeness of the action log	Sample logged red team actions against the replay material and the red team test report. Confirm timestamps, actors, targets and outcomes are present and that the log covers the whole testing period.	Gaps in timestamps, actions absent from the log, or log entries that cannot be matched to a scenario or flag.
Evidence of restoration	Request records of credential and key deletion or change, command and control deactivation, kill switch activation and removal of backdoors and malware. Confirm the control team lead notified the blue team after the agreed end.	Restoration checklists signed without verification, or compromised credentials still valid after testing ends.

Which records prove that active testing ran as planned

Active red team testing is only as credible as the records behind it. The cards below cover the artifacts an authority, the test manager and a later assessor will ask for, and they connect through the control team, which owns the logs, approvals and meeting records that show each action was controlled and traceable.

Complete red team action log

This is the master record of every action the testers take against live systems, with timestamps, source hosts, targets, techniques and the scenario and phase each action belongs to. It feeds the replay with the blue team and the red team test report, so gaps in it weaken the whole closure phase. Check that entries are written during testing rather than reconstructed afterward, that the log is append-only or hash-protected, and that the control team can export it in full. Ask who holds the signing key and who reviews the log at each weekly meeting.

Leg-up log with approvals

Every leg-up given beyond the test plan must be provided by the control team, approved by the control team and test manager, and logged. Each entry should record the reason the red team could not progress, what was provided, the approvers, and the date the leg-up was applied. Confirm that no leg-up appears in the red team action log without a matching approval entry, because an unexplained shortcut can make a successful attack look more capable than it was.

Weekly and daily meeting minutes

The control team holds at least weekly update meetings where the red team reports progress to the control team and test manager. Daily meetings are highly recommended during critical phases. Minutes should capture progress against each scenario, decisions on leg-ups and scheduling, open risks and actions with owners. Keep minutes dated and version controlled, and confirm that the test manager has reviewed and accepted each set before the next meeting.

Detection and response decisions

When staff of the entity or of an ICT third-party provider detect the red team, the control team proposes measures to continue while keeping the test secret, and the test manager validates them. Record the detection time, the alert source, what the blue team knew, the proposal, the validation and the outcome. These records show whether the entity's monitoring worked and whether the test was kept on track, and they should be cross-checked against the action log to confirm timing.

Suspension and limited purple teaming record

If the control team lead suspends testing in exceptional circumstances, after consulting the test manager, the suspension reason, decision time, scope of the pause and resumption criteria must be written down. If testing continues as a limited purple teaming exercise as a last resort, record which activities became shared and how they count toward the 12 weeks of active testing. Ask for this record even when no suspension occurred, since a clean statement that none was needed is itself evidence.

Restoration and cleanup records

After the agreed end of active testing, the control team lead informs the blue team and the testers restore the environment. Keep a dated checklist covering deletion or change of compromised credentials and keys, deactivation of command and control, kill switch checks, and removal of backdoors and malware, with the person who verified each item. Ask for independent verification scans or host checks where possible, and retain this record with the closure evidence because it proves the environment was returned to a known state.

What active red team testing costs in money and effort

This table lists each cost component of the active testing period, who carries it, whether it is one-time or recurring, and what drives it up or down. Use it to structure a written quote and to see where self-hosted open-source tools shift spend from licenses to engineering time. The main takeaway is that the largest recurring costs come from people's time across the 12-week minimum, so scope and meeting discipline matter as much as tooling.

Cost component	One-time or recurring	What drives it	How to keep it down
Red team testers' fees for the active period	One-time within the engagement, priced over the active period	Number of scenarios, attack phases to complete, and whether scenarios run in parallel or in sequence	Ask for a fee breakdown by scenario and phase in the written quote, and confirm which phases are included
Control team and test manager time	Recurring weekly for the duration of active testing	Length of active testing, number of scenarios, and frequency of update and daily meetings	Agree meeting cadence and reporting formats in advance, and confirm who attends which meetings
Blue team time on detection and replay preparation	Recurring during testing, with a one-time peak at replay	Maturity of existing detection, volume of logs to review, and number of staff who must respond	Tune detections before testing starts, and log red team actions so replay preparation draws on existing records
Logging infrastructure and storage	Recurring for the testing period, plus retention after testing	Volume of ingested logs from hosts, network devices and cloud services, and retention needed for replay and evidence	Confirm log sources and retention periods in scope, and reuse existing SIEM or open-source pipelines where they already meet the need
Open-source detection and collection tools (for example, Wazuh, OpenSearch Security Analytics, osquery, Velociraptor)	One-time setup, then recurring operation and upgrades	License spend is typically nil for these tools, so cost shifts to engineering time for deployment, rule tuning, hardening and maintenance	Budget engineering hours explicitly, confirm licensing terms for each tool with its vendor or project, and plan upgrades outside the testing window
Leg-up preparation by the control team	Recurring whenever a leg-up is needed	Number of leg-ups beyond the plan, and how quickly the red team can progress without them	Anticipate likely blockers in the red team test plan and prepare approved leg-ups in advance, with logging from the start
Handling staff detection and proposed continuation measures	Recurring when detection occurs	Number of detections, involvement of ICT third-party providers, and whether a suspension is considered	Define in advance who receives detection notices and who validates continuation measures with the test manager
Restoration effort	One-time at the agreed end of active testing	Number of compromised credentials, keys, command and control channels, and backdoors to remove	Keep a running inventory of all artifacts created during testing so cleanup is a checklist rather than a search
External review of the evidence	One-time per test, with possible follow-up on findings	Volume of logged actions and the depth of independent review requested by the authority or auditor	Confirm in writing what the independent reviewer will examine, and structure logs so they can be sampled efficiently

Which open-source tools can produce detection and forensic evidence during active testing

Four self-hosted open-source tools can produce much of the detection and forensic evidence that active testing relies on, provided the organization deploys them inside its own environment and confirms they fit its logging architecture. OpenSearch Security Analytics (Apache-2.0) runs detectors that match ingested logs from hosts, network devices and cloud services against prepackaged or custom Sigma rules. Each match is recorded as a finding with its rule, log type and severity, and alerts go to channels such as Slack or email. For the control team, the useful output is a timestamped record showing whether staff detected a red team action, which the control team can compare with the action log during weekly update meetings. Confirm which log sources your environment can feed into the detectors, because a detector cannot flag activity that never reaches it.

Wazuh (GPL-2.0-only) decodes collected logs and compares each event against a ruleset of over 3,000 built-in rules and decoders, plus any custom rules your team writes for the scenarios in the test plan. Matching alerts are written to alerts.log and alerts.json, mapped to MITRE ATT&CK techniques and forwarded to the Wazuh indexer for review in the dashboard. The ATT&CK mapping helps the blue team and test manager check detection coverage against the attack phases in the red team test plan. The JSON output also gives the replay session a structured input. osquery (Apache-2.0 OR GPL-2.0-only) complements these tools by exposing running processes, open network connections and file hashes as SQL tables, with osqueryd scheduling queries across a fleet. After the agreed end of active testing, these queries can help the testers and blue team confirm that compromised software and malware have been removed.

Velociraptor (AGPL-3.0-only) collects forensic artifacts defined in VQL from endpoints and runs hunts across groups of systems, including machines that were offline and collect when they reconnect. Each hunt gets its own notebook for analyzing the combined results, which supports forensic review of what the red team reached. These tools record and analyze activity, but they do not replace the red team action log. The control team still has to keep that log of every red team action, because the replay and the red team test report depend on it. Before relying on any of these tools, confirm with your own counsel and engineers that the AGPL-3.0 and GPL obligations fit your distribution and hosting model, and that each tool's coverage matches your environment.

Who runs the control team, the red team and the independent assessor

The entity owns the test and every decision made during active testing. Its control team, led by the control team lead, is the only party that gives leg-ups, approves them with the test manager, and proposes measures when staff detect the red team. The blue team responds as it would to a real attack, without knowing the test is under way, so its detection and response are measured honestly. A named logging owner keeps the record that the replay and the red team test report depend on.

Control team lead: Holds the weekly update meetings, approves and logs every leg-up, and informs the blue team when active testing ends.
Blue team: Detects, investigates and responds to red team activity under normal operating conditions, and keeps its own records of what it saw.
Logging owner: Confirms that all red team actions are recorded in a form that can be replayed, and that the record is retained and protected.
Suspension decision-maker: The control team lead may suspend testing in exceptional circumstances after consulting the test manager, so this authority should be defined in advance.

Confirm with your authority who may act as control team lead, how the blue team is kept unaware, and who signs off restoration at the end of testing.

Where active testing usually falls short and how to close each gap

Active red team testing runs for at least 12 weeks against live production systems, and most of its weak points show up in the records rather than in the attacks. The cards below cover six gaps that assessors often find, the step that closes each one, and the artifact that proves it. Check each artifact before the test starts, not after the replay.

Action logs without timestamps or actors

Every red team action should be logged so the replay with the blue team and the red team test report can reconstruct what happened. A log entry without a precise timestamp, source host, or named operator cannot be matched to a detection event, so the blue team cannot tell whether a control worked. Before testing starts, agree a log schema with the testers that records time, actor, target, technique, and outcome for each action, and check a sample entry during the first week. The artifact is a log extract that a reviewer can line up against the blue team's detection timeline.

Leg-ups without logged approval

Leg-ups are extra access or information the control team gives the red team when progress stalls. Each one must be provided by the control team, approved by the control team and test manager, and logged. A leg-up given verbally or in a chat thread breaks the chain of evidence, and it can make a successful attack look stronger or weaker than it really was. Require a written request, a named approver, and a log entry for each leg-up before it is delivered. The artifact is a leg-up register with request, approval, delivery time, and the scenario phase it served.

Staff detection handled informally

When staff of the entity or an ICT third-party provider detect the red team, the control team proposes measures to continue while keeping the test secret. The test manager must validate those measures. Informal fixes, such as a quick call to the SOC lead to stand down an alert, remove the test from the record and can hide a real gap in detection. Set a written escalation path that routes every detection to the control team lead and test manager within the same working day. The artifact is a detection decision record showing the proposed measure, the test manager's validation, and the effect on the scenario.

Meetings held without a record

The control team holds at least weekly update meetings where the red team reports progress to the control team and test manager, and daily meetings are highly recommended during critical phases. Meetings that happen but leave no minutes give the authority no proof that oversight occurred, and decisions get lost between weeks. Assign a note taker, circulate minutes with open actions, and store them with the test records. Ask whether daily meetings are scheduled for critical phases and who decides when a phase is critical. The artifact is signed weekly minutes with a decision log and an action list.

Restoration that misses backdoors and C2

Restoration ends testing and must remove what the red team left behind. Deleting or changing known credentials and keys is only part of the job. Command and control channels, kill switches, and backdoors or malware can persist in scheduled tasks, service accounts, cloud roles, or network paths that nobody listed. Build the restoration checklist from the red team's action log rather than from memory, then verify each item with a separate scan or query, such as osquery for running processes or Velociraptor for artifacts across endpoints. The artifact is a restoration checklist cross-checked against the action log, with verification output for each item.

Active testing stopped without a documented decision

Active testing should run for at least 12 weeks so the red team can complete every attack phase and try to reach the flags. If testing stops early because the team is busy, a system fails, or a suspension is informal, the test may not meet its minimum duration and the results will be incomplete. Any early end or suspension must be a written decision by the control team lead after consulting the test manager, with the reason and the weeks completed. The artifact is a signed suspension or end-of-testing record that states the weeks completed, the scenarios finished, and the remaining gaps.

Questions buyers ask about active red team testing before hiring help

How much effort does the active red team phase need from our own staff?

Your staff carry the most sustained effort in the testing phase, even though the red team does the attacking. The control team, which is staffed from the entity, holds at least weekly update meetings with the red team, the test manager and the control team lead, and it supplies every leg-up the red team needs. The control team also proposes responses when staff or an ICT third-party provider detect the red team, and the blue team works through detections in the same period. Daily meetings are highly recommended during critical phases, so plan for a standing commitment across the full testing window. Confirm named individuals, their backup cover and how many hours per week each role will need before the test starts.

Can we run the active red team testing without an outside partner?

TIBER-EU does not prohibit running parts of a test internally, but the framework separates roles that must stay distinct. The threat intelligence provider and the red team testers are procured from outside the entity, and the authority's TIBER Cyber Team and test manager supervise the process. Your own team can own the control team, the blue team and the preparation of systems and logging, which is where most of the internal load sits. DeployOpen can prepare systems, logging and evidence for the entity, but it does not act as the red team testers, the threat intelligence provider, the test manager or the party that issues the test summary or attestation. Check the adopting authority's rules on who may perform each role before deciding.

What drives the time and cost of active red team testing up or down?

The minimum active testing period is 12 weeks, and scope, scenario count and the level of monitoring at the entity set most of the effort above that floor. Costs arise from the red team testers, the threat intelligence provider, the internal control team and blue team, and any work to prepare logging and detection tooling. Costs rise when there are more scenarios, more in-scope systems, more third-party providers involved, or frequent leg-ups that need approval and logging. They fall when logging is already centralized, detection rules are mature and the control team has clear decision rights. Ask any provider to break its quote into testing days, reporting, control team support and change requests, and to state what triggers a change order.

Can the 12 weeks of active testing run scenarios in parallel?

Yes. The framework allows scenarios to run in parallel or in sequence, with the 12 weeks treated as a minimum that must cover all attack phases. Each scenario still has to complete its in, through and out phases, so parallel running only works if the red team, control team and blue team can handle the concurrent activity. Parallel scenarios increase the logging volume, the number of leg-up decisions and the chance that staff detect the red team in more than one place at once. Agree the schedule in the red team test plan, and confirm with the test manager how overlapping scenarios will be sequenced for weekly reporting.

What happens when our staff detect the red team during testing?

Detection does not automatically end the test. The control team proposes measures so the test can continue while staying secret from the blue team, and the test manager validates those measures. In exceptional circumstances the control team lead may suspend the test after consulting the test manager. As a last resort, testing can continue as a limited purple teaming exercise, and that period counts toward the 12 weeks. Every detection and response should be logged, because the logs feed the replay with the blue team and the red team test report. Agree the decision path and the named people who can suspend testing before the first day of active work.

Does DeployOpen issue the TIBER-EU test report or attestation?

No. DeployOpen does not issue test reports, attestations or certifications for a TIBER-EU test. Its role is to plan, implement, harden and document the self-hosted open-source platforms, logging and detection stack that the entity uses during the test, and to support evidence preparation for the closure phase. The red team and blue team reports, the test summary report and the attestation are produced by the parties the framework assigns them to, with the authority's TIBER Cyber Team and test manager holding oversight. Ask any partner to show in writing which party produces each deliverable and who signs it.

What should a written scope for active testing include before work starts?

A written scope should name every deliverable, owner and date before the active phase begins. Ask for the systems and networks in scope and those explicitly excluded, the logging sources that will be onboarded, and the detection tools in use. Require a clear statement of how leg-ups are requested, approved and logged, the weekly and daily meeting cadence, and the decision rights for suspension. Include the restoration procedures that end testing, such as credential and key changes, command and control deactivation, kill switches and backdoor removal, and who verifies them. Finally, confirm the change process, the reporting format and what is excluded from the fixed fee.

How DeployOpen prepares logging, evidence and restoration for active testing

DeployOpen helps regulated organizations prepare the systems, logging and evidence trail that active red team testing depends on, inside their own infrastructure. The organization keeps ownership of its controls and of the TIBER-EU decisions, while DeployOpen prepares the environment and documentation that the control team and testers work from.

How we scope

Written scope agrees which production systems, log sources and monitoring tools are in place before active testing starts.
Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work begins.
The scope names who holds restoration duties, credential inventories and kill switch owners for each system in the test.

How we build

Logging pipelines are configured so every host, network device and cloud service feeds the detection tooling the blue team reviews.
Open-source detection tools such as Wazuh, OpenSearch Security Analytics, osquery and Velociraptor are deployed inside your environment and tuned to your log sources.
Action logs, leg-up records and change history are structured so the replay with the blue team can reconstruct each red team action.

How we hand over

Handover includes runbooks for logging, evidence collection and the restoration steps that end active testing.
Restoration checklists cover credential and key changes, command and control deactivation, and removal of backdoors and malware.
Documentation maps logs and records to the evidence the test manager and independent assessors will ask to review.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Support can cover tuning of detection rules and log coverage between the 12 weeks of active testing and later test cycles.
Confirm with your test manager and threat intelligence provider which artifacts they require before quoting the work.