How Often Should You Run a Penetration Test?

The short answer: at least once a year, and more often when compliance frameworks, environmental changes, or your risk profile call for it.


The longer answer is more useful, because the right cadence for a SaaS company shipping daily is not the right cadence for a regional bank running quarterly releases. This post lays out a framework for setting pen test frequency based on three drivers: compliance requirements, change-driven triggers, and risk. It also covers the most common mistake, which is treating annual testing as enough when it almost never is.


The Three Drivers of Pen Test Frequency

Every reasonable testing cadence comes from three inputs.

    Compliance requirements set the floor

    If a framework you must comply with says "at least annually," that is your minimum.

    Change-driven triggers force fresh tests outside the calendar

    A pen test report describes your environment at one moment. Significant changes invalidate that snapshot.

    Risk dictates whether you test more often than the floor

    The more sensitive your data, the faster your code changes, the more exposed your attack surface, the higher your testing cadence should be.

    Most companies stop at compliance. The ones that take security seriously layer change-driven testing and risk-based testing on top.


    Pen Test Frequency by Compliance Framework

    If you are subject to one or more of these frameworks, this is your baseline.

     FrameworkMinimum Frequency Key Notes 
     PCI-DSS 4.0 / 4.0.1Annual, plus after any significant change Requirement 11.4. Segmentation testing annually for all entities (11.4.5) and every six months for service providers (11.4.6). Documented methodology and retesting required. 
     SOC 2 (Type I and II) Annual (practice, not explicit mandate)Trust Services Criteria do not specify frequency. Auditors expect annual testing inside the audit window. 
     HIPAA Annual (practice, not explicit mandate)Security Rule requires risk analysis and reasonable safeguards. Annual testing is the established practice for handling PHI. 
     ISO/IEC 27001:2022 Annual (practice, not explicit mandate)Annex A controls point to regular vulnerability and technical compliance reviews. Reinforced by the three-year recertification cycle. 
     CMMC AnnualRequired at Level 2 and above for contractors handling Controlled Unclassified Information (CUI). 
     FedRAMP Annual Required for authorized cloud service offerings, with results submitted to the sponsoring agency.
     NIST CSF / NIST 800-53 Organization-defined (annual is the floor) Control CA-8 governs pen testing. Quarterly testing is common for high-impact systems.

    Requirements in Detail

    PCI-DSS 4.0 / 4.0.1

    Requirement 11.4 mandates internal and external penetration testing at least annually and after any significant change to infrastructure, applications, or network segmentation controls. Segmentation testing has its own cadence. Under Requirement 11.4.5, all entities using segmentation must validate it at least annually. Under Requirement 11.4.6, service providers must validate segmentation at least every six months. PCI-DSS 4.0.1 also requires a documented testing methodology, retesting after remediation, and CVSS-rated findings. The future-dated requirements became mandatory on March 31, 2025.

    SOC 2 (Type I and Type II)

    SOC 2 does not mandate a specific pen test frequency in the Trust Services Criteria. Annual penetration testing is the practical standard, and most auditors expect to see it. SOC 2 Type II covers a 6-to-12-month period, so a missing or expired pen test report shows up clearly during the audit. If you have a Type II audit on the calendar, schedule the pen test so the report is dated inside the audit window.

    HIPAA

    HIPAA does not explicitly require penetration testing. The Security Rule requires risk analysis and reasonable safeguards, and the Office for Civil Rights (OCR) has consistently treated pen testing as evidence of due diligence. Annual testing is the established practice for covered entities and business associates handling protected health information (PHI), with additional testing after any change that affects how PHI is stored, processed, or transmitted.

    ISO/IEC 27001:2022

    ISO 27001 does not mandate a fixed pen testing cadence. Annex A controls covering vulnerability management and technical compliance reviews point toward regular testing. Annual is the norm, and the three-year recertification cycle reinforces it. Significant change should trigger an additional test under your information security management system.

    CMMC

    For Department of Defense contractors handling Controlled Unclassified Information (CUI), penetration testing is part of the periodic assessment expectations at Level 2 and above. Annual testing is standard and expected by C3PAOs during certification assessments.

    FedRAMP

    Authorized cloud service offerings require annual penetration testing, with results submitted to the sponsoring agency as part of continuous monitoring.

    NIST Cybersecurity Framework (CSF) and NIST 800-53

    Frequency is "as defined by the organization," with control CA-8 governing penetration testing. Annual is the floor most federal and federal-adjacent organizations use, with quarterly testing for high-impact systems.

    The Simple Combo Rule

    If you are subject to multiple frameworks, take the strictest frequency requirement across all of them. Do not run two separate testing programs.

    Change-Driven Testing

    Calendars are not the only trigger. The most common phrase across compliance frameworks is "and after any significant change," which is left vague on purpose. Frameworks expect you to define what counts as significant for your environment and document it.


    In practice, run a fresh pen test when any of the following happen:

    You change segmentation controls, including firewall rules, VLAN changes, or new isolation methods

    You migrate critical infrastructure, including cloud platform changes, datacenter moves, or network re-architecture

    You complete a merger, acquisition, or carve-out that brings new systems into scope

    You change your authentication or identity provider

    You add a new third-party integration that touches sensitive data or extends trust into your environment

    Your compliance scope expands, including new regulated systems, new geographic markets, or new data classifications

    You launch a new application or major feature with new authentication, payment processing, or sensitive data handling

    A working rule: if a change would alter the diagram you showed your last pen tester, the new state should be tested.

    Risk-Based Testing for Companies Without Compliance Pressure

    If no compliance framework forces your hand, frequency comes from risk. Four questions drive cadence:

    How sensitive is the data you handle?

    How often does your code or infrastructure change?

    What would a breach actually cost your business in dollars, downtime, and customer trust?

    How exposed is your attack surface, including public web apps, APIs, remote workforce, and third-party integrations?

    A reasonable starting framework:

    Customer-Facing Applications and APIs

    Test continuously or quarterly. These are the highest-traffic targets and they change the most.

    Production Cloud Infrastructure

    Test annually with ad hoc testing after major architecture changes.

    Internal Networks and Corporate IT

    Test annually for most companies. Larger or more sensitive environments may justify semi-annual testing.

    Mobile Applications

    Test before each major release. At minimum, annually.

    Companies under fast-changing conditions, including SaaS startups in active development and regulated firms scaling quickly, often outgrow annual testing within their first 18 months.

    The Annual Test Gap

    The most common cadence is once a year. It is also the cadence most likely to leave you exposed.


    If you test in January and finish remediation by March, you have about nine months until the next test. In those nine months your developers ship features, your infrastructure shifts, new vulnerabilities are published in the libraries you depend on, and threat actors learn new techniques. By December, the environment your pen tester signed off on is gone.


    The annual pen test gives you confidence at the moment of the test and decreasing confidence every week after. By the time the next test runs, the report is mostly historical.


    This is one of the reasons Penetration Testing as a Service (PTaaS) has become more common. It replaces the annual snapshot with continuous coverage so the gap stops growing.

    How to Build a Testing Cadence That Fits Your Business

    Three steps.

    Set the Floor with Compliance

    List every framework that applies to your business. Take the strictest frequency requirement across all of them.

    Add Change-Driven Triggers

    Document the changes in your environment that should trigger a fresh test. Build the trigger list into your security program documentation and your change management process so it gets caught.

    Adjust Upward for Risk

    If your business handles sensitive data, ships fast, or operates in a high-threat sector, increase frequency above the floor.

    Review the cadence annually. As your environment, customer base, and regulatory exposure change, the right cadence changes with it.

    How APT Helps You Find the Right Cadence

    APT Security Management offers pen testing through a prepaid token model. You buy tokens, then spend them on testing as you need it. The same balance covers other services if you need to draw from it. Tokens are valid for 12 months from purchase.


    For companies that prefer a defined engagement with a fixed price, APT also offers flat-rate Penetration Testing as a Service (PTaaS) packages with set scope and deliverables. Both options include manual testing by OSCP- and CISSP-certified testers, retesting on remediated findings, and audit-ready reporting for SOC 2, PCI-DSS, HIPAA, and ISO 27001.


    A 30-minute consultation will tell you what cadence makes sense for your environment. We look at your compliance requirements, your release cycle, and your current testing posture, and recommend the cadence that fits, not the one that maximizes your invoice.

    Frequently Asked Questions

    How long does a penetration test take?

    Most engagements run one to four weeks of active testing, plus one to two weeks for reporting. Scope drives the timeline. A small web application is faster than an enterprise network with cloud and segmentation testing.

    Is annual penetration testing enough for SOC 2 Type II?

    For most SOC 2 environments, yes. Auditors expect annual testing inside the audit window. If your environment changes significantly during the audit period, additional testing is the safer call. Talk to your auditor early if you are unsure.

    Does penetration testing replace vulnerability scanning?

    No. Vulnerability scanning is automated and runs continuously or weekly. Penetration testing is performed by humans and tests business logic, chained exploits, and actual exploitability. Compliance frameworks generally require both.

    What counts as a "significant change" that requires retesting?

    Frameworks leave this to you to define. Common triggers include new application launches, major infrastructure migrations, identity provider changes, segmentation rule changes, mergers and acquisitions, and changes that expand compliance scope.

    Can we test more often without paying more each time?

    Yes, depending on the model. A subscription or token-based PTaaS arrangement lets you draw on testing capacity throughout the year rather than scoping a new engagement each time.

    Set the right testing cadence for your environment

    Book a free 30-minute consultation. We will look at your compliance requirements, your release cycle, and your current pen testing posture, and recommend a cadence that fits. 

    Book a Free Consultation