How often should penetration testing be done?

By The PenTest Index · Rules and prices checked October 10, 2026

How often should penetration testing be done? For most companies, once every 12 months, and again after a significant change. Twelve months is the interval PCI DSS, New York's NYDFS rule and the FTC Safeguards Rule set where they apply. SOC 2 and today's HIPAA rule name no interval, so your own policy, contract or report recipient decides.

Three conditions matter. Only PCI DSS, of those three rules, also requires a test after a significant change. The FTC test applies only if you have neither effective continuous monitoring nor other systems that detect, on an ongoing basis, changes that may create vulnerabilities, and maintain customer information concerning 5,000 or more consumers. And some PCI DSS service providers must test every six months. Find your row below, then turn it into dates.

Your minimum, by situation

We read each of these texts on October 10, 2026. Links and limits are in the rule table further down. A penetration test, or pentest, is a planned, permitted attack on your own systems to find weak spots. Segmentation means the controls that wall off card data from the rest of your network.

Already know you need a test this quarter? Compare published offers.

Build your penetration testing schedule

A good schedule has three separate lines, not one "next test" date. Mixing them is how companies end up paying twice or missing a deadline.

It works like a car inspection. The sticker has a date. A major repair can mean another look before that date. And checking that one repair held is not a new inspection.

The builder below does the date math. Pick the rules that apply, enter your last test date and any big changes planned, and it gives you the interval that governs, your next due date, how many tests to plan for, and the date to book by.

Planning tool

Pentest Schedule Builder

Runs in your browser. Nothing you choose is sent, saved or submitted.

1Who needs the test or the report? Choose at least one.

PCI DSS requirements applicable to our payment environmentPCI DSS service providerPCI DSS multi-tenant service providerFTC Safeguards Rule (financial institution under FTC jurisdiction)NYDFS Part 500 covered entitySOC 2, ISO/IEC 27001 or HIPAAA customer contract or questionnaireOur own policyNo outside requirementNot sure

2Last tests

Date of the last full penetration test of this system

I know the dateNever testedNot sure

Date

3Planned changes in the next 12 months

Significant changes planned (0 to 12)

Types of change, for your own notes only (optional, not used in the calculation)

Sign-in or account recoveryRoles or tenant separationNew public API or sensitive workflowCloud permissions or network boundariesNew third-party access

4Evidence date and planning times

Date the evidence is due (optional)

Lead time before the test starts, calendar days (illustrative)

Testing, calendar days (illustrative)

Report, calendar days (illustrative)

Fixing findings, calendar days (illustrative)

Retest, calendar days (illustrative)

Your schedule

Choose who needs the test or the report to see a schedule.

Copy schedulePrint scheduleClear

Planning aid from The PenTest Index. Not legal advice, not a compliance finding and not permission to test.

Choose who needs the test to start the schedule.

A worked example

This company is made up. Say you run a 30-person SaaS company with one web app and its API. You have a SOC 2 audit. One enterprise contract promises a third-party penetration test every 12 months. Your last full test ended February 12, 2026. A new single sign-on release is planned for January 11, 2027.

The plan: SOC 2 sets no interval, so the contract governs. The next full test is due no later than February 12, 2027. Run it after the sign-on release ships, and one purchase covers both the yearly test and the change.

With the builder's illustrative planning times, the dates look like this:

Here is how that plan holds up against each thing this buyer needs. This is our Purchase Check: we test a plan or an offer against stated requirements, one at a time, and say what is still open.

The one question that settles the open row: "Does the test itself need to fall inside the 12 months, or the retest of the fixes too?" If the retest must also fall inside, start about eight weeks earlier and test the sign-on release separately.

"Supported" here means that one requirement is met by this plan as written. It is not a verdict on any provider, and no provider has quoted for this example.

A blank schedule you can copy

PENETRATION TESTING SCHEDULE

