Blog

This post is an excerpt from GRC 20/20’s most recent research piece, Third Party GRC Maturity Model: A New Paradigm in Governing Third Party Relationships, and upcoming webinar From Ad Hoc to Agile: Set Your Course for Third-Party GRC Maturity.

Traditional brick-and-mortar business is a thing of the past: physical buildings and conventional employees no longer define the organization. The modern organization is an interconnected maze of relationships and interactions that span traditional business boundaries. Layers of relationships go beyond traditional employees to include suppliers, vendors, outsourcers, service providers, contractors, subcontractors, consultants, temporary workers, agents, brokers, intermediaries, and more. Complexity grows as these interconnected relationships, processes, and systems nest themselves in intricacy, such as deep supply chains.

In this context, organizations struggle to govern third party relationships. Risk and compliance challenges do not stop at organizational boundaries. An organization can face reputation and economic disaster by establishing or maintaining the wrong business relationships, or by allowing good business relationships to sour because of weak governance of the relationship. Third party problems are the organization’s problems and directly impact the brand, as well as reputation, while increasing exposure to risk and compliance matters. 

Fragmented governance of third party relationships through disconnected silos leads the organization to inevitable failure. A haphazard department- and document-centric approach for third party governance, risk management, and compliance (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. 

A New Paradigm in Governing Third Party Relationships

The primary directive of a mature third party GRC management program is to deliver effectiveness, efficiency, and agility to the business in managing the breadth of third party relationships in context of performance, risk, and compliance. This requires a strategy that connects the enterprise, business units, processes, transactions, and information to enable transparency, discipline, and control of the ecosystem of third parties across the extended enterprise. In the end, third party management is more than compliance and more than risk, but is also more than procurement. Using the definition for GRC^[1]  – governance, risk management and compliance – third party GRC is a “capability to reliably achieve objectives [GOVERNANCE], while addressing uncertainty [RISK MANAGEMENT], and act with integrity [COMPLIANCE]” in the organization’s third party relationships.  

Third party GRC is a “capability to reliably achieve objectives [GOVERNANCE], while addressing uncertainty [RISK MANAGEMENT], and act with integrity [COMPLIANCE]” in the organization’s third party relationships.  

Five Stages of Third Party GRC Maturity

Mature third party GRC is a seamless part of governance and operations. It requires a top-down view of third party governance, led by the executives and the board, where third party risk management is part of the fabric of business – not an unattached layer of oversight. It also means bottom-up participation, where business functions identify and monitor transactions and relationships that expose 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 

Organizations at the Ad Hoc stage of maturity have siloed approaches to third party governance, risk and compliance at the department level. Businesses at this stage do not understand risk and exposure in third party relationships; few if any resources are allocated to third party governance. The organization addresses third party GRC in a reactive mode — doing assessments when forced to. There is no ownership or monitoring of risk and compliance, and certainly no integration of risk and compliance information and processes in context of third party performance. 

2: Fragmented

The Fragmented stage sees departments with some focus third party GRC within respective functions — but information and processes are highly redundant and lack integration. With siloed approaches to third party GRC, the organization is still very document-centric. Processes are manual and they lack standardization, making it hard to measure effectiveness.

3: Defined

The Defined stage suggests that the organization has some areas of third party GRC that are managed well at a department level, but it lacks integration to address third party risk across departments. Organizations in the Defined stage will have defined processes for third party GRC in some departments or business functions, but there is no consistency. Third party GRC processes have the beginning of an integrated information architecture supported by technology and ongoing reporting. Accountability and oversight for certain domains such as bribery and corruption risk and compliance, and/or information security are beginning to emerge. 

4: Integrated

In the Integrated stage, the organization has a cross-department strategy for managing third party governance across risk and compliance. Third party GRC is aligned across several departments to provide consistent frameworks and processes. The organization addresses third party GRC through shared processes and information that achieve greater agility, efficiency, and effectiveness. However, not all processes and information are completely integrated, and there is not an integrated view of third party performance.

5: Agile

At the Agile 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. 

Advancing Your Organization’s Third Party Governance Maturity 

Organizations with third party GRC processes siloed within departments operate at the Ad Hoc, Fragmented, or Defined stage. At these stages third party GRC programs manage third party risk and compliance at the departmental level and lack an integrated view with no gain in efficiencies from shared processes. 

In the Integrated and Agile maturity levels, organizations have centralized third party GRC oversight to create consistent programs around the world with a common third party GRC process, information, and technology architecture. These organizations report process efficiencies reducing human and financial capital requirements, greater agility to understand and report on third party performance, risk, and compliance, and greater effectiveness through the ability to report and analyze third party risk and compliance data. The primary difference between the Integrated and Agile stage is the integration of third party GRC in the context of performance, objectives, and strategy in individual relationships aligned with the organization. Differences may be seen in top-down support from executive management, and when various risk and compliance functions align with strategy to collaborate and share information and processes. 

The Agile Maturity approach is where most organizations will find the greatest balance in collaborative third party governance and oversight. It allows for some department/business function autonomy where needed, but focuses on a common governance model and technology architecture that the various groups in third party GRC utilize. A federated approach increases the ability to connect, understand, analyze, and monitor interrelationships and underlying patterns of performance, risk, and compliance across third party relationships. It allows different business functions to be focused on their areas while reporting into a common governance framework and architecture. Different functions participate in third party GRC management with a focus on coordination and collaboration through a common core architecture that integrates and plays well with other systems.

Supporting 3rd Party GRC Research . . .

GRC 20/20 has defined this in our key research papers:

• Third Party GRC Maturity Model: A New Paradigm in Governing Third Party Relationships
• Third Party Management by Design

Upcoming webinar:

• From Ad Hoc to Agile: Set Your Course for Third-Party GRC Maturity

GRC 20/20 is also presenting on how to build a business case for and evaluate the range of 3rd Party GRC solutions in the market:

• Buyers Guide: Third Party GRC Solutions

GRC 20/20 is also facilitating several upcoming workshops on this topic as well:

• Third Party Management by Design, Seattle – September 24th
• Third Party Management by Design, Minneapolis – September 26th
• Third Party Management by Design, Charlotte – October 7th

Other Case Studies, Strategy Perspectives, and Solution Perspectives on Third Party GRC can be found here.GRC 20/20’s 3rd Party GRC Research

Ask GRC 20/20 an inquiry on what 3rd Party GRC solutions available in the market and what differentiates them, this is what we do – research and analysis of technology for GRC . . . .

^[1]        This is the OCEG definition of GRC.

I am amazed at the number of risk management programs I encounter that lack an organized structure and approach. So often what we know as ERM (enterprise risk management) is a hodge-podge of processes and assessments that somebody tagged the ERM label on without much thought for what they were doing. In fact, most of the ERM processes I encounter are nothing more than a slightly expanded view of SOX and financial controls: they are not truly an enterprise view of risk across the organization and its operations that aligns and supports performance management and strategy.

One of the best research pieces I have seen on Risk Culture is from the Institute of Risk Management, which I am delighted to be an honorary life member and love participating in their research and events. Every organization has a culture that defines and influences how risks are understood and managed. How integrated or disintegrated risk management is with strategic planning and performance.

Most ERM programs lack the fundamental building blocks for a risk management program, and that is established in an enterprise risk management charter and policy (or something similar if you do not like the term risk as some risk pundits do not). I will be presenting on this in detail in the upcoming webinar: PART 2: Developing an Enterprise Risk Management Strategy & Policy

I worked with one Fortune 100 firm that asked me what the main components of an ERM policy are and then asked me to review and comment on theirs. Here is what I provided.

MY ANSWER: ERM policies are organization specific; no two ERM policies are identical. However, there is a logical structure that works well as a starting block for most organizations. These include the following structural components for an ERM policy:

• Objective/Purpose. As with any policy it is necessary that the policy begin with the organization and purpose of the policy. This is nothing more than writing out the charter for ERM and establishing the authority of this policy to establish and govern the ERM program.
• Risk Governance Structure. It is critical that the organization establish the governance structure for risk management and specifically how it is aligned with strategic planning and objective/performance management. This is a big area of failure for most ERM programs when it is often the case that risk management operates as an island with very little to know interaction with the board and executives or with organization strategy and objectives. A solid ERM policy will identify how the board and its committees interact with ERM as well as senior executives.
• Roles & Responsibilities. Once the governance structure is in place, the policy should get into specific roles and responsibilities for ERM. This includes a clear understanding of the roles of a Chief Risk Officer, executive management, business operations, risk owners across the business, risk management staff, and the role of audit in the assurance oversight of risk management.
• Risk Culture. The single greatest hurdle to successful ERM is articulating and integrating risk management into the organization’s culture. In one sense risk management is part of the culture no matter what is articulated in policy – an organization can have a cavalier approach to risk taking, a structured approach to risk taking and oversight thereof, or anywhere in between. The organization needs to clearly spell out how the organization approaches risk taking, ownership, management, and ongoing monitoring of risk in the organization.
• Risk Strategy. Following on the heels of risk culture, the ERM policy should next deal with how ERM aligns and integrates with corporate performance, objective, and strategy management. ERM often is disconnected from these areas which makes it of little practical use to the organization.
• Risk Tolerance & Appetite. The next logical sequence in the ERM policy is to establish the boundaries of risk taking in articulating the organization’s approach and boundaries to risk tolerance and appetite (yes, I acknowledge that some I respect hate the term appetite, but this is where you would include it). It is hear that the policy discusses what is acceptable and unacceptable risk. This provides the high-level boundaries and approach to risk taking, though most of the specifics on these boundaries will be found in supporting policies (e.g., credit risk policy).
• Risk Taxonomy. The ERM policy needs to authorize and give authority to the development and ongoing maintenance of the organization’s risk taxonomy. The highest level structure for risk management should be included in the policy – such as the establishment of risk oversight for areas such as strategic, financial/treasury, operational, and legal/compliance risks. The policy should reference and give authority to the establishment of another document that defines the depth of the structure of risk categories that the organization recognizes and manages.
• Risk Ownership. You cannot hold anyone accountable for risk unless clear ownership of risk is defined. While specific ownership of individual risks are found in supporting risk management policies (e.g., vendor risk policy, privacy policy, credit risk policy, information risk policy) – the ERM policy should state the ownership of risk at the high-level categories defined in the risk taxonomy. It should also be clear on the point that the risk management function does not own risk, the business and process owners are the ones that own risk. The ERM process is there to communicate and provide the infrastructure to manage and monitor risk to support the risk owners across the business.
• Risk Assessment Process. The ERM policy is to authorize the formation of risk assessment processes in the organization. The policy itself should outline the expectations of required periodic assessments such as an annual ERM assessment process, and is to authorize the establishment of more specific risk assessments that are established in supporting risk management policies. This section of the policy should identify the approval needed to establish a risk assessment, what structure is provided, and how the assessment gets communicated and integrated into the ERM structure.
• Risk Infrastructure, Documentation. & Communication. Documentation of risk, risk taking, risk acceptance and ownership, as well as assessment, management, and monitoring activities for risk are critical to a successful ERM program. An organization cannot hold individuals accountable for risk taking if there is not clear documentation on the risk. This section should authorize the establishment of an enterprise platform to monitor ongoing risk management processes across the organization. It should also establish a warning against the use of technologies such as spreadsheets for risk assessments that lack proper audit trails and a system of record of risk activities.
• Mitigation & Response. The ERM policy should articulate the proper response plans to risk such as risk transfer, risk acceptance, risk mitigation, and risk avoidance. While much of the details of this will be worked out in supporting risk policies, it is in the ERM policy that the are defined at a high level.
• Key Risk Indicators. Ongoing monitoring for risk is critical to a successful ERM program. This involves the authorization and establishment of a process to gather metrics on Key Risk Indicators that are further defined in supporting policies. The ERM policy should provide guidance on how KRI information is collected, how often, and establish that KRI’s are to be relevant to the business and mapped to Key Performance Indicators of the business.
• Risk Training. Individuals throughout the organization has some role in risk management as part of their day to day oversight, management, and activities – it is necessary that risk culture, risk taking, and risk responsibilities be clearly understood at all levels of the business for the various business roles and the risks they encounter and manage. The ERM policy establishes an ongoing risk training and awareness program to communicate and educate risk to employees, stakeholders, and business partners.
• Risk Budgets/Funding. The ERM policy should establish and authorize the financing for risk management and oversight activities. This ties into other sections of the ERM policy as well as supporting policies to clearly define what budget areas various risk activities will be financed from.
• Risk Activities (calendar). The ERM policy should establish what activities are required of ERM on an ongoing/calendar basis. This should include monthly/quarterly/annual reports and assessments, the individuals responsible for them, and who they get communicated to. One of the best examples I have seen of this is at Microsoft in what they have called ‘The Rhythm of Risk’ in which risk management is aligned to the needs of the board and executives based on their quarterly and monthly calendars.
• Definitions. Finally, as with all policies, a section is needed that clearly defines definitions related to risk and risk management. I encourage the use of standard definitions such as those in ISO 31000 and ISO:IEC 73.

As I stated before, no two risk management policies are alike. What I have provided here is some guidance on the sections I most often include in developing an ERM policy (as well as supporting risk policies). There are other standard sections to policies such as revision history I have not included for the sake of simplicity.

I would love to hear your thoughts on the topic of ERM policies. Please feel free to comment in this forum, or send me an e-mail. If anyone seeks further help in writing, reviewing, and/or revising their risk policies please do not hesitate to contact me.

Upcoming Risk Management Webinar Series

The Evolution of Risk: Impacting Change Across the Organization

• PART 1: Overcoming Top Challenges in Risk Management, May 29 @ 11:00 am – 12:00 pm CDT
• PART 2: Developing an Enterprise Risk Management Strategy & Policy, June 19 @ 11:00 am – 12:00 pm CDT
• PART 3: Understanding the Lifecycle & Process of Risk Management in the Rhythm of Business, July 23 @ 11:00 am – 12:00 pm CDT
• PART 4: How Technology Makes Risk Management Efficient, Effective, & Agile (and How to Build a Business Case), August 20 @ 11:00 am – 12:00 pm CDT

Upcoming Risk Management by Design Workshops

• Risk Management by Design, London, United Kingdom, June 12
• Risk Management by Design, South Africa, September 11
• Risk Management by Design, Dublin, Ireland, October 22

Other GRC 20/20 by Design Workshops

• Policy Management by Design, London, United Kingdom, June 13
• Third Party Management by Design, Seattle, USA, September 24
• Third Party Management by Design, Minneapolis, USA, September 26
• Third Party Management by Design, Charlotte, USA, October 7
• Policy Management by Design, New York, USA, October 24

Providing 360° Contextual Awareness of Risk

The physicist, Fritjof Capra, made an insightful observation on living organisms and ecosystems that also rings true when applied to risk management: 

The more we study the major problems of our time, the more we come to realize that they cannot be understood in isolation. They are systemic problems, which means that they are interconnected and interdependent.

Fritjof Capra

Capra’s point is that biological ecosystems are complex, interconnected, and require a holistic understanding of the intricacy in interrelationships as an integrated whole, rather than a dissociated collection of parts. Change in one segment of an ecosystem has cascading effects and impacts to the entire ecosystem. Consider the interconnectedness of a cycle of risk in the context of a draught and a forest fire. A drought increases the risk of a forest fire. If a fire should start this further contaminates the water as a byproduct of the fire. As the forest regrows it further reduces the water supply to sustain this growth which could cause more drought conditions.

This is true in risk management. What complicates this is the exponential effect of risk on the organization. Business operates in a world of chaos. Applying chaos theory to business is like the ‘butterfly effect’, in which the simple flutter of a butterfly’s wings creates tiny changes in the atmosphere that could ultimately impact the development and path of a hurricane. A small event cascades, develops, and influences what ends up being a significant issue. Dissociated data, systems, and processes can leave the organization with fragments of truth that fail to see the big picture of performance, risk, and controls across the enterprise, as well as how it supports their strategy and objectives. The organization has to have holistic visibility and 360° contextual awareness into risk relationships across the enterprise. Complexity of business and intricacy, and interconnectedness of risk data, requires that the organization implement a risk management strategy.

Organizations take risks all the time but fail to monitor and manage these risks effectively in an environment that demands agility. Too often risk management is seen as a compliance exercise and not truly integrated with the organization’s strategy, decision- making, and objectives. A cavalier approach to risk-taking is a result of a poorly defined risk culture. It results in inevitable failure of risk management, providing case studies for future generations on how poor risk management leads to the demise of organizations – even those with strong brands. 

Gone are the years of simplicity in business operations. Exponential growth and change in risks, regulations, globalization, distributed operations, competitive velocity, technology, and business data encumbers organizations of all sizes. Keeping this risk, complexity, and change in sync is a significant challenge for boards, executives, as well as risk management professionals throughout all levels of the business. This challenge is even greater when risk management is buried in the depths of departments and approached from a compliance or audit angle, and not as an integrated discipline of decision-making that has a symbiotic relationship on performance and strategy. Organizations need to understand how to monitor risk-taking, measure that the associated risks being taken are the right risks, and review whether the risks are managed effectively.

Risk management in the modern organization is:

• Distributed.Even the smallest of organizations can have distributed operations complicated by a web of global supplier, agent, business partner, and client relationships. The traditional brick and mortar business with physical buildings and conventional employees has been replaced with an interconnected mesh of relationships and interactions which define the organization.  Complexity grows as these interconnected relationships, processes, and systems nest themselves in intricacy.
• Dynamic.Organizations are in a constant state of flux as distributed business operations and relationships grow and change. At the same time, the organization is trying to remain competitive with shifting business strategies, technologies, and processes while also keeping pace with change to risk environments around the world. The multiplicity of risk environments that organizations have to monitor span regulatory, geopolitical, market, credit, and operational risks. Managing risk and business change on numerous fronts has buried many organizations.
• Disrupted.The explosion of data in organizations has brought on the era of “Big Data” and with that “Big Risk Data.” Organizations are attempting to manage high volumes of structured and unstructured data across multiple systems, processes, and relationships to see the big picture of performance, risk, and compliance. The velocity, variety, veracity, and volume of risk data is overwhelming – disrupting the organization and slowing it down at a time when it needs to be agile and fast.
• Accountable.There is growing awareness among executives and directors that risk management needs to be taken seriously. It is part of their fiduciary obligations to oversee risk management as an integrated part of business strategy and execution. Furthermore, regulations that are increasing personal liability within these roles, such as the UK Senior Managers and Certification Regime (among other similar regulations), put an emphasis on business leaders taking greater interest and accountability for risk, control, and compliance.

Understanding the Interrelationship of Risk and its Impact

Risk management is often misunderstood, misapplied, and misinterpreted as a result of scattered and uncoordinated approaches that get in the way of sharing data. Risk is pervasive; there are a variety of departments that manage risk with varying approaches, models, needs, and views on what risk is and how it should be measured and managed. These challenges come at department and process levels, and continue to build as organizations develop operational and enterprise risk management strategies that span these departments. 

For some organizations, risk management is only an expanded view of routine financial controls, resulting in nothing more than a deeper look into internal controls with some heat maps thrown in, and does not truly provide an enterprise view of risk aligned with strategy and objectives. Completing a risk assessment process and ticking the box has got in the way of true risk analysis and understanding. 

Risk management is about the risk of not achieving objectives, therefore making the ability to link and measure risk to strategic objectives critical; as is monitoring performance against those objectives. The outcome of this is improved decision-making, better return on investment across the business, improved profitability, and a better customer experience.

Risk management silos — where distributed business units and processes maintain their own data, spreadsheets, analytics, modeling, frameworks, and assumptions — pose a major challenge to achieving this. Documents and spreadsheets are not equipped to capture the complex interrelationships that span global operations, business relationships, lines of business, and processes. Individual business areas focus on their view of risk and not the aggregate picture, unable to recognize substantial and preventable losses. When an organization approaches risk in scattered silos that do not collaborate, there is little opportunity to be intelligent about risk. This is due to the fact that it intersects, compounds, and interrelates to create a larger risk exposure than each silo is independently aware of. A siloed approach fails to deliver insight and context and renders it nearly impossible to make a connection between risk management and decision- making, business strategy, objectives, and performance. Risk accountability is frequently distributed across different board level owners. Today it is critical that these roles are all working off the same data and that this risk data is clean, reliable, and timely.

It can be bewildering to make sense of risk management and its varying factions across strategic, financial, credit, market, conduct, operational, project, legal, regulatory, third-party, strategic, insurance, and hazard risks. It makes enterprise and operational risk management a challenge if a risk management strategy forces everyone into one flat view of risk, confirming to have significant issues in risk normalization and aggregation as they roll-up risk into enterprise risk reporting. This is exponentially compounded when risk velocity is considered: when risk materializes into an event it moves very quickly. Are organizations agile enough to react?

The Risk Central Nervous System

Organizations need to develop a risk management capability aligned with strategy, performance, and objectives that operate as a risk central nervous system. Consider the following from Steve Balmer:

If you think of the human body, what does our nervous system let us do? It lets us hear, see, take input. It lets us think, analyze, and plan. It lets us make decisions and communicate and take action. Every company has a nervous system: companies take inputs, they think, they plan, they communicate, they take action.

Steve Balmer, former CEO Microsoft

A nervous system connects with other major systems of the body, and provides among others analytical capability, strategic thinking, and quick response to the environment. 

In the same context, organizations need a command and control hub that provides the analytical capability to measure and monitor a connected view of risk across:

• Strategy
• Operations
• Compliance & Regulatory
• Reputational
• Conduct
• Market
• Insurance
• Credit
• Liquidity

Managing risk effectively requires multiple inputs and methods of modeling and analyzing risk. This requires information gathering — risk intelligence — so the organization has a full perspective and can make better business decisions. This is an important part of developing a risk analysis framework. Mature risk management is built on a risk management process, information, and technology architecture that can show the relationship between objectives, risks, controls, loss, and events. The demand is for predictive analytics to extract from this mass amount of data what exactly will help to prevent future significant losses, events, as well as incidents, and further help strategic business objectives succeed.

This means enabling a federated and connected view of risk that leverages artificial intelligence, machine learning, and robotic process automation to make the risk management process more efficient, effective, and agile. This in turn enables organizations to spend more time focusing on the analysis of risk in the context of the organization, its strategy, and objectives. Technology makes it easier to share data, while still maintaining independence of thought and action across the organization. 

In light of this, organizations should consider: 

• How does the organization know it is taking and managing risk effectively to achieve optimal operational performance, and meet its strategic objectives? 
• Which objectives could fail as a result of current risks?
• How does the organization make the right business decisions?
• What impact does risk have on products and services? 
• What is the impact or potential impact on customers?
• Do businesses understand the interrelationships and correlations between risks? 
• Does the organization understand the relationships generally between cause and effect, processes, end-to-end process flows, and products and services? 
• Does the organization understand the risk exposure to each individual objective or process, and how it interrelates with other risks to aggregate into an enterprise perspective of risk? 
• Can the organization accurately gauge the impact risk has on strategy, performance, project, process, department, division, and enterprise levels? 
• Does the organization have the information it needs to quickly respond to and avoid risk exposure, and also to seize risk-based opportunities? 
• Does the organization monitor key risk indicators across critical projects and processes? 
• Is the organization optimally measuring and modeling risk?

Gathering multiple perspectives on risk is critical for producing effective relational diagrams, decision trees, heat maps, and scenarios. This risk intelligence comes from: 

• The external perspective.Monitoring the external environment for geopolitical, environmental, competitive, economic, regulatory, and other risk intelligence sources. 
• The internal perspective.Evaluating the internal environment of objectives, projects, risks, controls, audits, loss, performance and risk indicators, and other internal data points. 

The bottom line: Organizations are best served to take a federated approach to risk management that allows different projects, processes, and departments to have their own view of risk. This can then roll into enterprise and operational risk management and reporting that supports business objectives while being integrated with decision-making processes. This can be done through a common risk management strategy, process, information, and technology architecture that supports overall risk management activities from the process level up through an enterprise view. 

Organizations need to clearly understand the breadth and depth of their risk management strategy and process requirements, and from there select the right information and technology architecture that is agile and flexible to meet the range of risk management needs for today, and into tomorrow. 

Upcoming Risk Management Webinar Series

The Evolution of Risk: Impacting Change Across the Organization

• PART 1: Overcoming Top Challenges in Risk Management, May 29 @ 11:00 am – 12:00 pm CDT
• PART 2: Developing an Enterprise Risk Management Strategy & Policy, June 19 @ 11:00 am – 12:00 pm CDT
• PART 3: Understanding the Lifecycle & Process of Risk Management in the Rhythm of Business, July 23 @ 11:00 am – 12:00 pm CDT
• PART 4: How Technology Makes Risk Management Efficient, Effective, & Agile (and How to Build a Business Case), August 20 @ 11:00 am – 12:00 pm CDT

Upcoming Risk Management by Design Workshops

• Risk Management by Design, London, United Kingdom, June 12
• Risk Management by Design, South Africa, September 11
• Risk Management by Design, Dublin, Ireland, October 22

Other GRC 20/20 by Design Workshops

• Enterprise GRC by Design, Baltimore, USA, June 2
• Policy Management by Design, London, United Kingdom, June 13
• Third Party Management by Design, Seattle, USA, September 24
• Third Party Management by Design, Minneapolis, USA, September 26
• Third Party Management by Design, Charlotte, USA, October 7
• Policy Management by Design, New York, USA, October 24

Humans excel at analytics; it is the way our brains are wired. We are constantly taking in information, processing, analyzing, and making decisions. Whether it is crossing a street, reading a book, watching a show, being a spectator or a participant at a sporting event . . . we are constantly analyzing everything around us.

The challenge is that we can be throttled and slowed down in analysis. This is particularly true in a Governance, Risk Management, and Compliance (GRC) context. The official definition of GRC is that it is “a capability to reliably achieve objectives [GOVERNANCE], while addressing uncertainty [RISK MANAGEMENT], and act with integrity [COMPLIANCE].” To achieve GRC means that GRC roles and functions have to take in a massive amount of information, process it, align it in context, and make decisions.

Historically, we have done this manually. A lot of manual information gathering, processing, and reporting. Documents, spreadsheets, and emails were the backbone of this process. I was recently talking to one organization that was spending 200 employee hours building one report on GRC for the board of directors. They were combing through stockpiles of documents, spreadsheets, and emails gathering, calculating, and documenting information. This is not agile in today’s dynamic, distributed, disrupted business environment. We need GRC context quickly and efficiently. We need information to make the organization agile in a dynamic risk environment.

GRC related technologies have provided great benefit in automating . . .

[this is continued as a guest blog written by GRC 20/20 Research on the IsoMetrix Blog]

GRC 20/20 interacts with a lot of organizations as they evaluate solutions for policy and training management. As the only analyst firm that breaks this functionality out as its own segment of the broad Governance, Risk Management, and Compliance market, we have identified over 100 solutions that do policy and training management. Many of these are very niche and just focus on policies in a specific department or a specific industry, while several are what can be implemented for a consistent enterprise policy management program across the organization.

With an RFP requirement database of over 200 requirements for policy management solutions/platforms, GRC 20/20 breaks the market into basic, competitive, and advanced solutions. Interactions have included working with organizations of all sizes to assist them in their policy management RFPs. This includes a global organization that engaged GRC 20/20 for our RFP requirements in enterprise policy management to evaluate solutions to manage policies in 8 languages to over 160,000 employees across the organization. I have recently been interacting with one global bank as they build their business case for enterprise policy management and look to move forward with an RFP. But interactions also include inquiries with small and mid-sized organizations looking for policy management solutions.

I bring this experience to the table to provide background on the breadth of involvement of GRC 20/20 Research in policy and training management solutions available in the market. The reason is that I want to highlight some of the drivers and trends on how this has changed and what I see organizations are looking for now in the next generation of policy and training management. These can be divided across the following three areas:

• Back-office of policy management. Organizations are looking for that solution that enables the policy management lifecycle from the authoring, approval, communication plans, tracking, monitoring, metrics, and maintenance of policies. One of the key elements I see here that organization are looking for is the collaborative authoring environment. Organizations are looking for that next generation portal that allows multiple authors and editors to be in the document at the same time in a web interface. They want to move away from the document check in and check out approach as that is the old generation of technology and provide real-time collaboration and authoring/editing. There is also a need to manage policies in the context of regulatory change, particularly in financial services and integrate regulatory change and policy management processes. Organizations also desire the ability to manage exceptions, deviations, policy related form development and workflow (e.g., disclosures), and built communication and awareness campaigns on policies.
• Front-office policy and training engagement. Organizations are looking for solutions that are highly intuitive, engaging, and interactive (see graphic above). They want to bring policy and training together into the same portal. Every month I get inquiries from organizations that say their users, particularly millennials, go out to Facebook and can watch a video in Facebook, they don’t have to go out too YouTube to watch a video. That is the way modern technology works and what the want in the next generation policy and training portal. to bring together policy and training/eLearning/LMS into the same portal. They also want portals that are mobile that work on tablets and smartphones. In fact, I have had conversations with several firms that want to use tablets as policy and training kiosks as the bulk of their employees do not have computers issued for work (e.g., retail, hospitality, manufacturing). Intuitive, engaging, and interactive experiences are essential for the policy portal.
• Defensible compliance. One of the primary drivers for policy management solutions in the market is to provide a defensible system of record for all policy interactions from the back-office to the front-office. Regulatory challenges such as UK SMCR, US DOJ Guidelines, US Sentencing Commission Guidelines, US FCPA and more dictate that organizations have operational compliance that is more than paper and are driving compliance programs that include policy and training management. They need a record of activity on what policies were active at what time, who accessed policies, was trained on them, made aware of them. Documents, spreadsheets, and emails do not provide a defensible system of record and organizations are turning toward purpose built compliance and policy/training management platforms to provide this.

This is just scratching the surface on what organizations are looking for and considering in policy and training management solutions. There is a lot more, but this summarizes the general trends in three directions. The ultimate goal is to enable an organization of integrity that can demonstrate that values, ethics, commitments, and boundaries are clearly understood, communicated, and followed. And when they are not the organization takes action. Policies are critical governance documents that cannot be managed haphazardly.

Upcoming Policy Management Workshop

• Policy Management by Design, London, June 13
• Policy Management by Design, New York, October 24

Key Research on Policy Management Strategy

• Policy Management by Design

On-Demand Policy Management Research Briefings

• How to Purchase Policy & Training Management Platforms

Published Research on Policy Management – Strategy Perspectives

• Benchmarking Your Policy Management Program
• Policies, The Last Mile of Risk Management: The Relationship Between Risk and Policies
• Technology Priorities for Compliance & Ethics: Aligning Technology to Changing Requirements
• Regulatory Change Management: Effectively Managing Regulatory Change in Financial Services

This is the 3rd blog in a 5-part series on developing a strategic plan for Third Party Governance/Management in your organization.

Growing up in Northwest Montana I spent a lot of time in the outdoors. This led into a passion for rock climbing when I was in high school (a hobby I put aside for 25 years and am tempted to pick up again). Everything was something to climb. My friends and I would go into town late at night and climb buildings, I was in a climbing competition my senior year of high school, and then taught climbing in the Grand Tetons the summer after high school. Those were the days!

Climbing laid the foundation for me in evaluating GRC technology, and in the case of today’s topic 3rd Party Governance, Risk Management, and Compliance (3rd Party GRC) solutions. You don’t throw everything into a backpack haphazardly and start a climb. When you are climbing both space and weight are critical. You need to understand what the journey is ahead of you from start to finish and select the right equipment for you to accomplish the task. This is true of 3rd Party GRC technologies, platforms, and solutions.

There are over 140 providers of various aspects of 3rd Party GRC. Some are very narrow and do a very specific thing (e.g., financial health/risk of 3rd parties, GDPR compliance, Conflict Minerals), while others provide a broad platform to manage an array of 3rd Party GRC needs and requirements. But even the broad platforms have differences. I have been fielding a number of complaints from organizations that find the 3rd Party Modules in their Enterprise GRC Platforms to be limiting as they only manage things at the relationship level but fail to get into the contract and service level agreements. A large bank may have a relationship with a service provider or outsourcers, but there may be 100 contracts/service level agreement tied to that one relationship. The bank needs to know that 89 of those contracts touch GDPR requirements. Or a manufacturer needs to know the individual materials and components and the traceability of those materials/components down through a nested supply chain. Some solutions do not go deep or broad enough.

Third Party GRC is often a module that fails in Enterprise GRC initiatives as organizations try to bundle everything into one platform. This can work with the right solution, but as these organizations move forward with their Enterprise GRC Platform they often find that the 3rd Party GRC module is limited and does not meet the requirements of managing the details of a relationship that are critical to the organizations . . . so they end up scrapping this module and go looking for a deeper solution that can meet their needs.

The right technology architecture enables the organization to effectively manage 3rd party performance and risk across extended business relationships, and facilitate the ability to document, communicate, report, and monitor the range of assessments, documents, tasks, responsibilities, and action plans. There can and should be be a central core technology platform for 3rd Party GRC that connects the fabric of processes, information, and other technologies together across the organization. Many organizations see 3rd Party GRC initiatives fail when they purchase technology before understanding their process and information architecture and requirements. Organizations have the following technology architecture choices before them:

• Documents, spreadsheets, and email.Manual spreadsheet and document-centric processes are prone to failure, as they bury the organization in mountains of data that is difficult to maintain, aggregate, and report on – consuming valuable resources. The organization ends up spending more time in data management and reconciling, as opposed to active risk monitoring of extended business relationships. 
• Point solutions.  Implementation of a number of point solutions that are deployed and purpose built for very specific risk and regulatory issues. The challenge here is that the organization ends up maintaining a wide array of solutions that do very similar things but for different purposes. This introduces a lot of redundancy in information gathering and communications that taxes the organization and its relationships.
• ERP and procurement solutions.There is a range of solutions that are strong in the ERP and procurement space that have robust capabilities in contract lifecycle management, transactions, and spend analytics. However, these solutions are often weak in overall 3rd party governance, risk management, and compliance, but these players have now started to look more at 3rd Party GRC.
• Enterprise GRC platforms.Many of the leading enterprise GRC platforms have 3rd party (e.g., vendor) risk management modules. However, these solutions often have a predominant focus on risk and compliance, and do not always have the complete view of performance management of third parties. These solutions are often missing key requirements, such as third party self-registration, third party portals, and established relationships with third party data and screening providers.
• Third Party GRC Platforms.These are solutions that are built for the breadth and depth of 3rd Party GRC. Some are fully focused on just 3rd Party GRC, while a few Enterprise GRC platforms have deeper capabilities than their peers. These solutions have the broadest array of built-in (versus built-out) features to support the breadth of third party management processes. In this context they take a balanced view of 3rd party governance and management that includes performance of third parties, as well as risk and compliance needs. These solutions often integrate with ERP and procurement solutions to properly govern 3rd party relationships throughout their lifecycle, and can feed risk and compliance information into GRC platforms for enterprise risk and compliance reporting where needed.

Successful 3rd Party GRC requires a robust and adaptable information architecture that can model the complexity of 3rd party information, transactions, interactions, relationship, cause and effect, and analysis of information that integrates and manages:

• Master data records.This includes data on the third party such as address, contact information, and bank/financial information.
• Third party compliance requirements.Listing of compliance/regulatory requirements that are part of third party relationships.
• Third party risk and control libraries.Risks and controls to be mapped back to third parties.
• Policies and procedures.The defined policies and procedures that are part of third party relationships.
• Contracts.The contract and all related documentation for the formation of the relationship.
• SLAs, KPIs, and KRIs.Documentation and monitoring of service level agreements, key performance indicators, and key risk indicators for individual relationships, as well as aggregate sets of relationships.
• Third party databases.The information connections to third party databases used for screening and due diligence purposes, such as sanction and watch lists, politically exposed person databases, cyber-security ratings, as well as financial performance or legal proceedings.
• Transactions.The data sets of transactions in the ERP environment that are payments, goods/services received, etc.
• Forms.The design and layout of information needed for third party forms and approvals.

The right third party technology architecture choice for an organization involves integration of several components into a core third party governance platform solution to facilitate the integration and correlation of third party information, analytics, and reporting. Organizations suffer when they take a myopic view of third party management technology that fails to connect all the dots, and provide context to business analytics, performance, objectives, and strategy in the real-time business operates in. Some of the core capabilities organizations should consider in a third party governance platform are:

• Internal integration.Third party management is not a single isolated competency or technology within a company. It needs to integrate well with other technologies and competencies that already exist in the organization – procurement system, spend analytics, ERP, and GRC. So the ability to pull and push data through integration is critical. 
• External integration.With increasing due diligence and screening requirements, organizations need to ensure that their solution integrates well with third party databases. This involves the delivery of content from knowledge/content providers through the third party technology solution to rapidly assess changing regulations, risks, industry, and geopolitical events.  
• Content, workflow, and task management.Content should be able to be tagged so it can be properly routed to the right subject matter expert to establish workflow and tasks for review and analysis.  Standardized formats for measuring business impact, risk, and compliance. 
• 360° contextual awareness.The organization should have a complete view of what is happening with third party relationships in context of performance, risk, and compliance. Contextual awareness requires that third party management have a central nervous system to capture signals found in processes, data, and transactions, as well as changing risks and regulations for interpretation, analysis, and holistic awareness of risk in the context of third party relationships.

It is critical that organizations closely understand the breadth and scope of 3rd Party GRC across the organization and define a strategy and process for what they want to accomplish now, as well as 3 to 5 years from now. It is then they can evaluate and consider the right features and functionality they need in a 3rd Party GRC.

Supporting 3rd Party GRC Research . . .

GRC 20/20 has defined this in our key research paper (currently being revised):

• Third Party Management by Design

GRC 20/20 is also presenting on how to build a business case for and evaluate the range of 3rd Party GRC solutions in the market:

• Buyers Guide: Third Party GRC Solutions

GRC 20/20 is also facilitating several upcoming workshops on this topic as well:

• Third Party Management by Design, Atlanta – April 15th
• Third Party Management by Design, Houston – April 17th
• Third Party Management by Design, Seattle – September 24th
• Third Party Management by Design, Minneapolis – September 26th
• Third Party Management by Design, Charlotte – October 7th

Other Case Studies, Strategy Perspectives, and Solution Perspectives on Third Party GRC can be found here.

Ask GRC 20/20 an inquiry on what 3rd Party GRC solutions available in the market and what differentiates them, this is what we do – research and analysis of technology for GRC . . . .

Outside of Governance, Risk Management & Compliance (GRC), my passion and interest is in British medieval history – from the Anglo-Saxon period through the Plantagenets and the War of the Roses. Nothing quite inspires like a good Anglo Saxon epic, particularly Beowulf. One of my favorite moments is when Beowulf goes up against the vicious monster Grendel. Grendel is a behemoth of a monster, devouring, imposing, and outright terrifying. Beowulf engages Grendel unarmed with no armor and defeats him in a vicious battle by tearing off the monster’s arm. The agility of Beowulf in a fight against a dominant and imposing behemoth reminds me of what is taking place in the context of GRC platforms and technologies in the market.

The Dominion of the GRC Behemoth

A few months back there was a LinkedIn post that described the song Hotel California as being a parable of an implementation of one GRC solution, that after $500 thousand in license, and $2 million in implementation, three years later it is ready to do something. This is something I am hearing every week from organizations that are frustrated with GRC Market Leaders that have significant cost of ownership and build out. Where an organization has to have certified experts make changes because of the complexity of the system and it may take months to see configuration changes implemented.

Several of my workshops this past year have had prominent organizations express their frustrations with established GRC Leaders in the market (note: I use the term GRC but these are also the same leaders Gartner has in their IRM Magic Quadrant). In reviewing RFPs GRC 20/20 has been involved in over the past two years, solutions that Gartner and Forrester consider a Leader, in their respective Magic Quadrants and Waves, have a ratio of software license to implementation of 1:3 to 1:5. That is for every dollar spent on software license in the first year an organization can expect to spend 3 to 5 dollars on configuration and build out. This is the configuration and build out, not management consulting costs for process design. Solutions that are outside the Leaders quadrant have a ration of about 1:0.5 to 1:2. While some of these GRC Leaders are working hard to rearchitect their solution to address this, it is opening the door to other solutions that have entered the market with highly agile solutions.

Era of Agile GRC

The reality is that GRC can be agile and not a behemoth of cost. There are a range of solutions in the market that are highly agile with ease of configuration and adaptability. This was illustrated at a user conference I was a keynote speaker at last year in Sydney, Australia (note: I am not naming names in this post as there are several agile solutions in the market and want to be fair to all, you can always ask me about these in inquiry). This is a young GRC solution provider who had their solution on the market less than a year and had 200 people at their conference (which is very impressive for a user conference in Sydney, let along a first user conference). After my keynote, they had a session in which they stated they would build a complete case/incident management module with forms, workflow, tasks, and reporting in else than an hour. To illustrate this further they had 2 bartenders up front with 200 cocktail glasses and said this fully functioning module will be complete before the bartenders finished pouring 200 drinks for the attendees. They did it.

GRC 20/20 is seeing a range of highly agile GRC related solutions in the market that have a significant return on value and low cost of ownership when contrasted to legacy GRC solutions that are often seen as the market leaders. This is forcing the market to adjust to consider highly agile solutions available to organizations as well as traditional market leaders to rearchitect their solutions to remain competitive.

I would love to hear your thoughts and experience . . .

Or you can also ask GRC 20/20 an inquiry on what Agile GRC solutions are the up and comers and what is changing with traditional market leaders so they can maintain their positions . . . .