Notifications
Clear all
Topic starter
18/08/2026 2:50 pm
TL;DR: Continuous penetration testing can strengthen DORA compliance by keeping exploit evidence, remediation status, and retest results current between formal assessments, according to Equixly. The operational shift is from point-in-time testing to an evidence trail that ties weaknesses to critical functions, third-party paths, and closure decisions.
NHIMG editorial — based on content published by Equixly: Compliance, DORA and continuous penetration testing
By the numbers:
- DORA came into force in the EU on 17 January 2025, covering 20 types of financial entities and ICT third-party service providers.
- ENISA found that supplier attacks led to sensitive data exposure in 63% of cases and operational disruption in 26%.
- Financial entities in scope for TLPT needed a separate technical standard, Commission Delegated Regulation (EU) 2025/1190, which became enforceable on 8 July 2025.
Questions worth separating out
Q: What breaks when continuous penetration testing is treated as a replacement for DORA TLPT?
A: It breaks the regulatory distinction between ongoing validation and formal threat-led testing.
Q: Why do identity controls matter in DORA penetration testing programs?
A: Identity controls often determine whether a technical weakness becomes a business incident.
Q: How do organisations know continuous testing is actually improving resilience?
A: Look for three signals: findings are tied to specific critical functions, remediation is verified with retesting, and the evidence trail can be mapped to risk decisions.
Practitioner guidance
- Map tests to critical functions and identity-dependent workflows Build the continuous testing scope around payment paths, customer-facing APIs, administrative workflows, and third-party provider links that would materially affect a regulated service if compromised.
- Require proof of exploitability, fix, and retest Do not close findings on severity alone.
- Separate formal TLPT governance from continuous validation Use continuous testing to maintain current evidence, but keep TLPT scope, independence, and supervisory requirements distinct so the program does not blur regulatory obligations.
What's in the full article
Equixly's full blog covers the operational detail this post intentionally leaves for the source:
- How the platform chains API calls and workflows to validate exploitability in live environments
- What remediation guidance and retest outputs look like when continuous testing is wired into CI/CD
- How the DORA proof trail is structured for findings, owners, and closure evidence
- Why the article treats GenAI systems and MCP implementations as testable API-based paths
👉 Read Equixly's DORA analysis of continuous penetration testing and proof trails →
DORA penetration testing and the proof trail teams are missing?
Explore further
18/08/2026 3:32 pm
Continuous testing is becoming the evidence layer of DORA, not a replacement for formal testing. DORA still distinguishes between broad resilience testing and selected threat-led penetration testing, but the practical challenge is proving that a fix remained effective after the original test closed. Continuous validation is what keeps the record alive between audit points. For financial entities, the compliance question is shifting from whether a test happened to whether the proof trail still matches the live environment.
A question worth separating out:
Q: Who should own remediation when continuous testing finds exploitable issues?
A: The team that owns the code, configuration, dependency, or workflow should own the fix. Security should validate the finding, define priority, and confirm closure, but not become the permanent remediation queue. That division of labour keeps the programme moving and prevents security from becoming the bottleneck.
👉 Read our full editorial: Continuous penetration testing and DORA proof trails for financial entities
