How Does Patch Management Actually Work?
Key takeaways
- An accurate asset inventory is the precondition for everything else, and most Indian businesses cannot currently list every version of every system they run.
- Prioritising by exploitability and internet exposure beats prioritising by severity score, because a high severity flaw behind a firewall is not worth an emergency change window.
- A written service level target per severity band is what turns patching from a personal habit into an auditable control.
- Patch verification matters as much as deployment, because a failed update that reported success is common and leaves the system exposed.
- CERT-In's 180-day log retention and the evidence expectations of an ISO 27001 audit both assume you keep a dated record of what was patched and when.
As of 24 October 2026: the service descriptions, prices and turnaround figures on this page are current.
What does a workable patch process look like end to end?
Six stages, in this order. Inventory: know what you run, what version, and who owns it. Prioritise: decide the risk order using internet exposure, business criticality and whether the flaw is exploited in the wild. Test: apply the update to a representative machine first, because a patch that breaks your business application is worse than a late one. Deploy: roll out in waves, least critical first, so a bad update hits a small group. Verify: confirm the version changed and the service still works, because silent failures are common. Record: keep the date, systems, outcome and approver, since that record is what an auditor will ask for.
How do I prioritise when I cannot patch everything at once?
Use exposure first and severity second. Anything reachable from the internet sits at the top, because mass exploitation finds it automatically. Next comes anything running on a system that handles money, customer records or health data, since a breach there carries regulatory and notification obligations. Then anything with a known working exploit against your specific product. Then everything else, on a monthly cycle. When the backlog exceeds capacity, the honest fix is to reduce exposure: take the old system off the internet, put it behind a proxy, or segment it, and record the decision as a compensating control with an expiry date rather than leaving it unpatched forever.
How do I prove the patching is actually happening?
Keep three artefacts and make them retrievable in minutes. A dated patch report from the deployment tool, listing systems and outcomes, including failures. A baseline configuration record, so you can show what a system looked like before and after. And an exception register, listing every system that is deliberately not patched, with the reason, the compensating control and the review date. That register is the document that makes an audit conversation short, because it shows you made a considered decision rather than missed the work. Without it, a missing patch looks like negligence rather than a risk decision.
| Band | Applies to | Target | Escalation |
|---|---|---|---|
| Critical, exploited | Internet-facing or business-critical systems | Patch within 72 hours | Emergency change approval, daily tracking |
| Critical | All other systems with critical severity | Within 14 days | Weekly tracking, owner sign-off |
| High | General systems and servers | Within 30 days | Monthly review |
| Medium | Internal tools and clients | Within 60 days | Monthly review |
| Low | Non-critical, non-exposed systems | Within 90 days or at next release | Quarterly review |
| Exception | Any system that cannot be patched | Compensating control recorded | Expiry date, quarterly re-approval |
What are the frequently asked questions?
Get a straight answer on this
Give us an export of your current systems and versions, and we will return a ranked patch backlog with the service level target for each item.
Send us the details See pricing