Patch Management Services

The Vulnerability Was Public. The Patch Was Available. Nobody Applied It.

Read the incident reports and a pattern repeats with uncomfortable regularity: the flaw that let an attacker in had a vendor fix available, sometimes for months. Patching is unglamorous work, and it is the work that would have prevented a large share of the intrusions our forensics team investigates.

Almost nobody sets out to run unpatched systems. The gap opens quietly, through a sequence of individually reasonable decisions. A server hosts an application the vendor certified against a specific operating system build, so updates are deferred until the vendor blesses a newer one, and the vendor is in no hurry. A line-of-business tool broke once during a maintenance window two years ago, so automatic updates were disabled on the machines running it and never re-enabled. A firewall or switch is working fine, and firmware updates for network gear require a reboot that interrupts everyone, so they wait for a quieter quarter that does not arrive. Each choice made sense in isolation. Together they produce an environment where the average time between a fix being published and a fix being installed is measured in seasons.

The second failure mode is coverage rather than delay. Most organizations can report confidently on the machines their management tool knows about. The risk sits in the machines it does not: the laptop of an employee who has not connected to the corporate network in five weeks, the virtual machine spun up for a project and never decommissioned, the contractor device that was granted access once, the appliance a vendor installed and manages badly, the workstation in a back office that runs a single piece of specialized equipment. A patch compliance report showing ninety-eight percent is comforting until you learn that the denominator was wrong. Attackers do not sample your environment randomly. They find the two percent.

Third-party software is the third gap, and it is the largest one in most environments we assess. Operating system vendors have spent two decades building reliable update mechanisms, and the built-in tooling handles them acceptably. The browsers, PDF readers, compression utilities, remote access clients, database engines, runtime frameworks, media players, conferencing tools, and dozens of small utilities installed by individual users have no such coordination. Each has its own release cadence, its own updater, and its own habit of failing silently. These applications sit directly in the path of email attachments and web content, which is exactly where an initial compromise tends to begin.

Petronella Technology Group approaches patching from a position most managed service providers do not occupy. We run offensive security engagements, including internal penetration testing and external penetration testing, and our founder is a licensed digital forensics examiner who investigates breaches after they happen. That gives us an unusually direct view of which missing patches adversaries actually convert into access, and which ones sit near the bottom of a severity list forever without ever mattering. Patch management done well is not about installing everything immediately. It is about knowing what to move first.

Patching is one function inside a larger operational program. For most clients it sits alongside monitoring, backup, and support under managed IT services, with server workloads handled through server management services and day-to-day user issues routed through the IT help desk. Organizations with their own IT staff frequently take patching alone as a co-managed IT services engagement, keeping everything else in house.

The honest comparison is not managed patching against a well-run internal program. A well-run internal program is excellent, and organizations that have one should keep it. The comparison that matters is against the program most organizations actually have, which is automatic updates enabled where they were never disabled, a handful of servers patched during whichever quarter someone remembered, and no way to answer the question an auditor or an insurer will eventually ask.

The fifth item deserves particular attention because it produces false confidence rather than known risk. A machine that has downloaded an update, applied it to disk, and is waiting on a restart will frequently report itself as compliant while remaining fully exploitable until someone reboots it. In environments where users suspend laptops rather than shutting them down, and where server reboots are deferred to avoid disruption, this state can persist for months across a meaningful share of the estate. We measure applied-and-active rather than downloaded, which is why our first report often looks worse than the one it replaces.

Step five is where most programs quietly fail, and it is the step that separates a mature operation from a wishful one. Every environment has something that cannot be patched on the standard schedule: a medical device with a locked-down operating system, a manufacturing controller certified against a specific build, an application whose vendor has not shipped an update in three years. Pretending otherwise produces a program people route around. The correct answer is to name the exception, document why it exists, put a compensating control around it such as network segmentation or restricted access, assign an owner, and set a review date. An assessor will accept a documented exception with a control. An assessor will not accept a surprise.

Where Patch Management Shows Up in Your Obligations

Almost every framework a regulated business answers to names patching directly, and assessors ask for evidence rather than intent.

Defense contractors face the most explicit requirement. NIST SP 800-171 requires organizations to identify, report, and correct system flaws in a timely manner, and to install security-relevant updates within defined periods. Those controls carry directly into CMMC, where an assessor will ask what your defined timeline is, whether you met it, and how you know. A verbal answer does not survive that conversation. If you are estimating where your program currently stands, our free SPRS score calculator shows how flaw remediation weighs against the rest of the assessment, and Craig Petronella's CMMC 2.0 Certification Guide walks through the underlying control families.

