ERM: The basics

An introduction to ERM (Enterprise Risk Management) for security, IT and operational risk professionals. ISO and COSO frameworks; risk measurement and prioritization; mini-case studies and real-world ERM examples.

1 2 3 Page 3
Page 3 of 3

What are some other tips for implementing successful ERM programs?

One approach suggested by Steinberg is to use risk concepts in the strategic development process and related implementation planning. Companies can also try setting up an ERM program for one business unit, with a leader who is well respected, and see the successes and benefits it brings to that unit and how it can be extended to others in the company.

In a midsize company, you can take a big-bang approach, where an ERM process is developed and rolled out for the entire organization, he said. This can work if you've got the support of top management to develop and design how risk management will be deployed, with an appropriate implementation plan, along with training and all the elements of an effective project and change management.

If CFOs, compliance officers and other senior staff managers band together, Steinberg said, they can be a major influence in getting senior operations executives to consider that risk management is good management. They can be a positive force in moving an organization to deal effectively with risk in a strategy setting and integrate risk management principles into business objectives.

For security leaders in organizations without an effective ERM program, it can be useful to work with other corporate leaders, such as the CFO and chief compliance officer. In some companies, this group of executives has been able to influence and persuade the CEO to support an initiative that brings ERM to the fore.

Smart in theory...Give me an example of translating ERM into action.

Georgetown University provides a good example of turning the concept of ERM into specific systems and projects that reduce risk. Three years ago, cAt one time, campus-wide security was handled in several departments, with little coordination among teams. The university had experienced more than one significant security project failure and data security breach, according to Bill Badertscher, senior engineer for facility and safety control systems.

Leaders at Georgetown recognized that a strategy was needed to address systems in the facilities and security spaces. Led by CIO Dave Lambert, that strategy included the formation of several new groups within IT.

Their first step was to conduct a risk assessment to prioritize spending needs. They then established a budget to immediately replace some legacy systems, including access control and video surveillance. Other priorities included emergency response and fire-protection systems.

Another early step was for IT to take a leadership role in replacing departmental systems and independent cabling networks. Nearly all the new systems now interface with the data network, which was able to accommodate the power and communication needs. The philosophy was to leverage the data network as much as possible and closely manage data security along the way.

The university's ERM program is not just about facility and security control systems, Badertscher said. New groups were also established to take responsibility for scholarly information systems; research and regulatory administration; data security and policy; and advancement.

The end result is a collection of new initiatives that are reaching out across the university to address enterprise risk.

One of the bigger challenges, according to Badertscher, was the roles and responsibilities issue. There was initially some defensiveness among the departments, where people wanted to know why IT was stepping into what they thought of as their turf. Badertscher's group communicated that they were not trying to take over operations in those spaces but simply needed to understand their business needs. They set up a simplified approach, in which the business units describe their needs, and Badertscher's group describes how that is accomplished through technology.

Legal principles are a driving force in Georgetown's ERM strategy, particularly where it comes to prioritizing risks, according to Badertscher. This is because the most significant risks are incidents that lead to lawsuits or negatively impact the school's reputation. A key element that comes into play, then, is understanding "due care," which is the care that a reasonable person would exercise under the circumstances. Further, the university practices due diligence to make sure the security controls it puts in place are effectively operationalized and maintained.

There is also the matter of foreseeability, Badertscher said. For example, he said, if assaults were occurring in particular areas of the campus, the university cannot turn a blind eye to those incidents. Established case law outlines what universities should do to protect parking lots, for example, or residence halls. Further, the school needs to evaluate what its peers are doing and stay on top of best practices. The very real connection between what Georgetown is doing and how well it mitigates risk is based on the legal consequences of what it does, Badertscher said.

In the end, while various stakeholders across the university have their own ideas about what good security means, decisions must be based on a clear understanding of the risks involved, Badertscher said. This includes identifying Georgetown's assets and assessing the threat environment and its vulnerabilities—and then communicating its plans. (For a more in-depth look at Georgetown's ERM implementation, read All systems go.)

