IT Operations
A Patch Management Process That Holds Up
Affix Center · · 6 min read
Quick answer: A patch management process is a repeatable cycle for finding, testing and installing software updates: keep an inventory, watch for updates, assess and prioritise, test, deploy, then verify and report. It should cover operating systems, business applications, web applications and network devices, with agreed timelines for each severity level.
Almost every serious security incident has a familiar root cause: a known weakness that already had a fix, but the fix was never applied. A clear patch management process closes that gap. It decides which updates go where, how fast, who approves them and how you prove they were installed.
In many Indian offices, patching is still informal. One IT person clicks "update" when there is time, servers are left alone because "nobody wants downtime", and branch laptops in Thane or Nashik go months without a check. The result is an estate where nobody can say with confidence what is patched and what is not. This guide sets out a process that holds up under audit and under pressure.
Why an Ad Hoc Approach Fails
Patching looks simple until you try to do it across 200 devices, three office locations and a mix of Windows, Linux, network equipment and business applications. Common problems include:
- No complete inventory. You cannot patch devices you do not know exist.
- Fear of breaking things. A bad update once took down the billing server, so now nobody patches it at all.
- Third-party software is ignored. Operating systems get updates, but browsers, PDF readers, Java and VPN clients are left behind.
- No evidence. When an auditor or customer asks for proof, there is no report to show.
The Six Stages of a Patch Management Process
A workable process runs as a repeating cycle. Each stage has a clear owner and output.
1. Inventory
Maintain an up-to-date list of every endpoint, server, network device and application, with its version and owner. Pull this from your endpoint management tool, not a spreadsheet that goes stale.
2. Monitor for updates and advisories
Track vendor release cycles, such as Microsoft's monthly Patch Tuesday on the second Tuesday of each month, and security advisories published by CERT-In and by the vendors you depend on. Assign one person to review these every week.
3. Assess and prioritise
Not every patch is urgent. Rank each one by the severity of the flaw, whether it is being actively exploited, and how exposed the affected system is. An internet-facing firewall or VPN gateway always comes before an internal print server.
4. Test
Apply patches first to a small test group that mirrors your production systems. For critical business applications, confirm that key workflows such as billing, payroll and ERP posting still work.
5. Deploy
Roll out in waves: pilot users, then general users, then critical servers inside an agreed maintenance window. Keep a rollback plan ready, including backups or snapshots taken just before the change.
6. Verify and report
Confirm installation through your tooling, chase failures, and produce a monthly compliance report showing patch coverage by system group.
Setting Timelines That People Follow
A policy without deadlines is a wish list. Define target timelines by risk level and get management to sign off on them. A typical starting point looks like this:
- Critical and actively exploited: emergency change, applied within days.
- High severity: within the next regular cycle, usually two weeks.
- Medium and low severity: within the monthly cycle.
- Feature updates: scheduled after testing, often quarterly.
Adjust these to your own risk appetite and any sector rules you follow. Banks, NBFCs and other regulated entities often face stricter expectations from their regulators, so check your applicable guidelines.
Handling Servers, Network Devices and Legacy Systems
Endpoints are the easy part. The harder cases need their own rules:
- Servers: agree fixed monthly maintenance windows with business owners in advance, so patching is not negotiated every time.
- Firewalls, switches and Wi-Fi controllers: firmware updates are often forgotten. Put them on a quarterly review, and treat security advisories for perimeter devices as urgent.
- Legacy and unsupported systems: some machines run software that cannot be updated, such as an old lab instrument PC. Isolate them on a separate network segment, restrict access and document the risk. Plan for operating system end of support: for example, Microsoft has announced that Windows 10 support ends on 14 October 2025, so any remaining Windows 10 machines need an upgrade or replacement plan.
- Cloud workloads: patch virtual machines like on-premise servers, and use managed services where the provider handles the underlying updates.
Patching is one part of wider security hygiene. It works best alongside access control, backups and monitoring, which our cybersecurity services cover in more depth.
Tools, Automation and Documentation
Choosing tools
Manual patching does not scale beyond a handful of machines. Look for tooling that can:
- Discover devices automatically and keep the inventory current.
- Patch both the operating system and common third-party applications.
- Deploy in groups with scheduled windows and automatic reboots outside working hours.
- Report compliance by device, group and location.
- Handle remote laptops that rarely connect to the office network.
The right tool depends on your mix of operating systems, number of devices and whether you already use a Microsoft 365 or other endpoint management platform. Many organisations fold patching into a managed service, as part of their wider IT operations and support arrangement.
Writing the policy
Write the process down in a short policy, two or three pages, and review it once a year. It should cover:
- Scope: which systems and applications are included.
- Roles: who monitors, who approves, who deploys and who verifies.
- Timelines by severity.
- Maintenance windows and change approval steps.
- Exception handling: how a system can be excluded, for how long and with whose approval.
- Reporting: what is reported monthly and to whom.
Good records also help when customers send security questionnaires or when you prepare for frameworks such as ISO 27001.
Measuring Whether the Patch Management Process Works
A process only holds up if you measure it. Track a small set of numbers every month and share them with management:
- Patch coverage: the percentage of devices fully up to date, broken down by servers, laptops and network devices.
- Time to patch: the average number of days between a critical patch being released and being installed across your estate.
- Failed installs: how many devices failed an update and how quickly they were fixed.
- Open exceptions: systems excluded from patching, with their owner and review date.
- Unknown devices: machines found on the network that were missing from the inventory.
Trends matter more than any single month. If coverage slips at one branch or time to patch keeps rising, that points to a staffing, tooling or connectivity problem you can fix before it turns into an incident.
What a Patch Management Process Document Should Contain
Auditors and clients often ask for the process in writing. A short document of two or three pages is enough if it covers these sections:
- Scope: which systems are covered, including servers, PCs, network devices, cloud workloads and web applications.
- Roles: who approves, who deploys and who verifies.
- Sources: where the team gets update and advisory information.
- Priority levels and timelines: how fast each severity must be patched.
- Testing: what is tested, on which pilot group, and for how long.
- Maintenance windows: when patching may happen and how users are informed.
- Rollback: how to undo a patch that breaks something.
- Exceptions: how unpatched systems are recorded, approved and protected.
- Reporting: what is measured and who sees it.
Patching by System Type
| System type | What needs patching | Main risk if missed | Practical approach |
|---|---|---|---|
| PCs and laptops | Operating system, browsers, office software | Malware through email and web | Automatic deployment with a pilot group first |
| Servers | Operating system, databases, middleware | Service outage or data breach | Test first, patch in a maintenance window, keep a rollback plan |
| Web applications | CMS core, plugins, frameworks, libraries | Website defacement or data theft | Staging copy, update, test key pages, then go live |
| Network devices | Firewall, switch, router and Wi-Fi firmware | Attack from the internet edge | Scheduled updates with a configuration backup |
| Legacy systems | Often no patches available | Known flaws stay open | Isolate on the network and plan replacement |
Web applications are missed most often, because the server team assumes the developer handles them and the developer assumes the opposite. Name an owner for each application and include it in the same monthly cycle.
Related reading: endpoint security for small business, IT asset management best practices, Windows 10 ESU deadline, what a good VAPT covers.
Frequently Asked Questions
What is a patch management process?
It is a repeatable cycle to find, assess, test, deploy and verify software updates across all your systems, with set timelines and records.
How often should we patch?
Run a regular monthly cycle for most updates, and use an emergency process for critical flaws that are being actively exploited.
Should we install patches automatically?
Automatic updates suit most user laptops and desktops. For servers and business-critical systems, test first and deploy in a planned window.
What do we do with systems that cannot be patched?
Isolate them on the network, limit who can access them, monitor them closely and plan their replacement.
What is the difference between patch management and vulnerability management?
Vulnerability management finds and ranks weaknesses across your systems. Patch management fixes those that have a software update. Some weaknesses need a configuration change instead, so the two processes work together.
Who should own the patch management process?
IT operations usually runs it, with security setting priorities and business owners approving maintenance windows. One named person should be accountable for the monthly report.
How Affix Center Can Help
Affix Center helps organisations in Mumbai and across Maharashtra set up patch management that runs every month without heroics. Our team can build your asset inventory, configure patching tools, agree maintenance windows with your business teams and provide monthly compliance reports.
To review your current patching gaps, contact our IT operations team.