Skip to main content

Exceptions & Risk Acceptance

Use this guide to manage patching exceptions when systems cannot be patched within standard SLAs due to vendor constraints, legacy application compatibility, or temporary business risk trade-offs.

When to Request an Exception​

Typical reasons for exceptions include:

  • The patch conflicts with a critical application and no fix or workaround is available yet.
  • The system is scheduled for decommissioning and patching is not cost‑effective.
  • Regulatory, contractual, or operational constraints limit when changes can be made.

Exceptions should be rare and time‑bound rather than permanent.

What an Exception Should Capture​

An exception record should include at least:

  • Scope – specific hosts, applications, environments, and vulnerabilities or patches covered.
  • Reason – why hosts cannot be patched within normal SLAs (for example, ASG/EKS membership, inactive Breeze, end-of-life OS, low disk space, or exclusion by tag).
  • Compensating controls – additional monitoring, access restrictions, or segmentation in place to reduce risk.
  • Owner – accountable team or individual.
  • Expiry or review date – when the exception must be re‑evaluated.

In Cloudaware, you can link exceptions to CMDB objects, vulnerabilities, and patch findings so you can distinguish “known and accepted” risk from true non‑compliance.

Reviewing and Closing Exceptions​

  • Review exceptions regularly (for example, monthly or quarterly).
  • Close the exception once the patch can be applied or the asset is retired.
  • Use compliance reports to highlight exceptions that are nearing or past their review dates.

Package Exclusions​

In some cases, you may need to exclude specific Linux packages from patching while keeping the rest of the system in scope. On yum-based distributions, such as RHEL, CentOS, and Amazon Linux 1, you can use the yum-versionlock plugin to lock package versions.

To exclude a package from future updates by locking it to the currently installed version, first install the plugin:

yum install yum-versionlock

This creates the /etc/yum/pluginconf.d/versionlock.list file on the system.

To lock the version of a group of packages, such as the java-* package family, run:

yum versionlock java-*

Packages matching the pattern will be excluded from future upgrades and will not appear in the list of available updates.

Instance-Level Package Exclusions​

If certain instances need to be excluded from the patching process, apply the following tag to the instance: cloudaware:PatchingMaintenance = Exclude.

In this case, patching will not be performed on tagged instances.

Application and Account‑Level Exclusions​

In practice, exceptions are often applied at the application or account level — for example, excluding an entire application stack or a cloud account from a particular patching cycle when the risk of change is too high.

Cloudaware supports excluding whole applications or accounts from patching. Support for excluding individual instances at a finer granularity is under development and validation. Contact Cloudaware support at support@cloudaware.com for the latest capabilities and recommended patterns.