What is GRC (Governance, Risk and Compliance)?

“Great minds can build a business that works – and then create a recipe for it. Others need a recipe to build a business that works.”

The father of GRC, Mr. Michael Rasmussen introduced the GRC acronym in February of 2002. In 2003, the OCEG (Open Compliance and Ethics Group) released a model and a framework for GRC. The acronym was officially established, and it denotes three words; Governance, Risk, and Compliance. Although many are not aware of the inherent value and meaning of GRC, every company on this planet is doing GRC. Formally or informally. Just as OCEG says, “GRC is not something new. Totally Revolutionary”. To understand why Mr. Rasmussen and OCEG combined these three words into what has become a widely respected concept, let us first have a look at this story.

In the year 2001; one of the greatest companies in the US was just awarded “America’s Most Innovative Company” by Fortune magazine – for the sixth year in a row. The dot-com era had just reached its peak and consequently, most investors and regulators were used to the new normal of exceptionally high share prices. Combined with the era’s minimal regulatory environment, this allowed the CEO to be “creative” and hid toxic assets and losses in a plot involving the CFO, other executives, and even its auditor. In what we now know as the time’s biggest corporate bankruptcy to ever hit the financial world, Enron^[1] collapsed in December 2001 leaving behind a shareholder loss of $74 billion, the loss of billions in pension benefits for its employees, the collapse of the audit firm Arthur Andersen, and not to mention all employees, business partners, and further financial and societal implications as a result of people and businesses losing their income.

Although Mr. Rasmussen had a broad vision for GRC v. 1.0, what the Sarbanes-Oxley Act of 2002 (SOX) introduced as a direct response to the Enron scandal, was the focus for every company in the financial sector at that time. Basically, GRC 1.0 became the recipe for how to run your company adhering to SOX internal control requirements.

Let us have a look at a very different story:

Imagine yourself creating a business – it is the year 2005. You have a great business idea where you will allow anyone in the world to transfer money to anyone by using an online service. However, you decide to start out small, so your first milestone is to have a local company use your service to pay salaries to all employees without the hassle of sending checks by mail. You decide that you want to sell it as a subscription-based service and provide it as a Software as a Service (SaaS). It becomes a great success, your customer loves it. You decide to go for the next milestone. 100 more companies and added features that allow the users to use the service for personal use in the new evolving webshops to pay for goods using their personal credit cards on file. You build a team of developers, a few executives to help you run the business, a back office, and a few sales representatives. Your success continues. One day your servers are hit by a cyber-attack exploiting an error in your code that renders your service unavailable for five days and causes a massive leak of data – this happens the day before payday. Your customers are furious as it becomes visible all over the media.

This incident caused your customers a loss of productivity, the inability to pay salary on time, loss of their employee’s personal data including usernames, emails, passwords, bank accounts, and credit cards on file. And, it caused your own company the loss of reputation, loss of customers, and a couple of lawsuits resulting in fines that caused a 2-year financial setback including 50% layoffs.

If we pretend that we conduct an investigation or a GRC assessment after the incident
presented above, we might come up with brutal findings like these examples:

The customer

1. Risk assessment for the salary payment process
   • No risk assessment was conducted for the salary payment process, leaving top management unaware of the risks associated with it.
   • Lack of a 3rd party/Vendor Risk Management process
   • A risk assessment of their internal salary payment process and the associated 3rd parties involved would have revealed the likelihood of not being able to pay on time due to a failing 3rd-party process step.
2. Responsibility for the salary payment process
   • The investigation uncovered that no responsibility was formally assigned for the salary payment process.
3. Contingency plan if the process fails
   • No contingency plan was implemented in case of a failing process
   • Risk assessment and formal responsibility for the salary payment process could have led to the establishment of a contingency plan upon a failed process – if the process was deemed business-critical.
4. Policy for 3rd parties
   • A policy for how to govern and manage 3rd parties that are involved in business-critical processes did not exist.
   • Such policy would have given directions to management and could have avoided the incident
   • No contractual obligations and liabilities were put forward to the vendor. The lawsuit did not cover our damages.
5. No formal defined process for salary payment
   • A formal process for salary payment would have made it easier to risk assess it in the first place
6. Information Security
   • According to Information Security, this incident would be classified as a breach of availability, confidentiality, and privacy.
   • No formal ISMS was established that would have given guidelines and tools to the organization for how to protect the data and ensure the availability of the service

