Vulnerability and Patch Management Standard

1 PURPOSE

This Standard outlines the requirements for identifying, assessing, prioritizing, remediating, and monitoring vulnerabilities for the University System of New Hampshire (�鶹��ý��Ƶ). By providing specific criteria and roles, this Standard ensures that vulnerabilities are remediated in a risk-informed way that is consistent with institutional policies and that serves the security and compliance needs of the �鶹��ý��Ƶ.

2 SCOPE

This Standard applies to all �鶹��ý��Ƶ-owned or managed technology resources connected to the �鶹��ý��Ƶ network. It encompasses the processes and responsibilities associated with vulnerability identification, assessment, and remediation. This includes, but is not limited to, endpoints, servers, network devices, web applications, and cloud-based systems.

3 STANDARD

�鶹��ý��Ƶ (ET&S) shall develop and maintain a systematic vulnerability and patch management program to enable a proactive cybersecurity posture. The program shall identify vulnerabilities and prioritize, as well as continually remediate, risks in institutional information systems through the implementation of the following activities. ET&S shall oversee enforcement actions and support remediations.

3.1 Vulnerability Reporting and Scans

3.1.1 The program shall ensure timely visibility and reporting of vulnerability data to system owners and relevant leadership

3.1.2 Vulnerability reports shall include vulnerability details, severity ratings, and remediation recommendations.

3.1.3 Wherever feasible, vulnerability management tasks shall be automated to increase efficiency and consistency.

3.1.4 All applicable �鶹��ý��Ƶ information systems shall:

have ET&S-approved Vulnerability Management technology installed
have reporting enabled
undergo internal and external scans at least quarterly

3.1.5 Web Application and SaaS Application scans

All web applications shall be scanned at least monthly using ET&S-approved scanning technologies.

In addition, all vulnerabilities reported by Software-as-a-Service (SaaS), Platform-as-a-Service (PaaS), and Infrastructure-as-a-Service (IaaS) vendors shall be acknowledged and addressed by the respective managing team in accordance with this standard.

3.1.6 Reporting

Vulnerability reporting is classified as restricted data and shall be stored in a secure centralized depository.

3.2 Vulnerability Remediation

3.2.1 Prioritization
�鶹��ý��Ƶ shall use the Vulnerability Priority Rating (VPR) as the primary method for determining the urgency and sequence of vulnerability remediation efforts.

�鶹��ý��Ƶ may also consider and, where appropriate, defer to vendor recommendations when prioritizing and applying patches or addressing vulnerabilities.

All vulnerabilities shall be remediated in accordance with the timeframes defined in this standard.

Patches shall be deployed at times to ensure minimal disruptions to university operations when possible. “Whenever possible, Patches should be implemented at times that are least disruptive to university operations.”

Research Labs may request a manual patch schedule through the exception process that differs from the schedule below to avoid interference with operations.

3.2.2 Vulnerability Classification
Vulnerabilities shall be classified by severity using standardized risk levels: Critical, High, Medium, or Low. All Critical and High vulnerabilities impacting �鶹��ý��Ƶ information systems shall be remediated per the timelines defined in this standard. If remediation cannot be completed within the required timeframe, an exception shall be submitted per Section 3.4.4.

3.2.3 Remediation Timeline
The remediation timeline begins upon validation and classification of the vulnerability.

VPR Range	Qualitative Equivalent Severity	Remediation Requirement
9.0 – 10.0	Critical	Remediate within 30 days
7.0 – 8.9	High	Remediate within 30 days
4.0 – 6.9	Medium	Remediate within 90 days
0.1 – 3.9	Low	Monitor and address as necessary

3.2.4 Exception impact on remediation timeline

If an exception request is submitted before the remediation deadline, the timeline may be paused pending review. If the exception is denied, the remediation clock resumes from the date of notification.

3.2.5 False Positive Reporting
If a user believes a reported vulnerability is a false positive, they can submit supporting evidence through a service ticket and request a review via the . During the review period, the remediation timeline is paused. If the finding is validated, the timeline resumes from the date the requester is notified of the determination.

3.2.6 Unpatchable Vulnerabilities
If a vulnerability cannot be remediated through standard patching, an exception request shall be submitted under Section 3.4.4.

3.2.7 Change Management

All patching shall follow the �鶹��ý��Ƶ change management process.

