Why do organisations need continuous penetration testing to support DORA and GDPR obligations?

Why This Matters for Security Teams

Continuous penetration testing matters because both DORA and GDPR look beyond a one-time assessment and toward ongoing assurance that controls still work when systems, identities, and dependencies change. Under DORA, organisations need evidence that ICT risk is being managed as an operating discipline, not a periodic exercise. Under GDPR, the security of processing obligation expects proportionate and current protection for personal data, including the systems and pathways that expose it. That is why teams often pair retesting with remediation tracking, exploitability validation, and board-level reporting.

This is also where many programmes slip: annual tests can confirm a point-in-time posture, but they do not tell you whether a newly deployed service, exposed API, or privilege change reopened the same weakness. Current guidance suggests aligning testing cadence to business change and threat exposure, then preserving evidence that findings were prioritised and closed. For reference, the EU Digital Operational Resilience Act (DORA) frames resilience as an ongoing obligation, not a one-off review.

In practice, many security teams encounter control failure only after a material change or incident has already invalidated the last test cycle, rather than through intentional continuous validation.

How It Works in Practice

Continuous penetration testing is not the same as running a scanner on a schedule. It combines targeted human-led attack simulation, repeatable test cases, and ongoing retest cycles so the organisation can prove that remediation really reduced risk. In regulated environments, the objective is not just to find vulnerabilities but to show traceability from issue discovery to closure, with evidence that the exposure no longer exists or has been sufficiently contained. That evidence becomes valuable for audit, incident review, and governance reporting.

For DORA, this supports resilience testing by showing that technical weaknesses, segmentation gaps, and identity abuse paths are being discovered and corrected as part of normal operations. For GDPR, the same programme helps demonstrate security of processing, especially where personal data may be reached through application flaws, misconfigured access, or weak administrative controls. NHI Management Group recommends treating credentials, tokens, and service accounts as part of the attack surface, because continuous testing often reveals that a seemingly small secret exposure can become a path to regulated data.

• Test against realistic attack paths, not just CVE lists, so findings reflect how compromise would actually occur.
• Retest after material change, such as a cloud migration, new integration, new IAM policy, or major release.
• Track evidence of remediation, including validation that fixes did not introduce a compensating weakness.
• Feed results into risk registers, incident lessons learned, and executive reporting.

Teams should also align with recognised security baselines, including the EU General Data Protection Regulation (GDPR) for security and accountability expectations, and the practical control logic reflected in CIS Critical Security Controls for ongoing defence. These controls tend to break down when large environments change faster than retesting can be scheduled, because inherited trust and configuration drift outpace validation.

Common Variations and Edge Cases

Tighter continuous testing often increases operational overhead, requiring organisations to balance assurance against system stability, production access, and remediation capacity. That tradeoff is especially visible in regulated financial services, where change windows are narrow and evidence requirements are high. Best practice is evolving here: there is no universal standard for exactly how continuous testing must be implemented, so organisations should define a cadence and scope that reflect their risk profile, critical services, and regulatory exposure.

Some environments need more frequent retesting because the attack surface shifts quickly, such as cloud-native platforms, externally exposed APIs, and services with frequent identity or secret rotation. Others may need deeper manual testing after release gates, because automated checks alone do not reliably surface chained abuse paths, business logic flaws, or privilege escalation routes. The strongest programmes combine continuous monitoring with periodic adversarial validation, then link results to governance records that can be shown to auditors and privacy stakeholders.

Where identity is part of the risk path, the question is not only whether an application is vulnerable, but whether access paths, service accounts, and privileged workflows are being continuously challenged. In that sense, continuous penetration testing is a practical bridge between resilience testing and identity assurance, especially when security teams need to prove that exposure was discovered, remediated, and confirmed closed before it becomes a DORA or GDPR reporting problem.

Related resources from NHI Mgmt Group

• What breaks when continuous penetration testing is treated as a replacement for DORA TLPT?
• Why do small organisations still need penetration testing?
• How can organisations prioritise penetration testing when applications outnumber testers?
• What do organisations get wrong about penetration testing and SOC 2?