How often to run a penetration test

How often to run a penetration test depends on the rule that applies to you

Most rules that apply to a penetration test set an annual minimum and require extra tests after significant change, while a smaller number set risk-based or threat-led timing. Under PCI DSS, internal and external penetration tests must run at least every 12 months and after significant changes, and CIS Controls Safeguards 18.2 and 18.5 ask for external and internal tests at least annually. NIS2 leaves the interval to risk assessment, and DORA threat-led penetration testing (TLPT) follows a multi-year cycle set by the supervisory framework. Before you commit to a calendar, confirm which of these rules your regulator, acquirer, insurer or largest customer actually cites, because the wording of that clause sets your deadline.

Organizations commission penetration tests to find exploitable weaknesses before attackers do, to confirm that controls work as designed, and to produce evidence for an auditor, customer or board. Those goals change over time. A new payment flow, a new identity provider, a major platform upgrade or a cloud migration can add exposure well before the next scheduled test, so the rule's trigger list matters as much as its annual date. Treat the required frequency as a floor. A clean report describes the systems as they were on the test dates, and it does not guarantee security between tests, which is why continuous scanning and change reviews are usually paired with the periodic manual test.

To set your own cadence, list the rules that apply, write down each trigger they name, and map your release calendar against them. Ask your provider how they will handle a test that falls near a major release, and agree in advance whether a change will prompt a targeted retest or a new engagement. Confirm with your assessor how they define significant change and whether they accept a test that predates a recent upgrade. The answers belong in your written scope, so the test date and the change history stay aligned.

What PCI DSS, CIS Controls, NIS2 and DORA require on timing

This table compares how four frameworks set the timing of penetration tests, from fixed intervals to risk-based judgment. Read each row against your own obligations, then use the evidence column to plan what your assessor will ask to see.

Framework	Timing expectation	Evidence to show the assessor	Confirm with your assessor
PCI DSS (11.4.2 and 11.4.3)	Internal and external penetration tests at least every 12 months and after significant changes	Dated test reports, scope showing in-scope systems, and a record of the change that triggered any extra test	Which changes count as significant for your environment and whether segmentation tests fall on the same cycle
PCI DSS (11.4.4)	Exploitable vulnerabilities corrected by risk ranking, then the test repeated to verify the fixes	Remediation tickets linked to findings and retest results confirming closure	How long after the original test a retest remains valid, and when a new engagement is needed
CIS Controls v8.1 (Safeguard 18.2)	External penetration tests at least annually; the assessment metric fails if more than twelve months pass since the last external test	Date of the most recent external test and the scope it covered	Whether your assessor applies the twelve-month metric as a hard pass or fail threshold
CIS Controls v8.1 (Safeguard 18.5)	Internal penetration tests at least annually	Internal test report with scope, dates and remediation status	Whether an internal test can run on a different date from the external test without affecting the assessment
NIS2	Risk-based; the directive sets no fixed test interval in its text	Documented risk assessment that sets test frequency, plus records showing tests follow significant incidents or architecture changes	The interval your national transposition law and competent authority expect, and whether they name a minimum
DORA threat-led penetration testing (TLPT)	Described as every three years for in-scope entities, under the threat-led framework	Test plan approved by the competent authority, scope and testing provider records, and remediation plan	The three-year cycle, which entities are in scope, and whether annual penetration testing is still required alongside TLPT
Release cadence and major change	No framework sets a release-based rule; extra tests usually follow significant or security-relevant changes	Change log linking major releases, architecture changes or new internet-facing services to a test decision	Which of your releases your assessor treats as significant and how they judge the timing of the next test

Penetration testing frequency by situation: calendar, change or risk-based

Cardholder data environments face the most prescriptive calendar. PCI DSS requires internal and external penetration tests at least every 12 months and after significant changes, and it requires internal and external vulnerability scans at least once every three months. Penetration testing sits on top of that scanning rhythm, so scan reports never replace a manual test.

