Category: The GRC Pundit Blog

The importance of stages

Climbing a mountain like Mount Everest is not done haphazardly. It takes careful planning and an organized route. It also involves breaking the trek up the mountain into stages. One does not simply run up Mount Everest. You climb a mountain like Everest too quickly . . . you die. Tackling a trek up a large mountain is broken into stages that are manageable and allow for proper recovery and review of plans before the next ascent.

The same approach is done with a significant regulation, like UK SMCR in the financial services industry. UK SMCR is a significant shift in accountability, communications, attestation, and certification of staff in a financial services organization. As with other significant regulations, financial services firms are tackling UK SMCR in stages.

Beginning your SMCR journey

The first stage of the UK SMCR trek was mapping and aligning senior management functions in the organization. This was foundational and like getting to the first base camp of the UK SMCR Everest. You cannot manage accountability and certification if you do not have the responsibility maps and roles defined.

The run up to the 9^th of December 2019: SMCR implementation date

The second stage of UK SMCR climb was to . . .

[this is a guest blog by GRC 20/20’s Michael Rasmussen published on the SureCloud blog. The rest of the blog can be read at the link below]

Business is No Longer Brick & Mortar Walls

I was recently talking to a global manufacturer about the challenges they face in defining their organization. The challenge is that there are no more brick and mortar walls that define the organization. Their organization, like yours, is a web of third party relationships. In many areas, these relationships are further complicated as they nest themselves in other relationships in deep supply chains and subcontractors. What used to be thought of as an internal risk within the traditional brick and mortar walls of this global manufacturer is now extended across an array of relationships in the extended enterprise.

However, as we were talking, it is not just about risk management. The organization has to ensure that these extended enterprise relationships share the same values and commitments to integrity define the core organization, the global manufacturer. It also has to ensure that each of these relationships is meeting the objectives that the relationship is in place for. This gets further complicated where the organization has to not only manage the performance/objectives, risk, and compliance at the relationship level but also at the contract, facility, and/or service-level.

One financial service firm stated they cannot simply manage a service provider/outsourcer relationship at the relationship level but needs to understand the details at each contract/service-level of the relationship. They might have one relationship but have 100 contracts/service levels within that relationship. They need to manage how each contract is performing and the unique risks that each contract has.

I sat on the social accountability advisory firm for one Fortune 100 firm that was managing international labor standards across 5,000 suppliers. However, these 5,000 suppliers had an aggregate of 20,000 facilities. Social accountability cannot simply be managed at the relationship level of each supplier but had to extend into each facility servicing this global firm.

However, Organizations Focus on Third Party Risk Silos

The challenge is that many organizations approach third party risk management in isolated silos. The IT security team has their process and technology focused on security. Corporate compliance and ethics are concerned about anti-bribery and corruption and have their processes for managing this in third party relationships. Then other departments such as quality, environmental, health and safety, EST/CSR, and others have their siloed processes to govern relationships. This results in no one seeing a full spectrum of the risk and exposure in these relationships. Perhaps each area has some concerns in a relationship, but in their silo it is not a big enough concern. But if they would aggregate the concerns across silos monitoring the one relationship they should have alarms going off.

However, what is often missing, is the governance of these relationships. As organizations focus on the silos of risk they often forget to put in context how these third party relationships are delivering on the performance and objectives of the relationship.

It Is Time to Move to Third Party GRC

It is time for organizations to stop thinking about Third Party Risk Management and start doing Third Party Governance, Risk Management, and Compliance (GRC). Third Party GRC is the capability to reliably achieve objectives [GOVERNANCE] while addressing uncertainty [RISK MANAGEMENT] and act with integrity [COMPLIANCE] in and across the web of the organizations third party relationships in the extended enterprise (note: this is modified from the OCEG definition of GRC to fit Third Party GRC).

Think about it. Each relationship has a purpose. There would not be a relationship if there was no purpose for it. The organization needs processes in place to reliably achieve the objectives of the relationships – this is third party governance. Then the organization needs to manage the uncertainty in the relationship. Risk, according to ISO 31000, is the effect of uncertainty on objectives. The organization has to monitor and manage the uncertainty/risk in meeting the objectives of the relationship. Then the organization needs to ensure the integrity in the relationship, that the compliance requirements, values, and ethics are in place and aligned with the organizations.

