Skip to content

Patching Policy

Authorized By: Chief Information Security Officer (CISO)

Prompt and complete patching is critical to defending against attacks. Most cyber attacks target systems with known, unpatched vulnerabilities. All Safire systems-endpoints, servers, network devices, applications, and mobile devices-must be patched against the latest security vulnerabilities to protect Safire data, systems, and networks.

This policy applies to all Safire employees, contractors, and third parties accessing Safire’s systems, networks, and data. It applies to all Safire-owned assets and any personal devices (BYOD) strictly authorized to connect to the secure network.

While everyone plays a role in keeping Safire patched, responsibilities differ by function:

  • All Users: Do not ignore auto-update notifications on workstations and, where applicable, mobile devices that access Safire email or business applications. Once prompted, users must allow updates to install within 24 hours.
  • IT Department: Responsible for monitoring patch releases, testing, and deploying updates to infrastructure, servers, and endpoints.
  • System Owners: Responsible for coordinating maintenance windows with IT to ensure business-critical systems can be patched without unplanned downtime.
  • Automation: Employee workstations (laptops/desktops) and low-impact devices (printers) shall be configured by IT to apply security patches automatically .
  • Vendor Selection: When selecting software or cloud services, preference must be given to vendors with robust, transparent patching policies .
  • End-of-Life (EOL) Software: Software or operating systems that are no longer supported by the vendor (receive no security patches) must be removed from the network or strictly isolated (air-gapped).

Critical Timelines (Service Level Agreements)

Section titled “Critical Timelines (Service Level Agreements)”

IT and Compliance are responsible for adhering to the following timelines for vulnerabilities based on their severity (e.g., CVSS Score):

  • Emergency / Zero-Day (Active Exploitation): Patches must be deployed within 48-72 hours of release.
  • Critical Severity: Patches must be deployed within 14 days of release.
  • High Severity: Patches must be deployed within 30 days of release.
  • Medium/Low Severity: Patches should be deployed during the next scheduled maintenance window or quarterly.
  • Testing: Patches for servers and business-critical devices (e.g., manufacturing equipment) shall be tested in a simulated/“sandbox” environment prior to production deployment to ensure business continuity.
  • Scanning: Compliance will perform vulnerability scans at least monthly (and after major changes) to verify that patches have been successfully applied.

If a security patch cannot be installed due to business compatibility or legacy constraints, the following process applies:

  1. Notification: The System Owner must notify the CISO immediately.
  2. Mitigation: IT must implement compensating controls (e.g., network segmentation, firewall rules) to reduce the risk of the unpatched vulnerability.
  3. Approval: The acceptance of the unpatched vulnerability and the sufficiency of the compensating control must be documented in a Plan of Action and Milestones (POAM) and approved by the CISO.

The policy owner will verify compliance through automated vulnerability scanning tools, patch management reports, and internal audits. Oversight is provided by CISO, IT, and Compliance functions. Enforcement of this policy is coordinated through Human Resources and Executive Management.

Any exceptions must be approved by the Policy Owner in advance.

For any unpatched assets identified during scans that exceed the mandated timeline, the CISO is authorized to immediately remove those assets from the network. Employees tampering with or obstructing the patching of assets shall be subject to disciplinary action, up to and including termination of employment.

Section titled “Related Standards, Policies, Plans, and Procedures”
  • Risk Assessment Policy
  • System and Network Security Policy

Revision History

2026-08-20 — Darren Rush
Merge pull request #2 from safire-dev/dev (16cb681)
Edit this Page