Vulnerability Management Standard for Information Technology


University of North Carolina at Chapel Hill Information Technology Standard for Vulnerability Management



Vulnerability Management is the activity of discovering, preventing, remediating, and controlling security vulnerabilities: 1) through routine patching of system components, 2) patching or remediating vulnerabilities identified by network, systems, and application scanning, and 3) addressing vendor-identified or other known vulnerabilities through compensating controls or other methods. Managing system vulnerabilities in a timely fashion is key to the protection and security of, and continued access to, University data and other resources.

Scope of Applicability

Components of IT services in which vulnerabilities routinely occur including on-premise or cloud hosted servers, middleware and other underlying application infrastructure, and client-facing application systems are in scope. 

For “Cloud” systems, consult the contract terms to determine allocation of responsibility for Vulnerability Management. Typically hosted “Software as a Service” (SaaS) applications will have most Vulnerability Management activities provided by the vendor, unless these responsibilities explicitly rest by contract with the University. (However, configuration and access management, encryption, and other applicable responsibilities still apply.) “Platform as a Service” (PaaS) and “Infrastructure as a Service” (IaaS) are likely in scope for this Standard unless responsibility for vulnerability management is explicitly allocated by contract as a vendor responsibility. Any questions on this allocation of responsibility can be settled by an Information Security Risk Assessment.

Every system which does or might be used with Tier 2 or Tier 3 data or which is considered “mission critical” (including infrastructure supporting applications and services determined to be Mission Critical and covered by business continuity requirements) must have one or more identified responsible parties able to ensure compliance with this Standard, which might include patching or other remediation responsibilities. This Standard applies to all responsible parties or those in a role likely to make them a responsible party. Traditionally this would be a “system administrator” for servers, for a web application it might be an application administrator, for a database it might be a database administrator, or even a service owner or business/functional individual for other types of IT services. Non-traditional roles should be considered when the service is a third-party system which might be managed by non-IT staff.


The Chief Information Security Officer (CISO) has the authority to take action, with appropriate communication with system owners in advance, to ensure that un-remediated systems do not pose a threat to University information resources. Drastic actions such as blocking systems from the campus data network shall require the joint approval of the CISO and Chief Information Officer (CIO) (or in their absence, CISO/CIO delegates).

All of the following must be patched on an appropriate schedule and, as feasible and determined, scanned in a fashion and on a schedule appropriate for the risk profile of the assets, regulatory requirements, and availability of scanning resources: University network infrastructure; servers; operating systems on virtual machines; cloud-hosted virtual machines, images, or containers; database servers; database servers; databases; applications; and comparable services and systems. Discovered vulnerabilities must be remediated. See below for more detail.

Cloud Systems

Platform as a Service and Infrastructure as a Service

Infrastructure as a Service (IaaS) almost always puts Vulnerability Management responsibilities fully on the customer. Platform as a Service (PaaS) may share responsibilities between provider and customer. Units contracting for such services for use with Tier 2/3 data or for mission-critical systems must register them in System Administration Initiative (SAI) unless an exception applies.

Software as a Service

Typically responsibility for vulnerability management of SaaS systems will rest with the vendor. If that is known not to be the case, the unit contracting for the service must plan prior to implementation and on an ongoing basis for vulnerability management based on the specific environment and service context. Note, such planning may require procurement of specific tools in the environment, which should be accounted for early in the project. This includes proper configuration management in keeping with access control and other security controls requirements and constraints. If upgrades are optional, those should be in operational plans at appropriate intervals to address vulnerabilities effectively.

Costs can be challenging to predict. Projects and uses must be considered on a situational basis and vulnerability management commiserate with risk must be planned for, included in project costs, and implemented by the provider or a UNC responsible individual, or some combination of both.

Third-party Applications

Software in use at the University must be obtained as required by University procurement and vendor management requirements, configured with appropriate consideration of vulnerability management, and maintained appropriately to the risk of its environment and use. Systems being scanned as part of the SAI program may have some application scanning done normally.

Scanning and Remediation

Where feasible and required, scanning should occur on a scheduled basis, and identified vulnerabilities addressed in a timely way considering “level” of the vulnerability, availability of patches, specific data types involved, and overall risk-based prioritization.

Applications handling Tier 3 data must be scanned and vulnerabilities timely remediated if a purpose-built vulnerability scanning tool is available unless an exception is allowed. Additional assessment and testing (such as penetration testing) may be required by law or policy for specific data types, or by the ISO in order to achieve an approved Tier 3 Security Risk Assessment.

Applications in use with Tier 2 data should be scanned if feasible and vulnerabilities timely remediated based on priority, taking risk and specific use of the application into consideration. Scanning may be required by the ISO in order to achieve an approved Tier 2 Security Risk Assessment.