Healthcare organizations reach patching through the HIPAA Security Rule, which requires procedures for guarding against and detecting malicious software and expects the risk analysis to account for known technical vulnerabilities. Running software with published, unaddressed flaws is difficult to defend as reasonable and appropriate when the fix was freely available. Our HIPAA compliance team scopes patch programs with that documentation burden in mind, and the same discipline supports the broader IT security risk assessment that regulation expects you to maintain.

Payment environments have the most prescriptive language of all: PCI DSS sets explicit expectations for how quickly critical security patches must be installed, and a quarterly scan will find what you missed whether or not you were tracking it. Beyond formal regulation, commercial pressure now does similar work. Cyber insurance applications ask about patching cadence and unsupported software, enterprise procurement questionnaires ask the same, and a claim can be complicated by an answer that turns out to have been optimistic. Organizations building the surrounding documentation often use our ComplianceArmor platform to generate and maintain the written policies these frameworks require.

What Drives the Cost of a Patch Management Service

Pricing follows the shape of the environment rather than a headcount alone. These are the factors that move an estimate, and the ones we confirm during scoping.

The primary driver is the number and diversity of systems in scope. Fifty identical Windows laptops running a standard image are a straightforward engagement. Fifty endpoints spread across three operating systems, plus a dozen servers, two hypervisor hosts, a storage array, and a set of network appliances, is a materially different program, because each platform brings its own update mechanism, its own testing requirements, and its own failure modes. Diversity costs more than volume, which is why standardizing an estate often pays for itself in operating cost as well as in risk.

The second driver is the tolerance of the business for disruption. An office that can accept a Tuesday evening maintenance window is inexpensive to serve. A manufacturing line, a clinical environment, or a system supporting overnight processing requires coordinated windows, tighter testing, staged rings, and sometimes standby staff, all of which represent real effort. Similarly, regulatory scope raises effort: an environment holding controlled unclassified information, protected health information, or cardholder data requires evidence discipline and reporting rigor that a general office network does not.

Finally, the starting condition matters more than clients expect. Taking over a well-maintained environment is mostly a matter of instrumenting it and running the cycle. Taking over an environment with years of accumulated exceptions, unsupported software, and undocumented systems involves a remediation project before the steady-state service begins, and it is more honest to price that separately than to bury it. We assess the actual environment and provide a written estimate before any work starts, because a monthly figure quoted without seeing the estate is a guess wearing a suit.

Twenty-Four Years of Keeping Systems Current

Patching is a maintenance discipline, and maintenance disciplines are proven by longevity rather than by marketing.

Petronella Technology Group has operated from Raleigh since April 2002 and has held a BBB A+ rating since 2003. We are a CyberAB Registered Provider Organization (RPO #1449) with CMMC Registered Practitioners on staff, and our founder is an NC Licensed Digital Forensics Examiner (License #604180-DFE) and cybersecurity expert witness. Twenty-four years of continuous operation means we have supported clients through several complete generations of operating systems, three eras of update tooling, and every kind of update that broke something important at an inconvenient hour. That history is the relevant credential here. Patching is not difficult to understand; it is difficult to sustain.

Craig Petronella has published 15 books on cybersecurity and business technology. In How Hackers Can Crush Your Business he makes the case that attackers rarely need a novel exploit when an ordinary maintenance lapse will do, which is precisely the economics that make patch management the highest-return control most organizations own. His IT Buyers Guide sets out the questions to ask before signing any IT contract, including several worth asking of us. He holds MIT Sloan Executive Education certification in Cybersecurity for Managers, has appeared as a cybersecurity commentator on NBC, ABC, CBS, FOX, and WRAL, and hosts the Encrypted Ambition podcast. The full library is available in our book collection.

We also verify our own work adversarially, which few providers do. The same firm that patches your environment runs penetration testing engagements against client networks, performs digital forensics after incidents, and now delivers AI red teaming for systems built on language models. Findings from that offensive work feed straight back into how we prioritize updates, and a patch report that has survived an internal penetration test is worth considerably more than one that has only ever been read.

The Triangle concentration of healthcare systems, biotechnology firms, law practices, universities, and defense suppliers means our engineers spend their days in environments where a maintenance window is genuinely constrained and the compliance evidence genuinely matters. Local clients can read more about our regional practice on our managed IT services in Raleigh page. Clients elsewhere receive the same program delivered remotely, with the same reporting and the same option to fold patching into a broader cybersecurity engagement.

Last Updated: July 28, 2026