Minimum timing: at least every 12 months for internal and external tests, plus after significant changes to the environment.
Change triggers: new payment flows, changes to network segmentation, new paths into the cardholder data environment, or a major upgrade to the payment platform. Ask your assessor to confirm which changes they treat as significant.
Segmentation checks: if segmentation reduces scope, retest it after changes to firewalls, network design or the systems on either side of the boundary.
Remediation retest: exploitable findings must be corrected according to the entity's risk ranking, and the test repeated to verify the fix under requirement 11.4.4.
Evidence the assessor asks for: dated reports showing scope and methodology, segmentation results, remediation records, retest evidence and the quarterly scan reports.

Confirm whether your assessor expects the test to fall inside the assessment period, and keep a change log that shows how each significant change was classified.

How release cadence and major changes set penetration testing frequency

A fixed annual test can miss changes that ship between cycles, so the testing calendar has to follow what changes in the environment, not only the date on the calendar. PCI DSS already works this way: its requirements for internal and external penetration tests call for a repeat after significant changes in addition to the 12-month interval, so an organization that releases often can be in breach of its own assessment conditions without knowing it. The practical first step is a written change classification. Ask which changes would plausibly open new attack paths and treat those as test triggers. Common candidates include new internet-facing services or changed exposure of existing ones, identity and authentication changes such as new login flows, MFA changes or new federation, new third-party or internal integrations that move data or privileges, cloud account or network segmentation changes, and major version upgrades of core platforms.

A high release cadence changes the shape of the testing program more than its size. When releases are frequent, a single large manual test each year covers a system that has already changed several times, so the more useful pattern is a smaller, targeted manual test for each trigger class, scheduled against the change calendar, combined with automated scanning between tests. Organizations that want this continuously can look at a continuous model, but the reader should check that it still includes manual work after significant changes rather than only automated output. Ask the provider how it would scope a targeted test for a single release, how quickly it can start after a trigger, and how it records which changes were tested and which were not.

The most important decision sits with the organization. It must define what counts as significant in its own change policy, with examples for each trigger class and a named owner who decides borderline cases, and then agree that definition with its assessor or auditor before the first cycle relies on it. Write down the reasoning for each exclusion, such as a cosmetic front-end change or a patch that does not alter exposure, because an assessor will ask why a change was not tested. Review the definition after incidents or major platform decisions, and keep the change log, the trigger decisions and the resulting test records together so that the frequency can be shown to match the environment as it actually changed.

How one test cycle runs from planning to retest

The cycle follows the four NIST SP 800-115 phases and then closes with remediation and retest, so each step produces a written record that the next step depends on. Readers can use it to see where their own approvals, data and fixes fit into a single test.

Agree rules and approval before any testing
Planning is the only phase in which no testing takes place. The organization identifies the rules that govern the test, finalizes and documents management approval, and sets the testing goals. NIST SP 800-115 provides a rules of engagement template in Appendix B that many teams use as a starting point, adapting it to their own environment. NIST does not endorse one methodology over another, so the rules should state which methodology the tester will follow. The step is complete when the signed rules of engagement and goals exist and the tester has confirmed them in writing.
Map targets and information access
During discovery, the tester identifies hosts, services, applications and accounts within the agreed scope and gathers the information the chosen knowledge level allows. Whether the tester starts with no details, partial details or full documentation changes how much time this phase takes and how complete the results will be. The check that closes discovery is a target list the client has reviewed against the approved scope, with any unexpected assets raised before exploitation begins.
Validate weaknesses through manual attack
The attack phase is where a tester, working mostly by hand, tries to confirm whether weaknesses can be used to defeat security features. PCI SSC describes this as a mainly manual process, in contrast to automated scanning that finishes in seconds to minutes per host. Penetration tests may last days or weeks depending on scope. The phase closes when each candidate weakness is either confirmed with evidence or recorded as not exploitable, and when testing stops within the rules agreed in planning.
Write the report with severity reasoning
Reporting turns confirmed results into a document the client can act on. PCI SSC's suggested outline covers the executive summary, scope, methodology, limitations, testing narrative, findings with references such as CVE and CWE, and environment clean-up. Severity should be explained, typically using a industry score such as CVSS, with traceable reasoning if the score was adjusted for the environment. The step closes when the client has received a draft, reviewed it for factual accuracy and the final report has been issued.
Prioritize and remediate findings
The client's team ranks each finding according to its own risk policy and schedules fixes. PCI DSS requirement 11.4.4 expects exploitable vulnerabilities to be corrected in line with that ranking. Remediation owners should record what changed, where, and why a fix was accepted or deferred. The step is complete when every finding has a documented status, whether fixed, compensated or formally accepted with an owner and a review date.
Retest to confirm the fixes hold
PCI SSC's guidance says the tester should retest once remediation is complete to validate that new controls mitigate the original risk. PCI DSS requirement 11.4.4 requires the penetration test to be repeated to verify corrections. If remediation takes place long after the original test, the guidance indicates a new engagement may be needed instead of a retest, so the client should raise timing with the provider early. The step closes with a retest report that documents each closed finding and any that remain open.
Feed results into the next test trigger
The closed cycle becomes the baseline for the next decision. The client records the date of the test, the scope tested and any significant changes that occurred since, then checks these against the calendar and change triggers in their program. Confirm with the assessor or customer which dates and records they will accept as evidence before the next cycle begins.

