Help review broadcast on systems patching directive

There is an existing Patch Management Procedure signed by the heads of the various
IT teams including apps teams, Network, Servers, Ops, IT Security : Audit finds the
procedure inadequate to meet local regulatory requirement and I'm broadcasting it
as a way to supplement this.

Calling individual meetings after the broadcast is what I have in mind.
There's quite a few lapses & audit issued faults (& certainly hold IT Compliance
partially accountable for these lapses).

Thanks for suggesting strong words like "shall" etc

Good there is a regime and it is better if you can even include reference to portal or link on the SOP documented.

The briefing as follow up is good and that can be included as well in the comms.

The use of 'shall' and 'must' are necessities from compliance angle compared to 'should' or 'may'. Discrete timeline is recommended otherwise broad open term like regularly can have different benchmark.. One note is the timeline should commence based on patch availability.

revised as follows:

"
IT Teams,

For your attention and compliance:

Please review monthly the availability of patches for the respective products under your care via the appropriate channels including products

The patches covered shall include functional, security and non-security patches.  The platforms covered include  but is not limited to server, host and workstation OS, applications, appliances or devices firmwares/microcodes/IOS

Assess if the patch is applicable to the products under your support within 5  working days from the patch release date and document this assessment, its risk rating plus the source (such as the principal’s url/link that publish the patches) in a tracking sheet as it may be required for audit

Maintain a patch register and update it within 3 working days after patching to facilitate tracking : this is an auditable item.

If you are unable to patch within the stipulated lead time after the release of patches, you are required to raise an SR with relevant  approvals to seek extension or to seek permanent exemption if the patch is known to cause issues with no known solution.

In instances where upgrades or new releases are required to address the issues published (ie no patch is available), do plan out a timeline to perform the upgrade

To minimize issues arising from patching, do test out  patches in development, SIT/UAT before rolling out to production  environment.  Obtain downtime (or if the downtime request is declined, an email to this effect) officially in email where required.

By adopting good patching practices, systems will be better protected against disruptions, undue risks, sub-optimal performance (eg: due to malicious attacks, bugs, malfunctioning or sub-optimal resource handling) which will reduce audit and regulator’s findings.