How Often Should You Pentest? Time Testing to Releases, Not the Calendar

Most SaaS companies treat penetration testing like a fire extinguisher: buy it, mount it on the wall, forget it exists until the auditor asks where it is. That’s not a security program. That’s a compliance transaction dressed up as one.

A real testing program has a shape. It has cadence, sequencing, and memory from one year to the next. Here’s how to build one that actually gets stronger over time instead of resetting to zero every January.

The Checkbox Problem

Annual pen testing exists because auditors and enterprise procurement teams require it. That’s a fine reason to start, but it’s a bad reason to stop thinking. If your only question is “did we check the box this year,” you’re optimizing for a report, not for risk reduction.

The organizations that get real value from testing ask a different question: what did last year’s test teach us, and how does that shape what we test next? A program with memory finds different things than a program that starts from scratch every twelve months because your attack surface doesn’t reset either. New features ship, new integrations get added, and the vulnerabilities you fixed last year have cousins hiding in the code you wrote this year.

Build the Calendar Around Two Anchors

Most teams try to schedule testing around a single date on the compliance calendar. That’s backwards. You need two anchors, not one.

Compliance deadlines set the floor. If you’re pursuing SOC 2 Type II, ISO 27001, or a customer security questionnaire cycle, you know roughly when evidence is due. Just remember that passing the audit and being secure are different things. Work backwards from that date with enough buffer to remediate findings before the audit, not during it. A test that finishes the week before your audit window opens is a test with no time to fix anything.

Release cycles set the rhythm. If you ship major features quarterly, testing once a year means three-quarters of your product ships untested until the next annual engagement finds it, sometimes a year later. Mid-market SaaS teams with meaningful release velocity should treat testing as a cadence tied to what changed, not just when the calendar says it’s due. That doesn’t mean a full-scope engagement every quarter. It means matching scope to what’s new: a major new module gets its own targeted test; incremental changes can wait for the next scheduled assessment.

The teams that get this right treat compliance as the non-negotiable minimum and layer in additional targeted testing around significant releases. The teams that get it wrong let compliance define the entire program and are surprised when a real incident happens in the nine months between tests.

Sequencing: What to Test, and in What Order

Not everything needs the same depth every year. A sensible multi-year sequence looks something like this:

1. Year one establishes the baseline. This is typically your broadest engagement, external and internal network, web application, and any customer-facing APIs, because you’re building the map of your environment for the first time.
2. Subsequent years narrow scope based on what changed. New product lines, new cloud infrastructure, or a shift to a new authentication model each warrant their own focused test. Areas that haven’t changed and tested clean can move to a lighter revalidation.
3. Retesting is not optional and not an afterthought. Every finding that gets remediated needs to be verified, not just marked “closed” in a spreadsheet. Finding closed is not finding fixed, and a program that skips verification is trusting that the fix worked instead of confirming it.

This is where a lot of programs quietly fail. Retesting gets treated as a nice-to-have that falls off the roadmap once the report is filed and the board update is sent. A program that’s actually built for the long term treats retesting as a structural part of the calendar, not a bonus round.

What a Multi-Year Program Looks Like

A mature program has three properties a one-off engagement never will:

• Findings from year one inform scope in year two. If your test firm doesn’t carry that history forward, you’re paying full price to relearn things you already knew.
• Retesting is built into the cost of doing business, not an add-on you negotiate every time. This is why we include five free retests with every engagement. It’s not a discount gimmick, it’s an acknowledgment that a finding isn’t actually resolved until someone verifies it, and that verification shouldn’t be a line item you have to fight for.
• The relationship compounds. A tester who has worked with your environment for three years understands your architecture, your risk tolerance, and where the bodies are buried, in a way a new vendor starting cold never will. That’s part of why EliteSec is founder-led: the same person scoping your test in year one is the one reviewing your fixes in year three.

If you’re currently choosing between a full penetration test and a lighter vulnerability assessment for a given cycle, that decision should be driven by where you are in this sequence, not by which one is cheaper this quarter.

Putting It on the Calendar

In practice, few teams follow a clean Q1-Q4 script, and you shouldn’t force one. Some clients book their next assessment a full quarter ahead. Others call in needing testing the following week. Most of the demand we see clusters in Q2 and Q3, as teams push to get tested before a compliance window closes or before a major release ships. There’s no single calendar that fits every organization, but there is a principle worth holding onto: test before you release, not after.

Time testing to what’s shipping, not to a fixed quarter. If a major release is coming, get tested ahead of it so you have runway to fix what’s found before it reaches customers (here’s how to prepare so the engagement itself doesn’t slip). That’s a more useful trigger than “it’s been a year” or “it’s Q1 on the spreadsheet.”

Base retest timing on severity and your own remediation SLAs, not the calendar. A reasonable heuristic:

• Critical findings: fix and retest as soon as possible.
• High findings: within two weeks.
• Medium findings: within four to six weeks.
• Low findings: as your schedule allows.

This is a starting point, not a rule. Some teams retest within a few weeks of getting their report. Others need up to six months to work a fix through their release process, which is part of why we give clients a 12-month window to use their five free retests rather than forcing a fixed turnaround. Because a pentest can land in any quarter depending on when your compliance cycle or release plan calls for it, a rigid schedule is less useful than a clear rule for when testing and retesting should happen relative to what you’re building.

The firms selling one-time engagements have no incentive to help you think this way. A program that compounds year over year is worth more to you and less predictable in billable hours, which is exactly why so few vendors bring it up. Build the calendar anyway. Your third year of testing should be finding different things than your first, not the same things again.