DE – Diese Seite auf Deutsch Book a free 20-min test audit
DORA resilience testing

Test evidence for your DORA testing programme – from an independent senior engineer

DORA (Regulation (EU) 2022/2554) has applied since 17 January 2025. Article 25 lists performance testing, end-to-end testing and scenario-based tests among the tests a resilience testing programme can include. I run those tests on your critical payment and banking systems and hand over reports and test code your team keeps.

Book a 20-min test audit →Free 20-min check-upSee a sample report

Not legal advice. Assertwise provides testing, not legal or compliance advice. Your compliance function decides whether and how DORA applies and how test evidence is used.

The problem

  • Article 24 asks for a risk-based testing programme, tests by independent parties (internal or external), remediation of findings with validation, and at least yearly tests on ICT systems supporting critical or important functions.
  • Most small fintech engineering teams have CI tests, but no load tests on payment paths, no documented failure scenarios and no retest trail.
  • A green pipeline is not evidence. Compliance needs scope, method, thresholds, findings and retests.

How Assertwise helps

  • Performance and load testing of payment, onboarding and ledger APIs with workload models from your traffic (payday, month-end, campaign peaks).
  • End-to-end tests across your services and partner sandboxes, automated in your CI.
  • Scenario-based failure tests: PSP and KYC timeouts, database failover, retry storms, duplicate webhooks.
  • Code-level review of money-moving paths: idempotency, locking, rounding, authorisation.
  • TLPT readiness: making sure the engineering-side tests on critical functions are in place and documented before a specialised TLPT provider starts.

Scope and deliverables

  • Written scope within 2 working days of our call, mapped to the Article 25 test types you want covered.
  • Test plan with pre-agreed thresholds (latency percentiles, error rates, correctness checks such as "no duplicate ledger entries").
  • Report: each finding with reproduction steps, trace, severity and suggested fix; critical findings reported the same day.
  • Retest of fixed findings, documented with date and result.
  • k6, Playwright and API test code in your repository, ready for the next yearly cycle.
  • DPA in place; test data deleted after the project.

What we don't do

  • No legal or compliance advice, and no opinion on whether DORA applies to you.
  • No "DORA certification" – the regulation does not provide one; test reports are evidence, not a verdict.
  • No threat-led penetration testing (TLPT) under Article 26.
  • No ICT third-party register, incident reporting or policy writing.

FAQ

Can Assertwise be the "independent party" in Article 24(4)? I'm external to your engineering team and not involved in building the system, so I can act as one of the "independent parties, whether internal or external" the article mentions. Whether that independence fits your programme is a decision for your compliance function.

Do you do TLPT? No. I help with TLPT readiness on the engineering side; the TLPT itself is done by specialised providers under Article 26.

Will you load-test production? Only if you explicitly ask and we agree limits in writing. By default I test staging or a production-like environment.

We're a microenterprise. Does Article 24 apply? Article 24 refers to financial entities "other than microenterprises", and Article 25(3) has separate wording for microenterprises. Ask your compliance function how this applies to you.

What do we need to provide? Access to a test environment, API documentation, and a contact who knows the system. For load models, anonymised traffic metrics.

Start with one critical payment flow

Tell me which flow matters most. You get a written scope within 2 working days.

Book a 20-min test audit →

Sources