These are three legs of one stool, and all are needed. It is more than third party risk. That only gets you a partial view. Organizations need to start thinking fo Third Party GRC in defining these programs.

Only a Few Solutions Deliver on Third Party GRC

I recently published my Third Party GRC Maturity Model. This breaks the measurement of maturity of an organization’s Third Party GRC program into 5 levels – Ad Hoc, Fragmented, Defined, Integrated, and Agile. The Ad Hoc stage is fire fighting and reactive. The Fragmented stage is manual processes at a department level. Defined is technology-enabled third party risk management at a department level. Integrated is an enterprise view of third party risk across departments. Agile is where we achieve Third Party GRC as it looks at risk and compliance in context and in balance with the objectives and performance of each relationship.

From a technology perspective, there are a lot of siloed very focused solutions that do one area of third party risk to get an organization to the Defined stage. There are a handful of solutions that can take a broad view of third party risk across departments to get an organization to the Integrated stage. There are only a few solutions on the market that can truly deliver on Agile and bring an integrated view of the objectives/performance in the context of the risk and compliance in each relationship.

Today’s business environment where the business has no boundaries and extends across an array of third parties necessitates that organizations start focusing on the Agile – Third Party GRC and not silos of third party risk management.

GRC 20/20 Third Party GRC Workshops

I will be teaching my Third Party GRC by Design workshops in the following cities in February. Registration is free but limited to those within organizations managing aspects of their third party relationships. In other words, it is not open to solution providers trying to sell products/services. Come join us . . .

• Dallas, Third Party GRC Management by Design, February 10th
• New York, Third Party GRC Management by Design, February 19th
• San Francisco, Third Party GRC Management by Design, February 21st
• London, United Kingdom, Third Party GRC Management by Design, February 25th

Upcoming Risk Management by Design workshops are:

• Los Angeles, Risk Management by Design, March 12th
• Washington DC, Risk Management by Design, March 17th
• New York, Risk Management by Design, March 19th
• Toronto, Risk Management by Design, July 14th

Upcoming Policy Management by Design workshops are:

• Chicago, Policy Management by Design, April – details forthcoming
• New York, Policy Management by Design, April 28th
• London, United Kingdom, Policy Management by Design, June – details forthcoming

Governance, Risk Management and Compliance (GRC) is “a capability to reliably achieve objectives [GOVERNANCE], while addressing uncertainty [RISK MANAGEMENT], and act with integrity [COMPLIANCE].” This is the official definition of GRC as found in the OCEG GRC Capability Model and their focus on Principled Performance that has been in place for the past 15 years. I have been honored to be a key part of the development and evolution of the GRC Capability Model since this time.

GRC is something organizations do, it is not something they buy. The organization is governed, it manages risk, and it complies with obligations and boundaries. There is technology for GRC, but you do not buy GRC an organization does GRC. Technology enables GRC and makes GRC processes more efficient, effective, and agile. It frustrates me to no end when an organization asks me to come in and they tell me we just purchased GRC now can you come in and tell us how to do GRC. That is putting the cart before the horse. You have governance, risk management, and compliance processes in place today. What is working? What is not working? What do you want to change?

GRC is something that organizations have been doing long before we had an acronym for GRC. GRC has existed since the dawn of business and has been a part of business strategy, processes, and behavior. Whether it was working or not, GRC existed long before an acronym came into play.

But we do have an acronym, and I was the first to use that acronym on a cold snowy day in February 2002 at the Chicago office of Forrester Research (I was an analyst at Forrester from 2001 to 2007). I had just sat through a solution briefing of a technology that mapped risks to controls to policies to regulations/standards and had structured workflow and tasks for accountability and to conduct assessments. I thought this is great. When I was managing a risk and compliance consulting practice in Chicago in the 1990s this is the type of solution I envisioned and wished was available. I knew there was a market for this type of technology that took existing GRC related processes and made them efficient, effective, and agile. Throughout that day in Chicago, I noodled over it and ended up calling it GRC technology. From there I wrote the first two Forrester GRC Waves before I left Forrester in 2007 to go independent.

