Continuous penetration testing and DORA proof trails for financial entities

At a glance

What this is: This is a DORA-focused analysis arguing that continuous penetration testing helps financial entities maintain an auditable proof trail between formal security tests.

Why it matters: It matters because IAM, PAM, NHI, and application teams must show how authentication paths, APIs, provider links, and privileged workflows are tested, fixed, and revalidated under DORA.

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.
• Exploitation of security vulnerabilities as an initial access vector grew by 34% year over year in Verizon's 2025 Data Breach Investigations Report.
• 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.

👉 Read Equixly's DORA analysis of continuous penetration testing and proof trails

Context

DORA changes the testing problem for financial entities because compliance is no longer satisfied by isolated scans or an annual pen test alone. The question is whether security testing can produce evidence that survives system change, supports remediation, and maps to the critical functions and provider paths that DORA actually regulates.

That is especially relevant where identity controls sit inside application flows, API integrations, and third-party service paths. Standing access, authentication changes, and exposed secrets can turn a technical weakness into an operational resilience issue, which is why continuous validation matters for IAM, PAM, and NHI governance.

Equixly's article starts from the DORA testing requirement and then extends it into continuous penetration testing. That starting point is typical for financial compliance teams, but the article is more operational than most DORA summaries.

Key questions

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. Continuous penetration testing can keep evidence current, but it does not replace the independence, scoping, and supervisory requirements that apply to TLPT. Teams that blur the two risk producing attractive reports without meeting the formal obligation that regulators expect.

Q: Why do identity controls matter in DORA penetration testing programs?

A: Identity controls often determine whether a technical weakness becomes a business incident. Authentication, authorization, privileged access, and provider trust all sit on the path to a critical function. If those controls are not included in testing, the organisation may validate a vulnerability without validating the actual operational risk it creates.

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. If the program only produces issue lists, it is generating activity rather than resilience. A working program reduces uncertainty about whether fixes hold in production.

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.

Technical breakdown

Why DORA testing needs a proof trail, not just a test result

DORA treats testing as evidence of resilience, not a checkbox. A useful security test must connect the trigger, the system under test, the exploit path, the business function exposed, the control that failed, and the remediation outcome. That is why a one-time report is weak evidence when systems, APIs, and provider dependencies keep changing. Continuous penetration testing extends the value of a standard pentest by preserving context over time, which matters for both annual testing obligations and threat-led exercises. It makes the result auditable, repeatable, and directly tied to the risk register.

Practical implication: retain test evidence in a form that links exploitability, owner, fix, and retest outcome.

How continuous penetration testing fits critical functions, APIs, and identity paths

In DORA programs, the meaningful unit is not the vulnerability category alone but the path to a critical or important function. That includes web applications, APIs, access rules, and third-party integrations that move customer data or money. Identity controls are part of this path because authentication, authorization, and privileged workflows often determine whether an exploit becomes operational impact. Continuous testing is most valuable when it exercises these paths repeatedly as code, roles, and providers change. It helps teams distinguish theoretical exposure from weaknesses that can actually affect service delivery.

Practical implication: scope tests around critical workflows and identity dependencies, not generic asset inventories.

What governance makes continuous testing usable for DORA evidence

Continuous testing only helps if governance preserves independence, severity ranking, remediation ownership, and evidence retention. Independence prevents testers from grading their own controls. Severity ranking lets teams compare issues against ICT risk criteria rather than a flat list. Remediation tracking forces closure to be verified, not assumed. Evidence retention is essential because regulators need to see what was tested, what changed, and whether the fix held. Without those disciplines, continuous testing becomes noise instead of a proof mechanism.

Practical implication: assign clear owners and require retest evidence before a finding can close.

Threat narrative

Attacker objective: The objective is to demonstrate exploitable exposure in a live path that can disrupt a critical financial function or expose sensitive data.