The vendor

1. Policy for secure development
   • No policy for secure development exists.
2. Secure development practice
   • Due to a lack of policy, developers do not have a clear direction for what is expected. A review of the code reveals that a few developers follow secure development practices but most don’t.
   • No records regarding awareness for secure development practices exist
   • Spot check uncovers that OWASP is unknown to 80% of the developers
3. Lack of business continuity management
   • No formal program for disaster recovery, business continuity, or resilience has been established
   • No backup system was established
4. Lack of implemented best practices for information and cyber security
   • An ISMS based on ISO 27001/2 best practice was partially documented
   • The ISMS was not fully implemented and was not operationalized
   • Security controls were either not working or in an immature state
5. Regulations impacting their business
   • Top management was not aware of the legislation regulating their business.
   • The company is in breach of PCI-DSS that was put in effect in 2004 to protect credit card information by mandating information security best practices.

Looking to evaluate GRC software? Download our free, customizable GRC RFP template.

Download

In the above stories, we see that greed, incompetence, not being able to distinguish right from wrong, and external threats pose a risk to individuals, companies, nations, and even the global society. In the recent 20 years, we have seen a dramatic increase in regulations to prevent incidents like the above – making running a business more complicated. The importance of financial stability, national security, the environment, healthy societies, and much more are the primary focus for international and national regulations. Similar to the national level, each company must establish its own policies for how the company should be run. Over the years, many standards, good practices, and best practices have been developed to help organizations get their ducks in a row. Experts have invested much time into creating standards for financial audits, how to run an information security program, how to avoid corruption, how to make your company resilient to disastrous events, how to ensure data privacy, and how to assess risk to mention a few. All of this is GRC – and much more.

This is a topic without a right answer. In general, the word “control” in a generic GRC context can be very confusing as it is used in different subcontexts with some different definitions. We mainly differ between a control requirement (E.g. compliance controls from ISO 27001 Annex A, requirements from different regulations, and NIST controls) and a response to a control requirement, to risks, or even to performance requirements. The controls (in the context of a response) can further be split into risk control measures (often used in the O&HS context for hazards and for operational/IT controls) or control activities (the financial world). On a high level, these serve the same purpose, and the terms are in many contexts being used interchangeably. When the control is a response to a risk, we often call it a risk control measure/activity. All controls that are responses to a risk or a compliance requirement become internal controls.

Although the concept of internal controls has existed since ancient Egypt, the introduction of the Sarbanes-Oxley Act (SOX) emphasized the concept of internal controls to an extent that now many associate internal controls with SOX requirements. The concept of internal controls is no longer solely associated with accounting. Internal controls now include all internal controls across the different GRC domains such as business continuity, information & cybersecurity, and more.

Some control measures/activities are proactive, others are reactive – proactive measures will reduce the likelihood of a risk/hazard materializing, a reactive measure will reduce the consequence of a materialized risk event/hazard. Before you will be able to establish controls, you need to be aware of the control requirements and/or the risks. And, before you can identify the risks and the control requirements, you need to know the business context (jurisdictions, markets, industry ++) and the business objectives. This leads us to the definition of the ‘G’ in GRC – ‘Governance’ and the control environment. The totality of the values, objectives, policies, processes, standards, structure, and more.

In our latter illustrative story, our investigation/assessment generated some findings – a finding is a common word auditors use when they identify something that is not according to requirements (e.g. major, minor, object for improvement, or observations). All of the bullet points from our assessment above are examples of GRC measures that could have been implemented to avoid the incident – at both companies. I mentioned that these findings were “brutal”. However, too many companies are in this situation as we speak.

A business does not run itself – we need governance to ensure that we reliably achieve our objectives, we need risk management to address uncertainties, and we need compliance management to act with integrity.

According to OCEG, “GRC is the integrated collection of capabilities that enable an organization to achieve Principled Performance“. So, what is “Principled Performance?^[2] OCEG’s definition of “Principled Performance” is to “reliably achieve objectives, address uncertainty, and act with integrity” So then we get the following definition;

“GRC is the integrated collection of capabilities that enable an organization to reliably achieve objectives, address uncertainty, and act with integrity” – OCEG.^[3]