We talk about GRC technology it is essential to understand there is technology for GRC, but technology itself is not GRC. In fact, there is no technology solution on the planet that does all things GRC. From a strategy, process, and technology perspective there can be a core platform to document and report on objectives, performance, risks, controls, and such. But this often means that the core platform integrates with other specialized solutions as not one platform does everything related to GRC. It does not exist. One RFP that I recently supported wanted an Enterprise/Integrated GRC platform that did everything. From the top-down view of risks and controls to IT security to environmental, health and safety compliance and risks. I told them at the beginning that such a platform does not exist. They wanted to look and I wrote the RFP requirements and went through the process with them. They ended up with three platforms that did their specialized areas, with one being the master platform for overall risk reporting.

The history and evolution of GRC technology has evolved over the years since I first defined it in 2002. We are currently in GRC 4.0 – Agile GRC and watching as it transitions into GRC 5.0 – Cognitive GRC. This is not a linear timeline but an evolution as the capabilities of underlying technology for GRC evolves. So they do overlap and while we are not at GRC 5.0 today, we see the early adoption and interest in it as the technology evolves and provides itself and will become mainstream over the next two years. The stages of technology for GRC are:

• GRC 1.0 – SOX Captivity (2002 to 2007). When I first defined and modeled technology for GRC back in February 2002 at Forrester, I clearly defined it as a broad and integrated view of objectives and the risks, control, and policies that relate to those objectives. Unfortunately, Sarbanes Oxley hit in 2002 and the focus for the first several years of GRC was on SOX compliance and internal controls over financial reporting. It drove and advanced solutions in the market, but also kept them away from being the broader GRC solution that I originally envisioned.
• GRC 2.0 – Enterprise/Integrated GRC (2007 to 2012). Once organizations addressed SOX, it was time for technology for GRC to get back to what I had originally defined it for – an enterprise view of business objectives and the risks, controls, policies, and issues related to those objectives. The concept of the Enterprise Integrated GRC platform gained hold that multiple departments can work off a common information and technology architecture to manage risks, control, policies, compliance, audits, assessments, and incidents. But solutions had their strengths and weaknesses, and no one could do everything. My last Forrester Wave I wrote before leaving Forrester at the end of 2007 had four different Wave graphics to show the strengths and weaknesses of a solution coming from different points of view of risk, compliance, audit, and overall.
• GRC 3.0 – GRC Architecture (2012 to 2017). As the technology for GRC uses expanded in the organization, it became apparent that no one platform solved all the challenges related to GRC. It required integration as organizations looked to leverage best of breed risk, compliance, control solutions where they made sense but still integrate with an overall platform for risk aggregation, normalization, and reporting. There was often still a central hub for GRC management, but it no longer pretended to do everything and integration with other business systems as well as deeply focused GRC solutions was necessary. GRC also started to evolve where it was no longer just about the back office of GRC processes (what some would refer to as the second and third lines of defense), but it was also about the front lines of the organization (first line) that are making risk and compliance decisions that impact objectives every day.
• GRC 4.0 – Agile GRC (2017 to 2021). This is our current stage of GRC technology. The need for highly configurable technology that engages the entire organization on GRC from the front office to the back office. Agile technology that is configurable without advanced certifications and knowledge, what we call citizen development (though this can get out of hand and cause issues if not monitored and controlled). Where things did not break on upgrades because of heavily customized coding. The provision of GRC interfaces that are highly intuitive and engaging that were contextually relevant and easy to navigate for the role using them. Interfaces that are highly visual and interactive. Many legacy GRC solutions try to adapt to Agile by putting a fresh coat of paint on the user interface, but the underlying data and application architecture is still fifteen to twenty years old. There is a new breed of Agile software for GRC that takes this technology to the next level of value to the organization.
• GRC 5.0 – Cognitive GRC (2021+). We are already seeing this today, the role and impact of cognitive/artificial intelligence technologies on GRC. Things such as machine learning, natural language processing, and predictive analytics are starting to bear hold and take Agile GRC technologies to the next level. While these capabilities are making strides with some early adopters, it will be about 2021 when cognitive GRC technologies gain a greater hold in the market and have proven themselves with the early adopters.

