Who's Legally Liable for a Risk Management Failure?

Corporate liability is often straightforward. Illegal action leads to negative consequences, which lead to discovery, which leads to assignment of liability. But it isn't always that clear-cut.

Sometimes innocent individuals or organizations are caught up in a questionable situation that causes considerable harm. At other times, individuals intentionally engage in wrongdoing, but their actions don't lead to any tangible consequences. In either case, corporate executives—and even treasury and finance managers—may be surprised to learn how legal liability is assigned.

It might seem that the degree to which an individual or organization is held liable for wrongdoing should be tied to the results of his or her actions. However, legal liability for crimes committed may be completely unrelated to the consequences of the illicit activities.

A Tale of Two Risks

Consider, for example, the recent real-world cases of two companies. Business A, a leading global bank, manages billions of dollars in assets. An employee in Business A stole more than $20 million from clients, then used false promises and forged account statements to cover his tracks. He was not arrested until April 2016, more than four years after the embezzlement started.

Business B is a private e-commerce company, with fewer than 200 employees, that misrepresented its information security practices. In marketing collateral and other documents, this company claimed its "safe" and "secure" transactions met and exceeded industry best practices. In reality, Business B never implemented the security practices it publicized, and certainly did not execute them regularly. Nevertheless, the company didn't suffer an actual data breach, so customers didn't experience tangible consequences.

Which organization should be held more liable? Business A did not discover the embezzlement scheme until clients had been affected, but upon discovering it, the company immediately reported the problem to the FBI. In contrast, Business B was not only aware of its misrepresentations, but it knowingly perpetuated them in order to grow its customer base.

These are not hypothetical scenarios. JPMorgan Chase (Business A) recently fired the broker responsible for more than $20 million in embezzlements. Thanks to the cooperation of the JPMorgan management team, and records documenting its risk management program, the bank faced no charges related to the incidents; the broker was sentenced individually. In contrast, Business B—Dwolla—was found guilty of risk management negligence regarding its data security practices. The Consumer Financial Protection Bureau (CFPB) subsequently hit Dwolla with $100,000 in penalties for lacking proper risk management processes and failing to disclose ineffectiveness.

Together, these cases demonstrate how the risk management landscape has changed over the past few years. Regulators are shifting to focus on evaluating companies' prevention strategies and disclosure habits. And enforcement agencies are increasingly targeting individuals over corporations when the company has appropriate risk management policies and practices in place. To do so, they need evidence. Thus, it's important to maintain a well-defined risk management program that stores an electronic trail of completed due diligence procedures.

Disclosure at the Heart of a New ERM Framework

Both trends—increasing efforts to target responsible individuals and a greater focus on companies' pre-breach practices—are contributing to the changing nature of enterprise risk management (ERM). The change was set in motion in 2010, when the SEC enacted its proxy disclosure enhancements to hold board members personally responsible for the effectiveness of their company's risk management program and for the accuracy of its disclosures to shareholders.

More specifically, the SEC extended the board's risk management role down to the level of business processes, where material activities take place. Previously, boards were responsible only for CEO-level risks and decisions. In a way, holding board members responsible for exposures caused by low-level decisions may seem at odds with regulators' greater focus on individual liability, but the two are actually intimately related.

JPMorgan Chase was unaware of Michael Oppenheim's illegal activities for years. That's a good reminder that risks are difficult to detect; JPMorgan's executives likely would have been held liable if they had failed to prove that adequate measures were taken to prevent fraud. Fortunately in this case, the company had documented extensive employee training and adherence of its management practices to anti-corruption policies. Crucial to proving both points was the historical assessment record available in the company's risk management program.

This record provided the means to two important accomplishments: First, it helped JPMorgan respond to investigations. The company's previous statements had not indicated ineffective risk management (disclosure is required by the SEC's proxy disclosure enhancements anytime problems are uncovered). The historical record proved no such disclosure was necessary; JPMorgan's risk management program was up to industry standards. As a result, the company avoided enforcement penalties.