System or scope:
Who needs the report, and why:
Rule, contract or policy that sets the interval (or "not confirmed yet"):
Interval, and where it comes from:
Last full test: dates, scope, report reference:
Next full test due no later than:
Changes that would trigger another test:
Change coming up, and when it will be tested:
Fixes waiting for a retest, owner, target date:
Last day to request a retest, and where the provider says so:
How recent the recipient needs the test to be:
Provider or plan we already have that might cover this:
Open questions, and who is chasing each one:

Keep passwords, findings and system details out of this record. A schedule is not permission to test. Written authorization has to name the actual targets and activities.

How often is penetration testing required? What each rule says

Only some rules name an interval, and those mostly say 12 months. Several well-known frameworks name none. Here is what we found in each text.

Rules that set an interval

Recommendations, not law

No interval in the text

Proposed, not in force. HHS has proposed a HIPAA update that would require penetration testing "at least once every 12 months" and vulnerability scanning at least every six months. It was published as a proposed rule on January 6, 2025. As of October 10, 2026 the Federal Register lists no final rule, and the HHS fact sheet says the current rule remains in effect.

Our 21-rule tracker covers more, including FedRAMP, DORA and IRS Publication 1075, with quotes and exceptions.

This table reports what each text says. It is not legal advice. Your assessor, auditor, customer or regulator decides what they accept.

How often should penetration testing be done if no rule applies to you?

Once every 12 months for each system that faces the internet or holds sensitive data, and again after a significant change. That is our recommendation, not a requirement.

We suggest 12 months for three reasons. It is what the rules that do set an interval mostly say. It is what CIS and MVSP recommend. And it is what a customer is most likely to ask for, since MVSP, a baseline some buyers use to vet vendors, says "at least annually".

It is also what many companies do, though the surveys come from companies that sell testing. In Fortra's 2024 survey, 43% of security professionals said they test once or twice a year, and 17% said never. In Cobalt's 2025 survey of mid-size and large organizations, 30% said quarterly and 27% said once a year. Both are summarized, with their limits, on our statistics page.

A quiet internal system with little exposure does not have to inherit your public app's schedule. Decide it on its own risk and write down why.

Is once a year enough?

Yes, if the system changes little and you fix what the test finds. No, if you ship major changes between tests, or someone who reads your report asks for more.

Four quick checks, and what each answer means:

1. Have you shipped a significant change since the last test? Test the changed part now. Don't wait for the anniversary.
2. Are you still fixing last test's serious findings? A sooner test will mostly find them again. Fix, retest, then test. Four reports published in 2026 give serious-flaw repair and resolution benchmarks of 38 to 58 days, by different measures (our summary).
3. Does a customer, regulator or contract ask for more? Their number wins for that system.
4. None of the above? A yearly test with scans in between is a plan you can defend.

You will see "test quarterly" on a lot of vendor pages. We found no rule in our tracker that requires quarterly penetration tests. In PCI DSS, "every three months" refers to vulnerability scans, not penetration tests. Quarterly testing is a choice you can make for a high-risk app. It is not a requirement.

Do you need a new test after every release?

No. A cosmetic release does not call for a new test. A change that alters how someone reaches the system, signs in, or moves data through it deserves a look, and under PCI DSS a significant change requires a test.

PCI DSS does not give a fixed list. The full standard says what counts "is highly dependent on the configuration of a given environment," and names six things that must at least be considered: new hardware, software or networking equipment in the card data environment; a replacement or major upgrade there; a change in the flow or storage of account data; a change to its boundary or to the scope of the assessment; a change to supporting infrastructure such as directory services or logging; and a change in the vendors that support it.

For everything else, here is how we would sort changes. These examples are our judgment, not a definition from any standard.

The extra test can cover just the changed part. That is why it usually costs less than the yearly one. To describe that part to a provider, write a short scope.

Should you test before or after launch?

Where you can, test a security-sensitive change before it reaches everyone, then check anything the test environment could not show. That is our advice. If a rule requires testing after a change, a test of a staging copy may not satisfy it. Ask your assessor.

