Proving Patch Management: What Reports Auditors and Major Clients Actually Want to See

The updates run automatically—but no one can prove it

The question on the questionnaire sounds harmless: “Within what timeframe are critical security updates installed, and how do you verify this?” The honest answer in many companies is: Windows updates itself, the rest happens eventually, and there’s no way to prove it. This is precisely where supplier audits fail more often than due to a lack of technology.

The unfortunate part is that the company is often better prepared than it can prove. The systems are up to date, but no one can say how up to date, since when, on how many devices, or which vulnerabilities have been patched. This article explains what auditors and major clients actually want to see, which reports provide that information, how the patching modules from major vendors differ, and what limitations you should be aware of before purchasing.

Why do auditors ask about the patch status first, of all things?

Because unpatched, publicly known vulnerabilities are among the most common entry points of all—and because, unlike many other factors, this aspect can be objectively verified. An auditor cannot measure how well your workforce recognizes phishing. However, they can ask how old the oldest unpatched critical vulnerability in your inventory is—and that number says a lot about the organization as a whole.

In addition, this topic appears in virtually every set of regulations. The 2022 version of ISO 27001 lists the management of technical vulnerabilities as a separate control point under section 8.8. The NIS 2 Directive explicitly names the handling and disclosure of vulnerabilities as one of the required categories of measures. And the Swiss ICT Minimum Standard includes vulnerability management within the “Identify” and “Protect” functions. Anyone designing a questionnaire draws on these sources—which is why the questions are so similar.

Is the update required, or is proof required?

Both, but it is the proof that is verified. This is the point where most organizations underestimate the issue. An auditor cannot see whether your devices are up to date—they can only see what you present to them.

Typically, four things are required. First, a written policy specifying responsibilities and deadlines based on severity—for example, critical vulnerabilities must be addressed within fourteen days. Second, reports demonstrating that vulnerability scans are conducted regularly, with a clear timeline. Third, a tracking system from discovery to resolution that shows who did what and when. Fourth, a documented exception policy for anything that cannot be patched.

The most common complaint is a specific one: the organization marks a vulnerability as resolved without having technically verified that the patch has actually been applied. A checkmark on a list is not proof—a repeat scan that no longer finds the vulnerability is.

Answering Security Questionnaires from Major Clients Correctly
Shows which items on such questionnaires can be substantiated with endpoint software and which must be verified through organizational measures.

Are automatic Windows updates not enough?

For the operating system, yes; for the rest, no—and the rest is the larger attack surface. Microsoft’s automatic updates cover Windows and Microsoft applications. They do not cover everything else typically installed on a workstation: PDF programs, browsers other than Edge, archiving tools, runtime environments, remote maintenance software, and industry-specific applications.

It is precisely these programs that are listed in the questionnaire under the heading “third-party applications,” and it is precisely these that are most often out of date in practice because no one addresses them individually. A patch module handles them centrally and, in doing so, provides the side effect that really matters: a list of exactly which software is actually in use. This inventory is the first required attachment for most audits.

There’s a second point to consider: Automatic updates cannot be controlled. Anyone who needs to prove that a patch was installed within a specific timeframe requires a schedule and a report—not a mechanism that runs on its own at some point.

What is the difference between vulnerability management and patch management?

Vulnerability management identifies and assesses vulnerabilities; patch management resolves them. This distinction isn’t just semantics—it’s the reason why some questions on the questionnaire cannot be answered using a patch module alone.

The process has four stages: identifying which software is installed and what known vulnerabilities it has; assessing how severe and exploitable these vulnerabilities are within your own environment; remediating them, usually through a patch; and verifying that the remediation was effective. Most products in this category cover all four stages, which is why they are often called “Vulnerability and Patch Management.”

The distinction becomes important when no patch is available—either because the vendor has not yet released one or because the software is at the end of its lifecycle. In such cases, every set of guidelines requires an alternative measure and a decision—not simply inaction. This is precisely why the assessment phase is necessary.

What deadlines should I set for critical vulnerabilities?

One that you can meet. That sounds obvious, but it’s the only sensible rule: A seven-day deadline that’s regularly missed looks worse in an audit than a thirty-day deadline that’s met. You made a commitment and didn’t keep it.

It’s common to tier deadlines by severity, with different deadlines for critical, high, and medium-severity gaps. However, severity alone is a weak metric. The classification becomes more meaningful when two additional factors are taken into account: whether the vulnerability is already being actively exploited, and whether the affected system is accessible from the Internet. A medium-severity vulnerability on a server connected to the Internet—for which attack tools already exist—is more urgent than a critical vulnerability on an isolated test system.

Incorporate this logic into your policy. An auditor who sees that you prioritize based on exploitability and exposure rather than strictly by score will view this as a mature process—and accept longer deadlines for the non-critical portion.

What specific reports do I need?

Five reports cover the vast majority of all questionnaires and audits, and all five come from the management console, not from a self-maintained spreadsheet.

