How Often Should You Do Penetration Testing in India? Frequency by RBI, PCI DSS, SEBI and Customer Requirements
How often should penetration testing be done in India? RBI, SEBI, PCI DSS and SOC 2 frequencies in one table, the changes that trigger a test, and one calendar.
How Often Should You Do Penetration Testing in India? Frequency by RBI, PCI DSS, SEBI and Customer Requirements
How often should penetration testing be done in India? RBI, SEBI, PCI DSS and SOC 2 frequencies in one table, the changes that trigger a test, and one calendar.
Most Indian companies should run a penetration test at least once a year and again after any major change to their systems. Some regulated businesses must test more often. Middle Layer and larger NBFCs need a vulnerability assessment every six months, and some SEBI-regulated entities, such as market infrastructure institutions and qualified stock brokers, need VAPT every half-year.
Your real answer comes from three layers: the minimum your rules set, the changes that should trigger an extra test, and how fast your own systems change.
Layer 1: the minimum your rules set
Here is what each common rule asks for. Find every row that applies to you. Your floor is the strictest one.
| Rule | Who it covers | Minimum frequency |
|---|---|---|
| RBI NBFC Directions 2026 (Chapter V) | Middle, Upper and Top Layer NBFCs | VA every 6 months, PT every 12 months on critical and customer-facing systems |
| RBI NBFC Directions 2026 (Chapter IV) | Base Layer NBFCs, assets ₹500 crore and above | No fixed calendar; a vulnerability management process and yearly IS audit |
| RBI Payment Aggregator Directions 2025 | Payment aggregators | Bi-annual VAPT reports to the IT Committee; annual system audit |
| SEBI CSCRF | MIIs and qualified stock brokers | VAPT every half-year |
| SEBI CSCRF | Other SEBI-regulated entities | At least yearly; some categories more often, so check your tier |
| PCI DSS v4.0.1 | Businesses that handle card data | Internal and external pentest every 12 months; service providers test segmentation every 6 months |
| SOC 2 | SaaS companies with SOC 2 reports | No fixed frequency; auditors usually expect a recent independent test |
| ISO 27001 | Certified organisations | No fixed pentest frequency; testing supports vulnerability management and secure development controls |
Two notes before you plan. First, almost every rule also asks for testing after significant changes, not only on a calendar. Second, the rules differ on who may test. SEBI CSCRF VAPT and RBI's payment aggregator system audit need CERT-In empanelled auditors, while RBI's NBFC Directions and PCI DSS ask for qualified, independent testers.
A common myth worth clearing up: the 2022 CERT-In Directions are about reporting incidents within six hours and keeping logs. They do not set a pentest frequency for every Indian company.
Layer 2: the changes that should trigger a test
A calendar test checks your systems on one day. Attackers look at them every day. These events should start a test even if your yearly one is months away:
A new product, app or customer portal goes live
A major release that changes login, payments, roles or data access
A move to a new cloud account, region or provider
A new third-party integration, such as a KYC, payment or AI provider
A change to network segmentation or firewall design
After a security incident, to confirm the hole is closed
Before a big enterprise deal or funding round, when buyers ask for a recent report
Cloud moves are easy to underestimate. Storage permissions, keys and network rules often change quietly during migration.
Layer 3: how fast your own systems change
If no rule applies to you, let your release speed decide.
Ship every week or two?
A yearly test covers one version out of dozens. Continuous pentesting, where testing follows your releases, fits better.
Ship monthly or quarterly?
Twice a year, timed after your biggest releases, is a sensible rhythm.
Mostly stable internal systems?
Once a year, plus a test after any major change, is usually enough.
Whatever the frequency, the retest matters as much as the test. SecurityLit's VAPT methodology ends with risk-based ranking, remediation timelines and retest validation planning, so each cycle closes the loop.
Stacked rules: one calendar instead of four
Many Indian fintechs answer to more than one rule. Running separate tests for each one wastes money and team time. Here is an example of merging them.
Example: a payments company that is an RBI payment aggregator, a PCI DSS service provider and also shares SOC 2 reports with enterprise customers.
Internal and external network, web apps, APIs, mobile apps and segmentation test
Fix and retest to close findings and validate fixes
Annual system and cyber security audit by a CERT-In empanelled auditor
Second VAPT cycle and second segmentation test
Fix and retest
Extra testing after major releases or infrastructure changes
Two VAPT cycles a year cover the RBI bi-annual VAPT reports and the PCI DSS six-monthly segmentation tests. The April cycle also covers the yearly PCI pentest. Either cycle gives the SOC 2 auditor a recent, independent report. The empanelled system audit stays a separate engagement, because RBI requires that specific type of auditor.
If no one in your team owns this calendar, that is often the real gap. A virtual CISO can own the testing plan, track findings and keep evidence ready for auditors.
Signs you are testing too rarely
Even with a yearly test on the books, these signs say your rhythm is too slow:
Your last report describes features or servers that no longer exist
Findings from the last test are still open when the next one is due
A customer security questionnaire asks for a report from the last six months, and yours is older
New APIs or apps went live without anyone testing them
Your developers learn about security issues from customers, not from testers
If two or more of these sound familiar, add a mid-year cycle or move part of your testing to a continuous model.
How to budget for the right frequency
Frequency is the biggest lever on your yearly security testing spend. Before you lock a budget:
List every rule that applies, and the strictest frequency among them
Count expected major releases and infrastructure changes for the year
Decide which tests can be combined into one cycle
Keep one slot free for an unplanned test after an incident or big change
You can get an instant estimate for each cycle with SecurityLit's pricing calculator. If you are unsure which rules apply to you, a compliance pre-assessment can map them first.
Frequently Asked Questions
Is a yearly penetration test enough?
For many companies with stable systems and no stricter rule, yes, as long as you also test after major changes. Regulated NBFCs, payment aggregators, some SEBI entities and PCI DSS service providers need some testing every six months.
How often must NBFCs do VAPT under RBI's 2026 Directions?
Middle, Upper and Top Layer NBFCs need a vulnerability assessment at least every six months and a penetration test at least every twelve months on critical and customer-facing systems, plus testing before go-live, after go-live and after changes.
How often does PCI DSS require penetration testing?
At least once every 12 months for internal and external testing, and after any significant infrastructure or application change. Service providers must also test segmentation at least every six months.
How quickly must SEBI-regulated entities close VAPT findings?
SEBI's clarification on CSCRF sets closure of vulnerabilities found during VAPT within three months of the VAPT report. Check the latest SEBI circulars for your category.
Does CERT-In require every company to do yearly penetration testing?
No. The 2022 CERT-In Directions focus on reporting cyber incidents within six hours and keeping logs. Pentest frequency comes from your sector regulator, standards such as PCI DSS, customer contracts and your own risk.
How often should an early-stage Indian startup do a pentest?
Before your first big launch or enterprise customer, then at least once a year and after major releases. If you sell to banks, NBFCs or large enterprises, expect them to ask for a report from the last 6 to 12 months.
This article is general information, not legal advice.
Planning next year's testing calendar?
Book a free scoping call with SecurityLit and build one plan that covers every rule you answer to.
Related Articles
Most Indian companies should run a penetration test at least once a year and again after any major change to their systems. Some regulated businesses must test more often. Middle Layer and larger NBFCs need a vulnerability assessment every six months, and some SEBI-regulated entities, such as market infrastructure institutions and qualified stock brokers, need VAPT every half-year.
Your real answer comes from three layers: the minimum your rules set, the changes that should trigger an extra test, and how fast your own systems change.
Layer 1: the minimum your rules set
Here is what each common rule asks for. Find every row that applies to you. Your floor is the strictest one.
| Rule | Who it covers | Minimum frequency |
|---|---|---|
| RBI NBFC Directions 2026 (Chapter V) | Middle, Upper and Top Layer NBFCs | VA every 6 months, PT every 12 months on critical and customer-facing systems |
| RBI NBFC Directions 2026 (Chapter IV) | Base Layer NBFCs, assets ₹500 crore and above | No fixed calendar; a vulnerability management process and yearly IS audit |
| RBI Payment Aggregator Directions 2025 | Payment aggregators | Bi-annual VAPT reports to the IT Committee; annual system audit |
| SEBI CSCRF | MIIs and qualified stock brokers | VAPT every half-year |
| SEBI CSCRF | Other SEBI-regulated entities | At least yearly; some categories more often, so check your tier |
| PCI DSS v4.0.1 | Businesses that handle card data | Internal and external pentest every 12 months; service providers test segmentation every 6 months |
| SOC 2 | SaaS companies with SOC 2 reports | No fixed frequency; auditors usually expect a recent independent test |
| ISO 27001 | Certified organisations | No fixed pentest frequency; testing supports vulnerability management and secure development controls |
Two notes before you plan. First, almost every rule also asks for testing after significant changes, not only on a calendar. Second, the rules differ on who may test. SEBI CSCRF VAPT and RBI's payment aggregator system audit need CERT-In empanelled auditors, while RBI's NBFC Directions and PCI DSS ask for qualified, independent testers.
A common myth worth clearing up: the 2022 CERT-In Directions are about reporting incidents within six hours and keeping logs. They do not set a pentest frequency for every Indian company.
Layer 2: the changes that should trigger a test
A calendar test checks your systems on one day. Attackers look at them every day. These events should start a test even if your yearly one is months away:
A new product, app or customer portal goes live
A major release that changes login, payments, roles or data access
A move to a new cloud account, region or provider
A new third-party integration, such as a KYC, payment or AI provider
A change to network segmentation or firewall design
After a security incident, to confirm the hole is closed
Before a big enterprise deal or funding round, when buyers ask for a recent report
Cloud moves are easy to underestimate. Storage permissions, keys and network rules often change quietly during migration.
Layer 3: how fast your own systems change
If no rule applies to you, let your release speed decide.
Ship every week or two?
A yearly test covers one version out of dozens. Continuous pentesting, where testing follows your releases, fits better.
Ship monthly or quarterly?
Twice a year, timed after your biggest releases, is a sensible rhythm.
Mostly stable internal systems?
Once a year, plus a test after any major change, is usually enough.
Whatever the frequency, the retest matters as much as the test. SecurityLit's VAPT methodology ends with risk-based ranking, remediation timelines and retest validation planning, so each cycle closes the loop.
Stacked rules: one calendar instead of four
Many Indian fintechs answer to more than one rule. Running separate tests for each one wastes money and team time. Here is an example of merging them.
Example: a payments company that is an RBI payment aggregator, a PCI DSS service provider and also shares SOC 2 reports with enterprise customers.
Internal and external network, web apps, APIs, mobile apps and segmentation test
Fix and retest to close findings and validate fixes
Annual system and cyber security audit by a CERT-In empanelled auditor
Second VAPT cycle and second segmentation test
Fix and retest
Extra testing after major releases or infrastructure changes
Two VAPT cycles a year cover the RBI bi-annual VAPT reports and the PCI DSS six-monthly segmentation tests. The April cycle also covers the yearly PCI pentest. Either cycle gives the SOC 2 auditor a recent, independent report. The empanelled system audit stays a separate engagement, because RBI requires that specific type of auditor.
If no one in your team owns this calendar, that is often the real gap. A virtual CISO can own the testing plan, track findings and keep evidence ready for auditors.
Signs you are testing too rarely
Even with a yearly test on the books, these signs say your rhythm is too slow:
Your last report describes features or servers that no longer exist
Findings from the last test are still open when the next one is due
A customer security questionnaire asks for a report from the last six months, and yours is older
New APIs or apps went live without anyone testing them
Your developers learn about security issues from customers, not from testers
If two or more of these sound familiar, add a mid-year cycle or move part of your testing to a continuous model.
How to budget for the right frequency
Frequency is the biggest lever on your yearly security testing spend. Before you lock a budget:
List every rule that applies, and the strictest frequency among them
Count expected major releases and infrastructure changes for the year
Decide which tests can be combined into one cycle
Keep one slot free for an unplanned test after an incident or big change
You can get an instant estimate for each cycle with SecurityLit's pricing calculator. If you are unsure which rules apply to you, a compliance pre-assessment can map them first.
Frequently Asked Questions
Is a yearly penetration test enough?
For many companies with stable systems and no stricter rule, yes, as long as you also test after major changes. Regulated NBFCs, payment aggregators, some SEBI entities and PCI DSS service providers need some testing every six months.
How often must NBFCs do VAPT under RBI's 2026 Directions?
Middle, Upper and Top Layer NBFCs need a vulnerability assessment at least every six months and a penetration test at least every twelve months on critical and customer-facing systems, plus testing before go-live, after go-live and after changes.
How often does PCI DSS require penetration testing?
At least once every 12 months for internal and external testing, and after any significant infrastructure or application change. Service providers must also test segmentation at least every six months.
How quickly must SEBI-regulated entities close VAPT findings?
SEBI's clarification on CSCRF sets closure of vulnerabilities found during VAPT within three months of the VAPT report. Check the latest SEBI circulars for your category.
Does CERT-In require every company to do yearly penetration testing?
No. The 2022 CERT-In Directions focus on reporting cyber incidents within six hours and keeping logs. Pentest frequency comes from your sector regulator, standards such as PCI DSS, customer contracts and your own risk.
How often should an early-stage Indian startup do a pentest?
Before your first big launch or enterprise customer, then at least once a year and after major releases. If you sell to banks, NBFCs or large enterprises, expect them to ask for a report from the last 6 to 12 months.
This article is general information, not legal advice.
Planning next year's testing calendar?
Book a free scoping call with SecurityLit and build one plan that covers every rule you answer to.