What testing more often changes in cost and effort

This table breaks down what a buyer pays for in each testing cycle, which parts recur and which are one-time setup, and what raises or lowers effort. Read it when comparing an annual test with a more frequent cadence, and use the drivers to see where a quote is likely to move.

Cost component	Who is paid and what for	One-time or recurring	What drives it up or down
Scoping and rules of engagement	Tester time to confirm targets, accounts, exclusions and testing windows, documented before any testing starts	Recurring per cycle, with a one-time setup for the first cycle	Stable target lists and existing rules of engagement shorten it; new environments or new roles lengthen it
Testing time by target	Tester hours spent on each internet-facing or internal target, with manual work carried out for each	Recurring per cycle	Number of internet-facing targets, number of environments, and how much manual depth the test requires
Roles and accounts	Tester time to test each privilege level, such as anonymous, standard user and administrator	Recurring per cycle	Each additional role or account type adds test paths; fewer roles keep effort down
Knowledge level (black, grey or white box)	Tester time to learn the target before testing; black-box work may require more time, money and resources to meet PCI DSS deliverables (PCI SSC Penetration Testing Guidance v1.1)	Recurring per cycle	Providing architecture and documentation to the tester usually reduces discovery effort; confirm the level in the quote
Stability between cycles	Tester time to re-learn what changed since the last test and to decide what to retest versus retest from scratch	Recurring per cycle	Unchanged environments with documented baselines lower effort; frequent releases and infrastructure changes raise it
Change-triggered extra tests	Additional scoped testing after significant changes, such as new internet-facing systems or major architecture changes, which PCI DSS requires for in-scope environments	Recurring when triggered	Release cadence and the number of major changes per year; define what counts as significant in advance
Retesting	Tester time to verify that remediation fixed each finding, documented in a retest report	Recurring per remediation cycle	Number of exploitable findings and whether fixes are delivered close to the original test
Reporting	Tester time to write findings, severity reasoning and remediation advice, and to hand over the report	Recurring per cycle	Number of findings, required report format, and whether the report must serve an auditor or customer
Threat-led testing budget reference	The European Commission's 2020 DORA impact assessment (SWD(2020) 199) cites an ESA estimate that threat-led penetration testing costs between 0.1% and 0.3% of the total ICT budget of the firms concerned	Recurring for firms in scope	Applies only to threat-led testing under DORA; use it as context, not as a benchmark for other test types

What you receive each cycle and whether an auditor or customer accepts it

Each test cycle should end with a written report, and the report's value depends on its contents. The cards below cover the sections a reviewer checks first, then the retest record that shows whether findings were closed. Whether that evidence satisfies an assessor is the assessor's decision, not the tester's.

Scope, method and limitations

