Patch Management Policy

I have to create a patch management policy for our clients. Just wondering if you guys have any general ideas or advice?

Find more posts tagged with

SAVE $250 on Your Boot Camp — Use Code "EXAM26"

Exclusively for TechExams members for Infosec Boot Camps starting before April 30, 2026

View Boot Camps

Comments

N2IT

Was it a proposal or you just flat out created it? I would think you would/should discuss this with your clients before it "goes live".

Just my thoughts. I created a patch management release plan for the Linux/Unix boxes at my last position. It was high-level and needed their sign off before we started to discuss the fine details about the plan.

paul78

A couple of things to also think about in the policy:

1) who approves
2) how often patches must be deployed I.e - patch cycle
3) are there different classifications of patches (emergency patches, compliance patches) - for example - if a patch is for a invulnerability with exploits-in-the-wild with high impact - does it go in mid-cycle.
4) what level of testing is required prior to deployment
5) Monitoring for new patches - who does it
6) Release communications - what stakeholders need to be notified.
7) Maintainence windows - for example - if a patch requires a reboot, will it be deployed diffirently.

Compliance monitoring - how do you track that patches are deployed - is there an automated scanner that will be used to do out-of-band validation
9) Post-deployment testing - what testing is done after a patch is deployed.

4_lom

4_lom wrote: »

I have to create a patch management policy for our clients. Just wondering if you guys have any general ideas or advice?

I was assigned the task of creating it. My current proposal does heavily involve client decisions. I was just asking for general ideas regarding patching schedules, guidelines, etc. Just general ideas...

ChooseLife

paul's got pretty much all of it covered. One more point (sort of combining #3 and #8 from this list) is that patches of different criticality may have varying, but mandatory deadlines. E.g.
"Critical patches must be installed within 30 days of their release"
"Non-crititical patches must be installed within 90 days of their release"

afcyung

NIST does a great job of putting out pubs for various INFOSEC topics. The below is patch/vulnerability management.
Paul hit the major points.

http://csrc.nist.gov/publications/nistpubs/800-40-Ver2/SP800-40v2.pdf

paul78

4_lom wrote: »

My current proposal does heavily involve client decisions.

You may want to reconsider having customers involved in the decisioning process for patching. What type of business you are in can also influence the level of involvement that customers can play.

For example, if your business is providing an ASP solution, I recommend not involving any customer. Customers should be "inform" only for emergency patches that occur outside a standard maintainence window or if patch review has high risk of adverse impact. All other patches can be standard operating procedure. You can have a policy item that states that customerr contracts have provisions for standard maintainence which include patching. This limits issues with competing customer requirements on patch scheduling.

If your business is to provide managed infrastructure at customer sites, you can include the customer in decisioning but just be sure that your contracts allow for liabilty waivers if customers are not responsive to security patching requests.