After you define your Third-Party GRC Strategic Plan, and define your Third-Party GRC Processes, next comes the defining and deploying your information and architecture to enable third-party GRC/risk management . . .

The primary directive of a mature third-party governance program is to deliver effectiveness, efficiency, and agility to the business in managing the breadth of third-party relationships in the 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. This is built on a defined information and technology architecture that delivers 360° contextual and situational awareness of your third-party relationships.

Third-Party GRC Management Information Architecture

Third-party GRC management fails when information is scattered, redundant, non-reliable, and managed as a system of parts that do not integrate and work as a collective whole. The third-party GRC management information architecture supports the process architecture and overall third-party GRC management strategy. With processes defined and structured in the process architecture, the organization can now understand the specifics of the information architecture needed to support third-party processes. The information architecture involves the structural design, labeling, use, flow, processing, and reporting of third-party management information to support third-party management processes. 

Successful third-party GRC management information architecture will integrate information across third-party management systems, ERP, procurement solutions, and third-party databases. This requires a robust and adaptable information architecture that can model the complexity of third-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 an 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 intelligence databases and services. The information connections to third-party databases used for screening and due diligence purposes, such as sanction and watch lists, politically exposed person databases, as well as financial performance or legal proceedings.
  • Transactions. The data sets of transactions in the ERP environment include payments, goods/services received, etc.
  • Forms. The design and layout of information needed for third-party forms and approvals.

Third-Party GRC Management Technology Architecture

The third-party GRC management technology architecture operationalizes the information and process architecture to support the overall third-party GRC management strategy. The right technology architecture enables the organization to effectively manage third-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 a central core technology platform for third-party GRC management that connects the fabric of the third-party GRC management processes, information, and other technologies together across the organization. Many organizations see third-party GRC management 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 difficult data to maintain, aggregate, and report on, consuming valuable resources. The organization spends more time in data management and reconciling than active risk monitoring of extended business relationships. 
  • Point solutions. The implementation of several point solutions that are deployed and purpose-built for particular risk and regulatory issues. They typically focus on one and possibly more areas of third-party risk. The challenge here is that the organization maintains an array of disconnected 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 solutions. There is a range of strong ERP and procurement space solutions that have robust capabilities in third-party transactions and spend analytics. However, these solutions may be weak in overall third-party governance, risk management, and compliance. 
  • Enterprise GRC platforms. Many of the leading enterprise GRC platforms have third-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 often miss key requirements such as third-party self-registration, third-party portals, and established relationships with third-party data and screening providers.
  • Third-party GRC management platforms. These are solutions built specifically for third-party GRC management and often 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 third-party governance and management that includes the performance of third parties and risk and compliance needs. These solutions often integrate with ERP and procurement solutions, or may be provided by a procurement solution, to properly govern third-party relationships throughout their lifecycle and can feed risk and compliance information into GRC platforms for enterprise risk and compliance reporting where needed.

The right third-party GRC technology architecture choice for an organization often involves integrating several components into a core third-party GRC management 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 that business operates in.  

Some of the core capabilities organizations should consider in a third-party GRC management 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 in the organization – procurement system, spend analytics, ERP, and GRC. 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 delivering 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 tagged to 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 the 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 and change risks and regulations for interpretation, analysis, and holistic awareness of risk in the context of third-party relationships.

The above blog is an excerpt from GRC 20/20’s latest research paper, there is much more detail on each of these 7 areas in the research paper, Third Party GRC Management by Design:

Leave a Reply

Your email address will not be published. Required fields are marked *