From: www.itworld.com

Automating governance, risk and compliance: 10 key considerations

by Ted Frank

June 28, 2006 —

 

Effectively automating the breadth of governance, risk and compliance (GRC) requires a journey few have completed. Most GRC efforts are executed within silos of specific, discrete compliance requirements, whether it is Sarbanes-Oxley or HIPAA. Even when addressed broadly, GRC has often been treated as a "nice-to-have" add-on to other projects or programs. Exacerbating this phenomenon is the fact that GRC practitioners have traditionally lacked the political clout to secure resources and the experience in building technology business cases -- all while being charged with achieving organizational compliance. The good news is that times have finally changed. With the heightened focus on risks and regulations, GRC is now being transformed into a formal category of automation.

Following are ten key considerations that should help IT and GRC practitioners kick off the debate as well as some simple steps for early implementation of a successful GRC program.

1. A Starting Point

First, complete a comprehensive inventory. What GRC programs exist? Who is accountable for each of them? What tools are being used? What processes are already in place? Who is mandating and evaluating them? How is GRC baked into compensation practices?

It is remarkable how broadly risk can impact an organization when financial, legal, operational and regulatory risks are included in the definition. Even more remarkable is how difficult it is to quickly secure solid answers to these questions. Compiling an inventory of explanations is the first step in understanding the organization's GRC ecosystem and getting a feel for its overall health and effectiveness. Gather this base information in advance of a technology discussion because it will allow the team to better define impact across a broad set of issues and drive benefit to more stakeholders.

2. Document the organization's current GRC vocabulary

One of the most basic and significant problems many organizations face is the range of definitions and perceptions surrounding common GRC terms. Each perception (or definition) is influenced by many experiences, issues or projects, which leads to countless assumptions being made in even the simplest GRC discussions. Technology has always treated compliance as many individual, secondary considerations instead of a set of processes to be collectively considered. Correcting the situation begins with getting your arms around who assumes what in the organization.

Compliance Management - Defined

Compliance management is the implementation of processes designed to control any type of risk and meet voluntary or mandated expectations of performance. Prominent mandates that fall under GRC include Enterprise Risk Management, Sarbanes-Oxley, HIPAA, Corporate Code of Conduct, Anti Money Laundering statutes, Operational Risk and COBIT.

3. Define the GRC vocabulary to be used going forward

Before any real dialogue can begin around GRC, a standardized baseline vocabulary must be established throughout the organization. The key terms required to carry on a productive conversation should be clear and easy to remember, with well thought out, simple definitions. Simple candidates include obvious terms like "risk," "compliance" and "governance" but also less obvious terms such as "loss" or "control." Once established, these definitions should be communicated to all involved and immediately put into practice. These terms should also be reiterated throughout training, developed through ongoing education and implemented with new personnel. For a sample GRC vocabulary, click here.

4. Adopt a process standard that can be consistently applied across GRC programs

It is essential for practitioners and technologists to decide on a consistent process model that facilitates deployment of a solution meeting a broad array of GRC processes/needs. Most people involved in GRC for the first time believe that their particular mandate is unique. As one of the most common failure points in GRC, this issue can be linked to various historical problems, ranging from inconsistent processes to the development of countless single use, isolated technologies that ultimately fail to deliver significant value. Best practice GRC processes are now emerging, however, presenting new opportunities to more effectively manage this far-reaching set of domains. One of the most complete standards is published by the Open Compliance and Ethics Group (OCEG). To see examples of these click here.


Key Considerations

Technologists

Practitioners

5. Develop a GRC methodology centered on integration with core operating practices

Long ago, business people realized that quality needed to be woven into the fabric of the organization. Operating, sales and manufacturing personnel all need to make quality a substantial part of their everyday practices to make the product work. Many organizations have even established environments where quality is such an integral part of the company culture that workers automatically incorporate it into their approach of duties without a second thought. Quality is assumed.

The similarities between quality and GRC are striking. GRC also must be part of the culture of an organization to be most effective. In order to achieve such a state, compliance officers must be obsessed with fitting risk issues within the context of the organization's core operating practices. GRC cannot be treated as an isolated function of mandates dictating approaches to compliance. By concentrating on and understanding GRC's impact on core operating processes, GRC managers can achieve a critical appreciation of their impact on the business as a whole.

A solid understanding also serves as a baseline for discussing opportunities with technology personnel who may be focused on driving these same operating processes. Think of it as a common ground from which GRC and technology personnel can collectively meet each others' objectives.

6. Find the most vocal critics of GRC and make them allies

GRC management's impact on business operations is often murky and tough to quantify. That being said, these issues have an agreed upon impact on operational performance. Find those units or operations most affected by (and perhaps most unhappy with) compliance requirements and work with them to streamline and lessen impact without degrading efficacy. Making the extra effort provides important opportunities to demonstrate effective leadership and win support for technology projects.

7. Select a consistent set of metrics to be used across GRC

GRC may be one of the last bastions of un-automated processes and one of the last areas where performance metrics are few and far between. Even if metrics do exist, they are often inconsistent across risk domains and lack important context. Defining these metrics in advance provides an important end-point that practitioners and technologists can use as a benchmark in their automation discussions. Beginning without the end goal in mind is like beginning a cross-Atlantic voyage without maps or a GPS navigation system.

8. Recognize that GRC is a strategic issue and an important driver of business performance

Recent evidence has begun to show that effective risk management enables organizations to be more competitive and nimble in the marketplace. That being said, the dialogue between technology and GRC practitioners is bound to take an entirely different tone if executive management and all parties involved operate under the assumption that effective GRC is an important driver of business performance.

9. Aggressively identify and capture quick wins

Rather than trying to drive a large and expensive project to automate a large part of the GRC puzzle, practitioners and technologists will be much more successful if they identify a series of quick win projects. Many of these projects exist, each of which can have a significant impact on the reputation of the GRC team and, in turn, the resources allocated to it. Assuming the prerequisite steps have been completed, including process model metrics and definitions, the solutions put in place to address these quick win opportunities should drive immediate and recognizable benefits. Demonstrating the technology's ability to deliver quick wins and to extend usage across multiple projects is an important validation of the approach.

10. Define your technical requirements and needs

In a recent survey of GRC practitioners, those who had begun implementing GRC platforms, instead of using existing technologies or point tools, rated their satisfaction with their technology substantially higher. In contrast it is very easy for GRC practitioners to focus narrowly on the mandate in front of them at the moment and request technology for specific needs. Gartner estimates that this "siloed" approach can cost up to ten times more in technology costs. Providing your technology partners with well thought out, consistent process models, desired metrics and corresponding functional requirements will undoubtedly produce a stronger result, a better return on investment, and a better relationship.

All companies face GRC issues, it is how practitioners approach the issues that makes the difference. Those teams that take a careful, well thought out approach to execution, beginning by focusing on a limited number of specific goals while setting benchmarks to monitor overall processes, will realize immediate and long-lasting benefits.

The ideas expressed in this article are solely those of the author and do not necessarily reflect the opinions of ITworld.com.