Skip to Content

I give a lot of credit to the analysts and other pundits (e.g., at OCEG and among the CPA firms) who push the value of GRC convergence. Rather than having fragmented functions that operate independently in a fragmented fashion – resulting in inefficiencies, gaps, and redundancies – they advise organizations to ‘federate’ the departments and related processes involved in managing GRC issues so they can operate in a more convergent or coordinated fashion.

But, and this is a significant ‘but’, these analysts and pundits are pretty silent on the need to avoid GRC applications fragmentation. In the same way as functions and processes need to federate to ensure efficiency and effectiveness, it is critical to ensure that the applications that support each aspect of GRC work effectively together.

For example, does it make sense to have separate applications for the management of corporate strategies and the risks to the strategies? Doesn’t it make more sense to link the information in the strategy management application to the related risks in the risk management application? When you have separate applications with essentially the same data, each system may have different definitions for that data and make it difficult for the user to keep them aligned and in sync.

Does it make sense to have risks in one application and another, totally separate application house the assessment and testing of controls over those risks?

Instead, at least one analyst advocates selecting the best individual point solutions without considering the potential for duplicative data (and the problem keeping them in sync), the need for the applications to work together in a federated process, and the total cost of ownership when you have application proliferation.

To report this post you need to login first.

6 Comments

You must be Logged on to comment or reply to a post.

  1. Jonathan Simcock
    OK, point made but what are SAP doing to enable GRC federation across vendors/applications within corporations.  How about SAP sponsor a GRC data exchange protocol/standard so that convergence on true GRC federation across the enterprise can be plotted.
    (0) 
    1. Norman Marks Post author
      Jonathan, our primary response to this need is to integrate our own GRC applications:
      – strategy management is linked to risk management
      – risk management is linked to process control, where controls are identified and tested
      – process control is linked to access control for IT access management

      In addition, we are working with select partners to enable them to interface their complementary products with ours.

      (0) 
        1. Norman Marks Post author
          Babak,

          Federated in this context means that there is no necessity for all the functions to report to the same manager, or all the application functionality to be tightly integrated. The applications need to be able to work effectively together, where the data is kept in sync (with the same definition and values) and redundancy minimized. Many times, human intervention is required rather than purely automatic updating. For example, if a control is tested and found ineffective, judgment should be applied to determine the level of risk this represents, rather than immediately upgrading related risk levels.

          (0) 
  2. Gregory Guglielmetti
    What was there first the chicken or the egg? Application fragmentation exists because GRC and Risk Management are interpreted in completely different approaches by different business Areas in most companies. Software products for GRC were born out of different necessity (Axentis and RiskMetrics for example for banking) GRC and Approva have more of an industrial/SAP background and there are countless others “risk approaches” that have been “hardcoded” in specific GRC solutions.
    If a GRC solution decides to follow the COSO model, its probably going to be quite useless for a project risk management tool or for a credit risk solution. I do not believe there will be “one approach” and “the solution” to GRC issues, it is just too broad a field. At least until a common “ontology” will be developed for GRC that will be shared accross industries and solutions. Until then, happy fragmentation!
    (0) 

Leave a Reply