The report should state exactly what was tested, including hosts, applications, accounts and dates, and which testing approach was used. It should also state its limitations, such as excluded systems, restricted windows or access the testers did not have. An assessor reads these sections first to decide whether the test covers the environment in question. Check that the method is named and that a scan-only run is not presented as a penetration test.

Findings with CVE and CWE references

Each finding should describe the weakness, the affected asset and the evidence that supports it, with references such as CVE and CWE where they apply. Weakness categories make it possible to compare one cycle with the next and to spot repeat problems. Ask whether each finding was confirmed by a tester or came from an unverified tool output. Findings without a clear affected asset are hard to track and hard to retest.

Severity reasoning and risk ranking

The report should explain how each severity or risk rank was derived, typically from a scoring system such as CVSS. Where the tester adjusted a score for your environment, the reasoning should be traceable, for example an exposed management interface or compensating controls. This matters because your remediation deadlines often depend on the ranking. Ask the provider to show the adjustment logic, not only the final label.

Tools and environment clean-up

A good report lists the tools used and the versions where relevant, so the work can be reviewed and reproduced in principle. It should also confirm that test accounts, temporary files and any changes made during testing were removed or reported. Assessors and customers ask about this because testing can leave artifacts behind. Ask for the clean-up confirmation to be written into the report, not promised verbally.

Retest report that closes findings

After remediation, a retest should confirm for each finding whether the fix works, partly works or was not applied. The retest report is the record that shows a finding was closed, and it is the document most often requested alongside the original report. PCI DSS requirement 11.4.4 expects corrections to be verified by repeating the test. Ask how retest scope, timing and any fee are set before the original test begins.

Acceptance is the assessor's decision

DeployOpen runs testing and prepares the report, but does not issue audit reports, attestations or certifications. The client's assessor, certification body or customer security team decides whether the evidence is sufficient for their requirement. Before commissioning a test, confirm with your assessor which sections, methodology statements and retest records they expect. Doing this early avoids rework when the cycle is reviewed.

Preparing for repeat tests so each cycle stays comparable

Before each repeat test, the client should assemble the same core inputs so the tester starts from an accurate picture. The first is a current asset inventory covering external addresses, internal ranges, cloud accounts, applications and APIs in scope, with owners named for each. Next, document every significant change since the last test, including new releases, new integrations, identity provider changes, network moves and infrastructure upgrades. PCI DSS treats significant changes as a trigger for testing in its own right, so this list is also the evidence that decides whether an extra test is needed. Confirm the exact change criteria with your assessor and your own change management policy rather than relying on memory.

Second, name the people who make the engagement run: a technical contact who can answer questions during testing, a business owner who can approve scope changes, and an escalation path for a finding that suggests active compromise or service disruption. Prepare test accounts and roles that match the previous cycle, so access levels can be compared across tests. Agree testing windows and change freezes in writing, and record any monitoring or incident response teams that should be told in advance. Also gather the remediation status of previous findings, including which were fixed, accepted as risk, or still open, with retest evidence where it exists.

Keeping the scope baseline the same between cycles makes trends and retest results easier to read. When the target list, account roles and exclusions stay constant, a change in the number of findings can be traced to the environment rather than to a shift in what was tested. Where scope must change, record the difference explicitly in the statement of scope so the next comparison accounts for it. Ask your provider to confirm how they will reference earlier findings and whether they will reuse the same identifiers, since this affects how readable the year-on-year report will be.

What to check in a provider before you commit to a recurring schedule

A recurring testing schedule only works if the provider's method, people and paperwork hold up year after year. The cards below cover what to verify before signing, so each annual or change-triggered test produces comparable, defensible evidence.

Methodology disclosed in writing

Ask for the testing methodology as a written document, not a verbal summary, and check that it maps to a public standard such as NIST SP 800-115 or OWASP ASVS. NIST does not endorse one methodology, so the provider should state which approach it uses and where it combines them. A written method lets your auditor compare one year's test with the next. Confirm that the method is also named in the report, as ASVS guidance expects.

Redacted sample report

