How TIBER-DK works for a Danish financial entity facing a DORA threat-led test
If your organization is a Danish financial entity and has been told, or suspects, that it must run threat-led testing, start with one fact: Danmarks Nationalbank has run TIBER-DK since its introduction in December 2018, with tests beginning in January 2019, and a TIBER-DK test counts as a DORA TLPT because the programme incorporates the DORA requirements. The central bank is the TLPT authority in Denmark, so it is the body that identifies which entities must test. Whether you are on that list, how often you must test and how large the engagement becomes depend on that identification, your risk profile, the ICT systems in scope and the providers you rely on. Confirm your status with Danmarks Nationalbank before you budget or select providers, because a voluntary test and a mandatory DORA TLPT are not interchangeable in cost or in obligation.
Your organization owns its controls and its remediation. Danmarks Nationalbank and the TIBER-DK team coordinate and run the test process, and the independent threat intelligence provider and red team testers carry out the technical work. What gives the test its weight is the process output, including the reports and attestation produced under the framework, not any single tool or vendor. DeployOpen can prepare the systems, logging, documentation and evidence your team will need when the testers and the authority ask for it, and can support the control team in working through the process. It does not issue reports, attestations or certifications, and it is not the tester or the authority. Ask early whether your testers must be external and how the control team will be staffed, since those decisions shape the scope.
Plan around the 3-year interval, which the DORA framework sets as the minimum for identified entities. The competent authority can ask for more or less frequent testing based on your entity's risk profile, so treat three years as the baseline rather than a guarantee. Ask Danmarks Nationalbank in writing which systems, functions and providers it expects in scope, when the next test is due and what it requires from you before procurement starts. Under the framework, TIBER-EU tests produce no pass or fail result, so use the findings to raise your cyber maturity, and keep the evidence of how you acted on them. The TIBER-DK and TLPT overview on the central bank's site is the right next read for the current process and contacts.
How a TIBER-DK test moves from notification to attestation
The sequence runs in three TIBER-EU phases, preparation, testing and closure, and ends with an attestation that shows the test was carried out to the framework's mandatory requirements. Each phase closes with a defined output that the next phase depends on. Confirm the exact sequence against Danmarks Nationalbank's published test process overview before planning.
Receive written notification from Danmarks Nationalbank
The test begins when Danmarks Nationalbank, acting as the TIBER-DK authority, notifies the entity in writing that a threat-led test is required or proposed. The notification starts the preparation phase, which lasts up to six months from that written notice. The entity confirms receipt and names its internal contact, so the authority knows who will run the test on its side. The step is complete when the notification is on file and the entity has its own point of contact for the programme.
Initiate the test and set up the control team
During initiation, the entity and the authority agree the test's governance, and the entity appoints a control team to oversee the test internally and manage its risk. The control team holds the knowledge of the test and sits between the testers and the blue team, so the blue team does not know it is being tested. The output is an initiation document and a documented risk management approach that the authority reviews. The step closes when both are agreed.
Scope critical functions and flags
The entity identifies its critical or important functions and the live production systems that support them, and turns them into flags, the targets the red team will try to reach. The scope specification document records which functions, systems and third parties are in scope and any exclusions, with the reasons. Danmarks Nationalbank and the test manager review the draft before it is accepted. The step is complete when the scope specification document is signed off by the authority.
Procure threat intelligence and red team providers
The entity procures a threat intelligence provider and red team testers that meet the requirements the authority sets, under the procurement guidance TIBER-EU publishes. The entity must confirm each provider's independence, qualifications and handling of sensitive data before contracting. The preparation phase ends with both providers under contract and the test ready to enter the testing phase. Ask Danmarks Nationalbank which provider events and criteria apply in Denmark before selecting firms.
Produce the targeted threat intelligence report
The threat intelligence provider analyzes threats relevant to the entity, selects realistic attack scenarios and documents them in a targeted threat intelligence report. The control team and test manager check the report against the scope and the flags before any red team work starts. The output is an approved report that defines the scenarios the red team will use. The testing phase begins only after this approval.
Run the red team test against the flags
The red team writes its test plan, which the control team and test manager review, and then carries out active testing for at least 12 weeks against the flags. The blue team defends without knowing the test is under way, and the control team keeps the test within the agreed boundaries. Testers produce a red team test report as the testing phase closes. The step is complete when active testing ends and the report is submitted.
Complete reports, replay and purple teaming
The blue team writes its own test report, and the red and blue team reports are followed by a replay in which both teams walk through the attack step by step. Purple teaming follows, where the teams work together on detection and response improvements. These activities are due within 10 weeks of the end of active testing. The step is complete when the replay and purple teaming sessions are recorded.
Issue the summary, remediation plan and attestation
The 360 degree feedback is gathered, and the test summary report is written, followed by a remediation plan that sets out how the entity will act on the findings. The remediation plan is due within 8 weeks of the authority's assessment. The attestation is issued last and confirms the test was carried out to the framework's mandatory requirements. Confirm the attestation wording and recipients with Danmarks Nationalbank before the closure phase begins.
Implementation documents and provider events to check before procurement
Danmarks Nationalbank publishes the TIBER-DK documents and runs events for providers, so these are the first sources to read before scope or tender terms are drafted. The cards below cover what each source sets out and what to confirm with the central bank.
TIBER-DK implementation document
This document describes the programme and the test process that Danmarks Nationalbank runs in Denmark. Read it before drafting scope or tender terms, because it sets out the roles, the phases and the obligations that a TIBER-DK test must meet. Check how it treats the DORA TLPT requirements, since a TIBER-DK test is counted as a DORA TLPT. Note any Danish-specific elements that go beyond the common framework.
Test process overview
The test process overview gives a step-by-step view of how a TIBER-DK test moves from notification through preparation, testing and closure. Use it to build your internal timeline and to check which deliverables fall to the entity, the threat intelligence provider and the red team testers. Confirm with the central bank which milestones it reviews and how it signs off on each one before you fix contract dates.
Threat intelligence provider events
Danmarks Nationalbank runs events for threat intelligence providers who may be procured for a TIBER-DK test. Attending or reviewing the material helps a provider understand the deliverables expected of the targeted threat intelligence report and the scenario selection. Ask the central bank whether the event material is open to providers you are considering, and whether attendance is a condition for taking part.
Red team tester events
Separate events are run for red team testers, covering the standards that red team test plans and reports must meet. Check the current event schedule with Danmarks Nationalbank rather than relying on older listings. Confirm whether the central bank expects testers to have attended before they are named in procurement, and what evidence it wants of that.
Questions for the central bank
Use TIBER-DK@nationalbanken.dk for questions about the status of a test, the process, or which document applies to your case. Send questions in writing so the answers can be kept with the contract file. Ask how the programme handles changes to the process and which version of the documents governs a test already in progress.
What a TIBER-DK test costs in money and staff time
The largest external outlay in a TIBER-DK test usually goes to the threat intelligence provider and the red team testers. Under the TIBER-EU process, the entity procures both itself, and the framework's preparation phase covers that procurement. Because the testers work for a sustained period of active testing, their fees track the scope agreed for the test rather than a standard product price.
- Threat intelligence provider: Covers the targeted threat intelligence report and scenario selection that shape the rest of the test.
- Red team testers: Cover the red team test plan, active testing and the red team test report.
- Service provider procurement: Some of the cost sits in the procurement work itself, including preparing requirements and evaluating bids.
- Scope drivers: The number of flags, the size of the systems in scope and the length of active testing move the fee more than any other factor.
- Recurrence: These costs fall per test. Under DORA the interval is at least every 3 years, so budget them as a recurring cycle.
Ask each provider for a written, scope-based quote that separates threat intelligence, testing and reporting, so you can compare bids on the same basis.
Internal staff time is often the cost that is least visible in a budget. The control team and blue team are drawn from the entity's own people, and they carry the test alongside their normal duties. The control team oversees the test and manages the flags, while the blue team defends and responds as it would to a real attack. Both teams also take part in closure work such as the blue team test report, replay, purple teaming and the 360 degree feedback.
- Control team: Supervises active testing, handles risk management and coordinates with the authority and the providers.
- Blue team: Monitors, detects and responds during testing, then contributes to the blue team report and replay.
- Management and approvals: Senior sign-off on scope, risk acceptance and the remediation plan.
- Remediation work: Fixing the weaknesses found is an internal cost that can exceed the test itself.
- Recurrence: Staff time recurs with each test cycle, and the remediation effort may continue well after closure.
Estimate the hours with your control team lead before the preparation phase begins, and confirm how much of that time your staff can give without displacing other work.
Some entities bring in an implementation partner to prepare systems, controls and evidence before and after the test. This work is optional and sits outside the core test roles. DeployOpen, for example, prepares systems and evidence inside the client's own infrastructure, but it does not act as the threat intelligence provider or red team tester, and it does not issue the attestation or any report of assurance.
- Readiness work: Preparing logging, monitoring and detection coverage so the blue team can be assessed fairly.
- Evidence preparation: Organizing documents for the control team, the scope specification and the remediation plan.
- Remediation support: Implementing fixes identified in the test summary report.
- Independence: A partner that helps prepare systems should not also be the tester, which may affect your procurement rules.
- Recurrence: Usually project-based, with optional retainers for ongoing support, upgrades and continuous testing.
When you request a quote, ask for a fixed scope with written deliverables and confirm that the partner's role does not overlap with the testing providers.
Danmarks Nationalbank coordinates and is responsible for the TIBER-DK programme and acts as the TLPT authority that identifies entities required to test. Its role in running the programme is central, but this page does not establish any fee for the authority's participation. Whether the central bank charges an entity for its oversight of a test is a question for the authority itself, and you should not assume either way until you have a written answer.
- Coordination role: The authority coordinates the test and facilitates the process, which shapes the time your teams spend with it.
- Identification: Entities identified as required to test should confirm the obligations that come with that status.
- Fee confirmation: Ask Danmarks Nationalbank directly whether any fee applies to your test and how it is invoiced.
- Documents and events: Implementation documents, the test process overview and provider events are published without a cost stated on the source material.
- Recurrence: Any fee that applies would need to be confirmed for each test cycle.
Before you commit a budget, write to TIBER-DK@nationalbanken.dk and request the current position on fees, invoicing and expected staff involvement.
What makes a TIBER-DK test larger, longer or more expensive
A TIBER-DK test is scoped around the critical or important functions an entity runs, the systems behind them and the third parties that support them. The cards below cover the drivers that widen that scope, and the preparation that keeps the test contained.
Critical or important functions and flags
The number of critical or important functions in scope and the flags attached to them set the attack surface the red team must test. Each additional function usually adds threat intelligence work, planning and reporting. Ask Danmarks Nationalbank and your team to agree the function list and flags in writing before procurement, so that the scope is fixed before providers are priced.
Systems and locations in scope
The number of production systems, data centers, cloud regions and branches that touch an in-scope function changes how much ground the red team must cover. Each added location can require separate access arrangements and more time to test. Keep a current inventory that maps each flag to its hosts, sites and accounts so that scoping discussions start from facts.
Third-party ICT providers in scope
When a flag depends on an ICT provider, the test may need that provider's consent, contract terms and participation in planning. Shared hosting, managed services and outsourced operations add coordination steps and legal review. Identify each provider and its contractual position early, because a late objection can stop or redesign part of the test.
Evidence maturity and documentation
Teams that can produce current architecture diagrams, configuration baselines, logging coverage and incident records give the control team and assessors less to reconstruct. Gaps in these records tend to extend preparation and the time spent answering questions during testing. Review your evidence set against the scope before notification, and record which items are missing.
Risk profile and test frequency
The entity's risk profile is the input Danmarks Nationalbank uses to decide whether a test is needed and how often it recurs. DORA sets a baseline of at least every 3 years for identified entities, but the authority may ask for more or less frequent testing based on risk. Ask the authority how your profile was assessed and what changes would alter the cycle.
Questions Danish entities ask about TIBER-DK and DORA TLPT
Does a TIBER-DK test count as DORA threat-led penetration testing?
Yes. Danmarks Nationalbank states that TIBER-DK incorporates the DORA TLPT requirements, so a TIBER-DK test counts as a DORA TLPT. The programme has run since 2019 for financial-sector entities, and the central bank coordinates it and is responsible for it. The practical point for your team is that the test has to follow the programme's process and mandatory requirements, not just a generic red team exercise. Confirm the current requirements in the TIBER-DK and TLPT guidance before you plan.
Who decides whether our entity must run a TLPT in Denmark?
Danmarks Nationalbank is the TLPT authority in Denmark and identifies the entities that are required to test. Being identified is an authority decision, not a self-assessment, so the first step is to confirm your status with the central bank rather than assume it. If you receive a notification, the preparation phase of the framework follows. Questions about your status should go to TIBER-DK@nationalbanken.dk, and you should ask the authority which entities and functions it expects to be in scope.
How often does a Danish entity have to run a threat-led test?
DORA requires financial entities identified by their competent authority to carry out TLPT at least every three years. The authority may ask for testing that is more or less frequent based on the entity's risk profile, so the three-year interval is a ceiling for the baseline rather than a fixed schedule for every firm. Ask Danmarks Nationalbank for the cycle that applies to your entity, and plan budget and staffing for each test in that cycle, not only the first one.
Can our own security team run a TIBER-DK test internally?
The TIBER-EU framework requires that the threat intelligence provider and the red team testers be external to the tested entity, so internal staff cannot fill those roles. Your internal team does take part as the control team and blue team, which supervise the test and respond to it. Confirm the exact provider rules in the TIBER-DK implementation document, because the programme's own requirements govern your test. An implementation partner such as DeployOpen can prepare your systems, controls and evidence for the test, but it does not act as the external red team.
What does the work need from our team during a TIBER-DK test?
A TIBER-EU test has five parties: the authority's TIBER Cyber Team and test manager, your control team, your blue team, the threat intelligence provider and the red team testers. Your side needs a control team that can manage the test, keep the scope and risk controls under review, and coordinate with the authority. The blue team needs time to detect and respond to the test without being told the scenario in advance. Plan for staff time across preparation, the active testing period and the closure phase, which includes reports, replay, purple teaming and remediation planning.
Does a voluntary TIBER-DK test count as a mandatory DORA TLPT?
A voluntary test is useful for learning, but it does not automatically satisfy a DORA TLPT requirement. TIBER-DK tests that the authority requires under DORA are the ones that count for the mandatory obligation, and those are identified by Danmarks Nationalbank. If you are not identified but want to test voluntarily, ask the authority in writing how the result will be treated and whether it can later be used toward a mandatory cycle. Do not assume the two categories are interchangeable.
Does mutual recognition apply if we operate in other EU countries?
Mutual recognition applies among authorities that have adopted TIBER-EU and that meet its mandatory requirements. A test that complies with those requirements can spare an entity operating in several jurisdictions from duplicate tests, but the recognition depends on the authorities involved and on the scope agreed for each test. Check with Danmarks Nationalbank and with each other authority that regulates your group, and ask for written confirmation of which tests will be accepted. The TIBER-EU framework page is the natural starting point for the common rules.
How DeployOpen prepares systems and evidence for a TIBER-DK test
DeployOpen works on TIBER-DK as an implementation partner. We prepare the systems, controls and evidence that an organization brings to its TIBER-DK test, while Danmarks Nationalbank runs the programme and the organization owns its controls. We do not run the test or issue its reports.
How we scope
- Agree a written, fixed scope covering the systems, environments and functions the organization wants prepared before the test begins.
- Map which self-hosted open-source platforms are in scope and record where each one runs inside the organization's own infrastructure.
- Confirm with the organization which parts of its preparation fall to DeployOpen and which remain with internal teams and the authority.
How we build
- Plan and deploy self-hosted open-source platforms inside the client's cloud accounts, data centers or air-gapped networks.
- Configure logging, access control and monitoring so that detection and response activity can be reconstructed afterwards.
- Harden and document each component, then keep backup and upgrade records that an assessor can review during the test.
How we hand over
- Deliver configuration baselines, architecture diagrams and control documentation for the in-scope systems and processes.
- Produce evidence packs that map each system to the controls the organization reports against, ready for the test team to review.
- Hand over runbooks and ownership records so the organization can operate and explain its environment after the engagement ends.
How we support
- Ongoing support, upgrades and continuous security testing are available as retainers after the fixed-scope engagement closes.
- Confirm with DeployOpen in writing which support and retesting activities are included before work starts.
- Ask Danmarks Nationalbank through TIBER-DK@nationalbanken.dk about its current requirements for the test and any remediation follow-up.
Sources and further reading
- TIBER-DK/TLPT threat-based red team tests, Danmarks Nationalbank ↗
- TIBER-EU Framework (January 2025), ECB ↗
- TIBER-EU framework, European Central Bank ↗
- Adopting TIBER-EU will help fulfil DORA requirements (September 2024), ECB ↗
- Regulation (EU) 2022/2554 (DORA), EUR-Lex ↗
- Commission Delegated Regulation (EU) 2025/1190 (TLPT RTS), EUR-Lex ↗
