How to Formalize Your Vulnerability Management Program

March 22, 2022 | By IANS Faculty

A vulnerability management framework is necessary for providing structure and focal points to properly address ongoing information risks. Documenting specific standards and policies, ensuring proper execution of the necessary steps, and keeping the right people on board with vulnerability management initiatives is the recipe for success. Most importantly, it all takes time and diligence. This piece presents the areas to consider when formalizing a vulnerability management program and offers guidance for getting it right. 

Basics of Vulnerability Management 

A healthy vulnerability management program both sets expectations and ensures ongoing oversight. The standards, policies and procedures needed vary depending on specific risks and organizational needs. 


Standards are aspects of a vulnerability management program that involve specific approaches and configurations that are “standardized.” At a minimum, this should include: 

  • Systems and applications in scope. 
  • Tools used for vulnerability scanning and penetration testing, security intelligence and patch management. 
  • Asset criticality ratings defining the relative importance of specific hosts, applications and information, with efforts focused initially on the most critical assets. 
  • Vulnerability ratings, ideally unique to the specific business’s needs, which will likely focus on “criticals” and “highs,” rather than simply going with vendor recommendations and/or addressing everything at once. These should include: 
    • Vulnerabilities creating tangible business risks. 
    • Flaws requiring further penetration testing. 
    • Weaknesses that can be considered acceptable. 
  • Vulnerability metrics that help measure areas such as exploitability, tangible risk and compensating controls. 
  • Information included in technical reports shared with technical team members (i.e., DevSecOps and network administrators) and summary reports to management. 


Policies are documented rules that leverage the standards and outline what must be done to effectively manage identified risks. These include: 

  • Schedule/cadence for vulnerability scanning and manual testing, such as weekly, monthly or quarterly. 
  • Allocation of compensating controls, such as firewall rules, patch management or endpoint protection when necessary. 
  • Follow-up patching requirements that address “criticals” in a certain number of days, “highs” in a certain number of days, and so on. 
  • Reporting testing and remediation results to stakeholders. 
  • Remediation testing to determine which of the previously identified flaws have been addressed. 
  • Requirements for outside parties involved with vulnerability testing or oversight, such as testing tools and methodologies used. 


Procedures are the implementation of security standards and policies and are unique to each organization. You should document your procedures, along with the associated standards and policies, and store them so they are readily accessible to all team members. 

Vulnerability Management Lifecycle Considerations 

Vulnerability management is not a one-time exercise. Vulnerability scanning, additional penetration testing (when required) and remediation must be carried out on a periodic and consistent basis. 

The core element of vulnerability management is identifying specific areas of weakness – the focal points – that must be addressed to provide the greatest return to the business. A vulnerability management lifecycle is often made up of the following components: 

  • Scanning 
  • Manual testing 
  • Risk analysis 
  • Patching 
  • Reporting 
  • Follow-up/success measurement 

The end goal should be to minimize vulnerabilities and risks to a tolerable level, and nothing more. Those who strive for perfection in vulnerability management end up realizing fewer benefits than those who focus their time, money and efforts on their highest payoff tasks. 

Staffing Considerations 

Success is typically achieved using dedicated resources (where possible) for each of the lifecycle tasks above. Some find getting system owners/administrators involved in the risk analysis process and remediation efforts works well. Others don’t, and see little success in doling out the responsibilities of risk analysis and remediation, especially to staff members outside of IT who might have less security buy-in.  

Tooling Considerations 

Using risk analysis capabilities from an outside provider can help streamline efforts and keep costs to a minimum. However, such a tool might not provide all the functionality needed. A third-party risk analysis tool from a vendor may need to be used. 

Dedicated risk analysis tools can help with asset classification, overall risk analysis and integration with other tools that might be used for vulnerability testing. This additional functionality and insight often helps enterprises take their vulnerability management program to a more advanced stage, where they can focus on risk, rather than simply addressing individual vulnerabilities uncovered by a single vulnerability scanner time and again. 