When I look at the GRC market, I break it out into the following categories of solutions that I monitor and differentiate. Any solution in the market might just operate in one of these areas, or across several. But no one does it all. But there are a range of solutions that GRC 20/20 monitors, differentiates, and follows in our market research that span:

• Integrated GRC Platforms. Capability to manage an integrated architecture across multiple GRC areas in a structured strategy, process, information and technology architecture. These are the hubs that bring multiple areas below together into one overall view of integrated GRC reporting across the enterprise.
• Anti-Money Laundering/KYC, Fraud & Corruption. Capability to manage AML, KYC, bribery, corruption, and fraud in the organization.
• Audit Management & Analytics. Capability to manage audit planning, staff, documentation, execution/fieldwork findings, reporting, and analytics..
• Automated Continuous Control Management/Enforcement. Capability to automate the detection and enforcement of internal controls in business processes, systems, records, transactions, documents, and information.
• Business Continuity Management. Capability to manage, maintain, and test continuity and disaster plans,  and implement these plans expected and unexpected disruptions to all areas of operation.
• Compliance & Ethics Management. Capability to manage an overall compliance program, document and manage change to obligations, assess compliance, remediate non-compliance, and report.
• Environmental Management. Capability to document, monitor, assess, analyze, record, and report on environmental activities and compliance.
• Finance GRC Management. Capability to manage the financial risks, controls, and reporting of the organization.
• Health & Safety Management. Capability to manage, document, monitor, assess, report, and address incidents related to the health and safety of the workforce and workplace.
• HR GRC Management. Capability to govern and manage risk and compliance in employee relationships, training, activities, and issues/incidents.
• Internal Control Management. Capability to manage, define, document, map, monitor, test, assess, and report on internal controls of the organization.
• IT GRC Management. Capability to govern IT in the context of business objectives and manage IT processes,  technology, and information risk and compliance.
• Issue Reporting & Management. Capability to notify on issues and incidents and manage, document, resolve, and report on the range of complaints, issues, incidents, events, investigations, and cases.
• Legal Management. Capability to manage,  monitor, and report on the organization’s legal operations, processes, matters, risks, and activities.
• Physical Security Management. Capability to manage risk and losses to individuals and physical assets, facilities, inventory, and other property.
• Policy & Training Management. Capability to manage the development, approval, distribution, communication, forms, maintenance, and records of policies, procedures and related awareness activities.
• Quality Management. Capability to manage, assess, record, benchmark, and track activity, issues, failures, recalls, and improvement related to product and service quality.
• Reputation & Responsibility Management. Capability to manage the sustainability, ESG, and corporate social responsibility program of the organization.
• Risk Management & Analytics. Capability to identify, assess, measure, treat, manage, monitor, and report on risks to objectives, divisions, departments, processes, assets, and projects.
• Strategy & Performance Management. Capability to govern, define, and manage strategic, financial, and operational objectives and related performance and risk activities.
• Third Party GRC Management. Capability to govern, manage, and monitor the array of 3rd party relationships in the enterprise, particularly risk and compliance challenges these relationships bring.

While these are categories/buckets of capabilities that GRC 20/20 maps solutions in the market into, the reality is that one solution can go across many of these areas, or be confined to just one area. But no one does everything that is why it is about GRC information and technology architecture.

GRC 20/20 is here to answer your questions on strategy, solutions, and technology for GRC. We are a research organization so it is our job to objectively understand and differentiate solutions in the market and the problems they solve. Feel free to ask an inquiry.

The Policy Management Illustrated Series

• Frustrated by policy management?
• Having trouble finding all the policies (both authorized and unauthorized) floating around in your organization?
• Wasting time and resources that could be well applied elsewhere to help the organization achieve its objectives and stay on track?
• Realizing something has to change? 

In our research, we have found that many organizations fail at several key stages of policy management. Too often there is no formal guidance or requirements for the authoring and approval of policies. There is no risk-based consideration to determine which policies should be supported with training. There is no single repository for all policies with version control and linkage to related obligations, processes and controls. And on and on and on. 

