The value of a risk register

January 21, 2017 52 comments

A risk register makes you feel good.

It makes you feel you have accomplished something, a list of risks that might cause harm to the organization.

It makes the executive team and the board feel that they can check the box: “do you have a risk management program? Yes.”

But, does that risk register help people formulate and then execute the right strategies for the organization to deliver optimal value?

Does it help people at all levels of the organization make informed and intelligent decisions?

In fact, does it do more harm than good? Does it give the false impression that risk to organizational objectives is managed at acceptable levels, when in fact decisions are made daily that do not give appropriate consideration to “what might happen”?

I did a small consulting project for an organization recently that wanted to improve its risk management. I pointed out that their annual filing with the SEC had 13 pages of risk factors. I asked whether they were used to enable better decision-making. The answer was a bunch of smiles. Frankly, I doubt that the executives present were even familiar with those 13 pages.

As I suggested in Risk in the Fourth Dimension, we need to consider what we are trying to achieve and why.

The purpose of risk management is not to produce or review a list of risks. It is to help the organization achieve its objectives by considering what might happen and acting to optimize outcomes.

What do the leaders and decision-makers of the organization need to be informed and successful?

Is it a list of risks?

Do risks remain static or are they dynamic?

In World-Class Risk Management I not only point out the need to manage the business at the speed of risk (I love the fact that others have adopted my phrase), which is dynamic, but that we need to consider the potential aggregate effect of risks on each corporate objective.

There are some risks that are transitory, such as those you consider when deciding which candidate to hire for an open position, and others that are continuing.

All you will see on a risk register (or for some a heat map, misleading as those charts are) are those that are expected to continue in some shape or form.

But even those continuing risks can change with surprising volatility, which is rarely indicated on a risk register.

A risk register or other form of list of risks does have some value, but it is limited.

I believe it is better to have a list of objectives and a continuing assessment of the likelihood they will be achieved.

That’s what matters. That’s why we need some form of risk management.

I ask again the question in Risk in the Fourth Dimension: are we just doing what we are told, as children, or are we figuring out how to help people make better decisions, as adults? That may be quite different from so-called traditional ERM, SRM, etc.

I welcome your comments.

Risk in the Fourth Dimension

January 15, 2017 12 comments

As a young boy, my family often spent our vacations at a hotel near Rimini, on the Adriatic coast of Italy.

The hotel owner had a six year old son. If I recall correctly, his name was Mario.

Mario only spoke a little English, which he had picked up from guests. But there was one word that he used all the time and which I recommend to you now.

The word, a magic word with amazing power, is “why”.

“Why are you going to the beach?” “Why do you want to swim?” “Why do you want a tan?”

Let’s think of the power of this word when it comes to risk and risk management.

For board members and executives, the question is “why should I spend my limited time on risk management? Do I do it only because it is expected or the regulators told us to do it?”

For risk practitioners, the question is “why should risk management be important to the organization and its leaders? Are its leaders only paying scant attention because it is expected or required for compliance with regulatory requirements? Why am I doing this; is it because my job is to help manage risk, or is it for some larger purpose?”

For internal auditors, the question might be “why should I assess risk management? Is it because that is what internal auditors are expected to do? Is it because it is ‘best practice’ or required by IIA Standards?”

I think these are all good questions that demand answers.

The answers are the key to unlocking the value of risk management.

The journey to the answer to the question ‘why’ starts with answering the question ‘what are we trying to achieve?’

We say that risk is about achieving objectives. So what are they? What are we trying to achieve?

We also say that risk management enables us to make more intelligent and informed decisions, and that making the right decisions is how we achieve our objectives.

So, every time we think we need to make a decision, we should ask “What are we trying to achieve?” followed by “Why are we making this decision?”

Now, we can start to think about what might happen (getting rid of the ‘r’ word, which only limits our thinking).

We can progress to additional questions, such as “Do I have all the information I need; am I involving the right people; how will my decision affect my and others’ objectives; what are the options; which is best; are any of the potential consequences of the decision unacceptable?” and so on.

But if you don’t have an answer to why you are making the decision and what you are trying to achieve, will you make the right decision?

For board members and executives, there has to be a rational and adult answer to “why should I care” and “why should I spend my time?”

As adults, we shouldn’t be doing things just because we are told to do them.

