June 28, 2006, 9:56 AM — 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.
