Before
Patch managers manually reviewed Microsoft release information, identified critical and exploited vulnerabilities, and matched affected products to Windows inventory. They then calculated rings, maintenance dates, freeze exceptions, service impacts, and CAB change details across separate planning steps.
How it works
- Select the Microsoft release, verify that it has not already been planned, and summarize critical updates and known exploited vulnerabilities.
- Match affected products to active Windows assets and service dependencies, then calculate ring assignments, deployment windows, emergency timing, and freeze handling.
- Draft the CAB summary and create a parent change with linked child wave changes containing the approved planning details.
Workflow details
- Release selection and duplicate control: The flow runs on a nightly schedule or on demand, selects the requested Microsoft security release or the latest published release, and checks for an existing active rollout before continuing. Missing releases and already planned campaigns end without creating duplicate changes.
- Security assessment: For each supported product in the inventory, it retrieves critical vulnerabilities, knowledge base articles, corrected builds, and total CVE counts without downloading the entire release dataset. It also checks the relevant period for Microsoft vulnerabilities listed in the CISA Known Exploited Vulnerabilities catalogue and identifies the affected products.
- Inventory and impact mapping: The workflow reads active Windows configuration items, their product versions, owning teams, departments, locations, maintenance windows, and dependent services. It groups systems into deployment waves based on ring and responsible team, while omitting releases that affect no in-scope systems.
- Deterministic rollout planning: Fixed rules assign systems to pilot, office and warehouse, store, or production rings with defined deployment timing. Zero-day exposure accelerates affected rings and creates emergency changes; deployment windows that overlap a change freeze are moved before the freeze when possible, or marked for CAB exception review.
- Change preparation and handoff: The flow drafts an executive CAB note, creates a parent change containing the release rationale and calendar, creates child changes for each wave with configuration items, services, dates, implementation, rollback, and test plans, then links the children to the parent and returns the rollout summary.
What changed
The release-to-change planning process now produces a consistent rollout structure in one run. Duplicate campaigns and releases with no affected assets are filtered automatically, while zero-day acceleration, freeze moves or exceptions, affected services, rollback plans, and parent-child change relationships are prepared before CAB review.
Work removed
Manually reading release data, checking exploited-vulnerability lists, counting affected product CVEs, matching products to configuration items, grouping assets by team and ring, calculating deployment dates, checking freeze conflicts, copying affected services into changes, and drafting the CAB summary.
Expected outcome
Each applicable release produces a repeatable, review-ready deployment plan; in the documented demonstration, the flow prepared 12 waves covering 827 configuration items, a workflow output rather than a measured savings claim.