As children, when our mother told us to make the bed, did we do it well or just enough to get by?

If we were in the armed forces and the sergeant told us to make the bed, we probably made it better than was really needed for our comfort.

As adults, we make it (I hope) well enough to make the room look OK and our bed comfortable when we return to it.

As adults, we should manage risk because of its value to the organization, not because we are told to do it, because it is in the governance code, it is our job, or because of professional standards.

Understanding the value starts with “what are we trying to achieve?” on the journey to “why are we doing this?” and “what is the right decision?” The word ‘we’ includes us as individuals, as members of a team, but especially the interests of the organization as a whole.

Let’s take a specific risk management task, the report to the executives and the board.

Why do we do this, prepare and share the report?

What are we (the risk practitioner) trying to achieve?

What are they (the board and executives) trying to achieve?

Is this the right communication? Is it helping them achieve what they want to achieve?

Are we practicing risk management as children (doing what we are told or is expected) or as adults (doing so because it helps the organization and its leaders succeed)?

I welcome your comments.



PS – the title is stolen from the late Victor Mollo, author of two of my favorite bridge books, Bridge in the Menagerie and Bridge in the Fourth Dimension.



How much cyber risk should an organization take?

January 7, 2017 10 comments

I did a video with Joe McCafferty of MISTI last month. He wrote about it here, and you can find the video on YouTube.

I am interested in whether you share my views.

I also have some questions for you – after you watch the video:

  1. Should we be measuring cyber risk in relation to the potential effect of a breach on business objectives? Or should it be based on the effect on information assets?
  2. Do we know how to assess the level of risk?
  3. Are we doing a good job knowing how much risk we need to take to achieve our objectives? In other words, are we excessively risk averse or embracing of risk – and do we really know whether we are making the right business decision?
  4. Does it all come down to ROI, the cost and the value of additional investment in cyber prevention, detection, response, and remediation?
  5. Are we hyperventilating about cyber when there are more important risks to address?

I welcome your comments and answers.

The real risks: the ones not in the typical list of top risks

December 31, 2016 22 comments

This is the time of year when people are rushing to share the top risks to organizations across the world.

Those lists include such items as cyber, political change, economic instability, and so on.

Here’s a different type of list.

It’s comprised of risks that are perhaps the most critical but, for whatever reason, rarely figure on any risk register (those awful devices) or other ERM report.

They are not in any particular order.

  • Bad decisions, for any number of reasons such as involving the wrong people; relying on gut experience instead of information; failing to act; and so on
  • Poor information flowing to decision-makers and the board (it may be out-of-date, slow, incomplete, indigestible, wrong, or simply off the mark)
  • Hiring the wrong people
  • Not having sufficient people
  • Lack of teamwork
  • Lack of shared goals
  • Politics
  • Legacy systems that make the organization lack agility
  • Bureaucracy that slows decisions and stifles ingenuity and innovation
  • A bully of a CEO
  • Executives who don’t listen
  • Poor morale
  • High turnover of staff
  • Failing to fire poor customers
  • Ignorance of new technology that could disrupt the business
  • Being excessively risk averse
  • An ineffective internal audit function
  • An ineffective risk management function
  • A legal function that does not provide quality advice when it is needed
  • A CFO who does not get involved in the business and its operations
  • And so many more

I welcome your thoughts – and additions of risks that are too often overlooked, usually for political reasons.


An expert shares his views on the future of risk management

December 18, 2016 Leave a comment

James Lam has an impressive resume: Chief Risk Officer for major financial institutions, author of a respected book on ERM, consultant, and board member.

Recently, he wrote a white paper that is available through RIMS or Workiva, Next Frontier: Performance-Based Continuous ERM.

I think it is fair to say that James and I agree on many points but disagree on others.

For example, he is focused on managing the downside, while I prefer to think that we need to help decision-makers understand all the potential effects – both positive and negative.

You can decide for yourselves by reading his white paper.

