This article can also be found in the Premium Editorial Download "Information Security magazine: Finding affordable encryption options for laptop data security."
Download it now to read this article plus other related content.
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
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.
This was first published in June 2010