A vulnerability management policy sets the ground rules for the process, minimum standards, and reporting requirements for vulnerability management.
An effective vulnerability management policy can help with the cyclical process of discovering and managing vulnerabilities found within IT hardware, software, and systems. A documented policy enables IT teams to create a trackable and repeatable process that meets the expectations of executives and conforms to compliance requirements.
This article helps organizations of all sizes to start the policy creation process with a fundamental overview and a downloadable template.
- Free Vulnerability Management Policy Template
- How to Create a Vulnerability Management Policy in 4 Steps
- Common Vulnerability Management Policy Sections
- Top 5 Vulnerability Management Policy Best Practices
- How Vulnerability Management Policies Work
- Top 5 Benefits of an Effective Vulnerability Management Policy
Free Vulnerability Management Policy Template
Here is a link to a detailed vulnerability management policy template to help organizations create a vulnerability management policy.
How to Create a Vulnerability Management Policy in 4 Steps
Organizations large and small can create a functional Vulnerability Management Policy by following four key steps:
- Determine the Vulnerability Management Policy
- Verify the Vulnerability Management Policy
- Approve the Vulnerability Management Policy
- Review and Modify the Vulnerability Management Policy
Determine the Vulnerability Management Policy
The person or team drafting the policy will first need to determine the critical rules and steps within the vulnerability management policy. For example some fundamental questions to answer include:
- Who is responsible for the vulnerability management process?
- What assets and systems will be covered by the vulnerability management process?
- What is the priority for vulnerability detection, assessment, and remediation?
- What is the process for vulnerability detection?
- What is the process for vulnerability assessment?
- What is the process for vulnerability remediation?
- How can the vulnerability management process be validated and verified?
- What reports are needed to establish and measure success and compliance for the vulnerability management process?
Don’t know where to start? Write down the current practice. Most IT teams have at least an informal process for obtaining and applying updates and patches, even if they are not written down or monitored.
While updates and patching remain a subset of vulnerability management, it at least provides a starting point for a more comprehensive policy. If the organization already has processes for double-checking configurations for networking equipment or open ports for server firewalls, those can also be added and broadened into a more comprehensive policy that encompasses more IT systems.
This first draft can simply be notes. Formal paragraphs and language can come later after the basic principles have been outlined.
Verify the Vulnerability Management Policy
With the critical rules in place the policy development team should verify the rules against external requirements and practical limitations.
External Vulnerability Management Requirements
Every organization faces general or specific regulations from international, federal, state, or local governments. Additionally, the organization may be forced or choose to comply with compliance frameworks (NIST, PCI DSS, etc.) and industry standards. The policy development team needs to check these external regulations and revise any rule that does not meet the compliance requirements.
Some compliance standards will be broad and vague, others will be detailed or have specific requirements. For example, for the CIS Critical Security Controls, the requirements are broad:
- 7.1 Establish and Maintain a Vulnerability Management Process: Establish and maintain a documented vulnerability management process for enterprise assets. Review and update documentation annually, or when significant enterprise changes occur that could impact this Safeguard.
- 7.2 Establish and Maintain a Remediation Process: Establish and maintain a risk-based remediation strategy documented in a remediation process, with monthly, or more frequent, reviews.
The requirement requires the existence, but does not specify the content or requirements for the vulnerability management process or risk-based remediation strategy.
The credit card industry PCI DSS requirements will be more specific. For example, a restaurant chain may already have a patching process and policy that covers their computers. However, PCI DSS may require vulnerability scanning for a network, evaluation of point of sale (POS) terminals, and periodic penetration testing.
Practical Vulnerability Management Limitations
Most organizations have limited resources and often idealized policies do not take these limitations into account. The vulnerability management policy team should test the proposed rules with the IT team. If an IT team cannot comply with standards and requirements with their current resources, the organization will need to adjust the rules or resources as necessary.
In the restaurant chain example above, perhaps the patch management tool managing the current patch management policy cannot scan for network vulnerabilities or for updates on the POS terminals. The current tool will need to be upgraded or complemented by a vulnerability management tool, service, or penetration testing service that can meet the PCI DSS regulatory requirements.
Also read:
- Patch Management Policy: Steps, Benefits and a Free Template
- Top Vulnerability Management Tools
- Patch Management vs Vulnerability Management: What’s the Difference?
Approve the Vulnerability Management Policy
After verification of the proposed vulnerability patch management rules, the rules need to be formalized and approved by the organization’s management. Now is the time where rough notes need to be revised into formal paragraphs, tables, and appendices.
Once drafted, pass the policy to corporate management and legal counsel for review and approval. The policy can be modified as required and the final draft should be signed by the executives of the organization to ratify and acknowledge the requirements.
Review and Modify the Vulnerability Management Policy
Even though the Vulnerability Management Policy is approved in step three, the organization, IT resources, and regulations will change over time. All policies should be living documents that evolve as the organization changes. and should be periodically reviewed and updated.
Common Vulnerability Management Policy Sections
Required Sections: These core sections should be part of every policy related to Patch Management.
- Scope: What IT assets and systems are covered by the policy.
- Vulnerability Management Authority: Who is in charge and responsible for the vulnerability management policy and its execution.
- Vulnerability Identification: Determine the type of vulnerability scans, penetration tests, and other methods required to identify vulnerabilities for mitigation.
- Vulnerability Evaluation: How to verify, evaluate, and rank the severity of the discovered vulnerability.
- Vulnerability Priority: How to prioritize vulnerabilities in the context of the risk of the exposed assets.
- Vulnerability Mitigation Guidelines: define the vulnerability mitigation process from mitigation design and testing, scheduling the mitigation, and verifying successful mitigation.
- Mitigation Tracking and Exceptions: Requirements for tracking new, ignored, and mitigated vulnerabilities.
- Vulnerability Management Reporting: How to measure success and compliance with vulnerability management with reports, how to report, what to report.
Recommended Sections: These sections help to flesh out the patch management policy with additional rules to protect the organization and to help prepare the IT Department.
- Asset list: A list of resources or links to asset lists to help define the scope of systems and software tracked for patching and updating
- Audit controls and management: Outline what reports, logs, and information can satisfy internal and external auditors to track vulnerability management success and verify vulnerabilities have been successfully mitigated
- Enforcement: Penalties that the IT Department may incur for failure to execute the vulnerability management process
- Distribution: Who must or should receive the vulnerability management policy
- Policy version: Tracking versions and approvals of the vulnerability management policy
See the Top IT Asset Management Tools
Bonus / Nice-to-Have Sections: These sections do not change the core elements of the patch management policy, but can make the policy more usable or comprehensive.
- Overview: Sets expectations and goals for the policy
- Definitions: Definitions for technical terms and acronyms can be useful to help non-technical readers understand the policy; generic terms can be defined for clarity
- Compliance appendix: Copies or links to relevant compliance frameworks with which the organization must comply
Top 5 Vulnerability Management Policy Best Practices
An organization can create an effective vulnerability management policy by focusing on five key best practices:
- Focus on What to Do, Not How
- Right-size Policy Length
- Keep Policies Distinct
- Make Policies Verifiable
- Tailor Policies to Needs, Not Tool Capabilities
Focus on What to Do, Not How
Technology changes so quickly that a policy will not be able to keep up with the details. When writing any IT-related policy, the policy should focus on the high-level goals, key deliverables, and compliance requirements. The IT team will then use those constraints in combination with their budget and personnel constraints to develop an appropriate solution.
Additional details may lock the IT team into obsolete tools, practices, or perspectives that may ultimately undermine instead of strengthening security. Where needed, exhibits or additional reports can be used to provide details that may need to be changed more frequently than the policy itself. For example, in the sample template, the IT team is required to maintain a list of the types of vulnerability scanners used to detect potential vulnerabilities.
Right-size Policy Length
Policies should be no longer and no shorter than needed. IT teams often favor shorter policies because the lack of defined requirements provide them with maximum flexibility for execution. However, the lack of defined requirements often leaves gaps in requirements or makes the policies hard to verify for management or compliance.
On the other hand, attorneys often feel compelled to lock down as many details as possible to make verification more simple and to clarify as many points as possible. Unfortunately, this often tends to lead to over-prescriptive requirements that lock an IT team into the requirements of the moment and leave little room for keeping up with a dynamic IT environment.
These opposing forces must be balanced. IT teams, executives, and attorneys must work together to enable a document with sufficient detail so that the IT team can clearly demonstrate compliance with the policy, but not so much detail the policy becomes a shackle on the vulnerability management process.
Keep Policies Distinct
Vulnerability management policies should focus on vulnerability management and avoid covering tangentially related issues such as endpoint protection, change management, logging, alerting, network security, and monitoring. Even though these important but tangential security and documentation controls protect against unknown and known vulnerabilities, they do not belong in the policy because they do not directly relate to the vulnerability management process.
Additionally, security and compliance teams will look for information in expected policies. For example, to look up policies regarding endpoint protection, most would first look for an overall security policy or a specific endpoint protection policy. To bury the information in a vulnerability management policy is unintuitive and may lead to confusion.
Some might try to copy-paste elements from other existing policies, such as an endpoint protection policy, into the vulnerability management policy for completeness. However, unless the documents are linked for automatic updates, the copied information can rapidly become out of date. Instead of inserting sections of the other existing policies, reference them as needed.
Policies should be individually comprehensive with minimal overlap. Overlap with other policies can lead to language conflicts, uncertainties, and gaps in compliance and security. In the event an organization decides to mix policies, an index or guide should be produced to help team members locate policy information rapidly.
Make Policies Verifiable
Vague policies with nebulous, undefined deliverables satisfies only the requirement to have a policy, not the requirement to have a useful one. Effective policies define the deliverables clearly so that the IT team will have no difficulty satisfying policy requirements.
For example, in the sample policy, the policy clearly defines requirements for:
- Periodic scanning and reports to prove the scans were conducted
- Timeframes for vulnerability mitigation and the reports to show that the IT team conformed with those timeframes
- Vulnerability and mitigation tracking with verifiable reports
When done effectively, compliance and management reports become a byproduct of the vulnerability management process and do not require any additional effort.
Tailor Policies to Needs, Not Existing Capabilities
Although every organization should begin drafting policies based upon existing practices and capabilities, this can lead to a trap of preserving incomplete processes into written policies. The organization should carefully examine their environment and ensure the policy reflects their true needs.
For example, an IT team of a hospital may use a commercial tool to conduct vulnerability scanning of their IT environment, but the tool may only scan PCs, network devices, and servers, which leaves an enormous range of healthtech devices unscanned for vulnerabilities. Their policy requirements should not reflect the limited devices currently scanned, but the full range of devices that need to be included in the vulnerability management process.
How Vulnerability Management Policies Work
All organizations conduct some form of vulnerability management, even if the process is ad hoc and undocumented. Lack of documentation becomes an issue in two primary cases: when preparing for compliance audits or when the organization suffers a breach and is compelled to prove that the IT and security teams executed the appropriate level of cybersecurity and IT defense.
Written policies provide instructions that can be used to show the intended strategy of the organization. Policies do not directly improve security, but a lack of policy will often be viewed as negligence.
Many compliance frameworks, such as the U.S. National Institute of Standards and Technology (NIST) Framework for Improving Critical Infrastructure Cybersecurity, consider policies to be a fundamental requirement for even the lowest levels of cybersecurity maturity. A vulnerability management policy falls under: Information Protection Processes and Procedures (PR.IP) Section 12 which requires that “a vulnerability management plan is developed and implemented.”
An auditor can easily use the policy as a starting point to understand how a company does, or does not, comply with a framework. Of course, the organization will then need to back up the written policy with evidence of action through reports, vulnerability scans, and penetration tests.
Even though not all organizations will be subject to compliance, all organizations can benefit by using vulnerability policy reports to provide a metric for the company to measure vulnerability management. For example, if reports show that the mitigation of high risk vulnerabilities takes longer than desired, the management can consider adding more resources or outsourcing.
Top 5 Benefits of an Effective Vulnerability Management Policy
Many organizations of all sizes tend to avoid the hassle of documentation because the task seems overwhelming, tedious, and constraining. However, an effective vulnerability management policy delivers five key benefits:
- IT Hardening
- Employment Defense
- Executive & Board Member Peace of Mind
- Litigation Protection
- Compliance Easy Button
IT Hardening
An effective vulnerability management policy will naturally enable an effective vulnerability management process that locates and remediates weaknesses in IT and security systems. The process naturally hardens the entire IT environment against attack and removes opportunities for easy exploitation by malicious attackers. This process naturally reduces risk and the likelihood of devastating exploitation for the entire organization.
Employment Defense
Despite the best efforts of the IT team, people will still click on phishing links, zero-day vulnerabilities will still be discovered, and company resource constraints may require some vulnerabilities to remain exposed. Although an effective vulnerability management process can reduce the risk, attacks may still succeed in damaging the organization.
In many cases, executives may initially look for a scapegoat to take the blame for an incident and IT teams often will be targeted. An IT Team that can provide documentation of compliance with an executive-approved vulnerability management policy can demonstrate reasonable best efforts were made to prevent possible breaches. This documentation can protect the IT team against unfair treatment after a breach and protect their jobs.
Executive & Board Member Peace of Mind
Effective vulnerability management policies require reports that can be shared with non-technical executives to enable confidence in the IT team. The non-technical executives don’t need to know the IT details to look at a time-to-remediate report and see if their IT team is meeting the required timeframe for vulnerability mitigation. Clear reports enable smooth communication with executives and the board of directors of an organization to help build confidence in the security posture of the organization.
Litigation Protection
In the event of a breach or successful cybersecurity attack, government agencies or stakeholders may attempt to pursue legal action against the organization. Fortunately, legal standards generally require reasonable efforts of protection, which can be supported with the documentation from an effective vulnerability management policy and program.
Organizations without formal reporting and processes will need to scramble to figure out what documentation may be required to support past efforts and then hope they still have the archival data to create that documentation. Organizations with formal documentation and reporting will already have a significant portion of their evidence ready to present when required.
Compliance Easy Button
An effective vulnerability management policy should be designed to reflect the compliance requirements of the organization. Once the vulnerability management policy and process have been adopted, the organization’s regular internal reports will naturally report on compliance without any additional effort or steps.
Bottom Line: Vulnerability Management Policy
No policy will be perfect, but organizations should start developing a vulnerability management policy as soon as possible so they can begin to reap the benefits, such as IT hardening and simplified compliance. The adoption of any policy will be an iterative process, so get a good version 1.0 in place and be prepared to revise it as it meets real-world conditions.
More information on Vulnerability Management:
