How Often Should You Pentest? Frequency Guide by Framework and Risk Level

How often should you actually pentest?

Most companies test once a year. They schedule it in Q4, file the report alongside their SOC 2 evidence, and move on. That's fine as a baseline. But it's not a strategy.

73% of organizations change their IT infrastructure every quarter. Only 40% adjust their security testing accordingly. That gap is exactly where attackers look.

This guide breaks down how often to pentest based on your compliance requirements, your risk level, and what's actually changing in your environment — so you can stop guessing and start scheduling intentionally.

The honest baseline: annual testing

Annual penetration testing is the floor, not the ceiling. If you're doing it once a year, you're meeting the minimum expectation of most compliance frameworks and security auditors. That's worth something.

But "annual" made sense when software releases took months and infrastructure barely changed. You're probably shipping code weekly. Your cloud footprint shifts every time an engineer spins up a new service. Your attack surface is not the same as it was 12 months ago.

Annual testing catches what's wrong today. It doesn't catch what went wrong last February.

That doesn't mean annual testing is useless — it means it needs to be the start of your testing program, not the whole of it.

What each compliance framework actually requires

PCI DSS

PCI DSS is the most prescriptive framework when it comes to pentest frequency. Requirement 11.4.3 mandates:

• External penetration testing at least annually
• Internal penetration testing at least annually
• Additional testing after any significant infrastructure or application upgrade or change

"Significant change" is deliberately broad. A new payment processor integration, a major application release, a cloud migration — all of these should trigger a targeted pentest, not just wait for the annual cycle. PCI DSS 4.0, now fully in effect, made this expectation explicit.

If you're in scope for PCI and handling cardholder data, once a year is the minimum — not the plan.

For a deeper breakdown of what PCI requires specifically, see our PCI DSS penetration testing guide.

SOC 2

SOC 2 doesn't mandate penetration testing frequency in the same explicit way PCI does. The framework is principles-based: you define your controls, you document them, you demonstrate they work.

What auditors actually expect is a different story. Most Type II auditors want to see an annual external pentest as evidence your security controls are validated, not just described. Enterprise customers reviewing your SOC 2 report will look for it too.

The safe answer: at minimum annually, and whenever you make material changes to your systems or architecture.

Our SOC 2 penetration testing guide covers exactly what auditors look for in the evidence package.

ISO 27001

ISO 27001:2022 doesn't explicitly require penetration testing at all — it's not named in Annex A controls. What it does require is that you conduct regular information security risk assessments and test your controls.

In practice, most certified organizations run annual pentests as part of their risk management process. ISO auditors will expect to see evidence that you're evaluating technical vulnerabilities systematically. A pentest report is the clearest way to demonstrate that.

If you're ISO-certified and not testing annually, you're creating an audit finding waiting to happen.

See: ISO 27001 penetration testing requirements

HIPAA

HIPAA's Security Rule requires covered entities to conduct risk analyses — but it doesn't say "penetration testing" by name. That's a bit of a loophole that many healthcare organizations have used to avoid formal testing.

HHS guidance and OCR enforcement actions tell a different story. Organizations that have suffered breaches and skipped systematic vulnerability testing have faced significant fines. A proposed HHS rule update is expected to make annual penetration testing an explicit requirement for covered entities and business associates.

If you're in healthcare and processing PHI, don't wait for the rule to become mandatory. Annual testing is the right baseline now, with additional testing for any new systems processing patient data.

GDPR, NIS2, and others

GDPR requires "appropriate technical and organizational measures" to protect personal data — penetration testing qualifies. There's no specified frequency, but data protection authorities in the EU have taken the position that annual security assessments are reasonable for most organizations processing personal data at scale.

NIS2, which applies to essential and important entities across the EU, requires organizations to have measures for testing and reviewing the effectiveness of cybersecurity risk management. Annual testing is the standard interpretation, with higher-risk sectors expected to test more frequently.

Risk-based frequency: the real framework

Compliance requirements are a floor. Your actual testing schedule should be driven by your risk profile.

High frequency (quarterly or more)

These organizations should test every quarter, at minimum:

