Finding the level of risk you are comfortable with

Australian business management teams have a healthy understanding and appreciation of business risk. They are aware of policy risk from a violation and implication perspective and the lending issues of capital risk. Australian IT management teams are correspondingly across the ins and outs of technical risk. However, business management and IT management teams could almost be speaking two different languages when it comes to communicating risk to each other.
 
These two different risk languages are rarely put on the agenda for discussion.  The teams do not appear at the same meetings.  This makes the translation of technical risk into a business framework almost impossible.
 
If business managers don’t understand technical risk, and IT managers don’t understand business risk, then nobody ever fully investigates and understands a comprehensive risk mitigation strategy. As far as I am aware, there are very few risk specialists that have both a background in risk and IT and whom are capable of translating these risks into business risks. I mean, very rare.
 
So if you don’t speak the language of IT risk and need to understand your organisation’s comfort level of technical risk, where do you start?
 
The first step is for me to let you in on a little secret may or may not shock you. When organisations don’t understand the level of risk they are comfortable with and they don’t understand what level of risk has been introduced to the organisation, they usually have much higher levels of risk than they realise. This has been the proven case time and time again.
 
My second piece of advice is that I believe there is a corresponding rise between software vulnerabilities, data security risk, operational risk, and reputational damage which have reached a critical point requiring intervention.
 
So knowing that, we recommend that CIOs determine their organisation’s current level of risk and map business requirements to that risk. To do this, a great place to start is with a vendor-neutral framework I referred to in yesterday’s blog.  The Open Software Assurance Maturity Model (OpenSAMM) helps you evaluate and measure the security resilience of your organisation and the software you rely on. OpenSAMM sets a clearly articulated benchmark for IT Managers, CIO’s and business management teams.
 
OpenSAMM’s methodology allows you to understand your security posture and maturity level against the rest of your industry peers.  It verifies the controls you need to eliminate unacceptable business risks associated with IT. It is extremely cost-efficient to invest in a security program that will measure and rate your software security risk level. Investing in secure software is estimated at 100 times less costly as fixing insecure solutions.
 
In fact, I am such a supporter of the OpenSAMM methodology that we are aiming to introduce it into at least a third of our clients’ projects over the next twelve months. The benefits of OpenSAMM go well beyond understanding your current security posture.  It facilitates the inclusion of IT security in emergency response teams, vendor procurement, quality assurance, architecture and design, and much more.

Today’s CIO’s are facing a different threat landscape and need to put a security plan in place.  They must be vigilant in the detection of security incidents. Plans and awareness are not as common as you think. If your organisation needs help, partner with an organisation that can propose a security plan, implement systematic processes to address the vulnerabilities facing businesses today and partner with you to help with the security speed bumps in business.

I have no doubt that security breaches will escalate and cybercriminals will become more voracious for data. At the same time, I am also aware that businesses will continue to focus on reducing costs and utilising new technologies such as cloud computing to achieve this end. OpenSAMM enables organisations to develop an awareness of the data assets it owns and extends the responsibility of who is looking after them in its review process, whether that is internal or via an external cloud provider.

If you know the risks, you can better manage them.