Patch Management Policy: Building a 15-Day Cycle That Satisfies CERT-In

What CERT-In Actually Requires

CERT-In Directions 2022 requires organisations to implement a vulnerability management programme with defined timelines for critical patch deployment. The RBI Cybersecurity Framework for banks mandates that critical patches be applied within 30 days. ISO/IEC 27001:2022 Annex A.8.8 requires management of technical vulnerabilities. All three frameworks require a documented policy, not ad hoc patching.

The 5-Stage Patch Management Process

1. Identify: Automated vulnerability scanning (weekly minimum) using tools like Tenable Nessus or Qualys. Subscribe to vendor advisories and NIST NVD alerts.
2. Assess: Prioritise using CVSS score, asset criticality, and exploitability. A critical vulnerability on a DMZ-facing server is not the same risk as on an isolated dev machine.
3. Test: Deploy patches to non-production environments first. Document test results. Define rollback procedures before deploying to production.
4. Deploy: Use change management approval for production patching. Maintain deployment records with timestamps, systems patched, and operator identity.
5. Verify: Re-scan patched systems to confirm successful remediation. Close the vulnerability ticket only after verification scan shows clear.

What Auditors Look For as Evidence

Auditors will not accept "we patch regularly" as evidence. They expect: a written Patch Management Policy (version-controlled, board-approved), vulnerability scan reports showing before/after state, deployment logs with timestamps, exception registers for patches that cannot be applied, and an escalation path for zero-day events. Without documentation, even excellent patching practices fail the audit.