What TIBER-LU asks of a Luxembourg entity and who runs it
A supervisor, a contract or a DORA obligation now points your organization to TIBER-LU, the joint framework of the Banque centrale du Luxembourg and the CSSF. It has been in place since 3 November 2021, and the TIBER-LU Implementation Document (version 1.1) was updated on 20 June 2025 so the programme can run alongside DORA threat-led penetration testing (TLPT). The first task is to establish which authority is driving your test, whether it is a voluntary exercise or a mandated DORA TLPT, and to confirm that with the authority before any spend is committed.
Your organization owns its controls, its risk decisions and its test outcomes. The two authorities run the programme, including the TIBER Cyber Team roles and the sign-off of key documents. An implementation partner such as DeployOpen can prepare systems, logging, control evidence and documentation for the test, and can support the remediation work that follows. It does not issue the attestation, and it does not issue any report on the entity's behalf. Those documents come from the entity and the authority under the framework. TIBER-LU is also not a pass or fail certification: the framework is designed to show strengths and weaknesses so the entity can improve its cyber maturity.
Cost and effort depend on the scope the authority agrees, including the functions and flags tested, the number of providers and whether the test is multi-jurisdictional. Ask for a written scope before accepting any figure, and confirm the following with tiber@bcl.lu (central bank) and tiber@cssf.lu (supervisor): which authority applies to your entity, who your point of contact is, and which version of the Implementation Document governs your test. Check the current framework text in the TIBER-EU Framework (January 2025) alongside the TIBER-LU documents before you plan the timeline.
Who does what in a TIBER-LU test
The Banque centrale du Luxembourg and the CSSF run TIBER-LU jointly, and the framework is delivered through a TIBER Cyber Team and a test manager. The team is the authority's point of contact for the tested entity, it reviews the scope and key documents, it supervises the threat intelligence and red team work, and it assesses the results. The authorities own the process, not the technical work of the test.
- Process ownership: The TIBER Cyber Team sets the timeline, approves the scope specification and tracks each phase from notification to closure.
- Supervision: The test manager and team oversee the red team testing and check that the control team keeps the test safe and controlled.
- Assessment: The authority assesses the closure deliverables, including the red and blue team reports, before the remediation plan is due.
- Multi-jurisdiction coordination: Where several TIBER Cyber Teams are involved, they agree a lead team and the roles of other teams as participants or observers.
- Outsourcing: Authorities do not outsource their oversight role. The tested entity should not expect the authority to select its providers.
Confirm the current contacts and documents with tiber@bcl.lu and tiber@cssf.lu before the test starts.
The tested entity owns the test, its systems and its results. Its control team manages the test internally and is the only channel between the providers and the authority. The blue team represents the entity's live defensive functions, which detect and respond to the red team without being told the test is under way. The entity is responsible for the remediation plan and the attestation at closure.
- Control team: Runs the internal side of the test, holds the flags and the scope, and manages risk and safe execution. Its members are normally senior staff who can stop activity if needed.
- Blue team: Operates detection and response as it normally would, and produces the blue team test report at closure.
- Procurement: The entity buys its threat intelligence provider and red team testers, and must select providers that meet the TIBER-EU requirements for them.
- Governance: The entity signs the attestation, owns the remediation plan and reports to its board on the findings.
- Outsourcing: The control team and blue team are normally internal. Advisory support can be bought, but the entity should confirm that the control team stays under its own management.
Ask your compliance lead to confirm which roles must be internal under your authority's requirements.
TIBER-EU sets out five parties in a test: the TIBER Cyber Team and test manager, the control team and blue team, the threat intelligence provider and the red team testers. The last two are external providers procured by the entity. An implementation partner may help prepare systems, controls and documents during the preparation phase, but it sits on the preparation side and does not run the threat intelligence or red team testing.
- Threat intelligence provider: Produces the targeted threat intelligence report and proposes the scenarios used in testing.
- Red team testers: Write the red team test plan, carry out active testing against the flags, and produce the red team test report.
- Implementation partner: Prepares systems, documentation and evidence before testing starts, and does not act as a red team or threat intelligence provider in the same test.
- Independence boundary: Providers must be independent of each other and of the entity's internal teams, and the same firm should not both prepare and attack the systems in a way that compromises the test.
- Limits: No partner issues the test summary report or the attestation. Those remain the responsibility of the entity and the authority.
Check the provider requirements in the TIBER-EU procurement guidance and the TIBER-LU implementation document before you sign any contract.
How a TIBER-LU test moves from notification to attestation
The sequence runs in three TIBER-EU phases, each closing with a defined output that the BCL and CSSF can check before the next phase begins. Following it in order keeps the test comparable with other TIBER-EU tests and with DORA threat-led penetration testing.
Receive written notification and initiate the test
The test begins when the authority sends written notification to the entity, and the preparation phase, which lasts up to six months from that notification, opens. The entity and the TIBER Cyber Team then hold initiation to confirm roles, the test timeline and the parties involved, including the test manager and the control team. The output is a set of initiation documents that record who is accountable for each function. Confirm with the TIBER-LU contacts at tiber@bcl.lu and tiber@cssf.lu how the notification is issued and which initiation documents they expect.
Set up the control team and risk management
The entity appoints its control team, the internal group that supervises the test, keeps the tester activity safe and protects test confidentiality. The entity also documents its risk management arrangements for the test, including how it will stop or adjust activity if testing causes unintended impact. The output is a confirmed control team membership and a risk management record that the authority has reviewed. Ask the TIBER-LU contacts which roles must be named in writing and at what point the record is due.
Scope critical or important functions and flags
The entity and the TIBER Cyber Team identify the critical or important functions in scope and set the flags, which are the targets the red team will try to reach. The scope specification document records the functions, systems, third parties and boundaries agreed for the test. The output is an approved scope specification that fixes what the red team may and may not attack. Where a lead team is needed for a multi-jurisdictional test, the teams agree it at this stage, considering the entity's home member state and the order of initiation.
Procure the threat intelligence and red team providers
The entity procures a threat intelligence provider and red team testers under the framework's requirements for service provider procurement, and the authority checks that the providers meet them. Contracts and their terms are agreed before any testing starts. The output is signed provider contracts and a record of the authority's review. Confirm with the TIBER-LU contacts whether the authority reviews provider selection before contracts are signed.
Produce the targeted threat intelligence report and scenarios
The threat intelligence provider analyzes the threats that could realistically target the entity and selects the scenarios the red team will use. The output is the targeted threat intelligence report, which the control team and test manager review and approve before testing begins. This report is the first deliverable of the testing phase and sets the basis for the tests that follow.
Agree the red team test plan and run active testing
The red team prepares the red team test plan, which sets out how each scenario will be executed against the flags. Once the control team and test manager approve it, active red team testing runs for at least 12 weeks under their supervision. The output is a documented record of the attack activity, kept by the control team, that shows what was attempted and what the blue team detected or missed. Ask the TIBER-LU contacts how the plan is submitted and approved.
Deliver the test reports, replay and purple teaming
Within 10 weeks of the end of active testing, the red team and blue team each deliver their test reports. The test then moves through replay, where the activity is walked through step by step, and purple teaming, where red and blue teams work together on the gaps found. The entity completes 360 degree feedback from the people involved. Outputs are the red team test report, the blue team test report, replay findings, purple teaming results and the 360 degree feedback record.
Issue the test summary report, remediation plan and attestation
The entity and the TIBER Cyber Team agree the test summary report, which covers the strengths and weaknesses found. Within 8 weeks of the authority's assessment, the entity submits its remediation plan setting out how it will raise its cyber maturity. The test closes with an attestation confirming the test was carried out under the framework. TIBER-EU tests do not produce a pass or fail result. Confirm the attestation format, signatories and submission route with the TIBER-LU contacts.
Voluntary TIBER-LU test or mandatory DORA TLPT: which applies
This table compares a voluntary TIBER-LU test with a DORA threat-led penetration test (TLPT) on trigger, decision-maker, DORA status and what to confirm. Read it as a checklist: the path you are on determines whether a test counts toward DORA, so confirm it with the supervisor before any provider is procured.
| Aspect | Voluntary TIBER-LU test | Mandatory DORA TLPT |
|---|---|---|
| Trigger | Entity is invited or chooses to take part in a TIBER-LU programme run under the BCL and CSSF framework | Entity is identified as required to perform TLPT under DORA and the applicable competent authority rules |
| Who decides | The BCL and CSSF, jointly, through the TIBER-LU programme | The competent authority designates the entity, which then follows its formal requirements |
| Counts as DORA TLPT | Only if the test also meets the formal requirements set by the competent authority for DORA purposes | Yes, when the test is run under the TIBER-EU core requirements and the authority's formal requirements |
| Core requirements | Must keep TIBER-EU's mandatory requirements, as adopted in TIBER-LU | Core requirements of DORA TLPT are identical to TIBER-EU, per the ECB (September 2024) |
| Test frequency | Set by the programme, not by a DORA deadline; confirm the expected cycle with the supervisor | Set by the DORA and competent authority requirements that apply to the entity |
| Provider procurement | Confirm with the supervisor which provider rules and approvals apply before contracting | Confirm with the competent authority whether the provider and contract requirements are met before contracting |
| What the entity should confirm | Whether participation is voluntary and whether results must be shared for any DORA purpose | Whether the test will be formally accepted as DORA TLPT and which authority supervises it |
| Contact | tiber@bcl.lu for the central bank side and tiber@cssf.lu for the supervisor side | Your competent authority, using the same TIBER-LU contacts where the CSSF is involved |
What changed in TIBER-LU after DORA TLPT
The BCL and CSSF revised TIBER-LU because DORA introduced threat-led penetration testing (TLPT) as a binding requirement for certain financial entities, and the existing Luxembourg programme had to continue alongside it without creating two incompatible testing regimes. Following DORA's entry into force and its TLPT requirements, the two authorities reviewed the framework they had implemented jointly on 3 November 2021. The result was an updated *TIBER-LU Implementation Document*, version 1.1, dated 20 June 2025. Its purpose is to keep the voluntary programme running while aligning it with the DORA TLPT regime. For an entity in Luxembourg, the practical question is which test it is in, and whether a test run under TIBER-LU can satisfy a DORA obligation. Confirm that answer with the BCL and CSSF contacts before scoping any test.
The 2025 changes to TIBER-EU, which Luxembourg applies, matter for the same reason. The Eurosystem's update of 11 February 2025 aligned the process steps of TIBER-EU with the deliverables and strict timelines of the DORA TLPT regulatory technical standards. Purple teaming became mandatory, the White Team was renamed the Control Team, and authorities were allowed to publish a short implementation document in place of a full national guide. Entities should expect the Control Team role, the purple teaming step and the closure deliverables to be checked against the DORA timelines. Plan your internal roles and provider contracts around these named steps rather than around the pre-2025 wording.
Luxembourg specifics, including how the authorities apply these changes, which obligations sit with the BCL and which with the CSSF, and what the version 1.1 document requires of your organization, appear only in the document itself. Read the version 1.1 implementation document in full before starting preparation, and send written questions to tiber@bcl.lu for the central bank side or tiber@cssf.lu for the supervisory side. Keep the answers on file, since they will inform the scope specification and the procurement of your threat intelligence provider and red team testers.
What an entity needs in place before the BCL and CSSF start a test
Before the Banque centrale du Luxembourg and the CSSF open a TIBER-LU test, the entity must have its people, scope, asset map, providers, budget and test environment ready. Each card below names one item, how the entity can check it internally, and what the authority is likely to ask to see during initiation and scoping.
A named control team
The control team steers the test on the entity's side, sits between the authority and the red team, and manages risk during active testing. Confirm that named members have the seniority to stop or adjust a live scenario and that each has a deputy. Expect the authority to ask for the membership list, roles, and the entity's risk management approach for the test, including how the team will handle a situation where the red team reaches a live production system.
Agreed scope of critical functions
The scope specification sets which critical or important functions the test covers and which flags the red team will pursue against them. Check that business owners have validated each function against the entity's own impact analysis and that the scope reflects the functions the entity would most want protected. Expect the authority to review a draft scope specification document and to challenge functions that are missing or defined too narrowly.
Documented ICT and business function map
The function map links each critical function to the people, processes, systems, data and third-party services that support it. Verify that the map is current, that it names systems hosted by external providers, and that owners have signed off on it. Expect the authority to ask how the map was built, which sources it relied on, and how it will be used to choose flags and target systems during threat intelligence work.
Procurement plan for testers and intelligence
The entity must procure a threat intelligence provider and red team testers that meet TIBER-EU requirements, and the procurement must follow the guidance on service provider selection. Prepare a written plan covering selection criteria, evaluation steps, contract terms and the timing needed before testing starts. Expect the authority to review the procurement approach and to confirm that the chosen providers are independent of each other and of the entity's own service providers.
Remediation budget and named owner
A TIBER-LU test produces a remediation plan that the entity must deliver after the authority's assessment, so funding and ownership need to exist before the test starts. Confirm who approves spending, which budget line will carry remediation work, and which executive owns delivery. Ask internally how the budget will be sized, since it depends on the findings. Expect the authority to ask who signs the remediation plan and how progress will be reported.
Test environment access arrangements
Access arrangements define how the red team reaches production and supporting systems, what emergency contacts exist and how the test can be halted. Verify that the entity has written rules for access, logging, data handling and escalation, and that operations staff know how to reach the control team at any hour. Expect the authority to ask for these arrangements, the escalation path and the process for stopping the test if a live service is affected.
How mutual recognition helps entities that operate in several countries
Mutual recognition means a test that meets the TIBER-EU mandatory requirements can count in every adopting jurisdiction, so a Luxembourg entity with operations elsewhere does not have to repeat the same threat-led test for each supervisor. The recognition rests on the common process and technical quality standards that TIBER-EU sets. It does not rest on the Luxembourg label alone. An entity that drops a mandatory element, such as the closure phase or the required scoping, loses the basis for recognition in every country at once, so the mandatory requirements are the first thing to check before any test starts.
When a test spans several jurisdictions, the TIBER Cyber Teams involved agree which one leads. The TIBER-EU Framework (2025) says the choice takes into account the entity's home member state, the functions being tested and the order in which the authorities initiate their parts. Other teams join as participants or observers. For a Luxembourg entity, the practical step is to map its group structure before scoping: identify the home supervisor, list the entities and functions in each country, and note which authority is likely to lead. Ask the BCL and the CSSF to confirm that view early, using tiber@bcl.lu and tiber@cssf.lu as the starting points, because the lead decision shapes the scope, the procurement and the timetable.
Recognition is not automatic and it is not a waiver. Each supervisor still decides how the test relates to its own requirements, and the entity should obtain written confirmation of the arrangement from every authority involved, including whether a test run under TIBER-LU also counts as DORA threat-led penetration testing for the group. Ask each supervisor which documents it will accept, who receives the test summary and attestation, and how observer teams will take part. Build those answers into the initiation documents and the budget, because an arrangement agreed late can force a second test.
How to choose a threat intelligence, red team or readiness partner
A TIBER-LU test needs several outside parties, and each one should be chosen against the same written checks. The cards below cover experience, independence, scope, evidence handover and alignment with the authorities, so the entity can judge providers before signing anything.
Relevant TIBER-EU experience
Ask each provider which TIBER-EU or DORA threat-led tests it has delivered, in which roles, and under which national implementation. Confirm that the team members who will work on the test have done this work, not only the firm. Ask how the provider stays current with the 2025 framework document and the ECB guidance published with it. Treat vague answers about experience as a reason to ask for a named, written reference from the entity's own side, not as a pass.
Command of mandatory requirements
A provider should explain the mandatory TIBER-EU requirements in its own words and show where each one appears in its proposed work plan. Check that it understands the 2025 deliverables, including the purple teaming step and the Control Team that replaced the White Team. A provider that cannot map its plan to these items will create gaps the authority may later reject.
Independence from the red team
When a firm helps prepare the entity, for example by building the control team process, documenting risk management or assembling evidence, it should not also be the red team testing the same systems. Ask each provider to state in writing which roles it holds and which it declines. Confirm that the entity, not the implementation partner, makes the decisions that the authority expects the entity to own.
Fixed-scope written deliverables
Require a written scope that lists each deliverable, its owner, the document it produces and the phase it belongs to. For a Luxembourg test, the list should match the preparation, testing and closure phases of the framework. Ask how changes to scope are priced and approved. A quote that cannot be traced to this list is not yet comparable with others.
Handover of evidence and documents
Confirm in the contract that all test documents, reports, logs and evidence transfer to the entity at closure, in formats the entity can store and produce to the BCL or CSSF. Ask who keeps working copies, how long the provider retains test data and how it is deleted. The entity must be able to answer an authority question without relying on the provider's systems.
Confirming the approach with the authorities
Before signing, ask the provider how it will confirm its approach with the BCL and CSSF, and when. The procurement must meet the authority's requirements, and the entity signs and owns the contracts. Neither the BCL nor the CSSF approves providers through this process unless the authority says so in writing, so do not accept a provider's claim of endorsement. Send questions to tiber@bcl.lu or tiber@cssf.lu.
Questions Luxembourg entities ask before a TIBER-LU test
What does a TIBER-LU test cost, and what drives the price?
A TIBER-LU test has no published price, and the cost depends on the written scope. The main components are the threat intelligence provider, the red team testers, the internal effort of your control team and blue team, and any remediation work that follows. Providers are procured by the entity under the framework's procurement guidance, so each cost line is paid to a party you contract with directly. Costs rise with the number of critical or important functions in scope, the number of jurisdictions involved and the depth of the purple teaming and reporting. Ask every bidder for a written quote that separates threat intelligence, red teaming, reporting and internal staff time, and that states which deliverables each line covers.
How long does a TIBER-LU test take from start to finish?
The preparation phase lasts up to six months from the authority's written notification. Active red team testing runs for at least 12 weeks against the flags set under the control team's supervision. Reports, replay and purple teaming must be completed within 10 weeks of the end of active testing. The remediation plan is due within 8 weeks of the authority's assessment. Add the time for threat intelligence work and provider procurement, which sit inside the preparation and testing phases, and plan for the test to span many months overall.
Can our team run a TIBER-LU test without outside help?
Your organization must own the test. That means the control team, the decisions on scope and risk management, the contracts with providers, the blue team's detection and response work, and the remediation plan. The framework requires external threat intelligence and red team providers, so an in-house team cannot replace them. An implementation partner can help prepare your systems, logging and evidence, support the control team's documentation and coordinate deliverables, but it cannot act as the tester in the independent roles the framework requires. Confirm with the BCL and CSSF which parts of the process you must perform yourself before you scope any outside help.
Does a voluntary TIBER-LU test count as DORA TLPT?
A test completed under TIBER-LU can satisfy DORA threat-led penetration testing only if it also meets the formal requirements set by your competent authority. The ECB states that the core requirements of DORA TLPT and TIBER-EU are identical, so the process and technical standards carry over. Whether your entity is designated for mandatory testing, and which authority applies the formal requirements, depends on your supervisory status. Ask the BCL and the CSSF in writing how a voluntary test is treated for your entity before you commit budget.
Who should we contact at the BCL and the CSSF about TIBER-LU?
The central bank and the supervisor both run the programme and use separate mailboxes. Write to tiber@bcl.lu for questions addressed to the Banque centrale du Luxembourg and to tiber@cssf.lu for questions addressed to the Commission de Surveillance du Secteur Financier. Include your entity name, your supervisory status and the question in the first message so the right team can respond. Check the TIBER-LU page of the BCL for the current programme material before you write.
What does a TIBER-LU test ask of our staff day to day?
Staff are needed across five roles: the control team, the blue team, the people who supply the scope and critical functions, the contract and procurement owners, and the people who own remediation. The control team, which replaced the White Team under the 2025 framework, coordinates the test and holds confidential information about it, so its members must be trusted with that access. Blue team members will handle detection and response during active testing, often without knowing when red team activity happens. Plan for steady time from security operations, IT owners of the in-scope systems, risk and compliance staff who approve the scope, and senior management who sign off decisions.
Can an implementation partner issue the TIBER-LU attestation?
No. An implementation partner prepares systems, evidence and documentation, but it does not issue attestations, reports or certificates. The attestation is the closing deliverable of the process that the authority runs, and it reflects the authority's assessment of the test, not a statement from a vendor or consultant. Keep your partner's role in writing in the engagement scope, and ask the BCL and CSSF to confirm which documents they expect from each party at closure.
How DeployOpen prepares systems and evidence for a TIBER-LU test
DeployOpen does not run TIBER-LU tests or decide outcomes; the BCL and CSSF and their TIBER Cyber Team do. We prepare the self-hosted open-source systems, controls and documentation that a tested entity needs so that its preparation and closure work is organized and traceable. Every engagement starts from a written, fixed scope.
How we scope
- We agree a written, fixed scope covering the systems, functions and flags the entity has identified for its TIBER-LU preparation.
- We map which self-hosted platforms, logs and control records must be available for the control team and the blue team.
- We confirm with the entity which documents it must obtain from the BCL or CSSF before work starts, such as the notification and initiation material.
How we build
- We deploy and harden self-hosted open-source platforms inside the entity's own infrastructure, so data stays under its control.
- We configure logging, monitoring and alerting so detection and response activity during active red team testing can be reconstructed afterwards.
- We set up the records the control team needs for risk management and oversight, and check that they are complete before the testing phase begins.
How we hand over
- We deliver the technical documentation, configuration baselines and evidence packs in the form agreed in the scope document.
- We walk the entity's control team and blue team through the platforms, runbooks and evidence locations so staff can answer questions during the test.
- We prepare handover material for the closure phase, including inputs for the blue team report and the remediation plan, while the entity and its provider own those deliverables.
How we support
- We can support remediation work on the systems identified during the test, under the same written scope.
- Ongoing support, upgrades and continuous testing are available as retainers for entities that want continuity beyond a single test cycle.
- Before engaging, ask the BCL and CSSF which TIBER-LU guidance documents apply to your entity, and confirm your scope with them and your procurement team.
