Operational risk management – what we really need

Operational risk management has been the buzz word du-jour in recent years, due to the Basel II initiative in the banking industry and Solvency II in the insurance industry.

The Basel II definition of operational risk is “the risk of loss resulting from inadequate or failed internal processes, people and systems, or from external events.”

It seems that in the middle of the great financial crisis, TARP, unmet calls for transparency and trillions being sunk into the US financial services industry (instead of encouraging innovation, manufacturing and creation of free cash flow…), Basel II deserves to be judged and found wanting.

Perhaps we need to update the Basel II definition of operational risk and bring it into line with a modern set of threats. For example, we might say, let’s add to the Basel II definition, “… and risks due to networking with other businesses”. This is a reasonable addition, since in my experience in data security projects and according to the Verizon security breach reports,  over 70% of data loss incidents involve outsourcing and sub-contractors.

External business partnerships are indeed, a source of risk for financial institutions that do business process outsourcing (especially if one considers data loss) but it appears to me that the Basel II and Solvency II definitions  are  less appropriate for the technology and manufacturing industries, where  innovation and product development are performed by relatively small engineering teams and key assets are product quality and customer safety and not credit cards in database servers.

Let’s take the example of a company that makes a robot to assist in micro-surgery.

For the medical device company, the biggest operational risk  is a flawed product that might damage a patient. The FDA sees this as a regulatory issue and addresses it with the 510(K) but my gut feeling is that most small (4-6 people)  software development teams don’t really have a “process”.  After an audit by a regulatory affairs consultant, they can comply and still fall hard on a software defect or design flaw.

It’s amazing to me that the Basel II definition of does not consider customer safety as an  operational risk, and yet, the lack of customer safety and networked-business risks in the Basel II definition only serves to illustrate the futility of a check list approach to operational risk management.

Since regulatory compliance is not a substitute for analyzing particular threats to a particular business unit,  I would propose a different definition of op risk:

“Any combination of one or more threats that exploits vulnerabilities to damage company assets as measured in dollars (or euro or yen ….)”

This definition is universally applicable to financial services, IP developers, manufacturing, distribution, health care, bio med etc…The definition does not limit business management to risk analysis inside the company but enables a company to consider threats due to product quality, compliance, extended business relationships, PHI, PII and a whole slew of new risks that don’t even exist yet on their current threat surface.

It’s a definition that forces the company executives to ask themselves what are their key threats and assets and vulnerabilities and how much of the company value is at stake.

Threat models are not a silver bullet solution to prevent a crisis like AIG on one hand or Toyota on the other. A threat model is only a tool to implement a risk strategy by the business management. Threat modeling  needs to be used in the proper way, measured in dollar values and must be reviewed regularly – at least once/year.

The beauty of the above definition is that it links operational risks to business operations.

Any business in any vertical, must define their own threat landscape, define their control/security countermeasure strategy, run their own risk assessment regularly and  insure that their data security and regulatory compliance policies, procedures and systems are aligned with the latest version of their threat model.

Read more about threat modeling and operational risk management on this blog.

Related Posts Plugin for WordPress, Blogger...
Tell your friends and colleagues about us. Thanks!
Share this

3 thoughts on “Operational risk management – what we really need

  1. It is absolutely essential that Risk Identification be linked to a process rather than professional thumb-sucking based on one’s extensive knowledge of the business/subject. This can only be achieved by identifying the risk exposure to the business. In turn, this is achieved by analyzing the business’s strategic/business plan. If uncertainty exists when considering the achievability of goals and objectives then the business is exposed to risk. By questioning ‘what will impact/prevent and objective from being achieved?’ one would be able to identify the risks to business.

    This approach is managed within Riskalyzor.com, an online risk management tool that can be found at http://www.riskalyzor.com.

  2. Koos,
    I totally agree. This is one of our secrets to success in Data loss prevention projects. Where most vendors including Symantec and Mcafee focus on data classification, we focus on business process classification. A business might have thousands of different data classes including many they don’t know about (which leads to expensive data discovery projects) but that same business will probably have less than 10 key business processes that involve sensitive customer data, product safety, sales, marketing etc…

    Once you classify business processes, you then need to associate threats and estimate damage to the assets of those business processes.

    Thanks for the input
    Danny

Leave a Reply

Your email address will not be published. Required fields are marked *