Patch management automation in vRx: when to use static and dynamic patch groups

Patch management automation needs a clear answer to one question: should the set of patches stay fixed, or should it change as new patches match an approved rule? Use a static patch group when you need a deliberate selection. Use a dynamic patch group when you want recurring selection to follow a rule as patch data changes.

In vRx, static groups contain hand-picked patches; dynamic groups maintain membership from rules. Deployment can run on demand, on a schedule, or through configured rules. These controls let teams turn repeatable patch selection into recurring remediation while retaining a deliberate path for specific changes. Vicarius documents these patch-group and deployment options.

Choose the group according to what the team authorizes over time. A pilot may require the same selected patches throughout its review. Routine application maintenance may require new matching patches to enter the selection without somebody rebuilding a list every week. Both choices can support automation.

Decide what is allowed to change

Start with the intended remediation outcome. For a compatibility pilot, you may want to establish whether a particular update works with an important application. For recurring maintenance, you may want a supported application family to receive eligible updates through an established process.

Those objectives call for different selection behavior. A changing patch list makes it harder to reproduce the original pilot. A permanently fixed list can leave recurring work waiting for someone to add the next release. Choosing a group type should resolve that difference before you decide how often deployment runs.

The first two rows describe documented product behavior. The review focus is a recommended operating practice: review the part of the process that can change the meaning of the work.

Keep patch selection separate from asset targeting

A patch group answers which updates belong in the work. An asset group answers which machines are in scope. A software group organizes applications. Treating these as separate decisions makes the resulting policy easier to explain and test.

For example, selecting an application's patches does not by itself describe the devices that should receive them. The same selected update may be appropriate for a test population today and a broader population after validation. Likewise, a group of production servers can remain stable while its eligible patch selection changes.

Use this separation in the policy description. State the selection, the target population and the deployment timing independently. That gives a reviewer a concrete way to identify an accidental expansion without reconstructing the entire workflow from a group name.

For readers establishing the wider process, the patch management overview provides the broader context. Here, the decision is narrower: which selection behavior should feed recurring remediation?

A fixed pilot and a recurring policy can coexist

Consider a hypothetical endpoint team preparing an application update. Its service owner wants a compatibility check against a business-critical extension before wider deployment. The team also maintains a recurring patch policy for ordinary releases.

For the pilot, the team deliberately selects the update under review and identifies the test population. It records the application behavior that must remain healthy and the evidence needed to accept the change. The selected patch set provides a stable reference for that evaluation.

For recurring maintenance, the team defines a rule that represents the intended patch family. The policy owner reviews that rule and the associated deployment scope. Future membership changes can then follow the rule rather than a repeated request to assemble another spreadsheet.

These are two operating patterns, not a claim that one group automatically promotes into another. The organization should define how a pilot result affects the next deployment decision. Keep that decision consistent with its existing change process.

A useful review question is: if a new matching patch appears tomorrow, should this work include it? If the answer is yes under the same policy, dynamic selection deserves consideration. If the answer is that only the specifically reviewed set belongs in the change, a static selection is easier to reason about.

Let policy carry the routine work

The goal is to avoid rebuilding ordinary remediation decisions for every release. Write the recurring policy at the level where the team can authorize repeatable behavior: the intended software scope, target population, timing and evidence of completion.

Human attention should concentrate on situations that change that authorization. Examples include a newly important application dependency, a failed functional check, a target population that no longer matches the policy or an update requiring a different maintenance arrangement. These are reasons to reassess the policy, not reasons to recreate every routine deployment manually.

Give each exception a responsible owner and a next decision point. A deferred update with no revisit condition can become invisible inside a successful-looking schedule. An exception record should identify the affected assets, the reason for delay and the evidence that will allow the work to resume.

Use the team's existing authoritative records and automate the transfer of routine execution evidence wherever its established integrations support that flow. The purpose is to preserve a decision trail without making people retype deployment results.

Verify the outcome on the affected assets

After deployment, verify that the intended systems run the required software and that the vulnerable condition has been removed. Group membership alone cannot establish either result.

NIST includes verification within enterprise patch management, alongside identification, prioritization, acquisition and installation. Use that lifecycle to define completion before deployment begins. NIST SP 800-40 Revision 4 provides the underlying planning guidance.

For a hypothetical deployment, the completion review might distinguish machines where installation succeeded, machines awaiting a required restart and machines that were not available for assessment. Preserve those differences. A device that has not supplied current evidence should not quietly inherit the status of a reachable peer.

The relevant verification also depends on the change. An installed-version check can help establish that an update landed; the service owner may still need a functional check. Define both tests where necessary, and keep the result tied to the asset and observation time. The patch verification checklist explains this evidence distinction in more detail.

Handle work that cannot follow the routine patch path

Some remediation decisions will need a different action or timing. Route those cases through an explicit exception process rather than quietly expanding a patch-selection rule to cover unrelated work.

For the policy owner, the essential questions are practical: what condition remains, what action is currently authorized and what evidence would demonstrate an acceptable outcome? Record temporary exposure reduction separately from permanent correction. This preserves the purpose of remediation when the preferred fix cannot proceed on the normal schedule.

Review repeated exceptions as a policy-design signal. If the same application repeatedly needs a special decision, its dependencies or maintenance requirements may justify a separate operating pattern. Changing a policy deliberately is more useful than carrying an unexplained exception indefinitely.

Frequently asked questions

When should I use a static patch group in vRx?

Use a static group for a deliberately selected set, such as the updates under review in a bounded pilot. Its membership stays fixed until changed. That makes the selected set explicit without implying that the overall deployment process must be manual. See the documented group behavior.

When does a dynamic patch group make sense?

A dynamic group suits recurring selection when a rule expresses which patches belong. Review the rule carefully because it governs membership as patch data changes. Decide separately which assets receive deployments and under what timing policy.

Does a dynamic group mean every new patch deploys immediately?

No. Group membership and deployment policy answer different questions. Document both the selection rule and the authorized deployment behavior so that a current patch list is not confused with an instruction to deploy immediately.

How should a team measure whether automation worked?

Check whether the intended assets reached the required state, identify exceptions and retain time-stamped verification evidence. Count completed actions separately from confirmed remediation outcomes, especially when restarts or service checks are required.

See the selection-to-remediation flow

Request a vRx demo focused on a fixed pilot and a recurring patch policy. Bring one application scope and one target population so the discussion can follow the work from selection through deployment and verification.