Generally speaking, organizations run more effectively with well-written policies, and policies can also be a conversation starter to tackle some of the objectives or goals that not everyone is on board with. 

The benefits of a well-written policy become even more important when it comes to responding to a vulnerability or incident. Having a vulnerability management policy is not only a requirement for compliance with PCI, SOC, and most other similar certifications, but it also provides guidance and expectations within your organization. 

If you’re considering writing or updating your vulnerability management policy, you can listen to our podcast on the topic, and use the following checklist to help you cover everything:

1.) Set goals and objectives   

Before you even begin, you’ll need to know what results you have in mind for your vulnerability management program. Every organization is different and has different needs. You may work for a small organization that can remediate quickly, so you may want to write the policy with the objective of creating quick but reasonable expectations. If you work for a large company that has specific needs when it comes to scanning and reporting findings, you’ll want to be very detailed in the process in case anyone who may not have been trained needs to know the process. 

Become familiar with your current vulnerability management program and speak with asset owners to get an understanding of what expectations are reasonable and if there are any unaddressed issues that can be resolved in the policy.

2.) Consider requirements 

If you are seeking to obtain or keep certifications such as PCI or SOC, look up the requirements. You’ll also need to look up and follow any other regulations that may apply to your industry.

3.) Read documentation 

Whenever I am tasked with writing a policy, I always check to see if there is a NIST document on the topic. For vulnerability management policies, there is the Guide to Enterprise Patch Management Technologies. There are plenty of other good resources as well, but always check to make sure they are not too outdated. You can also check with the company that performs your audits as they most likely will have up-to-date resources.

4.) Work out the details 

Every vulnerability management policy should have at least:

1. Remediation timelines- based on the severity of the findings and/or the type of asset. If your organization is unable to remediate in a timely manner, you can create a timeline based on prioritizing the most critical assets first.
2. Patch Management- Include details such as how the patches will be tested before deployment and how they will be deployed.
3. Exceptions handling- Not all findings will be able to be remediated right away. Additionally, there may be reasons that can be classified as accepted risk as to why the asset is not being updated. There are cases in which updating a system may cause it to no longer function in the same way. Patching can also affect the availability of a system.
4. Scanning schedules for each type of asset- Your assets should be organized into different groups depending on their risk level.
5. Vulnerabilities scoring and reporting- You can score vulnerabilities on a numbered scale or put them in categories that range from Low to Critical. Have a plan for how vulnerabilities will be reported to asset owners.
   

5.) Consequences 

What happens if the policy is not followed? Some potential consequences could be additional training or decommissioning of the asset. A policy violation could also be an indication that something is not set up correctly or operating as intended, so first check to make sure everything is working right.

There are very few reasons (if any) not to follow a policy when there is a process for exceptions (and the people approving the exceptions are being reasonable.) If there are too many policy violations, however, it may be time to review your vulnerability management policy to see if there are any reasons why the policy continues to be violated. You may want to create a better exception process or change the remediation timeline.

6.) Review and update your policy 

At least annually, you’ll want to review your policies and update them if needed. New requirements may have come up, or your goals and objectives may have changed. This is also a good time to review training materials and see that they cover your policies and any new changes. 

Conclusion

These six steps will help you create a vulnerability management policy that works for your organization and provides the guidelines and expectations that are required. 

Keep in mind throughout the process that this is a dynamic experience–you will find things that don’t work or things that have changed and you’ll want to update the policy. You also can not create a perfect policy, and you may find that a lot of people disagree with it. While you’ll likely always have some disagreement, remember to take feedback into consideration and create policies that are realistic and give people an opportunity to be in compliance instead of creating an opportunity to make someone’s job more difficult.