On this page
A penetration test report has no expiry date of its own. The period it stays valid for comes from whoever relies on it. PCI DSS asks for a new test at least once every 12 months, and customers and regulators often set periods of their own. Change to the areas the test covered can end a report's usefulness long before any of those dates. This post sets out who decides the period, which changes shorten it, and how to show a customer or auditor that the report still describes production.
Does a penetration test report expire?
A penetration test report does not expire on a fixed date. None of the standards and regulations cited in this post gives a report a validity period. The UK National Cyber Security Centre says a test can only show that systems are not vulnerable to known issues "on the day of the test". Each party that relies on the report decides how old a report it will accept.
Two dates are often mistaken for an expiry date. Many testing providers describe a report as current for 12 months, and some print a validity period of six months on their own certificate. That period is the provider's convention. PCI DSS v4.0.1 also asks you to keep penetration testing results for at least 12 months (requirement 11.4.1), which is a rule about retention. Neither date says whether the report still matches production.
A report therefore has two limits. One is the period set by the rule, contract or policy that asked for the test. The other is the point at which production stops matching what the tester saw, because a report describes one build. Change brings that second point forward, and nothing on the report's cover shows it.
A report can pass its period and still describe production well. It can also stay inside its period while describing an application that no longer exists.
- 4 AprNew third-party domainnot confirmed
- 2 JunSecurity header removedCR-10482
- 1 OctContent security policy widenednot confirmed
Who decides how long a penetration test stays valid?
The period is set by whoever relies on the report, such as a standard, a regulator, a customer, an insurer or your own security policy. Where several apply, the shortest period and the strictest change trigger set the pace. The table lists common sources and what each one states.
| Who sets it | Period | Change trigger | Source |
|---|---|---|---|
| PCI DSS v4.0.1, requirements 11.4.2 (internal) and 11.4.3 (external) | At least once every 12 months | After any significant infrastructure or application upgrade or change | PCI SSC document library |
| DORA, Regulation (EU) 2022/2554, Article 24(6), for financial entities other than microenterprises | At least yearly, for all ICT systems and applications that support critical or important functions | A risk assessment upon each major change (Article 8(3)) | EUR-Lex |
| DORA, Article 26(1) | Threat-led penetration testing at least every 3 years, for the entities identified under the article; the competent authority may raise or lower this | None stated | EUR-Lex |
| Central Bank of Bahrain Rulebook, OM-5.5.28 | At least twice a year, for licensed banks | None stated in the rule | CBB Rulebook |
| NIST SP 800-53 Rev. 5, control CA-8 | A frequency the organisation defines | Verify the affected controls after system changes (CM-4(2)) | NIST CSRC |
| A customer's security questionnaire or contract | Set by each customer | Set by each customer | The questionnaire or contract |
| A cyber insurer's proposal form | The form's question, such as a test in the last 12 months | Material information disclosed before each renewal | The insurer's form |
| Your own security policy | The interval your policy states | The changes your policy says need testing | Your policy |
Every row sets a maximum age, and none of them promises that a report stays valid for the whole period. PCI DSS pairs its 12-month interval with a trigger for significant change, so a change can bring the next test forward. DORA's yearly rule covers "appropriate tests", and Article 25(1) lists penetration testing among them. The Central Bank of Bahrain sets the shortest fixed interval in the table.
Customers and insurers often set the period that matters in practice, because they read the report. In our experience of delivering assessments, most security questionnaires ask for a test in the last 12 months. Many also ask for the report itself, or for a letter from the tester that summarises it.
An insurer's question can be narrower. One New Zealand insurer's cyber proposal form asks whether you have "conducted a penetration test or external vulnerability scan in the last 12 months" (question 3.1(c)). The same form makes your answers the basis of the insurance contract. That question asks whether a test took place. It says nothing about whether production still matches what was tested.
What shortens a penetration test report's useful life?
Change to the areas the test covered shortens a report's useful life. Each such change makes a statement in the report untrue, or removes a condition that a finding's rating relied on. Changes outside the tested areas matter far less. An edit to a marketing page leaves the report as accurate as it was.
Vikax names fifteen kinds of change when it compares two versions of a page or API. Six of them bear most directly on what a web application report says.
- A security header removed or changed. The report's configuration section records the headers the tester saw, such as
Strict-Transport-Securityand its directives. Once a header is removed, that section describes a different application. A finding rated lower because a header blocked part of the attack may also need a new rating. - A content security policy widened. Testers often rate a cross-site scripting finding lower when the policy blocks inline scripts and unknown sources. Adding
'unsafe-inline'or a wildcard source removes that condition. The rating in the report then understates the risk. - A new third-party domain. A script from a new domain now runs on pages the tester examined, and the tester never reviewed it. The report's account of client-side controls no longer covers everything those pages load.
- An API route added or removed. The report's scope lists the routes the tester exercised. A new route has had no authorisation testing at all. A removed route can take with it a check that other routes relied on.
- A form destination changed. When a sign-in or payment form posts to a new host, the data goes somewhere the test did not cover. The report's description of that data flow is out of date.
- A sign-in flow changed. Authentication and session management are usually central to a web application test. A new identity provider or an added sign-in option means those results describe the old flow.
One change of this kind can be enough. A widened policy on the account page can change the risk of a finding the report rated low within a day of release.
Some causes of ageing never show up as a change in production. A vulnerability published for a component the application uses changes the risk overnight. Changes on the server and in internal networks stay out of reach of any check made from outside. An outside comparison answers part of the question, and an account of the report's age should say which part.
How do you show a customer or auditor that the report still describes production?
Send the evidence behind the report along with the report. A reader who sees what the test covered and what has changed since can judge whether the report still describes production. Three pieces of evidence do most of the work.
- A record of what the test covered. The pages, APIs and files in scope as the tester saw them, with a reason for anything left out. Vikax keeps this as a sealed record of the assessment, which nobody can edit or delete once it is sealed.
- The current state, with its evidence. How far production has moved since the assessment, and each change behind that state with the evidence from before and after. The post on what changed since the last penetration test explains how to check this from the outside.
- An export the reader can keep. A dated file that holds the record and the changes since, with the decisions your team recorded. Vikax exports it as PDF, HTML, JSON or ZIP, and records a fingerprint of each file so that its holder can check it was not altered.
Releases make the account easier to follow. Vikax groups the changes it sees into releases, and your team confirms the releases it planned under its own change reference. A reader can then tell which changes came through your change process and which nobody has confirmed yet. The same records serve an auditor who tests change management, as the post on change records an auditor can follow explains.
A questionnaire answer built on this evidence might read: "External penetration test of the customer portal completed on 14 March 2026. Since then, three changes have touched tested areas. One belongs to confirmed release CR-10482, and two are under review. Evidence attached." The reader can see what moved since the test and what your team did about it.
- Assessment record
- Sealed 14 Mar 2026 · 12 in scope · 2 excluded with reasons
- Since the assessment
- Significant change
- Changes in tested areas
- 4 Apr · New third-party domain · not confirmed2 Jun · Security header removed · CR-104821 Oct · Content security policy widened · not confirmed
- Testing decision
- Review firstA. Hassan · 2 Oct
PDF · 1.8 MBFingerprint 9f3c…1d6eRecords cannot be edited or deleted
None of this makes the report newer or extends its period. Vikax records what changed in production and keeps the evidence. Testing and judgements about risk stay with your testers and analysts. The page for security teams shows how that evidence supports audits and customer reviews.
When is the answer a new penetration test?
A new test is due when the shortest period that applies to you runs out. It is also due when a change to the tested areas is significant under your own definition. Between those points, the evidence shows whether targeted testing of the changed areas will do or the application needs a full assessment.
The period is the simpler part. An application covered by PCI DSS requirement 11.4.3 that had its external test on 14 March 2026 needs the next one by 14 March 2027 at the latest. The same application at a bank licensed in Bahrain needs at least two tests in every year. Put the earliest date that applies in the testing plan for each application.
The change trigger needs more care. PCI DSS asks for a test after any significant infrastructure or application upgrade or change. Requirement 6.5.2 then asks you to confirm that the applicable requirements are in place on the changed systems. The PCI SSC's penetration testing guidance says a significant change "is not prescribed by PCI DSS" and depends on each entity's risk assessment (section 2.6). Decide what counts as a significant change before one arrives.
The evidence then sets the scope. A new API route may need authorisation testing of that route and the routes around it. A rewritten sign-in flow alongside a new API version may mean the report describes a different application, and a full assessment is the right scope. Our post on targeted testing or a full assessment covers how to choose.
The tester who runs the next test needs the same evidence. If a testing provider holds your report, your team can give a named analyst at that provider access in Vikax. The access is limited to the applications, environments or assessments you choose, and every use of it is audited. Vikax also gives the tester a summary of what changed and what the last assessment covered, mapped to the OWASP testing guides.
Record the decision either way, with the evidence that led to it. A customer who asks next year why the report was still accepted in June will want to see that record. Vikax keeps each testing decision with its evidence, and nobody can edit or delete it afterwards.