Financial sector · DORA evidence under Art. 24/25

DORA pentest for banks, insurers and payment providers

Since 17 January 2025, Regulation (EU) 2022/2554 has applied directly to the entire financial sector in the EU, replacing the BaFin circulars BAIT, VAIT, ZAIT and KAIT for DORA-regulated firms. Art. 24/25 DORA requires regular security testing from every affected company. Institutions that the supervisor classifies as significant additionally face a Threat-Led Penetration Test under Art. 26/27, at least every three years and exclusively on live production systems. We deliver the structured baseline test for the normal case, plus the preparation that keeps a later TLPT from turning into a nasty surprise.

Request a DORA security check View the dependency map
  • Art. 24/25 DORA covered
  • TIBER-DE-oriented approach
  • Free initial consultation

E-01

Art. 28 DORA · Register of ICT third-party providers

What stops when one provider stops?

Art. 28 DORA requires a continuously maintained register of all contracts with ICT third-party providers, filed with the supervisor at least annually (with BaFin by 31 March). The register answers only half the question. The other half: which of your critical functions hang on that one entry and stop the moment it fails or is compromised. The map shows that relationship for a fictional institution with four critical functions and six providers in its register.

Institution four critical functions Account keeping Payments Online banking Regulatory reporting D1 Core banking D2 Payment provider D3 Data centre D4 Cloud platform D5 Identity service D6 Market data
Illustrative register structure, no real customer data. Which providers are critical in your case is settled during scoping.

The map walks through the entries by itself. Click an entry to hold it and read at your own pace.

  1. Carries: Booking logic, account master data, order processing

    Stops with it Account keeping, payments and regulatory reporting at once

    What we test there

    Legacy interface protocols, batch access, service accounts with far-reaching rights, and the question of whether a test environment holding real data sits on the same network.

    Art. 25 DORALearn more

  2. Carries: Connection to clearing and bulk payment traffic

    Stops with it Payments

    What we test there

    The stretch between your house and the provider: certificates, signature validation, replayability of orders, and the separation between entry and approval.

    Art. 25 and 28 DORALearn more

  3. Carries: Operation of the servers everything else runs on

    Stops with it all four functions, because nothing is left underneath them

    What we test there

    Remote maintenance access, jump servers, network segmentation between tenants, and physical access control to the areas where your systems stand.

    Art. 25 DORALearn more

  4. Carries: Customer portal, document storage, analytics

    Stops with it Online banking and regulatory reporting

    What we test there

    The tenant role and permission model, key management, publicly reachable storage, and who at the provider holds administrative access to your environment.

    Art. 25 and 28 DORALearn more

  5. Carries: Sign-in for customers and staff

    Stops with it Online banking and account keeping

    What we test there

    Enforcement of multi-factor sign-in, recovery paths, session handling, and the transitions between customer sign-in and internal sign-in.

    Art. 25 DORALearn more

  6. Carries: Input for valuation, risk calculation and filings

    Stops with it Regulatory reporting

    What we test there

    Integrity of the delivered data, authenticity of the delivery path, and whether a manipulated delivery would be noticed in-house at all.

    Art. 25 and 28 DORALearn more

E-02

Attack surface, financial sector

Where attackers actually start at banks and insurers

The map above shows what hangs on what. This entry shows where someone from the outside actually starts. Four areas turn up again and again at financial institutions, and none of them is unknown to the house. What is usually unknown is how far you get from there.

  1. 01

    Core banking systems and payments

    Legacy core banking platforms and payment interfaces running protocols that are rarely reassessed. What was designed as an internal protocol fifteen years ago now often sits on a network that has grown considerably.

    How we cover it

    Infrastructure pentest against the systems themselves, including which accounts operate the interfaces and what one of them would make possible.

    Art. 25 DORA
  2. 02

    Online banking and banking APIs

    Customer portals and interfaces are the most direct target and at the same time the system with the largest damage on successful access. The typical finding is not a spectacular flaw but an authorisation check that fails to separate two customer accounts cleanly.

    How we cover it

    Web app pentest to OWASP standard, extended by the failure patterns that recur in the financial sector, such as missing object-level authorisation between accounts.

    Art. 25 DORA
  3. 03

    Branch network

    Public areas, teller zones and meeting rooms with network access. A physical attack surface that a purely IT-side view tends to miss, because it appears in no system inventory.

    How we cover it

    Physical pentest in an agreed branch, plus a check of how far the branch network is separated from the central network.

    Art. 25 DORA
  4. 04

    ICT third parties and supply chain

    Outsourcing partners, cloud providers and payment service providers, which DORA defines as a risk of its own in Art. 28. Critical ICT third-party providers can even fall under direct supervision by the European Supervisory Authorities.

    How we cover it

    Review of the access you have granted to third parties: remote maintenance, interfaces, service accounts, and whether they are actually closed when a partner leaves.

    Art. 28 DORA