Second, the historical record also simplified the assignment of responsibility. JPMorgan's historical risk management data proved unequivocally that Oppenheim had intentionally violated existing corporate anti-corruption measures. This simplified the separation of the criminally liable individual from the organization.

The JPMorgan and Dwolla cases are strong examples of regulators' increased focus on pre-breach processes. Unlike JPMorgan, Dwolla did not suffer from any type of fraud, data breach, or insider trading. In fact, the company appeared to be growing and healthy. Even though none of Dwolla's customers were affected by its security lapses, the company still had to pay $100,000 in penalties. It will also likely lose a portion of its customer base. This fact alone should serve as a call to action for every organization.

Options for Corporate Risk Management

Companies can't afford to simply assume the worst will never happen; regulators proactively put all types of organizations under the microscope, incident or no incident. Whether big or small, public or private, companies have two choices: Adopt an ERM program that maintains an electronic trail of due diligence procedures or disclose the lack of such a program.

Either option is acceptable according to the law. Regulators will not penalize companies that choose one or the other. Of course, disclosure might push investors away and reduce a company's customer base, but this alternative is preferable to misrepresentation. Even if Dwolla's data security practices had exceeded industry standards (as advertised), it still could not have claimed to encrypt all personally identifiable information (PII).

The disclosure rule demands just that: complete and total risk disclosure and accountability for risk mitigation.

Companies that choose the first option—implementing an enterprise risk management program for protection against fraud, external risks, and more—need to take four key steps:

1. Identify risks holistically. A company cannot consistently and accurately identify risks if it's looking at exposures on a department-by-department basis. Likewise, risk management can't be performed by one team on behalf of the entire organization. The people best equipped to identify departmental and functional risks are front-line employees and managers, so they should be involved on a regular basis.

The entire organization should share a common risk management framework that consists of a secure, centralized, customizable root-cause risk library. Risk libraries allow programs to expand and adapt with a changing business environment. They also enable front-line managers to identify risk in real time.

To identify risks quickly and precisely, users need access to a library that breaks risk into different categories and subcategories. At the broadest level, risks should be identified as threats related to external forces; company employees; company processes; internal systems; or relationships with partners, vendors, customers, etc. When these categories are then broken out into even more specific segments, the result is a comprehensive risk library.

A well-designed risk library helps users identify where each risk originates. For example, consider the difference between a risk filed in "People > Fraud > Insider Trading" vs. a risk housed under "External > Fraud > Theft & other crimes"; library users can easily determine whether each of these risks comes from internal employees or external parties. A central library structured under the root-cause categories of external, relationships, processes, people, and systems improves front-line managers' ability to identify the risk source, rather than symptoms. Front-line managers can then escalate to the right department (depending on the risk source) and hierarchical level (depending on the risk severity) to allocate resources for timely action.

Another benefit of centralized risk libraries is the discovery of links between different resources and business processes. If different departments unknowingly identify the same risk, but approach it in different manners, their follow-up actions might be redundant—or, worse, might interfere with one another. Consider management of IT SOX (Sarbanes-Oxley) compliance vs. internal controls over financial reporting. In most companies, these processes are managed by different groups, without establishing a direct connection. A company does not need to retest its SOX compliance if the IT resources integral to the controls have not changed within the past year. However, an organization may retest if it has failed to connect resources and processes, even though doing so is a waste of resources.

2. Assess & evaluate. When performed regularly, risk assessments are the best tools for rooting out warning signs of issues as minor as an ambiguous contract term or as major as fraud. The intervals at which assessments are performed varies from company to company, but a good rule of thumb is to fill out an assessment every time something at the business changes: When processes are modified or extended, when new employees are hired, when staff turnover rates increase, or when relevant regulations are amended. Assessment frequency can also be modified depending on risk severity, and risk assessments should be required with all budget submissions to ensure that projects and initiatives are executed appropriately.

