Most SaaS startups should re-pentest at least once every 12 months. That is the floor for auditor and enterprise customer freshness expectations. On top of that annual cycle, re-pentest after any of four triggers: a major release that introduces new attack surface, a refactor that changes architecture, a security incident with root cause beyond your original pentest scope, or an enterprise contract that requires evidence within the last 12 months. Fintech, health, and regulated SaaS often run on a 6-month cycle because their buyers expect tighter freshness.
An enterprise customer’s security team emails you. “Your last pentest report is from 14 months ago. We need evidence from the last 12 months for our annual vendor review. Can you share something current by end of next week?”
You do not have one. The deal is in motion. Your champion is asking what timeline you can commit to. The procurement clock is ticking.
Or: your SOC 2 Type 2 observation window opens in 8 weeks. Your auditor expects the pentest to fall inside the window. The one you did last March is outside it.
Or: you shipped a major refactor in the last quarter. New auth provider, new payment integration, new tenant isolation model. The pentest you did before the refactor does not cover the new attack surface. The old report is technically valid, but it is not relevant to what an attacker would test today.
These are the moments when re-pentest cadence stops being theoretical and becomes a deal-protection decision. This is the timing deep-dive in our Pentest Buyer-Education series. It complements the what is penetration testing pillar, the DAST vs pentest explanation of why scanner output does not substitute for periodic re-pentest, the 5 questions to ask a pentest vendor that re-apply on re-engagement, the pentest cost guide for re-pentest budget planning, and the SOC 2 pentest timing walk-through.
Why Re-pentest Cadence Matters
Auditors, enterprise customers, and investors all evaluate your pentest evidence on three dimensions: scope (did it cover what matters), depth (was it manual + methodology-driven, aligned to standards like NIST SP 800-115), and freshness (when was it done). Of the three, freshness is the one most founders underestimate.
A pentest report from 14 months ago can be a 100 percent valid report and still get rejected on freshness alone. The reviewer is not questioning the work. They are applying a default rule: evidence older than 12 months does not count for this audit period or this vendor review cycle.
Three buyers, three freshness defaults:
SOC 2 auditor. Your pentest report needs to fall within the audit observation period. For Type 1 audits, that is the point-in-time assessment date. For Type 2 audits, that is typically a 12-month window. A pentest done 3 months before the window opened does not satisfy the requirement. Auditors are increasingly strict about this because the AICPA Trust Services Criteria at CC7.1 and CC7.2 emphasize ongoing monitoring evidence.
Enterprise customer vendor review. Most enterprise security teams run annual vendor reviews. They ask for current evidence: current pentest report, current SOC 2 report, current vulnerability management evidence. “Current” usually means within the last 12 months. Some industries (financial services, healthcare, government) tighten this to 6 months.
Investor diligence. Series A and later rounds increasingly ask for a recent pentest report as part of technical diligence. The investor’s technical advisor or third-party diligence firm will check the date on the report. A 2-year-old report signals that security is not actively maintained, regardless of how good the original report was.
The cost of losing a deal or failing an audit because of pentest freshness is asymmetric to the cost of running the re-pentest. A re-pentest costs INR 75,000 to 1.8 lakh per the pricing guide. A stalled enterprise deal that was tracking to INR 25 lakh ARR for year 1 is two orders of magnitude more expensive. The math is unambiguous. The discipline is making the budget decision before the deal-protection moment, not during it.
The 4 Re-pentest Triggers
There are four triggers that should drive a re-pentest decision. The first is time-based. The other three are event-based and stack on top of the annual cycle.
Trigger 1: Time-based (annual minimum)
Annual is the floor. The reason is not technical, it is institutional. Auditor playbooks, enterprise vendor review cycles, and investor diligence checklists all default to a 12-month freshness window. Going beyond 12 months puts you outside that default and into a defensive position where you have to argue why your older report should still count.
The exception is high-risk SaaS where buyers expect 6-month cadence:
- Fintech and payment SaaS. PCI-DSS, RBI Master Direction on IT Governance and Cyber Security, payment scheme rules all push toward 6-month or quarterly testing on payment-handling components.
- Health and patient-data SaaS. Customer security teams in healthcare, especially those serving US hospital systems, expect 6-month cadence on critical paths.
- Critical infrastructure and government-adjacent SaaS. CERT-In Critical Information Infrastructure designations and sector-specific frameworks tighten cadence.
- High-velocity release teams. SaaS shipping new major functionality every quarter often run a quarterly micro-pentest on the changed surface plus an annual full pentest. The annual still covers stable surface; the quarterly covers what shipped recently.
For most Series A to B SaaS outside those categories, annual is the right cadence baseline. Push to 6-month when your enterprise customer or auditor explicitly requires it.
Trigger 2: Release-based (after major release)
Major releases change the attack surface. The pentest you did before the release does not cover the new surface. Auditors and enterprise customers know this. So do attackers.
What counts as a major release:
- New authentication flow. Moving from session cookies to JWT, adding SSO, adding magic links, adding biometric login, adding passkeys, replacing your auth provider.
- New payment integration. Adding Razorpay, Stripe, or a new payment processor. Adding subscription billing logic. Adding refund or chargeback flows.
- New privileged-data API. Adding an API that exposes PII, financial data, health records, or admin-only fields. Adding bulk export endpoints. Adding cross-tenant query capabilities.
- New third-party integration. Adding a webhook receiver from a third party. Adding an OAuth integration with a high-trust partner. Connecting to a data warehouse or analytics platform that handles customer data.
- New role or permission model. Adding admin tiers. Splitting roles. Adding delegation or impersonation features. Changing tenant isolation logic.
- New tenant-isolation logic. Moving from row-level to schema-level isolation. Adding sub-tenant or workspace constructs. Changing how customer data boundaries are enforced.
What does not count as a major release:
- Bug fixes and UI tweaks
- Copy changes
- Internal refactors that do not touch the trust boundary
- Performance optimizations
- Logging, observability, and monitoring improvements
- Feature flag toggles for already-tested features
The judgment call: did this release change what an attacker could try, or change what they could access if they succeeded? If yes, scope a focused re-pentest on the changed surface. If no, your annual cycle still covers you.
The trap to avoid: re-pentesting for every release. That breaks pentest budgets, exhausts your engineering team’s remediation capacity, and creates pentest fatigue where findings stop getting taken seriously. Be disciplined about what counts as major.
Trigger 3: Refactor-based (after architecture change)
A refactor changes the underlying structure. The old pentest covered the old structure. The new structure has new attack patterns that the old pentest did not test.
Examples that warrant re-pentest:
- Monolith to microservices migration. Service-to-service auth, internal API surface, service mesh configuration, mTLS handling, all new attack vectors.
- Cloud-provider migration. Moving from AWS to GCP, GCP to Azure. IAM model changes, VPC topology changes, managed service exposure changes.
- Framework swap. Moving from Rails to Node, Django to FastAPI, Express to Fastify. Different middleware ecosystems, different default security postures, different vulnerability patterns.
- Core dependency replacement. Replacing your ORM, your job queue, your caching layer, your search engine. These touch the trust boundary in ways that can introduce new attack surface.
- Database migration. PostgreSQL to MongoDB, single-tenant to multi-tenant database, on-prem to managed service.
- Auth provider swap. Replacing Auth0 with Cognito, Clerk with Supabase Auth, custom auth with a managed provider.
Refactor-based re-pentests are often broader than release-based because the changes are pervasive. A monolith-to-microservices migration is not a focused change. It rewrites how every component talks to every other component. Plan a full re-pentest, not a focused one.
Trigger 4: Incident-based (after security incident)
After a security incident, you need to know two things: did the fix work, and did the incident reveal a class of weakness that exists elsewhere in your application that your original pentest did not cover.
A re-pentest scoped to the incident answers both. It validates the fix in production state (not just in code review). It expands scope around the root cause to test for sibling weaknesses. If your incident was a broken access control in one API endpoint, the re-pentest tests every API endpoint for the same class of bug.
Incidents that warrant a re-pentest:
- Confirmed data breach or unauthorized access
- Successful exploitation by a bug bounty researcher or external reporter (whether or not you have a formal program)
- Customer-reported security issue that you confirmed and patched
- Indicator of compromise found during routine monitoring
- Lateral movement detected in your environment
- Credentials compromised in a way that exposed customer data
The re-pentest after an incident is also evidence. If you have to disclose the incident under DPDP Act, CERT-In Direction 2022 reporting obligations, or a customer contractual breach notification, having a post-incident re-pentest report demonstrates that you took remediation seriously and validated the fix. That changes the conversation with the regulator, the customer, and your insurance carrier.
Re-pentest Scope Decisions: Don’t Re-test EVERYTHING
A common mistake is treating every re-pentest as a full re-pentest. That is unnecessary, expensive, and exhausts your engineering team’s remediation capacity. The right approach is scope-by-trigger.
Re-test changed components first. If a release added a new payment integration, the re-pentest scope should be the payment integration plus the surrounding flows that interact with it (cart, checkout, subscription management, refund handling).
Smoke-test unchanged components. For surface that has not changed, a lighter-touch validation is sufficient. The unchanged surface is still in your annual cycle. The re-pentest is not re-validating it; it is just confirming the changed surface did not break something elsewhere.
Full re-pentest only when changes are pervasive. A monolith-to-microservices migration warrants a full re-pentest. A new auth flow warrants a focused re-pentest on the auth flow plus interaction points. A bug fix warrants no re-pentest at all.
The vendor should be able to walk this through with you during the scoping conversation. If a vendor quotes you a full re-pentest at full price for what is clearly a focused change, that is a signal to push back or get a second quote. We confirm re-pentest scope in writing before kickoff so the price matches the actual work, not a default plan.
Re-pentest vs Retest: Clarify the Difference
Buyers conflate retest and re-pentest. They are different engagements with different scopes, prices, and uses.
Retest verifies that findings from a single pentest engagement have been fixed. It is part of the original scope. It uses the same threat model, the same tester, and tests against the specific findings in the report. The deliverable is a retest section appended to the original report confirming which findings are now closed.
At Cybersecify, retest is included:
- Startup Pentest: 1 full retest within one month of the v1.0 report
- Growth Pentest: 1 full retest within one month of the v1.0 report
Most quality vendors include retest. Some bill it at 30 to 50 percent of the engagement cost. Always confirm before signing.
Re-pentest is a new engagement after time has passed or after the application has changed. It scopes fresh testing against the current state of the application. It is not verification of old findings. It produces a new report with a new engagement date.
The distinction matters for budget and for evidence. A retest report extends the validity of the original engagement (here is what was found, here is what was fixed). A re-pentest report is a separate evidence artifact (here is what we tested in March 2027 vs what we tested in March 2026).
When your enterprise customer asks for “your most recent pentest report,” they mean re-pentest. They do not mean a retest of a 14-month-old engagement.
Re-pentest Trigger Matrix
This is the decision table. Use it for budget planning, release planning, and conversations with auditors or enterprise customers.
| Trigger Type | Example | Recommended Scope | Cybersecify Plan Fit |
|---|---|---|---|
| Time-based (annual) | 12 months since last pentest, no major changes | Full re-pentest of original scope | Startup (1 scope) or Growth (2 scopes) |
| Time-based (6-month, high-risk) | Fintech SaaS, payment processing, health data | Full re-pentest of original scope | Growth Pentest (annual) + focused Startup re-pentest at month 6 |
| Major auth-flow change | Added SSO, added passkeys, swapped auth provider | Focused re-pentest on auth + interaction points | Startup Pentest scoped to changes |
| New payment integration | Added Razorpay, added subscription billing, added refund logic | Focused re-pentest on payment flows + adjacent flows | Startup Pentest scoped to changes |
| New privileged-data API | Added admin API, bulk export, cross-tenant query | Focused re-pentest on new API + access control | Startup Pentest scoped to changes |
| Architecture refactor | Monolith to microservices, cloud migration, framework swap | Full re-pentest of original scope (changes are pervasive) | Growth Pentest (multi-scope coverage) |
| Post-incident | Confirmed breach, bug bounty exploit, customer-reported flaw | Focused re-pentest on root cause + sibling weaknesses | Startup Pentest scoped to incident scope |
| Enterprise contract requirement | Customer asks for evidence within last 12 months | Full re-pentest of in-scope surface for that customer | Startup or Growth depending on scope count |
India Regulatory and Audit Context
For India-anchored SaaS, four regulatory and audit frameworks shape re-pentest cadence expectations.
CERT-In Direction 2022 mandates incident reporting within 6 hours and certain baseline security controls. It does not impose a uniform pentest cadence on all private SaaS, but customer contracts (especially with banks, payment companies, government departments) often flow CERT-In expectations down to vendors. If your customers are CERT-In-regulated, expect their vendor security questionnaires to ask for annual or 6-month pentest evidence. See our CERT-In incident reporting walk-through for the framework detail.
RBI Master Direction on IT Governance and Cyber Security (April 2024) requires annual cyber audits for regulated entities (banks, NBFCs, payment system operators, NPCI-affiliated entities). If your SaaS sells to or processes data for any RBI-regulated entity, their annual audit cycle will pull you in. Re-pentest cadence aligns with their audit calendar. See RBI cybersecurity framework for fintech startups for the regulated-fintech walk-through.
SOC 2 Type 2 observation period is typically 12 months. Your pentest report must fall within the window. Annual re-pentest aligned with your audit calendar is the standard pattern. See penetration testing for SOC 2 for the auditor-perspective deep-dive.
ISO 27001 audit cycle. Initial certification (Stage 1 + Stage 2) requires evidence of independent testing. Surveillance audits (annual for 2 years after Stage 2) and recertification (every 3 years) continue to ask for current pentest evidence. Annual re-pentest aligns with the surveillance audit cycle.
DPDP Act 2023. Significant Data Fiduciary designations carry an annual independent audit obligation under Section 10(2)(c). The draft DPDP Rules expected to be notified in 2026 will likely formalize what evidence the audit needs. Pentest evidence is highly likely to be part of it. Read our DPDP Act compliance checklist for the broader DPDP framework.
For SaaS startups not in regulated sectors, the cadence driver is customer + auditor + investor expectations, not regulation directly. Annual is the floor. 6-month is right when buyers explicitly require it.
What a Re-pentest Engagement Looks Like
Re-pentest engagements are usually 50 to 70 percent of the original pentest scope. The reduction comes from:
- Scope-by-trigger: testing changed components in depth, smoke-testing unchanged
- Threat model carryover: the threat model from the original engagement applies (with delta for the new surface)
- Architecture understanding: the tester does not need to relearn the application
- Findings baseline: known-and-fixed findings do not need re-discovery; the focus is new findings
Cost is typically 60 to 80 percent of the original engagement. For a Startup Pentest re-engagement at INR 74,999 original, expect INR 45,000 to 60,000 for a scope-focused re-pentest, depending on how much surface is affected. For a Growth Pentest re-engagement at INR 1,79,999 original, expect INR 1,20,000 to 1,50,000 for an annual cycle covering the same 2 scopes.
The Cybersecify approach for re-pentest:
- Re-scope conversation. What changed since the last engagement? What is the trigger? What is the audit or customer driver?
- Scope confirmation in writing. What surface is in scope, what is smoke-tested, what is out of scope. Price matches actual scope.
- Re-engagement using same plan structure. Startup Pentest or Growth Pentest, scoped to changes. No separate re-pentest SKU.
- Report references prior engagement. New report cross-references the previous report for trend visibility (closed findings, repeat patterns, scope evolution).
- Same methodology. OWASP WSTG v4.2 + PTES. Manual + tool-assisted. Senior OSCP-led testing.
- Same retest inclusion. Re-pentest engagements include retest the same way as the original engagement.
For multi-year customers, we maintain the engagement history so each new re-pentest builds on prior context. That is one of the practical benefits of staying with the same vendor across years.
What Cybersecify Offers for Re-pentest
We do not have a separate re-pentest product. Re-pentests use the same plan structure as initial engagements, scoped to the changes.
Startup Pentest (INR 74,999, 5 business days, 1 scope). Right for narrow re-pentest of a single application post-refactor, focused re-pentest on a single major release, or annual cycle for a SaaS with one application in scope. Includes 1 full retest within one month of the v1.0 report. PTES + OWASP WSTG methodology.
Growth Pentest (INR 1,79,999, 10 business days, 2 scopes). Right for annual cycle covering multiple applications, full re-pentest after a pervasive refactor (monolith to microservices, cloud migration), or 6-month cycle for regulated SaaS. Includes 1 full retest within one month of the v1.0 report, SOC 2 + ISO 27001 audit prep, and real-world attack simulation. Additional scopes at INR 74,999 each (from the 3rd scope, scopes run in parallel up to 3 at a time, +5 business days per batch; 5+ scopes get a custom scoping proposal).
For scope-focused re-pentests where the changed surface is genuinely narrow, we will scope and price it accordingly. We do not default to full price for partial scope. The re-scope conversation is part of the engagement.
View pricing details for plan comparison. Book a free 30-minute call with the founders to scope your re-pentest engagement or discuss timing relative to your audit or customer cycle. We will map your current state, your trigger, and the right scope.
The Bottom Line
Annual is the floor. Re-pentest triggers on top of the annual cycle: major release with new attack surface, architecture refactor, security incident, enterprise contract requirement. The cost of running a re-pentest is one to two orders of magnitude less than the cost of a stalled enterprise deal, failed audit, or post-incident breach disclosure without remediation evidence.
The discipline is making the cadence decision before the deal-protection moment, not during it. Budget for annual re-pentest as a recurring line item. Treat event-based re-pentests as part of release planning, refactor planning, and incident response. Keep prior reports as part of your security evidence library.
Book a 30-minute call to scope your re-pentest engagement, or view full pricing to plan budget for the next 12 months.
We are a founder-led cybersecurity firm in Bengaluru working with AI-first and API-first SaaS startups, Seed to Series B. Both founders are personally involved in every engagement. No juniors, no handoffs. Our team holds OSCP, CISSP, CEH, and ISO 27001 Lead Auditor certifications. See our web application pentest service page, API pentest service page, or AI application pentest service page for scope detail, or contact us directly.