Which of these areas belong in your test is decided during scoping. A baseline test does not have to cover everything at once, it has to show that the critical functions were tested.

E-03

The difference DORA makes

Basic security testing or TLPT: which applies to you?

DORA has no one-size-fits-all answer. For the broad mass of financial companies, a structured security test under Art. 24/25 is enough. Only institutions the supervisor classifies as significant face the considerably heavier Threat-Led Penetration Test under Art. 26/27. The table shows how the two really differ, and where our service ends.

Criterion Basic security testing (Art. 24/25 DORA) TLPT (Art. 26/27 DORA)
Who is affectedEvery DORA-regulated financial company, without exceptionOnly financial entities designated by the supervisor, e.g. G-SIIs/O-SIIs or payment and e-money institutions with more than EUR 150 billion in payment volume in each of the two previous years
FrequencyAt least annuallyAt least every three years
Test environmentTest or production systems, depending on scopingExclusively live production systems
Project durationTypically a few weeksAt least 12 weeks following the TIBER-DE process
Who may testAn experienced pentest team is sufficientOnly testers who meet the requirements of Art. 27 DORA (certification by an accreditation body or adherence to a code of conduct, insurance, track record), under the Bundesbank TIBER-DE framework
EffortManageable and plannable, a self-contained projectVery high, a specialised team over months plus supervisory oversight
Legal basisArt. 24/25 of Regulation (EU) 2022/2554Art. 26/27 of the same regulation, shaped in Germany through TIBER-DE
Our contributionFully covered as a self-contained projectPreparation only. We do not run the TLPT itself.

TIBER-DE is the German framework for TLPT: operated by the Bundesbank, supervised on substance by BaFin. If you are unsure whether your institution size is heading towards TLPT, the fastest way to settle it is a short initial call with us.

E-04

Self-check

Which path are you on?

Four questions that point the way. Answer them in order, the result below updates as you go. The binding classification is made by the supervisor, not by you.

  1. 01Has the supervisor classified you as a significant institution under Art. 26/27 DORA?

    leaning towards path B: TLPT obligation, at least every three years on production systems

    path A is enough: baseline test under Art. 24/25, at least annually

  2. 02Are you a payment or e-money institution with more than EUR 150 billion in payment volume in each of the last two financial years?

    leaning towards path B: that is one of the criteria for being classified as significant

    path A is enough, provided no other classification criterion applies

  3. 03Are you listed as a systemically important institution, or does your insurance business exceed EUR 1.5 billion in gross premiums with more than EUR 10 billion in technical provisions at the same time?

    leaning towards path B: this too is among the criteria by which the supervisor measures significance

    path A is enough, the baseline test covers your testing obligation

  4. 04Is a TLPT date under TIBER-DE already on the horizon?

    leaning towards path B: the test alone runs at least 12 weeks, and the preparation needs lead time

    path A is enough, repeated annually

E-05

Two paths, one goal

Path A or path B: how it runs at your place

Depending on how your institution is classified, we scope the project either as a baseline test under Art. 24/25 or as preparation for a future TLPT. Both paths follow a clear sequence, but differ in depth, lead time and outcome.

Which path applies to you?

Path A · baseline test (Art. 24/25)For every DORA-regulated financial company, as a rule at least annually (risk-based for microenterprises).

Path B · TLPT readiness (Art. 26/27)For institutions the supervisor classifies as significant, or is likely to.

Unsure? The self-check above helps with the classification.

Path A · Art. 24/25 DORA

