Due to the stunning increase in the amount of regulatory and industry requirements over the past decade, a methodology...
commonly referred to as governance, risk and compliance (GRC) emerged. The most basic definition of the GRC methodology is that it harmonizes efforts across previously detached disciplines that existed in their own silos within an organization.
Historically, compliance was a function of audit, risk management -- if it was performed at all-- was a function of management, and governance generally didn't exist as a discipline outside of Wall Street and the banking industry until Sarbanes-Oxley (SOX) made it a requirement for publicly traded companies. However, with the emergence of the Payment Card Industry Data Security Standard, the maturation of SOX and the increased scrutiny being brought to bear by industry-specific regulations such as Gramm-Leach Bliley (GLBA) and the Health Insurance Portability and Accountability Act (HIPAA), it's become impossible for organizations to avoid addressing each of these disciplines. And the amount of effort required by an organization in order to fulfill its compliance obligations can be substantial.
GRC aims to help streamline compliance efforts but the concept has become clouded as vendors tout automated GRC solutions and even compliance practitioners don't all agree on what it's supposed to be. Let's take a closer look at the GRC concept, the key steps for developing a GRC program, and where the discipline is headed.
GRC began making its way into the business community in the early part of this decade. In 2003, the Open Compliance and Ethics Group (OCEG) began designing frameworks to rein in the myriad corporate activities required to achieve compliance. The nonprofit group is comprised largely of volunteers from a wide range of business domains who over the years have published several standards to provide a consistent approach for defining and managing a GRC program (see page XX). Not long after the group started their work, a suite of software products began to emerge that were hyped as complete, automated GRC solutions.
Today, type "GRC" or "governance risk compliance" in any popular search engine and the page fills with a wide range of software products from a variety of vendors. So is GRC a methodology or a software product? David Bachman, a partner with Quasar Associates, who advises clients in audit and risk, says, "I don't think of GRC as either a methodology or software driven solution. It is an overall way to look at governance, risk and compliance and can include methodologies developed in various areas (SOX compliance, ITIL, HIPPA) and the associated software solutions for those areas." Even so, it's difficult to determine at the onset of a GRC implementation where to begin. Do you need to have GRC software in place to guide the process? "The methodology drives the strategic end of GRC implementation; the software supports the strategy," explains Scott E. Cohen, senior manager of IT advisory services at KPMG. "One should not select software until the strategy is developed and requirements obtained."
To further complicate matters, even seasoned audit and compliance professionals don't agree on exactly what it's supposed to be. Carol Ward, a risk management consultant who works in the banking industry, describes GRC as "simply being the natural framework that leaders should use to organize their oversight of risk management in their organization." However, she's found that much of the content available to educate practitioners has blurred the lines, adding that recent blogs on the topic have "gone off into confusing intellectual discourse."
Some practitioners struggle to define the disciplines and how they relate to one another. For example, many view GRC as synonymous with enterprise risk management (ERM). "They are one in the same. If you are implementing an ERM solution you must have all of the elements of GRC included," Bachman says. But at a fundamental level, GRC is intended to include all of the related disciplines represented in its name, Cohen says: "I view GRC as the convergence between all the disciplines."
DEVELOPING A GRC PROGRAM
A fundamental truth about developing a GRC program, or framework, is that much of what needs to be built into it is very likely already present in an organization. After a decade of GLBA, seven years of SOX, five years of PCI and a lifetime of audit, a wide range of related activities need to be integrated into your GRC program. Unfortunately, they are likely isolated by discipline (e.g. audit, project management, legal, etc.) and unique to the business silo they are used to support. This often results in multiple teams with related frameworks in the same functional areas. Ask any key IT stakeholder about compliance and they'll likely regale you with stories of how they're being asked to provide evidence for testing non-stop and by different compliance groups. But the silver lining to this sometimes suffocating effort is that it makes it easier to identify and inventory what controls are already in place and which requirements they're aligned against. Consider these key activities when scoping out the prospects of developing a GRC framework:
- Inventory what you have. Manage this much like you would a risk assessment. Develop a standard questionnaire and circulate through your infrastructure, making sure to interview all stakeholders. Identify the compliance requirements, inventory what controls have been aligned against those requirements and who typically coordinates the testing to ensure they're functioning as documented. But be prepared to meet some resistance during the process as GRC will likely appear as one more compliance initiative to support. "Most organizations feel like they have all this stuff already: 'We have compliance officers for HIPAA, we have ITIL in place, we are SOX compliant. Why do we need something more?'" Quasar's Bachman says. He adds that the greatest challenge is "selling the idea that you need something that can pull all this information together from these various silos, without having to recreate everything."
Keep in mind that beyond what you find in developing the inventory, you'll also need to conduct a gap analysis in order to identify required controls that may be missing.
- Align inventoried controls against in-scope regulations. There are two clear efficiency gains from a properly developed GRC framework: a coordination of efforts between the three domains (governance, risk and compliance) and a consolidation of efforts to implement and maintain the necessary controls. Dorian Cougias, founder of Lafayette, Calif.-based Network Frontiers and lead analyst of the Unified Compliance Framework (UCF), which maps IT controls across international regulations, standards and best practices, says that five years ago, people argued about whether compliance mandates should or even could be harmonized. "Now everyone takes it for granted, because of the ridiculous rate at which compliance mandates are growing, that harmonization is a must for survival," he adds. For example, if you need to test logical access controls in support of both PCI and SOX, you would want to identify that commonality and coordinate your efforts so that both regulations are supported by a single approach. Not all tests can be applied to seemingly related requirements but by working with the internal controls experts, those that are candidates will be identified and managed accordingly.
- Sell the benefits of GRC to management. Perhaps the most significant component of GRC is the point where it engages management. A major element of GLBA addresses management's responsibility to ensure that non-public personal information is handled properly. Consider a similar approach when building out a GRC program. A common practice for banking institutions is to arrange for information security training for their board of directors to educate them on their responsibilities in support of GLBA; think about using a similar approach when designing your GRC framework. Tone at the top is an integral part of a successful program because at the next level down from the executive suite, there's a constant power struggle regarding ownership and direction for each of the related GRC domains. Cougias explains how governance is rooted in methodology, or a body of methods and rules used in a given discipline, that is defined by senior management. Compliance, on the other hand, is conveyed as a process: a series of actions or operations, he says. Fundamentally what that means is that while the rules are set by executive management, the related control activities are developed and supported by stakeholders throughout the organization. Oftentimes, the stakeholders design and support controls to achieve compliance and don't expand them to consider efficiencies and are often resistant to cooperative efforts. Setting the tone at the top is critical because it's from senior management that the rank and file takes their marching orders. Without the C-level team supporting the GRC initiative and providing direction, it's unlikely that the methodology will develop deep roots.
One of the key benefits from a GRC program is the coordination of activities across the silos. If audit isn't directed to work with the risk management team and if both groups don't work with key stakeholders throughout the institution to coordinate and align their efforts, the program is unlikely to succeed. The OCEG Red Book 2.0 (GRC Capability Model) talks about embedding controls within the innumerable business and related operational processes -- an effort that requires a bit of organizational muscle. Eventually an institution needs to move past using GRC as a better way to maintain compliance and leverage its capabilities to manage the business; leave it to middle management to drive the GRC framework and that's not likely to happen.
Nonprofit provides GRC guidance
Organizations looking for guidance on building a GRC program can look to the Open Compliance and Ethics Group (OCEG). A nonprofit organization, the OCEG has taken a leadership position within the GRC domain by producing a series of standards and guidelines that provide clear direction on how to assess and develop the necessary controls to support GRC. The documentation is designed and vetted by a mostly volunteer group that reads like a "who's who" of GRC thought leaders from across the audit and compliance industry. The de facto standard for developing a GRC framework is the Red Book 2.0 (GRC Capability Model). Included within the document is an overview of GRC and its related disciplines and directions on building out either a complete or partial framework.
A second key document authored by the OCEG is the Burgundy Book (GRC Assessment Tools), which helps institutions evaluate the design and effectiveness of its GRC framework. The Burgundy Book includes an overview of the assessment process, criteria for success and a series of tools to assist in the process. Both of these documents can be obtained free-of-charge after establishing a user account with OCEG. In addition to documentation, the OCEG website offers related information and links to support the GRC community and help advance the adoption of GRC principles.
Despite the fact that GRC has been around in some form for several years now, it's still very much in its infancy in terms of widespread adoption. Much like COBIT, another popular governance-based framework that languished for years in relative obscurity until it helped provide clarity in the age of SOX, GRC is poised to become a key business strategy in the near future. While no one is certain what the next round of banking legislation is going to entail, one thing is almost certain: better risk management activities are going to be expected if not required. "Hopefully companies will see the need to expand GRC to not only control compliance risk, but as a means to help manage the overall success of their organization," Quasar's Bachman says.
Also expect significant advances in the availability of automated GRC solutions. While they've been around for a while, they've been slow to make significant headway as a straightforward GRC solution; that's going to change. Wider adoption of GRC as a framework combined with better integration of regulations into GRC software will make it easier to see the benefits of implementing a software solution. There are already solutions that highlight interdependencies between various regulations when entering controls, thus ensuring economies of scale are identified automatically; this capability will continue to improve. "If today we are just beginning to make the links between mandated compliance processes and GRC tool methodologies, then in the next couple of years we'll see this bond strengthening," Cougias says. And in the very near future those capabilities will improve as GRC tools begin to pass information to other applications to update them for compliance, he adds.
Perhaps the biggest changes to GRC will be in how it's understood and relied upon. The last thing an enterprise is willing to consider while operating under the constraints of current economic conditions is spending money on or committing resources to something that's not critical to their bottom line. However, as the various elements of GRC become better understood and practitioners become more adept at articulating their value proposition to their management, you can expect that to change. According to the OCEG GRC Capability Model Redbook 2.0, "a high-performing GRC system will always deliver value." Once that becomes an accepted fact and not just a line embedded within documentation, GRC will have finally arrived.
David Schneier is managing director at consulting firm R.I.S.C. Associates with extensive experience in developing, implementing and managing compliance programs. Send comments on this article to email@example.com