The integrated collection of capabilities needed to “reliably achieve objectives” includes the art of corporate governance. “Addressing uncertainties” is the art of risk management, and “acting with integrity” is the art of compliance management. All of the capabilities are “integrated” and go hand in hand, across departments, and across business lines. Thus, inherent in the definition is also the concept of non-silos to support the effectiveness and efficiency of an organization.

GRC is to be understood as an umbrella concept that incorporates/integrates multiple GRC related frameworks to fit your organization – and your industry. GRC is something every company does – even if they do not use the acronym GRC.

You can think of GRC as the toolbox and instructions for running your company at its best. The better and more relevant the tools are, the better the result. Inside this toolbox and instructions, there are hundreds of proven methods and frameworks that will help you reliably achieve objectives. This is also why regulators mandate parts of the GRC toolbox for certain industries because it helps the regulator to achieve their objectives.

Historically, the first version of GRC turned into a response to the need for prudent corporate governance after Sarbanes Oxley hit in 2002. The focus for the first several years of GRC was on SOX compliance and internal controls over financial reporting. From that point in time, the GRC domain has evolved. Not because the GRC definition has changed, but because the world of regulations, expectations, and requirements has evolved – and GRC is still the toolbox to reliably achieve today’s business objectives. Over this period more tools have been added to the toolbox. If your GRC program does not work, one reason could be the tools in your toolbox are not the right tools for your company, the tools are not used properly, or your GRC program has become siloed.

In the GRC context, tools are not primarily about technology. Tools and recipes include frameworks, methods, models, best practices, policies, roles & responsibilities, processes, procedures, calculations, simulations, surveys, reports, a combination of the above, and much more. The technology’s role is simply to enable the organization to succeed by digitalizing the GRC tools.

Governance is roughly about setting the premise for success by equipping managers with clear direction, expectations, and resources. There are a plethora of different tools available – and different experts will prefer and recommend different tools. However, there exist some high-level commonalities that will span most governance frameworks and expert opinions. These include:

• Corporate vision & values
  The power of unity, working together toward a greater good, the foundational attitude, and the ability to make the right decisions in everyday situations are great governance tools that help tune all employees onto the same channel.
• Tone from the top
  The internal culture is heavily dependent on the tone from the top and, not at least, the business integrity of top management. Behavior, attitude, and values will quickly ripple down into the organization.
• Strategy & Objectives (performance objectives, risk appetite, compliance objectives)
  A formally defined business strategy including objectives, initiatives, and performance goals will equip the organization to align and design the GRC program according to the business objectives – this is where many GRC programs fail.
• Roles & Responsibilities
  Clear roles and responsibilities will equip the employees with an understanding of where they fit in the big puzzle, within which boundaries they can work, and what are their mandate and responsibilities. Not only to understand one’s job but to understand everybody
  else’s job.
• Policies
  Policy documents are the written official policies executed by the organization for important areas such as Policy for risk management, policy for Information Security, Policy for ESG, Anti-bribery, corruption, and much more. Policies often have statements for sanctions if
  breached by the employees.
• Processes
  Einstein once said: “Insanity is doing the same thing over and over and expecting different results.” A process is the same thing with the opposite expectation; Ensuring the same result by doing the same thing the same way every time. A process should be documented,
  measured, improved, and audited. In the GRC domain that is expected and often required.

Risk has many different flavors in terms of methods and definitions. However, in general, we can say that risk is about identifying and managing uncertainties, threats, or hazards – and risk can have both downsides (negative consequences) and upsides (positive consequences or opportunities). Let us have a look at some different definitions of risk from a selection of well-known risk frameworks:

Table 1.1 A selection of well-known risk frameworks

Although there are different definitions of risk and risk-based frameworks, the risk management process is generally the same. The different risk methodologies emphasize the following phases differently and might use different names. Remember, the nature of a framework is that it should be modeled to fit your organization. If the methodology you decide on (or are mandated to use) is not prescriptive, you have the freedom to, and might even be required to, make adjustments to fit your organization.

1. Identification
   Using a variety of different tools, this phase is about identifying any risk/uncertainty/hazard that might impact our objectives/assets. We can identify risks by looking at many different perspectives/dimensions such as for our processes, strategic objectives, products, information assets, compliance objectives, services, third parties, production, and more.