It is a good idea to scan applications with Tier 0 or Tier 1 data, (it is required if they are mission-critical) or if there are concerns for data integrity. When implementing an application, configuration management should be a priority and vulnerability management planning should occur.


Software in use at the University is required to be supported (have at least security patches available). Routine patching must occur on a planned basis appropriate to the risk. If routine patching in environments where the University controls the patch or upgrade process is to occur less than quarterly, an ISO exception is required.

In-House “Homegrown” Applications

Vulnerability management for homegrown applications is challenging. Tools available include repositories that check for known vulnerabilities in code libraries (GitLab, Azure, GitHub, and Google all have such services available). Scanning Dev and Test systems with server scanning tools (such as those available for use through SAI) can identify some application vulnerabilities such as outdated or vulnerable libraries. Secure application development practices can prevent many vulnerabilities from occurring at all. For mission critical or Tier 3 systems, third-party assessment and penetration testing is an option. Vulnerability management (including library management) planning is required for applications developed in-house. That planning must be documented and processes created and followed for applications impacting Tier 2 or 3 data. Unit ISLs should work with the ISO to understand what tools and resources may be centrally available, but units developing in-house should consider security costs such as Vulnerability Management to be a routine operational expense.

System Administration Initiative

The Systems Administration Initiative (SAI) is a mandatory monitoring program for UNC-Chapel Hill systems (servers, appliances, network devices, and Cloud Platforms and infrastructure) that host sensitive information and/or are designated as mission critical.

Individuals who are responsible for campus resources within the scope of SAI must register and receive training. This includes individuals who “inherit” responsibilities, or who have them “informally” rather than as part of their job description or performance plan. Systems within scope must be registered and (by default) enrolled for scanning unless an exception applies.


If any of the following job duties are within your scope of responsibility or if these descriptions apply to you, you are required to register with SAI and complete the applicable training.

  • You are a systems administrator with direct responsibility for installing, configuring, or patching Operating Systems on servers (on-prem, PaaS, or IaaS servers), or network devices (routers, switches, security appliances, storage servers/appliances, or similar systems)
  • You are the only application administrator or the designated responsible person for a multi-user application system. Where multiple Application Administrators exist for a single system, each is responsible for ensuring that one is designated as the SAI responsible person. Application Administrators for SaaS applications for which vendors are wholly responsible for scanning and patching are excepted.
  • You coordinate or are a liaison for an external contractor or OEM that supports on-prem applications.
  • You are a Database Administrator or similar infrastructure/middleware manager with direct responsibility for installing, configuring, or patching platform applications. 


Systems designated by the Information Security Controls Standard as requiring SAI participation must be registered with SAI. The most appropriate individual (systems administrator or similar) for a given server must register the device and engage with the program to ensure compliance. Responsibility for driving this compliance stems from the top executive of any unit.

SAI Engagement

Systems enrolled in SAI must be available for authenticated or agent scans unless an exception is granted (see SAI program documentation for the process to apply for exceptions).

Timelines for scanning and for remediation of identified vulnerabilities are established by the SAI Program based on severity levels, availability of patches, and risk.

Patching identified vulnerabilities within the SAI timelines is required unless the responsible individual applies for and is granted an exception.

Grace periods are intended to address the wide differences in system context that affect ability to patch, but they are not intended to extend the actual timelines.

Systems that routinely cannot be patched on the SAI timeline should be submitted for a blanket exception.

Patching of higher-severity vulnerabilities must be a priority for units, while patching of lower-severity vulnerabilities may occur on the longer timelines provided.

Repeated delays in patching the same systems may be addressed by the CISO or ISO staff with unit management. Often this can assist in shedding light on resource constraints or the importance of managing vulnerabilities. In some cases however, these situations may trigger a requirement for additional training of responsible individuals or in the case of serious lapse(s), employee may be referred for performance management action by the unit.

In cases where persistently unpatched systems present a threat to the University computing environment, the CISO and CIO may determine that the system must be managed by another entity (a commercial contract, ITS or another campus unit, or another responsible individual within the original unit), with the original unit bearing the cost of that support. Or the system may be taken offline until the vulnerabilities are addressed and a plan is in place for ongoing maintenance.


Systems that cannot reach other campus devices and cannot reach the Internet are excepted from these requirements.

Individual systems or groups of systems using documented ISO-approved compensating controls may be granted exceptions to specific parts or all of this Standard.

Routine exceptions to scanning or remediating vulnerabilities are handled through the SAI “VPR” exception process. This process includes ISO staff and peer systems administrators from campus units reviewing requests and determining scope of exceptions.

Frequency of patching, scanning, or time to remediation exceptions for SAI or non-SAI systems and applications may also be made by the ISO based on consideration of compensating controls, nature of the system in context (patch windows, frequency of vendor patch releases, potential impact of a breach, etc.) and availability of technical resources.

