How Often Should You Pentest?

Your last pentest report is clean and dated March. Since then the team has shipped 30 releases, a new billing API and a second user role. Nobody has tested any of that.

That gap is what the frequency question is really about. There are two answers: the minimum an auditor will accept, and what it takes to find a new hole before someone else does.

Applies 2026

• PCI DSS v4.0.1: internal and external pentests at least once every 12 months and after any significant change (Requirements 11.4.2 and 11.4.3).
• SOC 2 and ISO/IEC 27001: no fixed interval. Pentesting is one way to meet the criteria, and yearly is what auditors and enterprise buyers usually expect.
• DORA: yearly testing of ICT systems that support critical or important functions, and threat-led tests every 3 years for designated firms.
• Mandiant's mean time to exploit: 63 days in 2018 to 2019, 5 days in 2023, minus 7 days (estimated) in 2025.

Framework wording and threat figures were checked on 2026-09-26. The sources are listed at the end of the page.

What is the minimum pentest frequency by framework?

Only PCI DSS and DORA name an interval in the rule itself. The others ask you to test "regularly" or based on risk, and leave the number to you and your auditor. This table sticks to what each text says.

Two things stand out. First, "every 12 months" is the longest gap any of these allows, not a target. Second, PCI DSS ties testing to change as well as to the calendar, and the NIS2 rules point the same way. If you ship every week, the change trigger is the one that bites.

Why isn't an annual pentest enough anymore?

Because the time between a weakness appearing and someone exploiting it has collapsed, and a yearly test leaves each release untested for months.

Google's Mandiant tracks the average time from a vulnerability's disclosure to its first exploitation. The trend is hard to argue with.

A negative number means that, on average, exploitation starts before a patch exists. VulnCheck counted 884 vulnerabilities newly exploited in 2025, and 28.96% of them were exploited on or before the day their CVE was published (State of Exploitation 2026, 2026-01-21). CISA's Known Exploited Vulnerabilities catalogue listed 1,726 entries when we checked on 2026-09-26. In Mandiant's own incident work, exploits were the most common way in for the sixth year running, at 32% of intrusions (M-Trends 2026).

AI is speeding this up. In November 2025 Anthropic reported a state-linked campaign in which AI agents carried out 80 to 90% of the work against about 30 targets, at a pace of thousands of requests, often several per second. In May 2026 Google's Threat Intelligence Group reported the first zero-day exploit it believes was built with AI, and described attackers using AI models as "expert-level force multipliers for vulnerability research and exploit development".

To be fair about the evidence: these figures mostly describe known products such as VPNs, firewalls and CMS plugins, not your own code. Your app's bugs don't get CVE numbers. VulnCheck also found that AI-discovered vulnerabilities weren't exploited more often than others (14 of 1,061 in the first half of 2026), and Mandiant wrote that 2025 "was not the year where breaches were the direct result of AI". The case for testing often doesn't rest on AI hype. It rests on speed. Scanning, probing and building exploits are now cheap and fast, so the time a new weakness in your app stays unnoticed by attackers is shrinking.

Now do the arithmetic for an annual test. A bug that ships the week after the pentest stays in production, untested, for up to 51 weeks. With weekly releases, that's 50 or so releases nobody tested. Daily testing cuts that window to a day.

How often should you pentest your web app? A cadence by app type

Test as often as the app changes, and scale the depth to the risk. For most teams that means a fast daily pass, a deeper run every month or quarter, and a human-led test once a year or when the scope needs judgement.

A daily Light run isn't a replacement for a deep test. With 400 credits and 3 agents, it's a quick pass over the whole surface that catches the obvious regression on the day it ships, and it has no expert review. The monthly Deep run (4,000 credits, 20 agents, 2 hours of expert review) is where the harder findings turn up. Keep both.

Common mistake. Testing the day before the audit and calling it a program. An auditor sees a clean report. The next 11 months of releases see nothing.

What counts as a significant change?

PCI DSS doesn't give a full list, and NIS2 leaves it to what you "deem significant". So write your own definition down, apply it the same way each time, and keep the record. Auditors look for that record.

For a web app or API, we'd treat these as significant:

• A new or changed login, SSO, MFA or session handling.
• A new user role, a new tenant model or changes to who can see what.
• New API endpoints or GraphQL mutations that read or write sensitive data.
• Changes to payment, checkout or anything that touches cardholder data.
• A major framework, language or library upgrade.
• New third-party integrations, such as OAuth apps, webhooks or file uploads to external storage.
• Infrastructure changes in front of the app: a new domain, CDN, WAF rules or API gateway.
• A new data flow, such as exporting customer data to a new system.

Copy changes, styling and bug fixes that don't touch authentication, authorization or data handling usually aren't significant. Record the decision anyway.

A continuous schedule makes this question less stressful. If the app is tested every day, a change that you judged minor still gets tested the next morning.

How Barrion does it

Barrion's AI agents test web apps and APIs the way an attacker would, across 8 testing areas mapped to all 97 OWASP WSTG v4.2 test cases. You can save a pentest and put it on a schedule: daily, weekly, monthly, quarterly, every six months, yearly, or a custom rhythm. One app can have several schedules, for example a daily Light run plus a monthly Deep run.

Each schedule has its own scope and depth. You choose whether it runs every time, or only when your app has changed. Change detection compares a snapshot of the start page's links and scripts with the last one, so a backend-only release can slip past it. That's why we suggest keeping at least one every-time schedule. You can also trigger runs from your CI/CD pipeline via the Barrion API, so a release to staging or production starts a pentest on its own.

Every run labels its findings new, still open, resolved or regressed, so a fix that came undone shows up the day it comes back. Findings are checked against the live app before they're reported. Ones that can't be confirmed are kept as lower-confidence leads, not counted as vulnerabilities. From Standard level up (1,000 credits), a security engineer reviews each report.

What we don't test: internal networks, Active Directory, mobile apps, physical security, social engineering, and TLPT under DORA. If PCI DSS 11.4 applies to you, the internal network part still needs a specialist, and your assessor decides whether a report counts as your yearly test.

You can start a pentest yourself. Scheduled pentests are part of the Business plan, which you arrange with sales. Continuous programs are scoped to your apps, cadence and depth. Talk to us and we'll price it for your setup.

For more on the model, read what continuous pentesting is and how it compares in continuous vs annual pentests. What a single run costs is on the pentest cost page, and what a year-round program costs is in continuous pentesting cost.