Executive Summary: Residual Risk for Operations 

This article explores residual risk within the broader landscape of operational risk and the dangers of developing tunnel vision that can result in catastrophic outcomes. Specifically, residual risk management requires a balanced view of both security and non-security threats. By regularly evaluating and documenting residual risk, organizations can maintain resilience and uphold regulatory compliance, adapting to an evolving risk environment. 

The post includes two downloadable sample files to document non-security risks and specific regulatory examples that reenforce this approach. 

Key Points: 

• Beyond Cybersecurity: Operational risk is not limited to cybersecurity threats but includes non-security issues like software bugs and system misconfigurations. Focusing solely on cyber threats creates an incomplete view of residual risk, which can lead to poor risk management, flawed investment strategies, and compromised resilience. 

• Regulatory Perspective: Regulators recognize the importance of both security and non-security risks. Regulatory frameworks commonly require organizations to evaluate inherent and residual risks comprehensively to meet compliance standards. 

• Documentation and Accountability: Effective residual risk management requires robust documentation. Standard practices involve maintaining a risk register to log all identified risks, including their controls and residual levels, and conducting risk assessments that distinguish between inherent and residual risk to track changes over time. 

Residual risk is the risk we ultimately live with. It’s the risk that’s left after risk-reduction controls (whatever they may be) have been applied with any new risks that those controls may bring themselves.  

A model of acceptable residual risk (often termed “appetite for risk”) drives investments in risk reduction (to operate within that model), guides business decision making (bets worth taking), and informs regulatory guidelines (to ensure broad stability and serve public interests).  

A shared view of residual risk serves as the common ground for the interplay between organizational ambitions, calculated risk taking, and regulatory compliance.  

Organizations cannot afford to get this wrong. 

The threats posed by cyber-attacks are indisputable and material, but they are not the only operational threats we face. The root causes behind operational outages or disruptions include both cybersecurity exploits and non-security incidents such as software bugs and system misconfigurations.  

Many organizations—and even some regulators—have shown a tendency to underplay the inherent risks stemming from non-security issues.  Perhaps it’s the adversarial, sensational, and even personal nature of cyber-attacks that’s behind this mindset. Regardless, ignoring non-security operational risks can – and has proven to be – catastrophic.  

Inherent risk is the risk we’d face before we proactively act to influence that risk. An incomplete view of inherent risk can be catastrophic as it inevitably leads to a proportionally inaccurate model of residual risk – which, in turn, will upend risk management investment strategies, business decision making, and compliance programs.  

Non-security risk factors are not adversarial and, as such, call for a different kind of vigilance, emphasizing quality, reliability, and communication. Said another way, even the very best cybersecurity controls cannot effectively reduce the operational risks stemming from non-security bugs and misconfigurations.  

Regulators’ role in all of this is to set minimum standards to protect public interests and maintain broader stability – to ensure that organizations do not unduly disregard public risk factors.  

While regulators are not immune to “tunnel vision trap,” it is worth noting that they have consistently framed their motivations and requirements in terms of inherent and residual risk and reenforced the relevance of both security and non-security operational risk factors. See the table below for a partial list of examples. 

Additionally, risk management frameworks and regulations collectively offer consistent guidance that managing residual risk alone is not sufficient. The risk management processes themselves must be documented to demonstrate adherence to the underlying principles and a common understanding of acceptable residual risk. A typical documentation approach includes maintaining:  

• A risk register, which records all identified risks, their levels, and the controls applied (if any), and 

• Risk assessments that evaluate each risk’s likelihood and potential impact, distinguishing between inherent risk (before controls) and residual risk (after controls).  

NOTE: You can download these informational samples of a risk register and a risk assessment specifically designed for non-security (operational) bug risks. Download them here:  

The Risk Register spreadsheet records individual risks associated with non-security vendor defects, detailing the controls applied, the assessed residual risk level, and review dates to ensure ongoing monitoring. 

The Risk Assessment Document offers context and deeper analysis, guiding users through each risk’s description, inherent risk level, and specific controls for non-security-related vendor bugs.

Defining acceptable levels of risk and ensuring that current residual risks fall within these limits is not a one-time task; it’s a process that must be baked into operations. As business environments, threats, and operational contexts evolve, so too must an organization’s understanding of what constitutes acceptable risk. The frequency of review and updates vary, but the principle remains the same: risk assessments and definitions are living documents.  

The following is an incomplete list of representative regulations, their residual risk terminology, and the expected risk assessment update frequency for each.