When to Expand Your Pentest Scope: A Guide for Series A/B CTOs

Your pentest report can still be current even if your pentest scope is outdated. That's an easy gap to miss at a Series A or B company.

You run an annual pentest, remediate the findings, and keep the report ready for customer security reviews. Meanwhile, engineering keeps shipping. An AI assistant gets added. A mobile app launches. New administrative roles appear. A funding round accelerates an infrastructure migration.

None of those changes automatically means you need another full pentest. But each should trigger the same question: Did we introduce something important that our last pentest never actually tested?

Why pentest scope evolves over time

‍A penetration test is a point-in-time assessment of an agreed scope. Your pentest scope is the subset of your environment pentesters are authorized and expected to assess during a particular engagement. 

‍Your attack surface is broader. It’s the systems, interfaces, functionality, roles, infrastructure, and other components that could potentially be attacked. It can change while your documented pentest scope stays the same.

Not every release requires another pentest. Adding a handful of endpoints or making incremental product improvements probably doesn't require you to rethink your testing program. The changes worth paying attention to are the ones that introduce something fundamentally different: a new application platform, trust boundary, privileged role, integration, infrastructure layer, or system capable of accessing sensitive data or taking actions on a user's behalf.

‍You've added AI features to your product.

Three months after your annual pentest, your engineering team ships an AI assistant that can query customer data and trigger actions through internal tools. Your pentest report is still current. But your pentesters never had the opportunity to assess what happens when someone deliberately tries to manipulate that assistant.

A conventional web application pentest can still cover the surrounding application and APIs. What it doesn't necessarily answer is what happens when someone attacks the AI functionality itself:

Can prompt injection influence downstream actions? 

Can an agent invoke a tool in an unintended way? 

Can sensitive information be extracted through the model? 

Does an AI component have broader permissions than it needs?

That creates authorization risks at the retrieval and tool layers that a conventional application pentest may not be designed to probe. A RAG system might return documents from the wrong organizational context, or a tool-connected agent might be manipulated into acting with more privilege than intended.

An agent that can access customer data and invoke tools creates different trust relationships than a standard CRUD endpoint. Your testing must account for what the AI can actually do. If it didn't, targeted AI security testing may be a more appropriate addition than simply waiting for the next standard application pentest. This distinction can also become important during enterprise security reviews, where buyers may ask for evidence that AI-specific attack surfaces were tested separately from the broader application. 

You've launched a mobile app.

Your last pentest covered your web application and APIs. Six months later, customers can access the same product through an iOS or Android app. It's tempting to conclude that most of the important security testing has already happened because the mobile app communicates with the same backend.

The mobile client introduces its own attack surface that can include:

• local data storage
• device permissions
• certificate validation
• platform-specific behavior
• different authentication
• different session-handling patterns

Those issues exist on the device. The exact testing required depends on how your mobile application is built and what functionality it exposes. Sharing a backend doesn't mean you've tested the mobile client. If the iOS or Android application itself wasn't included in the previous scope, decide whether the risks introduced on the device warrant dedicated mobile application testing.

For example, an API may correctly prevent unauthorized access while the mobile client still stores authentication tokens or sensitive data insecurely on the device. The backend passed its test; the client introduced a separate problem.

An enterprise prospect is asking about something you didn't test

A security questionnaire asks whether a particular integration was tested. The buyer wants evidence of API coverage. Their security team asks whether administrative functionality was included. They want to know whether authorization between different user roles was actually tested.

You pull up your latest report. It doesn't answer the question.

Earlier in a company's growth, excluding certain integrations, APIs, administrative functionality, or RBAC scenarios can be a completely reasonable scoping decision. Not every component carries the same risk or warrants the same testing effort. But your product doesn't stay still.

Tenant isolation has become the most specific version of this problem in enterprise SaaS procurement. In our experience, it's one of the most common security questions enterprise buyers ask, and one that a standard pentest report doesn't automatically answer.

