Is TIBER-EU mandatory for my organization?
If a regulator, customer or board is asking whether you must run a threat-led test, the short answer is this: TIBER-EU is voluntary for authorities to adopt, and it is mandatory for an entity only when its competent authority identifies it for DORA threat-led penetration testing (TLPT). Most of the 21 jurisdictions listed by the ECB as adopting TIBER-EU ran tests on a voluntary basis, and the framework itself treats intervals of 3 years between tests as the norm. Confirm the current adoption list on the ECB TIBER-EU page before you rely on it, because the list changes as authorities join.
Whether you are identified depends on your sector, size and systemic importance, and on the criteria your competent authority applies. For significant institutions, the ECB identifies entities using criteria on systemic importance, business impact and ICT risk profile, and keeps a list updated annually. Ask your authority in writing whether you are on a TLPT list, which provisions apply to you, and what testing frequency it expects, since the authority can require more or less frequent testing than the baseline. Microenterprises and entities excluded under Article 16(1) of DORA are outside the TLPT obligation. A voluntary test is still possible, but it does not count toward the timing of a mandatory test.
You own the decision to test and the controls that a test examines. The authority and its TIBER Cyber Team govern the test itself, including the test manager's role, approvals and the attestation at closure. Your first practical steps are to record your identification status, name a single point of contact for the control team, and agree with your board who will sign off a voluntary test if one is proposed. Clarify these points early, because they determine whether any testing you commission will meet the formal requirements that your authority sets.
Which entities must test under DORA and the criteria used
DORA requires threat-led penetration testing (TLPT) from entities that competent authorities identify, using categories set in Article 2(2) and criteria tied to systemic importance and ICT risk. The cards below set out who falls in those categories, where the authority can decide otherwise, and how the ECB selects significant institutions.
G-SIIs and O-SIIs
Credit institutions that are global or other systemically important institutions, or part of one, are the first category Article 2(2) asks authorities to require testing from. Check whether your group is designated at group level, since a subsidiary can be pulled in through its parent. Confirm your current designation with your competent authority, because the status can change between review cycles.
Large payment and e-money institutions
Payment institutions are in scope when they exceed EUR 150 billion of payment transactions, and electronic money institutions when they exceed EUR 40 billion of outstanding e-money, in each of the two preceding years. Both thresholds are tested against the two-year window, so a firm that crosses a threshold briefly should ask its authority how the look-back applies. Keep transaction and e-money records that can support the calculation.
Central securities depositories and central counterparties
Central securities depositories and central counterparties are named directly in Article 2(2), so authorities are expected to require testing from them unless their own assessment shows testing is not justified. Market infrastructure operators should confirm their authority's position in writing. Their critical services, settlement chains and interconnections usually drive the scoping discussion once a test is designated.
Certain trading venues and large insurers
Article 2(2) also covers certain trading venues and large insurers, which the authority selects based on the scale and criticality of their ICT services. Insurers should check how their size is measured and whether group-level figures apply. Trading venues should map which systems support order execution, clearing links and market data distribution.
Authority waiver for unjustified testing
Article 2(2) lets the authority skip the requirement for an in-scope entity where its assessment shows testing is not justified. A waiver is a supervisory decision, not something the entity can assume. Ask the authority for its reasoning in writing, and keep the ICT risk and maturity evidence that supports the request.
ECB significant institution criteria
For significant institutions, the ECB applies criteria on systemic importance, business impact and ICT risk profile to decide who must test. It keeps a list that is updated annually, and each listed institution must appoint a single point of contact who joins the control team when testing starts. Check the current list and make sure the contact is named before the authority asks for it.
When a TIBER test is voluntary and what that means
Most jurisdictions run TIBER tests on a voluntary basis, so an entity outside the DORA TLPT population usually has no legal duty to test. Adoption of the framework is itself voluntary for authorities, and each adopting jurisdiction publishes its own national or European implementation document. A test only counts as a TIBER test when a test manager from the TIBER Cyber Team accompanies it. If your authority offers a test without that role, treat it as a different exercise and confirm with the authority how it is classified before you describe it to your board or regulator as TIBER-based.
The Spanish implementation guide, TIBER-ES, says any entity may ask to be tested, but it advises testing mainly for systemic entities or those with a certain level of cyber maturity. The TIBER Cyber Team may accept or decline the request. Less mature entities can usually find weaknesses through simpler tests at lower cost and risk. Before you submit a request, check the authority's own criteria, ask whether a test manager will be assigned, and confirm what the authority expects from you if the request is accepted.
Significant institutions under the ECB's supervision need to read the voluntary route with care. The TIBER-EU SSM guide allows a significant institution to run a voluntary TIBER test through its national TIBER Cyber Team, provided it informs the ECB. That test is not a DORA TLPT and does not count toward the timing of the mandatory test, so the three-year clock keeps running. Voluntary tests suit entities that want to learn where they are weak and can act on the findings, but the decision should be made with the mandatory schedule in view.
How the 3-year cycle and exclusions work
This sequence shows how a financial entity moves from identification by its competent authority to a recurring TLPT obligation, and which entities fall outside it. The authority, not the entity, decides when testing happens and how often.
Competent authority identifies the entity
The entity's competent authority decides whether it must carry out threat-led penetration testing (TLPT). For significant institutions, the ECB identifies entities using criteria on systemic importance, business impact and ICT risk profile, and keeps the list updated annually. The entity does not choose this status for itself. You know this step is complete when the entity has written notice that it is subject to mandatory TLPT, or when it appears on the annually updated list.
Apply the Article 2(2) population test
Authorities are required to require testing from listed categories of financial entities, including credit institutions that are G-SIIs or O-SIIs (or part of one), large payment and electronic money institutions, central securities depositories, central counterparties, certain trading venues and large insurers. Authorities may drop an entity from this group if their assessment shows testing is not justified. Confirm your category against Article 2(2) of DORA and check the written assessment from your authority.
Confirm exclusions before planning
Microenterprises and entities under Article 16(1) of DORA are excluded from the TLPT obligation. An entity that falls in either group should record the basis for its exclusion and keep it on file for supervisory review. If an excluded entity still wants a test, it would be a voluntary exercise and not a DORA TLPT. Ask your competent authority to confirm the exclusion in writing.
Set the testing interval by risk profile
Identified entities must carry out TLPT at least every 3 years. The authority may require testing more or less often, based on the entity's risk profile. The timing is therefore set by the authority, and the entity should ask for the confirmed date and interval in writing. The first test starts when the authority notifies the entity under the TIBER-EU process, and the next cycle is counted from that point under the authority's rules.
Appoint the single point of contact
Each mandatory entity appoints a single point of contact for the TLPT. This person joins the control team when the test starts and becomes the main link between the entity, the TIBER Cyber Team and the test manager. Confirm the appointment in writing before the preparation phase begins, since the control team cannot be formed without this named contact.
Track the next cycle with the authority
After each test, the cycle restarts under the authority's timetable, and a voluntary test does not reset or count toward the timing of a mandatory test. Keep a register that records the authority's decisions, the interval it set, the exclusion basis and the date of the last DORA TLPT. This record shows the authority, and any later assessor, that the entity follows the cycle it was given.
When a voluntary test still makes sense
An entity that is not on its competent authority's list for mandatory TLPT can still ask its national TIBER Cyber Team for a test. The value is a threat-led view of how attackers would reach critical functions, which a fixed-scope penetration test rarely provides. Acceptance is not automatic, because the TIBER Cyber Team may accept or deny requests, so the decision comes before any budget is committed. Read the DNB and Bundesbank short read on timing before you apply.
- Threat-led value: scenarios are built from threat intelligence about actors who target your sector, then tested against live defenses.
- Maturity prerequisite: the framework treats tests as advisable for entities with a certain cyber maturity, so expect questions on detection, response and past testing.
- Lower-cost alternative: where maturity is limited, simpler tests with lower costs and risks can surface weaknesses first, as the Spanish implementation guide notes.
- Test manager role: a test only counts as a TIBER test if a test manager from the TIBER Cyber Team accompanies it, so a privately run red team exercise does not carry the label.
- Confirm first: ask the national team in writing whether your entity is eligible, what the initial request must contain and whether it will accept a test in the planned year.
Before budgeting, ask the national team to confirm acceptance and what it expects the control team and blue team to supply.
A significant institution named for mandatory TLPT may run a voluntary TIBER test through its national TIBER Cyber Team after informing the ECB. Under the ECB's SSM guide, that test is not a DORA TLPT and does not count toward the timing of the mandatory test. Its value is practice and a sharper view of weaknesses before the mandatory cycle, which must run at least every 3 years unless the authority sets a different frequency based on the entity's risk profile. Review the SSM implementation guide before deciding.
- Timing does not reset: the voluntary test leaves the mandatory due date unchanged, so both must be planned on the same calendar.
- Double cost exposure: the entity may fund a second full test, so the budget should show both tests separately.
- Lessons transfer: findings and remediation from the voluntary test can shape scope, flags and supplier readiness for the mandatory test.
- Notification discipline: inform the ECB before the voluntary test proceeds, as the SSM guide sets out.
- Confirm first: ask your joint supervisory team how the voluntary test will be recorded and whether its outputs can be reused in the mandatory test.
Check with your supervisory team how the voluntary test interacts with your mandatory date before committing internal or provider resources.
TIBER-EU is designed for systemically important entities that are sufficiently mature in ICT, but it can be used by entities of any type or size in the financial and other sectors. A jurisdiction may extend it to sectors such as telecommunications or utilities. In that case, the test's eligibility and rules come from the national implementation document and the sector regulator, not from DORA. The framework document sets out the mandatory requirements any adopting jurisdiction must keep to.
- Legal basis: an extension comes from the national authority or sector regulator, so confirm which body sets the rule and whether it is mandatory or voluntary.
- Mandatory core: an adopting jurisdiction must keep to the framework's mandatory requirements, while optional requirements may be adapted locally.
- Maturity and scope: the framework was built for mature organizations, so check whether your ICT controls and monitoring can support a threat-led test.
- Supplier dependencies: outsourced platforms and cross-sector providers may fall in scope, so contractual permission is needed before testing starts.
- Confirm first: check whether your sector appears in the national implementation document and whether the regulator accepts voluntary requests.
Ask the national TIBER Cyber Team and your sector regulator to confirm the legal basis in writing before treating the test as a compliance step.
Mandatory DORA TLPT compared with a voluntary TIBER-EU test
This table compares a mandatory DORA threat-led penetration test with a voluntary TIBER-EU test on who requests it, who decides, and how each counts toward the testing cycle. Read each row against your own situation and confirm the specifics with your competent authority, because the rules depend on whether you are identified for mandatory testing.
| Question | Mandatory DORA TLPT | Voluntary TIBER-EU test |
|---|---|---|
| Who requests it | The competent authority requires it from entities it identifies for TLPT | The entity asks, and the national TIBER Cyber Team may accept or deny the request |
| Who decides | The competent authority identifies the entity and sets the testing frequency | The TIBER Cyber Team decides whether to accept the test |
| Counts toward the 3-year cycle | Yes, it sets the timing of the mandatory test | No, a significant institution's voluntary test does not count toward its mandatory timing |
| Test manager present | Yes, a test manager from the TIBER Cyber Team accompanies the test | Yes, a test is only a TIBER test if a TIBER Cyber Team test manager accompanies it |
| Core requirements identical | Yes, the ECB states the core requirements of DORA TLPT and TIBER-EU are identical | Yes, the same framework applies when the test runs under a national or European implementation |
| Who pays for providers | The entity procures and pays its threat intelligence and red team providers | The entity procures and pays its threat intelligence and red team providers |
| Confirm with your authority | Whether formal requirements beyond the core set apply to your test | Whether your authority will accept the request and how it treats the test in its records |
How to confirm whether your entity is identified
Start by establishing whether your entity is identified for mandatory DORA threat-led penetration testing (TLPT), because that status, not the size of your institution, decides whether a test is compulsory. The ECB identifies significant institutions subject to mandatory TLPT using criteria on systemic importance, business impact and ICT risk profile, and it keeps the list updated annually. Your compliance lead should check the current list first, then confirm the answer with the competent authority. Do not rely on a summary from a consultant or a peer, because the list changes each year and the authority's written answer is the record you will need.
Next, read the implementation document that governs your jurisdiction. Each adopting country publishes a national TIBER-XX or European TIBER-EU YY document, and that document sets local rules that sit on top of the framework's mandatory requirements. Look for how the authority applies Article 2(2) of DORA, how it treats voluntary requests and whether it adds conditions to the test. Write down the document title, version and date you relied on, so the assessment can be traced later.
Then ask the competent authority in writing whether your entity is on its TLPT list for the current cycle, and ask how the answer affects the timing of your next mandatory test. Record the reply in your compliance file with the date, the sender, and the name of the person who confirmed it. If you are identified, ask the authority to confirm your single point of contact. Each identified entity must appoint one, and that person joins the control team when the test starts. Name this person now, document the appointment, and make sure they understand that the role carries responsibility for coordinating the test.
What an implementation partner can and cannot do for your status decision
Whether your entity is mandatory or voluntary is decided by the organization and its authority, not by a consultant. DeployOpen can prepare the material that informs that conversation and plan the cycle, but it does not identify entities, issue reports or run the test itself.
Ownership of the status decision
Your board and management own the position your entity takes on TIBER-EU and DORA TLPT, including whether to request a voluntary test. A partner can help you structure the internal discussion and document the reasoning, but the decision and its records stay with your organization. Ask any partner to confirm in writing that it does not make or sign this decision on your behalf.
Authority identification
Identification of a significant institution for mandatory TLPT is made by the competent authority, which for significant institutions is the ECB under its published criteria on systemic importance, business impact and ICT risk profile. A partner cannot promise identification or predict the outcome. Confirm with your supervisor which criteria apply to your entity and what information they expect from you.
ICT asset inventory and gap notes
Before any authority conversation, you need a current picture of your critical or important functions and the ICT systems that support them. A partner can help build that inventory, record where it is incomplete, and write gap notes that show what is known and what is not. These documents are working material for your team, not a finding or an assessment result.
Evidence preparation for the authority
Supervisors will ask for evidence of how your organization manages ICT risk, runs testing and handles prior findings. A partner can gather and organize that evidence from your own systems, such as configuration records, prior test reports and remediation tracking. It cannot certify that the evidence is sufficient; that judgment belongs to the authority.
Test cycle planning
Mandatory TLPT must take place at least every 3 years for identified entities, and the authority can require more or less frequent testing based on risk. A partner can help map that interval against your change calendar, budget cycles and supplier contracts so the next test is planned, not discovered late. Treat any plan as a draft until your authority confirms the timing in writing.
Independent test roles stay separate
The TIBER Cyber Team and test manager at the authority, the independent threat intelligence and red team providers, and the test attestation all sit outside an implementation partner's role. Where an authority accompanies a test, it carries the test manager function. A partner preparing your systems must not also act as your red team provider on the same test without checking the independence and conflict rules.
Common questions about TIBER-EU obligations
Do we need a voluntary TIBER-EU test if our authority has identified us for DORA TLPT?
No. If your competent authority has identified your entity for mandatory threat-led penetration testing, the DORA TLPT obligation applies to you, and a TIBER-EU test under your national or European implementation can serve as that test if it meets your authority's formal requirements. A voluntary test is a separate choice that adds value only when you want more frequent testing than the mandatory cycle or want to test a system outside the mandatory scope. Confirm with your authority which test it expects you to run and whether an additional test is needed.
What must we do if our authority says we are not identified for TLPT?
Treat the answer as a status decision, not a closed question. Ask the authority to confirm in writing that your entity is not on the list of institutions it must test, and record the date and the reason given. Then decide whether a voluntary test still makes sense for your cyber maturity and risk profile. Note that the authority may still review your status later, because identification depends on systemic importance, business impact and ICT risk profile, and that assessment can change over time. Keep the written confirmation in your DORA evidence file.
Can our own security team run the TIBER-EU test without outside providers?
Not in the way the framework is designed. A TIBER-EU test needs a threat intelligence provider and red team testers that are procured externally, and the TIBER Cyber Team and test manager at the authority supervise the test. Your internal staff form the control team and blue team, manage the test with the authority, and handle evidence and remediation. Your internal red team can take part only within the independence and conflict rules set by your authority. Confirm the exact role limits for internal testers with your test manager before you plan staffing.
How often do we have to repeat threat-led penetration testing?
Identified financial entities must carry out TLPT at least every 3 years. Your competent authority can ask for more or less frequent testing based on your risk profile, so the 3-year interval is the minimum for a mandatory test and not a fixed schedule for every entity. The TIBER-EU framework also treats intervals of 3 years between tests as the norm because of the resources and costs involved. Ask your authority to confirm the interval in writing, and plan remediation and staffing so the next cycle starts on time.
How much effort does the mandatory status question take from our compliance lead?
The effort is mostly coordination and documentation, not testing. Your compliance lead typically needs to gather the entity's ICT risk data, business impact information and prior test history, answer the authority's questions on systemic importance and ICT risk profile, and confirm the single point of contact who joins the control team if you are identified. The amount of work depends on how well your ICT asset inventory, critical functions and previous assessments are documented. Ask your authority which information it expects and by what date, so the work can be scheduled before any notification arrives.
Does a voluntary TIBER-EU test count toward our mandatory testing deadline?
Generally no. Under the TIBER-EU approach for significant institutions, a voluntary TIBER test run through a national TIBER Cyber Team after informing the ECB is not a DORA TLPT and does not count toward the timing of the mandatory test. This means the mandatory 3-year clock continues to run independently of any voluntary test. Confirm with the ECB and your national authority how a voluntary test is recorded, so your DORA testing plan shows which test satisfies which obligation.
Who decides whether a voluntary TIBER test can go ahead?
The TIBER Cyber Team at the relevant authority decides. In the Spanish implementation, for example, any entity may ask to be tested, but the team may accept or deny the request, and tests are advised mainly for systemic entities or those with a certain cyber maturity. Less mature entities often find weaknesses through simpler tests with lower costs and risks. Before you apply, ask the authority which entities it accepts, what maturity evidence it expects, and whether a lighter assessment would meet your goals.
How DeployOpen works on this
DeployOpen is a Chainscore Labs company that plans, implements and documents self-hosted open-source platforms inside your own infrastructure. For a question like whether TIBER-EU applies to your entity, we help you prepare the systems, controls and evidence that a competent authority or an independent assessor will examine, while the authority and the entity's own leadership make the determinations.
How we scope
- We agree a written scope that names the entities, systems, ICT services and regulatory questions covered before any work starts.
- The scope records which decisions stay with your competent authority and which inputs we prepare for them, such as system inventories and criticality mapping.
- Engagements are fixed-scope, with deliverables and timelines confirmed in writing, and a quote follows directly from that scope.
How we build
- We deploy and harden the self-hosted open-source platforms that hold your ICT asset register, incident records and testing documentation inside your environment.
- We configure logging, access control and document repositories so that evidence of ICT risk management can be produced on request.
- We integrate these platforms with your existing cloud accounts, data centers or air-gapped networks without moving data outside your control.
How we hand over
- We deliver written documentation of each system, its configuration, its owners and the evidence it generates for your assessors.
- We walk your staff through operation, so your own team can answer questions from the authority or an independent assessor.
- We confirm with you which determinations, reports and attestations remain with your organization, your authority or an independent auditor, since DeployOpen does not issue them.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the initial handover.
- Security testing of applications, APIs, cloud and infrastructure can be scoped separately under its own written agreement.
- We recommend that you confirm your authority's current guidance and any national rules with the authority directly before relying on our preparation work.