Truly effective risk assessments are those that are standardized. Standardization means results are understandable across departments—for example, IT managers should understand the risk reports that result from risk assessments designed and performed by finance. Each department should use the same enterprise-level criteria for categorizing impact (e.g., effect on net income, regulatory penalties, inability to achieve strategic plans); likelihood; and, ultimately, assurance, or the estimated effectiveness of mitigation activities. Assessments should also be pushed out to the most appropriate party.

This approach ensures that risk managers can aggregate non-sensitive department data cross-functionally, presenting an objective view of where resources need to be allocated. The goal of an ERM risk assessment is not to create a series of mutually exclusive reports, each of which focuses on risks within a single function. The goal is to create an interconnecting web of risk assessments that senior management can use to determine how resources can help mitigate threats and realize business opportunities.

3. Mitigate. Once risks have been identified and assessed, they need to be prioritized. Effective risk evaluation—and the subsequent design of mitigation activities—fits three criteria.

First, each control must be "linked" to the risks it mitigates. An ERM system provides users an easy way to pin controls to one or more risks, with the click of a button. When any other user accesses the system, he or she will see how, or whether, a particular risk is currently being addressed. This information streamlines the mitigation process, preventing redundancy by highlighting the risks that require the most attention. Note that mapping risks to controls in this manner is futile if the control documentation doesn't detail how the mitigation addresses a root cause of the risk, such as insufficient hiring guidelines, rather than a symptom of the problem, such as poor customer service.

Second, effective controls are "linked" both to relevant resources—such as third-parties, IT applications, policies, and data models—and to the business processes in which they operate. This is accomplished by building a repository of critical resources (something most organizations already have) and then determining which processes and mitigation activities depend on each resource. As an example, consider a specific control, such as a backup system for critical data, which relies on an internal IT application to operate correctly. Thanks to the resource repository, parties responsible for maintaining that backup system can see which other controls—for example, the organization's main firewall—rely on the same resource (the internal IT application). The web of connections shows risk managers who is involved in what process, and also simplifies resource prioritization.

Finally, the descriptions and details of controls should be updated regularly and published in a central location. This ties back into the fundamental flaw of siloed approaches: They don't allow managers in one department to understand how their risks and controls relate or connect to other departments. When corporate functions fail to collect, record, and share risk assessment results, they cause long-term issues of redundancy and inefficiency, even if the assessments are effective.

A good example of these concepts is the implementation of defenses against data-security breaches. The IT department may dictate the complexity and change frequency for employee passwords in specific systems. However, only the process owner in each department can determine whether his or her group has identified all the software applications for which IT regulates password changes. Neither IT nor the business process owners can identify, assess, mitigate, or monitor risk by themselves. All parties should be involved in the process—even if only for a few minutes each quarter—if mitigations are going to be effective.

4. Monitor. Risk mitigation leads to the last step in ERM: risk monitoring. It's one thing to implement controls; it's another to ensure that they're actually accomplishing what they should be. If a risk mitigation activity is performed correctly but does not address the root cause of the risk, the problem will never go away. For example, re-evaluating firewall policies to determine whether they are relevant and effective might appear to mitigate cyber threats, but if the real danger is phishing emails sent directly to employees, the root cause will remain unaddressed.

Organizations should execute a few steps to ensure effective monitoring. First, pushing risk assessments to all managers, from the front lines up through senior management, helps highlight emerging risks. When a risk's score for impact, likelihood, or assurance rises significantly, that is a sign that resources should be reallocated.

Second, companies should work to identify different areas that might benefit from a common control. Uncovering these interdependencies improves efficiency by reducing the number of tests that need to be performed; when you operate only one control instead of two, you only have to verify that one control is operating as intended.

Third, organizations need to collect and report on business metrics on a regular basis. For example, monitoring the percentage of risks with a higher overall score than the average mitigated risk can serve as a warning sign that risks aren't being addressed adequately. Another metric, a count of the mitigation and monitoring gaps related to corporate objectives, is calculated by mapping risks to leadership's annual goals. Consider a third example, the percentage of all front-line managers that are performing risk assessments.

