Patch decisions need an operational context.

Establish whether the issue applies

Record the advisory source, affected product and version, the assets that match it, and the date of the assessment. Confirm applicability with the supplier where necessary. A product-family match is a starting point, not proof that a particular installation is affected.

Review the consequence of action and inaction

Include operations, engineering, maintenance and security. Consider the credible effect of exploitation, the connectivity of the asset, the process it supports and the existing safeguards. Also assess the change itself: compatibility, timing, redundancy, support conditions and the consequences of failure.

An unavailable patch does not end the review. Document possible compensating measures with an owner and review date. They might involve changing an access path, reducing unnecessary connectivity or improving monitoring. Their suitability depends on the actual system; this page does not authorise a configuration change.

A decision record

Test the restoration path

A backup file and a restore capability are different things. Check which project files, software, licences, keys and supplier support are necessary. Agree the conditions under which the change will be stopped or reversed. Retain the result of the post-change checks with the change record.

Keep deferred decisions visible

Record who accepts a deferred action and when it will be revisited. Reassess when the threat information, exposure, vendor advice or operation changes. Avoid a permanent queue of unowned exceptions. The objective is a defensible treatment decision and a review mechanism, not a promise that every patch can be installed immediately.

Start with the asset inventory guide; read the original OTCSA vulnerability-management paper and use the workbook to capture the next action.