Section 26 of the RBI 2023 IT governance direction says critical information systems, and those in the DMZ with a customer interface, need vulnerability assessment at least every six months and penetration testing at least every 12 months. They are also tested across the lifecycle. Non critical systems follow a risk based approach.
The rules in section 26
- Frequency for critical and customer facing DMZ systems: VA at least once every six months, PT at least once in 12 months.
- Lifecycle: VA and PT before go live, after go live and after major changes.
- Non critical systems: risk based decision on need and periodicity.
- Testers: appropriately trained and independent information security experts or auditors.
- Environment: after implementation, PT on the production environment. If a test environment is unavoidable, it must resemble production and any deviation is documented and approved by the Information Security Committee.
- Fixing: identified vulnerabilities and risks must be fixed in a time bound way, with compliance sustained so known vulnerabilities such as those in the CVE database do not recur.
- Method: a documented approach covering scope, coverage and the scoring mechanism, with CVSS given as an example. It may also apply to cloud hosted systems.
Patch management in section 13
Regulated entities need documented policies that assess the business impact of applying or not applying a patch, apply patches in a secure and timely manner with approvals, and have a way to recover from failed deployments.
What this means for a vendor team
Your customer will ask for your latest test reports, how you track fixes, and how quickly you patch. Prepare:
- A calendar that shows the six month and 12 month cadence for your own critical systems.
- A record of who tested, with their independence.
- A fix log that links each finding to a ticket and closure date.
- A written scoring approach, such as CVSS plus exploitability.
- A rule that a major change triggers a new test.
Between the tests
A point in time test goes stale quickly. The direction's wording on sustaining compliance so known CVEs do not recur points to continuous checks between tests. Dependency scanning on every build and a gate that blocks known vulnerable components are cheap ways to do that.
Try it yourself
In the demo, see how a pull request gate responds to a vulnerable component. Notice what evidence the gate leaves behind.
Click through it at your own pace, or open it full screen.
Safeguard offers SBOM and dependency scanning, reachability analysis and policy gates for this. It is not a penetration test, and independent testers are still needed.
Quick check
Can a scanner replace the annual penetration test?
Section 26 asks for testing by trained and independent information security experts. Treat scanning as a complement.
Do all systems need a six month VA?
No. That cadence is for critical systems and DMZ systems with a customer interface. Others use a risk based approach.
Sources
Last reviewed: 19 October 2026.
