A penetration test report has no legal expiry date, but in practice it is treated as valid for about 12 months, and after that most enterprise customers and procurement teams reject it. A material change to your application or infrastructure can void it much sooner, which is why "how old is the report" is only half of the question a buyer is really asking.
Teams staring at a report dated last year and wondering whether it will clear a security review need three answers: the practical acceptance window, the frameworks that set the clock, and the changes that reset it early. This post covers all three.
How long is a penetration test report valid before customers or procurement teams require a new one?
The working answer in 2026 is twelve months. Enterprise customers conducting vendor assessments typically expect a penetration test performed within the past 12 months, and that expectation shows up directly in vendor security questionnaires before contracts are signed (Safe Security, Vendor Security Questionnaire best practices).
That number is a convention, not a law. No standard stamps an expiry date on the PDF. Instead, validity is decided by three separate clocks running at the same time:
The customer or procurement acceptance window. The most common rule your buyers apply, usually 12 months, sometimes tighter for regulated or high-risk deals.
The compliance framework that governs you. PCI DSS, SOC 2, ISO 27001, and DORA each set their own cadence, and some are stricter than the generic 12-month norm.
Material change. A significant change to the tested environment can invalidate a report on the day it ships, regardless of the date on the cover.
A report is "still valid" only when all three clocks agree. Miss any one and a buyer can, and often will, ask for a new test.
Figure 1: The practical validity curve buyers apply. A report reads as fresh early, aging past six months, and commonly rejected past twelve months or after a material change. Source: common enterprise procurement acceptance windows, per Safe Security vendor questionnaire guidance.
What each framework actually requires
If a specific compliance regime applies to you, its cadence overrides the generic 12-month convention, and in some cases it is the reason procurement is asking in the first place. The table below summarizes the reported third-party requirements, attributed to each framework. These are the frameworks' own rules, not a Stingrai adjudication of any audit outcome.
Framework | Reported testing cadence | Retest trigger | Source |
|---|---|---|---|
PCI DSS 4.0.1 (req 11.4.2 internal, 11.4.3 external) | At least once every 12 months | After any significant infrastructure or application upgrade or change | |
PCI DSS 4.0.1 (req 11.4.5 segmentation) | At least once every 12 months | After any change to segmentation controls or methods | |
SOC 2 Type II | A test performed inside the observation window (commonly 6 to 12 months) | Test outside the window does not evidence operating effectiveness | |
ISO 27001:2022 (Annex A 8.29) | No fixed interval set; annual is the widely accepted minimum | After significant infrastructure or application change | |
DORA (Articles 26 to 27, TLPT) | Threat-led penetration testing at least every 3 years for identified financial entities | Frequency may be adjusted by the competent authority |
Two details in that table catch teams out.
First, PCI DSS 4.0.1 is explicit and the strictest of the common four. Requirements 11.4.2 and 11.4.3 call for internal and external penetration testing "at least once every 12 months" and "after any significant infrastructure or application upgrade or change" (PCI SSC, PCI DSS v4.0.1). PCI's future-dated requirements became mandatory on 31 March 2025, so this is not a forward-looking nicety, it is the current bar for anyone in scope.
Second, SOC 2 Type II cares about when the test happened relative to your audit period, not just its age. SOC 2 does not name penetration testing as a hard requirement, but auditors commonly treat it as evidence for CC4.1, the control that requires the entity to evaluate whether its controls are present and functioning. A test conducted outside the observation window (commonly 6 to 12 months) does not evidence operating effectiveness during the period under review (AICPA, SOC 2). A perfectly recent report can still be the wrong report if it lands outside your window.
Figure 2: Reported testing cadence by framework. Sources: PCI SSC (PCI DSS v4.0.1), AICPA (SOC 2), ISO/IEC 27001:2022 Annex A 8.29 guidance, and EU DORA Articles 26 to 27.
When a change forces a retest before 12 months
Age is the obvious clock. Material change is the one that surprises teams, because it can void a report the week after it ships. Every major framework builds a change trigger into its cadence, and buyers increasingly ask "has anything significant changed since the test" as a follow-up question in their questionnaires.
PCI DSS gives the clearest reference point for what "significant" means. Its guidance describes a significant change as, among other things, new hardware or software added to the environment, major upgrades, changes to how account data flows or is stored, changes to the boundary or scope of the assessment, changes to supporting infrastructure such as directory or logging services, and changes to third-party providers (PCI SSC, significant change FAQ). ISO 27001 practice echoes the same idea: test again after significant infrastructure changes, major application releases, or a security incident (ISO/IEC 27001:2022 Annex A 8.29 guidance).
In plain terms, treat the report as stale, regardless of its date, when any of the following happens:
A major application release that changes authentication, authorization, payment, or data-handling logic.
New authentication or access-control (a new SSO provider, a new role model, a new API surface).
New or re-architected infrastructure (a cloud migration, a new external service, a change to network segmentation).
A merger or acquisition that brings unfamiliar systems into scope.
A scope change that puts assets in front of users that the last test never touched.
A security incident that suggests the previous coverage missed something.
Figure 3: Material change triggers that can void a report before the 12-month mark. Change definitions per PCI SSC and ISO/IEC 27001:2022 Annex A 8.29 guidance.
The uncomfortable reality is that a fast-moving product team can outrun an annual test in a single quarter. Ship a new checkout flow in month three and the report on file describes an application that no longer exists.
What buyers actually reject in 2026
Procurement teams and security reviewers are not reading your report for pleasure. They are looking for reasons to accept or reject it quickly. The common rejection triggers:
Older than 12 months. The single most frequent reject. The date on the cover is past the acceptance window in the questionnaire.
Wrong window for the audit. For a SOC 2 Type II buyer, a test that falls outside their observation period does not count, even if it is recent.
Scope mismatch. The report covers a marketing site or a single API, but the deal is about the product the customer will actually use.
Stale after a known change. The buyer knows you shipped a major release, migrated clouds, or acquired a company, and the report predates it.
No evidence of remediation. High and critical findings with no retest or fix confirmation reads as unresolved risk.
None of these are about the quality of the original test. They are about whether the evidence still describes the thing being bought, today.
How continuous testing keeps the report inside the window
The annual human penetration test is the anchor of a credible security program, and it is not going anywhere. The problem is the eleven months in between, where product ships, infrastructure changes, and the report on file drifts further from reality until a buyer flags it as stale.
Continuous testing closes that gap. Rather than a single point-in-time snapshot that ages for a year, Penetration Testing as a Service keeps evidence current between the deep annual engagements, so the customer-facing report reflects the application as it exists now, not as it existed last spring. Our take on the tradeoff is in Continuous Red Teaming vs the Annual Pentest and Continuous PTaaS, Explained.
This is exactly where Stingrai's AI agent, Snipe, earns its place. Snipe is an autonomous web application penetration testing agent built to hunt the complex, high-impact classes that generic scanners miss, including IDOR, broken authorization, and business logic flaws. It runs black-box dynamic testing and white-box source review, generates AutoFix pull requests for what it finds, and can run as a PR-gating check on every pull request. When a material change lands, that is precisely the event that would otherwise void your report, Snipe re-tests the changed code before it merges, so the evidence stays current instead of going stale in production.
The result is a report that keeps describing the live application, backed by senior penetration testers who validate the high-severity findings. That is how you hand a procurement team a report that clears the window, on the first pass. Stingrai's testing supports your SOC 2, ISO 27001, PCI DSS 4.0, and DORA compliance programs by keeping the evidence current for your audits. For a deeper look at what a strong report should contain, see How to Evaluate a Penetration Test Report.
Frequently Asked Questions
How long is a pentest report valid?
In practice, a penetration test report is treated as valid for about 12 months. There is no legal expiry, but enterprise customers conducting vendor assessments typically expect a test performed within the past 12 months, and vendor security questionnaires reflect that (Safe Security). A material change to the tested environment can void it sooner.
When does a pentest report expire?
A report does not "expire" on a fixed date, but it stops being accepted when it passes the buyer's acceptance window (commonly 12 months) or when a significant change to the application or infrastructure makes it no longer representative. PCI DSS 4.0.1 requires re-testing after any significant change and at least every 12 months (PCI SSC).
Is my pentest report still valid if it is older than 12 months?
Usually no for procurement purposes. Most enterprise customers set their acceptance window at 12 months, so a report past that mark is commonly rejected in a vendor security review (Safe Security). If a compliance framework applies, its cadence, such as PCI DSS 4.0.1's 12-month rule, sets the same or a stricter bar.
Does PCI DSS require annual penetration testing?
Yes. PCI DSS 4.0.1 requirements 11.4.2 and 11.4.3 require internal and external penetration testing at least once every 12 months and after any significant infrastructure or application upgrade or change. These future-dated requirements became mandatory on 31 March 2025 (PCI SSC, PCI DSS v4.0.1).
Does SOC 2 require a specific pentest date?
SOC 2 does not mandate a penetration test by name, but auditors commonly treat it as evidence for control CC4.1. For a Type II report, the test should fall inside the observation window (commonly 6 to 12 months), because a test outside the window does not evidence operating effectiveness during the period under review (AICPA, SOC 2).
What counts as a significant change that voids a report?
PCI DSS describes a significant change as new hardware or software in the environment, major upgrades, changes to how account data flows or is stored, changes to the scope or boundary of the assessment, changes to supporting infrastructure, or changes to third-party providers (PCI SSC, significant change FAQ). In everyday terms, a major release, a new authentication system, a cloud migration, or an acquisition should trigger a fresh test.
How often does ISO 27001 require penetration testing?
ISO 27001:2022 does not set a fixed interval. Annex A 8.29 requires security testing, and annual testing is the widely accepted minimum in practice, with additional testing after significant infrastructure or application changes (ISO/IEC 27001:2022 Annex A 8.29 guidance).
Can continuous testing keep my report from going stale?
Yes. Continuous PTaaS keeps evidence current between annual human engagements, so the report reflects the live application rather than a year-old snapshot. Stingrai's Snipe agent re-tests on significant change and gates pull requests in CI, keeping evidence inside the 12-month window buyers expect.
References
PCI Security Standards Council. PCI DSS v4.0.1, Requirement 11.4 (Penetration Testing). 2024. https://www.compliancepoint.com/assurance/pci-dss-v4-0-vuln-pen-requirements/. Requires internal and external penetration testing at least once every 12 months and after any significant change; future-dated requirements mandatory 31 March 2025.
PCI Security Standards Council. FAQ: What is meant by "significant change" in PCI DSS? https://www.pcisecuritystandards.org/faq/articles/Frequently_Asked_Question/What-is-meant-by-significant-change-in-PCI-DSS/. Official PCI SSC guidance describing the activities that qualify as a significant change.
AICPA. SOC 2 (System and Organization Controls). https://www.aicpa-cima.com/topic/audit-assurance/audit-and-assurance-greater-than-soc-2. SOC 2 Type II evaluates control effectiveness over an observation window; penetration testing is commonly used as CC4.1 evidence.
ISO / ISMS guidance. ISO/IEC 27001:2022 Annex A 8.29, Security testing in development and acceptance. https://www.isms.online/iso-27001/annex-a-2022/8-29-security-testing-in-development-acceptance-2022/. Requires security testing; no fixed interval, with annual as the widely accepted minimum in practice.
European Union. Digital Operational Resilience Act (DORA), Article 26 (Advanced testing / TLPT). https://www.digital-operational-resilience-act.com/Article_26.html. Identified financial entities must carry out threat-led penetration testing at least every 3 years, aligned to TIBER-EU.
Safe Security. Vendor Security Questionnaire (VRAQ) Best Practices. https://safe.security/resources/blog/vendor-security-questionnaire-vraq-best-practices/. Enterprise customers conducting vendor assessments typically expect a penetration test performed within the past 12 months.