When we're ready, what's the best way to organize for risk management?

Implementing ERM typically means creating a single, centralized department or formal team that is responsible for risk. Because this usually means bringing together functions now spread out across many business departments, there can be turf battles and other pushback unless the program is initiated from the C-suite, and senior management has bought in to the change.

Here are three sample organizational charts [pdf link] depicting different approaches to a centralized ERM function.

-- In the first, the operational risk and compliance functions report directly to a chief risk officer (CRO). In some financial organizations, the CRO coordinates this work with views into market, credit and related financial risks, using dotted-line reporting relationships.

-- The second org chart depicts the operational risk aspect of ERM. Dotted-line relationships—for example, from the director of information security to the CIO—often connect risk-related work to other departments.

-- The third chart shows how CSOs are rising in the executive ranks, without always gaining solid-line authority over key security staff.

Another way to understand how organizations should restructure to accommodate an ERM function is through the experience of other companies. Here's a quick look at how ERM evolved at three companies, all of which created a single ERM entity, backed by the highest levels of the organization and functioning as a highly visible partner:

Synovus Financial: The company appointed its first Chief Risk Officer in 2008, who introduced a much more focused approach to risk assessment and how risk plays into the company's decision-making. Previously, ERM was aimed primarily at credit risk, and information security was responsible for perimeter concerns, such as firewalls, intrusion prevention, information security policy and vendor due diligence.

Establishing a CRO position was essential because it showed the company's commitment to getting a handle on all its risk and that someone was leading the charge from the top of the organization, according to the director of operational risk.

Once the CRO was in place, the ERM team focused on what exactly should fall under the direction of risk management. It concluded that anything about risk assessment, monitoring or governance should be directly under the team, while day-to-day management of aspects such as firewalls would be left to the proper department. In all cases, the risk management function retains ultimate authority for actual policies.

AXA Equitable: The senior vice president of risk management was traditionally responsible for just business continuity issues. But at the urging of his CEO, he soon added privacy, information security and records management to his portfolio. When the consolidation started, most of the risk assessment capability resided in IT. The CIO cooperated in the transfer and now views the risk department as an essential partner in IT's operations.

To encourage the required cultural transformation and buy-in, AXA hold an annual three- to five-day, companywide exercise in business continuity and crisis management. This popular program ensures the entire company is aware of the plans and how to carry them out.

Providence Health and Services: Led by the CFO, the ERM initiative unified the information and physical security, audit, compliance, risk and insurance departments under a single person, the CISO. As a result, instead of having many separate meetings about each of those issues, there was one entity providing advice and answering questions. Additionally, the business began turning to the CISO for help, instead of him having to insert his department in what others were doing.