Request a sample report with client details removed and check whether it contains the sections a PCI SSC style outline expects: scope, methodology, limitations, findings with evidence, and severity reasoning. A recurring engagement lives or dies on report quality, because each year's findings must be compared against the last. If the sample is generic boilerplate or a scanner export, treat that as a warning about the manual work behind it.

Tester experience over certificates

PCI SSC lists OSCP, GIAC GPEN and GWAPT, CREST certifications and CHECK as indications of tester skill, but it does not validate them and states that certifications alone do not establish experience. Ask who will actually test your environment, how many years they have worked in that technology, and whether the same people return each cycle. Certificates are a starting filter, not a substitute for a conversation about past work.

CREST accreditation as a company signal

CREST is a not-for-profit that accredits member companies and certifies individuals. Company accreditation shows that the firm's processes have been assessed at the organization level, which matters for a multi-year relationship. It does not guarantee that a particular tester is strong, so pair it with the tester checks above. If AI systems are in scope, ask whether the provider holds CREST's AI-Enabled Penetration Testing accreditation, which CREST announced in September 2026 for its first cohort of ten companies.

Independence and conflicts

Confirm that the provider does not also build, sell or administer the systems it tests, or, if it does, that the conflict is disclosed and managed. Over several years, a tester who helped configure a platform may be less inclined to challenge its design. Ask how testers are rotated, who signs off findings, and whether the provider has any reseller or vendor relationship that could influence its recommendations.

Data handling and retention

Each recurring test collects credentials, architecture details and vulnerability evidence, which accumulate into a sensitive archive. Ask where evidence is stored, how long it is retained, who can access it, how it is deleted at the end of the contract, and whether testing traffic and tools are controlled within your environment. Written answers here protect you across every cycle, not just the first.

Retest terms in the contract

PCI SSC guidance says testers should retest once remediation is complete, and PCI DSS requirement 11.4.4 requires repeating tests to verify corrections. Check whether retests are included in the fee or charged separately, how long after the original report they can be scheduled, and what happens when fixes arrive long after the test. A recurring schedule should state these terms so that fixes are verified before the next annual cycle begins.

Manual work in recurring offerings

Before you commit to a recurring or continuous package, ask what share of the work is manual and which parts are automated scanning. PCI SSC describes penetration testing as a mainly manual process, distinct from scans that run in seconds to minutes per host. Ask which findings come from tester judgment, how many hours of hands-on testing each cycle includes, and whether change-triggered tests are covered. A recurring price that is mostly scanning will not satisfy an annual manual test requirement.

Questions buyers ask about penetration testing frequency

How often does PCI DSS require a penetration test?

PCI DSS requires internal and external penetration tests at least every 12 months and after significant changes, under requirements 11.4.2 and 11.4.3. The standard also expects exploitable vulnerabilities found in testing to be corrected according to the entity's risk ranking and the test to be repeated to verify the fixes (requirement 11.4.4). The annual clock is the floor, not the plan. A significant change, such as a new payment flow, a new network segment or a major platform upgrade, starts a new test even if the last one was recent. Confirm with your Qualified Security Assessor which systems fall in scope and what counts as significant in your environment, because that judgment shapes the timing more than the calendar does.

Does an annual penetration test satisfy CIS Controls?

An annual test meets the baseline that CIS Controls v8.1 sets. Safeguards 18.2 and 18.5 ask for external and internal penetration tests at least annually, and Safeguard 18.2 fails the CIS assessment metric if more than twelve months have passed since the last external test. Meeting the calendar requirement does not prove the test was thorough. Assessors look at whether the test covered the environment that matters, used manual work beyond automated tools, and led to tracked remediation. Confirm with your assessor which assets and test types they expect, and whether internal tests need the same cadence as external ones in your design.

What should trigger an extra penetration test after a release?

A standard annual cycle does not follow your release calendar, so change events should trigger extra testing. Typical triggers include a new internet-facing service, a changed authentication or payment flow, a new identity provider or access model, a major version upgrade of a core platform, a new cloud account or network path, and a significant change to segmentation. PCI DSS treats significant changes as a trigger for testing in its own right. Frequent minor releases usually do not each need a full test. A practical approach is to agree a written change threshold with your testing provider and your assessor, so the decision is made before a release, not after an incident. Confirm which changes your assessor treats as significant.