Does a focused test restart the yearly clock?

Only if it covered everything the yearly test must cover. Testing one feature, or rechecking one fix, does not move the deadline for the whole system. In the worked example above, the shortcut fails for exactly this reason.

What does testing more often cost?

It depends on how the test is sold. Per-test prices multiply. Packs and annual plans may not, and their pages often don't say how many full tests you get.

We read these pricing pages on October 10, 2026 and did the multiplication. The offers are different kinds of work, so this is not a like-for-like comparison. Every figure is a published list or starting price, not a quote.

The 2-test and 4-test columns are our arithmetic on the published price. Astra and Intruder prices are in US dollars. Pentest-Tools.com shows a dollar sign without naming the currency on this service page.

What this means for your schedule:

• One test a year: per-test pricing is the simple route. You pay for what you use.
• Two or more a year: a pack or annual plan can cost less per test. Intruder's standard pack works out to $3,000 a test, $1,000 less than its standard single price, if you use all four inside the year.
• Before you sign any plan, ask: "How many full tests does this price cover in 12 months, and what does each extra one cost?"

Two things can rule an offer out before price matters. Intruder's process starts with connecting your code repository, so it does not fit if you can't share source code. And an AI-run test only works for you if the person reading the report accepts one. Ask them first.

If your schedule is covered by a provider or plan you already pay for, you may not need to buy anything. Put the same question to them.

Your schedule tells you how many tests to buy. Which offer fits depends on what's being tested and who reads the report. Answer a few quick questions to see which of the offers we compare fit, and get a brief you can send to the providers you choose. It's free, with no email or sign-up, and nothing is sent to providers. It covers web app and API testing best.

Find My PenTest Match

Already decided? Go straight to the published terms.

See Pentest-Tools.com's web app test prices

See Intruder's pentest pricing

See Astra's plans

For more price evidence, see what a penetration test costs.

Does a retest count as your next penetration test?

No. A retest checks that specific findings were fixed. It does not restart the 12 months.

PCI DSS treats them as separate steps. Requirement 11.4.4 says that once weaknesses are corrected, "penetration testing is repeated to verify the corrections." That sits alongside the yearly test, not in place of it.

What a retest does have is its own deadline, set by your provider. Miss it and you may pay extra. Two published examples, read October 10, 2026:

• Astra includes one manual re-scan on Pentest Auto, two on Pentest Expert and four on Enterprise. Requests must be submitted within 30 days of the date the vulnerabilities were reported, or 90 days on Enterprise. Extensions are decided case by case. So if findings are reported March 1, plan to ask for the retest by March 31, and confirm how Astra counts the days.
• Cobalt offers free retesting on Agile and Comprehensive pentests for 6 months on its Standard tier and 12 months on Premium and Enterprise, "only available within an active contract." Its documentation also gives a cutoff of 10 days before your contract ends. A contract that ends soon can shorten your window.

Remember the benchmarks above: 38 to 58 days covers different repair and resolution measures. A 30-day window can close before the fix is ready. Ask before you buy: "How many retests are included, what starts the clock, and what happens if our fix takes longer?"

Read Astra's rescan rules

Read Cobalt's retesting policy

Have a quote in hand? Check its retest terms. More on each offer: Astra, Cobalt.

How recent does a penetration test need to be for a customer or auditor?

Ask them. Twelve months is the common expectation, but only the person reading the report can say what they accept.

Check two things about the report you already have. They are separate, and a recent date answers only one of them.

1. Does it still describe the system? If you have changed sign-in, permissions or what's exposed since the test, the report covers a system you no longer run.
2. Does it meet the reader's terms? That means the date, the scope, and whether they want proof that fixes were retested.

If both hold, you may not need a new test. If one fails, fill that gap and no more.

A question you can copy and send:

How recent must the testing be when we hand over the report, which systems must it cover, and do you need evidence that findings were fixed and retested?