If your organization's ERM and monitoring processes do need to be reevaluated, the best place to start is the RIMS Risk Maturity Model. The RMM is a free online assessment designed to give risk managers—and others—an immediate analysis of their current enterprise risk management programs. The RMM's umbrella framework benchmarks programs based on 25 competency drivers and their underlying readiness indicators.

Benefits of Well-Documented, Repeatable ERM

Back in 2009, a robust ERM program saved Morgan Stanley from legal liability when a managing director admitted to bypassing internal controls required by the Foreign Corrupt Practices Act (FCPA). Investigations revealed that the employee had plotted to evade the firm's controls in order to transfer ownership of a multimillion-dollar property in Shanghai to himself, a Canadian lawyer, and a Chinese official. Morgan Stanley emerged from the investigation with far less damage than would have been inflicted if the firm had not maintained an enterprise risk management program documenting the execution of related internal procedures.

When the Department of Justice looked into the matter, it found ample evidence of:

Effective change management. Morgan Stanley regularly modified internal controls related to the FCPA to remain in compliance with changing regulation line items.
Effective risk identification. The firm had identified specific risks related to asset accountability and bribery of foreign officials. Drilling down to the root causes of these risks enabled risk managers to develop appropriate mitigation activities.
A seemingly comprehensive controls framework. After identifying risks and assessing them for impact and likelihood, Morgan Stanley implemented controls designed to mitigate root-cause risks. Employees were required to go through multiple training sessions—54 for employees in Asia offices—to learn the ins and outs of related internal controls.

JPMorgan Chase and Morgan Stanley are two prime examples of the fact that a well-documented and repeatable ERM program not only reduces the occurrence of risk events, but also minimizes negative consequences if something does fall through the cracks.

Not even the most robust controls can prevent every kind of incident. Regulators and enforcers understand this, so they don't expect organizations to have a perfect track record. Instead, they look for pre-breach policies that demonstrate a reasonable effort to mitigate potential risk. Having appropriate ERM practices in place can make the difference between good publicity and embarrassing headlines (or worse).

Full Disclosure in Business-to-Business Relationships

Regulators aren't the only organizations that expect full disclosure about corporate risk management activities. CNA Financial Corporation pushes risk assessments out to its prospective insurance customers and requires prospects to meet specific risk management policies and practices in order to qualify for coverage.

One such customer was Cottage Health System, a nonprofit that manages hospitals in Southern California. When the healthcare company suffered a data breach in which more than 30,000 medical records were accessed, CNA refused to pay the claim on the policy. CNA uses its insurance application form to screen prospective customers, determining the likelihood and probable impact of future claims. Much like regulators, CNA requires prospective customers to document key procedures and to disclose any risk management weaknesses.

Heading off Liability

From an ERM perspective, all the court decisions we've discussed were entirely correct. Regulators like the SEC aren't looking for incident-free track records. They're looking for evidence of a repeatable effort across the enterprise to prevent incidents from occurring.

The CFPB's case against Dwolla dissipates the "it won't happen to me" mind-set. The CFPB oversees a wide variety of financial institutions—including banks, credit unions, and insurance agencies—meaning that a huge number of organizations could find themselves in Dwolla's shoes.

It's also apparent that company size is not an effective predictor of who will be looked at next. Dwolla is a small, private company with fewer than 200 employees. It doesn't take a fraud or data breach event to attract regulatory trouble, and the CFPB could easily turn its attention toward even smaller businesses.

For companies of all shapes and sizes, now is the time to implement a comprehensive enterprise risk management program. The risk of a tarnished brand reputation, and the serious consequences of negligence charges, are simply too high to disregard ERM any longer.

Steven Minsky is CEO of LogicManager, Inc., a leading provider of ERM software solutions, and a recognized thought leader in ERM. He is the author of the RIMS Risk Maturity Model (RMM) and corresponding 2008 and 2015 State of ERM Reports. Minsky is also a patent author in risk and process management technology and an instructor on many ERM and GRC topics.