How long does a TIBER-EU test take, and who does what at each step?
If your authority has sent a written notification, or DORA threat-led penetration testing now applies to you, expect three mandatory phases running from that notification to the authority's signed attestation. The framework's durations give a preparation phase of up to six months, a testing phase of about 18 to 21 weeks (4 to 6 weeks of threat intelligence and scenario selection, 2 to 3 weeks of red team test planning, and at least 12 weeks of active testing), and a closure phase that the framework says may take longer than 18 weeks. Added together, these figures make a test of well over a year is possible, though the actual calendar depends on your authority, the agreed scope and how quickly your own people and procurement move. The framework's limits are deadlines, not targets. Initiation documents are due within three months of notification, and the scope specification document, approved by your management body, and completed procurement within six months. Procurement is the step most often on the critical path, because the threat intelligence provider and red team testers must be selected and contracted before testing starts. Ask your test manager early which sign-offs they expect, who in your organization can approve the scope, and how many weeks your procurement function needs for a contract of this kind. Your control team lead should also block time for weekly progress meetings during active testing. Roles stay fixed throughout. Your authority, through its TIBER Cyber Team and test manager, runs the process and approves the key deliverables, and only the authority's signed attestation concludes the test. Your organization owns the control team, the blue team and the remediation plan. Providers carry out threat intelligence and red teaming. DeployOpen can help prepare your systems, evidence and documentation for each step, but it does not issue reports, attestations or certificates.
Who takes part in a TIBER-EU test and what each party owns
The TIBER authority, through its TIBER Cyber Team and a designated test manager, runs the framework at national or European level. The authority issues the written notification that starts the test, supervises the process and decides whether the test meets the framework's requirements. The test manager is the day-to-day point of supervision for the entity and the providers.
- Notification and oversight: The authority opens the test with a written notification and keeps the process within the framework's timelines.
- Approvals: The test manager approves the initiation documents, scope specification, targeted threat intelligence report, red team test plan, test summary report and remediation plan.
- Attestation: The authority's signed attestation concludes the test. It confirms the process was completed, not that the entity passed.
- Limits: The authority does not own the entity's controls, does not fix findings and does not certify security.
Before committing resources, confirm which authority and TIBER Cyber Team will supervise your test and what fees, if any, that authority charges.
The control team is the small group inside the tested entity that knows about the test and manages it from start to finish. It is the entity's counterpart to the test manager. Its members are the only staff aware of the test, and they work on a strict need-to-know basis. The control team can also halt the test at any time if there is a risk of damage.
- Coordination: The control team sets up risk management for the test, schedules work and keeps the authority and providers informed.
- Approvals and sign-off: It prepares the initiation documents and scope inputs that go to the management body and the test manager.
- Information control: It protects the code name used for the entity and limits who receives test details.
- Halt authority: It can stop active testing if the test threatens live systems or operations.
- Ownership: The entity keeps responsibility for its controls, evidence and remediation after the test.
Check that the control team members have clear mandates, deputies for absences and a documented halt procedure before the notification arrives.
The blue team is everyone at the entity and relevant providers who is not in the control team and is not aware of the test. Its members defend the systems exactly as they would during a real attack, so their detection and response are what the test measures. Keeping them unaware is the core rule that makes the results meaningful.
- Normal operations: Blue team staff detect, triage and respond to activity using their usual tools and procedures.
- Unawareness: Staff must not be told about the test, the red team activity or the flags until the closure phase.
- Reporting: The blue team contributes to the blue team test report, which covers what was detected, what was missed and how response performed.
- Replay and purple teaming: After closure begins, selected staff take part in replay and purple teaming exercises.
- Provider staff: Relevant external providers may also form part of the blue team and must respect the same secrecy.
Identify which teams, shifts and providers would detect activity, and confirm that the control team can keep them unaware while still protecting live services.
The external threat intelligence provider gathers information on threat actors that could realistically target the entity. The provider turns that work into the targeted threat intelligence report, which shapes the scenarios the red team will use. The provider does not attack the entity itself.
- Threat research: The provider analyses threat actors, their methods and the entity's exposure to them.
- Scenario creation: It proposes scenarios and attack paths that inform the red team test plan.
- Deliverable: It produces the targeted threat intelligence report, which the test manager approves.
- Procurement: The entity procures the provider during the preparation phase, under the framework's requirements for service provider selection.
- Confidentiality: The provider works under the code name and handles sensitive information under contract.
Ask prospective providers to show how their reports map to scenarios and how they handle independence and conflicts of interest.
The red team testers carry out the active attack simulation against the flags agreed in the scope. They work under the control team and test manager's supervision and must hold the skills and independence the framework requires. Their work produces the red team test report, which describes the attack paths they used and what they achieved.
- Test plan: Testers write the red team test plan, which the test manager approves before active testing starts.
- Active testing: The framework requires at least 12 weeks of active red team testing, with at least weekly progress meetings.
- Reporting: Testers deliver the red team test report within four weeks of the end of active testing.
- Boundaries: Testers work within the agreed scope and may be stopped by the control team at any time.
- Procurement: The entity procures red team testers during preparation, and the testers must be independent of the entity's regular testing and advisory work where the framework requires it.
Confirm your provider's team composition, experience and conflict rules in writing before the scope is finalised.
What happens in the preparation phase
The preparation phase turns the authority's written notification into an agreed test footing: a control team that runs the test on the entity's side, initiation documents, a scope approved by the management body, and procured providers. Each step produces a document or approval that the next step depends on.
Receive the written notification from the authority
The TIBER authority notifies the entity in writing that a TIBER-EU test will take place. This notification starts the clock for the whole test, and the preparation phase, which lasts up to six months, runs from this point. The entity's management body should log the date, confirm who receives the notification internally, and check the authority's contact details for the TIBER Cyber Team and the test manager. The step is complete when the entity has acknowledged receipt and named its first point of contact for the test manager.
Set up the control team and assign a code name
The entity appoints its control team, the small group that knows the test is taking place and supervises it on the entity's behalf. Awareness stays limited to this group on a need-to-know basis. The control team also agrees a code name that all parties use for the entity, so that the threat intelligence provider, the red team testers and the authority can refer to the entity without exposing its identity. The control team can halt the test at any time if there is a risk of damage. The step is complete when the membership, decision rights and code name are recorded and the test manager has confirmed them.
Draft the initiation documents
The entity, through the control team, prepares the initiation documents. These set out the test's governance, roles, contacts and the entity's understanding of the test process, and they are the first formal deliverable the test manager reviews. The framework requires these documents to be completed within three months of the notification. The control team should confirm which internal and external parties will be in the blue team, since they will not be told about the test. The step is complete when the test manager approves the initiation documents.
Identify critical functions and flags for scoping
The entity identifies the critical or important functions that the test should cover and the flags, which are the target assets or objectives the red team will try to reach. This work feeds the scope specification document. The control team should gather the systems, data, people and third-party services that support each function, and note any dependencies on suppliers whose systems would be part of the test. The step is complete when the control team has a candidate list of functions and flags ready for the scope discussion with the test manager.
Agree the scope specification document
The control team and the test manager agree the scope specification document, which records the functions, flags, systems, boundaries and rules of engagement for the test. The management body must approve this document. Approval by the management body makes the scope a board-level decision and gives the control team a clear mandate. The framework requires the scope specification document to be approved within six months of the notification, together with the completed initiation documents and procurement. The step is complete when the management body has signed off on the scope and the test manager has confirmed it.
Procure the threat intelligence provider and red team testers
The entity selects and contracts an external threat intelligence provider and the red team testers, following the authority's rules on provider selection and independence. The test manager reviews the procurement choices. Procurement covers the provider's team, experience, insurance and conflict checks, as well as contract terms for confidentiality and the code name. The step is complete when both providers are contracted and the test manager has accepted them. The framework requires procurement to be completed within six months of the notification.
Confirm the preparation phase is closed
Before the testing phase begins, the control team and test manager check that all preparation outputs are in place: notification acknowledged, control team and code name recorded, initiation documents approved, scope approved by the management body and providers procured. The test manager's confirmation marks the transition to the testing phase. The entity should keep this record as evidence of how it met the preparation requirements. The step is complete when the test manager has confirmed in writing that the preparation phase is closed.
Which deliverables are due in closure, and when
The closure phase turns testing results into a documented improvement plan and a signed conclusion. Each deliverable depends on the one before it, so a late red team report pushes back the rest. The cards below list each item in order, with its deadline and the ECB guidance document that describes it.
Red team test report
The red team testers document what they attempted, what worked, and how far they got against each flag. It is due within four weeks of the end of active testing. Check that the report covers the full scenario set from the red team test plan and that the control team reviews it before the blue team starts its own analysis. The ECB publishes a guidance document for this deliverable.
Blue team test report
The blue team report describes what the entity's defenders saw, detected, escalated and missed during the active test. It is written by the blue team, not the control team, and it is due with the replay and purple teaming outputs. Check that detection timelines and response decisions are recorded accurately, since they drive the purple teaming discussion. The ECB publishes a guidance document for this deliverable.
Replay and purple teaming
Replay walks the blue team through the red team's actions step by step, and purple teaming turns the gaps into joint tests of detection and response. The framework makes purple teaming mandatory in the 2025 update. Confirm with the test manager which attack paths will be replayed and who holds the purple teaming sessions, since both must finish within the same ten-week window.
360 degree feedback
The 360 degree feedback step collects views from the control team, blue team, management and other relevant staff on how the test ran and what it revealed. It is a structured input to the test summary report rather than a separate exam. Plan interviews and written feedback early so they do not compete with the replay schedule, and agree in advance who may comment and how responses are anonymized.
Test summary report
The test summary report is the consolidated account of the whole test, written by the tested entity with the control team and approved by the test manager. It is due within eight weeks of the test manager's assessment of the red and blue team reports. Check that it reflects strengths and weaknesses, since TIBER-EU tests produce no pass or fail result. The ECB publishes a guidance document for this deliverable.
Remediation plan and attestation
The remediation plan sets out the actions, owners and timelines the entity commits to in response to the findings, and it is due in the same eight-week window as the summary report. The test manager approves the plan, and the TIBER authority's signed attestation then concludes the test. Ask the authority which remediation evidence it expects to see, and confirm who signs for the entity.
What stretches or shortens a TIBER-EU test
The schedule of a TIBER-EU test is set by the framework's durations, but several factors decide whether an entity lands near the start or the end of each window. The largest is the time the authority takes to review what the entity submits. The framework sets deadlines for the entity's own deliverables, such as initiation documents within three months of notification and the scope specification document and completed procurement within six months, but the authority's review and approval of key deliverables, including the scope and the red team test plan, sit outside the entity's control. Confirm with the TIBER authority how many working days it takes to return comments, whether it reviews drafts before formal submission, and who must sign off at the management body level, because an approval that waits for a board meeting can consume weeks of the preparation phase.
Procurement is the second driver. The preparation phase must finish, including the completed procurement of the threat intelligence provider and red team testers, within six months of notification, and the threat intelligence and scenario work that follows is planned against the provider's start date. Entities that have already run a provider selection, with agreed rates, conflict checks and contract terms, typically face fewer delays than those that start the search after notification. Scope drives the other end of the timeline. A larger number of flags, critical or important functions with many dependent systems, and third-party systems in scope all lengthen the scope specification, the threat intelligence work and the time testers need on active testing. Ask the authority early whether the planned flags are proportionate and whether any provider-hosted systems will need separate agreements before the scope is approved.
Closure is where the schedule is most often lost. The red team report is due within four weeks of the end of active testing, and the blue team report, replay and purple teaming must be completed within 10 weeks, so weak blue team reports push the test summary report and remediation plan later. The framework allows the closure phase to run longer than 18 weeks, so plan for that possibility rather than the minimum. Entities can shorten the closure by assigning the blue team and control team clear evidence owners during testing, keeping detection and response logs complete, and agreeing the remediation planning approach before the final report arrives. Ask the authority how it handles remediation plans that depend on a supplier fix, and whether the eight-week window for the test summary report and remediation plan can be extended if a risk-based plan needs board approval.
What the entity must have in place before notification
The authority's written notification starts a clock: initiation documents are due within three months and the scope specification, approved by the management body, plus completed procurement within six months. The cards below are the items that have to exist before that clock starts, so the entity can move through the preparation phase without delay.
Board sponsorship for the test
The scope specification document must be approved by the management body, so the board has to back the test before the work begins. Confirm that a named board member or executive committee has accepted the purpose, the risk of disruption to live systems and the budget for remediation. Ask whether the board minutes record that decision, since the authority will look for it during preparation.
A named control team lead
The control team is the small group that knows about the test and keeps it confidential, and it can halt the test if there is a risk of damage. The lead needs seniority to make that call and the time to run the team through preparation. Check that the lead is named in writing, that the members are on a need-to-know list and that the lead has a deputy who can act during active testing.
Backups and supplier contracts for testing
Red team testing may reach systems run by cloud, outsourcing and intra-group providers, and those providers must agree before the scope is set. Review backups for in-scope systems and confirm that restoration has been tested. Check the supplier contracts for clauses that allow security testing, define who approves it and name the notice a supplier needs before testing starts.
A procurement plan for outside providers
The threat intelligence provider and the red team testers must be procured within the six-month window, and the test manager approves the choice. Draft the procurement plan early so that tender documents, evaluation criteria and conflict checks are ready when the notification arrives. Ask the authority which provider requirements apply in your jurisdiction and whether any checks must be recorded for the test manager.
Internal capacity for the blue team
The blue team is everyone at the entity and relevant providers who is not in the control team and not aware of the test, so it covers the security operations staff who will respond to the red team. Identify who would detect and respond to activity, how their workload will be covered during active testing and how their reports will be handled. Confirm that the staff who respond are not told about the test in advance, because their response is part of what the test measures.
TIBER-EU process questions buyers ask
How long does each phase of a TIBER-EU test take?
The preparation phase lasts up to six months from the authority's written notification, and the testing phase runs about 18 to 21 weeks. The framework gives 4 to 6 weeks for threat intelligence and scenario selection, 2 to 3 weeks for the red team test plan, and at least 12 weeks of active red team testing with weekly progress meetings. The closure phase is the one the framework says may take longer than 18 weeks, because the red team report is due within four weeks of active testing ending, while the blue team report, replay and purple teaming are due within 10 weeks, and the test summary report and remediation plan within 8 weeks of the test manager's assessment. Confirm the exact dates in your own notification with your authority, since the timeline is set per test.
Can our own team run a TIBER-EU test without outside providers?
No. A TIBER-EU test needs an external threat intelligence provider and external red team testers, so procurement of both is a mandatory step in the preparation phase. Your organization owns the test in the sense that its control team, blue team and management body make the decisions the framework assigns to them, and the TIBER authority's test manager oversees the process. Internal staff can take part in the blue team and the control team, but the framework's independence rules limit what internal testers can do. Ask your authority which roles internal staff may hold before you plan staffing.
What does the work require from our team?
The work requires a named control team that knows about the test and a blue team made up of everyone else at the entity and relevant providers who is unaware of it. The control team handles notification, initiation, scoping, procurement and the replay and purple teaming exercises, and it can halt the test at any time if there is a risk of damage. Awareness is limited to the control team on a need-to-know basis, and every party uses a code name for the entity. Expect the largest demands during active testing and closure, when blue team members must respond to the red team without knowing it is a test. Confirm staffing levels and backfill plans with your board before the authority's notification arrives.
Who signs the attestation that concludes a TIBER-EU test?
The TIBER authority signs the attestation that concludes the test. The test manager approves the key deliverables, including the initiation documents, the scope, the threat intelligence report, the red team test plan, the test summary report and the remediation plan, before the authority's signed attestation closes the test. Your entity receives the attestation as the formal record that the test is complete, but it does not sign it for the authority. External providers, including the threat intelligence provider and red team testers, also do not issue the attestation. If your regulator or auditor asks for proof of completion, request the signed attestation from the authority.
Does a TIBER-EU test produce a pass or fail result?
No. TIBER-EU tests produce no pass or fail result. The framework is designed to show where an entity is strong and where it is weak, so it can raise its cyber maturity. The main outputs are the red team test report, the blue team test report, the test summary report and the remediation plan. Those documents describe what the red team achieved, how the blue team detected and responded, and what the entity will fix and when. Plan internal messaging around findings and remediation, not around a score, because no score exists.
How often does an entity repeat a TIBER-EU test?
The framework treats intervals of 3 years between tests as the norm. The framework gives this interval because of the resources and costs involved in a threat-led test. Your authority or the DORA threat-led testing rules may set a different cycle for your entity, so confirm the schedule with your authority and record it in your resilience testing plan. Between tests, the findings and remediation plan from the previous test are the main evidence of follow-up work.
What can outside help do during a TIBER-EU test, and what can it not do?
Outside help can supply the threat intelligence provider, the red team testers and, where it is permitted, support for project management and evidence preparation. It cannot take over the decisions the framework assigns to your control team and management body, and it cannot sign the attestation or replace the test manager's review. Independence and conflict rules also limit which providers may serve the entity and what they may do for it in parallel. Before you engage a provider, ask the authority how the independence rules apply to your chosen support and obtain written scope for each role.
Where outside help fits in the process
Outside help fits into the TIBER-EU process in two broad ways: an entity can buy in specialist delivery, but it cannot hand over the decisions that give the test its meaning. The scope decision, the board's approval of the scope specification document, the control team's direction of the test and the remediation of weaknesses stay with the tested entity. The entity can outsource the threat intelligence work to an external threat intelligence provider, the active attack work to red team testers, and project and evidence support to a consultant. Some entities also engage an external control team lead, who supports the entity's own control team but does not replace it.
The independence and conflict rules decide who can do what. The threat intelligence provider and the red team testers are procured under the framework and must be separate organizations from each other, so the attack team does not also shape the threat picture it is tested against. Staff who run the test on the entity's side must keep the code name and need-to-know discipline, and anyone who supports the control team must not be a blue team member who is unaware of the test. Before signing, confirm with the test manager in writing which provider roles, conflicts and information flows the authority accepts, because those rules are set by the framework and the national implementation rather than by the vendor.
The test manager and the TIBER authority keep their roles however much support the entity buys. The test manager approves the key deliverables, including the initiation documents, scope, targeted threat intelligence report, red team test plan, test summary report and remediation plan, and the authority's signed attestation concludes the test. A provider's report cannot replace these approvals or the attestation. Ask each provider to state in its contract which deliverables it drafts, which the entity must sign, and how it will support the test manager's review, so that accountability for every step remains visible.
How DeployOpen prepares systems and evidence for a TIBER-EU test
DeployOpen works on the TIBER-EU process from the entity's side: it prepares the self-hosted open-source platforms, controls and records that the control team and blue team need across preparation, testing and closure. The entity owns its test, its approvals and its attestation, while DeployOpen supplies scoped preparation work and documentation in the client's own infrastructure.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Written scope identifies which self-hosted platforms, environments and evidence sources support the critical or important functions in the test.
- Quotes follow from the written scope, so the entity can compare what is included in preparation, testing support and closure.
How we build
- Systems are planned and deployed inside the client's own cloud accounts, data centers or air-gapped networks.
- Logging, monitoring and alerting are configured so the blue team's detection and response can be recorded and reviewed later.
- Backup, access control and hardening settings are documented so the control team can show how the environment was prepared.
How we hand over
- Documentation covers architecture, configurations, runbooks and the evidence each deliverable needs, prepared for the control team.
- Evidence packs are organized to support the red team and blue team reports, the test summary report and the remediation plan.
- The entity receives the artifacts and keeps ownership of its controls, approvals and the authority's attestation process.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the test concludes.
- Remediation work on the platforms can be scoped in writing to address weaknesses identified during the test.
- Entities should confirm with their test manager which preparation tasks DeployOpen may perform and which must stay with the internal team.
