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
- 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.
HAPPY NEW YEAR!
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.
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.
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.
My good friend, Jay Taylor, recently had a piece published in the Private Directors Association newsletter. Culture: The One Element Most Critical For The Board’s Management Of Risk makes some interesting points.
After pointing out the need to ensure an appropriate culture by referencing some management gurus, he shares 6 questions for board members to ask of management.
- Is the CEO active in creating the culture for the organization? Is he or she modeling the right behaviors?
- Is there appropriate tone at the top, both during and outside of board meetings?
- During strategy, product, and investment discussions, is there transparency around business assumptions, openness to respectful but challenging views, and identification of emerging risks to the business model beyond the immediate planning horizon?
- Is there a willingness to bring forward bad news? Is there an understanding that failure may occur, but the business cannot grow and prosper without taking smart risks?
- Has the board established clear expectations for timely identification and handling of risk, particularly those around business goals and objectives? Is there clear risk ownership?
- Not everything should be filtered through the CEO. Are other executives and risk owners present at board meetings and allowed to take questions directly?
I would add a few of my own. These are questions the board should address to the CEO:
- How would you describe the organization’s culture?
- What do you see as an effective culture? Is it about ethics, risk, teamwork, or more?
- Is it acceptable? How do you know? If not, what are you doing about it?
- Are you getting objective feedback that tells you whether the culture is really the way you think it is?
- How do you make sure it remains the way you need?
Jay also shares eight red flags that may indicate that when it comes to risk, the culture is not what you desire.
These are all good, and I am sure you could add a few more.
But let me ask you, as I have in other posts, isn’t there more to culture than how risk, ethics, and compliance are addressed? Isn’t culture the driver of optimal performance as well?
I welcome your views.
PS – my thanks for Jay for recommending my World Class Risk Management book.
The Risk Management Association has published Key Principles of Operational Risk Management.
Designed by practitioners at financial services organizations, the document make a number of good points.
But let me start with what is missing: guidance on when to take risks.
When an organization is focused on avoiding failure, it is very hard to be successful.
Operational risk is basically about the things that can go wrong in day-to-day processes that can trip you up.
It is impossible to eliminate such risk.
The best you can hope for is to take a level of risk that is appropriate given the business and what it takes to be successful.
It’s not even about “balancing” risk and reward. The potential for reward should always be higher than the potential for loss – but the key is to use the same assessment methods to understand the potential range of positive effects or outcomes as is used to assess the potential harms.
Recognize that it’s not ‘either or’ reward or loss. It is highly likely that both will occur!
Anyway, the guidance makes some good points:
- Risk management is an integral part of business management and should be incorporated into overall business and financial planning.
- Business culture within institutions must embrace the value of risk escalation and welcome independent challenge of risk decisions. Soliciting multiple points of view and engaging in debate result in better, more informed decisions
- Senior management should provide direct oversight of current and emerging exposures. Meanwhile, risk management should be part of the normal management process and governance, not be made a separate, adjunct function.
- Risk teams should be established with qualified, high-performing professionals who are closely integrated with business operations and the decision-making processes.
- Effective risk management is a basic responsibility of business leaders and managers.
- Risk management activities dictated solely by remote oversight functions lacking detailed execution experience are highly prone to error and inefficiency.
But I have a problem with the traditional perspective in this section:
As part of sound business and strategic decision-making, operational risk implications must be assessed and considered in order to determine whether to
- Manage the risk.
- Tolerate the risk.
- Transfer the risk (for example, by insuring against the risk).
- Decline the risk.
To be successful, sometimes you need to take the risk, even to embrace the risk because of the potential for reward.
The attitude of tolerating or even accepting the risk is simply wrong. Take it happily!
If financial services organizations fail to take the right level of the right risks, they will fail and fade away.
I welcome your comments.
My apologies in advance to all those who talk about third-party risk, IT risk, cyber risk, and so on.
We don’t, or shouldn’t, address risk for its own sake. That’s what we are doing when we talk about these risk silos.
We should address risk because of its potential effect on the achievement of enterprise objectives.
Think about a tree.
In root cause analysis, we are taught that in order to understand the true cause of a problem, we need to do more than look at the symptoms (such as discoloration of the leaves or flaking of the bark on the trunk of the tree). We need to ask the question “why” multiple times to get to the true root cause.
Unless the root cause is addressed, the malaise will continue.
In a similar fashion, most risk practitioners and auditors (both internal and external) talk about risk at the individual root level.
Talking about cyber, or third party risk, is talking about a problem at an individual root level.
What we need to do is sit back and think about the potential effect of a root level issue on the overall health of the tree.
If we find issues at the root level, such as the potential for a breach that results in a prolonged systems outage or a failure by a third party service provider, what does that mean for the health of the tree?
Now let’s extend the metaphor one more step.
This is a fruit tree in an orchard owned and operated by a fruit farmer.
If a problem is found with one tree, is there a problem with multiple trees?
How will this problem, even if limited to a single tree or branch of a single tree, affect the overall health of the business?
Will the owner of the orchard be able to achieve his or her business objectives?
Multiple issues at the root level (i.e., sources of risk) need to be considered when the orchard owner is making strategic decisions such as when to feed the trees and when to harvest the fruit.
Considering, reporting, and “managing” risk at the root level is disconnected from running the business and achieving enterprise objectives.
I remind you of the concepts in A revolution in risk management.
Use the information about root level risk to help management understand how likely and to what extent it is that each enterprise business objective will be achieved.
Is the anticipated level of achievement acceptable?
I welcome your thoughts.