A control is unhealthy if:
*It has evidence that isn’t regularly updated despite requirements
*It has evidence that regularly fails one or more tests
*It has no evidence and cannot be tested (in this instance, the control might not exist)
The organization can then estimate the percentages of risk mitigation based on each control’s health. This includes risks that have only a single mitigating control, and risks that have multiple controls. If the organization already has a recent internal risk assessment or similar instrument, this data can be reused. One rule of thumb: a healthy control reduces more risk than an unhealthy control.
The next step is nuanced: the compliance team should gently approach each control owner to get the control owner’s professional opinion on how effective each control is at mitigating a risk. Having evidence about the control’s health (or lack of health) makes this about facts, not opinions. The goal is that each control operator can provide additional context that may increase or decrease the effectiveness of each control at mitigating a risk, with the usual rules that not all controls will mitigate 100 percent of a risk, and not all risks will be reduced to 0 percent probability or impact.
Evaluating Outlying Controls for Possible Budgetary Efficiencies
Following the process above allows the compliance team to develop three lists of controls for additional scrutiny and possible cost reductions:
*Controls that regularly are not healthy
*Controls that mitigate less than 20 percent of a risk and are one of several controls that are mitigating a risk
*Controls that aren’t associated with any documented risk
Controls that appear on the first two lists that are based on commercial solutions are leverage for renewal negotiations with vendors. If a vendor cannot help to improve the effectiveness or health of their control, the organization should consider removing it from their environment and replacing it by either strengthening another control or by deploying an alternative control. If a vendor disagrees with the mapping of their solution to the control and associated risk, consider if the solution is being used appropriately. For example, a multifactor authentication solution would be a good fit for reducing the risks of account takeovers, but be a poor fit to detect data exfiltration.
For those internal controls that appear on the first two lists of controls but do not use a technology solution, the compliance team should partner with the control operators to determine the root cause. Often, it will be training or staffing, though it can be another, less-obvious factor, such as a lack of awareness of the control.
Controls that appear on the third list, which aren’t associated with any documented risk, should be carefully scrutinized for their point of origin. Often, the source of the control may be a current or former commercial contract, regulatory requirement, or local legal requirement. However, if