# Recurring penetration testing after each release

Source: https://penetrationtestservices.com/recurring-penetration-testing/
Publisher: Excession Labs (penetrationtestservices.com)
Last updated: 2026-11-09

Recurring vs continuous penetration testing: we test web apps and APIs after meaningful releases, scope only what changed, and verify fixes from the last report.

> **Short answer:** Recurring penetration testing means repeating a scoped test after meaningful releases, instead of once a year. Each round covers what changed: new features, new roles, new API routes and fixes from the last report. Excession Labs agrees the scope for each round in writing. It is release-driven testing and does not monitor your system around the clock.

If your product ships every week, a single annual pentest describes a version of the app that no longer exists. Recurring penetration testing repeats the test after the releases that matter, so the evidence stays current. We test at agreed points. We do not watch your system around the clock, so this is not continuous testing.

## When should you test again?

Test after each meaningful release. A change is meaningful when it can alter who may do what or where data flows.

Common triggers:

- A new role, permission or sharing feature.
- A new API route, version or public integration.
- A change to sign-in, SSO, MFA or password reset.
- A change to billing, plans or entitlements.
- A new file upload, import or export.
- A new tenant model, database or storage layout.
- Fixes from the last report, which need verification.

Standards set minimums that a fast-moving team may need to exceed. PCI DSS v4.0.1 requires penetration tests at least once every 12 months and after significant change (requirement 11.4, as reported in vendor summaries; confirm the wording with your assessor). The [PCI SSC](https://blog.pcisecuritystandards.org/just-published-pci-dss-v4-0-1) states v4.0.1 is the only active version. In the Cobalt 2025 survey, 27% of respondents tested annually and 30% quarterly ([Cobalt, Figure 5](https://resource.cobalt.io/state-of-pentesting-2025)). The guide [how often should you pentest](/guides/how-often-should-you-pentest/) covers the rest.

## What does a recurring round cover?

Each round has a written scope in three parts.

| Part | What it covers |
|---|---|
| Scope delta | What changed since the last test: features, roles, routes, integrations |
| Fix verification | Each finding from the last report, checked again |
| Regression checks | Controls that held last time, tested again near the changes |

We do not repeat the whole test unless you ask for it. A delta round is smaller, so it costs less than a first test. The first round sets the baseline: a full test of the app, with a report that lists controls that held.

## How do we prove findings each round?

The evidence standard does not change between rounds. A finding needs evidence of a real effect. We read the changed record back through another session, run controls next to each exploit request, and save requests and responses with timestamps. The [methodology](/methodology/) page has the details.

> **Sample finding:** This is a demonstration. It uses a fictional app, Harbor Notes, and no real customer system was tested.
> 
> **Finding R-05 (round 2): New share links ignore the note's owner check (Medium).** Release 2.8 added share links. The previous round tested `/api/notes/{id}` only.
> 
> ```http
> POST /api/notes/7731/share HTTP/1.1
> Host: api.example.com
> Authorization: Bearer 
> ```
> 
> Note 7731 belongs to user B. The response was `201 Created` with a link, and the link opened the note anonymously (Observed). Control: note `999999` returned 404. Fix: apply the same owner check on the share route.
## What do you get?

Each round produces a report in HTML, PDF and Markdown, with proof-of-concept scripts. The report contains an executive summary, a findings table, per-finding sections and a remediation plan. A fix-verification section states the result for each earlier finding. See [retesting](/retesting/) for what a retest result looks like.

## What do we need from you?

- A release note or change list since the last round.
- A build or tag to test, and a staging or production plan.
- Updated accounts and roles, including any new ones.
- Updated API docs or a route list.
- The last report's open findings and what you changed.
- Written authorization for each round, and a technical contact.

## What changes the quote?

The size of the scope delta, the number of new roles and routes, and the number of fixes to verify set the quote. So does the number of rounds per year. We publish no prices and quote after scoping (see [pricing](/pricing/)).

The guide [after the pentest: remediation and retest](/guides/after-the-pentest-remediation-and-retest/) covers what happens after the report. To start, [request a pentest](/contact/).

## Questions

### How often should we test?

Test after changes that touch authentication, access control, payments, data models or new integrations. Standards such as PCI DSS set a minimum of once every 12 months and after significant change. See our guide on how often to pentest.

### Is this the same as continuous testing?

No. We test at agreed points, after releases that matter. We do not watch your system around the clock. Say what triggers a new round, and we agree the scope each time.

### Does each round retest old findings?

Fixes from the last report can be included in the next round's scope. We verify that each fix works and that nearby controls still hold. Agree this at scoping.

### Can we change the scope between rounds?

Yes. Scope follows your product. Each round has its own written scope, so new features, roles and APIs are added when they ship.

## Sources

- [PCI SSC blog: Just Published: PCI DSS v4.0.1](https://blog.pcisecuritystandards.org/just-published-pci-dss-v4-0-1)
- [PCI DSS v3.2.1 to v4.0 Summary of Changes, r1](https://listings.pcisecuritystandards.org/documents/PCI-DSS-v3-2-1-to-v4-0-Summary-of-Changes-r1.pdf)
- [Cobalt State of Pentesting Report 2025, Figure 5](https://resource.cobalt.io/state-of-pentesting-2025)
