The term operational risk management (ORM) is defined as a continual cyclic process which includes risk assessment, risk decision making, and implementation of risk controls, which results in acceptance, mitigation, or avoidance of risk. ORM is the oversight of operational risk, including the risk of loss resulting from inadequate or failed internal processes and systems; human factors; or external events. Unlike other type of risks (market risk, credit risk, etc.) operational risk had rarely been considered strategically significant by senior management.
Levels
Deliberate
Deliberate risk management is used at routine periods through the implementation of a project or process. Examples include quality assurance, on-the-job training, safety briefs, performance reviews, and safety checks.
In Depth
In depth risk management is used before a project is implemented, when there is plenty of time to plan and prepare. Examples of in-depth methods include training, drafting instructions and requirements, and acquiring personal protective equipment.
Time Critical
Time critical risk management is used during operational exercises or execution of tasks. It is defined as the effective use of all available resources by individuals, crews, and teams to safely and effectively accomplish the mission or task using risk management concepts when time and resources are limited. Examples of tools used includes execution check-lists and change management. This requires a high degree of situational awareness.
Categories:
People
The people category includes employees, customers, vendors and other stakeholders. Employee risk includes human error and intentional wrongdoing, such as in cases of fraud. Risks include breach of policy, insufficient guidance, poor training, bed decision making, or fraudulent behavior. Outside of the organization, there are several operational risks that include people. Employees, customers, and vendors all pose a risk with social media. Monitoring and controlling the people aspect of operation risk is one of the broadest areas for coverage.
Technology
Technology risk from an operational standpoint includes hardware, software, privacy, and security. Technology risk also spans across the entire organization and the people category described above. Hardware limitations can hinder productivity, especially when in a remote work environment. Software too can reduce productivity when applications do increase efficiency or employees lack training. Software can also impact customers as they interact with your organization. External threats exist as hackers attempt to steal information or hijack networks. This can lead to leaked customer information and data privacy concerns.
Regulations
Risk for non-compliance to regulation exists in some form in nearly every organization. Some industries are more highly regulated than others, but all regulations come down to operationalizing internal controls. Over the past decade, the number and complexity of rules have increased and the penalties have become more severe.
Flow:
Step 1: Risk Identification
Risks must be identified so these can be controlled. Risk identification starts with understanding the organization’s objectives. Risks are anything that prevents the organization from attaining its objectives.
Step 2: Risk Assessment
Risk assessment is a systematic process for rating risks on likelihood and impact. The outcome from the risk assessment is a prioritized listing of known risks. The risk assessment process may look similar to the risk assessment done by internal audit.
Step 3: Risk Mitigation
The risk mitigation step involves choosing a path for controlling the specific risks. In the Operational Risk Management process, there are four options for risk mitigation: transfer, avoid, accept, and control.
- Transfer: Transferring shifts the risk to another organization. The two most often means for transferring are outsourcing and insuring. When outsourcing, management cannot completely transfer the responsibility for controlling risk. Insuring against the risk ultimately transfers some of the financial impact of the risk to the insurance company. A good example of transferring risk occurs with cloud-based software companies. When a company purchases cloud-based software, the contract usually includes a clause for data breach insurance. The purchaser is ensuring the vendor can pay for damages in the event of a data breach. At the same time, the vendor will also have their data center provide SOC reports that show there are sufficient controls in place to minimize the likelihood of a data breach.
- Avoid: Avoidance prevents the organization from entering into the risk situation. For example, when choosing a vendor for a service, the organization could choose to accept a vendor with a higher-priced bid if the lower-cost vendor does not have adequate references.
- Accept: Based on the comparison of the risk to the cost of control, management could accept the risk and move forward with the risky choice. As an example, there is a risk that an employee will burn themselves if the company installs new coffee makers in the breakroom. The benefit of employee satisfaction from new coffee makers outweighs the risk of an employee accidentally burning themselves on a hot cup of coffee, so management accepts the risk and installs the new appliance.
- Control: Controls are processing the organization puts in place to decrease the impact of the risk if it occurs or to increase the likelihood of meeting the objective. For example, installing software behind a firewall reduces the likelihood of hackers gaining access, while backing up the network decreases the impact of a compromised network since it can be restored to a safe point.
Step 4: Control Implementation
Once the risk mitigation choice decisions are made, the next step is implementation. The controls are designed specifically to meet the risk in question. The control rationale, objective, and activity should be clearly documented so the controls can be clearly communicated and executed. The controls implemented should focus preventive control activities over policies
Step 5: Monitoring
Since the controls may be performed by people who make mistakes, or the environment could change, the controls should be monitored. Control monitoring involves testing the control for appropriateness of design, implementation, and operating effectiveness. Any exceptions or issues should be raised to management with action plans established.