"Did your pentest include explicit cross-tenant authorization testing?" 

A report that covers OWASP Top 10 and authorization testing across user roles answers a different question than whether an authenticated user in one tenant can access another tenant's data through any endpoint in your application. If the scope of the previous engagement didn't explicitly include that test, the report won't provide the evidence the buyer is looking for, and a targeted scope expansion is typically faster and cheaper than repeating the entire engagement.

Does our report provide evidence about the parts of the product this buyer is actually evaluating? If it doesn't, you don't necessarily need to retest everything already in scope. Targeted coverage of an integration, API, administrative workflow, or authorization model may close the gap.

‍Funding or M&A changed your architecture

We've seen a customer's pentest scope roughly double after the company raised funding. The funding wasn't the reason. What the company did afterward was.

The company moved from a single-tenant to a multi-tenant architecture. The application still served the same basic purpose, but the underlying security model had materially changed. Tenant isolation and authorization boundaries now carried significance they hadn't before.

A Series A or B round might fund an infrastructure migration, an architectural redesign, product expansion, or a move to a different tenancy model; each of which can create new trust relationships and shift where risk lies. An acquisition raises a related challenge: previously separate environments, identities, credentials, and permissions often need to coexist or be consolidated. Old and new systems may run side by side during the transition, with credentials crossing boundaries that once kept environments apart. Don't use the business event as the trigger. Look at what technically changed because of it.

If your tenancy model, infrastructure, identities, permissions, or trust boundaries are materially different from those that existed during your last pentest, your previous scope warrants another look.

‍How to tell if your pentest scope is outdated

Pull up the scope from your last engagement and compare the product that was actually tested with the product you're operating today. Don't count releases or endpoints. Look for meaningful changes in what users can access, where sensitive data lives, how systems communicate, which components can take actions, and where trust boundaries exist.

Start with five questions:

• Have you shipped an AI feature since your last pentest?
• Is there an iOS or Android application that wasn't included in the original scope?
• Has a prospect or customer asked for security evidence your existing report doesn't provide?
• Have funding or M&A activities led to meaningful infrastructure or architectural changes?
• Has your tenancy model, authorization model, infrastructure, or another major trust boundary materially changed?

If every answer is no, your existing scope may still represent your environment reasonably well.

If you answered yes to one or more, ask yourself: Did your existing test actually cover the security assumptions introduced by this change?

‍Not sure whether your scope needs to change?

The simplest test is to compare today's product with the product you actually pentested.

‍FAQ

‍How often should you pentest?

Pentest cadence and pentest scope answer two different questions: when should you test, and what you should test. 

‍What should you test?

An annual testing schedule doesn't necessarily mean your scope should remain unchanged for the entire year. Material changes to your product, infrastructure, architecture, or trust boundaries can justify targeted testing between scheduled assessments.

The deciding factor isn't simply how much time has passed. It's whether your existing scope still represents the environment you're operating in.

‍What's the difference between pentest scope and attack surface?

Your attack surface includes everything in your environment that could potentially be attacked. Your pentest scope is the agreed subset of that environment pentesters are authorized and expected to assess during a particular engagement.That means your attack surface can change while your documented pentest scope remains static.

Adding an AI agent, launching a mobile application, introducing new administrative roles, or changing your tenancy architecture can create attack surfaces that weren't included in the previous scope.That doesn't mean there was anything wrong with the previous pentest. The environment changed.

‍Do I need a new pentest every time I ship a feature?

No. Most feature releases don't justify a new penetration test. The changes worth reassessing are those that introduce a materially new attack surface or trust boundary. Examples include AI functionality with access to tools or data, a new mobile application, major integrations, new privilege levels or roles, significant architectural changes, or infrastructure migrations.

Even then, another complete pentest may not be necessary. Targeted testing of the new attack surface may be a more appropriate addition to your existing security testing program.