Here are some excerpts that I like, with emphasis added. I will add some comments in a moment.

  • The scope and severity of risk is so great that doing so could mean economic destruction. Instead, risk management should become proactive, not simply minimizing negative risk but also maximizing opportunity. To do so, ERM must be a continuous process, constantly monitoring and assessing risk in a forward-looking way that provides companies with a path toward opportunity.
  • For these reasons, ERM is entering a third phase in its development focused on continuous monitoring, business decision support, and shareholder value maximization.
  • ERM programs must adapt expeditiously. A monthly or quarterly process is no longer sufficient. Just as risks and opportunities are changing continuously, ERM programs monitor and respond on a continuous basis.
  • In addition to becoming a continuous process, ERM must support key business decisions and add shareholder value.
  • To support strategic risk management decisions, the company’s performance management system must integrate key performance indicators (KPIs) and key risk indicators (KRIs).
  • Unfortunately, many companies perform these actions in two distinct siloes. As part of strategic planning, they perform steps 1 and 2 and report the results to the executive committee and full board. Separately, as part of risk management, they perform steps 3 and 4 and report the results to the risk and audit committees. In order to effectively manage strategic risks, these steps must be fully integrated.
  • In order to add value, the continuous ERM process must be integrated into the strategic, financial, and operational decisions of the organization.
  • The ERM dashboard should similarly organize risk information (e.g., quantitative metrics, qualitative risk assessments, early warning indicators) within the context of key strategic and business objectives. For each objective, the dashboard report might show green, yellow, or red indicators to signal that its achievement is on track, threatened, or off track, respectively. For objectives with yellow or red indicators, the board and management should then be able to drill down to underlying analyses
  • A key goal of an ERM dashboard is to highlight potential problems before they become critical. For that reason, the dashboard should include early warning indicators that help foreshadow such issues. A well-designed ERM dashboard would provide KPIs and KRIs that are most relevant to the decision-making needs of each user, whether at the board, management, or business-unit level. Ideally, each metric would include performance thresholds and/or risk tolerance levels to provide benchmarks for evaluation.

I say pretty much the same thing in World-Class Risk Management, but there are some important differences.

  • We need to address the combination of all the things that might happen. While James’ piece talks about seizing opportunities, with which I agree, he talks about individual risks and not the combination of good and bad things that may flow from an individual action or decision. He likes to show potential outcomes on a bell curve. I believe that is simplistic. A decision can and usually does have multiple effects and it’s the combination of them, some good and some bad, that needs to be considered when selecting among options. The net of all the good and bad may be positive, but one or more harms may be beyond tolerance while the net is acceptable.
  • I very much like the emphasis on supporting decision-making. However, we should put ourselves in the shoes of the decision-maker and ask “what is the information they need to make informed and intelligent decisions, selecting the best among all alternatives?” See this other post.
  • I fully agree that a periodic review process is insufficient. However, taking stock every so often is valuable.
  • I also agree that it is necessary to integrate KPIs and KRIs, but rather than a yellow/red/green traffic light assessment for each objective, I think you can take a highly valuable extra step. See A revolution in risk management.
  • I like the idea of dynamic risk appetite (although I prefer risk criteria that are designed to aid individual decisions). Business conditions change constantly and we need to constantly challenge prior notions of acceptable levels of risk. One of the problems of the concept of risk appetite is that it disregards the potential for reward. I don’t see where James has addressed this. As I said above, it is possible for the net of the good and bad effects to be acceptable while individual harms are not.

I encourage you to download and read James’ white paper. It gets into a lot of areas and provides advice that I have not highlighted here.

I welcome your thoughts and comments.

Selecting software to help manage user access risk

December 17, 2016 Leave a comment

In my last post on this topic, User access risk and SOX compliance, I talked about how a top-down, risk-based approach can help right-size the SOX scope when it comes to user access. It can reduce the number of access rules in scope as key controls from hundreds to less than twenty for many organizations. I also talked about how software is essential in managing access risk.

I believe software is essential in managing user access risk, not only for SOX but also for other business risks.

In fact, the potential harm from inappropriate access is typically greater for other business risk (such as the possibility of disruption of activities such as revenue generation or manufacturing, reputation risk, and the protection of valuable intellectual property) than it is for SOX.

The first step to selecting software, for this or any other purpose, is to define your needs. What do you need, which are the priorities, and how valuable is satisfying each need?

Is this just for SOX or, as I prefer, to manage all access business risk?