If there is a need for an emergency remediation, ET&S may bypass standard processes by submitting an emergency change ticket to mitigate urgent "Zero-Day" vulnerabilities.

3.2.8 Patch Validation
Following the application of security patches or alternative remediations, system administrators shall verify that the vulnerability has been successfully resolved. This may include post-remediation functional testing. Validation ensures that changes are effective and do not introduce new risks to the confidentiality, integrity, or availability of �鶹��ý��Ƶ technology resources.

Validation activities shall be documented to ensure accountability, traceability, and compliance with applicable regulations.

System administrators shall maintain a patch register to document all applied patches, including system name, patch identifier, date applied, validation results, and responsible personnel.

3.3 Reporting and Metrics

3.3.1 Monthly performance metrics shall be maintained to evaluate the effectiveness of the �鶹��ý��Ƶ vulnerability and patch management program. These metrics shall include, but are not limited to:

Vulnerability detection metrics
Mitigation and remediation metrics

Coverage metrics

Timeliness metrics

Risk-based prioritization metrics

Trend analysis and program maturity indicators

3.4 Noncompliance, Exceptions, and Enforcement

3.4.1 Vulnerabilities with a Vulnerability Priority Rating (VPR) of 7.0 or higher (Critical or High) that remain unresolved more than 30 days after detection, and without an approved exception, will be escalated to senior leadership. ET&S shall notify the responsible System Administrator, Service Owner, and/or Supervisor.

3.4.2 As part of the Barricade vulnerability management cycle, ET&S Cybersecurity Operations and Engineering will, on a 30-day basis, generate and distribute reports identifying systems with unresolved vulnerabilities rated VPR ≥ 7 for more than 30 days. Departments unable to meet remediation timelines must submit an exception request in accordance with Section 3.4.4.

3.4.3 If a system continues to pose risk without remediation or an approved exception, the �鶹��ý��Ƶ CISO may initiate risk mitigation measures. Such actions may include:

Directing system owners to submit a formal exception request,

Requiring documentation of compensating controls or,

Authorizing the isolation or disconnection of non-compliant systems from the �鶹��ý��Ƶ network, with appropriate documentation.

3.4.4 Exceptions

Temporary exceptions may be granted for enterprise systems that face operational constraints, such as limited maintenance windows, extended testing requirements, or vendor-delayed or unscheduled patch releases. Exception requests shall demonstrate due diligence in attempting remediation and clearly articulate the justification for the delay. For additional details, refer to the, the corresponding , and the.

4. Roles and Responsibility

4.1 CISO

The CISO shall be responsible for the vulnerability and patch management program, approve cybersecurity exception requests, authorize emergency and high-impact enforcement actions to protect �鶹��ý��Ƶ assets, ensure stakeholder notifications during urgent remediation efforts, and approve system quarantine, isolation, or shutdown when necessary.

4.2 Cybersecurity Governance, Risk and Compliance (GRC)

Cybersecurity GRC shall manage the exception process, review and collaborate with the CISO on exception approvals, support departments in documenting valid exceptions, conduct risk assessments, and ensure all exception activities comply with the �鶹��ý��Ƶ Cybersecurity Exception Standard.

4.3 Cybersecurity Operations and Engineering (Cyber Ops)

CyberOps shall manage the vulnerability and patch management program; maintain vulnerability reporting tools; notify system owners of identified vulnerabilities through the Barricade process; issue the Over 30-day Report and initiate enforcement actions such as isolating or disconnecting systems with CISO approval when necessary; and provide general consulting.

4.4 System, Service, and Application Owners

System, Service, and Application Owners shall review and act on vulnerability and patch notifications for the systems, services, and applications they own, ensure remediation is completed within the timelines defined in this Standard, initiate and participate in the approved exception process when deadlines cannot be met, implement corrective actions directly or through assigned System Administrators, and support overall compliance with vulnerability response requirements.

Document History

Approved by: Thomas Nudd, Chief Information Security Officer, 30 September 30, 2022
Reviewed by: Dr. David Yasenchock, Director Cybersecurity GRC, September 29, 2022
Revision History:
- Revised formatting, K Sweeney, 22 July 2023
- Revised formatting, K Sweeney, 30 MAY 2024
- Revised formatting, Cybersecurity GRC, 13 July 2025
- Updated to v2.6, Cybersecurity GRC, 5 November 2025