Contributing Roles | Vulnerability Management

The groups most commonly having a contributing role in the VM process are asset owners, Human Resources, IT, and Security. The last group, Security, may be surprising to you in that one would expect a direct operational role rather than a contributing one. Although it may be the case that Security is the principal operator of the system, we discuss it at a higher, abstract level as a customer that contributes requirements.

Asset Owners

Asset owners are those who ultimately pay for things and derive the most benefit. They control the purse strings, and therefore have considerable say over what gets done. In many organizations, the asset owner is the line of business. This either happens through a chargeback mechanism or direct purchase. This becomes most apparent at the middle and upper levels of management.
It is natural for typical IT workers to consider the systems they administer as their own. This sense of ownership is not founded in reality but only from an emotional attachment. Working through their managers will ultimately yield better cooperation in a large organization when making plans to assess the security posture of an asset. Maintaining emotional separation from the asset will enhance objectivity when making key decisions about the asset’s security posture. Two very important contributions of an asset owner are the asset classification and valuation functions, which cannot and should not be performed by the administrator of a system. There will be more on this topic when we discuss planning and execution of the VM program.


Security departments are often the groups dealing directly with VM. However, organizations with a strong focus on service management as described in the ITIL service management framework may consider this a subset of the existing framework. In either case, a close and cooperative relationship between the security function and IT should exist. A partnership will make VM implementation easier and you will likely receive better internal support.
Since security is the ultimate goal of a VM system, it is natural that Security is a key participant and possibly full owner and operator of the VM program. Depending on the type of business, however, it is possible that other groups such as Compliance will take on this role. For example, companies that depend heavily on payment card industry (PCI) standards compliance may wish to have the compliance organization take ownership of the process while partnering closely with Security as a customer and key constituent.


Human Resources is one of the most overlooked groups. VM systems often find critical compliance problems, which can expand into evidence of security incidents perpetrated by an employee. HR is an instrumental part of the reporting process as well as the “stick” part of security policy. Ultimately, HR is there to help manage the risk to the company from things that employees do. Any reporting process that is developed should probably consider the relationship with HR should action other than patching and configuration management be required.
HR is also involved in the creation and maintenance of performance management programs. With careful planning, it is possible to tie vulnerability remediation performance to employee performance objectives. To achieve this, it may be necessary to give HR a clear understanding of how the VM program and support systems work. HR can then work with the VM program manager to determine what their role will be in mediating any potential conflicts that may arise with managing an employee.


Information technology is obviously heavily involved in technology and process. If you are working as a separate security or compliance group, I recommend partnering with an IT project manager to get the technology deployed. A senior IT manager would also be very helpful in getting systems and networks remediated. The VM program manager should work with senior IT managers to develop the process and identify the key individuals who will oversee the work. In all likelihood, you will have to get some initial guidance from managers and then propose a process. Be sure to furnish a diagram. IT people work well with drawings and seem to commonly prefer analyzing existing design.

Operational Roles | Vulnerability Management

Other roles to be filled in the ongoing operation of a VM program have both direct and indirect participation and contribute greatly to the program’s effectiveness. The roles are defined early in process development with more concrete modifications when hardware and software are procured. This is because the selection of technology will impact how people work, their involvement in the communications among other groups, and the nature of their interdependencies. If an automated process fulfills a key activity in a role, then the requirement for the role may be diminished altogether.
For example, at the outset it may be planned to have a role of an administrator to take discovered critical vulnerabilities and distribute the remediation requests to the appropriate system owners or administrators. However, it may subsequently be determined that the selected technology can automate this process, and therefore the role is minimized to one of monitoring.

Vulnerability Manager

This role is responsible for assuring the correct configuration and operation of the technology, as well as creating, monitoring, and distributing reports as needed. It is by no means a simple administrator role. The individual must be able to interpret technical reports produced by the system and to explain the cause and remediation for a vulnerability. Knowledge of operating systems, networks, and security practices is required. This individual will interact with system administrators and network managers to assure that the vulnerability identification and remediation processes meet goals.

Incident Manager

When vulnerabilities require attention, one person must take responsibility for remediation. It is often the owner or administrator of the vulnerable target. This individual should have insight into the configuration and operation of the target and be able to assess the impact of a change to that system. This person, known as an incident manager, will work with the vulnerability manager to complete the required remediation tasks. It is the responsibility of the incident manager to follow up on the assigned remediation tasks until they are complete. In some cases, this role in combined with the role of change manager. For example, smaller organizations may have one person to field all work for engineers and administrators. This person could be responsible for receiving incidents, coordinating changes, and distributing remediation work.

Change Manager

In a more complex remediation scenario where multiple systems or business functions may be affected by a complex change, the change manager will act as a project manager to oversee the full extent of the change. This manager will inform the affected parties, coordinate activities, perform testing or assure that proper testing is completed, and work with the vulnerability manager to verify compliance.

Compliance Manager

This role is primarily one of a recipient and end user of the VM system, and also one of the principal beneficiaries. In a normal compliance function, the compliance manager is tasked with assuring that the systems in use by the company adhere to policies and standards. This manager is generally a recipient or consumer of reports from the VM system. More importantly, in a dynamic environment the compliance manager will review trend reports to determine whether there is a continuous or repeating activity that results in a system being out of compliance. This allows the compliance manager to discover processes in the organization that may be flawed in a way that leads to repeat policy deviations.
In an environment where service level agreements (SLAs) are used to establish service levels, the VM program manager may create an SLA for the compliance manager to assure that audits take place at the required frequency and the appropriate checks are run on each target. Metrics for this are simple and easily derived from the vulnerability scan results.

Popular Posts