Patch Management: Process, Risks and Best Practices

Patch management is the structured process by which a company records, evaluates, tests, distributes, and verifies software fixes. It's much more than simply clicking "Update Now."

The difference becomes apparent when multiple servers, workstations, mobile devices, and specialized applications are involved. This is when the real challenge arises: Which updates are security-relevant, which could disrupt operations, and when can they be installed without interrupting business?

Patch management balances two opposing risks. Updating too late leaves known security vulnerabilities open. Updating without proper evaluation risks outages. This article shows how to reconcile these two risks: with a seven-step process, clear target times, maintenance windows, and transparent documentation.

Table of contents

• What is Patch Management?
• Patch, Update, or Upgrade: The Differences
• What Risks Arise – On Both Sides
• The Patch Management Process in 7 Steps
• Best Practices for SMEs: Target Times, Maintenance Windows, Exceptions
• Tools and Automation
• Do It Yourself or Outsource?
• Conclusion
• FAQ on Patch Management

What is patch management?

Patch management refers to the recurring process of identifying software and system fixes, assessing their risk, testing them, distributing them in a controlled manner, and documenting the results. The goal is to close known security gaps without compromising operational stability.

Installing individual updates may seem simple at first, but it doesn't scale. As soon as multiple locations, mobile devices, different software versions, and business-critical applications are involved, the coordination effort and the risk of errors increase dramatically.

In contrast, a process ensures repeatability: consistent evaluation criteria, standardized testing procedures, defined rollout phases, and documentation of what was implemented and when.

Which systems are included

A complete scope encompasses significantly more than just Windows workstations:

• Workstations: Operating systems, browsers and their extensions, mobile devices
• Servers: Windows and Linux servers, virtualization platforms, databases
• Network: Firewalls, switches, VPN connections, access points
• Third-party software: PDF programs, Office extensions, runtime environments, industry-specific software

The last group is the most common blind spot. These programs are not maintained via the operating system's central update mechanisms and therefore often remain outdated for years – even though they are frequently used for attacks.

Also easily overlooked: Network devices at the internet edge. A firewall or VPN connection is accessible from the outside and is therefore a prime target. Firmware updates for these devices are an essential part of the process.

Patch, update or upgrade: the differences

The three terms are often used interchangeably in everyday language, but they differ in scope, risk, and testing effort.

In practical terms, this means that a security patch for an exposed server should be installed within a few days. In contrast, upgrading to a new major version of a business application is a separate project with a testing phase, deadline, and fallback plan.

What risks arise – on both sides?

Patch management is challenging because both directions are dangerous.

Risk 1: updating too late

Manufacturers typically only release patches after a vulnerability has been analyzed. Publication makes the vulnerability public, and with it, the risk increases dramatically because attackers adjust their automated scans accordingly.

Unpatched systems are then exploited for initial network access, privilege escalation, or data exfiltration. A lack of updates is among the most frequent causes of successful attacks on companies, particularly as an entry point for ransomware.

Risk 2: updating without verification

An update can fix security problems while simultaneously introducing new ones. Changes to drivers, login procedures, network components, and anything else that business applications depend on are particularly vulnerable.

Typical errors after an untested rollout include:

• Login problems after changes to authentication components
• VPN connections dropping while working from home
• Business software failing to start or losing database connection
• Printer or scanner functions failing
• Noticeable performance degradation on terminal servers

The solution is not to patch less, but to patch in stages. First a small pilot group, then the wider community.

The patch management process in 7 steps

The following process works even with limited resources and still provides sufficient control and evidence.

1. Inventory: What devices, operating systems, applications, and network components exist, and how critical is each system?
2. Identify patch sources: Where does information about available fixes come from—vendor channels, management tools, security alerts?
3. Prioritize: Link the severity of the vulnerability to its business criticality and external accessibility.
4. Test: Pilot group for workstations, separate testing for critical server roles.
5. Plan the rollout: Define phases, coordinate maintenance windows, clarify restart rules and communication.
6. Deploy and monitor: Monitor installation status, error messages, and service availability.
7. Document and improve: Secure evidence, record exceptions, and incorporate findings into the next cycle.

Steps 1 and 2: No inventory, no patch management

The most common reason for gaps in inventory is not negligence, but a lack of awareness of one's own assets. Systems that no one has on their inventory list will not be updated: the old server in the next room, the laptop of someone who is rarely present, the network device at a branch office.

A useful inventory for each system records: a clear name, role, criticality, installed software with its version, and the responsible person. For mobile devices, the fact that they are often offline adds another layer of complexity – the process must include catch-up time.

Steps 3 and 4: Prioritize and test

Prioritization combines technical complexity with operational importance. A critical patch for an internet-accessible server takes precedence over an equally critical patch for an isolated test system.

For standard workstations, a representative pilot group of a few devices from different departments is usually sufficient for testing. For terminal servers, ERP systems, or industry-specific software, a dedicated test environment that replicates the core dependencies is worthwhile.

Define specific test cases in advance instead of general observations: login, access to network drives, printing, VPN connection, application startup, database access. And define termination criteria – at what point should the test be rolled back instead of being reworked?

Steps 5 to 7: Roll out, monitor, verify

Roll out in phases: pilot group, then standard workstations, then servers according to criticality.

Before making any changes to critical systems, a verified backup is essential. In virtualized environments, snapshots offer a quick way to revert to the original system—but they don't replace a backup because they reside on the same infrastructure.

Documentation is not an end in itself. In a crisis, it answers the crucial question: Was this system up-to-date at the time of the incident? Without documentation, it's impossible to pinpoint the cause or provide evidence to insurance companies or auditors.