The CISO and their designated staff member(s) may make exceptions in writing to any part of this Standard.

Specific guidelines regarding compensating controls, developed in collaboration with internal University committees and the CISO, may make exceptions to the requirements specified in the UNC-Chapel Hill Standard for Vulnerability Management. These exceptions will balance the requirements of this standard with potential negative impact to the mission of the University.


Software as a Service (SaaS): The capability provided to the consumer is to use the provider’s applications running on a cloud infrastructure. The applications are accessible from various client devices through either a thin client interface such as a web browser (e.g., web-based email) or a program interface. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.

Platform as as Service (PaaS): The capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages, libraries, services, and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage, but has control over the deployed applications and possibly configuration settings for the application-hosting environment.

Infrastructure as a Service (IaaS): The capability provided to the consumer is to provision processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, and deployed applications; and possibly limited control of select networking components (e.g., host firewalls).

Mission Critical: A system so critical to the mission of the UNC-Chapel Hill business unit that any incident requires immediate response. If a system is deemed mission critical by the department, then contact and escalation information has been provided for the system in advance of any incident or outage. The owning business unit determines whether a resource is mission critical. Once designated as mission critical, heightened information security policies and standards apply in an effort to assure that the resource remains available. If a business unit does not designate a resource as mission critical, that resource may not be a priority for restoration of services in the event of an incident or outage.

Responsible Individual: Individual with a role in Vulnerability Management for a specific system. If a system is in scope and no Responsible Individual is designated, it is assumed to be any system or application administrator.

Sensitive Information: Information classified as Tier 2 or Tier 3 in the UNC-Chapel Hill Information Classification Standard.

System Administration Initiative (SAI): Program through the Information Security Office to provide training to administrators and to manage vulnerability scanning for covered systems.

Vulnerability: Weakness in an information system, system security procedures, internal controls, or implementation that could be exploited or triggered by a threat source.

University Constituent: UNC-Chapel Hill faculty, staff, students, retirees and other affiliates, contractors, distance learners, visiting scholars and others who use or access UNC-Chapel Hill resources.

Related Requirements

External Regulations and Consequences

Failure to comply with this standard may put University information assets at risk and may have disciplinary consequences for employees, up to and including termination of employment. Students who fail to adhere to this standard may be referred to the UNC-Chapel Hill Office of Student Conduct. Contractors, vendors, and others who fail to adhere to this standard may face termination of their business relationships with UNC-Chapel Hill.

Violation of this standard may also carry the risk of civil or criminal penalties.

University Policies, Standards, and Procedures

Informational Resources

  • The University “System Administration Initiative” (SAI) is a program that trains “Responsible Individual” University staff, who have IT security responsibilities for particular systems, and registers certain kinds of systems for scanning/monitoring/tracking purposes.
  • Many of the topics in this Standard are covered on Training and resources are available to individuals and campus units to support the work of Vulnerability Management.

  • Questions about secure application development and checking of homegrown applications and code can be directed to your unit Information Security Liaison, or the Information Security Office. One source for good background is, A good starting place is their document on using components with known vulnerabilities.

  • For more background on Sensitive Information please go to and search for "Sensitive Information," visit,, or consult the Information Classification Standard

Contact Information

Primary Contacts
Subject Contact Telephone Online/Email
Standard Questions ITS Policy Office 919-962-HELP or
Request Information
Security Consulting
UNC ITS Information Security Office 919-962-HELP
Report a Violation UNC ITS Information Security Office 919-962-HELP N/A
Assistance with
Sensitive Information
Data Governance Oversight Group 919-962-HELP and

Document History

Effective Date: Previous Standards were incorporated in Vulnerability Management Policy dated 30 June 2010. Standalone Standard effective 2/18/2016, signed by the Chief Information Security Officer

100% helpful - 1 review


Article ID: 131251
Thu 4/8/21 9:04 PM
Tue 12/14/21 3:55 PM
Effective Date
If the date on which this document became/becomes enforceable differs from the Origination or Last Revision, this attribute reflects the date on which it is/was enforcable.
12/15/2020 8:34 AM
Issuing Officer
Name of the document Issuing Officer. This is the individual whose organizational authority covers the policy scope and who is primarily responsible for the policy.
Issuing Officer Title
Title of the person who is primarily responsible for issuing this policy.
Vice Chancellor for Information Technology and Chief Information Officer
Last Review
Date on which the most recent document review was completed.
12/09/2021 12:00 AM
Last Revised
Date on which the most recent changes to this document were approved.
12/14/2021 12:00 AM
Next Review
Date on which the next document review is due.
12/13/2024 12:00 AM
Date on which the original version of this document was first made official.
02/18/2016 11:00 PM
Responsible Unit
School, Department, or other organizational unit issuing this document.
Information Technology Services