The structured baseline test

For the vast majority of financial companies this is the relevant piece of evidence. We deliver it as a clearly bounded, repeatable project.

What happens

  1. Scoping and classification

    Together we establish whether a baseline test is sufficient and define which core systems, online banking components, branches and third-party connections belong in scope. The basis for this is your Art. 28 register, because it already records what your critical functions hang on.

  2. Reconnaissance and test execution

    Publicly available information, network reconnaissance, then manual testing within the agreed scope, on test or production systems as arranged. Every step is logged so the report can show when what was done.

  3. Risk rating and a DORA-mapped report

    Every finding is rated by severity and exploitability and assigned to the matching DORA article. The audit-ready final report with management summary can be used directly in BaFin reviews.

Outcome: documented evidence under Art. 24/25 DORA, repeatable every year.

To the DORA page

Path B · Art. 26/27 DORA

TLPT readiness instead of a nasty surprise

If you are likely to be classified as a significant institution, we prepare systems and processes specifically for a future TLPT, without running the TLPT ourselves.

What happens

  1. Threat-intel-informed scoping

    From publicly available information and your institution's threat picture we derive realistic attack scenarios, including possible vishing pretexts, in the way the threat intelligence phase of a TLPT will later demand.

  2. Production-safe rehearsal of the TIBER-DE phases

    We run through the phases of a TLPT in a controlled way, with clear abort criteria and without risk to live operations, and check whether your processes, contacts and detection hold up.

  3. Gap list before the TLPT

    You receive a prioritised list of the gaps a TLPT test team would find, plus a remediation plan, so the later and far more expensive TLPT does not fail on avoidable basics.

Outcome: readiness report and gap list as the basis for the next TLPT cycle, at least every three years.

We do not run the TLPT ourselves. For that, Art. 27 DORA requires testers with specific credentials (certification or a code of conduct, professional indemnity insurance, experience); the test itself is accompanied operationally by the Bundesbank and supervised by BaFin.

Learn more

E-06

Art. 25(1) DORA

A good vishing campaign is test and evidence in one

Art. 25(1) DORA explicitly lists scenario-based tests as a permitted test method, and Art. 13(6) obliges you to run awareness programmes. A vishing campaign serves both. In practice that means: a controlled call posing as IT support, branch management or an external provider shows whether staff would hand over credentials or release a transfer, and produces exactly the documented test artefact you need for your DORA evidence. We plan every campaign with agreed scenarios, escalation levels and a debriefing that files straight into your compliance folder.

Alongside classic email phishing, vishing maps the specific entry route that the supervisor rates as one of the most relevant, more on that in the next entry.

Social engineering and vishing Learn more

E-07

Not an isolated case but a pattern

What the supervisor reports on vishing attacks

Solid, publicly documented individual cases with names and damage figures are rare in the financial sector. Institutions are naturally more reserved about incidents than some other industries. BaFin, however, writes in its “Risks in Focus 2026” that social engineering attacks such as phishing and vishing are considered the most relevant entry vectors and are therefore the ones tested most often in TLPTs.

A sector-wide observation by the supervisor, not a case study of a single company. Access Granted was not involved in any of the reported campaigns.

How you notice that it concerns you

  • The call comes from a number that matches one of your providers.
  • It refers to a project that is genuinely running and publicly known.
  • It ends with an action that would be routine in daily business, only somewhat more urgent.
Learn more

E-08

Path A in practice

What a baseline test report looks like

An extract as it stands at the end of path A: every finding with severity, remediation and the DORA article it relates to. The mapping is the reason the report can be used in a review without translation work.

Financial sector pentest report · illustrative extract Sample
Finding Severity Reference
Vishing simulation: customer service releases credentials after an authority pretext (sample value)HighArt. 25(1) DORA
Online banking API: weak authorisation check between customer accounts (BOLA)CriticalArt. 25 DORA
Third-party VPN: access without multi-factor authenticationHighArt. 28 DORA
Core banking system: outdated interface protocol without encryptionHighArt. 25 DORA
Branch: network socket in the customer area reachable without port securityMediumArt. 25 DORA
Active Directory: missing network segmentation between branch and head officeHighArt. 25 DORA
6 findings · remediation plan included DORA mapping Art. 24/25 and 28

