Patch Management Under CERT-In and RBI Guidelines: What Indian Enterprises Need to Know

If your company has a subsidiary, a development center, or a managed-services vendor in India, Indian cybersecurity regulation is already part of your risk profile. It also affects any US firm that touches Indian financial institutions or handles data inside India.

Two regulators matter most: CERT-In, the national incident response agency, and the Reserve Bank of India (RBI), which governs banks, NBFCs, and payment players. Neither treats patching as optional housekeeping. Both expect unpatched systems to be defensible only with evidence, and both expect speed.

This post breaks down what each regulator expects and how US IT managers can build a patching program that holds up in both jurisdictions.

Why patching is a regulatory issue, not just an IT task

Most major breaches trace back to a known vulnerability with an available fix. Attackers weaponize new CVEs within days, and the gap between disclosure and exploitation keeps shrinking. Indian regulators have responded by moving patching out of the "best practice" bucket and into audit scope.

For US teams, the useful framing is this: India's rules resemble what you already face under SEC disclosure requirements, state breach laws, and frameworks like NIST CSF. The difference is that Indian rules add hard clocks and prescriptive evidence expectations.

What CERT-In requires

The 2022 Directions. CERT-In issued its Directions on 28 April 2022, effective late June 2022, under Section 70B(6) of the IT Act. They apply to service providers, intermediaries, data centers, body corporates, and government organizations. Two requirements shape patch operations directly:

• Six-hour incident reporting. Covered entities must report listed cyber incidents within six hours of noticing them. That window assumes you can detect an event fast and know exactly which systems are affected and how they are configured. Without an accurate patch inventory, you cannot answer "were we exposed?" in time.
• 180-day log retention. Logs from all ICT systems must be kept securely for a rolling 180 days and handed over on request. CERT-In's own FAQs list firewall logs and intrusion prevention system logs among the examples, which makes your detection stack part of your compliance story.

The 2025 audit guidelines. In July 2025, CERT-In published its Comprehensive Cyber Security Audit Policy Guidelines. They set a structured framework for audits, expect a comprehensive audit of ICT systems at least annually, and call out proper patch management as part of the auditee's responsibility. Audits now lean on evidence such as scan results, patch records, and logs rather than policy documents alone.

Takeaway: you need to show that patches were identified, prioritized, deployed, and verified, with timestamps.

What RBI expects

RBI-regulated entities face a more detailed regime. The RBI's Cyber Security Framework for banks (2016) and its Master Direction on IT Governance, Risk, Controls and Assurance Practices (effective April 2024) require regulated entities to run structured vulnerability and patch management, tied to board-level governance and independent assurance. Its outsourcing-of-IT-services direction also makes the regulated entity accountable for its vendors' security.

That last point is where US companies get pulled in. If you serve an Indian bank, NBFC, or fintech as a vendor, your patching discipline becomes part of their compliance posture. Expect questionnaires, audit rights, and contractual SLAs on remediation timelines.

Confirm current circular details with your compliance counsel, since RBI updates its directions regularly.

Where enterprises struggle

1. Asset blind spots. Shadow IT, forgotten servers, and unmanaged endpoints never get patched because nobody knows they exist.
2. Manual cycles. Monthly patch windows can't keep up with exploitation measured in days.
3. Weak evidence. Teams patch, but can't prove it. Auditors and regulators treat undocumented work as undone.
4. Siloed tooling. Patching, detection, and response run in separate consoles, so correlating an exposed system with an active threat takes hours you don't have.

How automated patch management closes the gap

Automated patch management solutions address each of these problems directly:

• Continuous discovery and inventory so every server, endpoint, and cloud workload is accounted for.
• Risk-based prioritization that ranks fixes by exploitability and asset criticality instead of raw CVSS score.
• Policy-driven deployment with testing rings, maintenance windows, and automatic rollback for critical systems.
• Audit-ready reporting that records what was patched, when, and by whom, producing the evidence both CERT-In and RBI-style audits ask for.

Automation also reduces human error and frees your team for the work that needs judgment.

Patching is one layer: connect it to detection and prevention

Regulators care about outcomes: can you prevent, detect, and report? Patching works best alongside three other capabilities.

Network threat detection. Even a perfect patch program has a window between disclosure and remediation. Network threat detection watches east-west and outbound traffic for exploitation attempts during that window, and gives you the data needed to meet a six-hour reporting clock.

AI cybersecurity. Machine learning models can correlate vulnerability data, asset context, and live threat signals to flag which unpatched systems are actually being targeted. That turns a 10,000-item backlog into a short, ranked list. AI-assisted triage also shortens the time between "something looks wrong" and "we know what's affected."

Intrusion prevention. Intrusion prevention systems (IPS) can virtually patch known vulnerabilities by blocking exploit traffic at the network layer, buying time for systems that can't be updated immediately, such as legacy or operational technology assets. IPS logs also feed the retention requirement CERT-In emphasizes.

Together, these layers give you defense in depth and a documented trail.

A practical checklist for US teams with Indian exposure

1. Map your footprint. List every Indian entity, vendor, and data flow that touches regulated data or Indian financial institutions.
2. Build a single asset inventory covering on-premises, cloud, and endpoints, including third-party-managed systems.
3. Set remediation SLAs by severity (for example, critical and actively exploited vulnerabilities within days, not weeks) and make them measurable.
4. Automate deployment and verification, with exception handling that records compensating controls like virtual patching.
5. Centralize logs and test that you can retrieve 180 days of data quickly, in a form an investigator can use.
6. Rehearse the six-hour drill. Run a tabletop where the clock starts at detection and see whether you can identify affected systems and file a report in time.
7. Prepare vendor evidence. Keep patch reports, scan results, and audit summaries ready for Indian clients and regulators.
8. Review annually, aligned with CERT-In's annual audit expectation, and recheck RBI circulars for changes.

The bottom line

CERT-In and RBI have made the standard clear: know your assets, fix known vulnerabilities fast, detect what slips through, and prove all of it. US enterprises with Indian operations or Indian-regulated customers can't treat patching as a back-office routine anymore.

The good news is that a single, well-run program built on automation, continuous detection, and strong evidence satisfies Indian expectations and strengthens your posture against US regulators and attackers alike.