How often does DORA threat-led penetration testing apply?

DORA threat-led penetration testing (TLPT) is not an annual exercise. It applies to firms that its regulatory technical standards designate as in scope, and the testing cycle is set at every three years, which is the frequency you should confirm with your competent authority. The European Commission's 2020 impact assessment (SWD(2020) 199) cited an ESA estimate that threat-led testing costs between 0.1% and 0.3% of the total ICT budget of the firms concerned. Treat that as a planning reference from the impact assessment, not a quote. Firms outside TLPT scope still face DORA's general expectations for ongoing testing of ICT systems, so an annual or change-driven program may still be needed. Confirm your designation and cycle with your regulator.

Can our own team run penetration tests, and what do standards expect of the tester?

Many standards allow internal testing, but the tester's independence, skill and records matter as much as who employs them. NIST SP 800-115 says NIST does not endorse one methodology over another and leaves organizations to adopt or combine them, and it describes a planning phase with approved rules of engagement before any testing begins. PCI SSC's guidance lists OSCP, GIAC certifications such as GPEN and GWAPT, CREST certifications and CHECK as indications of skill, while noting that PCI SSC does not validate them and that certifications alone do not establish experience. Ask your assessor whether internal staff can meet the independence expectation for your scope, and document the methodology, scope, limitations and retest evidence in the same way an external report would.

How long does a penetration test cycle take, and what does it need from us?

Duration depends on scope size, test type, the depth of manual work and how quickly remediation and retesting happen. PCI SSC's guidance describes penetration testing as a mainly manual process that may last days or weeks depending on scope, compared with vulnerability scans that run in seconds to minutes per host. The cycle also includes planning, the report and retesting after fixes, which can add weeks or months depending on remediation. Plan time for the client side too: named contacts, account credentials for the agreed roles, a testing window, a list of exclusions, and someone to approve the rules of engagement in writing. Ask any provider for a timeline based on your written scope, and confirm your assessor's deadline before you book the work.

Does a vulnerability scan replace a penetration test?

No. A vulnerability scan identifies, ranks and reports known weaknesses, mostly with automated tools, and the PCI SSC guidance distinguishes that from penetration testing, which is a mainly manual process that exploits vulnerabilities to test whether security features can be defeated. Compliance frameworks ask for both. PCI DSS requires internal and external vulnerability scans at least once every three months (requirements 11.3.1 and 11.3.2) alongside the penetration testing cadence. OWASP ASVS 5.0.0 also states that running an automated tool without thorough testing is insufficient. Scans are good for frequent coverage, while penetration tests add judgment and chained attack paths. Confirm with your assessor which scan and test evidence they expect for your environment.

How DeployOpen scopes, tests, reports and retests

DeployOpen plans and runs penetration tests for self-hosted open-source platforms inside the client's own infrastructure, with the testing frequency set against the client's compliance obligations, release cadence and major changes. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we scope

We map which compliance obligations, such as PCI DSS or CIS Controls, set the minimum testing cadence for each target.
We list the systems, environments and release cycles that would trigger an extra test after a significant change.
We agree the testing window, exclusions and rules of engagement in writing before any testing starts.

How we build

We set the test calendar around the client's release schedule so major upgrades are covered before they reach production.
We confirm whether each test should be external, internal, or both, and whether it runs as black, grey or white box.
We record the planning decisions and assumptions so the next test can start from the same documented baseline.

How we hand over

We deliver a written report with scope, methodology, limitations and findings, including how each severity was derived.
We state the test date and version tested so an auditor can match each report to the period it covers.
We recommend a retest point for each remediation cycle, and confirm with the client whether a new engagement is needed.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the initial engagement.
A retainer can schedule recurring tests tied to release milestones, so the cadence follows the change history.
Confirm with DeployOpen which retest terms and retainer options apply before you commission the first test.

How often to run a penetration test