BLOG

By David Chernitzky, Co-Founder and CEO, Armour Cybersecurity  |  Serving organizations across Canada, the US, and beyond  |  Last updated August 20, 2026

Quick answer: Most compliance frameworks require penetration testing at least annually, and annual testing is the right baseline for most mid-market organizations. Annual alone is not sufficient when the environment changes significantly between tests: new application launches, infrastructure migrations, cloud adoptions, mergers, and major code releases all introduce new vulnerabilities that an annual test will not catch if they are introduced eleven months after the previous test. A complete penetration testing cadence combines annual full-scope testing for compliance and baseline validation with targeted testing triggered by material changes to the environment.

Key Takeaways

• Annual penetration testing is the compliance baseline required by PCI DSS, SOC 2, ISO 27001, and most other frameworks that mandate penetration testing. Organizations that conduct penetration testing less frequently than annually will face compliance findings and, more importantly, will leave material vulnerability windows between tests.
• The vulnerability window between annual tests can be significant. An organization that launches a new customer-facing application in month two of a twelve-month testing cycle has that application running in production for ten months before it is tested. Major changes should trigger targeted testing rather than waiting for the annual cycle.
• Change-triggered testing is not a replacement for annual testing. The annual test provides a full-scope baseline; change-triggered testing covers the specific new attack surface introduced by the change. Both are needed in a complete testing program.
• Organizations with active software development programs, particularly those that release code to production frequently, benefit from integrating security testing into the development lifecycle rather than relying solely on periodic penetration tests. This integration does not replace penetration testing but reduces the vulnerability introduction rate between tests.
• The cost of penetration testing should be evaluated against the cost of a breach or compliance failure, not against the cost of other security tools. A penetration test that identifies a critical vulnerability before an attacker does averts losses that are typically many times the cost of the test.

What Compliance Frameworks Require

The most specific penetration testing frequency requirements come from PCI DSS. Requirement 11.4 mandates external and internal penetration testing at least once every 12 months and after any significant infrastructure or application changes. For organizations that use network segmentation to reduce PCI scope, segmentation controls must also be tested: merchants test segmentation at least once every 12 months (Requirement 11.4.5), while service providers face a stricter cadence and must test segmentation at least every six months (Requirement 11.4.6). PCI DSS is the framework most prescriptive about penetration testing cadence; its 12-month requirement is the minimum, and the service-provider segmentation requirement drives a semi-annual cadence for those entities.

SOC 2 does not prescribe a specific penetration testing frequency but expects evidence of penetration testing as part of the monitoring controls. Most SOC 2 auditors expect annual penetration testing at minimum, and organizations that present penetration test results from more than 12 months prior during an audit may face a finding that their evidence is stale. ISO 27001 Annex A control A.8.8, which covers management of technical vulnerabilities, similarly does not prescribe a specific frequency but expects a systematic approach to identifying and addressing vulnerabilities, which auditors typically interpret as requiring at least annual penetration testing alongside continuous vulnerability management. HIPAA’s technical safeguard evaluation requirement is interpreted by regulators as requiring regular, periodic testing of technical controls, which most healthcare compliance advisors interpret as annual penetration testing at minimum.

When Annual Testing Is Not Enough

Application launches

Every time a new application or significant new application feature is launched into a production environment accessible by users or the internet, a new attack surface is created that has not been tested under adversarial conditions. An application that has been through code review and QA testing has had its functionality evaluated from a correctness perspective, not a security perspective. The authentication implementation, the session management, the input validation, the access control model, and the business logic of the new application have not been evaluated by someone attempting to exploit them. Launching an application without penetration testing, and waiting for the annual test cycle to cover it, means the application runs in production for a period that could extend to nearly a year with unknown exploitable vulnerabilities.

Application penetration testing before or immediately after launch is the most effective point in the lifecycle to find and remediate application vulnerabilities: the code is fresh, the developers are still familiar with it, and remediations can be implemented without the complexity of working around dependent features that were built on top of the vulnerable code after launch.

