A Patch Management Process That Holds Up

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:

1. Scope: which systems and applications are included.
2. Roles: who monitors, who approves, who deploys and who verifies.
3. Timelines by severity.
4. Maintenance windows and change approval steps.
5. Exception handling: how a system can be excluded, for how long and with whose approval.
6. 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.

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.

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.