• Financial services: High-value targets, strict regulatory expectations, complex transaction systems. Any change to payment flows, authentication systems, or customer-facing applications should be tested.
• Healthcare with large patient datasets: PHI is valuable on the dark web. Healthcare organizations are among the most targeted sectors, and the regulatory exposure from a breach is severe.
• Fintech and crypto: Rapid development cycles, public APIs, and money on the line. Attack surfaces change fast.
• Companies post-breach or post-incident: If you've been compromised, the question isn't whether you need more testing — it's how quickly you can get it scheduled.
• Organizations undergoing rapid growth: Acquisition, new product launches, team scaling — each adds infrastructure and people, both of which introduce risk.

Moderate frequency (twice a year)

• SaaS companies with enterprise customers: Enterprise buyers increasingly require evidence of recent testing before signing. Twice a year gives you a current report to show in any deal cycle.
• Organizations with significant cloud migration activity: Cloud environments are a common source of misconfigurations. Testing after a major migration and again 6 months later catches what the initial test missed.
• Mid-size companies processing sensitive data: If you handle financial data, personal data at scale, or sensitive employee data, annual isn't enough.

Annual testing

• Early-stage startups pre-product-market-fit, with limited attack surface and simple infrastructure
• Companies in stable environments with infrequent releases and predictable architecture
• Organizations testing primarily for compliance with a low-complexity scope

That said: if you're only testing annually and shipping code weekly, you should be honest with yourself about what that annual test is actually covering.

What should trigger an unscheduled pentest

Beyond your regular cadence, certain events should prompt additional testing regardless of when your last pentest was:

Major infrastructure changes. A cloud migration, a new data center, a significant network architecture change — these alter your attack surface in ways a 12-month-old pentest doesn't reflect.

New application launches or major releases. A major version release, a new customer-facing feature, a new API surface — especially if it touches authentication, authorization, or data handling.

M&A activity. Acquiring a company means inheriting their security posture. Pre-close security assessments are becoming standard in tech M&A. Post-close integration testing should be on your roadmap too.

New compliance requirements. If your customers or regulators are suddenly requiring a certain framework, don't wait for your annual cycle to get tested.

Security incidents. Any incident significant enough to trigger an internal review should also trigger a scoped pentest of the affected systems once remediated.

Significant staff changes. CTO or CISO turnover, major engineering team changes, or outsourcing decisions that affect system access.

The shift toward continuous testing

Annual pentesting is increasingly being supplemented — or replaced in some organizations — with more continuous approaches.

PTaaS (Penetration Testing as a Service) platforms offer ongoing access to security researchers who test your environment on a rolling basis rather than in discrete annual engagements. For companies shipping code daily, this model is starting to make more sense than a two-week annual engagement.

Gartner's CTEM (Continuous Threat Exposure Management) framework formalizes the concept: instead of periodic testing, organizations continuously discover, assess, prioritize, and validate their security exposures. It's a significant maturity jump, but one that larger security programs are moving toward.

The practical middle ground for most companies: a structured annual pentest for compliance purposes, supplemented with more targeted testing around major changes or launches.

For a comparison of testing approaches, see: Red team vs pentest vs vulnerability scan

A simple decision matrix

What actually drives the decision

If you're trying to answer this for your board or your own planning, three questions cut through it:

How often does your environment change? If your engineering team ships twice a week, you're introducing new risk twice a week. Annual testing covers a snapshot, not a moving target.

What does your compliance regime require? PCI is prescriptive. SOC 2 is expectation-based. Know which frameworks you're working against and what auditors actually look for.

What's the cost of getting it wrong? For a Series A SaaS company, a breach is reputationally expensive. For a healthcare provider or financial institution, it's potentially existential. That risk calculus should directly influence your testing budget and frequency.

The short version: test annually at minimum, more often if your environment changes frequently or your data sensitivity is high, and always test after major changes regardless of when the last test was.

One more thing: don't let "we just tested last year" become a reason to skip a test you know you need. The schedule is a floor, not an excuse. If something significant changed, test it.

The penetration testing cost guide covers what each type of test actually costs, which is usually the next question once you've sorted out frequency.

---

Figuring out how often to test is one thing — finding a provider worth trusting is another. Book a free consultation with our team and we'll walk you through what a pentest engagement looks like for your stack.