# DORA and recurring penetration testing, what is required > DORA sets two testing duties: a yearly programme every firm in scope runs, and threat-led penetration testing only where the authority designates you. Source: https://fmcybersecurity.com/en/insights/compliance/dora-and-recurring-penetration-testing/ Locale: English Other locale: https://fmcybersecurity.com/insights/compliance/dora-og-regelmessig-penetrasjonstesting/ ## Metadata - Date: 2026-08-06 - Author: christian-vik - Topic: compliance - Format: guide DORA asks for two different things when it says test, and they are not interchangeable. Every financial entity in scope, apart from microenterprises, runs a documented testing programme and tests its critical systems at least once a year. Threat-led penetration testing, TLPT, is a separate duty that runs at least every three years and only lands on firms the authority picks out. Blurring the two costs money in both directions. Firms that will never be designated budget for a red team they do not need. Firms that skip the yearly programme have nothing to hand Finanstilsynet when it asks. For the view across five different frameworks, read [which regulations require recurring pentests](/en/insights/appsec/which-regulations-require-recurring-pentests/). This piece stays inside DORA. ## Tier one, the yearly testing programme every firm in scope runs Every financial entity under DORA, except microenterprises, must run a documented testing programme and test its critical systems at least once a year. The rules sit in articles 24 and 25 of [Regulation (EU) 2022/2554](https://eur-lex.europa.eu/eli/reg/2022/2554/oj). Three points carry the weight. The programme is part of the ICT risk management framework, not a standalone purchase. Tests are run by independent parties, and internal parties count as long as they are independent of what they test. Appropriate tests must cover all ICT systems and applications supporting critical or important functions at least yearly. Article 25 then lists twelve methods the programme can draw on: vulnerability assessments and scans, open source analyses, network security assessments, gap analyses, physical security reviews, questionnaires and scanning software, source code reviews where feasible, scenario-based tests, compatibility testing, performance testing, end-to-end testing, and penetration testing. Penetration testing is one entry on a list of twelve. Nowhere does DORA say annual manual pentest. Two details get missed. Microenterprises combine a risk-based approach with planned testing instead of the full programme. Central securities depositories and central counterparties carry an extra duty: a vulnerability assessment before any deployment or redeployment of applications, infrastructure components and ICT services supporting critical or important functions. ## Tier two, TLPT, and who it lands on Threat-led penetration testing applies only to firms the authority designates, runs at least every three years, and is carried out against live production systems. Article 26 leaves out microenterprises and entities on DORA's simplified ICT risk framework. Everyone else is in the pool, but only the firms an authority identifies have to test. The criteria are the firm's impact on the financial sector, financial stability concerns, and its ICT risk profile and maturity. [Commission Delegated Regulation (EU) 2025/1190](https://eur-lex.europa.eu/eli/reg_del/2025/1190/oj), published on 18 June 2025 and applicable from 8 July 2025, turns those criteria into named categories: systemically important credit institutions, the largest payment and electronic money institutions, central securities depositories, central counterparties, the largest trading venues, and the largest insurers. The Norwegian side is in place. Finanstilsynet [added four level-2 regulations to DORA-forskriften on 26 January 2026](https://www.finanstilsynet.no/nyhetsarkiv/nyheter/2026/gjennomforing-niva-2-regelverk-under-dora/), the TLPT standard among them. Its published [DORA Q&A](https://www.finanstilsynet.no/tema/dora/qa-dora/), written before that step, says no assessment has yet been made of which firms will be required to run TLPT, and that designated firms will be told directly. The working read for a Norwegian firm today: if nobody has told you, you are in tier one. Norwegian TLPT runs through TIBER-NO, the framework Norges Bank and Finanstilsynet set up in 2021. Finanstilsynet's [risk and vulnerability report for 2025](https://www.finanstilsynet.no/publikasjoner-og-analyser/risiko--og-sarbarhetsanalyse/risiko--og-sarbarhetsanalyse-2025/ros-2025/risiko--og-sarbarhetsanalyse-ros-2025/) states that four enterprises have completed a TIBER-NO test. The ECB [updated TIBER-EU in February 2025](https://www.ecb.europa.eu/press/intro/news/html/ecb.mipnews250211.en.html) to line up with DORA and the TLPT standard, so a TIBER test and a DORA TLPT now follow the same process. When a TLPT ends, the firm hands the authority a summary of the findings, the remediation plans, and documentation showing the test followed the rules. The authority then issues an attestation confirming the test was performed as required, and that attestation is what lets supervisors in other countries recognise it. ## Who may run a TLPT, and how independent the tester has to be A TLPT tester must hold accreditation or follow a formal code of conduct, carry professional indemnity insurance, and prove expertise in threat intelligence, penetration testing and red teaming. Article 27 spells out the conditions. Highest suitability and reputability. Demonstrated capacity in all three disciplines above. Certification by an accreditation body in a member state, or adherence to formal codes of conduct or ethical frameworks. Independent assurance or an audit report covering how the tester manages the risk to your data. Professional indemnity insurance that covers misconduct and negligence. Internal testers are allowed on conditions most firms will not meet. The competent authority has to approve their use, and has to have verified that the firm has dedicated resources and that conflicts of interest are avoided across both design and execution. The threat intelligence provider always has to be external. A firm using internal testers must also contract external testers every third test, and credit institutions under direct ECB supervision must use external testers only. Read together, those conditions describe a specialised market with a short list of qualified providers. FM CyberSecurity does not deliver TLPT or TIBER-NO engagements, and no continuous testing product substitutes for one. If your firm gets designated, you buy that engagement separately, from a provider that meets article 27 on paper. ## What a supervisor asks to see A supervisor asks for the programme document, evidence that the yearly test covered the right systems, the record of how findings were closed, and proof that suppliers took part. Four artefacts do most of the work. The programme itself, written down, sitting inside the ICT risk management framework, with the risk reasoning for what gets tested, by which method, and how often. Coverage evidence. Not "we ran a pentest", but a list of the ICT systems and applications supporting each critical or important function, and the test that hit each one inside the last twelve months. The closure record. Article 24 requires procedures to prioritise, classify and remedy every issue a test reveals, plus internal validation that the weakness is fully addressed. A report full of open findings with no closure trail reads worse than a smaller test that was followed through. Supplier participation. Finanstilsynet expects ICT service providers to take part in the yearly testing where relevant, points at the contract clauses DORA requires for critical or important functions, and states in its own Q&A that it has flagged missing supplier involvement in several supervisory reviews. That is a named gap, published by the supervisor, and it is cheap to close. The reporting side of the same evidence pack is covered in [DORA audit requirements and what you report each year](/en/insights/compliance/dora-audit-and-reporting-requirements/). ## Five steps that close tier one this year 1. Confirm which tier you are in. Write down whether you are a microenterprise, whether you sit on the simplified framework, and whether any authority has designated you for TLPT. Date the conclusion and file it with the ICT risk framework. 2. List the critical and important functions first, then the systems under them. The yearly duty attaches to functions, not to an asset register. Most testing gaps I see in readiness reviews start as a system nobody mapped to a function. 3. Write the programme before you run a test. Methods, frequency, who tests what, and the risk reasoning behind those choices. Article 25 hands you twelve methods, so pick deliberately and record why. 4. Test on change as well as on the calendar. A yearly test proves the state of a system in March. Continuous application and infrastructure testing proves it again in July, when the new payment flow shipped. FM CyberSecurity runs this layer on [Aikido](/en/partners/aikido/), with [AI Pentest](/en/products/aikido/ai-pentest/) probing the applications continuously, and we write our own reports from the findings for the evidence pack. 5. Keep the closure record next to the report. Every finding gets a classification, an owner, a fix date and a validation entry. That file is what turns a test into evidence. Software helps with steps 3 and 5 and does nothing for step 1. [What DORA software covers, and what stays a board decision](/en/insights/compliance/tooling-for-dora-compliance/) draws that line. For the wider article-by-article picture, the [DORA checklist for Norwegian financial firms](/en/insights/compliance/dora-checklist-for-norwegian-financial-firms/) runs ten steps, and FM CyberSecurity's [DORA practice](/en/services/dora/) maps the requirement to your programme with article references in the documentation pack. Start with the function list. If your testing programme today is a folder of PDF reports, the list of critical and important functions and which of them were tested this year is the first thing a supervisor will ask for, and it takes an afternoon. Send me a message when you want a second pair of eyes on it. ## FAQ ### Does DORA require an annual penetration test? No. Article 24 requires appropriate tests at least yearly on all ICT systems and applications supporting critical or important functions. Article 25 lists twelve methods that qualify, and penetration testing is one of them. The obligation is to test the right systems with a method that fits the risk, and to prove it. ### How do I know whether my firm has to do a TLPT? The authority tells you. TLPT applies to firms identified under article 26, using criteria on financial-sector impact, financial stability and ICT risk profile, with the categories set out in Delegated Regulation (EU) 2025/1190. Finanstilsynet's DORA Q&A states that no assessment has yet been made of which Norwegian firms will be required to run TLPT, and that designated firms will be notified directly. ### Can we use our own people as TLPT testers? Only under narrow conditions. The competent authority must approve it, and must have verified that you have dedicated resources and avoid conflicts of interest through design and execution. The threat intelligence provider has to be external either way. Every third test has to use external testers, and credit institutions under direct ECB supervision must use external testers only. ### Does continuous automated testing satisfy DORA? For the yearly programme, it does the job when it covers the systems supporting critical or important functions, runs at least yearly, and produces a closure record for every finding. It does not satisfy TLPT, which is a separate, intelligence-led engagement against live production with its own tester requirements. ### Do our ICT suppliers have to take part in the testing? Finanstilsynet expects ICT service providers to participate in the yearly testing where relevant, and points at the DORA contract clauses for critical or important functions, which must cover testing of contingency plans and possible participation in TLPT. The supervisor has publicly noted missing supplier involvement in several reviews, so put the clause in the contract and the supplier in the test plan. --- For the full documentation index, see https://fmcybersecurity.com/llms.txt For the complete corpus as a single document, see https://fmcybersecurity.com/llms-full.txt