Deploying a patch is the easy part. Knowing what you own, and proving the update actually landed on all of it, is where patch management fails.
The short answer
Patch management is the process of identifying missing software updates across everything you run, testing them, deploying them on a defined schedule, and verifying they applied. It is one remediation path within vulnerability management, and the one that covers most known vulnerabilities in practice.
Most breaches involving a known vulnerability involve one where a patch already existed. Patch management is therefore an operational discipline before it is a technical one.
On this page
The five stages of patch management
Every patch management programme runs these five, whether or not anyone has named them.
| Stage | What it involves |
|---|---|
| Inventory | A current list of devices, servers, images and installed software. Without it, coverage figures are guesses |
| Detect | Comparing installed versions against available updates, usually through scanning or agent reporting |
| Test | Confirming the update does not break something. In practice most teams test on a small ring rather than a lab |
| Deploy | Rolling out in waves so a bad update affects a few machines rather than everyone |
| Verify | Confirming the version changed on each asset. This is what closes the loop, and the stage most often skipped |
Patch management is not vulnerability management
The two get used interchangeably and they are not the same scope. Patching is one of several responses to a finding.
| Response | When it is the right one |
|---|---|
| Apply the patch | A fix exists, testing is feasible, and downtime is acceptable. The default |
| Change configuration | The vulnerable feature can be disabled without losing anything you use |
| Compensating control | No patch available or deployment is blocked, so exposure is reduced another way, such as filtering the request at the web protection layer |
| Rebuild the image | Containers and ephemeral cloud instances. You replace the image rather than patch the running workload |
| Decommission | End-of-life software with no fix coming. Removal is the only real remediation |
| Accept the risk | Formally, with an owner and a review date. Not by silence |
Vulnerability management decides which of those applies and tracks it to closure. Patch management executes one of them well. Conflating the two produces a patch management programme that only ever handles the vulnerabilities that happen to have patches, and quietly ignores the rest.
Where patch management breaks down
Patch management rarely fails at the deployment step. It fails at the edges of the estate.
| Reason | What it looks like |
|---|---|
| The unmanaged tail | Servers are patched centrally. Laptops, contractor machines, that one legacy virtual machine and the demo environment are not |
| Reboots | The patch installs but requires a restart. Users defer indefinitely, so the machine reports patched and remains vulnerable |
| Third-party applications | Operating system updates are automated. Browsers, runtimes, database clients and desktop tools each have their own updater |
| Fear of breakage | One bad update years ago produced a permanent culture of deferral, which is worse than the original risk |
| End of life | No patch is coming. The finding stays open forever because nobody wants to own the migration |
| Cloud images | Instances are patched but the base image is not, so every new deployment reintroduces the vulnerability |
Reported patched is not the same as patched
Two failure modes hide inside a healthy-looking dashboard. A pending reboot leaves the vulnerable code still running while the tool reports the update as installed. A stale base image means every fresh container or instance arrives with the flaw already present, no matter how diligently the running fleet was updated. Both are only caught at the verify stage, which is why verification against actual running versions matters more than deployment success rates.
What auditors check in patch management
| What they ask for | Why it fails |
|---|---|
| A documented patching policy with timelines by severity | The policy exists but names no deadlines, so nothing can be measured against it |
| Evidence patches were applied within those timelines | Critical fixes sat open for months with no recorded reason |
| Coverage across the whole estate | The report covers servers only. Endpoints and cloud images are absent |
| An exception register | Deferrals are informal, with no owner, no compensating control and no review date |
| Emergency patching process | No defined path for an actively exploited flaw outside the normal cycle |
| Verification records | Deployment logs are supplied instead of proof the version actually changed |
PCI DSS names a specific window for critical patches. SOC 2, ISO 27001 Annex A and NIST CSF ask you to define your own timelines and then evidence that you met them. Setting a realistic deadline and hitting it consistently evidences better than an ambitious one you routinely miss.
Where Osto fits
Osto is not a patch deployment tool. It does not push operating system updates or replace the endpoint management platform that installs them, and that distinction is worth being clear about before a demo.
What it covers is the rest of the patch management programme. The VAPT scanner and vulnerability scanning find what is missing and categorise it by severity, with retest reports that close the verify stage. Cloud posture management covers the image and instance side. Software composition analysis and SBOM generation handle dependency versions in your own code, which no operating system updater reaches.
For the gap between disclosure and deployment, web and API protection can filter exploitation attempts at the edge, which is the compensating control auditors expect to see documented against a deferral. Findings, remediation and retest evidence live in one place alongside SIEM records, so the audit answer is one report rather than an export from four tools.
Platform walkthrough
Findings, fixes and retests in one record
Scanning across apps, cloud and dependencies, with edge filtering for the window before a fix ships and retest evidence an auditor will accept. One owner, one dashboard.
Book a demoEvidence from live controls · 200+ frameworks mapped · One platform, everything
Frequently asked questions
What is patch management?
Patch management is the process of finding missing software updates across your estate, testing them, deploying them on a defined schedule and verifying they applied. It covers operating systems, applications, firmware and cloud images.
What is the difference between patch management and vulnerability management?
Vulnerability management finds weaknesses, decides how to handle each one and tracks it to closure. Patch management executes one of those responses and evidences it. Configuration changes, compensating controls, image rebuilds and decommissioning are the others.
How quickly should critical patches be applied?
PCI DSS sets a defined window for critical fixes. Other frameworks ask you to set your own timeline and evidence that you met it. A realistic deadline consistently met evidences far better than an aggressive one routinely missed.
Do you patch containers?
Not the running container. You rebuild the image with the updated package and redeploy, because a patch applied to a running container disappears at the next deployment. Patching the base image is the actual fix.
What if no patch exists?
Apply a compensating control and record it. Disable the vulnerable feature, restrict access, or filter exploitation attempts at the web protection layer. For end-of-life software with no fix coming, decommissioning is the only genuine remediation.