Stifling, Suffocating, Security?

Security risk management requires balancing a number of stakeholders needs. The risk owners, ultimately a board of directors of an institution, set a risk appetite (whether implicitly or explicitly) , the business managers and leaders then seek to operate within that appetite to drive growth or deliver their mission. There is commonly a tension between the hunger for growth versus the desire for safety which tends to be very easily handled at an executive level but becomes increasingly more contentious the further down an organisation a disagreement occurs.

More junior management layers see the risk tolerance limits at the top end of the risk appetite as a hindrance to be avoided and the security risk management teams holding that line as needing to be actively handled. That friction often generates a number of exceptions or waivers which tend to form the core of what security risk managers worry about. Too many waivers and exceptions in aggregate can mean your practical risk tolerance is higher than your stated risk tolerance and its clear then why such a creeping exposure on the risk profile need to be managed.

In financial markets getting as close to your risk tolerance line as possible is a good thing as you’re not leaving the opportunity to make money on the table. However, in security risk the goal is to run as little risk as possible because as long as you don’t increase costs or friction there is nothing to be gained from taking additional risk within your appetite.

It is unfortunately all to common to find that security risk management teams are so focused on defending the risk tolerance line that they push back the control implementation into the risk appetite and ultimately hit what I have come to call the Control Tolerance of the business. Below this point the controls become counterproductive as they stifle growth, create unnecessary friction for customers and users and lead to missed opportunities.

As a discipline we focus so much energy an attention on defining risk tolerances and identifying and assessing exceptions that we have developed a commonly accepted set of approaches for this but I don’t hear any formalisation of measuring and assessing controls that are beyond the Control Tolerance of an organisation. We care about risk tolerances and exceptions, the risk owners care about these but the risk owners and the business managers also care about the the ‘Control Tolerance’ or at least they care about controls beyond it.

In a contrast to the upside risk in financial markets risk appetite the downside risks in security risk appetites means that security controls need to sit within the appetite and as close to the Control Tolerance as possible to minimise unnecessary risk. Consistent pain as a result of crossing the control tolerance can lead to business management regularly bypassing security or in extreme cases convincing the risk owners that’resetting’ the overall risk tolerance is necessary in order to reduce friction.

If the practical risk tolerance that the security teams are working to is below the control tolerance then such a reset is inevitable. If the control implementations are below the Control Tolerance but the Risk Tolerance would practically have allowed for less stifling control environments then such a reset will likely not only reduce the impact of stifling controls but also unnecessarily increase the overall risk tolerance and associated exposure to security risk. Ironically over-zealous security controls lead to a less well-secured environment.

Defining and measuring Control Tolerance is a new area but one worth considering. I’ll be honest I don’t have a good answer defined well yet, indicators like time to complete changes, time to deploy new products or some qualitative measures such as user experience surveys seem useful but there is plenty of work to do in this space. I have seen the frustration caused by operating over the Control Tolerance line but need to do more work on correlating control tolerance indicators that can tell me we’re close but not there yet. I suspect there is much to learn from the UX community on measuring user frustration.