The 364-day blind spot is a documented compliance risk
Most organisations run a penetration test once a year. The report lands in January, leadership reviews it, findings are categorised, remediation is planned. By February or March, the remediation tickets are somewhere in the backlog. By the following January, some of those tickets are still open — and the pentest that would have caught new vulnerabilities introduced in the intervening 12 months has not happened yet.
This is not an edge case. It is the default state of annual security testing. The 364 days between one test and the next represent a window during which an organisation is shipping features, upgrading dependencies, onboarding third-party integrations, and deploying infrastructure changes — all without systematic adversarial validation.
For a long time, auditors treated this as acceptable. A stamped report from a qualified firm was sufficient evidence that security testing had taken place. That is changing, and it is changing because three major regulatory frameworks are now asking different questions.
What ISO 27001, DORA, and NIS2 actually require
ISO 27001:2022 Annex A Control 8.8 (Management of technical vulnerabilities) requires organisations to demonstrate timely identification and remediation of vulnerabilities. The standard does not prescribe frequency, but it asks for evidence of a systematic, ongoing process. A single annual report is a point-in-time artefact, not a process.
DORA (Digital Operational Resilience Act), applicable to EU financial entities from January 2025, introduces Threat-Led Penetration Testing (TLPT) requirements under Article 26. TLPT is conducted at least every three years for significant institutions, but DORA also requires continuous vulnerability management (Article 10) as a distinct obligation. Continuous does not mean annual.
NIS2 (effective October 2024 across EU member states) imposes a risk-management framework that includes regular testing of security measures. Article 21(2)(f) explicitly lists “policies and procedures to assess the effectiveness of cybersecurity risk-management measures” as a mandatory element. Regulators in Germany (BSI) and the Netherlands (NCSC-NL) have begun interpreting this as requiring evidence of more frequent than annual testing for in-scope entities.
Audit signal (2026): In Q1 2026, we reviewed 23 customer compliance questionnaires from EU financial and healthcare entities. Fourteen of them asked specifically whether penetration testing was conducted “more frequently than annually” or “continuously.” This was not a question we saw frequently in 2024 questionnaires.
Continuous vs annual: a direct comparison
| Attribute | Annual pentest | Continuous AI testing |
|---|---|---|
| Coverage frequency | 1× per year | Every deploy or on-demand |
| Audit evidence trail | One PDF report per cycle | Timestamped finding log, always current |
| ISO 27001 8.8 fit | Point-in-time, not systematic | Continuous process, audit-ready |
| DORA Art. 10 continuous vuln mgmt | Does not satisfy | Satisfies with evidence export |
| NIS2 Art. 21 effectiveness testing | Marginal — depends on auditor | Strong evidentiary position |
| New vulnerability detection lag | Up to 364 days | Hours to days |
| Cost per finding | High (amortised over few findings) | Low (scales with usage) |
What AI-driven testing can and cannot replace
Continuous AI testing is not the same thing as a human red team engagement. This is worth stating plainly because the marketing around AI security tools has been loose on this point.
What AI testing does well:
- OWASP Top 10 coverage on every deploy, not just once a year
- API authorisation logic flaws that scanners miss (BOLA, mass assignment)
- Dependency and secrets exposure in source repositories (SAST)
- Continuous audit evidence generation for regulatory purposes
- Faster MTTR because findings arrive with remediation context
What AI testing does not replace:
- DORA TLPT, which specifically requires human testers from an accredited firm
- Physical security assessments
- Social engineering and phishing simulations
- Custom business-logic attacks requiring deep contextual understanding of a specific sector
The correct model is not annual pentest or continuous AI testing. It is annual (or triennial TLPT) human engagement plus continuous AI testing. The annual engagement provides depth and regulatory certification. Continuous AI testing closes the 364-day gap between those engagements.
How AssurePort approaches the continuous testing problem
AssurePort runs four live scan engines: Web Pentest, API Pentest, GitHub SAST, and Mobile APK. Each engine is a multi-agent pipeline that coordinates reconnaissance, exploitation attempt, finding validation, and remediation guidance in a single run.
Scan results are stored in Cloudflare D1 (EU West region) and exportable as structured JSON or PDF. The PDF includes a timestamped summary, full finding detail with CVSS scoring, and remediation steps — the format required by most ISO 27001 and DORA audit workflows.
Pricing starts at $99 for a single scan (Starter, no subscription) and scales to $299/month (Pro, 6 web scans) for teams that want ongoing coverage. There is no agent to install and no change to your deployment pipeline required. The scan runs against your live endpoint with a Rules of Engagement sign-off that creates a legal record of your explicit authorisation.
The practical compliance argument
If your organisation is subject to DORA, NIS2, or ISO 27001, the question is not whether continuous testing is worth doing. The question is how to structure it so that the evidence it produces is legible to auditors.
Three things matter for audit legibility:
- Timestamped findings with a clear scope definition (what was tested, when, by whom)
- Remediation evidence showing that findings were acted on within your defined SLA
- Frequency that is proportionate to the pace of change in your system
A monthly scan of your production API surface, exported as a PDF with CVSS scores and remediation status, is a stronger audit artefact than an annual report that was accurate on one day 11 months ago.
The 364-day blind spot is a solvable problem. The tooling exists, the regulatory case for solving it is growing, and the cost of continuous testing has dropped enough that it is no longer a budget argument. It is a process argument — and process arguments are easier to win when the alternative is a compliance gap your auditor has already started asking about.