What the TIBER-EU red team test plan must set out before any attack starts
The red team test plan is the document the red team testers write, based on the targeted threat intelligence report, to describe how they intend to attack the entity's live systems. The control team and the test manager must approve the final plan before any live testing starts, and they must also approve any later changes. The plan exists to keep live attacks against production within boundaries the entity has agreed in advance. Without it, a test can drift into systems, techniques or timings nobody authorized, and the entity's staff may not be able to tell a test from a real incident.
Planning is hard for three reasons. The first is scenario detail: for each scenario the plan must name the simulated threat actor, its intent, the target functions and supporting systems, the confidentiality, integrity, availability and authenticity aspects under test, the flags, and every expected attack path with its prerequisites, possible leg-ups and their deadlines. The second is ethical limits: the plan must state allowed and forbidden techniques, including ethical limits for social engineering and the protection of privacy. If physical security is in scope, it must also show the safeguards, including formal consent from the entity, that keep the work inside legal boundaries. The third is timing. The plan schedules activity for each scenario at least across the in, through and out phases, and the control team must prepare leg-ups so they can be delivered without raising alarms or causing delay.
Before the plan meeting, the control team and test manager should confirm who signs off each element, how progress reports will reach them and how often, which communication channels the testers will use, and how the entity's risk management controls will be updated once the plan is final. DeployOpen can help the entity prepare its own systems, logging and risk controls, and its evidence of them, but it does not write the red team test plan, approve it or issue any TIBER-EU report or attestation. Those remain with the red team testers, the control team, the test manager and the authority. Confirm the approval roles and the current version of the framework with your authority before drafting.
Which elements the plan must contain for each scenario
Each scenario in the red team test plan has to be described completely enough that the control team can prepare for it and the test manager can judge whether the attack is realistic. The six elements below move from who the attacker is, to what it targets, to how the attack unfolds and when each stage runs. Read them together: a plan that names an actor but no attack path, or flags but no schedule, will not give the control team what it needs.
Simulated threat actor and intent
The plan names the threat actor the scenario imitates, along with its intent and goals, such as disrupting a service, stealing customer data or manipulating transactions. The threat intelligence report is the basis for this choice, so the control team should be able to trace each actor back to the intelligence that supports it. Check that the goal is specific enough to tell when the test has succeeded from the attacker's point of view, and that the intent matches the entity's actual critical functions rather than a generic threat.
Target functions and supporting systems
For each scenario, the plan lists the business functions under attack and the systems that support them, including applications, identity services, networks, data stores and third-party connections. This turns an abstract threat into a defined set of assets the testers may touch. Ask whether every system needed to deliver the function appears in the list, because a missing dependency often becomes the route the testers take and the control team did not expect.
Targeted confidentiality, integrity, availability and authenticity
The plan states which of the four aspects, confidentiality, integrity, availability and authenticity, each scenario aims to compromise. Naming the aspect tells the blue team what kind of damage to watch for and tells the testers what success looks like. A scenario that targets integrity of payment instructions calls for different detection signals than one that targets availability of a trading platform, so the plan should not leave this vague.
Flags to capture
Flags are the specific objectives the testers try to reach, such as obtaining a particular dataset, executing a transaction in a test account or disabling a monitoring function. Each flag should be concrete, verifiable and agreed in advance, so that progress can be reported and the outcome can be reviewed later in the red team report. Confirm with the control team that each flag can be tested safely in production without causing harm beyond what the scenario allows.
Expected attack paths with prerequisites and leg-ups
Each scenario sets out the attack paths the testers expect to follow, the prerequisites each path depends on, and the leg-ups that would be provided if the testers get stuck, together with the deadline for each leg-up. Leg-ups are how the test keeps moving without waiting for real weaknesses to appear, so the control team needs to know what it will hand over and when. Check that the paths are plausible given the entity's current environment and that leg-up deadlines are realistic for the control team to meet.
In, through and out scheduling
The plan splits each scenario into at least three phases: getting into the systems, moving through them to act on objectives, and extracting evidence or leaving the environment. Scheduling each phase separately lets the control team plan monitoring, staffing and risk controls for each stage and makes it clear when the testers are expected to be active. Review whether the schedule gives enough time for the in phase to succeed and whether the out phase has defined end conditions, so the test does not drift into an open-ended intrusion.
How the plan moves from draft to approved and changed
The red team testers write the red team test plan from the targeted threat intelligence report, which is its basis. They then present the draft at a plan meeting, where the control team and test manager can question the scenarios, attack paths and planned leg-ups. The control team and test manager approve the final plan, and the same two roles approve any later change. Nothing in the plan should move into live testing on the testers' own authority, so the reader should confirm before the meeting that the agreed roles, sign-off method and meeting record are written into the initiation and scoping documentation.
Change control matters because a plan that drifts from its approved version makes the test hard to judge afterwards. A new target, a changed allowed technique or a shifted time window can alter what the blue team was supposed to detect and what the report can fairly conclude. Each decision, whether it adds a technique, moves a deadline, changes a communication channel or adjusts a forbidden action, should be recorded with its reason and the approver's name and date. Ask the testers how they will log proposed changes, how quickly the control team responds, and how the authority's test manager is kept informed of each approved version.
Once the plan is final, the control team has its own work to do. It updates the risk management controls that govern the test, so that the people who can stop or suspend activity know what they are watching for. It also prepares the specific leg-ups in advance so they can be provided without raising alarms or causing delay. Plan owners should check that every planned leg-up has a named provider inside the control team, a delivery method that does not depend on the blue team noticing it, and a fallback if the scenario changes after approval. Illustratively, a leg-up that needs a credential issued on a Friday evening should be planned against the same change control as any other change.
How the red team builds the test plan step by step
The sequence turns the targeted threat intelligence report into a plan that the control team and test manager can approve, with each scenario, technique limit, schedule and risk control written down before any live testing begins.
Receive and review the targeted threat intelligence report
The red team testers receive the targeted threat intelligence report from the threat intelligence provider and read it against the scenarios it selects. They confirm which simulated threat actors, target functions and supporting systems the report describes and note any unclear points to resolve with the provider before drafting. The step closes when the testers have a written list of questions and assumptions that the plan will be built on.
Detail each scenario and attack path
For each scenario, the testers describe the simulated threat actor, its intent and goals, the target functions and supporting systems, and the confidentiality, integrity, availability and authenticity aspects under test. They then map each expected attack path with its prerequisites, the possible leg-ups and the deadline for each leg-up. The step is complete when every scenario has a documented flag set and an attack path that the control team can follow and prepare for.
Define allowed and forbidden techniques
The testers list the techniques they intend to use and the techniques they will not use, including ethical limits for social engineering and rules for protecting privacy. Where a scenario involves physical access, such as breaching physical security to reach the network or planting a device, the plan records the safeguards that apply, including the entity's formal consent and the legal boundaries that will not be crossed. The output is a technique register that the control team can check line by line.
Set communication channels and progress reporting
The plan sets out the communication channels between the testers, the control team and the test manager, along with the procedures and frequency for progress reporting. It also records how urgent issues, such as unexpected detection or a risk to live services, are escalated. The step is done when the channels, contacts and reporting cadence are written into the plan and each party has confirmed it can use them.
Schedule the in, through and out phases
For each scenario, the testers schedule red teaming activity in at least three phases: entering the systems, moving through them and acting on objectives, and then extracting. The schedule shows how each phase depends on the leg-ups and how the control team will know when a phase starts and ends. The output is a per-scenario timetable that the control team can use to plan its own preparation.
Record risk management measures
The testers document their own risk management measures, such as safeguards against damage to live systems, stop conditions and how testing would be suspended. The control team then updates its risk management controls to match the plan and prepares the specific leg-ups so they can be provided without raising alarms or causing delay. The step closes when both sets of controls are written down and cross-checked against the scenarios and schedule.
Hold the plan meeting
The testers present the draft red team test plan at a plan meeting attended by the control team and test manager. The group walks through each scenario, technique limit, schedule and risk measure, and records every requested change and open question. The step is complete when the meeting minutes list the agreed changes and the outstanding items with an owner for each.
Obtain approval of the final plan
The testers revise the draft to reflect the meeting outcomes and submit the final plan for approval by the control team and test manager. Once approved, the control team completes its preparation of leg-ups and controls. Any later change to the plan must go through the same approval step, so the approved version is the single reference for active testing. The output is a signed-off plan version with its approval record.
Where ethical limits and physical intrusion need extra safeguards
Social engineering tests use phishing, phone pretexting and similar methods to see whether staff can be manipulated into giving up access or information. The TIBER-EU framework requires the red team test plan to set ethical limits for these techniques, so the plan must state which pretexts are allowed, which are forbidden and how staff distress is handled. Without those limits, a test can cause real harm to individuals without adding useful intelligence.
- Named forbidden pretexts: List themes the testers may not use, such as bereavement, health, financial hardship or threats against a person.
- Target selection rules: Record whether junior staff, customer-facing roles or individuals outside the target functions may be contacted.
- Stop conditions: Define when a test stops, for example if a staff member reports distress or a message reaches a person outside the agreed population.
- Escalation path: Name the control team contact who receives reports during the test and how quickly they must respond.
- Disclosure approach: Agree how and when staff are debriefed after a test without exposing individuals.
The control team should ask: which pretexts are forbidden by name, and who can halt a social engineering action within minutes if it goes wrong?
Red teams often reach personal data while moving through systems, such as customer records, employee files or mailbox contents. The plan must protect privacy, which means deciding in advance what the testers may view, copy or retain, and how any personal data encountered is handled. Where the tested entity processes personal data under the GDPR, the control team should confirm the approach with its data protection officer before approval.
- Data access limits: Specify that testers prove access with minimal data, such as a file listing or a single non-sensitive record, rather than bulk extraction.
- Retention and destruction: State where evidence is stored, who holds it, how long it is kept and how it is destroyed at closure.
- Extraction controls: Forbid exfiltration of real personal data unless the plan defines a substitute, such as a marked test file, that proves the path without exposing the data.
- Logging of access: Require that every access to personal data is logged and reviewable by the control team.
- Data protection review: Record whether the data protection officer has reviewed the scenarios that touch personal data.
The control team should ask: what personal data could the testers reach on each attack path, and what proof of access will they bring back instead of the data itself?
The framework allows physical intrusion to reach the network or plant a device, but only with appropriate safeguards, including the entity's formal consent and no crossing of legal boundaries. Physical tests carry risks to people, property and the premises owner, and they often involve third-party landlords, guards or building operators who have not agreed to the test. The plan must make these safeguards explicit before any physical action is approved.
- Written consent: Record the formal consent of the entity, signed by an authorized person, covering each site and each physical action in scope.
- Site and third-party inventory: List every premises, landlord and contractor involved, and confirm which ones have agreed to the test.
- Device controls: Describe any planted device, its power source, network connection, how it is labelled and how it is removed at the end of testing.
- Safety and emergency rules: Forbid actions that could endanger people, and define how testers stop if they meet security staff, police or emergency services.
- Cover and notification: Agree what the testers carry to show authorization and who the control team contacts if a site is challenged.
The control team should ask: which third parties would be surprised by this test, and what does a tester do in the first minute if challenged by a guard?
Some attack paths may touch systems, data or people the tested entity does not own or control, such as cloud providers, outsourced service providers, customers or networks of other organizations. Testing these without authorization can breach contracts and laws in more than one jurisdiction. The plan should identify these boundaries early, because the procurement and scoping steps may need changes before the test can proceed.
- Out-of-scope assets: List systems, domains and IP ranges that belong to third parties and must not be touched, including shared infrastructure.
- Provider permissions: Confirm whether each outsourced provider has consented to the testing of services it runs for the entity.
- Jurisdiction review: Record which legal jurisdictions the test touches, including where systems and staff are located, and whether counsel has reviewed them.
- Boundary stop rule: Require testers to stop and report to the control team if an attack path leads outside the agreed boundary.
- Fallback paths: Define the alternative leg-up or path the testers may use instead when a boundary blocks the planned route.
The control team should ask: which attack paths lead to infrastructure or data that someone other than the entity controls, and who has signed off on testing it? This is planning guidance, not legal advice. Confirm the legal position with qualified counsel in each relevant jurisdiction and with the national TIBER Cyber Team.
How supervisors and assessors test the red team test plan
This table sets out what the TIBER Cyber Team and test manager look for in the red team test plan, what evidence they ask for, and where plans usually fall short. Read each row as a question the plan must answer before the control team and test manager give approval.
| Test approach | Evidence requested | Common findings |
|---|---|---|
| Completeness per scenario | Each scenario's simulated threat actor, intent and goals, target functions and supporting systems, targeted confidentiality, integrity, availability and authenticity aspects, and flags | Scenarios that name a threat actor but omit flags, or that list target systems without the functions they support |
| Traceability from threat intelligence to attack paths | A clear link from each scenario in the targeted threat intelligence report to its expected attack paths, prerequisites and possible leg-ups | Attack paths that cannot be traced to any intelligence finding, or intelligence scenarios with no matching attack path |
| Clarity of forbidden techniques | A written list of allowed and forbidden techniques, including ethical limits for social engineering and rules for protecting privacy | Vague wording such as 'reasonable methods', or no stated limits on social engineering or physical access |
| Schedule coverage of in, through and out phases | A schedule for each scenario that separates entering the systems, moving through them and acting on objectives, and extracting | Schedules that show only overall testing windows, or that skip the out phase and extraction |
| Approval record | Evidence of the plan meeting, the red team's presentation of the plan, and the control team and test manager's approval of the final version | No dated record of approval, or a plan the control team has not seen in its final form |
| Handling of plan changes | A recorded change process showing who proposes a change, who approves it, and how the control team updates its risk management controls and leg-ups afterwards | Changes agreed informally during testing, with no updated plan or no matching update to leg-ups and risk controls |
| Communication and reporting | Documented channels, progress reporting procedures and frequency, and the testers' risk management measures | Reporting frequency left undefined, or no named escalation route for risks to live production systems |
Which evidence shows a plan that passes review
A red team test plan is only as credible as the records behind it. The cards below cover the documents an assessor or the TIBER Cyber Team will ask to see, from the approved plan through to the progress schedule that runs until active testing ends. Each record should be kept current between tests, not rebuilt before the next one.
Approved plan version and change log
Keep one approved version of the red team test plan, with a dated change log showing every amendment, who requested it, and who approved it. The control team and test manager approve the final plan and any later changes, so each version should name both approvers. Check that the scenario descriptions, flags and expected attack paths in the current version match what the red team is actually executing.
Plan meeting minutes
The red team presents the draft plan at a plan meeting. Minutes should record the questions raised, the changes agreed, the owners of each action, and any ethical limits set for social engineering or privacy. Minutes are the link between the draft and the approved version, so an assessor can see why a technique was allowed or excluded.
Control team and test manager approvals
Retain signed or otherwise attributable approval records from the control team and the test manager for the final plan and for each later change. Confirm that approvals are recorded before any changed technique or scheduling window is used in live testing. Missing or undated approvals are a common reason a plan cannot be shown to have been governed.
Leg-up preparation records with deadlines
Record each planned leg-up with its prerequisite, the deadline agreed in the plan, the staff who prepared it, and the date it was delivered or left unused. The control team prepares leg-ups so they can be provided without raising alarms or causing delay, so the records should show that preparation happened before the testing window opened.
Risk controls updated after approval
Once the plan is final, the control team updates its risk management controls. Keep a dated record of what changed, such as suspension criteria, escalation contacts, monitoring exceptions and the restoration procedure. Check that these controls reflect the approved attack paths, including any physical access elements that required formal consent.
Progress reporting schedule
Keep the agreed communication channels, reporting frequency and named recipients in a single schedule, with each progress report filed against it. Confirm that the schedule was followed, and record any gaps and their cause. Between tests, review the schedule against the current staff and contact list so the reporting chain still works when the next plan is written.
What writing and approving the test plan costs in money and effort
This table compares the cost components of drafting, approving and revising the red team test plan, showing who carries each cost and whether it is one-time or recurring. Read it as a checklist for the quote: each row names a component to ask the provider to price separately, along with the factor that moves its size. No figures are given here, so confirm amounts against your own written scope.
| Cost component | One-time or recurring | What drives it | How to keep it down |
|---|---|---|---|
| Red team testers' time to draft and present the plan | One-time, per plan version | Number of scenarios, depth of attack path detail, and how much targeted threat intelligence the testers must translate into paths | Agree the scenario count and path depth in the scope before drafting; reuse the approved threat intelligence report as the single basis |
| Control team and test manager review time | One-time for approval, then recurring for each change | Number of review rounds, how many internal functions must sign off, and clarity of the draft's communication and reporting sections | Name approvers and a review calendar at initiation; ask testers for a structured draft that follows the plan's required sections |
| Legal and ethics review of social engineering and physical scenarios | One-time per scenario type, plus recurring if scenarios change | Whether scenarios include social engineering, physical access or device planting, and the consent and legal boundaries that must be documented | Decide early whether physical or social scenarios are in scope; document formal consent and legal limits once, in reusable form |
| Leg-up preparation by the control team | One-time per approved plan, recurring for later leg-ups | Number of expected attack paths with leg-ups, the deadlines set for each, and how much access or information must be prepared without raising alarms | Limit leg-ups to those the plan genuinely needs; prepare them in a standard format and test their delivery path before testing starts |
| Plan revision after changes | Recurring, whenever scope, systems or scenarios change | Changes to production systems, staff, threat intelligence or risk controls during preparation or testing, and how many versions the approvers must review | Freeze the scope before drafting; record changes in a single change log so only affected sections are revised and re-approved |
| Testers' time for plan meeting and follow-up questions | One-time, with some recurring follow-up | Number of attendees, how many open questions remain after the meeting, and whether the testers must rework sections | Circulate the draft before the meeting and collect questions in writing; agree decisions in the meeting record |
| Internal staff time for risk management and communication setup | One-time to set up, recurring to maintain | Number of communication channels, progress reporting frequency, and how many internal staff must be briefed on the risk controls | Keep channels and reporting frequency to the minimum the plan requires; confirm who is on call during each phase |
Who writes, approves and supports the plan
The tested entity's control team is the group that approves the final plan and any later changes, so it sits at the center of the plan's governance. The control team knows the live environment, the critical or important functions in scope and the people who must stay unaware of the exercise. Alongside it, the risk owner accepts the testers' risk management measures and the residual risk of live testing against production systems, and legal counsel confirms that the permitted techniques, especially any physical or social engineering, stay within the entity's contracts, employment rules and local law. The blue team is kept separate so that it can detect the activity without seeing the plan.
- Control team approval: Confirms the final plan and approves each later change to scenarios, leg-ups or schedule.
- Risk owner sign-off: Accepts the testers' risk controls and the operational impact of testing on production services.
- Legal review: Checks consent, data protection, privacy limits and any physical access or device placement.
- Leg-up preparation: The control team prepares the specific leg-ups and updates its own risk controls once the plan is final, so they arrive without raising alarms.
- Blue team separation: Keeps the detecting staff unaware of the plan details.
Ask who in your organization holds each of these roles in writing before the plan meeting, and confirm that the control team has the authority to stop testing.
The red team testers are the procured providers who write the red team test plan. They use the targeted threat intelligence report as the basis for each scenario, then describe the simulated threat actor, its goals, the target functions, the flags and each expected attack path with its prerequisites and leg-ups. They present the draft at a plan meeting, where the control team and test manager can challenge assumptions before anything is approved. The testers also set out the communication channels, reporting frequency, allowed and forbidden techniques and their own risk management measures.
- Plan authorship: Writes the scenario detail, attack paths and the in, through and out schedule for each scenario.
- Technique boundaries: Proposes allowed and forbidden techniques, including ethical limits on social engineering and privacy protection.
- Plan meeting: Presents the draft and records changes requested by the control team and test manager.
- Reporting cadence: Defines how progress is communicated and how often.
- Own risk measures: Describes how the testers avoid harm to production systems during active testing.
Confirm in the procurement contract that the testers' plan is a deliverable, that they cannot start active testing before approval, and who holds the testers' risk management records.
An implementation partner such as DeployOpen can help the entity prepare the environment that the plan depends on. Typical work includes preparing logging and monitoring so that every action of the testers can be traced, building the infrastructure needed for leg-ups, and assembling evidence folders that the control team and test manager can use during testing and closure. The partner works inside the entity's own infrastructure and does not write the threat scenarios, approve the plan, or decide which techniques are allowed. Those decisions stay with the entity, the authority and the testers.
- Logging readiness: Helps make sure system logs needed to reconstruct the red team's actions are complete and retained.
- Leg-up readiness: Prepares the technical means by which the control team can supply leg-ups without delay.
- Evidence folders: Organizes the records the control team needs to show decisions, approvals and changes.
- Documentation support: Assists with runbooks for suspension and restoration of affected systems.
- No approval authority: Has no role in approving the plan or in any authority decision.
Ask the partner to state in its written scope which items it prepares and which it does not touch, and confirm that the entity retains control of every credential and system access granted.
The TIBER Cyber Team and test manager at the authority supervise the test, review the plan and approve it with the control team. The authority's role is supervision, not design. An independent assessor or certification body, where one is engaged for an attestation or report, tests the process independently. DeployOpen does not issue audit reports, attestations or certifications, and it does not act as the assessor for any TIBER-EU test. Independence ends at the point where a supporting provider starts to shape the evidence it is later asked to judge.
- Authority approval: The TIBER Cyber Team reviews the plan and the test manager oversees its execution.
- Independent assessment: Assessors test whether the process was followed, and issue any report or attestation themselves.
- Outsourcing boundary: Providers may prepare materials, but a supporting firm should not later assess its own work.
- Conflict check: Confirm that the assessor has no role in building the systems or the evidence it reviews.
- Documented decisions: Keep the approval record that the authority and assessor will examine.
Confirm with the authority which evidence it expects to see, and with the assessor whether any prior work on your systems creates a conflict of interest.
Questions buyers ask about the TIBER-EU red team test plan
How long does it take to write a TIBER-EU red team test plan?
The framework does not set a fixed duration for drafting the plan, so the length depends on how much the targeted threat intelligence report leaves open. The main drivers are the number of scenarios selected, the complexity of the target functions and supporting systems, and how many expected attack paths each scenario needs, with prerequisites, possible leg-ups and deadlines for each. The number of rounds at the plan meeting also matters. A clear, approved threat intelligence report shortens drafting. Ask the red team testers for a written schedule that covers drafting, the plan meeting and final approval, and confirm it fits the timelines your authority has set for the preparation and testing phases.
Can our own team write the red team test plan in-house?
Under TIBER-EU, the red team testers write the plan, using the targeted threat intelligence report as its basis. Your team's role is to supply inputs and to review the result through the control team. Internal work that helps includes mapping critical systems, data sensitivity, change freeze windows, business constraints and the people who must be reachable during testing. Your authority and procurement rules determine who may act as the red team provider, so confirm roles before work starts. DeployOpen can prepare your systems, logging, risk management controls and leg-up readiness, and documents them for the control team. DeployOpen does not replace the testers' authorship of the plan unless your written scope and procurement say otherwise.
Who must approve the red team test plan and any later changes?
The control team and the test manager approve the final red team test plan and any later changes. The testers present the draft at a plan meeting, where the scenarios, attack paths, allowed and forbidden techniques, leg-ups and schedule are reviewed before sign-off. The control team is staffed by people at the tested entity who run the test from inside the organization, and the test manager sits with the authority's TIBER Cyber Team. Your own governance may also require executive or risk committee sign-off on the outcome, so confirm that internal step early. Record approvals in writing so the final plan is clearly the version the testers execute.
How are changes to the red team test plan handled after approval?
Changes to an approved plan go back to the control team and test manager for approval. Common triggers include a newly discovered attack path, a change to a supporting system, a leg-up that needs new timing, or a safety concern raised during testing. Once the plan is final, the control team updates its risk management controls and prepares the specific leg-ups so they can be provided without raising alarms or causing delay. Ask the testers how they will request changes, how the communication channels and progress reports will record them, and how the change history will be kept for the closure phase. A documented change log makes the final test summary and remediation plan easier to write.
Does a TIBER-EU red team test plan have to include social engineering?
The plan must state allowed and forbidden techniques, and it must set ethical limits for social engineering and protection of privacy. Whether social engineering appears as an active technique depends on the scenarios chosen and the threat actor profile in the threat intelligence report. If social engineering is in scope, the plan needs clear limits on what the testers may do, how staff are protected from harm and how personal data is handled. If it is excluded, the plan should say so and list it as a forbidden technique. Physical security breaches, such as reaching the network or planting a device, are allowed only with safeguards such as formal consent from the entity and no crossing of legal boundaries. Confirm these limits with your legal and HR teams before the plan meeting.
What does DeployOpen do and what do the red team testers own?
The red team testers own the attack scenarios, attack paths, technique selection, execution and the red team test report under their contract. The threat intelligence provider owns the targeted threat intelligence report that the plan is built from. DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside your own infrastructure, and it prepares systems, controls and evidence for compliance assessments. DeployOpen does not issue reports, attestations or certificates, and those come from independent bodies. DeployOpen also runs security testing services, but whether it can act as a red team provider under TIBER-EU depends on your authority's procurement and independence rules, so confirm that in writing before engagement.
What must the red team test plan say about communication and progress reporting?
The plan must set out the communication channels, the procedures for progress reporting and how often reports are issued. These details decide how quickly the control team learns about detections, leg-up requests and safety issues during active testing. Ask the testers to name the contacts on each side, the escalation path for urgent events, and the secure channels used for sensitive material. Agree the reporting frequency at the plan meeting and write it into the approved plan, so both teams work from the same rules. Clear channels also reduce the chance that staff detection of the testers is handled inconsistently across teams.
Where test plans usually fall short and how to close the gap
A red team test plan is the document the control team and test manager approve before any live testing starts, so gaps in it become gaps in the test itself. The six patterns below appear often enough to check for early. Each one comes with a concrete fix that the control team and test manager can require before approving the plan.
Attack paths without prerequisites
Many plans list an expected attack path as a sequence of techniques but never state what must already be true for each step to work, such as a valid account, a reachable subnet or a specific software version. Without prerequisites, the control team cannot tell whether a stalled path reflects the testers' skill, a missing condition or a defense that worked. For each path, require the plan to list its prerequisites, the evidence the testers expect to see at each stage, and the leg-up that applies if a prerequisite is absent.
Missing leg-up deadlines
A leg-up is information or access the control team provides to keep a scenario moving, and the plan should state when each one may be requested. Plans that name leg-ups but omit deadlines leave the control team to decide ad hoc whether a request is overdue, which invites delay and inconsistent handling. Ask for a deadline per leg-up, tied to the attack path it supports, and confirm with the control team how it will be delivered without raising alarms.
Forbidden techniques left generic
Entries such as "no destructive activity" or "respect privacy" sound controlled but give the testers and the control team nothing to check against during testing. The plan should name the forbidden techniques concretely, set the ethical limits for social engineering, and state how personal data encountered during testing will be protected. A useful check is whether a tester could read the list and know, for a specific action, whether it is permitted.
Out phase not scheduled
Plans often schedule the in and through phases of each scenario in detail, then treat the out phase, where testers act on objectives and extract, as a single line or omit it. The framework requires scheduling at least across the in, through and out phases for each scenario. Ask that every scenario carry dates or windows for all three phases, so that the control team can plan monitoring and staff can recognize the activity that matters most.
Approval recorded only in email
When the control team and test manager agree a plan by email, the approved version and any later change can become hard to locate, and reviewers may not agree on which text was approved. The plan requires the control team and test manager to approve the final plan and any later changes, so the approval record should be a version-controlled document with a dated sign-off. Confirm with the provider how changes are numbered and stored before the plan meeting.
Risk controls not updated after approval
Once the plan is final, the control team must update its risk management controls and prepare the leg-ups. Teams often skip this step because the plan looks finished, which leaves monitoring rules, escalation contacts and suspension criteria written for an earlier version of the scenarios. Close the gap by making a dated update of the risk controls and leg-up preparation a named item that the test manager checks before testing begins.
How DeployOpen supports the red team test plan process
DeployOpen works for the entity under a written scope agreed before any work starts. Within that scope, DeployOpen plans and prepares the systems, logging, leg-up readiness and evidence that the control team and test manager need to approve the red team test plan and to run the risk controls it describes. In practice this means reviewing the attack paths and flags in the plan against the environment, confirming that the in, through and out phases can be recorded in logs that the control team can read, and preparing the specific leg-ups so they can be delivered without raising alarms or causing delay. Where the entity engages DeployOpen for security testing, the same written scope can cover the testing activities that the plan permits. Before signing, ask which plan components, logging sources and leg-up types are in scope, and who owns each one on the entity side.
DeployOpen does not issue TIBER-EU attestations, approve red team test plans or change approval records, and it does not act as the threat intelligence provider or the red team tester unless it is separately contracted for those roles through the procurement process the authority requires. The entity, its control team and the test manager keep ownership of the plan, the risk management controls and the approval decisions. Independent assessment and attestation remain the responsibility of the authority and the bodies it designates. Before engaging any partner, confirm in writing which roles it holds, which it does not hold, and how a conflict between a preparation role and a testing role would be handled. The authority's own implementation document is the place to confirm the rules that apply in your jurisdiction.
