Custom software for the TLPT process under DORA
Threat-led penetration testing is the most demanding form of testing under DORA, Regulation (EU) 2022/2554, and it is not a general obligation. Your supervisor decides whether you must carry out such tests. Once designated, a process is set out with its own roles, its own deadlines and documents that the authority approves one by one.
What the regime requires of you
Article 26 of DORA requires advanced testing for financial entities that have been designated for it. They carry out a TLPT at least every three years, and the competent authority can lower or raise that frequency. Micro-enterprises and the entities listed in Article 16(1) are excluded. The authority itself decides which entities are designated, based on impact-related factors, systemic character and the ICT risk profile.
The detailed rules have now been adopted. Commission Delegated Regulation (EU) 2025/1190 of 13 February 2025 was published in the Official Journal on 18 June 2025 and sets out firm criteria. Systemically important credit institutions fall within it, as do central securities depositories and central counterparties. For payment institutions, the threshold is €150 billion in payment transactions in each of the two preceding calendar years.
The test covers multiple or all critical or important functions and runs on live production systems. You decide for yourself which functions are included, but that outcome is validated by the authority, and the scoping document goes to your management body. This page covers only that testing regime. The ICT risk framework, the incident register and the register of outsourcing arrangements are covered on our page on DORA compliance software.
How we build this
The process begins with a notification from the TLPT authority and ends with an attestation. In between lie documents that each require their own approval.
Within three months of the notification, you submit a project charter, the leader of the control team and the codename. The scoping document follows within six months.
The control team, blue team, testers and threat intelligence provider each have a distinct position. Access follows need-to-know, and a system should enforce that.
The scoping document, threat intelligence report, red team test plan, both test reports, the summary and the remediation plan belong together, in one file with versions and approvals.
Each finding receives a root cause analysis, a prioritised measure, an owner and the risk of not acting. That is what the RTS requires of a remediation plan.
What the software actually does
The file carries the whole. What you set up beyond that depends on the number of functions in scope and the number of parties involved.
The scoping document with justification
Which functions are included and why, along with the underlying systems, processes and technologies. The RTS also requires a rationale for what you leave out of scope.
The risk assessment of the test itself
You unleash attacks on production systems. The assessment covers disruption, data damage and escalation, and remains in force for as long as the test runs.
Access on a need-to-know basis
Only the control team, the management body, the testers, the threat intelligence provider and the authority. The test receives a codename, and nothing more is recorded in the system.
Recording the suitability of providers
Curricula vitae, certifications, references and professional indemnity insurance. This documentation must be in place before contracting.
The deadlines of the closing phase
The red team test report within four weeks, and the blue team report no later than ten weeks after the end of the active phase.
From finding to measure
Each vulnerability receives a cause, a measure, a priority and an owner, and connects to your audit software.
Who we build for
The designation applies to very different institutions. Four situations.
Banks and systemically important institutions
Credit institutions designated as global or otherwise systemically important are named in the RTS. Significant credit institutions may only use external testers. See also software for the financial sector.
Payments and electronic money
Above €150 billion in payment transactions in each of the two preceding calendar years brings the designation into view, with a threshold of €40 billion outstanding balance for electronic money.
Custody, clearing and trading
Central securities depositories and central counterparties appear in the text without a threshold; trading platforms are added based on market share. Hosting then falls under demand, via a sovereign cloud.
Insurers and reinsurers
The RTS works in two steps here: first thresholds for premiums, technical provisions and share of total assets, and within that group a second set.
Test your idea first: a working prototype in 1 day
With OneDayBuild, we turn your idea into something tangible in one day for €1,150, so you can see whether further development is worth the investment. Decide to go ahead with the full build? Then we credit the full cost.
Explore OneDayBuild →Technology and integrations
The RTS prescribes what belongs in the documents, not what they should look like. Templates, roles and approvals should be configurable, so that the next test does not start from scratch.
Why Appfront
A process with a fixed sequence
We build the steps in the order the RTS requires, with approval as a condition for the next. A file that ignores that sequence will show gaps afterwards.
The attestation is the final step
The authority confirms in an attestation that the test was carried out in line with the requirements, and for that it examines a list of documents. That list should be complete at that point.
Separation you can demonstrate
Who saw what and when is part of the evidence here. We record access and inspection rather than relying on the agreement that nobody is looking.
We do not carry out the test
The red team is hired separately, with Article 27 as the benchmark. We build the system around it, alongside, for example, DevSecOps.
Security and privacy
A TLPT file contains the weak spots in your critical functions, the attack paths that worked and the systems that were affected. That is the information someone could use to attack you. The RTS calls this sensitive information and rejects reports that omit it from test managers' submissions. We build that separation into the document itself, so that such a version is not a patched-up afterthought.
Confidentiality is part of the outcome here: the RTS cites a breach of the test's confidentiality as a reason the attestation may not be issued. We set access by role, keep the blue team out of the system until the control team informs it, and record every inspection. How we handle security ourselves is set out in our information security policy; reports from outside come through our CVD policy.
Frequently asked questions about TLPT under DORA
No, it is a selection. The competent authorities designate who falls under this obligation, based on impact-related factors, systemic character and ICT risk profile. Micro-enterprises and entities under the simplified ICT framework are exempt; the RTS sets out thresholds for this.
At least every three years, says Article 26 of DORA. The authority may lower or raise that frequency based on your risk profile. This is separate from Article 24, which requires at least annual testing of the ICT systems supporting critical or important functions.
Yes. Commission Delegated Regulation (EU) 2025/1190 of 13 February 2025 was published on 18 June 2025 and entered into force on the twentieth day after publication. It sets out the identification criteria, the use of internal testers, the phases and the cooperation between authorities.
DNB developed TIBER-NL in 2016; the ECB then, drawing on that approach, established TIBER-EU. On 11 February 2025, TIBER-EU was updated to align with the RTS. Purple teaming became mandatory as a result, and the role formerly known as the White Team is now called the Control Team.
Only under certain conditions. The authority must approve it and verify that you deploy sufficient resources and rule out conflicts of interest; the threat intelligence provider must always be external. You must engage external testers for every third test.
In it, the authority confirms that the test was carried out in line with the requirements, so that other authorities will recognise it. It includes, among other things, the scope and the duration of the active red team phase. An attestation is not an endorsement of your ability to manage ICT risk; DORA makes that point clear.
We build the system around the process and the evidence: scoping, roles, documents, deadlines and follow-up. You have the testing carried out by testers who meet Article 27. For the rest of DORA there is DORA compliance software, for a routine review the ICT security assessment, and for the moment during the test itself the TLPT app.
That depends on the number of functions in scope, whether third-party providers are involved and whether it is a joint or pooled test. The dossier is usually the first thing that becomes usable. We give a reasoned estimate after the initial exploration.
Want to know whether your dossier will earn the attestation?
Take out the scoping document and check whether every function you left out of scope has a stated reason. That justification is a requirement under the RTS and the first thing the test managers look at. We build this as a standalone system and within a broader software development project.