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.