In response to this problem, OCEG, in collaboration with GRC 20/20, has developed an educational series of materials and webinars discussing the challenges and the solutions for better policy management. In addition to addressing each stage of the policy management lifecycle, the series will provide context that can help attendees build the business case for better management, demonstrating the value of policies in helping the organization achieve Principled Performance.

Each webinar will be accompanied by the release of a related installment in our Policy Management Illustrated infographic collection.

Whether you are directly responsible for policies or are on a compliance, risk, HR, legal, internal audit or IT team, you will find this series both helpful and enlightening.

Check out more details and register for each webinar by clicking on the titles below.  Sign up early to reserve your spot. 

Upcoming OCEG & GRC 20/20 Webinars . . .

• Policy Management Step – By – Step, November 4 @ 10:00 am – 11:00 am CST
• Standardizing Policy Design and Approval – Why it Matters, November 6 @ 10:00 am – 11:00 am CST
• Beyond the Shelf – Ensuring Policy Understanding with Communication and Training, November 11 @ 10:00 am – 11:00 am CST
• The Policy Enforcement Team – Roles and Responsibilities, November 13 @ 10:00 am – 11:00 am CST
• Engaging Employees – The “Now Generation” of Interactive Policies, November 18 @ 10:00 am – 11:00 am CST
• Keeping Up With Change That Impacts Policies, November 20 @ 10:00 am – 11:00 am CST
• Re-evaluating Policies – Methods for Maintaining Effectiveness, November 25 @ 10:00 am – 11:00 am CST
• Where Policy Management Fits in the GRC Ecosystem, December 4 @ 10:00 am – 11:00 am CST
• Results from the 2019 GRC Maturity Survey, December 5 @ 12:00 pm – 1:00 pm CST
• Building the Business Case for Better Policy Management, December 9 @ 10:00 am – 11:00 am CST
• Why Policies Matter, December 11 @ 10:00 am – 11:00 am CST
• Preparing for the Policy Management Change, December 16 @ 10:00 am – 11:00 am CST

Upcoming Workshops by GRC 20/20 . . .

• Policy Management by Design, London, October 21
• Risk Management by Design, Dublin, October 22
• Policy Management by Design, New York, October 24
• Policy Management by Design, Chicago, October 30
• Risk Management by Design, Chicago, November 5
• Compliance Management by Design, New York, November 12
• Building an Effective Policy Management Lifecycle, London, November 20

Upcoming GRC 20/20 Webinars . . .

• Back to Basics: Internal Audit Success in 2020, October 29 @ 11:00 am – 12:00 pm CDT
• The Rise of Agile GRC in a Dynamic and Disruptive Business Landscape, November 7 @ 10:00 am – 11:00 am CST
• UK SMCR’s Breakfast on Accountability vs Responsibility- The Chicken and the Pig, November 11 @ 4:30 pm – 5:30 pm GMT

Gartner, particularly John Wheeler, is hard at work trying to convince the world that their Integrated Risk Management (IRM) is something new to replace Governance, Risk Management & Compliance. You can check out John’s latest post mischaracterizing and misleading organizations in: GRC May Keep You “Out of Trouble” ,But IRM Will Keep You “ In Business” 

The first thing to note is that every solution in Gartner’s IRM Magic Quadrant and IRM Critical Capabilities reports have been and are GRC solutions. Every one of them has been marketing GRC, most for some time. These are the same platforms that have been calling themselves GRC that Gartner is now calling IRM. 

The second thing to note is that Gartner mischaracterizes what GRC is about by pushing it solely to compliance. I have refuted this time and time again by citing the long-standing official definition of GRC found in the OCEG GRC Capability Model that GRC “is a capability to reliably achieve objectives [GOVERNANCE] while addressing uncertainty [RISK MANAGEMENT] and act with integrity [COMPLIANCE].” I went into great detail on what GRC is in my recent article ‘Navigating Chaos‘ published in Enterprise Risk magazine published by The Institute of Risk Management (the real IRM). GRC since its inception has been focused on Principled Performance with an aim for the organization to reliably achieve objectives. 

