Lines of businesses, legal entities, functions, people, business processes, risks, controls, products, projects, programs, strategic initiatives, servers, facilities, suppliers – the business of doing business is complicated. And if we are to create a well-governed and risk-aware organization that reaches for the sky on the shoulders of GRC, then we need a simple and consistent way to handle all this complexity. Furthermore, as with all foundations, creating it requires a solid understanding of what we’re going to put on top of it. So, a comprehensive GRC foundation will need to be informed by GRC activities such as policy management, risk management, supply chain governance, IT risk, security, etc., so that it, in turn, can support all these activities with a common framework.
Before we get ahead of ourselves, if you’re still wondering what ‘GRC’ is, then here’s a quick introduction to the topic. OK, with that out of the way, let’s move on and enlist the help of our friendly neighborhood banana company, ‘The Wide World of Bananas, Inc.’ to be our role model for the day. “Why ‘bananas'” you say? Well, that’s easy – because they are yellow, healthy and such a fun fruit! And, like the banana, the business of growing and delivering them to your friendly neighborhood grocer hides more complexity than the surface lets on.
In this slideshow, Vasant Balasubramanian, vice president of product management at MetricStream, takes a closer at building a strong foundation for GRC.
Click through for elements that should be addressed when building a solid GRC foundation, as identified by Vasant Balasubramanian, vice president of product management at MetricStream.
Can’t I just build a wall first and worry about the foundation later?
No. Not really.
There are three primary reasons for spending some time upfront developing your GRC foundation:
- Create a simple model of a complex business: Large bananas, small bananas, plantations, workers, weather, fertilizer, transportation, financial data, IT assets, facilities, etc. – working with ‘The Wide World of Bananas, Inc.’ example – the business of doing business is not easy. Factor in all the banana peels dropped by workers snacking on bananas on the sly and this makes for a very complex and risky work environment. A simple GRC foundation data model based on best practices allows you to reduce all the complexity into well-defined libraries (risks, organizations, processes, etc.) with clear relationships between them.
- Create consistent language and terminology: We are a banana company! Let’s make sure that we’re all talking about bananas and bananas alone. No oranges, no pomegranates and no onions either. In other words, if we’re talking about our products, let’s make sure that we’re all talking about the same set of products. If we’re talking about risks, let’s make sure that we’re looking at them consistently. The risk of business data loss is the same risk whether it is in a line of business or whether it is in HR. The impact and implications are different in each case, but the risk is the same.
- Properly support downstream GRC activities: Say we start building GRC out in the group that ships bananas worldwide. Their risk library likely starts off with Level 1 risks for weather, shipping delays, improper packaging, etc. Say we go ahead and implement this as our risk library at first, and then along comes the CIO looking to implement an IT risk program. As the CIO’s team starts thinking about IT risks, they suddenly find the first level of the risk library full of low-level shipping-related risks. The answer, of course, is that the organization should have anticipated future growth and placed the detailed shipping risks at (say) Level 3 under ‘shipping’ as a Level 2 risk and ‘operations’ as a Level 1 risk. This would have allowed the IT group to subsequently create an ‘information technology’ Level 2 risk under ‘operations.’
Organizational structure and lines of business
To create a well-governed organization, it goes without saying that you need to know the organization’s structure. Within most organizations there is usually a single (or preferred) ‘source of truth’ that depicts the organizational structure. Go with that one.
However, for the purposes of GRC, it is not really required to map risks and business processes down to the most granular level of the organizational structure. Greater granularity of information means greater fidelity in decisions – but it also means a LOT more work and, possibly, noise. So, it is important to pick the right level of the organizational structure for various GRC activities so that it adds net value without overwhelming the practitioners that are administering the GRC program.
In banana-lingo – you probably care about the banana plantation in Jamaica, or maybe even the different functions within that plantation (if it is big enough), but at the level of GRC monitoring, you probably do not need to track the different teams of workers working under different foremen in different parts of the plantation.
Laws, regulations, standards, and then … more regulations
One of the most quoted realities of our times is that we live in an increasingly regulated world. Regulations govern working conditions, pesticides and fertilizers, packaging, shipping, accounting, data – the list goes on. When building out the GRC foundation, it is not important to know all the regulations that your organization is ever going to be subject to. All you need to do at the outset is have a well-defined way of modeling regulations, frameworks, authority documents, standards and citations as well as their relationships to controls, policies, etc. Then, as you expand the scope of the GRC program as well as the extent of your business, it is relatively simple to bring new regulations into scope and do more of what you are already doing with one or two regulations.
In reality, if regulatory compliance is not one of the first cornerstones of your GRC journey, then you just need to be aware that you will put the cornerstone in place at some point in the future and link it to other aspects of your GRC program at that point in time.
Speaking the lingua franca of business objectives & risks
A common set of clearly articulated and measurable business objectives goes a long way in ensuring organizational alignment and eventual attainment of the goals. Documenting these business objectives within GRC enables organizations to proactively measure risk and put controls in place to reduce the risk of missing the objectives. In other words, if ‘The Wide World of Bananas, Inc.’ identified a business objective to sell 50 percent more bananas in Europe within a year, they would be well served to measure the risks that might prevent them from attaining that objective, and then putting preventive controls in place to mitigate that risk.
And this brings us to the risk library. This is one of the central components of a GRC foundation and it is important to take the long view when planning out a risk library for your organization. Typical risk libraries are hierarchical in nature with six to 10 risks at Level 1 and three to 10 sub-risks at any given level. A risk library may be anywhere from one to four levels deep. Anything beyond three to four levels of hierarchy starts becoming far too granular and then you’re left ‘sweating the small stuff’ – like whether you should package 12 or 13 bananas in a box.
While designing the risk library, note that types of risk assessments as performed by different business groups may be performed at differing levels of the risk hierarchy. For instance, enterprise-level risk assessments may be conducted on organizations by reviewing just the six to 10 Level 1 risks. On the other hand, an IT organization conducting IT risk assessments may assess risk to critical business processes by measuring more granular risks at (say) Level 3 of the risk hierarchy.
And everything else…
In addition to these basic elements, other components of a GRC foundation may include business processes, functions, assets, asset classes, suppliers, services, products, projects, programs, etc. The specific choice of which of these components make it into your GRC program and when depends on the order in which you fold in additional GRC activities and programs along your GRC journey.
And, lastly, any conversation of a GRC foundation would be incomplete without talking about relationships between the different data libraries. For instance, one or more business processes reside in one or more organizations. One or more IT assets may support one or more of these business processes. One or more controls may apply to one or more of these IT assets, and so on. Decisions about which relationships are relevant and important to put in place, again, depend on the order in which your GRC journey unfolds. For instance, our banana company will likely start off modeling shipping providers and connecting them to granular Level 3 risks under a Level 2 risk called ‘shipping.’ Subsequently, as the IT team comes on board the GRC program, they will map assets and asset classes to the same risk library … but to Level 3 risks under the ‘information technology’ Level 2 risk. And so on.
To be sure, it is unlikely that you will start on all the different GRC foundational components that we discussed here because your GRC activities will likely evolve in phases over time, giving each phase time to be absorbed by the organization, and in turn informing the next phase. However, it is important to have a vision for where your GRC journey will eventually take you and ensure that you are making the right decisions upfront that will bring you to success on that journey without too many deviations. With a little planning upfront, that bright yellow glow in the distance may be a bright new tomorrow … or a big pile of bananas, depending on your point of view.