First, the inventory list: which devices are being managed and what software is installed on them. Second, the report on missing patches, broken down by severity—this report answers the question of the current status. Third, the same report with age information, i.e., how long a vulnerability has been open; this is the metric an auditor uses to measure your compliance with deadlines. Fourth, the list of failed installations, because a patch that didn’t install successfully will never be noticed without this report. Fifth, the overview of intentionally excluded patches, along with the reasons for their exclusion.

All of these reports have two characteristics that a manually maintained table lacks: a date and a scope. The report doesn’t just say that ninety-two devices are up to date, but also that a total of ninety-four are being managed. This difference is exactly what’s needed.

What do I do with systems that cannot be patched?

You document them as exceptions—including the reason, a workaround, a time limit, and approval. This is a recognized procedure and not an admission of weakness. What is not recognized is failing to mention the affected systems at all.

Typical examples include a machine control system whose manufacturer does not grant approval for newer versions, an industry-specific application that requires an outdated runtime environment, or a legacy system that must remain in operation for contractual reasons. Possible remedial measures include network isolation, restriction of access rights, an application lock on the affected system, or enhanced monitoring.

It is important to set a time limit. An exception without an expiration date will be flagged during the next audit because it indicates that no one is monitoring the situation anymore. Set a date by which the decision must be reviewed, even if it is foreseeable that the outcome will be the same.

How do the vendors’ patch modules differ?

Modules that centrally update operating systems and third-party applications and provide reports on these updates are comparable. Kaspersky offers its Vulnerability and Patch Management both as a standalone product and as an add-on module to existing packages and is therefore discussed separately below.

Feature	Bitdefender GravityZone Patch Management	ESET Vulnerability & Patch Management	Avast and AVG Business Patch Management
Windows and Third-Party Apps	✓	✓	✓
macOS	✓	✓	✕
Linux	Limited	✓	✕
Console can be run locally	✓	✕	✕
Local patch cache	✓	See note	✓
CVE information per patch	✓	See note	See note
Microsoft ESU patches	See note	See note	✕
Availability	Add-on module	Included starting with Complete	Standalone product

Regarding open and restricted fields: On Linux, Bitdefender does not update applications installed outside the package manager and automatically installs only digitally signed patches—for all others, a manual step is required, which you must account for in the process. For ESET, the information regarding CVE identifiers per patch and a local cache is not available at the same level of detail and should therefore be included in the proposal. For Avast and AVG, it is explicitly documented that extended security updates from Microsoft are not supported—a consideration for any organization operating a system beyond the regular end of support.

Which product is right for which environment?

For pure Windows environments that do not yet use a business package from one of the major vendors, standalone products are the fastest option: Avast Business Patch Management ⧉ and AVG Patch Management Business Edition ⧉. Both allow you to schedule scans daily, weekly, or monthly, display missing patches along with their severity level and release date, and let you exclude specific vendors or applications. To conserve bandwidth, a selected device on the network handles the distribution. The limitation is clear: Windows only; no other operating systems.

If you’re already using GravityZone, you can add Bitdefender GravityZone Patch Management ⧉ as an add-on module. It covers Windows, Linux, and macOS, displays the CVE identifier for each patch, can block individual patches if they disrupt a workflow, and can postpone the required reboot. For distribution within your own network, a device with a relay role can also be set up as a cache.

With ESET, the module is part of the package tier. It is included starting with ESET PROTECT Complete ⧉ as well as in ESET PROTECT Elite ⧉, which also includes the Detection and Response component. For the Entry and Advanced tiers, it can be added as a separate feature. It covers Windows, Linux, and macOS, including third-party applications, and the functionality can also be extended to servers, provided they are running the latest versions of the corresponding ESET server products.

Kaspersky offers both options: Kaspersky Vulnerability and Patch Management ⧉ as a standalone product and Kaspersky Vulnerability and Patch Management as an add-on ⧉ to supplement an existing Kaspersky package. Which option is available to you depends on the base product and should be clarified before placing an order.

Base, Base Plus, Add-On, or Renewal—what these terms mean
Explains how to interpret the package names available on the market and which of them require an existing license.

Do I perhaps already have the patch module?

Possibly, and it’s worth checking before placing any order. Several vendors have included patch management in their higher-tier packages instead of selling it separately.

With Kaspersky, patch management is included in the Next EDR Optimum tier; with ESET, it’s included starting with PROTECT Complete; and ThreatDown Advanced ⧉ also includes it as part of the bundle. Anyone who already has a license for one of these tiers doesn’t need an additional product; they simply need to activate and configure the feature—which, in practice, is surprisingly often overlooked because no one realizes it’s included.

Conversely, with Bitdefender, patch management is not included in any package tier but is consistently a paid add-on module. An offer for GravityZone that does not include this item does not meet the questionnaire requirement.

What pitfalls are there when making a purchase?

Three, which are often only noticed after placing an order.