1. Entry occurs through a vulnerability in an application, API, or connected service that supports a critical function, allowing the tester or attacker to reach a live business path.
2. Escalation happens when the weakness interacts with authentication, authorization, or provider trust, turning a technical flaw into broader access or control.
3. Impact is operational when the flaw could affect service delivery, customer data, or a money-moving workflow, which is exactly the kind of exposure DORA expects teams to prove and remediate.

NHI Mgmt Group analysis

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.

Identity paths are central to DORA because many business failures begin with authentication and authorization, not code alone. APIs, access rules, provider integrations, and privileged workflows all sit inside the path from technical defect to operational impact. That means IAM, PAM, and NHI teams cannot stay at the edge of DORA conversations. The governance gap is not just vulnerability discovery, but whether access-dependent workflows are exercised often enough to expose real business risk.

Proof without retest is incomplete governance. The article's strongest point is that closure must be demonstrated, not inferred, because systems change faster than formal testing cycles. That aligns with the broader operational resilience direction in NIST Cybersecurity Framework 2.0 and DORA's emphasis on current evidence. Financial entities should treat every unresolved retest as a live governance exception, not a documentation delay.

Continuous offensive security testing is the right concept for high-change financial environments, but only when scoped to critical services. A blanket approach creates noise and can dilute prioritisation. The value is highest when teams target the workflows where identity, APIs, and third-party access intersect with regulated functions. Practitioners should use the model to sharpen decision-making, not to multiply test volume.

What this signals

Financial entities should expect regulators and auditors to look for evidence that testing is continuous enough to reflect the live state of critical services, not just the state of last quarter's assessment. The programme signal is clear: without a durable proof trail, resilience claims become difficult to defend under DORA and harder to operationalise across IAM, PAM, and API-owning teams.

Proof-trail resilience: this is the operational gap DORA teams need to close, because control effectiveness now depends on whether exploitability was demonstrated, fixed, and revalidated after change. That same pattern applies to NHI-heavy workflows, where the lifecycle of credentials and service access changes faster than annual reviews can capture. Teams should anchor their operating model to current evidence and use NIST Cybersecurity Framework 2.0 to keep resilience, detection, and recovery aligned.

Where third-party services and API paths are involved, continuous testing becomes a governance tool for deciding which dependencies are tolerable and which need redesign. The practical shift is toward shorter remediation cycles, stronger ownership, and tighter linkage between security findings and business services, rather than a larger volume of test output.

For practitioners

• 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. Preserve the exploit evidence, the remediation owner, and the retest result so the record shows the issue no longer exists in practice.
• 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.
• Treat provider-linked findings as resilience issues When a weakness depends on an ICT third party, document the downstream business path, the access model, and the service impact so the finding can be triaged as an operational resilience risk.

Key takeaways

• DORA makes the quality of evidence as important as the result of the test.
• Continuous penetration testing is most useful when it tracks exploitability, remediation ownership, and retest closure across critical functions.
• Identity, API, and third-party paths should be part of the test scope because they often determine whether a vulnerability becomes an operational incident.

Key terms

• Continuous Penetration Testing: A repeated security testing approach that validates whether a weakness is still exploitable after systems, code, or access paths change. Unlike a one-off pentest, it preserves evidence over time so teams can show discovery, remediation, and retesting in a way auditors and operators can both use.
• Evidence Trail: An evidence trail is the set of records that explains how an identity decision was made, including inputs, checks, outcomes, and escalations. It matters because regulated onboarding must be defensible after the fact, not just successful in the moment.
• Threat-Led Testing: A method of testing security controls by simulating realistic attacker behaviour rather than checking policy compliance alone. It is useful because it reveals how systems behave under pressure, where identity controls fail, and whether detection and containment can work in live conditions.
• Critical Function: A business service or process whose failure would materially affect customers, operations, or regulatory obligations. Under DORA, the testing focus is not just whether a system contains flaws, but whether those flaws could disrupt a function the organisation must keep resilient.

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

👉 The full Equixly post covers the DORA testing sequence, governance principles, and proof-trail examples in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is designed for practitioners building control maturity across identity, access, and lifecycle risk.