If you peel back IRM in Gartner’s reports what do you find? GRC. It is not just the same technology, but the same pillars. Though I would argue it is GRC light as Gartner misses the boat in risk areas of quality, environmental, health and safety, sustainability, corporate social responsibility, and more that impact the modern organization.
Take a look at the recent Gartner IRM MQ and the IRM Critical Capabilities. It breaks IRM into three areas:

• Business Outcome Centric. Gartner says this is “an integration-optimization-based risk practice designed to automate the linkage among relevant insights on key corporate performance-related risks.” Interesting, this sounds like the Governance pillar in the GRC definition in the capability to reliably achieve objectives. 
  
• Operation-Centric. Gartner says “resilience is an adaptability-based risk practice focused on operational and IT risks offering an agile risk program in response to and re3cover form key business disruptions.” Interesting, this sounds like the Risk Management pillar in the GRC definition with the capability to “manage uncertainty.” ISO 31000 defines risk as the effect of uncertainty on objectives. 
  
• Compliance-Centric. Gartner says “compliance is a regulation-based risk practice providing evaluation and evidence in support of relevant legal and regulatory requirements.” Interesting, this even mentions Compliance but only in a limited way focused on regulations. The GRC Capability Model which is about 15 years old now, defines compliance as the “capability to act with integrity.” This is more than regulatory compliance but includes compliance to the risk boundaries of the organization (e.g., tolerance, appetite, capacity); the policies of the organization; the values, ethics, corporate social responsibility commitments of the organization; and the contractual obligations of the organization.

There you have it – IRM at its core is really GRC.

What really strikes me as interesting is that Gartner puts a lot of effort into stating there is a difference in these pillars from a technology perspective. I would agree, but Gartner’s research does not. You look at the IRM Critical Capabilities research and you have the same list of solutions in nearly identical order in each of these three areas. Same solutions on top same solutions on the bottom with very little movement between these areas. Why even break this out Gartner? From this research, you are stating that the same solutions that score high in Business Outcome also are the top for Operation Centric and Compliance Centric. Same solutions and nearly the same order in each of the three areas. It does not make sense.

But what is really ironic, is that I have been discussing this for 15 years this differentiation. My last GRC Wave I wrote at Forrester in 2007 had four Wave graphics. One for overall GRC combined, one for Governance focused on outcomes and objectives, one for Risk Management focused on operational risk, and one for Compliance. They say there is nothing new under the sun, Gartner proves this. They are just taking my approach in 2007 and using it in 2019. Just relabeling/renaming its areas. HOWEVER, if you look at the 2007 Forrester GRC Wave you will find a completely different ranking of solutions in each of the areas and not the same ranking. 

Gartner, drop the IRM facade. I don’t care if you want to call GRC IRM. You can call it ERM, ABC, XYZ. It does not matter what you want to call your category. Just stop misleading the world that saying GRC has failed when you are evaluating the same exact technology solutions that have called themselves GRC. Look at how you break out and define IRM, it maps to how GRC is defined and broken out. 

A haphazard department- and document-centric approach for third party GRC compounds the problem and does not solve it. It is time for organizations to step back and mature their third-party GRC approaches with a cross-functional and coordinated strategy and team to define and govern third party relationships. Organizations need to mature their third-party governance with an integrated strategy, process, and architecture to manage the ecosystem of third-party relationships with real-time information about third-party performance, risk, and compliance, as well as how it impacts the organization.
GRC 20/20 has developed the Third Party GRC Maturity Model to articulate maturity in the third-party GRC processes and provide organizations with a roadmap to support acceleration through their maturity journey.

There are five stages to the model:

1. Ad Hoc 
2. Fragmented 
3. Defined 
4. Integrated 
5. Agile

Today we look at Stage 5, the Agile level of third-party GRC.

At the Agile Maturity stage, the organization has completely moved to an integrated approach to third-party GRC across the business that includes an understanding of risk and compliance in context of performance and objectives in third-party relationships. Consistent core third-party GRC processes span the entire organization and its geographies. The organization benefits from consistent, relevant, and harmonized processes for third-party governance with minimal overhead.

The Agile Maturity is where most organizations will find the greatest balance in . . .

[this is a guest blog authored by Michael Rasmussen of GRC 20/20 that can be found at Aravo site, follow the link below to read more]