For most organizations, these needs will probably include:

  • A report that will identify violations of each access rule
  • A report of changes to access rules
  • The (provisioning) ability to scan requests for access, before such access is granted, to identify potential rule violations so they can be denied
  • The ability in the access provisioning system to ensure that the owners of each system, the manager of each employee, and others as needed, approve all requests for access
  • Reports for each owner of a system that will enable a review of who has access to each system he or she is responsible for
  • Reports for each manager so he or she can review what access their employees have
  • The ability to manage access within and across multiple systems, i.e., not just the financial systems or ERP, but every system where access needs to be managed
  • …and more

In many cases, a single software package will be needed. But where access to multiple systems is needed, it may be necessary to obtain a combination of software products.

For example, different software may be needed to run reports of access to the financial systems; a manufacturing system; a wire transfer system; and a system that manages physical access to buildings.

Given that, here are some criteria I would consider in selecting a software package:

  • Does it meet my needs, in particular those of the highest priority? Will it meet my needs for the foreseeable future?
  • How will I have to change my business processes? Will it support the way I want to do business?
  • What do current users of the software have to say about the vendor?
    • Do they say that the software meets their needs?
    • Are their needs similar to mine?
    • How easy is the software to implement?
    • How easy is it to maintain?
    • Is the vendor’s customer service excellent?
    • What other solutions did they consider?
    • Do they recommend this software?
  • What is the vendor’s reputation? Are there complaints or lawsuits against the vendor and do they relate to this piece of software?
  • Is the vendor financially sound? Is it committed to this software (if it has a small market share, it may limit future investment) or is this a small part of a larger offering? Is the vendor a target for acquisition?
  • How does the vendor manage upgrades or new releases? If there is a problem with functionality, how does it decide whether and when to issue upgrades?
  • Does the vendor have not only sales but also support staff who understand the business? Do they understand access management and how it needs to be managed?
  • Is the support and development staff substantial and able to maintain and upgrade the software when needed?
  • If, as is likely, consulting services will be needed to assist in the implementation of the software, are reliable consultants available, at a reasonable cost, who have the necessary expertise and experience? How good are their references?
  • What is the cost of the software, considering not only the initial acquisition cost but the cost of services that will be required to implement and then maintain it, and the ongoing software license cost?
  • Will the IT staff be able to provide necessary internal support? Will it be compatible with the network strategy?

A couple of thoughts from experts at consulting firms build on my points:

  • “When choosing your software, you want to make sure the vendor has the expertise to keep the methodology up to date. Otherwise, you may be constantly training your vendor,” Said Matt Bonser, Risk Assurance Director at PwC. “Choose a vendor that is making investments in their tools instead of making changes by only reacting to customer issues.”
  • “We recommend to our clients that they prepare a technology-agnostic solution design as the first step in selecting a GRC tool or any other enterprise-level application”, said Ronan O’Shea, Protiviti’s Global ERP Solutions practice leader.  “Analyze the business processes, business rules, data, event triggers, reports, etc. from an optimization and automation perspective and let the solution design, supported by critical use cases, drive the choice of technology, not vice versa.”

A vital consideration is the question of who will own the software within the company. I have seen situations where nobody takes ownership of the responsibility for managing user access risk.

I highly recommend resolving that question before acquiring software. Whoever will be responsible for managing the business risk from inappropriate access should lead the acquisition process.

Over the years, I have been involved in acquiring access software for several companies. Sometimes, it was straightforward but the more complex the business and the variety of access rules that need to be managed, the more critical it is to get this right.

If I was to leave you with one message it is this: make sure you have a robust provisioning capability. If you are able to prevent excessive access being granted, you will save the cost of the software quickly – IT and management won’t have to spend many hours chasing and correcting exceptions only to see new ones every month.

Most important, you will be able to maintain user access risk at acceptable levels.

In the previous blog post, I shared my story at Maxtor. The reason that new access violations kept appearing was that while reports were available to identify violations, the process for granting access was very weak. Our risk was high until we fixed the provisioning process.

I hope these two posts will strengthen your selection process.

Your comments are welcome.

User access risk and SOX compliance

December 12, 2016 6 comments

When you take a top-down, risk-based approach to the assessment of internal control over financial reporting (for Sarbanes-Oxley, “SOX”, compliance purposes), it is quite possible to make a significant reduction in the number of key controls included in scope.

