I spoke this year with three CEOs of financial institutions. Each of them, at the moment DORA entered into force — 17 January 2025 — asked me the same question: “I’ve heard about TLPT, but what exactly is it and does it apply to us?” The answer to that question has concrete financial, operational and reputational consequences. Getting your own status wrong costs money — both when an institution fails to carry out a required test and when it commissions one from an unqualified provider.
Threat-Led Penetration Testing (TLPT) is one of the most demanding and, at the same time, one of the most valuable tools that DORA introduces into the arsenal of digital resilience management. Unlike traditional penetration testing, a TLPT exercise is an advanced, multi-month intelligence and technical operation that simulates the activity of real APT (Advanced Persistent Threat) groups specifically targeting your institution. What is at stake is whether your defensive systems — people, processes, technology — are capable of detecting and stopping attackers before they cause real harm.
This article is a practical guide for CISOs, Chief Risk Officers and Boards of Directors of financial institutions. We explain what TLPT is, who it applies to, how it works and what it costs — and, most importantly, how to prepare for it effectively. After nearly a year of DORA being in force, we can see clearly which institutions have approached this topic strategically and which still treat TLPT as a distant regulatory problem. The difference in readiness is enormous — and increasingly visible to supervisory authorities.
What Is TLPT and How Does It Differ from a Standard Penetration Test?
Threat-Led Penetration Testing (TLPT) is a specific class of security testing in which attack scenarios are not defined by the testers themselves, but by current, personalised threat intelligence analysis. In other words, before anyone touches your technical systems, several weeks are spent gathering and analysing intelligence about which cybercriminal groups actually attack institutions of your type, what tactics, techniques and procedures (TTPs) they use, and which of your assets would be most attractive to them.
A standard penetration test is primarily a technical verification exercise: the tester reviews vulnerabilities, attempts to exploit them and reports the findings. This is a valuable exercise, but it has limited applicability to assessing resilience against advanced, targeted attacks. A modern penetration test checks whether you have unpatched software or misconfigured services. A TLPT checks whether you can survive an attack by an APT group that systematically penetrates your defences over three months before anyone in your organisation realises they are being watched.
There are four key differences. First, scope: TLPT covers the production environment and real critical functions of the institution, not test environments. Second, methodology: the test is based on a current, personalised threat intelligence report prepared by a specialist Threat Intelligence (TI) Provider. Third, duration: a full TLPT cycle lasts between 3 and 12 months, whereas a typical penetration test concludes within weeks. Fourth, supervision: the test is conducted under the oversight of the regulatory authority (the KNF in Poland) and may be recognised by other competent EU authorities through the mutual recognition mechanism.
It is worth emphasising that TLPT does not replace the regular penetration tests required by DORA for all financial entities. Article 25 of DORA imposes on all institutions an obligation to run a testing programme that includes, among other things, vulnerability assessments, open-source tests and network security evaluations. TLPT under Article 26 is the highest and most demanding level of this testing pyramid — reserved for institutions of the greatest systemic importance.
📚 Read the complete guide: Penetration Testing: Penetration testing — types, methodologies, process
📚 Read the complete guide: DORA: DORA - rozporządzenie o cyfrowej odporności operacyjnej dla sektora finansowego
Which Financial Institutions Are Required to Conduct TLPT?
DORA does not impose an obligation to conduct TLPT on all entities covered by the regulation. This is a crucial distinction that many institutions interpret incorrectly. Article 26 of DORA indicates that TLPT is required for significant financial entities — but what exactly that means depends on the decision of the competent supervisory authority of each member state.
The competent authority (in Poland: the KNF) has the right to designate which institutions are subject to the TLPT obligation, taking into account three criteria: the ICT maturity of the institution, its importance for the financial stability of the system, and its cyber risk profile. In practice, this means that TLPT will be mandatory primarily for large banks and insurers, operators of payment systems of key systemic importance, the largest investment firms, providers of critical infrastructure for the financial sector, and other entities that the KNF considers significant from the perspective of systemic risk.
The European Commission’s delegated regulation on TLPT (the RTS on TLPT) specifies the detailed eligibility criteria. Institutions are assessed with regard to their systemic importance for financial stability, the complexity of their ICT infrastructure, their incident history and threat profile, and their organisational readiness to carry out and manage a test of this scale. The supervisory authority may engage in dialogue with an institution before formally designating it for TLPT — and it is worth actively participating in that dialogue.
Even if your institution is not today designated as subject to the TLPT obligation, it is worth familiarising yourself with this requirement for two reasons. The first is a matter of the future: the KNF may expand the list of obligated entities as market maturity grows. The second is a matter of voluntary action and value: TLPT is simply one of the most effective resilience exercises that can be conducted — and many institutions carry it out on their own initiative, even without a regulatory mandate.
Institutions designated by the competent authority are required to conduct TLPT at least once every three years. The results of the test, together with the remediation plan, must be submitted to the supervisory authority. Importantly, the competent authority may request that a TLPT be conducted outside the regular schedule — for example, following a serious cyber incident.
What Is the TIBER-EU Framework on Which TLPT under DORA Is Based?
TIBER-EU (Threat Intelligence-Based Ethical Red Teaming for the European Union) is a framework developed by the European Central Bank in cooperation with national central banks, on which the TLPT methodology described in DORA is fully based. Understanding the structure of TIBER-EU is essential for any institution preparing for the test.
The TIBER-EU framework divides the test into three main phases. The first phase is preparation: it involves engaging the supervisory authority or central bank, establishing the White Team inside the institution (which manages the test and communicates with external providers), and selecting and contracting the providers — both the Threat Intelligence Provider (TIBER Threat Intelligence Provider) and the external Red Team. This phase concludes with the formal launch of the test and the signing of agreements covering scope and liability.
The second phase is testing: first, the TI provider conducts a targeted intelligence analysis and delivers the Targeted Threat Intelligence Report (TTIR) — a document that describes in detail which APT groups pose a real threat to the given institution and what TTPs they use. Based on the TTIR, the Red Team develops attack scenarios that it then executes in the production environment. The Red Team acts like a real adversary — silently, persistently, methodically.
The third phase is closure: this covers the formal debriefing (so-called purple teaming), in which the Red Team and the institution’s Blue Team jointly analyse the course of the operation, sharing knowledge and experience, drafting the final report and remediation plan, and subsequently submitting the report to the competent supervisory authority. Importantly, if the test was conducted in full compliance with TIBER-EU, it may be mutually recognised by the competent authorities of other EU member states — which is of enormous importance for financial groups operating across multiple countries.
The TIBER-EU framework is today implemented or being implemented in over twenty European countries, including Poland (TIBER-PL, coordinated by the NBP). This wide adoption means that the TIBER-EU provider market is maturing, regulatory competencies are growing, and the mutual recognition mechanism for test results is becoming increasingly operational. For Polish financial institutions of a cross-border nature, this is a concrete benefit: a test conducted once — recognised multiple times.
How to Select a TLPT Provider — Competency Requirements
Selecting the right provider is one of the most important decisions in the entire TLPT process, and simultaneously one of the areas where institutions make the biggest mistakes. DORA and the TIBER-EU framework set specific, high competency requirements for providers — and not every firm offering “penetration tests” or “red teaming” meets them.
With regard to the Threat Intelligence Provider, the requirements include: documented experience in APT analysis targeting the financial sector, the capability to conduct targeted Open Source Intelligence (OSINT), Dark Web Intelligence and Human Intelligence (HUMINT) analysis, the ability to deliver a formal TTIR report consistent with TIBER-EU methodology, and operational confidentiality — the TI provider must not have access to knowledge of the scope of the test to be conducted by the Red Team.
With regard to the Red Team provider, the requirements include: demonstrated experience in advanced, long-duration red team operations (a minimum of several dozen operations in production environments), the capability to execute the full MITRE ATT&CK kill chain (from reconnaissance through to exfiltration), sector-specific experience in the financial domain (SWIFT systems, payment systems, core banking systems), documented operational security (OPSEC) processes that eliminate the risk of accidentally disrupting production, and certifications and experience at the level of CREST STAR or equivalent.
It is also worth paying attention to the aspect of independence: the Red Team provider must not be the same firm that conducts your institution’s regular security audits or provides managed security services (MSSP). A lack of independence undermines the credibility of the results and may be challenged by the supervisory authority. Before signing a contract with a provider, it is worth checking whether the competent authority (KNF) maintains a register or publishes guidelines on qualified TIBER-EU/TLPT providers — practices vary from country to country.
A good practice is to run a Request for Proposal (RFP) process involving at least three providers, evaluating proposals not only on price but primarily on depth of understanding of your sector, quality of references from comparable projects, and the maturity of OPSEC processes. References from other financial institutions are invaluable here — ask the market before you sign a contract. A poor TLPT provider selection decision means losing several months and several hundred thousand zloty with no meaningful results.
How Does a TLPT Exercise Progress from Preparation to Report?
A full TLPT cycle is a complex operation, and understanding it allows you to manage the project far more effectively and avoid common pitfalls. Below we describe each stage in operational terms — as they actually appear from the perspective of a financial institution.
Stage 1: Preparatory phase (4–8 weeks). The institution establishes the White Team, composed of internal experts — typically the CISO, the ICT Risk Director and a designated legal counsel. The White Team is the only group inside the organisation that knows the test is being conducted — the Blue Team (the SOC security team) must operate without this knowledge, because only then does the test have measurement value. The institution formalises the scope, defines the Critical Functions and Critical Assets to be covered by the test, and enters into contracts with both providers.
Stage 2: Intelligence and scenario development phase (6–10 weeks). The TI provider conducts targeted analysis and delivers the TTIR report. This document is classified and provided exclusively to the Red Team — not to the institution’s White Team. Based on the TTIR, the Red Team develops 2–3 realistic attack scenarios (Generic Threat Scenarios tailored to the institution’s specifics) and presents them to the White Team for formal scope approval.
Stage 3: Testing phase (8–16 weeks). The Red Team carries out the simulated attack operation. This phase covers reconnaissance and information gathering (passive and active reconnaissance), attempts to achieve initial access using various techniques — including spear phishing, attacks on web applications and vulnerability exploitation — lateral movement within the network, privilege escalation, reaching the defined Critical Assets, and documented simulation of exfiltration or disruption. The Red Team documents every step of the operation with the precision required for the subsequent formal report.
Stage 4: Closure and Purple Teaming (2–4 weeks). Upon completion of the testing phase, a formal disclosure takes place: the Blue Team learns the facts of the operation. The so-called Purple Teaming then follows — a joint analysis by the Red Team and the Blue Team, in which every attacker action and defender response (or absence thereof) is discussed. The result is a precise map of what worked, what did not, which detection gaps need to be addressed, and which countermeasures must be implemented. The final report is submitted to the supervisory authority.
The value of Purple Teaming is often underestimated by institutions undertaking TLPT for the first time. It is precisely in this phase that the greatest amount of operational knowledge is generated: the Blue Team discovers which attack techniques were invisible to them, which alerts were triggered but ignored, and which detection gaps require urgent remediation. This knowledge translates directly into a concrete improvement plan for the SOC — and it is precisely why many institutions, after their first TLPT, significantly increase their investment in threat detection.
How Does Threat Intelligence Feed TLPT Scenarios?
Threat intelligence is the heart of the entire TLPT process — and this is precisely where the fundamental advantage of this methodology over traditional penetration testing lies. Understanding how TI is collected and used allows you to better evaluate the quality of a potential provider and the value of the entire exercise.
Targeted intelligence analysis for a specific financial institution covers several layers. OSINT (Open Source Intelligence) involves analysing public sources: your institution’s job postings (which reveal the technologies in use), data and credential leaks on services such as Have I Been Pwned, employee activity on social media, and historical incident data reported by similar institutions. Dark Web Intelligence covers monitoring criminal forums for discussions about your institution, sales of access to your systems, hired attack listings and stolen data.
APT group TTP analysis is the most valuable element of the TTIR report. The TI provider identifies which APT groups are actively attacking the financial sector in your jurisdiction or similar institutions worldwide, and maps their techniques to the MITRE ATT&CK framework. For a financial institution in Poland, this will mean analysing groups such as Lazarus Group (targeting SWIFT systems), FIN7, Carbanak and other groups focused on the banking sector. The analysis covers not only historical TTPs but also current campaigns — which means the TTIR report has a short “shelf life” and should be prepared immediately before the testing phase begins.
The final TTIR report is not a general trend analysis that can be purchased from a threat intelligence provider as a subscription. It is a personalised document that describes what genuinely threatens a specific institution, taking into account its technological infrastructure, employee profile, supplier relationships and specific threat exposure. Based on this report, the Red Team selects the techniques, tools and procedures that reflect the behaviour of real adversaries — not hypothetical attackers drawn from a generic scenario.
It is also worth noting the role of the Threat Intelligence Sharing envisaged by DORA: Article 45 of the regulation encourages financial institutions to voluntarily exchange threat information within trusted communities. Institutions that actively participate in such platforms (e.g. FS-ISAC) have access to better, more current TI — which directly improves the quality of TLPT scenarios and the overall effectiveness of the threat management programme.
📚 Read more about threats in the financial sector: Anatomy of a cyberattack on banking — from phishing to advanced frauds
How to Manage Risk During a Test Conducted in a Production Environment?
This is the question I hear from every CISO before their first TLPT: “What happens if the Red Team breaks something? Who is responsible for any downtime?” Conducting an advanced test in the production environment of a financial institution is undoubtedly a heightened-risk operation — but a manageable one, provided we prepare for it properly.
The first and most important element of risk management is a precise definition of scope and boundaries. The contract with the Red Team must contain an unambiguous description of which systems are in scope, which are out of scope (e.g. life-safety systems, critical payment systems during peak transaction hours), which actions the Red Team may take autonomously and which require prior notification of the White Team, and what the conditions are for immediately halting the operation (the so-called kill switch). The White Team must be able to stop the test at any moment without giving reasons to the Red Team.
Red Team OPSEC — meaning rigorous operational security procedures that minimise the risk of unintended side effects — is of critical importance. A professional Red Team does not use tools that could cause system instability, adjusts the intensity of its activities to the institution’s operational hours (avoiding actions during peak transaction hours), documents every action in real time, and maintains rollback procedures for every step that could cause a permanent change in the production system.
It is also advisable to engage the legal and insurance departments before the test starts. The contracts with providers must clearly regulate the allocation of liability. The institution must ensure that its existing insurance policies (cyber insurance) do not contain clauses excluding events arising from authorised penetration tests. Notifying the insurer about the planned TLPT is good practice — most cyber sector insurers actively support such activities as an element of risk management.
An important aspect of risk management is also controlling who within the organisation knows about the test. Too many people knowing about the TLPT creates a risk of information leaking to the Blue Team, which would distort the test results. Conversely, too few people involved on the White Team side can lead to a situation where the test touches a system outside the agreed scope or triggers an excessive operational response (e.g. the SOC cutting the network because it does not know that Red Team activity is authorised). The good rule is: minimum knowledge, maximum control — and careful calibration of the scenario for “what do we do if the Blue Team detects the Red Team and starts responding”.
How Much Does TLPT Cost and How to Plan the Budget?
This is the question that often begins the conversation with the board. The short answer is: TLPT is expensive. But the more complete answer is: TLPT is expensive relative to typical penetration testing, but cheap compared to the cost of the incident it might detect. I spoke with the chief operating officer of one Polish bank who compared these figures and stated plainly: “If TLPT costs us 400,000 zloty, and a potential incident — taking into account downtime, regulatory fines and reputational costs — could cost 40 million, then it is the cheapest insurance policy I have bought this year.”
TLPT costs are complex and comprise several components. TI provider cost (Threat Intelligence Provider): preparing the TTIR report typically costs between 30,000 and 80,000 EUR, depending on the depth of analysis and the size of the institution. Red Team cost: an advanced red team operation lasting 8–16 weeks, carried out by an experienced multi-person team, costs in the range of 100,000–350,000 EUR for a mid-sized institution, while for the largest players the figure can reach 500,000 EUR or more. Internal costs: the time spent by the White Team, legal counsel and consultants managing the project on the institution’s side represents an additional 50,000–150,000 PLN, assuming minimal engagement of external advisors.
Reporting and remediation costs: the final report and remediation plan are typically included in the Red Team price, but implementing the recommendations (remediation) is a separate project that can cost a further 100,000–500,000 PLN depending on the scope of the identified gaps. For institutions undertaking TLPT for the first time, remediation costs tend to be higher, because the test reveals more detection and procedural gaps.
Internal preparation costs are a category often overlooked in budgets. Before an institution is ready to conduct TLPT, it may be necessary to raise SOC maturity, implement or improve the SIEM/SOAR platform, build the capability to monitor east-west traffic within the internal network, and train the White Team in managing a TIBER-EU operation. Institutions that invest in these preparations before TLPT derive significantly greater value from the test — because they have appropriate detection tools that allow them to actually measure their ability to detect the Red Team.
When planning the budget, it is worth bearing in mind that TLPT must be conducted every 3 years — which means these expenditures must be planned in the multi-year cybersecurity budget. Good practice is to include TLPT in the multi-year security investment plan alongside other regular tests and audits, treating it as a recurring operational cost rather than a one-off project.
What Does the TLPT Preparation Timeline Look Like?
Preparing for TLPT takes not weeks but months of work. The table below shows a realistic preparation timeline for an institution planning to conduct its first TLPT.
| Stage | Duration | Key activities | Responsible |
|---|---|---|---|
| 1. Readiness assessment | 4–6 weeks | ICT maturity audit; verification of “significant entity” status; gap analysis against DORA Art. 26 | CISO + Chief Risk Officer |
| 2. Establishing the White Team | 1–2 weeks | Formal appointment of the White Team; defining roles; configuring communication channels | Board + CISO |
| 3. Defining scope | 3–4 weeks | Mapping Critical Functions and Critical Assets; consultations with the supervisory authority (KNF); formal scope approval | White Team + KNF |
| 4. Selecting and contracting providers | 6–10 weeks | RFP for TI Provider and Red Team; competency verification; due diligence; negotiations and contract signing | White Team + Legal Department |
| 5. Intelligence phase (TI) | 6–10 weeks | TI provider prepares the TTIR report; report delivered to the Red Team | TI Provider |
| 6. Scenario development | 2–3 weeks | Red Team develops Generic Threat Scenarios; White Team approves operational scope | Red Team + White Team |
| 7. Testing phase | 8–16 weeks | Red Team conducts the simulated attack operation in the production environment | Red Team |
| 8. Closure and Purple Teaming | 2–4 weeks | Disclosure; joint analysis; Purple Team workshops; drafting the final report | Red Team + Blue Team + White Team |
| 9. Remediation and reporting | 4–8 weeks | Implementing the remediation plan; preparing documentation for the KNF; formal test closure | CISO + White Team |
The total time from the decision to launch TLPT to the formal closure of the test is typically 12–18 months. Institutions formally designated for TLPT by the KNF should treat this timeline as a starting point and begin the readiness assessment and internal capability-building phases as quickly as possible.
It is particularly important not to defer the readiness assessment until the moment of receiving a formal designation. Institutions that proactively build internal knowledge of TIBER-EU, establish the nucleus of a White Team and complete a preliminary ICT maturity audit radically shorten the time required to complete the first two stages after formal designation. This is a real advantage — especially if the KNF sets a deadline for the first TLPT that is shorter than the standard 18 months.
How Does nFlo Deliver Tests Compliant with TIBER-EU and DORA?
nFlo is a cybersecurity company with documented experience in advanced red team testing and compliance programmes for the financial sector. We have completed over 500 security projects, serve over 200 clients from regulated industries and maintain a 98% client retention rate — which, in the security services industry, is an eloquent measure of quality and trust.
Our approach to TLPT for the financial sector rests on three pillars. The first is sector specialisation: our Red Team has deep experience in banking, payment and insurance system architectures — we understand how the systems we are testing work, which translates into precision and operational safety. The second is our own threat intelligence platform: we maintain internal TI resources and curated feeds specific to the financial sector, allowing us to deliver the full TIBER-EU cycle — from the TTIR report through to the final Purple Teaming — while maintaining the required separation of roles. The third is response time and operational support: in the event of an unplanned incident during the test, we can respond in under 15 minutes — which is critical when an operation is being conducted in a production environment.
Our TLPT services are designed as a programme, not a one-off project. We support financial institutions from the readiness assessment and KNF consultation stage, through the full execution of a TIBER-EU-compliant test, to the implementation of the remediation plan and preparing the organisation for the next TLPT cycle three years hence. We estimate that through our tests and recommendations, clients achieve an average 90% reduction in cyber risk in the areas covered by the tests — and that is the measure we hold ourselves to.
We also recognise that for many institutions the first step is not TLPT itself, but a readiness assessment for TLPT. We offer a dedicated pre-TLPT readiness assessment service that, within 4–6 weeks, gives the CISO and the board a reliable answer to the question: “Are we ready, and what do we need to do to become ready?” It is an investment that pays back many times over in a smoother main test and higher-quality results.
Related concepts
- Red Teaming — advanced security testing simulating real attackers
- Penetration testing — scope, methodologies and process
- DORA — financial sector requirements — a complete guide to the regulation
Learn more
- The DORA Regulation — essential information
- DORA compliance: the role of penetration testing and TLPT
- KSC/NIS2 and DORA — the financial sector
- KSC/NIS2 readiness audit — a guide for CISOs
Explore our services
If your financial institution is preparing for TLPT or you wish to assess your readiness against DORA’s digital resilience testing requirements, contact us. We will conduct a free initial consultation and evaluate the stage you are at on the road to TLPT.
FAQ — Frequently asked questions about TLPT and DORA
Is TLPT mandatory for all financial institutions covered by DORA?
No. TLPT applies exclusively to entities designated by the competent supervisory authority (in Poland: the KNF) as “significant”. Other institutions covered by DORA must conduct regular security tests (including penetration tests), but are not required to carry out a full TLPT in compliance with TIBER-EU methodology. It is, however, worth verifying your status directly with the KNF, as the list of obligated entities may be updated. Good practice is to engage in proactive dialogue with the supervisory authority even before formal designation — this allows you to plan your preparations better and avoid unpleasant surprises.
How long does a full TLPT cycle take from decision to test closure?
A realistic timeframe is 12–18 months from taking the decision to launch the process to the formal closure of the test and submission of the report to the supervisory authority. This time includes the preparatory phase, provider selection, the TI intelligence phase, the Red Team operation, Purple Teaming and implementation of the remediation plan. Institutions that have previously invested in building SOC maturity and internal knowledge of TIBER-EU may be able to reduce this to 10–12 months. It is not advisable to defer preparations until the moment of formal designation by the KNF.
Are the results of a TLPT conducted in one EU country recognised in another?
Yes — provided that the test was conducted in full compliance with TIBER-EU methodology and accepted by the relevant national competent authority. The mutual recognition mechanism for TLPT results is one of the key regulatory innovations of DORA and is of particular importance for financial groups operating across multiple countries of the European Union. The specific conditions for recognition are governed by the competent authorities of the countries involved. It is worth agreeing in advance with the supervisory authorities of all countries in which your group operates on the conditions for mutual recognition — before the test is conducted.
What happens if TLPT results reveal serious security gaps?
The discovery of serious gaps is in fact the purpose of the test — it is a success, not a failure. After the completion of TLPT, the institution must develop and implement a remediation plan that addresses the identified weaknesses. This plan is submitted to the supervisory authority together with the test report. The supervisory authority may monitor the progress of the remediation plan’s implementation. Failure to produce a plan or to implement it may result in supervisory action. In practice, supervisory authorities understand that the purpose of TLPT is to detect weaknesses, and treat an actively implemented remediation plan as evidence of mature risk management — not as an admission of fault.
What is the minimum frequency for conducting TLPT required by DORA?
DORA requires TLPT to be conducted at least once every three years. The competent supervisory authority may, however, request that a test be conducted before this deadline expires — for example, following a serious cyber incident, following a material change in the institution’s technological infrastructure, or where a new, serious sector-wide threat has been identified. The three-year cycle should be treated as a minimum, not as an optimal schedule. Institutions with high cybersecurity maturity frequently conduct elements of TIBER-EU methodology (e.g. abbreviated Red Team exercises) on an annual basis — between full TLPT cycles.
Sources
- Regulation (EU) 2022/2554 of the European Parliament and of the Council of 14 December 2022 on digital operational resilience for the financial sector (DORA) — Arts. 24–27
- European Central Bank: TIBER-EU Framework — How to implement the European framework for threat intelligence-based ethical red teaming (2018, updated 2022)
- European Banking Authority (EBA): Guidelines on ICT and security risk management (2019); updated in the DORA context
- European Insurance and Occupational Pensions Authority (EIOPA): DORA implementation guidance for insurance sector (2024)
- European Securities and Markets Authority (ESMA): Joint ESAs guidance on DORA implementation (2024)
- MITRE ATT&CK Framework: Enterprise Matrix v14 — https://attack.mitre.org/
- CREST: STAR (Simulated Targeted Attack and Response) standard — https://www.crest-approved.org/
- Komisja Nadzoru Finansowego (KNF): Communications on DORA implementation in Poland (2024–2025)
- Narodowy Bank Polski: TIBER-PL implementation work (2024)
