become a CIBER practical innovator
We are always seeking talented and innovative people. We have IT careers open all around the globe.
Manage Operational Risk Like a Bank!
Eric Tompkins, Principal Consultant : 08 June 2009 / 11:59 AM : 3 
Security leaders often find themselves responsible for the management of organizational risks beyond those traditionally thought of as the purview of security. In past years, security was confined to the application and operation of controls to reduce vulnerabilities. The current risk environment exposes businesses and government agencies to threats never before perceived. This has resulted, many times, in the governing bodies of organizations incorrectly pushing the responsibility for business risk management to the practitioner level. This is a mistake because only governance bodies have the authority to manage business risk.
One major class of business risks is Operational Risk. While there is no one “correct” definition of operational risk, it may be easiest to think of it as comprising all non-financial risks. The Bank of International Settlements (BIS), via the Basel II Conventions, defines operational risk as the “risk of loss resulting from inadequate or failed internal processes, people and systems or from external events.”
Operational risk management (ORM) comprises the disciplines of business continuity, emergency management, and security. In other words, ORM is the sum of organizational activities designed to keep the organization resilient in the midst of a wide variety of threats. Organizational resilience is far too strategic to be made the responsibility of the practitioners of the component activities. Only the organization’s governing body has the scope and vision, and the authority, to properly hold the responsibility for ORM.
The Basel II conventions established 10 principles for ORM. Three of these principles are very specific to banking regulation, and are not listed below. I changed banking specific language to make it more generically applicable, and I added italicized comments.
Principle 1 (Governance)
The board of directors (or whatever body governs your organization) should be aware of the major aspects of the enterprise’s operational risks as a distinct risk category that should be managed, and it should approve and periodically review the enterprise’s operational risk management framework. The framework should provide an organization-wide definition of operational risk and lay down the principles of how operational risk is to be identified, assessed, monitored, and controlled/mitigated.
The responsibility for ORM should reside with the governing body, not with practitioners. This helps ensure adequate vision, enterprise scope, and sufficient support of ORM.
Principle 2 (Audit)
The board of directors should ensure that the enterprise’s operational risk management framework is subject to effective and comprehensive internal audit by operationally independent, appropriately trained and competent staff. The internal audit function should not be directly responsible for operational risk management.
ORM activities should be audited for completeness and effectiveness. The auditor should report to the governing body. This helps ensure ORM activities are meeting enterprise-wide organizational goals and objectives.
Principle 3 (Implementation)
Senior management should have responsibility (and authority) for implementing the operational risk management framework approved by the board of directors. The framework should be consistently implemented throughout the whole organization, and all levels of staff should understand their responsibilities with respect to operational risk management. Senior management should also have responsibility for developing policies, processes and procedures for managing operational risk in all of the enterprise’s material products, activities, processes and systems.
Senior management should make sure the ORM framework is implemented, in a standard way, across the entire organization. This helps prevent stovepipes or “special cases”.
Principle 4 (Risk Assessment)
Enterprises should identify and assess the operational risk inherent in all material products, activities, processes and systems. Enterprises should also ensure that before new products, activities, processes and systems are introduced or undertaken, the operational risk inherent in them is subject to adequate assessment procedures.
Assess the risks of operating every single organizational activity. Don’t do anything new without a formal operational risk assessment. This helps prevent unintended side-effects, and keeps ORM activities tied to organization-wide goals and objectives.
Principle 5 (Risk Management)
Enterprises should implement a process to regularly monitor operational risk profiles and material exposures to losses. There should be regular reporting of pertinent information to senior management and the board of directors that supports the proactive management of operational risk.
Monitor operational risk status and regularly report the status to the governance body. The helps optimize costs and maintain the flexibility of the ORM program to deal with the changing business environment.
Principle 6 (Control)
Enterprises should have policies, processes and procedures to control and/or mitigate material operational risks. Enterprises should periodically review their risk limitation and control strategies and should adjust their operational risk profile accordingly using appropriate strategies, in light of their overall risk appetite and profile.
Once an operational risk has been identified, actually put into controls which address vulnerabilities, reduce the likelihood of threat occurrence (very difficult!), and/or reduce organizational impacts if the risk occurs. Periodically assess the validity and effectiveness of the controls. This helps maintain control effectiveness and keeps the ORM program focused on delivering real value.
Principle 7 (Resilience)
Enterprises should have in place contingency and business continuity plans to ensure their ability to operate on an ongoing basis and limit losses in the event of severe business disruption.
Business continuity is far more than having an IT backup solution, and it needs to be addressed by a function with more scope than IT. Addressing business continuity at an enterprise level helps to make sure business impacts are addressed on an organization-wide basis.
Wishful Though for the Day
I know most of you reading this blog entry already know these truths to be self-evident, but hopefully, you can leverage some of these concepts to drive ORM responsibility a little further up the hierarchy. If you’d like to discuss any of these ideas, please feel free to contact me.
Posted in Security on 08 June 2009
More by this author 
Tagged: Business Continuity Business Impact Analysis Disaster Recovery Governance Risk and Compliance Information Security Physical security Risk management Security maturity
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3 Comments
Javier Posada : 09 June 2009
Banks and risk management - are these really the institutions we want to be modeling ourselves after? What with the hundreds of billions of dollars in government bailout..?Eric Tompkins (author) : 16 June 2009
Fair comment, but that's financial risk, as opposed to operational risk. When was the last time you heard about an information breach at a bank? It happens, but it's very rare and discovered/mitigated almost immediately.
suzan : 01 September 2009
nice article about operational risk management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Post a comment
