It’s All About the Data

One of the great challenges in consolidating governance, risk, and compliance efforts across an organization is the centralization of all of the GRC relevant information.  GRC touches nearly every aspect of your business, from the ‘tone at the top’ to the test results from a given user account on a database last September.  Just identifying the information, crossing organizational boundaries to get access or permission to it, and consolidating it into a single authoritative repository can be a significant project involving many stakeholders.  This is one reason that I often advocate starting with a clearly defined, funded, specific compliance area.  It allows you to manage the complexity, find early success, and iterate and expand as appetite and budget allow.  Any initial success can begin the flow of data, and that data will help to drive decision making for future projects.

Due to the cost of capturing or generating this data, be it testing activities or the monitoring of key indicators, many organizations have an expressed interest in automation.  Automated testing, evidence capture, and the ability to update Key Risk Indicators (KRIs) or Key Performance Indicators (KPIs) in a timely fashion can reduce the costs of GRC while improving the quality and timeliness of the information captured.  The secondary effect is that the data flow begun with your early projects will turn into a data flood.

An Embarrassment of Riches

So, what to do with this sudden wealth of centralized compliance data?  The first and most obvious answer is to ‘pass the audit’ if you have a compliance focus, or ‘avoid the loss’ if you have a risk focus.  And certainly these are the central reasons for starting down the GRC path.  The initial focus must be on dashboards and reports that support the essential compliance and risk management processes, including the current state of affairs, important milestones and deadlines, and the management of any identified issues.  In my discussions with our customers and partners, the final paper reports required by upper management or auditors can vary significantly – so some degree of flexibility in the reporting of GRC data is essential.  At the same time, there are a large set of rather common requirements that should be met by online dashboard elements with a minimum of configuration required.

This early focus on audit reporting is natural, and essential.  But the net result of a GRC project should be greater than paper compliance reports and be generated faster than before.  As with so many other areas of business, the impact of having access to a large amount of centralized data is itself transformative.  The concept of key indicators is not new, but the ability to drive key indicators for risk and performance rests upon the availability of centralized GRC data.  Standardizing data collection and the language of risk allows executives to have a broad view across the various business units and projects, and see - perhaps for the first time - the overall risk portfolio of the organization.

Tell It Far and Wide

And yet, focusing reporting and dash-boarding efforts only on the C-suite also misses an opportunity.  While the board of directors generally drafts the risks to the business captured in annual reports, it’s the mid-level managers who, on a day-to-day basis, are responsible for directing employees, tasks, and budget.  Shouldn’t they have a view into the risks the organizations faces, and their responsibility to manage or reduce that risk?  Individual contributors carry out tasks daily that are control activities; shouldn’t they have the ability to log their activities?  Compliance managers should be able to see the availability of key personnel, and manage their projects by budget, time, and completion.  Control and asset owners need to know the status of their areas of responsibility.  Control testers should know what tasks they have to complete.  The list goes on; to net it out, while Governance, Risk, and Compliance may sound a bit autocratic, the reality of the solution is far more bazaar than cathedral. 

All of this can be summarized in a few basic requirements.  A GRC solution should be able to slice and dice data based upon roles in the organization, visualize that for the appropriate audience, have a standard set of online reporting for day to day use, and finally should support flexible report writing against the GRC repository.  It sounds simple enough, but as with all things risk and compliance related, the devil is in the details.