Infrastructure migrations

Infrastructure migrations, including data center migrations, cloud migrations, and major network redesigns, introduce new configurations, new connectivity paths, and new access patterns that have not been tested. A cloud migration that moves workloads from an on-premises data center to AWS or Azure creates a new environment governed by cloud-native security controls (IAM policies, security groups, storage bucket permissions) that are configured by the migration team and have not been validated by adversarial testing. Cloud misconfigurations are among the most common and most significant findings in modern penetration tests, and many of them are introduced during migration events when the primary focus is on functionality rather than security configuration.

A penetration test of the cloud environment shortly after migration completion, before the new environment is relied upon for production workloads, identifies configuration issues when they are easiest to remediate. Waiting for the annual test cycle means the cloud environment runs with unknown misconfiguration for a period that could extend to eleven months.

Mergers and acquisitions

Mergers and acquisitions introduce the acquired organization’s entire technology stack, network infrastructure, and security posture into the acquiring organization’s environment. The acquiring organization typically has limited knowledge of what vulnerabilities exist in the acquired environment, and the integration process, which often involves connecting the two organizations’ networks and extending access across organizational boundaries, creates new attack paths that did not exist before the acquisition. Penetration testing of the acquired environment as part of technical due diligence, or immediately after integration, is a standard practice in organizations with mature security programs precisely because M&A events consistently produce significant new exposure that pre-existing annual testing did not cover.

Significant code releases

Organizations with active software development programs that make frequent, significant changes to their applications face a challenge that annual penetration testing alone cannot address: the application that was tested a year ago may look very different from the application running today. Major code releases that introduce new features, new integrations, new data handling, or significant changes to the authentication or authorization model should trigger application penetration testing of the changed functionality before or shortly after release.

This does not require a full-scope application penetration test for every release. Focused testing of specific new features or components, scoped to the changed attack surface, is more efficient than repeating the full application test and produces targeted findings relevant to the changes. Over time, as the testing program matures, this change-triggered testing can be partially displaced by integrating security testing into the development pipeline, which catches common vulnerability classes earlier in the cycle.

Building a Complete Testing Cadence

A complete penetration testing cadence for a mid-market organization combines three types of testing activity. The first is the annual full-scope test: a comprehensive engagement covering the external perimeter, internal network, and primary applications, conducted against the full scope of the organization’s environment and producing the compliance documentation that annual framework requirements demand. The second is change-triggered testing: focused engagements scoped to new applications, migrated environments, or significantly changed attack surfaces, conducted when the change is introduced rather than waiting for the annual cycle. The third is periodic targeted testing of high-risk areas: for organizations with significant web application attack surfaces, quarterly or semi-annual application testing of the highest-risk application components maintains more current coverage of the application security posture than annual testing alone. Choosing among these depends on which types of penetration testing map to your actual attack surface.

The annual full-scope test is the baseline that no organization should fall below. Change-triggered testing is the addition that prevents the annual test from being a snapshot of a twelve-month-old environment. Together, they produce a testing program that provides both compliance documentation and genuine security validation throughout the year. Armour Cybersecurity supports all three types of testing activity with OSCP-certified consultants and a scoping process designed to match the test type and scope to the organization’s specific change events and compliance requirements. To discuss the right cadence for your environment, visit the penetration testing service page.

Frequently Asked Questions

Does the size of our organization affect how often we should test?

Organization size affects testing scope and cost more than testing frequency. A larger organization with a more complex environment requires a broader scope for each test and a more nuanced change-triggered testing program because more changes occur more frequently. But the fundamental drivers of testing frequency, compliance requirements and material environment changes, apply to organizations of all sizes. A 50-person organization that launches a customer-facing application, handles sensitive data, or operates under a compliance framework requiring annual testing should test annually regardless of its size. A 500-person organization with the same characteristics should also test annually, with a broader scope. The frequency question is driven by compliance requirements and change events; the scope question is driven by environment complexity and size.