Illustrative representation, no real customer data.

E-09

Relevant modules

These tests cover your DORA evidence

Art. 24 to 28 DORA call for different kinds of evidence. We cover the part that can be tested technically. This is how we assemble them for financial companies. Which modules you need depends on which critical functions are in the register and what they hang on.

DORA and TLPT for the financial sector: your questions

The baseline test under Art. 24/25 DORA applies to all financial companies and runs at least annually, usually on test or production systems. The Threat-Led Penetration Test (TLPT) under Art. 26/27 is considerably heavier: it runs exclusively on live production systems, takes at least 12 weeks and is mandatory only for institutions classified as significant by the supervisor.

Because the legislator deliberately arranged it that way: under section 28(6) BSIG, the core BSIG duties (sections 30, 31, 32, 35, 36, 38 and 39) do not apply to financial entities within the meaning of DORA; DORA takes precedence as a special rule (lex specialis). Risk management, incident reporting and security testing therefore follow DORA for you, not the BSIG.

We agree target group, pretexts and escalation limits with you beforehand, for example whether a call may go as far as requesting a transfer or is stopped before that. The calls themselves are controlled and logged. Afterwards you receive an evaluation including reporting behaviour and, where useful, targeted awareness recommendations for individual teams.

No, we deliberately do not run the full TLPT under TIBER-DE ourselves; for that, Art. 27 DORA requires specialised test teams with specific credentials. What we offer is the preparation for it: a TLPT readiness assessment that surfaces gaps in advance, so the later and considerably more expensive TLPT does not fail on avoidable basics.

The classification is made by the supervisor, not by you, on criteria such as systemic relevance or transaction volume, among others from around EUR 150 billion in processed annual payment volume or from EUR 1.5 billion in gross premiums combined with more than EUR 10 billion in technical provisions in the insurance business. If you are unsure whether your size is heading that way, we settle it in the free initial consultation against your actual figures.

That depends on the scope: the number of systems and branches, whether vishing and physical testing are included, whether it is a pure baseline test or TLPT readiness preparation. After the free initial consultation we know your scope and you receive a transparent fixed-price offer.

A baseline test under Art. 24/25 typically takes a few weeks depending on scope, from scheduling to the finished report. A TLPT readiness assessment usually needs a little more lead time because more systems and stakeholders are involved. The full TLPT itself takes at least 12 weeks under TIBER-DE.

Indirectly yes: Art. 28 DORA obliges you as a bank to keep a register of all ICT third parties and to assess their risk. The register goes to the supervisor at least annually, to BaFin by 31 March. Critical providers can even fall under direct supervision by the European Supervisory Authorities. That is why our pentest also examines how your third-party access and interfaces are secured.

BaFin can impose conditions, restrict business operations or levy fines. DORA itself sets no amounts and leaves them to the Member States. In Germany, failing to report major incidents or to carry out a required TLPT can cost up to EUR 5 million, other breaches up to EUR 500,000 (section 56(5e) in conjunction with (6) KWG). Since 2026 the earlier grace period is over and the supervisor reviews actively.

Yes, though not at the same depth. Art. 4 DORA explicitly provides for a proportionality principle: the scope and intensity of the requirements follow your size, risk profile and the nature and complexity of your services. According to its recital 3, the regulation covers around 22,000 financial entities in the EU, from the large institution to the small payment institution. The test scope is scaled by risk, the obligation itself does not fall away.

Ready for your DORA evidence?

In 30 minutes we clarify whether a baseline test is enough for you or whether TLPT readiness preparation makes sense, and you receive a non-binding, free quote.

Book a free initial consultation Send a request via the contact form
Take this page with you as a printable flyer (PDF)

Contact

Address
Albert-Einstein-Straße 1, 95028 Hof
E-Mail
hello@access-granted.de
Phone
+49 9281 5918506

AccessGranted X GmbH · HRB 7266 · Hof (Saale)

Company

Services

Regulatory pentests

Industries

Networks & trust seals
Trust Seal of the IT Security Association Germany (TeleTrusT)
Participant in the Alliance for Cyber Security
© AccessGranted X GmbH Last updated: September 23, 2026