2. Analysis & Evaluation (Assessment)
   Having identified the risks, this phase will focus on digging deeper into the risk to get to a risk level/exposure. The simplest approach is to set the likelihood and consequences to get to a risk level. However, as with everything in GRC, there are many different ways of doing this – it all boils down to what is needed in terms of business context and business objectives. Some industries will need a fully quantified approach with masses of historical data distributions and complex simulations to render different scenarios, while other industries will simply need a qualitative Low-Medium-High approach. However, the most common in business risk is to use a semi-quantitative approach which means using scales e.g. from 1-5 for likelihood and consequences where the formula for risk level/exposure is (risk = likelihood x consequence). Based on the guidelines from corporate governance, the risk should be evaluated according to the risk strategy, including the risk appetite. If the risk in question is analyzed at a level/exposure above the risk appetite, the individual or team responsible for evaluating the risk(s) will decide how to respond to the risk. Common responses include reducing, transferring, avoiding, or sharing the risk in question.
3. Treatment/Controls
   This is the phase where treatment is planned, if required according to the decided response in the evaluation phase, then implemented/executed, maintained, and improved. The treatment is carried out in terms of control activities/measures and can be one-time activities/measures or ongoing activities/measures. Examples of the latter are established processes, policies, technology measures, procedures, outsourced services, and more. Now we see how this is linked back to the governance layer.
4. Monitor & Report
   This phase includes the tools to properly monitor the risk situation using e.g. key risk indicators (KRIs), risk-adjusted KPIs, visualizations, notifications, and reports for board/management review. Crucial to this phase is to be able to monitor business impacts due to changes to the risk profile as well as to understand why.

In the scope of compliance, our goal is to act with integrity in relation to 4 dimensions:

• Regulatory compliance
  This includes laws and regulations that are mandated for the relevant jurisdictions and industries.
• Organizational compliance
  This includes any compliance framework we have decided to follow as a business, voluntarily, but supported or mandated by the board/upper management. E.g. ISO standards, good/best practices, project methodologies, reporting standards, and more. The reason we decide to implement such standards is mainly to effectively support a regulatory, ethical, or legal/contractual requirement, or simply to perform better as a company.
• Ethics/expectations
  This includes any expectation not founded in any law, regulation, or contract. This mostly reflects expectations from society, religious beliefs, ethics, norms, and core values, that affect our conduct and behavior.
• Legal/contract compliance
  This includes any compliance obligation we have legally agreed to, bound by a contract or other legal instruments with customers, distributors, other business partners, and more. E.g. we might have obligations in the contract that mandate us to run our operations or deliver our products/services in compliance with a certain ISO standard or according to other agreements.

Looking to evaluate GRC software? Download our free, customizable GRC RFP template.

Download

All of these dimensions of compliance are important to an organization and pose a risk if we are in breach of any of them. Yes, I used the word “risk” in this context. Many compliance frameworks recommend, require, or allow for a risk-based approach. This makes it clear to us that risk management is a tool to solve problems or make decisions. By using risk as a tool for managing your compliance, your organization will be better equipped to focus on the important aspects of compliance, spend fewer resources, and be able to more quickly respond to changes in obligations or seize opportunities.

A response to a compliance obligation/requirement is often called a control, internal control, or compliance control measure. In a risk-based approach, such control can be the same as the risk control as one single internal control (e.g. the process of risk assessing a new supplier) may serve the purpose of reducing risk and, at the same time, satisfying one or more compliance obligation(s). At this point, we start to see how complex it is to run your GRC program in Excel. A simple task for a professional GRC system, such as providing an overview of all internal controls across all risks and compliance obligations across the company, will be a complicated task.

In a forward-thinking organization, GRC is viewed as an integrated collection of all capabilities necessary to support Principled Performance – “to reliably achieve objectives, address uncertainty, and act with integrity”.

In Corporater we like to “emphasize the P in GRC” – meaning P for Performance. In fact, when the acronym GRC was invented, they considered including the P. However, a three-letter acronym was considered easier to remember so the P had to go. Due to this, I think a great deal of understanding of the relationship between GRC and Performance was lost. Every company has objectives, and to achieve objectives we need to perform. And, we need to comply – if not, the government will shut us down, issue a fine, or put us in jail. So, what is the proven recipe for reliably achieving our objectives, addressing uncertainties, and staying compliant?