How Often Should You Do Penetration Testing? What RBI, SEBI, IRDAI, PCI DSS, ISO 27001 and SOC 2 Actually Require
How often you should do penetration testing depends on which regulator or standard you answer to, and on how fast your systems change. What PCI DSS, RBI, SEBI, IRDAI, ISO 27001 and SOC 2 actually require, what counts as a significant change, and how to build a testing calendar that satisfies all of them at once.
Regulatory Compliance
"Once a year" is the answer most people have heard, and it is the right answer to the wrong question. Regulators and standards do not agree on a single interval, several of them distinguish between vulnerability assessment and penetration testing, and all of the serious ones add a second trigger that matters more than the calendar: significant change. Here is what PCI DSS, RBI, SEBI, IRDAI, ISO 27001 and SOC 2 actually require, quoted from the current texts, and how to turn them into one testing schedule that satisfies every regulator you answer to.
In short. PCI DSS requires penetration testing at least every 12 months and after any significant change, with vulnerability scans every three months. RBI requires vulnerability assessment every six months and penetration testing every twelve for critical and customer-facing systems at banks and larger NBFCs, plus testing through the system lifecycle. SEBI requires annual VAPT for most regulated entities, half-yearly for the most critical, with closure deadlines. IRDAI requires six-monthly assessment and penetration testing of internet-facing systems and annual testing of critical internal ones. ISO 27001 and SOC 2 set no interval; they expect a documented, risk-based process with evidence. The common thread is that annual is the floor, change is the trigger, and the regulator will ask for the closure evidence, not only the report.
First, two distinctions the regulators make
Vulnerability assessment is not penetration testing. An assessment is largely automated scanning that lists known weaknesses; a penetration test is a person trying to exploit and chain them. Most Indian regulators set a shorter interval for the first and a longer one for the second, and auditors notice when a scan report is presented as a penetration test. Our guide to vulnerability assessment versus management covers the difference in detail.
The calendar is only half the rule. Nearly every text pairs the interval with a change trigger: "after any significant infrastructure or application upgrade or change" in PCI DSS, "throughout their lifecycle (pre-implementation, post implementation, and after changes)" in RBI's directions, "mandatory security testing shall be conducted for all changes to internet facing information assets" in IRDAI's. A system tested in January and rebuilt in March is, for compliance purposes, untested.
PCI DSS v4.0.1
The payment card standard is the most prescriptive, and it is the one most other frameworks borrow from.
| Requirement | What | How often |
|---|---|---|
| 11.3.1 | Internal vulnerability scans, with high-risk and critical findings resolved and rescanned | "At least once every three months" |
| 11.3.2 | External vulnerability scans by a PCI SSC Approved Scanning Vendor | At least once every three months |
| 11.4.1 | A defined, documented and implemented penetration testing methodology covering the whole cardholder data environment perimeter and critical systems, from inside and outside, at application and network layers | Standing requirement |
| 11.4.2 and 11.4.3 | Internal and external penetration testing, by a qualified internal resource or external third party with organisational independence; the tester is not required to be a QSA or ASV | "At least once every 12 months" and "after any significant infrastructure or application upgrade or change" |
| 11.4.4 | Exploitable vulnerabilities corrected and "penetration testing is repeated to verify the corrections" | After each test |
| 11.4.5 | Segmentation testing, where segmentation isolates the cardholder data environment | At least once every 12 months and after any changes to segmentation controls |
| 11.4.6 | Segmentation testing, service providers only | "At least once every six months and after any changes to segmentation controls/methods" |
| 11.4.7 | Multi-tenant service providers support their customers' external penetration testing | Standing requirement |
Two details trip people up. The retest in 11.4.4 is part of the requirement, so a test with open critical findings and no retest does not satisfy it. And the 12 months run from the last test, not from the financial year. For the page-script requirements that arrived with version 4, see our guide to PCI DSS 6.4.3 and 11.6.1.
RBI: banks and NBFCs
RBI's 2026 cybersecurity directions for commercial banks (RBI/DoS/2026-27/410, 31 July 2026) and for NBFCs (RBI/DoS/2026-27/461, same date) use the same cadence, which they inherited from the November 2023 Master Direction on IT Governance.
- Scope. The bank "shall conduct VA and PT exercises periodically for all the critical and internet facing systems", and for critical internet-facing web and mobile applications, servers and network components "throughout their lifecycle (pre-implementation, post implementation, and after changes)".
- Frequency. For critical systems and systems in the demilitarised zone with a customer interface, "VA shall be conducted at least once in every six months and PT at least once in 12 months". Non-critical systems are tested on a risk basis. The NBFC directions carry the identical clause for the middle layer and above; base layer NBFCs have a vulnerability management requirement without a fixed interval.
- Where. Post-implementation testing in the production environment, with any deviation to a test environment approved by the information security committee, and the documented approach applies equally to cloud-hosted systems.
- Who. "Appropriately trained and independent information security experts / auditors". The directions do not require CERT-In empanelled auditors; where a bank uses one, it follows CERT-In's audit policy.
- Follow-through. Findings fixed "in a time-bound manner", with closure status reported to the IT strategy and information security committees "at least on a quarterly basis". Red teaming is optional for banks: "the bank may conduct red teaming exercises". DR drills are half-yearly.
The October 2026 update to the bank directions changed only a governance footnote about policy review; the testing clauses are as issued. Our articles on the 2026 directions and the NBFC directions by layer go clause by clause.
Payment companies are stricter. RBI's 2025 Master Direction for payment aggregators requires "an annual system audit, including cyber security audit, conducted by CERT-In empanelled auditors", with bi-annual VAPT reports to the IT committee. The directions for non-bank payment system operators issued on 5 November 2026 require application testing including vulnerability assessment and penetration testing "at adequate frequency (at least on annual basis)", with audits by CERT-In empanelled auditors or certified information systems auditors.
SEBI CSCRF
The Cybersecurity and Cyber Resilience Framework of August 2024 ties testing to the financial year and adds deadlines for what happens after the report.
| Step | Requirement |
|---|---|
| Frequency | Annual VAPT for regulated entities generally, commencing in the first quarter of the financial year; half-yearly for market infrastructure institutions, qualified stock brokers and entities whose systems are notified as protected systems by NCIIPC |
| After change | VAPT after every major release, including new systems and core software version changes |
| Report | Within one month of completing the VAPT, with a declaration by the managing director or chief executive |
| Closure | Findings closed within three months of the report; revalidation within five months of completion; anything still open after three months needs IT committee approval and closure before the next cycle |
| Who | External audits, including the cyber audit, by CERT-In empanelled information security auditing organisations for entities other than those on self-certification |
| Scope | The VAPT scope explicitly includes mobile applications |
In May 2026 SEBI added an advisory asking regulated entities to apply patches "on an immediate basis" and to run "regular vulnerability assessments using conventional and suitable AI-based vulnerability assessment tools", read together with the CSCRF. Our SEBI CSCRF compliance guide covers the framework as a whole.
IRDAI: insurers and intermediaries
IRDAI's Information and Cyber Security Guidelines, version 2.0 of April 2026, apply from the current financial year to insurers, foreign reinsurance branches and intermediaries, and they set the shortest intervals of any Indian regulator for internet-facing systems.
- "VAPT of critical internal applications or infrastructure components to be conducted periodically at least once in a year by a CERT-In empaneled Auditor."
- "VA should be conducted for all internet facing information assets and systems at least once every 6 months by a CERT-In empaneled Auditor. External Grey/White box Penetration Testing (PT) should be conducted for all internet facing information assets and systems once in 6 months by a CERT-In empaneled Auditor."
- "Mandatory security testing shall be conducted for all changes to internet facing information assets or systems and reported gaps should be closed before moving into production", and APIs and web services must have VAPT including secure code review before go-live.
- High-risk gaps closed within 30 days "followed by mandatory re-validation testing"; all gaps within two months.
ISO/IEC 27001:2022 and SOC 2: no interval, but evidence
Neither standard sets a frequency, and both are regularly misquoted as if they did.
ISO 27001. Annex A control 8.8 requires that "information about technical vulnerabilities of information systems in use should be obtained, the organization's exposure to such vulnerabilities should be evaluated and appropriate measures should be taken", and 8.29 requires security testing processes to be defined and implemented in the development life cycle. The interval is yours to set in the risk treatment plan, and the auditor will check that you set one, kept to it and acted on the results. In practice most certified organisations settle on annual penetration testing with more frequent scanning, because it is defensible and because their customers ask for it. Our ISO 27001 implementation guide covers how the risk treatment plan drives this.
SOC 2. The Trust Services Criteria do not mandate penetration testing. The points of focus under CC7.1 describe vulnerability scans "on a periodic basis and after any significant change in the environment", and CC4.1 lists penetration testing among the evaluations management may use. Points of focus are not individually required, but a Type II auditor will expect to see how you identify vulnerabilities over the review period, and a penetration test is the most common evidence. Our SOC 2 versus ISO 27001 guide explains how the two differ.
What the rest of the world says
- NIST SP 800-115, still the reference methodology, says that "because of its high cost and potential impact, penetration testing of an organization's network and systems on an annual basis may be sufficient", interspersed with regular scanning, and notes that "assessment frequency is often driven by an organization's requirements to demonstrate compliance". NIST CSF 2.0 asks that "vulnerabilities in assets are identified, validated, and recorded".
- UK NCSC sets no interval but observes, as a warning rather than a recommendation, that "it's not uncommon for a year or more to elapse between penetration tests". The UK government service manual asks teams to test "regularly, especially during major changes to your codebase" and before a service uses real user data.
- US healthcare. The proposed HIPAA Security Rule changes of January 2025 would require penetration testing at least every 12 months and vulnerability scans every six; as of November 2026 they are not final.
- CERT-In. The 2022 directions set no testing frequency at all; they cover incident reporting, log retention and clock synchronisation.
Who has to do the testing
Independence is the common requirement: PCI DSS asks for organisational independence, RBI for independent experts, ISO for competence and objectivity. Beyond that, some Indian regulators require formal audits by organisations on CERT-In's empanelled list: SEBI for cyber audits of most regulated entities, IRDAI for the testing in its guidelines, and RBI for payment aggregators and payment system operators. RBI's bank and NBFC directions do not. Check the current requirement for your sector and the current CERT-In list before engaging anyone for a regulatory audit; a penetration test done for your own assurance has no such constraint.
One calendar for all of them
Most organisations answer to more than one of these. The way to stay sane is a single schedule built on the strictest requirement that applies to each system, with change triggers written down.
| System class | Vulnerability assessment | Penetration test | Also after |
|---|---|---|---|
| Internet-facing, customer-facing, payment | Monthly scanning; formal assessment every three months (PCI) or six months (RBI, IRDAI) | Annual, or six-monthly where IRDAI or PCI service-provider segmentation rules apply | Every significant change, before go-live |
| Critical internal | Every six months | Annual | Major upgrades, architecture changes |
| Cloud accounts and identity | Continuous posture monitoring; formal review every six months | Annual, with assumed-breach scope | New accounts, federation changes, migrations |
| Mobile applications | With each release, automated | Annual, with the API in scope | Releases that change authentication, the API or SDKs |
| Non-critical internal | Risk-based, at least annually | Risk-based | Reclassification as critical |
Three habits make the calendar work. Define "significant change" in writing, with examples, so nobody has to argue about it during a release. Keep the closure evidence with the report, because every regulator above asks for the retest, the closure dates or the committee approval, not just the findings. And keep the results for at least 12 months, which PCI DSS requires and the others expect.
If you want this built for your estate, our security testing services cover web, API, mobile, network, wireless and cloud testing on the cadence your regulators set, and regulatory compliance work maps the schedule to RBI, SEBI and IRDAI evidence.
Frequently Asked Questions
Click any question to expand the answer.
QHow often should penetration testing be done?
At least annually, and after any significant change, is the floor set by PCI DSS, RBI, SEBI and most other frameworks. Internet-facing systems at insurers and some PCI service providers need six-monthly testing. Vulnerability assessment is usually required more often: every three months under PCI DSS, every six under RBI and IRDAI.
QWhat does PCI DSS require for penetration testing?
Requirements 11.4.2 and 11.4.3 of PCI DSS v4.0.1 require internal and external penetration testing at least once every 12 months and after any significant infrastructure or application upgrade or change, by a qualified and organisationally independent tester. Segmentation testing is required every 12 months, or every six months for service providers. Vulnerability scans are required at least every three months under 11.3.1 and 11.3.2.
QWhat does RBI require for VAPT?
RBI's 2026 directions for commercial banks and for NBFCs in the middle layer and above require vulnerability assessment at least once every six months and penetration testing at least once in 12 months for critical systems and customer-facing systems in the DMZ, plus testing through the lifecycle before and after implementation and after changes, including cloud-hosted systems. Base layer NBFCs have a vulnerability management requirement without a fixed interval.
QHow often does SEBI CSCRF require VAPT?
Annually for most regulated entities, starting in the first quarter of the financial year, and half-yearly for market infrastructure institutions, qualified stock brokers and entities with systems notified as protected systems. VAPT is also required after major releases. Reports are due within one month, findings closed within three months and revalidated within five.
QWhat does IRDAI require?
The 2026 guidelines require VAPT of critical internal applications and infrastructure at least once a year, vulnerability assessment and penetration testing of all internet-facing systems every six months, security testing for all changes to internet-facing systems before production, and closure of high-risk findings within 30 days with revalidation.
QDoes ISO 27001 require penetration testing?
Not explicitly. Annex A control 8.8 requires technical vulnerabilities to be identified, evaluated and addressed, and 8.29 requires security testing in the development life cycle, but the standard sets no interval. The organisation decides the frequency in its risk treatment plan, and the auditor checks that it was set, followed and acted on.
QDoes SOC 2 require penetration testing?
No. The Trust Services Criteria do not mandate it. The points of focus mention vulnerability scans on a periodic basis and after significant changes, and list penetration testing among possible evaluations. In practice a Type II auditor expects evidence of how vulnerabilities are identified over the review period, and a penetration test is the most common evidence.
QWhat counts as a significant change?
The standards leave this to the organisation, which is why it should be defined in writing. Typical examples are new internet-facing systems, major version upgrades, changes to authentication or payment flows, network re-architecture or segmentation changes, cloud migrations and new integrations with third parties.
QWho is allowed to do the testing?
All the frameworks require independence from the people who built and run the system. Some Indian regulators additionally require formal audits by organisations on CERT-In's empanelled list: SEBI for cyber audits of most regulated entities, IRDAI for the testing in its guidelines, and RBI for payment aggregators and payment system operators. RBI's bank and NBFC directions do not.
QIs vulnerability scanning the same as penetration testing?
No. Scanning is largely automated and lists known weaknesses; a penetration test is a person exploiting and chaining them to show impact. Most regulators set a shorter interval for scanning and a longer one for testing, and a scan report presented as a penetration test will not satisfy an auditor.
QHow long should test results be kept?
PCI DSS requires penetration test results and remediation records to be retained for at least 12 months. Other frameworks expect evidence to be available for the audit cycle, which in practice means keeping reports, retests and closure records for at least that long.
QDoes CERT-In set a penetration testing frequency?
No. CERT-In's 2022 directions cover incident reporting within six hours, log retention for 180 days and clock synchronisation; they say nothing about testing intervals.
Related reading
For what the tests themselves involve, see internal network penetration testing, cloud penetration testing and mobile application penetration testing. For choosing between a test and a red team, red team versus penetration testing.
Sources
- PCI Security Standards Council, PCI DSS v4.0.1, Requirement 11 (document library).
- Reserve Bank of India, Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework Directions, 2026.
- Reserve Bank of India, NBFC – Cybersecurity, Technology: Risk, Resilience and Assurance Framework Directions, 2026.
- Reserve Bank of India, Master Direction on IT Governance, Risk, Controls and Assurance Practices (November 2023).
- Reserve Bank of India, Master Direction on Regulation of Payment Aggregators (2025).
- Reserve Bank of India, Non-Bank Payment System Operators cybersecurity directions (November 2026).
- Association of Portfolio Managers in India, SEBI CSCRF presentation: periodicity and timelines.
- IndiaLaw, SEBI advisory on AI-driven vulnerability detection (May 2026).
- IRDAI, Information and Cyber Security Guidelines for Regulated Entities, Version 2.0 (April 2026).
- NIST, SP 800-115: Technical Guide to Information Security Testing and Assessment.
- NIST, Cybersecurity Framework 2.0.
- UK NCSC, Penetration testing guidance.
- GOV.UK, Service Manual: vulnerability and penetration testing.
- Office of Information and Regulatory Affairs, HIPAA Security Rule proposed rule status (RIN 0945-AA22).
- CERT-In, Directions under section 70B(6) of the IT Act, 2000 (28 April 2022).
- CERT-In, Empanelment of information security auditing organisations.
Adayptus Consulting
Offensive Security, Adayptus
Adayptus Consulting Private Limited is a cybersecurity consultancy based in Noida, India, testing applications, networks and cloud environments against the schedules Indian and international regulators set.
On This Page
- First, two distinctions the regulators make
- PCI DSS v4.0.1
- RBI: banks and NBFCs
- SEBI CSCRF
- IRDAI: insurers and intermediaries
- ISO/IEC 27001:2022 and SOC 2: no interval, but evidence
- What the rest of the world says
- Who has to do the testing
- One calendar for all of them
- Frequently Asked Questions
- Related reading
- Sources