The first concerns ESET: According to the manufacturer, vulnerability and patch management are not available in the locally operated version of the management console but require the cloud console. Organizations that deliberately manage their systems in-house—for example, due to location-specific requirements—cannot use this feature there. This is not a minor detail but a fundamental decision that must be made before purchasing.

The second issue concerns the software list. Each module updates only what is listed in its catalog. These catalogs are extensive and are continuously expanded, but they never cover everything. Bitdefender publishes a downloadable list of supported vendors and products that is updated monthly. Before purchasing, check whether your most important applications are included—industry-specific software, in particular, is rarely listed and must therefore be handled manually, which you’ll need to document separately.

The third point concerns servers. A patch module that covers only workstations only partially answers the questionnaire question, since the question refers to the entire infrastructure. Clarify whether server licenses include the same functionality and whether separate items are required for them.

Server Protection, Exchange, and File Servers: Why Endpoint Licenses Aren’t Enough
Explains why servers require their own licenses and products, and which additional roles must be covered.

How do I handle reboots?

Use scheduled maintenance windows instead of ad-hoc requests. Restarts are the reason why patch management fails in many organizations: No one wants to restart the server during working hours, and no one is there in the evening.

The modules solve this through two mechanisms. First, the scan can be separated from the installation—scans run daily, while installations occur at a scheduled time. Second, the reboot can be postponed so that the patch is installed but does not take effect until the next regular reboot.

When it comes to verification, one point is crucial but is easily overlooked: A patch that has been installed but is not yet active does not close the vulnerability. If your report counts such cases as resolved, you are verifying a state that does not exist. Therefore, define how long a pending reboot may remain open, and treat any instances that exceed this limit as an open vulnerability.

How does patch management help with the reporting requirement in Switzerland?

As of April 1, 2025, operators of critical infrastructure must report cyberattacks to the Federal Office for Cybersecurity within 24 hours of discovery, in accordance with the revised Information Security Act and the Cybersecurity Ordinance; missing information may be submitted within 14 days. This applies to government agencies and organizations as defined in Art. 74b of the Information Security Act (ISG); exceptions exist for smaller organizations and incidents with minor impacts.

The patch status plays no direct role in the report itself. However, it becomes important immediately afterward, specifically in determining how the attacker gained access. If it turns out that a vulnerability known for months and capable of being patched was exploited, this presents a different scenario than an attack via a vulnerability unknown at the time of the incident. A report documenting the patch status of the affected system at the time is therefore one of the most valuable documents of all—provided it was generated and retained prior to the incident.

What patch management does not do: It does not determine whether your organization is subject to reporting requirements, it does not detect an ongoing attack, and it does not replace a designated responsibility for reporting.

What does the NIS 2 Directive require regarding vulnerabilities?

The directive lists the handling and disclosure of vulnerabilities as one of the categories of measures that affected organizations must implement. It does not prescribe any specific software or a concrete deadline—what is required is a procedure that is demonstrably applied.

This is supported by the scans, prioritization, and reports generated by a patch module. The organizational aspects are not covered: the written definition of deadlines, the designated responsibilities, the handling of external reports regarding discovered vulnerabilities, and the regular review of whether the procedure is effective at all. No product can address these points.

Organizations that must comply with both Swiss and European requirements are faced with two sets of regulations that differ in terms of deadlines and terminology.

A Comparison of Cybersecurity Obligations in Switzerland and the EU
Compares the Swiss reporting requirement with the requirements of the NIS 2 Directive and highlights where they differ.

What does a patch module not cover?

Anything that isn’t an operating system or an installed application—and that’s more than you might think.

Not covered are the firmware of network devices, firewalls, access points, printers, and NAS systems. Yet it is precisely these devices that are directly connected to the internet and whose vulnerabilities are exploited particularly frequently. Also excluded are machine control systems, cloud services where the provider handles updates, and software that has reached the end of its lifecycle and for which there are simply no more patches available.

For these areas, you’ll need a second, usually manual process with its own list and schedule. Anyone who checks the box on the questionnaire indicating that all systems are integrated into patch management—while firewalls and NAS devices are managed separately—is providing information that won’t stand up to scrutiny.

How do I get started in thirty days?

In the first week, establish visibility: activate or procure the module, integrate all devices, and perform an initial full scan. Experience shows that the results are often unsettling—and that’s precisely why they’re valuable—because they reveal the actual inventory for the first time.

In the second and third weeks, work through the backlog, starting with everything accessible from the internet, and simultaneously document the guidelines: Who is responsible, what deadlines apply based on severity, when to scan, when to install, and how exceptions are approved. One page is sufficient; it just needs to be dated and approved.

In the fourth week, you generate the first set of reports and file them away. It is precisely this filed, dated report that serves as the proof people are asking for—and from the moment you start repeating this process monthly, a snapshot turns into a verifiable history. That is the real difference between a company that patches vulnerabilities and one that can prove it.

 

---