What should we do between annual penetration tests to maintain security?

Between annual penetration tests, the primary ongoing security activities are vulnerability management (continuous or monthly scanning and tracked remediation), security monitoring through a SIEM and EDR platform, access review on the quarterly cadence that most compliance frameworks require, and security awareness training including phishing simulation. These activities maintain hygiene and monitor for emerging threats in the intervals between penetration tests. They do not replace penetration testing because they do not perform manual adversarial validation, but they reduce the vulnerability introduction rate and increase the likelihood that new vulnerabilities introduced during the year are identified through monitoring rather than left undetected until the next penetration test. When a test does surface findings, the work that follows is a structured remediation process: assigning ownership, setting severity-matched timelines, and retesting to confirm closure.

How does penetration testing frequency interact with bug bounty programs?

Bug bounty programs invite external researchers to find and responsibly disclose vulnerabilities in exchange for monetary rewards. They complement penetration testing rather than replacing it. Bug bounty programs provide continuous, crowdsourced security research by a large number of diverse researchers with different skills and approaches. Penetration testing provides structured, scoped, methodology-aligned assessments with documented findings, reproducible evidence, and compliance-ready reports. Bug bounty programs do not produce the structured deliverables that compliance frameworks require from penetration testing; penetration tests do not provide the continuous, broad researcher engagement that bug bounty programs deliver. Organizations that operate both benefit from the breadth and continuity of bug bounty alongside the structure and compliance documentation of penetration testing.

How much does it cost to increase penetration testing frequency?

The cost of increased penetration testing frequency depends on the scope of each test and the provider relationship. Full-scope annual tests are the most expensive single engagements; change-triggered tests scoped to specific new applications or migrated environments are typically smaller in scope and cost proportionally less. Organizations that build a long-term relationship with a penetration testing provider often negotiate retainer arrangements that provide a defined number of testing days per year, which can be allocated across annual full-scope tests and targeted change-triggered engagements at a lower per-day rate than individual project pricing. The cost of more frequent testing should be evaluated against the alternative: the cost of a breach involving a vulnerability that was introduced during a change event and sat undetected for months because the next annual test had not yet been conducted.

What is the right penetration testing cadence for a company preparing for its first SOC 2 audit?

For an organization preparing for a first SOC 2 audit, the penetration testing cadence should be driven by the audit timeline. A SOC 2 Type II audit covers an observation period, typically six to twelve months. Penetration testing conducted during the observation period and with findings remediated within the period is the evidence that satisfies the CC4.1 monitoring control requirement. Ideally, the penetration test is conducted early in the observation period so that identified findings can be remediated during the period, demonstrating both the testing activity and the remediation response. A penetration test conducted in the final weeks of the observation period with findings not yet remediated presents a weaker compliance picture than one conducted with sufficient time for documented remediation before the audit. After the initial certification, annual testing maintains the compliance posture for subsequent audits.

The Bottom Line

Annual penetration testing is the floor, not the whole strategy. It satisfies the baseline that PCI DSS, SOC 2, ISO 27001, and HIPAA all expect, and it gives you a full-scope snapshot of your security posture once a year. The gap that annual-only testing leaves is the eleven months in between, when application launches, cloud migrations, mergers, and major code releases introduce new attack surface that the last test never saw. A complete cadence layers change-triggered testing on top of the annual baseline: focused engagements scoped to each material change, plus periodic targeted testing of your highest-risk application components if your web attack surface warrants it. Service providers using segmentation carry the added six-month segmentation testing cadence. The right program is driven by your compliance obligations and your rate of change, and it should be evaluated against the cost of a breach, not the cost of other tools. Armour Cybersecurity scopes annual, change-triggered, and targeted penetration testing with OSCP-certified consultants, matched to your environment and your framework requirements.