Copy question

For SOC 2, there is no number in the criteria. Your auditor checks you against the control you wrote. If your control says "annual penetration test," that is your interval.

Can scanning or continuous testing replace the yearly test?

A scan does not count as a penetration test. An ongoing testing service can, if what it actually does meets what your rule or report reader asks for.

A vulnerability scan looks for known weak spots. A penetration test tries to use them, the way an attacker would. Rules treat them as two jobs with two schedules. PCI DSS asks for internal scans at least once every three months (Requirement 11.3.1) and penetration tests every 12. Under the conditions above, the FTC rule asks for assessments at least every six months and testing every year. NYDFS asks for scans at a frequency set by your risk assessment, and promptly after material system changes. So run scans between tests. They are the cheaper way to cover the gap. More in penetration testing vs vulnerability scanning.

"Continuous" and "PTaaS" (penetration testing as a service) are labels for how testing is sold. The label does not tell you how often a full test happens. Before you count a subscription as your yearly test, ask the seller:

1. What starts an actual test, and how many are included per year?
2. Which systems and user roles does each test cover?
3. Who does the work, people or software, and who reviews it?
4. When do we get a dated report we can hand to a customer or auditor?
5. How are fixes checked, and until when?
6. What is the total commitment, and can we leave?

If your current provider already meets your rule on these points, you can stay where you are.

When should you book the test?

Work backward from the date someone needs the evidence, and leave room for fixes.

Providers' own pages give a wide spread. Stated start times run from "within 24 hours" to "6-8 weeks out." Stated lengths for a web app test run from 3 working days to 6 weeks. Those are the providers' words as we read them on October 8, 2026, collected here. Allow time for fixes; the repair and resolution benchmarks above range from 38 to 58 days.

A worked illustration, using the builder's planning times: 21 days of lead time, 14 of testing, 7 for the report, 45 for fixes and 14 for the retest come to 101 days. If the evidence is due March 31, 2027, book by December 20, 2026. Your own numbers will differ. Ask each provider for the report date in writing.

On a deadline? See each offer's stated timing.

Can a small company test every two years to save money?

Only if nothing sets a shorter interval, and then it is a risk you are choosing to accept.

Check in this order:

1. Is there a rule, a contract or a written control? If any of them says 12 months, two years is not on the table for that system.
2. What will customers ask? A vendor questionnaire built on MVSP asks for tests "at least annually." A two-year-old report may cost you a deal.
3. What has changed? If the system has barely changed and has little exposure, the case for waiting is stronger. New features, new exposure or unfinished fixes weaken it.

There are better ways to cut the bill than skipping a year. Use any test included in a plan you already pay for. Keep change tests narrow. Run scans between tests. And compare offers on the same scope, so a low price isn't just less work. There is no small-business exemption from a rule that applies to you, apart from the specific ones in the table above.

More questions

Does HIPAA require a yearly penetration test?

Not today. The rule in force asks for a "periodic technical and nontechnical evaluation" and does not name a penetration test. A 12-month requirement was proposed on January 6, 2025 and had not been finalized as of October 10, 2026.

Does SOC 2 require an annual penetration test?

No interval is written into the criteria. They name penetration testing as one way to evaluate controls. What binds you is the control your own company wrote and any promise made to customers.

Do internal and external tests follow the same schedule?

Where a rule sets an interval, it usually covers both. PCI DSS sets 12 months for internal testing (11.4.2) and external testing (11.4.3). NYDFS says "from both inside and outside." CIS recommends both at least annually.

Does cyber insurance require an annual penetration test?

We don't know of a general rule, and policies differ. Ask your insurer or broker in writing what the policy or application requires.

Sources and how we checked

We read each rule ourselves and quote its words. We do not sell, perform or authorize penetration tests, and nothing here guarantees that an auditor, customer or regulator will accept a report. See a mistake? Send a correction.

Next: what a penetration test costs.