For small and medium-sized enterprises (SMEs) without their own IT department, this very continuity is the hurdle—not the individual update. FIGULI CONSULTING builds the inventory, prioritizes security-relevant changes, coordinates testing, and manages the rollout with continuous monitoring. A central management platform is used to keep track of patch levels, errors, and exceptions for all managed systems.

Plan Patch Management with FIGULI

Best practices for SMEs: Target times, maintenance windows, exceptions

Define target times for each level of criticality

Instead of "as quickly as possible," verifiable targets are needed. A simple, phased approach has proven effective:

The specific timeframes must be tailored to the company. Crucially, they must be documented and measurable.

Once a vulnerability (CVE - Common Vulnerabilities and Exposures) with a CVSS score of 9.8 or higher is public and affects systems directly accessible from the internet, we recommend installing the patches or updates within 24 hours.

Coordinate maintenance windows with the relevant departments.

A maintenance window that affects accounting on the last day of the month will be avoided the second time around. Agree on fixed time slots with the relevant departments and communicate restarts in advance.

Announce necessary restarts early and clearly. Most of the available patches are already technically installed and are simply waiting for a restart, which no one is performing.

Exceptions are temporary

There will always be systems that cannot be updated—for example, a machine control system with manufacturer approval for a specific version.

Such exceptions are justifiable, but only under three conditions: they must be justified in writing, have an expiration date, and be secured by countermeasures, such as network segmentation or restricted access rights. An indefinite exception is not an exception at all, but rather a permanently open security gap.

Many companies use the module on patch and change management from the IT Baseline Protection Compendium as a guide for organizational structure.

Tools and automation

A suitable tool reduces tedious work, but it doesn't replace decision-making. Five functions are crucial:

• Inventory: automatic recording of devices, software, and version numbers
• Control: pilot groups, rollout phases, schedules, restart rules
• Coverage of third-party software, not just the operating system
• Reporting: technical status for IT, concise overview for management
• Revert: defined methods for undoing changes

In mixed environments, a combination is usually necessary: ​​the operating system's built-in tools for system updates, supplemented by a platform for third-party software and a central overview. For Linux servers, controlled package repositories and service-related tests are essential; for macOS, centralized management of operating system and program updates is key.

Automation is beneficial, but full automation is rare. Standard workstations can be largely automated. For servers and specialized applications, deliberate approval remains the better approach.

Operate it yourself or outsource it?

Without an in-house IT department, the challenge lies not in individual updates, but in ensuring reliable operation over months: keeping inventory up-to-date, prioritizing tasks, coordinating tests, monitoring rollouts, and maintaining documentation.

Outsourcing is worthwhile if updates regularly get delayed in daily operations, if many mobile devices or multiple locations need to be managed, or if critical systems require stable maintenance processes.

Responsibilities should remain clearly defined:

The costs depend primarily on the number of systems, the complexity of the environment, the amount of third-party software used, the desired response times, and the level of documentation required. Expect one-time costs for setup and inventory, as well as ongoing costs for operation, monitoring, and reporting.

Conclusion

Reliable patch management isn't achieved through isolated actions, but through clearly defined roles, binding target times, phased rollouts, and verifiable documentation. Patch management reduces the risk of successful attacks while simultaneously increasing stability because changes are implemented in a controlled manner rather than improvised.

Getting started doesn't require a comprehensive process. Begin with a complete inventory – it almost always uncovers systems that no one had considered. Then add target times for each criticality level and a fixed monthly cycle. Testing, reporting, and written policies are added gradually.

FIGULI CONSULTING supports Austrian SMEs in setting up and maintaining a structured patch management system: with inventory, prioritization, maintenance windows, rollout monitoring, and transparent reporting. This ensures that security updates are reliably installed without unnecessarily disrupting business operations.

Plan your patch management with FIGULI

FAQ on Patch Management

What is Patch Management?

Patch management is the structured process of identifying, prioritizing, testing, deploying, and documenting fixes for operating systems, applications, and devices. The goal is to close security gaps promptly while ensuring operational stability through controlled changes.

What is the difference between a patch, an update, and an upgrade?

A patch specifically addresses a vulnerability or a particular bug. An update bundles several changes and may include minor functional adjustments. An upgrade is a version jump with new features and significantly more testing and migration effort.

What risks arise from missing patches?

Known vulnerabilities remain exploitable and can serve as an entry point into the network, a means of escalating privileges, or for ransomware. Especially for servers, firewalls, and VPN connections, patch management should be closely integrated with ongoing server maintenance.

How often should updates be installed?

A staggered approach based on criticality is advisable: security-critical fixes for exposed systems within a few days, critical internal systems during the next maintenance window, and standard workstations on a monthly cycle. Crucially, the target times must be documented and verifiable.

How do I test patches before rollout?

Use a pilot group consisting of a few devices from different departments. For critical applications, also use a test environment. Define specific test cases such as login, printing, VPN connection, and database access, as well as clear termination criteria and a fallback plan.

What should be included in patch management?

In addition to workstations and servers, network devices such as firewalls, switches, and VPN access points are included, as well as virtualization platforms and third-party software. Third-party software and network devices are often overlooked, even though they are regularly used for attacks.

When is outsourcing worthwhile?

Outsourcing is beneficial when updates are neglected in daily operations, when many mobile devices or multiple locations need to be managed, or when critical systems require stable maintenance processes. Internally, approvals and business priorities remain the focus; externally, inventory, rollout, monitoring, and documentation are handled.