Pentest Report Shelf Life: When Penetration Test Results Expire
A pentest report is a snapshot of an asset at a point in time, and shelf life is the question of how long that snapshot stays defensible. Buyers ask it at every renewal. Vendors send it to procurement teams who hold it against a different cadence. Auditors read it against the framework the engagement was scoped under. The answer is rarely a single number; it is a small set of rules that interact with the asset, the framework, and the changes that have shipped since the test ended.1,3,5
This research lays out the cadence rules across PCI DSS, SOC 2, ISO 27001, FedRAMP, HITRUST, and CREST, the significant-change triggers that reset the clock before the calendar fires, the vendor-review reading of report validity, and the operational discipline that keeps the report durable rather than expiring quietly in a shared drive. The argument is not that twelve months is the right window or the wrong window. The argument is that the validity claim has to be explicit, written, paired to the in-scope asset description, and reproducible at audit time.3,4,6,7
The shelf life question is two questions, not one
When a buyer asks how long a pentest report is valid for, the request collapses two separate questions into one sentence. The first is the calendar question: what is the cadence the framework expects between engagements. The second is the change question: what events inside that calendar invalidate the report before the next scheduled engagement. Programmes that conflate the two end up overdue on one axis while being current on the other.
The calendar question has a fairly tight band of answers across regulated frameworks. Annual is the modal cadence. Six months is unusual outside high-assurance critical infrastructure work. Two years is rare and usually appears in low-risk contexts (low data sensitivity, slow-changing asset). The change question is the part that varies by programme, and it is the part most validity disputes are actually about.
The right framing is a written validity policy that names both axes per asset class. The policy is supplied with the report, referenced in the engagement record, and surfaced on the client portal so the next reviewer sees the validity argument rather than reconstructing it from a date stamp.
Cadence by framework
The cadence rules below are the de facto operating norms for the major regulated frameworks. They are not invariant. The risk assessment that sits behind each programme can justify a tighter cadence; the same risk assessment is rarely a defensible argument for a looser one.3,5,6,7,8
| Framework | Calendar cadence | On-change trigger |
|---|---|---|
| PCI DSS v4.0 | At least every 12 months, internal and external testing, with segmentation testing for the boundary itself. | Any significant change to the cardholder data environment forces a fresh test of the affected scope. |
| SOC 2 Type 2 | No fixed cadence; expectation is at least one test inside the audit observation period, typically 12 months. | In-scope system change requires the report scope to track the system description. Out-of-scope reports are control gaps. |
| ISO 27001:2022 (Annex A 8.8) | Cadence justified by the risk assessment; in practice annual to align with surveillance audits, fresh at recertification. | Risk-assessment trigger; new asset, new environment, or new threat model that the prior risk assessment did not cover. |
| FedRAMP | Annual penetration test per FedRAMP Penetration Test Guidance, submitted with the annual assessment package. | Significant change requires re-test of the affected components inside the continuous monitoring obligation. |
| HITRUST CSF (r2) | Internal and external testing inside the assessment window; cadence aligned to the certification cycle. | Corrective action plan items from the prior cycle must be covered; ignoring them is read as out-of-compliance. |
| CREST (commercial) | No fixed CREST cadence; inherits the cadence of the underlying certification (PCI, ISO, SOC 2, FedRAMP). | Validity argument is structural: accredited firm, registered testers, documented methodology, scope matched. |
| CBEST / STAR-FS (UK regulated) | Cadence set by the supervisor (Bank of England, FCA, PRA), typically scenario-led on a multi-year window. | Threat-led; test refreshed when the threat-led scenario set changes or when the regulator issues a fresh exercise. |
| Cyber Essentials Plus | Annual recertification with technical verification; not a full penetration test but parallel cadence. | Significant change to the in-scope environment expects a re-verification; the certificate is annual. |
The shared pattern across regulated frameworks is annual plus on-change. The shared failure mode is programmes that hold the calendar cadence and ignore the change trigger, or vice versa. The PCI DSS and FedRAMP framings are the strictest about wiring both rules into the obligation; the SOC 2, ISO 27001, and CREST framings rely on the buyer programme to operate the policy correctly.3,4,7
What counts as a significant change
The change trigger is the part of the validity question with the most disagreement and the least documented policy. PCI DSS v4.0 names the term but leaves the operational definition to the entity. The defensible change-trigger policy names the asset axes and the threshold for each so the question is reproducible rather than judged ad hoc at retest scheduling time.
Code or major version change
Major version upgrades on in-scope code (not patch-level fixes), framework swaps, language migrations, rewrite of authentication or session-handling components, and changes to data-handling pipelines. Minor releases inside the same architecture do not usually trigger a fresh test, but they accumulate; a programme that has shipped twelve minor releases in twelve months has likely crossed the threshold even if no single release was significant on its own.
Infrastructure and topology change
New cloud accounts, new regions, new identity providers, new container clusters, new network segments, new service mesh, and new third-party hosting introductions. The infrastructure change axis is the most commonly under-detected because the change usually happens inside platform engineering rather than inside the application teams that own the in-scope code.
Authentication or authorisation change
New SSO provider, new MFA scheme, new authorisation framework (RBAC to ABAC for example), new password or session policy, or new external IdP federation. Authentication and authorisation are the highest risk surfaces on most assets, so the change-trigger threshold should be set lower on this axis than on the infrastructure axis.
Integration and data-flow change
New integrations that move sensitive data in or out, new third-party APIs the asset depends on, new webhooks the asset publishes, new downstream consumers of the asset is data, and new tenancy models (shared to dedicated, single tenant to multi-tenant). Data-flow changes shift the threat surface even when the in-scope code looks unchanged.
Tenancy, jurisdiction, or customer-class change
New tenants on a shared deployment, new geographic regions that shift the regulatory surface, new customer classes (consumer to enterprise, public to government), and new payment or KYC partners. The customer-class change trigger is often missed because it is a commercial milestone rather than a technical one, but it commonly raises the threat profile materially.
Threat-landscape change
A high-impact CVE on a component the asset depends on, a CISA KEV listing the asset is exposed to, a sector-specific advisory from a regulator or CERT, or a new attack technique the prior test plan did not consider. Threat-landscape changes do not usually require a full re-test; they typically require a focused targeted re-test against the changed surface, with the result paired to the original report.13
The defensible programme writes the change-trigger policy down once and applies it consistently. A programme that decides on a case-by-case basis whether a given release counts as significant ends up with an inconsistent evidence trail, which the audit reads as control immaturity rather than control flexibility.
The vendor risk reviewer reading
Vendor risk reviews drive most of the day-to-day pentest report shelf-life questions. The reviewer is not reading the report against PCI DSS or SOC 2 directly; the reviewer is reading the report against a simplified validity rubric that the procurement team or the third-party-risk function maintains. Most rubrics converge on four checks.
- Date: was the test performed inside the last twelve months? Twelve months is the modal threshold; some critical-vendor reviews tighten to nine months, some lower-risk reviews accept eighteen.
- Scope match: does the in-scope asset described in the report match the system the customer is buying? A report that covers the customer-facing application but not the admin platform is invalid for an admin-platform purchase.
- Methodology and tester credentials: was the test performed by a third party with named credentials (CREST, OSCP, CEH, or equivalent)? Internal-only testing is read as a control gap on a third-party risk review.
- Findings status: are the findings listed with severity and remediation status, with high or critical issues either remediated or accompanied by written risk acceptance? Open critical issues without acceptance are a flag.
Some reviewers will accept an attestation letter in place of the underlying report. Attestation language condenses the four checks into a one-page statement on letterhead from the testing firm. The attestation is valid only as long as the underlying report is valid; an attestation issued from a stale report does not survive the second review cycle. The pentest attestation letter guide covers the language structure and the limits of attestation as evidence.
When the report invalidates inside the calendar window
Five trigger classes invalidate a pentest report before the calendar cadence fires. Programmes that watch only the calendar miss the invalidation events; programmes that watch only the change axis miss the cadence-based recertification. Both axes have to be wired in.
1. Material asset change
A major version, a framework swap, a rewrite of authentication, or a re-architecture of the deployment topology. The original test plan no longer describes the asset; the report covers a system that does not exist anymore.
2. Material scope change
New tenants, new geographies, new integrations, or new customer classes that move the threat surface outside what the original test plan covered. The report is still accurate against the original scope but the original scope is no longer the right scope.
3. Material threat change
A CISA KEV listing on a component the asset depends on, a sector-specific advisory, or a high-impact CVE in a transitive dependency. Focused re-test against the changed surface, paired to the original report, is the proportionate response rather than a full fresh engagement.13
4. Material remediation gap
Findings remain open past their SLA windows so the report no longer reflects current security posture. A report whose critical findings sit unfixed nine months after delivery is no longer evidence; it is a record of historical risk that has become current risk. The aging pentest findings research covers the long-tail accounting that the validity reading sits on top of.20
5. Material control change
New compensating controls or removed controls that change the residual risk against the in-scope asset. A report that assumed a WAF in front of the application is invalid if the WAF has since been decommissioned, even if no other change occurred.
Validity, retest, and recertification compared
Three operational responses to validity questions are commonly conflated: a retest, a recertification, and a supplemental note. They produce different artefacts, satisfy different audit reads, and cost different amounts. The clean separation matters when the buyer is asking which one they need.
| Response | When it applies | Artefact |
|---|---|---|
| Retest | A finding has been remediated and the buyer needs verification evidence inside the validity window of the original report. | Verification record paired to the original finding; the original report stays the source of record. |
| Supplemental targeted test | A change has invalidated part of the original scope (new dependency CVE, new integration, new sub-component) but the rest is still current. | Supplemental note appended to the original report describing the focused re-test, the result, and the remaining validity argument. |
| Recertification (full retest) | Annual cadence has fired, or a material asset change has invalidated the original scope as a whole. | Fresh report on a new engagement record, paired by lineage to the prior report for continuity rather than replaced. |
The pentest retest economics research covers the verification-cost discipline that retests and supplemental tests sit inside.19 The retesting use case and the pentest report version control workflow cover the operational mechanics that keep the lineage durable.16
Operational checklist for shelf life
The programmes that handle shelf life cleanly converge on a small set of disciplines. The list below is the durable shape of that discipline, drawn from PCI DSS Penetration Testing Guidance, NIST SP 800-115, OWASP WSTG, the FedRAMP Penetration Test Guidance, and the audit experience under SOC 2 and ISO 27001.1,4,7,11
At engagement scoping
- The framework the report supports is named (PCI DSS, SOC 2, ISO 27001, FedRAMP, HITRUST, CREST).
- The cadence rule is documented in the engagement letter, not assumed.
- The change-trigger policy is referenced or attached.
- The in-scope asset description includes versions, environments, and integration boundaries.
At report delivery
- The test start and end dates are stated explicitly, not derived from a cover page date.
- The methodology (NIST SP 800-115, PTES, OWASP WSTG) and tester credentials are named.
- The in-scope asset description is preserved on the engagement record, not only inside the PDF.
- The validity window is stated as a date range, not as a relative phrase.
- The change-trigger references are attached so reviewers see the invalidation rules.
During the validity window
- Material change triggers are monitored against the change-trigger policy, not at retest scheduling time.
- Open findings are tracked against their SLA windows so the report stays evidence rather than backlog.
- Supplemental targeted tests pair to the original report rather than opening a new engagement.
- Attestation language is reissued from the live engagement record rather than copy-pasted from a stale draft.
At validity expiry
- The fresh engagement is paired to the prior one by lineage, not replacing the historical record.
- Open findings carry forward to the new engagement with their original aging clock intact.
- Changes to the in-scope asset description since the prior test are documented as scope evolution rather than as fresh scope.
- The buyer rubric (twelve-month date, scope match, credentials, findings status) is run against the new report before issue.
How the engagement record carries shelf life
Shelf life gets cleaner when the validity argument lives on the same engagement record the original test lives on, rather than on a PDF that diverges from operational reality after delivery. The platform does not certify the report on the buyer side, but it makes the validity question reproducible and the audit trail self-documenting.
SecPortal pairs every test, retest, and supplemental finding to a versioned engagement record through findings management. CVSS vector, severity, evidence, and remediation guidance carry forward across retest rounds rather than getting reset on the next engagement.14 The pentest report delivery workflow keeps the test dates, methodology, in-scope asset description, and finding statuses on a single live record so the validity claim is reproducible at audit time.17
The branded client portal surfaces the test date, the in-scope asset, and the finding statuses on a single live record both sides see, so the validity argument stops sitting in a PDF that has been emailed to procurement teams that do not have access to the underlying record. The pentest report version control workflow keeps draft, reviewed, client-issued, reissue, retest-delta, and attestation versions in lineage so reviewers can read the current version without losing the historical chain.15,16
The vulnerability remediation SLA calculator pairs the validity calendar to the underlying SLA window, aligned with NIST SP 800-40r4 and the PCI DSS, ISO 27001, SOC 2, and CISA KEV reference frames. A finding whose SLA has expired is signal that the report is approaching invalidation on the remediation-gap axis rather than on the calendar axis.18
For pentest firms and consultancies
On the firm side, shelf-life management protects two things at once. It protects the buyer relationship because validity questions arrive routinely from procurement teams the buyer does not control, and a firm that can answer the question in one sentence with a portal link is materially easier to defend at renewal. And it protects the firm is engagement footprint because supplemental targeted tests inside an existing validity window are renewable revenue rather than one-off discount work. For pentest firms and security consultants, the operating commitment is straightforward.
- The validity window is named in the engagement letter and on the report, not implied.
- The change-trigger policy is supplied with the report or referenced from a stable URL.
- The in-scope asset description carries versions and integration boundaries, not only headline names.
- Attestation language is reissued from the live engagement record on demand rather than copied from drafts.
- Supplemental targeted tests pair to the original report by lineage and extend rather than replace its validity.
Reporting shelf life that way keeps the validity conversation short at every renewal cycle, which is the single highest-leverage commercial discipline in the post-engagement lifecycle.
For internal security teams and pentest buyers
On the buyer side, shelf-life questions arrive from procurement, vendor risk, audit, and customer success on different cadences and against different rubrics. A single answer rarely satisfies all four. The fix is a written validity policy paired to each in-scope asset, surfaced on the engagement record, and referenced from any attestation or report summary the team issues.
- Insist on a stated validity window at engagement scoping rather than at report delivery.
- Insist on a written change-trigger policy that names the asset axes, supplied with the report.
- Operate the change-trigger policy proactively against release calendars rather than retrospectively at audit.
- Treat aging open findings as a validity signal, not only as a remediation backlog signal.
- Reissue attestation language from the live engagement record, not from a static PDF copy.
The pentest delivery gap research covers the wider portal-and-SLA economics that shelf-life discipline plugs into. The severity calibration research covers how to score findings consistently so the SLA window derived from severity is itself defensible, which is the precondition for the remediation-gap axis of validity to be meaningful. The broader compliance question of when other audit evidence loses validity, beyond pentest reports, is covered in the audit evidence half-life research.
Conclusion
Pentest report shelf life is two questions, not one. The calendar question has a tight band of answers across regulated frameworks; annual is the modal cadence and on-change is the universal trigger. The change question has the most disagreement and the least documented policy, and it is the part of validity most disputes are actually about. The buyer reading, the vendor reading, the auditor reading, and the procurement reading collapse into a single answer when the validity policy is written, paired to the in-scope asset description, and reproducible from the engagement record.3,5,6,7
Treating shelf life as a written policy attached to an engagement record rather than as a date stamp on a PDF is the highest-leverage discipline in pentest delivery after delivery itself. It protects the commercial conversation at renewal, it keeps the audit trail current, and it produces evidence that survives the second and third review cycle rather than expiring quietly in a shared drive. The platform you use does not have to write the validity policy for you. It does have to make the policy reproducible and the audit trail self-documenting.
Frequently Asked Questions
Sources
- NIST, SP 800-115: Technical Guide to Information Security Testing and Assessment
- NIST, SP 800-53 Revision 5: Security and Privacy Controls for Information Systems and Organizations
- PCI Security Standards Council, PCI DSS v4.0 (Requirement 11.4 Penetration Testing)
- PCI Security Standards Council, Information Supplement: Penetration Testing Guidance
- ISO/IEC, ISO 27001:2022 Information Security Management
- AICPA, SOC 2 Trust Services Criteria (TSC) 2017 with 2022 Revisions
- FedRAMP, Penetration Test Guidance
- HITRUST, CSF Assurance Program: r2 Validated Assessments
- CREST, Penetration Testing Procurement Guide
- CREST, CBEST Implementation Guide
- OWASP, Web Security Testing Guide (WSTG)
- PTES, Penetration Testing Execution Standard
- CISA, Binding Operational Directive 22-01
- SecPortal, Findings & Vulnerability Management Feature
- SecPortal, Branded Client Portal
- SecPortal, Pentest Report Version Control Use Case
- SecPortal, Pentest Report Delivery Use Case
- SecPortal, Vulnerability Remediation SLA Calculator
- SecPortal Research, Pentest Retest Economics
- SecPortal Research, Aging Pentest Findings
Run pentest engagements with a durable validity trail
SecPortal keeps every engagement, retest, and supplemental finding paired to a versioned record so the shelf-life question is reproducible at audit time and the validity argument lives on the same record both sides see.