(For a more in-depth look at how these three companies merged their security operations with ERM, see Risk's rewards: Organizing for ERM.)

My organization has 'risk managers' who oversee our insurance purchases. How does that fit in?

The work of security operations and risk managers are intertwined - or should be. If you run a security operation that oversees operational risk, it's important to know what's on the mind of the risk manager and vice versa. Risk managers who want to buy a policy need to know what is being done in terms of the internal control environment.

Good information security controls can affect policy costs and other terms, according to Christopher Taylor, head of Zurich North America Commercial's Financial Institution segment. Companies should really understand how they've protected information in the past, how well they're doing it now and ways to improve what they're doing, he said. Ultimately, the cost of insurance will vary according to their particular situation.

When speaking with the risk manager—as well as the C-suite executives— security people need to tell them what layers of security are in place and the likelihood of a breach, Taylor said. They should also demonstrate they have done everything possible to minimize the likelihood of a security breach. (You can read more on Taylor's views of security threats, corporate risk and insurance in our Q&A, herein: What are your risk managers thinking about?)

Good communication with risk managers can help reduce your company's Total Cost of Risk, or TCOR.

What's TCOR?

Total Cost of Risk is a longstanding concept in the insurance risk management world. According to David Bradford, who conducts a TCOR benchmarking study for RIMS, the Risk and Insurance Management Society: "The concept is maybe a little deceptive when you say 'total cost of risk.' It's the total cost of things risk managers are responsible for. The idea has been around since the 1940s or '50s. The way we traditionally define it for purposes of the RIMS Benchmark survey, it's:

  • the cost of insurance
  • plus the cost of the losses that are retained instead of or as part of your organization—for example, risks the policy doesn't cover, or a company's deductible
  • and the administrative costs of the risk management department."

The formula and concept are evolving as corporate risks themselves evolve, and as ERM concepts forge new organizational approaches. At any rate, the more accurately insurance risk managers understand the actual security control environment, as well as the organization's risk appetite, the better they can purchase the right policies.

We're numbers-driven, but it's hard to quantify security risk. Especially on the IT side.

It's true that there are a lot of subjective estimates of risk in information security. And yet, done properly, risk management applies science to the problem.

Hubbard argues that IT is not as unique as its practitioners sometimes claim it to be, and that most organizations can start making better decisions without collecting tons of new data. There are "some very complicated models sometimes, but if the standard is not to have a perfect model but to simply outperform human intuition, then all we need to do is identify and remove certain known errors from human intuition," he said.

"If you have 20 sources of error that you know about and you got rid of 10 of them, you have less uncertainty than you had before. So you don't actually even have to have complete models," Hubbard noted.

(See the full text of the discussion, starting here: The great IT risk measurement debate, part 1.)

Additionally, several formal IT risk assessment frameworks have emerged over the years to help guide security and risk executives through the process of assessing and quantifying risk. Here's a quick look at these key frameworks; for a deeper look, read IT risk assessment frameworks: real-world experience.

OCTAVE (Operationally Critical Threat, Asset and Vulnerability Evaluation), developed at the CERT Coordination Center at Carnegie Mellon University, is a suite of tools, techniques and methods for risk-based information security strategic assessment and planning. Three different versions of OCTAVE are aimed at organizations of different sizes and maturity levels.

OCTAVE is designed to be self-directed and flexible to meet particular risk environments, security needs and skill levels. It aims to move organizations toward an operational risk-based view of security. A key strength is that it's thorough and well-documented. It considers all aspects of information security risk, from physical, technical and people viewpoints, proponents say, and can help your organization better understand its assets, threats, vulnerabilities and risks. Drawbacks at the time of this evaluation included its complexity and that it doesn't allow organizations to mathematically model risk.

FAIR (Factor Analysis of Information Risk) -- championed by Jack Jones, the former CISO of Nationwide Mutual Insurance -- is designed for understanding, analyzing and measuring information risk. It is designed to address security practice weaknesses, Jones said, such as a heavy reliance on practitioner intuition and experience, industry lore and best practices.

FAIR components include a taxonomy for information risk, standardized nomenclature for information-risk terms, a framework for establishing data-collection criteria, measurement scales for risk factors, a computational engine for calculating risk and a model for analyzing complex risk scenarios.

A strength of FAIR is its common language, which allows people from IT and the risk management practice to discuss risk in a consistent manner. It also allows for mathematical modeling of loss exposures, and its taxonomy enables more detailed definitions of threats, vulnerabilities and risks.

On the downside, FAIR can be difficult to use and was not as well-documented as OCTAVE. Users also cited a lack of access to current information about the methodology and examples of how the methodology is applied.

NIST RMF (National Institute of Standards and Technology's Risk Management Framework) outlines a series of activities related to managing organizational risk that can be applied to both new and legacy information systems, according to the NIST.

Proponents say the framework helps to both assess and manage risk. Its primary strength is that it was developed by the NIST, which is charged by Congress with ensuring that security standards and tools are researched, proven and developed to provide a high level of information security infrastructure. The framework is constantly being reviewed and updated as new technology is developed and new laws are passed. Furthermore, independent companies have developed tools that support the NIST standards.

As for weaknesses, like any of these frameworks, you have to make sure that the people who are doing the risk assessment have the discipline to put reasonable data into the model so you get reasonable data out, users said.

TARA, the Threat Agent Risk Assessment, is a risk-assessment framework created by Intel in 2010. It was designed to help companies manage risk by distilling the immense number of possible information security attacks into a digest of only those exposures that are most likely to occur. By using a predictive framework to prioritize areas of concern, organizations can proactively target the most critical exposures and apply resources efficiently to achieve maximum results.

Proponents say TARA is a good tool for identifying, predicting and prioritizing threats against your infrastructure. They also like TARA's "threat agent" view of risk; that is, the threat agent library and the methods and objectives library can be easily used within other risk-assessment methodologies, especially if there is a need to standardize on common threat agents and corresponding methods.

An early weakness noted was that it only addressed the likelihood of threat events, but doesn't take into account the risk's impact.

We use GRC software. Isn't that essentially the same as ERM?

There are many benefits to using governance, risk and compliance (GRC) software, as outlined in a recent CSO case study on Fiserv. However, first of all, it's important to remember that GRC is a process supported by technology, and companies should avoid focusing only on the software.

As Murray Walton, Fiserv's senior vice president and chief risk officer, points out, an effective risk-management program is part of an organization's quest for self-awareness. "To begin with technology rather than process is to risk letting the tool define the program rather than support it," Walton said.

"Before you can decide which tool meets your needs, you need an overarching process that helps assess your business and its assets, vulnerabilities and risk appetite."

Only when a company understands these baseline concepts can it really know how a GRC software solution will fit into its risk management program.

Some have compared the use of a GRC system as a flashlight, shining into the dark cupboards of your organization. But even though GRC can immensely improve your risk and compliance fact base and reporting capabilities, you still need to determine how to most effectively use the increased insight to improve risk management in your organization.

At Fiserv, GRC software "empowered our risk management staff to operate on a higher, more strategic plane," Walton said. It automated time-consuming tasks, simplified reporting and enabled the company to quickly understand where to focus its remediation efforts, investments, policy, people issues. "Rather than spending all that time figuring out where the risk is, we now get that intelligence from the system, and can spend more time addressing what we've found."

Another benefit is the increased credibility the ERM team has gained in its interactions with management, regulators and members of the board of directors. And because the GRC element is a packaged solution, it doesn't skip steps, Walton said, "It enforces a rigorous, process-driven approach to risk management that is inherently missing in the kind of homegrown, paper-based processes we used before." (Read more about Fiserv's GRC undertaking.)

Bottom line: GRC work can support and enhance ERM work, which in full form is broader than what GRC typically covers.

Ultimately what will be the role of security and the CSO here?

Risk touches everyone in the organization, so in some ways, everyone in the C-suite owns a portion of the enterprise risk management job. At the same time, it's essential to centralize oversight of risk management for the enterprise in a single entity.

That entity may or may not be the CSO. Some organizations appoint a chief risk officer, and others may assign ERM to another position or job title. But while the CSO is not always in charge of ERM, he or she is always a critical contributor in helping executives and the rest of the organization view operational risk elements.

The job of the enlightened CSO is to help those executives see their common challenges and address them in a way that facilitates cooperation between departments and helps connect the various functions within the company. For instance, improving loss prevention helps both the CFO and the COO, while improving investigations processes helps both Human Resources and Legal.

So, rather than simply trying to "build a great security department," the CSO is actually a connector. Your job is to help forge strong connections between other departments specifically on issues of operational risk.

This connector role is hugely important for companies today and can even establish competitive advantage if you see it in context of Harvard business professor and consultant Michael Porter's conception of the "value chain." In Porter's idea, companies with smooth interconnections among departments (sales, marketing, finance, manufacturing, etc.) will be faster, more nimble and more competitive than those that don't have the same fluidity. If you remove friction and solder smoother connections, Porter said, you are providing a basis for competitive advantage for your organization.

Seen in this light, the CSO has an essential role in ERM: Connect the functions within the company by helping everyone understand the risk elements. By reducing friction among the various departments, CSOs can build value into the value chain.

Copyright © 2013 IDG Communications, Inc.

1 2 3 Page 3
Page 3 of 3
Microsoft's very bad year for security: A timeline