A maintenance group is a set of assets with similar characteristics that generally get the same patching plan. NIST SP 800-40 Rev 4 recommends assigning every asset to one, then writing a plan for each group and each risk scenario. Fewer, clearer groups mean fewer exceptions to chase.
What NIST says
NIST says organizations should use software inventories, technical and business or mission characteristics, and risk response scenarios to assign each asset to a group. It leaves the level of detail to you, and asks you to reassess the definitions periodically and adjust them.
A maintenance plan then states the actions to take when a scenario occurs for a group, including the time frames for beginning and ending each action. See the four patching scenarios for what those scenarios are.
Start from the inventory
You cannot group what you cannot list. Start with an inventory of assets and the software on them. The groups come from questions such as:
- What does this asset do for the business, and how bad is an hour of downtime?
- Can it be rebooted at will, or only in a window?
- Is it exposed to the internet?
- Who owns it, and who can approve a change?
- Does the vendor still ship patches for it?
A starter set of groups
These are illustrative, not a standard. Adjust them to your estate.
- Employee laptops and phones, patched automatically with a grace period.
- Internet facing servers and services, patched fastest.
- Internal servers with maintenance windows.
- Build systems and developer tooling.
- Special purpose or legacy devices that need a stricter cycle.
- Assets with no vendor patches, which follow the unpatchable plan.
NIST also notes that groups can be defined by other characteristics, such as personnel roles. Pick whatever matches how decisions are made in your company.
Write one plan per group, per scenario
For each group, write down:
- Who gets the canary patch and how long it runs.
- The deadline for routine installs and the date they are forced.
- What happens in an emergency: who approves, how fast, what mitigations are pre-approved.
- What happens when no patch exists.
Keep each plan to a page. A plan nobody reads does not help during an incident.
Keep exceptions rare
NIST says groups should be defined to minimize assets treated as exceptions, but some exceptions are inevitable. Track and review every exception regularly. If several assets share a long-term exception, NIST suggests moving them to a separate group with its own plan. That is the cleanest fix: an exception that repeats is really a missing group. We cover tracking in the patch exception register.
Safeguard's asset discovery and SBOM and dependency scanning can feed the inventory side of this, and policies can encode group rules for builds. The free scan at https://gold.safeguard.sh/scan is a quick start for code.
Quick check
How many maintenance groups should we have?
NIST does not give a number. Enough to separate assets that need different handling, few enough that people can remember them.
Do groups have to match teams or departments?
No. They follow asset characteristics and risk, though ownership matters for approvals.
Sources
Last reviewed: 19 October 2026.