The only controls that need to be included in the scope for SOX are those that are relied upon to either prevent or detect a material misstatement of the financial statements. We call those “key controls”.

In my best-selling book, Management’s Guide to Sarbanes-Oxley Section 404: Maximizing Value Within Your Organization, I suggest this definition:

A key control is a control that, if it fails, means there is at least a reasonable likelihood that a material error in the financial statements would not be prevented or detected on a timely basis.  

In other words, a key control is one that is required to provide reasonable assurance that material errors will be prevented or timely detected.

The top-down, risk-based approach (which US regulators require external auditors to follow and encourage management to adopt) focuses the attention on key controls.

Organizations have a great many controls designed to address their various business risks. The top-down, risk-based approach enables management to exclude from the SOX scope controls that may be necessary for other business reasons (e.g., to protect valuable intellectual property) but are not key controls for SOX.

It is also possible to limit the number of controls, or “rules”, relied upon for user access risk for SOX.

By “user access”, I am talking about access to computer systems not only by business users (such as those in accounts payable, manufacturing operations, or cash management) but by people in IT charged with maintaining the systems in question.

I have led training classes for SOX program managers for quite a few years. A recurring theme is that the organizations they represent may have hundreds of access controls (“rules”) in their SOX scope.

They don’t need them all, not for SOX. They are not all SOX key controls.

Some history may be required to explain what I mean.

Many if not most organizations designed the IT portion of their SOX scope, including access controls, separately from the business process and risk side. They did not take a top-down, risk-based approach to identify what might go wrong in IT processes and activities that would lead to a material error or omission in the financial statements filed with the SEC. Instead, they relied on some combination of:

  • Checklists from consultants and others that listed access that should be limited, especially combinations of access that might represent a segregation of duties problem
  • Their experience of what constituted best practice in limiting user access
  • “Rules” included by vendors in their access control software – typically these can number about 140

But very often these rules may be necessary to run the business but highly unlikely to result in a material error or omission in the financial statements.

Examples of rules I have seen that are not critical for SOX, not key controls that need to be included in scope, are:

  • Rules about who can authorize a purchase requisition or order. Even if an unauthorized individual orders millions of dollars of materials or services, the financial statements may be correct: they will accurately record the expense and the level of cash
  • Rules about the ability of HR personnel to access payroll records. While it is possible that fictitious employees are set up and paid, it is highly unlikely that would ever be material to the financials – and the expense, though improper, has been incurred

The question to ask for all access rules is “if this happened, if this access was granted, is there at least a reasonable possibility (given all other key controls) that an undetected material error would be introduced into the financial statements?”

But there is a need for some level of access control rules. Examples include rules where:

  • A key control limits who can perform an activity, such as the approval of a journal entry
  • Access needs to be limited to certain powerful system commands, such as “root” access, that would enable an individual to bypass controls

At my last companies, we applied a top-down, risk-based approach and were able to reduce the number of access control rules in scope for SOX from more than 100 to less than 20.

But, managing user access can be a challenge.

When I ran the internal audit function at Maxtor, a $4bn manufacturer of disk drives, I also led the SOX compliance work on behalf of management.

When it came to access controls, our top-down and risk-based approach allowed us to reduce the number of rules in scope very significantly.

But we still had a problem!

We used software to identify violations of the SOX user access rules.

  • The first time we ran the software, we had more exceptions than employees! Management agreed to take prompt action and we came back after a few weeks.
  • We reran the software and the number of exceptions was down from the thousands to a couple of hundred. Some were repeat exceptions that management had missed, but an equal number were new ones! Management again agreed to act quickly and we returned in about two months.
  • Again we ran the software. This time, there were no repeat exceptions. But there were over a hundred new ones. We told management that time was running out to correct the situation before year-end.
  • We ran the software with hope and trepidation. Fortunately, there were less than ten exceptions and we were able to identify some mitigating controls, to the extent that we did not have a material weakness for SOX.
  • Around year-end, our external auditors ran their software to test these key controls. I went to my knees in prayer. Thankfully, their scans came out clean.

The right software can help you manage access risk. In fact, I am not sure that the typical organization can manage it acceptably without software. That will be the subject of a second blog post on this topic of user access.

For more on this issue, please refer to Management’s Guide to Sarbanes-Oxley Section 404: Maximizing Value Within Your Organization.