GRC Federalist Papers: A Call to Action
Business is complex. Gone are the years of simplicity in business operations. Exponential growth and change in risk, regulations, globalization, distributed operations, processes, competitive velocity, business relationships, disruptive technology, technology, and business data encumbers organizations of all sizes. Keeping complexity and change in sync is a significant challenge for boards and executives, as well as governance, risk-management, and compliance professionals (GRC) throughout the business.
GRC cannot be managed in isolated silos that lead to the inevitability of failure. This is what I call ‘anarchy’ architecture where decentralized, disconnected, and distributed GRC processes catch the organization off guard to risk and exposure. Complexity of business and intricacy and interconnectedness of GRC requires that we have an integrated approach to business systems, data, and GRC processes. However, the opposite is also a challenge: ‘monarchy’ GRC architecture. In this approach the organization takes a one-size-fits-all approach to GRC and tries to implement GRC processes through a single GRC platform all are required to use. This forces the organization to adapt and manage GRC to the lowest common denominator.
The challenge for organizations is how to reconcile homogeneous GRC reporting, risk transparency, performance analysis, and compliance with an operating model that is increasingly heterogeneous as transactions, data, processes, relationships, mobility, and assets expand and multiply. GRC fails when risk is addressed as a system of parts that do not integrate and work as a collective whole. GRC fails when it is thought of as a single platform to manage workflow and tasks. GRC is about the interactions and relationships of cause and effect across strategy, process, transactions, information, and technology supporting the business and requires a GRC architecture approach.
In the end, GRC architecture, and particularly technology, should not get in the way of business. The primary issue is overhead in extensive services and technology implementation to integrate and develop massive GRC implementations that end up slowing the business down and delaying value (if value is ever achieved). The problem is that by what GRC vendors call integration they really mean consolidation, replication, and redundancy. There is a huge gap between being functional and agile.
Organizations should aim to define a GRC architecture that effectively reconciles organization strategy, process, information, and technology into what I call a ‘federated’ GRC architecture that enables oversight, reporting, accountability, and analytics through integration with business processes, data repositories, and enterprise systems. Let GRC work with and throughout the business and not force parts of the business into a mold that does not fit. Allow for diversity while providing integration, discipline, and consistency. Note the word “centralization” is being avoided. To “centralize” immediately imposes alien constructs that undermine agility. Federated GRC goes beyond functional to be agile and valuable to the business by delivering a harmonious relationship of GRC and the business. GRC is to enable enterprise agility by creating dynamic interactions of GRC information, analytics, reporting, and monitoring in the context of business. Federated GRC enables agility, stimulates operational dynamics, and, most importantly, effectively leverages rather than vainly tries to control the distributed nature of the modern enterprise.
This blog article is part of the OCEG GRC Illustrated Series that GRC 20/20 is engaged as a thought leaders and designer: The Federated GRC Approach
