I got a chance to support Enterprise patching in a NERC environment. Not fun. Yes, the actual patching took minutes (unless they were dot-net patches which took forever!) but the documentation associated with SOX (Sarbanes–Oxley) and NERC was a nightmare.
Basically, you had to take a “pre” snapshot of every device to be amended - times 1-2K devices. Then you had to analyze the patch library and cull the non-applicable ones (NOTHING goes on a NERC-governed computer that hasn’t been fully vetted as necessary!). This list of recommended patches largely came from Microsoft, but also included firmware updates and 3rd party updates. Then comes patch testing - every month every patch has to be tested for compatibility. Another snapshot has to be done of the test-patched machines so that an analysis of potential compromises in security have not been introduced.
Mitigation takes place on any non-compliant patches. Results of these analyses goes to a board that makes a determination of need (yea or nay to go ahead and include a particular patch or patches).
Once completed, Change Control requests are prepared and submitted. The CC board studies the requests and approves the schedules for implementation. Conflicts in scheduling are resolved (for instance the owner of a particular server has scheduled the same time slot for upgrade of an application or hardware modification/repair). Alternate dates are hammered out and posted.
The patch team then implements the various patches. Following that another snapshot is taken of every patched machine and analyzed for compliance. Requests are forwarded to the server team for machines that reported patching issues.
Keep in mind that some of these steps pertained only to NERC machines. but also keep in mind that there were separate support teams for standard production servers, test servers, and NERC servers.
I spent an incredibly short time (a 1-week project) in a NERC environment. I do not envy the admins there.