Is your organization ready for a TIBER-EU test?
There is no formal readiness checklist for a TIBER-EU test. The DNB and Deutsche Bundesbank short read on when an entity learns the most from a TIBER test says that entities below a certain cyber maturity will likely benefit more from a gradual increase in security testing first. Readiness therefore depends on the entity's maturity, its board support, whether it has already run red teaming or scenario-based testing, and whether it has enough blue and control team staff. If a supervisor, contract or customer now points toward a test, the first decision is whether the organization is ready at all, and the national TIBER Cyber Team is the body to ask when that is unclear.
The organization owns the test and every control it depends on. An implementation partner can help prepare systems, backups and evidence, but only the authority, its test manager and the threat intelligence and red team providers run the test and judge the results. Readiness is therefore about what the entity must have in place before written notification: a control team lead with authority to take full control of the process, a designated back-up, and at least one board member who supports the test. The board must also accept the limited risk of testing live production systems as risk owner and fund remediation of the findings.
Three checks are worth running early. Confirm that the in-scope systems have backup and restoration capabilities through due diligence before any testing. Review ICT service contracts with outsourced providers to see whether they allow testing on the supplier's infrastructure, and plan clauses for future contracts if they do not. Finally, start procurement and scoping planning early, since the framework strongly encourages the TIBER Cyber Team to contact the entity well before notification and asks the entity to anticipate resource and budget constraints. Each gap found now is cheaper to close than one found after the authority has issued its written notification.
Which prerequisites must be true before a test starts
The Dutch and German authorities do not publish a formal readiness checklist, but they name the conditions that make a TIBER-EU test useful rather than damaging. Each card below is one condition, with the internal check you can run now and the evidence that shows it is in place before you talk to your national TIBER Cyber Team.
Critical importance or crown jewels
A TIBER-EU test targets the functions that matter most to customers, markets or the wider financial system. Start by listing your critical or important functions and the systems that support them, then ask whether an attacker reaching them would cause harm beyond your own organization. If the answer is unclear, the scoping conversation will struggle, and the test may not justify its cost. Evidence: a current list of critical functions, mapped to the ICT systems behind each, approved by senior management.
Culture open to learning
A test only teaches you something if the blue team can fail in front of the red team without being punished. Check how your security staff respond to past incidents and audit findings: do they look for causes, or for someone to blame? Ask whether managers would accept a finding that a detection control missed an intrusion for days. Evidence: post-incident reviews that record process gaps rather than individual fault, and a documented policy on how test findings are handled.
Prior red teaming or scenario testing
The DNB and Bundesbank short read recommends traditional red teaming or scenario-based exercises before a TIBER test, and notes these can follow the TIBER-EU steps without being TIBER tests. Review what you have run in the last few years: scope, findings, and whether the remediation actually closed. If you have never run an adversary simulation, a lighter exercise first will show whether your detection and response can handle one. Evidence: prior test reports, a tracked list of their findings with closure dates, and a record of retests.
Sufficient blue and control team staff
The blue team defends the live environment during the test, and the control team runs it with a lead, subject matter experts and, usually, a C-level member. Count the people who could fill each role without pulling them from a live incident or a regulatory deadline, and confirm a designated back-up exists for the control team lead. Ask whether they have crisis management and procurement experience, since the control team lead needs both. Evidence: named role holders, a staffing plan for the test period, and written deputies.
Board member support
The board owns cyber risk, must allocate the resources a test consumes, must authorize the limited risk of testing live production systems, and must fund remediation of the findings. Confirm that at least one board member has been briefed on these four points and is willing to sign off on them in writing before notification. Without that sponsor, the control team cannot make decisions about live systems. Evidence: board minutes recording the decision, a named sponsor, and an approved budget line covering both the test and remediation.
Why the board must support the test
The board owns cybersecurity risk, so a test that probes the entity's real defences is a test of the board's risk appetite as well as of the security function. Before notification, the board should confirm which critical or important functions it accepts as in scope and understand what a finding about a weakness in those functions means for the entity's risk register. The board does not need to design the test, but it does need to know what it is accepting.
- Risk ownership: Confirm the board has formally recorded cyber risk on its agenda and in its risk register for the functions under consideration.
- Scope acceptance: Ask the board to approve the critical or important functions and flags that the scope specification document will cover.
- Risk appetite: Check whether the board has stated a tolerance for compromise of those functions and whether a test result could breach it.
- Reporting line: Agree who briefs the board during the test and how often.
- Question to ask the board: Which of our critical functions are you prepared to see attacked by a threat-led team, and what would you need to see in the results to act?
Before notification, make sure the minutes show this decision, not only the security team's view of it.
The board must allocate the resources a test consumes. A TIBER-EU test needs a control team lead with authority, subject matter experts, a designated back-up, time from the blue team, and third-party providers for threat intelligence and red teaming. The framework warns that procurement and scoping take a long time and that the entity must anticipate resource and budget constraints, so the board's approval has to come early.
- Staffing commitments: Confirm named people for the control team lead, back-up and blue team, and whether their test work displaces other duties.
- Authority for the lead: The board should delegate management of the test to the control team lead with authority to take full control of the process and direct access to senior management.
- Provider budget: Approve a budget envelope for threat intelligence and red team providers before procurement starts.
- Internal time: Agree how many hours each phase will require from control and blue team staff.
- Question to ask the board: Who will you release from current projects for the length of the test, and who has the authority to stop a test if it threatens operations?
Before notification, get written confirmation of named roles and a budget decision, since these are the first items the TIBER Cyber Team will ask about.
As risk owner, the board must authorise the limited risk of testing live production systems. A TIBER-EU test is designed to run against production, so the board accepts that testing could disrupt services, expose data or trigger real incident response. The entity should show it has checked backup and restoration for in-scope systems and has contracts that allow testing at suppliers where infrastructure is partly outsourced.
- Production authorisation: The board signs off that live systems in scope may be tested within agreed rules of engagement.
- Backup and restoration: Confirm due diligence on in-scope systems shows that backups exist and restore successfully before any testing.
- Supplier contracts: Check that ICT service contracts allow testing on the supplier's infrastructure, or that clauses are planned for future contracts.
- Stop conditions: Agree who can halt testing, under what conditions, and how the control team escalates.
- Question to ask the board: Are you prepared to accept a production outage or a data exposure during the test, and who signs that acceptance on your behalf?
Before notification, record the board's acceptance of production risk together with the restoration evidence it relies on.
The board must fund remediation of the findings. A TIBER-EU test does not produce a pass or fail result. It shows strengths and weaknesses so the entity can raise its maturity, and the findings flow into a remediation plan that the entity owns. A test that finds weaknesses but has no funded fixes gives the board a list of problems and no improvement, which is why remediation funding belongs in the approval before testing starts.
- Remediation commitment: The board agrees in principle to fund fixes for findings, including those that need new tooling or staff.
- Unknown cost: Recognise that remediation cost cannot be known before the red team report exists, so ask for a contingency mechanism.
- Ownership: Name the executive accountable for delivering the remediation plan.
- Follow-up: Agree how the board will track remediation progress after closure.
- Question to ask the board: If the test finds a serious weakness in a critical function, how quickly can we fund and deliver the fix, and who approves the spend?
Before notification, ask the board to pre-approve a remediation approach so the plan is not delayed when the findings arrive.
How to tell if prior red teaming is enough
Traditional red teaming or scenario-based testing can come before a TIBER-EU test, and the DNB and Deutsche Bundesbank short read recommends it for entities that are not yet ready. These earlier exercises can follow the TIBER-EU steps without being TIBER tests, so they do not need the authority's involvement to count as preparation. The question for the board and the control team lead is whether past exercises have shown that the blue team can detect and respond to an adversary that is not announced and is pursuing goals chosen from threat intelligence. Only the organization can make that judgment, because it owns the risk and the consequences of a live production test.
Start by reading the record of past exercises against three things. First, scope: check whether the tests reached production systems, identity infrastructure, and the critical functions that a threat-led test would target, or whether they stayed on isolated lab environments and known hosts. Second, detection outcomes: check whether the blue team noticed the activity, how long it took, whether the alerts reached people who could act, and whether anyone escalated outside the security operations function. Missed detections matter more than successful intrusions, because a threat-led test assumes that some attacks will get through and tests whether they are found. Third, remediation closure: check how many findings from earlier exercises are still open, how long they stayed open, and whether fixes were verified by retesting. A long list of open findings suggests the organization is not yet able to absorb the remediation a TIBER-EU test would produce.
An outside provider can help with this review, for example by sampling past reports, checking whether detection logs can be reconstructed, and comparing findings against your current architecture. The provider prepares the analysis, but the organization decides whether the results justify going ahead, delaying, or first running a simpler test. Confirm with your national TIBER Cyber Team whether it wants to see this material before notification, since the framework encourages early contact and the authority decides whether to accept a request.
Staffing the control team and blue team
A TIBER-EU test runs on two internal teams that the entity must staff itself: the control team, which directs the test, and the blue team, which defends against it. The cards below cover what the Control Team Guidance asks of each role and how to confirm, before notification, that every role has a named person behind it.
Keep the control team small
The Control Team Guidance asks for a control team as small as possible. Each added member adds coordination, approvals and information-handling risk, so the question is not how many people could help but which roles the test cannot run without. Ask whether each proposed member has a defined task in the preparation, testing and closure phases. Write down the roles first, then assign names to them.
Name the control team lead
The control team lead is the person the board delegates test management to, so the role must sit with someone who has authority to take full control of the testing process. Confirm that the lead has direct access to senior management and a designated back-up who can step in during an active test. A lead without a named back-up is a single point of failure during the red team testing window.
Check the lead's experience
The Control Team Guidance expects the lead to have experience in red team testing, crisis management and procurement. Ask for evidence of each area: prior involvement in red team or scenario-based exercises, a documented incident or crisis role, and experience running a sourcing process for external providers. Where one person lacks a skill, decide whether a named expert will cover it and record that decision before notification.
Add a C-level member deliberately
The guidance describes a C-level member as usually part of an extended control team composition. Decide early whether that executive joins the control team or stays in an oversight role, and confirm the choice with the board sponsor. An executive who is expected to join but has not agreed to the time commitment is a common gap in readiness reviews.
Staff the blue team with named people
The blue team is the internal group that detects and responds to the red team, and its reports feed the closure phase. Name the individuals who monitor, investigate and respond, including those who cover out-of-hours shifts, since testing can run across them. Confirm that these staff can keep the test confidential from colleagues who are not part of the exercise, and that their normal duties can be reduced without weakening day-to-day operations.
Plan for third-party roles
Where service providers support the entity's ICT, the control team may need to name supplier contacts who can act during testing, and the contracts behind them must allow testing. Confirm which external providers will be involved, who is their named contact, and whether the entity can call on them quickly. Procurement of threat intelligence and red team providers starts in the preparation phase, so these names should be known before notification.
Backups and due diligence on in-scope systems
This sequence confirms that every system a red team may touch can be restored if testing goes wrong. It runs before any testing starts, and its written output gives the control team the evidence it needs to set risk management for the preparation phase.
Identify the in-scope systems and their owners
Start from the functions and systems the entity has flagged as critical or important for the test, then list the underlying ICT assets that support them, including servers, databases, network devices, cloud workloads and business applications. Record a named owner for each asset who can speak for its availability and recovery. The output is a single inventory that the control team can check against the scope specification. The step is done when every flagged function maps to assets and each asset has an owner.
Map where each system is hosted and supported
For each asset in the inventory, record whether it runs in the entity's own data centers, in a cloud account, or with an external provider. Note which backup jobs, snapshot policies and recovery procedures apply, and which party operates them. Where an ICT service is partly outsourced, flag the dependency now, because testing may reach the supplier's infrastructure. The output is a dependency map showing who is responsible for backup and restoration of each asset.
Confirm backup coverage and recovery objectives
Check that each in-scope asset has a backup that is current, complete and stored where an attacker who gains access to production would not also reach it. Compare the recovery point and recovery time the business expects with what the backup design can actually deliver. Record gaps, such as unprotected configuration data, backups without offline or immutable copies, or systems with no documented recovery procedure. The output is a gap list signed off by the asset owner.
Verify that restores have been tested
A backup that has never been restored is an assumption, not evidence. For a sample of in-scope systems, including the most critical ones, perform a restore in a non-production environment and time it against the expected recovery objective. Record what was restored, who performed it, what failed and how it was fixed. The step is complete when each sampled system has a successful restore record, and any failures have a documented fix and a retest date set by the owner.
Check contracts for testing at suppliers
Where in-scope systems depend on external providers, review the ICT service contracts to see whether they allow testing on the supplier's infrastructure and whether the supplier must support restoration. Where they do not, record the gap and decide with the provider whether an amendment is needed, or whether the scenario must be kept off that infrastructure. Legal and procurement staff should own this review, with the control team lead informed. The output is a contract register showing which clauses exist, which are missing and what is being done about each gap.
Document the results for the control team
Compile the inventory, dependency map, gap list, restore test records and contract register into one due diligence file. Each item should name its owner, its date and its open actions. Hand the file to the control team lead before the preparation phase risk management is set, so that residual risks on live production systems are based on verified recovery capability. The step is complete when the control team lead has accepted the file and any unresolved gaps are listed as risks with an owner and a board-level decision on how to accept them.
Feed the outcome into preparation phase risk management
The control team uses the due diligence file to set the risk management for live testing, including which systems are excluded, which require extra monitoring, and what triggers a pause or rollback. Gaps that cannot be closed before testing may lead to narrower scope or a decision by the board to accept the risk as risk owner. Confirm with the authority and the control team lead that the decisions are recorded before testing begins. The output is a documented link between verified recovery capability and the test's risk controls.
Do your ICT supplier contracts allow testing?
Where part of your ICT infrastructure runs at a supplier, the TIBER-EU framework recommends that you confirm your ICT service contracts allow testing on the supplier's infrastructure, or add such clauses to future contracts. Treat this as a readiness gate, not a legal footnote. A red team test that reaches a cloud platform, a hosting environment or a managed service without the provider's written permission can stop mid-test, create a contractual dispute and leave the control team unable to explain what was touched. Find out before the authority's notification, because the provider's consent often takes longer than any internal approval.
Run a contract review across cloud, hosting and managed service agreements that support the in-scope systems. The compliance lead should list every supplier that hosts, operates or administers an in-scope function, then check each agreement for four things: whether penetration or red team testing is permitted and under what notice, which environments and accounts are covered, how the provider's own monitoring and incident handling interact with a test, and who may authorize testing on the provider's side. Ask legal counsel to confirm the wording rather than relying on a general security clause. Where a contract is silent or restrictive, record the gap, the supplier contact and the date you raised it.
Plan supplier consent and cooperation early, alongside the procurement and scoping work that the framework expects to start well before notification. Agree with each relevant supplier who the contact is, what they will be told, how their staff may be involved and whether they will detect or respond to test activity. Confirm this with the control team lead and the test manager, and record the outcome in the readiness file. Where the review shows that a supplier will not allow testing, the board should know before it authorizes live production testing, because that decision carries the risk it owns. For the detail on contract clauses, scenarios on provider infrastructure and provider staff involvement, see TIBER-EU for ICT third-party service providers.
Why you should contact the authority before notification
Contacting the TIBER Cyber Team early gives the entity time to check its readiness, shape a realistic scope and secure budget before the formal notification starts the clock. The preparation phase that follows is capped at six months, so the groundwork done in these early conversations largely decides whether that window is used well.
Assess your own cyber maturity first
Before calling the authority, review your current security testing history, including any traditional red teaming or scenario-based exercises you have run. The DNB and Bundesbank short read notes that entities below a certain cyber maturity will likely benefit more from a gradual increase in security testing first, so this review decides whether a TIBER test is the right next step. The output is a short internal note stating your maturity, your prior testing and a provisional view on whether you are ready.
Confirm board support and a named sponsor
Brief at least one board member on what a test asks of the organization: resources, the limited risk of testing live production systems, and funding for remediation. The board owns cybersecurity risk and must authorize that risk as its owner. The output is a documented board decision or minute that names a sponsor and records the budget envelope the sponsor is prepared to discuss.
Prepare the readiness brief for the first call
Assemble a short brief covering the systems and functions you consider critical, your ICT outsourcing arrangements, your current testing record and your expected staffing for control and blue teams. Flag any known gaps honestly. The output is a document of a few pages that the entity can share with the TIBER Cyber Team, giving the first conversation a concrete basis rather than a general inquiry.
Check backup and restoration for in-scope systems
Carry out due diligence on the systems most likely to be in scope and confirm that backup and restoration capabilities are in place before any testing. Live production testing makes recovery capability a precondition, not an afterthought. The output is a list of candidate systems with the date each was last restored successfully, which you can use to answer the authority's questions about operational safety.
Review supplier contracts for testing rights
Where ICT infrastructure is partly outsourced, check whether your ICT service contracts allow testing on the supplier's infrastructure. If they do not, the framework recommends adding such clauses to future contracts. Involve legal and procurement in this review. The output is a register of contracts showing which permit testing, which need amendment and which require supplier engagement before any scope is agreed.
Estimate staffing and budget constraints
Identify who would fill the control team and blue team roles, and whether those people can be released for the duration of the test. Estimate the budget for provider fees, internal time and remediation. The framework expects the entity to anticipate potential resource and budget constraints, because procurement and scoping take a long time. The output is a resource plan with named roles and an agreed budget range to bring to the authority.
Hold the early conversation with the TIBER Cyber Team
Contact your national TIBER Cyber Team well before the written notification. Use the readiness brief to ask whether a TIBER test suits your current maturity, whether a traditional red team or scenario-based test would come first, and what the authority expects of your timing. The output is a written summary of the authority's view and a list of follow-up items agreed on the call.
Confirm the timeline before written notification
Ask the authority to confirm the planned notification date, the start of the preparation phase, and the expected deadlines for scoping and procurement. The preparation phase lasts no longer than six months from the start date in the written notification, so that date anchors the whole plan. The output is an agreed working timeline and a clear list of what the entity must have ready before the notification arrives.
Budgeting for remediation before the test
A TIBER-EU test ends in findings, not a grade, so the cost of acting on them belongs in the readiness decision. The cards below cover what the board must fund, the internal effort that closes findings, and the cost guidance to request before notification.
Board funding commitment
The board owns cyber risk and must fund remediation of the findings, so that commitment needs to exist before the written notification. Ask whether the funding is pre-approved as a separate line or must go through a later budget cycle. A test that finds weaknesses with no approved budget to fix them leaves the entity carrying the risk the test was meant to reduce.
Fixes to systems and controls
Remediation usually covers configuration changes, patching, architecture changes, new monitoring, and process fixes for controls the red team bypassed. Cost depends on how many findings touch production systems and how many suppliers must change their services. Ask the team to size fixes by system and by owner before the test starts, not after the report arrives.
Internal hours to track and close
Findings need an owner, a deadline and a tracked status, and the control team lead will spend time on this long after the test ends. Budget for the blue team, system owners, and procurement staff who handle supplier fixes. These hours are often unfunded because they sit inside existing job roles, so list them explicitly.
Follow-up validation testing
Once a fix is in place, someone must confirm it works and that the original attack path is closed. Validation may come from the blue team, a retest by the red team provider, or independent assessment, and each option carries a separate cost. Agree the validation method and who pays for it in the remediation plan, not as an afterthought.
Remediation plan deadlines
The closure phase includes a remediation plan that follows the authority's assessment, and the framework sets a deadline for producing it. Staff and budget need to be available in that window, which can coincide with other regulatory work. Plan for the peak effort on the remediation plan before the test begins.
Cost guidance to request
Do not assume figures. Ask the national TIBER Cyber Team whether it charges fees, and ask each provider for a written breakdown of what its work covers and what it leaves to the entity. The TIBER-EU cost topic explains each component in detail, so use it as a checklist when you compare quotes.
Readiness questions buyers ask before a TIBER-EU test
Can we run a TIBER-EU test without any prior red teaming?
Possible in principle, but the DNB and Deutsche Bundesbank short read recommends that entities first run traditional red teaming or scenario-based tests. Those exercises can follow the TIBER-EU steps without being TIBER tests, and they show your blue team how it performs against an adversary before a live, threat-led exercise adds pressure. Entities below a certain cyber maturity are likely to benefit more from a gradual increase in security testing first. Confirm with your national TIBER Cyber Team whether your current maturity justifies a threat-led test now, since the authority may accept or deny test requests.
Who decides whether we are ready for a test?
The decision sits with your national TIBER Cyber Team, which assesses requests and may accept or deny them. Your organization makes its own case by showing the readiness prerequisites: critical importance to citizens or systemic relevance (or clearly identified crown jewels), a culture where the blue team can make mistakes while learning, prior red teaming or scenario testing, enough blue and control team staff, and sponsorship from at least one board member. If you are unsure, the short read advises contacting the TIBER Cyber Team directly. An outside consultant can help you prepare the evidence, but cannot make the readiness call for you.
How long before notification should we start preparing?
Start well before the written notification, because the framework strongly encourages the TIBER Cyber Team to contact the entity early. Procurement and scoping take a long time, and the entity must anticipate resource and budget constraints. The preparation phase itself lasts no longer than six months from the start date in the authority's notification, so readiness work such as due diligence on in-scope systems, backup and restoration checks, contract review and staffing should be finished before that clock starts. Ask your TIBER Cyber Team which early steps they expect and how far ahead they want to begin scoping conversations.
Can we do the readiness work ourselves?
Much of it, yes, and the framework expects the entity to own its controls and decisions. Internal teams can review backup and restoration capability for in-scope systems, map which ICT services are partly outsourced, check supplier contracts for testing clauses, and measure whether blue and control team staff are available. What internal teams usually find harder is an objective view of their own gaps, plus capacity to run this alongside daily operations. Outside help is typically used to prepare systems and evidence, while the control team lead, board sponsorship and final decisions stay inside the organization. Clarify with your authority which roles must be filled internally.
Does an outside consultant change our readiness?
A consultant does not change your readiness on its own, because readiness depends on your systems, people and governance. A capable partner can help you test backups, document in-scope systems, prepare contracts and gather evidence for the authority, which speeds up the work. Be precise about roles: only the organization owns its controls, and only the authority and its test providers run the test. Independence and conflict rules also limit which providers can later take part, so any consultant involved in preparation should be checked against those rules before you engage it for testing. Ask any provider to state in writing what it will prepare and what it will not do.
What does the test ask from our staff and board?
The test asks for named people, time and decisions from both staff and the board. The board must delegate management of the test to a control team lead, allocate the resources a test consumes, authorize the limited risk of testing live production systems as risk owner, and fund remediation of the findings. The control team should be as small as possible: a control team lead with authority to take full control of the process, direct access to senior management and a designated back-up, subject matter experts, usually a C-level member in an extended composition, and relevant third-party providers. Confirm with your authority how many blue and control team staff they expect, and whether your remediation budget is agreed before notification.
What should we budget for before a test starts?
Budget for four cost groups: provider fees for threat intelligence and red teaming, internal control team and blue team hours across the three phases, remediation of findings, and any authority fees where your country charges them. Costs rise with scope, the number of in-scope systems, the number of outsourced suppliers needing testing clauses, and whether the test covers several entities. Remediation is usually the largest unknown, because findings are not known until the test ends. Ask your TIBER Cyber Team and your national implementation document for the fee rules that apply, and request a written quote that separates one-time work from recurring work.
How DeployOpen works on this
DeployOpen helps organizations find out where their environment stands before a TIBER-EU test is notified. We scope the readiness work in writing, build the prerequisites inside your own infrastructure, and hand over documented evidence that your teams own. Assessment of readiness and any decision on a test rest with your organization and the national TIBER Cyber Team.
How we scope
- Written scope agreed before work starts, covering which in-scope systems and supplier services the readiness review includes
- Review of existing red teaming or scenario-based testing history to show what your blue team has already been tested against
- Clear list of which decisions stay with the board and control team lead, and which technical inputs we prepare for them
How we build
- Backup and restoration checks on in-scope systems so recovery is confirmed before any live testing is authorized
- Preparation of the controls, logging and detection sources your blue team will need to show what it saw during a test
- Review of ICT service contracts to identify where testing on supplier infrastructure is not yet permitted and needs new clauses
How we hand over
- Written readiness findings that list gaps, owners and the maturity steps the framework suggests before a full test
- Runbooks and evidence records for backups, contract gaps and staffing needs, kept in your own systems
- Handover session with your control team lead, blue team and board sponsor so ownership of each open item is explicit
How we support
- Fixed-scope engagements, with scope, deliverables and timelines agreed in writing before work starts
- Ongoing support, upgrades and continuous testing available as a retainer once a test is underway or planned
- Confirm with your national TIBER Cyber Team and any independent provider which parts of the readiness work they expect you to evidence