The best way to determine whether a third-party risk analysis tool is needed is to look at how existing vulnerability management efforts are working and, specifically, which blind spots still exist. Identifying these gaps and opportunities can provide information on whether existing tools and processes can be adjusted to accommodate, or if a third-party tool is the only way to meet specific needs. 

READ: How to Coordinate CTI and Vulnerability Management

Vulnerability Management Remediation 

Issues in the remediation (patching) phase of vulnerability management often leave critical vulnerabilities present on the network for extended periods of time. For example, teams often try to patch too many systems at once or focus on patching vulnerabilities that might not need attention compared to other, more urgent findings. In the event of an incident or breach, these issues might be considered indefensible.

Criticality ratings must be created for systems and information assets, as well as the vulnerabilities themselves. For operating systems, it’s easy to assume all patches should be applied across the board, regardless of the urgency of the vulnerability, importance of the asset or related contextual information. However, this ends up creating distractions and unnecessary work that can negate any benefits of vulnerability management efforts. 

Common goals for operating system patch deployment are as follows: 

  • Criticals: Within 7 days, sometimes up to 30 days. 
  • Highs: Within 30 days, sometimes up to 60-90 days. 
  • Mediums: Within 60-90 days, if ever (initial and, perhaps, ongoing efforts will likely not include these vulnerabilities). 

These timelines should not be arbitrary, nor should they be set in stone. Risk tolerance and patching resources dictate what is best for the business, and that may change over time. 

Consider using an enterprise patch management tool. Another important consideration is whether the patch management tool supports software patching for third-party vulnerabilities involving Adobe Reader, Chrome, iTunes and the like. Vulnerabilities impacting third-party software often create greater risks than those impacting the operating system itself. 

Communicating Vulnerability Management to Management 

One of the biggest barriers to strong vulnerability management and the success of the overall information security program is technical staff attempting to take on vulnerability management without the involvement of leadership and other stakeholders. Often, a security committee either does not exist or is not providing direction. This approach ends up creating a false sense of security on the part of leadership, because it assumes all is well, since technical staff are not seeking feedback or involvement. All successful vulnerability management programs must have strong management buy-in. This not only ensures ongoing communication about program efforts, but also keeps stakeholders in the loop and likely more interested in positive outcomes. 

A common challenge is not fully understanding what to report on and how often this information should be communicated. This aspect of vulnerability management takes time to develop, based on experience and feedback from stakeholders. The same goes for system owners and administrators. 

The rule of thumb on what to report and how often is simply to ask. Obviously, what is communicated to technical staff will be different from what is communicated to management. The most important thing is to communicate only what’s necessary. Less is more, especially in the beginning. It’s important to remember stakeholders outside the vulnerability management team might not place the same level of importance on the tasks involved. They might not have the time to manage it either. 

Once vulnerability management efforts are more mature, and stakeholders are getting on board with both what is being accomplished and what is being asked of them, adjustments can be made to ensure everyone is getting what they need and in the proper doses. 

Creating a Vulnerability Management Framework 

Developing a framework can improve your vulnerability management program by helping provide structure and focal points to assist team members and properly address ongoing information risks. To get started: 

  • Get management buy-in: This ensures your program is supported and stakeholder communications is optimized to keep the program on track. 
  • Lay a strong foundation: Put optimal standards, policies and procedures in place. 
  • Focus on lifecycle management: Get the right staffing and tools in place, and ensure the focus is on minimizing risk to a tolerable level, not perfection. 

Although reasonable efforts will be made to ensure the completeness and accuracy of the information contained in our blog posts, no liability can be accepted by IANS or our Faculty members for the results of any actions taken by individuals or firms in connection with such information, opinions, or advice.

Access time-saving tools and helpful guides from our Faculty.

IANS + Artico Search

Our 2024-2025 CISO Compensation and Budget Benchmark Survey is Live!

Get New IANS Blog Content
Delivered to Your Inbox

Please provide a business email.