How often should you pentest your web app and API?

Set your web app and API pentest schedule by risk, and test again whenever a change could materially affect security. No single interval suits every SaaS product, and a calendar reminder can't tell you that you've just replaced your login system, redesigned permissions or exposed a new API.

In practice that means three layers: regular automated checks, planned manual assessments, and testing triggered by specific changes. Running one layer more often doesn't fill the gaps in another.

Start with exposure, impact and rate of change

Start by working out what is reachable and what a failure could expose. An internet-facing, multi-tenant app holding sensitive customer records needs testing far more often than an internal prototype running on synthetic data. Count the APIs, integrations and admin functions as well as the screens customers see.

Then look at how quickly the security-relevant parts of the product change. If your team edits authorization rules, account recovery or data-sharing every few weeks, focused tests between broader reviews are probably worth it. An interface that looks stable can still pick up risk through dependency updates, configuration changes and new integrations.

Finally, check your contracts and any regulations that apply to you with whoever owns them. A specific obligation may set a testing activity or interval, and that's the part to follow exactly. What you can't do is treat a generic recommendation, including this one, as proof of compliance, or assume every organization is bound by the same annual rule.

Use three complementary testing layers

Routine automated checks provide recurring feedback on the weaknesses they can detect. Depending on the application, that may mean running suitable code and dependency checks in development and scheduling authorized application scans. Set frequency around deployment practices, tool safety and the team's ability to act on results.

Planned manual assessments are where someone steps back and looks at broader risk. Choose the interval on purpose, write down why it suits your exposure and contracts, and revisit it when the product or the business changes.

Change-triggered tests don't wait for the next scheduled engagement. They can be much narrower, covering just the changed control and whatever depends on it, as long as you note what was checked and what's left for the broader review.

Changes that should trigger a testing decision

Changes to how people sign in come first: a new authentication provider, a different password recovery flow, or new session handling. Each affects who can get access and how long they keep it. Run your automated checks, and decide before the wide rollout whether a focused manual review is needed.

Changes to roles, tenant boundaries, sharing links or admin functions come next. The OWASP API Security Top 10 lists broken object-level and function-level authorization among its top API risks, and both tend to appear exactly when these areas change. New endpoints or API versions can add exposure even when the frontend barely looks different.

File uploads, external callbacks, payment-related workflows and third-party integrations all bring in new trust boundaries, because your app starts accepting input or requests from somewhere new. A significant configuration change or a security incident should also prompt a fresh look at the affected area. Bear in mind that incident response and a pentest are different jobs, and neither stands in for the other.

An illustrative cadence for a changing SaaS product

Imagine a hypothetical small SaaS team about to launch team workspaces. Before release, it maps the new roles, sets up separate test organizations and reviews how authorization is meant to work. It then arranges a focused assessment of the new boundaries and the APIs behind them, on top of its usual automated checks.

After launch, the team keeps running its automated tests and working through new findings. A few months later it replaces its identity provider. The workspace assessment doesn't cover that, so the team gets login, recovery and session behaviour tested again, because those are the controls that changed.

Each test in that story is tied to the risk a particular change introduced. That's the habit worth copying, rather than rerunning an unrelated test because the calendar says it's time.

Retest fixes and keep the evidence usable

A testing schedule needs room for fixing and retesting, not just for the tests themselves. A retest shows whether a specific behaviour has changed. It tells you nothing about the rest of the application.

Record the environment, tested version, scope, accounts used, limitations and resolution status. If a report is requested later, these details explain what its conclusions actually cover. Add regression tests where practical, and assign ownership for issues that remain unresolved.

For a lean team, maintain one short assessment register: last review, current scope, major changes since then, open findings, owner and next decision point. This makes the next test a deliberate choice instead of a rushed response to an expiring document.

Frequently asked questions

Is once a year enough?

For some teams, an annual assessment is a reasonable baseline, but it won't be enough if important changes land in between. Your risk, your contracts and any regulations that apply to you should set the schedule. There isn't one annual rule that applies to everyone.

Do we need a full pentest after every deployment?

No. Match the depth of testing to the change. Automated checks and regression tests can cover ordinary releases, while a change to a sensitive control, such as permissions or sign-in, may deserve a focused manual look.

Does continuous scanning replace periodic manual testing?

No. Scanning gives you frequent feedback on what it can detect. Running it more often doesn't give it an understanding of your application or the investigative depth of a well-scoped manual assessment.

A useful next step is to list everything security-relevant that has changed since your last assessment. Some items may only need automated web and API checks, such as pentest99.com offers (confirm what it currently covers). The rest is where to point a manual tester.

Sources: OWASP API Security Top 10 (2023); OWASP WSTG. Sources checked: November 2026.