How Often Should You Run a Penetration Test? (Compliance-Mapped, 2026)
Short answer: run a penetration test at least once a year, and again after any significant change to your systems. That baseline satisfies most security programs. Your compliance regime can tighten it: PCI DSS expects an annual test, SOC 2 wants evidence across its review period, ISO 27001 sets cadence by risk, and NIS2 ties testing to your risk-management duty. Below is the rule per regime, plus the changes that should trigger an off-cycle test.
The honest answer is that "how often" depends on two things: what changes in your environment, and which framework you answer to. A static yearly date on the calendar is the floor, not the rule. A company shipping weekly and a company that froze its product two years ago should not test on the same schedule. Here is how to set a cadence that holds up to an auditor and actually reflects your risk.
The Baseline: Annually, Plus After Significant Change
Across every major framework and most security teams, two triggers recur:
1. At least once a year
An annual test is the accepted minimum for any system that touches customer data or sits on the public internet. A test from eighteen months ago does not describe the environment you run today. Annual cadence keeps your evidence current and your risk picture honest.
2. After any significant change
A pentest measures a moment. The moment you materially change the system, that measurement expires. Significant changes that should trigger a fresh test include:
- A major new feature or product line that handles sensitive data
- An infrastructure migration (new cloud provider, new network segment, datacenter move)
- A new public-facing service, API, or login flow
- A material change to your authentication or access model
- A merger or acquisition that brings new systems into scope
If you only test on a fixed annual date and ship significant change in between, you carry untested risk for the rest of the year. The "annual plus change-driven" model closes that window.
What Each Compliance Regime Actually Expects
The baseline gets sharper once a framework is involved. Here is the rule per regime, in plain terms.
PCI DSS: annual, and after significant change
PCI DSS is the most prescriptive. Requirement 11.4 calls for penetration testing at least once every twelve months and after any significant change to the cardholder data environment. Segmentation controls get tested on the same annual-plus-change basis. If you process card data, the calendar is set for you: yearly, with off-cycle tests whenever the in-scope environment changes materially.
SOC 2: tied to your review period, annual in practice
SOC 2 does not name a fixed interval. It is criteria-based, built on the AICPA Trust Services Criteria, and it asks you to monitor your controls (CC4.1) and detect and respond to vulnerabilities (the CC7 series). For a Type 2 report, which covers a period of three to twelve months, your auditor wants evidence that this monitoring ran across the whole window. In practice that means an annual penetration test, scheduled so a documented test with findings, remediation, and ideally a retest falls inside the review period. The cadence is driven by your audit window, but it lands on annual for almost everyone.
ISO 27001: risk-based, with annual as the practical default
ISO 27001 is risk-driven, not interval-driven. Annex A control 8.8 (technical vulnerability management) expects you to identify and treat vulnerabilities, and the standard leaves the testing frequency to your risk assessment. For a SaaS company with internet-facing systems, that risk assessment almost always lands on an annual test plus testing after significant change, which mirrors the universal baseline. The difference is that with ISO 27001 you have to document why your chosen cadence matches your risk, rather than pointing to a fixed clause.
NIS2: testing as part of your risk-management duty
NIS2 took effect for in-scope EU entities in 2026. It does not prescribe a pentest interval either. Instead it requires appropriate, proportionate technical measures to manage cyber risk, and security testing is a core way to prove those measures work. For most essential and important entities, that means an annual test plus testing after significant change, sized to the risk of the service you run. If your organization falls under NIS2 this year, an annual cadence is the defensible default, and you should be able to show that testing is part of an ongoing risk-management program, not a one-off.
Need to lock in a cadence you can actually keep? Pick your asset and compliance goal, see the test plan and tradeoffs live.
Scope and price your pentestHigher-Risk Situations That Warrant More Than Annual
Some environments justify testing more than once a year:
High-velocity development
If you ship significant change every few weeks, an annual test leaves long untested gaps. A continuous or quarterly cadence on the parts that change fits better.
Sensitive data at scale
Health data, financial data, or large volumes of personal data raise the cost of a missed vulnerability, which raises the value of testing more often.
Customer or contractual requirements
Enterprise buyers increasingly write a testing cadence into their vendor agreements. If a customer requires twice-yearly testing, that contract sets your floor.
The point is not to test more for its own sake. It is to match cadence to how fast your risk changes.
Why a Platform Makes the Right Cadence Easy to Keep
Setting a cadence is the simple part. Keeping it, across changing systems and several regimes at once, is where most teams slip. This is where running your testing through a platform rather than a string of one-off engagements pays off.
Budget Security is built for the security manager who has to run a program, not file a single report. When a significant change lands and you need an off-cycle test, you do not start from scratch. Your assets are already registered, so you pick the asset and the goal (full pentest, SOC 2 readiness, NIS2, ISO 27001) and the AI scoping engine proposes exactly what gets tested and how deep, then shows you the tradeoff live: add days for deeper coverage, or trim them and see precisely what gets cut and whether the scope still meets your stated compliance goal.
Cadence also gets easier because everything lives in one place. Retests confirm you closed last cycle's findings without rescoping a whole engagement. Multi-engagement history in the dashboard gives you a continuous trail of "we tested, we found, we fixed, we verified," which is exactly the operating-effectiveness evidence a SOC 2 Type 2 examiner or an ISO 27001 auditor wants to see across time. Instead of hunting for a PDF from last year buried in an email thread, you open one view that shows every test, every finding, and every fix.
The testing itself is run by OSCP-certified veterans, the same caliber you would expect from a premium consultancy. We kept that caliber and modernized everything around it, so holding an annual-plus-change cadence is a few clicks rather than a new sales cycle each time.
Setting Your Cadence: a Quick Rule of Thumb
- Start with annual. Book at least one test every twelve months. This is your floor under every regime.
- Add change-driven tests. Trigger an off-cycle test after any significant change to your in-scope systems.
- Layer your regime's specifics. PCI DSS sets annual plus significant change explicitly. SOC 2 aligns to your review period. ISO 27001 and NIS2 want a documented, risk-based cadence, which usually lands on annual plus change.
- Increase frequency if your risk is high. Fast release cycles, sensitive data, or contractual terms can push you to quarterly or continuous testing on the parts that change.
Get those four right and your cadence will satisfy an auditor and reflect your real risk, not just a date on a calendar.
Ready to Scope Your Test? Start Here
Pick your asset and your compliance goal, see the test plan and the tradeoffs live, and lock in a cadence you can actually keep.