3 Issues That Plague Risk Management Programs

3 Issues That Plague Risk Management Programs

As a cybersecurity consultant, I’ve seen risk management programs executed different ways, but most have the same goal—to implement controls that minimize threats, reduce risks, and remediate vulnerabilities to a level that is acceptable to the organization. While working with organizations to build and implement risk management programs, I’ve noticed three common pitfalls that plague programs across every industry.

1. No Common Vocabulary

Risk analysts are immersed daily in frameworks, operational procedures, and data. This preoccupation is not inherently negative, but it does come with consequences. While the ‘heads-down’ nature of their work promotes fluency in peer conversations, they may find it difficult to effectively communicate findings in a relatable manner to a risk “outsider”a person whose job does not focus on risk. Such ineffective communication may lead to misinterpreted or misunderstood risk analysis among decision makers. Another consequence of not using a common vocabulary is the creation of silos. If the risk team doesn’t communicate its risk process to the business units, there is confusion throughout the organization as to the purpose of the risk team’s activities.

For example, a risk analyst conducts a risk assessment on a new customer service department project and shares the results with the appropriate stakeholders. During the meeting, it’s apparent some of the stakeholders are confused about what the risks mean to the project and don’t fully understand why the suggested controls should be implemented. If stakeholders don’t readily see the value of implementation to both their business unit and the organization, it’s unlikely the project will be prioritized. A solution is to create a risk language each stakeholder can understand.

  • Educate stakeholders on the value of the project and responsibilities and expectations of each role throughout the project lifecycle.
  • Explain how to interpret risk results, mitigations, and controls.
  • Outline how risk affects both the company and the business unit.

When all stakeholders can communicate with each other, it eliminates confusion and boosts the success rate of implementing the proper security controls. Communication across the organization, from technicians and analysts to the senior leadership team, is critical for the success of a risk management program.

2. Too Asset Focused

Most risk assessments I’ve observed focus on assets and rely on a business impact analysis (BIA) to evaluate asset value, criticality, and prioritization. BIAs and risk assessments should be a package deal. The BIA provides insights on an asset’s value and the effects of an event-caused interruption. A risk assessment should take information from the BIA to evaluate the impact to the asset and apply it holistically to the processes that support that asset. Unfortunately, risk assessors often overlook the risks to business and technical processes.

An example is when an organization collects values on a targeted group of assets that collect and distribute data for billing purposes. The risk assessor combines the asset values and impact scores from the BIA with asset risk scores and vulnerability scan results with the goal to reduce risk to the targeted assets.

But there’s a gap.

What this example assessment does not address is how users interact with the assets (which can include authentication/authorization) and instructions on how users are supposed to interact with the assets. The assessment also fails to properly review how the assets interact with other network components, or where the billing data is sent once processed. One solution is to consider business processes in the BIA and include them when conducting risk assessments that reference risk to processes and assets. This is accomplished by placing assets in context to their use by the organization. Detailed documentation, which identifies and maps critical business processes, is the start of identifying risk on processes. As processes are holistically mapped through technology (e.g. data flows), administrative (e.g. the patching procedure), and organizational (e.g. third-party risk) means, vulnerabilities and risks can be identified. Identifying risks to processes can highlight significant gaps, such as single points of failure and process inconsistencies and inefficiencies.

3. No Straight Line to the Bottom Line

The risk assessor completes an assessment. What’s next? How are results interpreted? I often find organizations struggle to answer these questions. They may find their assessment results are generic, may not clearly convey why a finding is an actual risk, or worse yet, a mitigation plan is not identified. This is most often the case when organizations utilize their risk assessments to satisfy a compliance requirement, rather than to inform the mitigation strategy.

One example of a good approach was during a recent client engagement. I completed a project risk assessment that showed significant cybersecurity risk. The business unit responsible for the risk explained that the project was a large revenue source for the organization. When I communicated the risk situation to the senior leadership of both the cybersecurity team and the responsible business units, everyone agreed the risk was great but acceptable, given its impact on revenue generation, the infrastructure involved, and cost to make changes (complexity of the mitigations, time and effort). It came down to their appetite for risk.  Open communication across all stakeholders allowed us to evaluate the risk against the client’s threat landscape and business priorities to inform a mitigation strategy that best served the enterprise (i.e. accepting the risk). 

Solutions to ensure risk assessments are not underutilized are challenging because they require fundamental changes to corporate culture, which start with changing how risk assessments are viewed. Communicating and properly portraying risks without sounding like “the sky is falling” can be difficult. One solution is to convert risk assessment results into terms the organization can understand. Having a standard definition for low, medium, high, and critical risk, or using quantitative results, such as potential loss, can be understood by everyone in the organization. When all stakeholders understand risks, the risk assessment is taken more seriously and often leads to mitigations and controls being implemented.

I recommend working with your senior leadership team on an agreeable solution to ensure cybersecurity risks are addressed appropriately. Look for areas where you can bridge communication gaps, expand the assessment scope, and underscore business value. Although there’s no quick fix to gaining ground on these three objectives, it can be done.



Create action plans that drive change throughout the organization. Start by addressing pitfall number one—no common vocabulary.

Get stakeholder buy-in and agree on a communication strategy for the entire organization. Armed with a shared vernacular, you’ll find successful communicating risk and collaborating on mitigation efforts. Need assistance getting started? Revolutionary Security can help.

Request a Meeting

 

Topics

Preventing a Meltdown: Recommendations for the Meltdown / Spectre Vulnerabilities
No Love for CVSS—ICS Industry Leaders Caution Reliance on the IT Standard