How to make GRC management enterprise-wide

A silo’d approach
to information management—with each department or division jealously protecting
its IT information assets—is common in a large organisation. There may be
some security benefits in this structure, but appropriate information from each
department has to be made available to the central management systems.

A similar silo’d
situation arises in regard to corporate governance, risk and compliance (GRC)
tasks. GRC needs to pervade the whole enterprise to be efficient and effective,
with a silo’d approach generally to the detriment of its functioning.

This is typically
exacerbated by a series of overlapping functions. Although titles vary, there
is nowadays commonly the equivalent of a chief risk officer (CRO), chief
finance officer (CFO), chief compliance officer (CCO), security manager, and an
internal audit manager function—and, somewhere in the middle of this, because
everything nowadays revolves around IT systems, the CIO.

Each of these will
be backed by a group of people and systems—who are all after some of the same information (mixed with
some specific to their needs alone), but presented in the way they are used to
using it, historically different for each. Nor is any one them going to roll
over and change to fit software for one of the other functions; this will not
give them what they need in the way that they want it.

A knock-on effect
of the silo’d approach is that each group will typically gather this common
information from other departments separately. Where this means other
departments need to complete questionnaires and complying with assessment
requests, those departments could be wasting time gathering overlapping
information and repeating answers on forms for one or other of them.

According to
Gordon Burnes, VP of sales and marketing at GRC software supplier OpenPages,
one enterprise the company dealt with was using no less than 40 different
solutions at once. Whatever else this achieved, it certainly did not make for
good governance. “Assessment fatigue from constantly supplying information
means quality goes down,” Burnes told me.

Unsurprisingly,
OpenPages believes it has cracked the problem. It has certainly come face to
face with it in many big-named enterprises which it can name among around 250
customers in the US
and elsewhere. The principle OpenPages uses is simple enough but that does not
mean it is easy to do.

OpenPages (version 5.5 recently released) uses a central repository for all risk
and compliance data, and this includes frameworks, libraries, policies,
entities, processes and accounts. So the repository can hold all the
information—both quantitative and qualitative—that all the GRC-affected
departments normally collect.

Parameters are set
for each piece of collected data to denote which departments need it and which
do not—immediately revealing the potential for consolidation, including
consolidation of common activities such as the assessments, into a single
platform which is process-driven. A flexible front end means each compliance or
risk group can view the information in the format it prefers (even down to one
department using “A, B, C” and another “1, 2, 3” for the same information).

Probably the
biggest benefit of this approach is that it is adaptable to fit the existing
company risk and compliance methodology; risk assessments, for instance, can be
applied at any enterprise level. Risk and compliance management can then be
integrated into the everyday business processes with the minimum of disruption—and the new software can be gradually implemented over time.

I am sure most
serious GRC software vendors will ultimately conclude this is the most
practical approach to go for the large enterprises. (Where other software does
this it should then only be a matter of features, functionality and benefits,
despite what major vendor consultancies who advise on GRC may say.) However,
there is one other thing that is needed in order to make this happen.

“It needs a
mandated approach,” said Burnes. In other words, this needs to be driven with
top-down authority. It needs the CEO’s blessing and possibly more than that to
make sure the CFO, CRO, CCO et al all give it whole-hearted support, and the
CIO gives priority to its implementation.

In the end, this
has to be done top-down and enterprise-wide—or the business will be left with
even more exposure to risk and legal sanction for non-compliance than it is
already.