The Value of a Common Architecture for GRC Platforms

Business is complex and dynamic, and requires agility to stay competitive. Market leadership requires the organization be quick to respond to changing conditions – to pause means loss. Governance, risk, and compliance (GRC) processes often work against business agility. Requirements and initiatives managed across numerous silos, using manual or varying technology approaches, burden the business. The lack of a common process and technology architecture comes at a significant management cost.

Whether the enterprise uses the “GRC” acronym or not, the fact is, every organization practices GRC. There is not a single executive that will tell you that they lack corporate governance, do not manage risk, and completely ignore compliance. The truth of the matter is, GRC has been a part of business since the dawn of business.

GRC is akin to the customer/client relationship management (CRM) systems of the 1980’s. Before CRM systems and processes entered the organization, client information and relationships were still being managed. The challenge was that they were being managed in scattered silos that created inconsistent and redundant data, with no view of the entire profile of the client and its interaction with the business. CRM systems entered the picture to create a single view of customer information and interaction across business processes and roles. GRC systems and processes aim to achieve the same thing – an integrated picture of governance, risk, and compliance information and processes across the business. An integrated view of GRC requires establishment of business processes and technology architecture.

The bottom line: Organizations spend more money on risk and compliance than they should, because of inefficient GRC processes.

Organizations have relied on manual and basic technology to manage risk and compliance processes. The cost to the business of inadequate GRC approaches is significant. Some areas where organizations report significant issues and cost include:

  • Excessive paper and spreadsheets.
  • Limited and fragmented reporting.
  • Files and documents out of sync.
  • Significant spend on external auditors and consultants.

A common GRC architecture makes risk and compliance efficient and manageable. Inefficiencies, redundancy, errors, and potential risks are identified, averted, or contained. This reduces risk exposure, and enhances business agility and performance.

Organizations require an enterprise view of GRC that not only brings together silos of risk and compliance, but integrates them into a common GRC architecture.

Robust GRC systems contain multiple applications, such as risk management, policy management, audit management, and document management. The individual functionality of each GRC application is key to achieving the desired results.

A less obvious and often overlooked key to GRC success lies in the integration and consistent design of each application. GRC systems lacking a common architecture (backbone), common user interface, and consistent processes and functional behaviors seldom deliver the full value and benefits sought by the organization. In fact, use of a collection of disparate GRC applications has been repeatedly demonstrated – in real-world settings – to actually reduce visibility and increase risk.

Business requires GRC architecture with a common user experience and seamless application and data integration across GRC modules. Specifically, value and economies are achieved when the GRC suite of applications delivers a common:

  • User and role-centric experience: The GRC application should meet the needs of each user accessing it, with relevant information, tasks, and processes specific to the business role.
  • Business-process orientation: A GRC application needs to automate business processes through workflows and elimination of information redundancy. Consistent risk and compliance management is essential to achieving value.
  • Environment focused on flexibility: A common GRC architecture not only allows for consistency, but also provides business agility in adapting GRC processes to a changing business.
  • Collaborative and information-rich experience: Business requires a GRC architecture that facilitates collaboration across business roles and presents information with respect to intricate relationships and within the appropriate business context.

In summary, business today requires a common GRC architecture that is context-driven and adaptable to a dynamic and changing business environment.

Simply put, a common architecture can enable a better-performing, less costly, more flexible solution. Organizations should not assume that all software platforms labeled “GRC” deliver a common technology architecture. Some solutions are assembled without a consistent strategy – a stream of mergers and acquisition activities compounds the problem, as the organization ends up with several code bases and data models.

A software system with a common architecture has the following:

  • A common user interface (screen design) for all applications.
  • A common workflow engine throughout the applications.
  • A common security model to protect applications and data.
  • A common programming language used to build the applications.
  • A common database used to run the applications.
  • A common enterprise architecture (a method for describing the departments and divisions within the organization).

Not all GRC software platforms are created equal. Some are a hodge-podge of technology because of a history of mergers and acquisitions; some are rushed to market without a common application and information architecture.

Delivering value and economies in GRC requires the application is built on a common architecture. With a common GRC architecture, the organization achieves business agility, consistency, efficiency, transparency, and accountability across GRC processes.

When investigating GRC solutions, Corporate Integrity encourages you to ask your technology provider the following five questions to expose the risks of a potentially flawed architecture:

  1. Which portions of the current solution did you build, and which did you buy or obtain through acquisition?
  2. Which portions of the system were developed by a third-party development firm?
  3. Are all consultants and trainers certified in each application module?
  4. Describe how the data for each application is stored in the database(s)?
  5. If you change the architecture of an application or consolidate architectures for multiple applications in the future, will you guarantee:
    • No loss of current features or functionality?
    • A full migration to the new architecture at no additional cost?

For the full text on this – please download my research piece: The Value of a Common Architecture for GRC Platforms. I would love to hear your thoughts, experiences, and approaches to GRC Technology. Please comment on this blog or send me an e-mail

No comments yet.

Leave a Reply