GRC: What Does It Mean?

Marketing Mythos

Perhaps the most damning comment one can make about GRC - either as a platform or a discipline - is that it's simply the product of clever marketing efforts. In particular, many in infosec have argued that GRC is really nothing more than a made-up buzzword (like APT and cyberwar) that only serves the purposes of vendors, and goes against the best interests of the business.

The truth is that GRC is more than just a marketing myth. It represents the confluence of several key notions that have matured in parallel over the past 10-15 years. It's probably true that GRC was a bit premature in its market entry and definition, but in the grand scheme of things, GRC is central to all that the business does on a daily basis.

To understand how GRC is more than simply marketing rhetoric, let's take a look at each of the key terms in GRC (Governance, Risk [Management], and Compliance), how those terms are defined in various fora, and then discuss practical applications of each key area. In the end we'll try to pull it all together into one comprehensive "how it all fits together" picture. We'll also discuss where security fits into this mix, since the letter S is notably absent from the GRC acronym.

What Do These Terms Mean, Anyway?

GRC as a discipline has existed since pre-Internet time, though albeit in a more primitive and less technical form. At its core, GRC comes to us from the business management schools with a focus on corporate governance. Once the Internet revolution began, things then started to accelerate and the ability of organizations to effectively manage people and technology became challenged. We hit a tipping point around 2002 as we came out of several accounting scandals. It's at that point that the Sarbanes-Oxley Act of 2002 (SOX) came into existence, which in turn triggered increased focus on other existing regulatory frameworks (e.g., HIPAA and GLBA ). Post-2002, the regulatory environment absolutely exploded, with new regulations both domestically and internationally (e.g., PCI DSS, HITECH, CA SB-1386, various European regs, NERC/FERC regs.).

GRC stands for Governance, Risk (or Risk Management), and Compliance. In many ways it is an odd and arbitrary confluence of concepts, while in other ways it makes perfect sense (more often it's just really confusing). There are a few questions that come out of this framework, which will be addressed in the next couple sections. However, before we even get to that point, let's talk about what each of these terms mean, both definitionally as well as in a practical sense.

Governance

The first term, Governance, is - I think - the hardest to define. I asked on Twitter recently for people to define, in 140 characters, what IT Governance is. Unsurprisingly, only one (1) person provided a serious response (and he provided 2, actually), which was endorsed by one other person.

Dictionary Definition: "exercise of authority; control" or "a method or system of government or management."

OCEG "Red Book" 2.0 Definition: "[The] culture, values, mission, structure and layers of policies, processes and measures by which organizations are directed and controlled. Governance, in this context, includes but is not limited to the activities of the Board, for governance bodies at various levels throughout the organization also play a critical role. The tone that is set, followed and communicated at the top is critical to succes."

From Stephen Gantz (@secarch):
* "IT Governance: trying to ensure you spend IT $$ and run IT projects that match business priorities/support business objectives"
* "Alternative: IT governance keeps you from wasting IT resources on things that provide little or no value"
(Source tweets available here and here

In Practical Terms: What we're talking about with Governance overall is, literally, management of an organization. In the sense of "IT Governance" we're then talking about management of technology within organizations. The reason this subset of governance arose is because technology has primarily been considered an overhead expense and is historically rather expensive. Even today, when most technologies are commoditized (to the degree that you can whip out a credit card and go buy tons of server space from Amazon or Google), it is still, nonetheless, something very foreign to human beings.

Originally, it seems that the Governance in GRC was really meant as IT Governance. However, today we see that the niche is broadening, especially as it expands its tendrils into areas like business intelligence. Also, as we'll discuss in the next section, Governance is coupling with Risk Management to start formalizing decision analysis and management practices that have to this point been largely academic.

Back to practical terms, when we think about "Governance" in the GRC context, we should be thinking about how organizations are run, and specifically how IT is efficiently and effectively managed. It applies traditional finance and economic thinking (for better or for worse) to the application of technologies in order to analyze costs, benefits, and effectiveness. We're very familiar with these analyses already in the legacy business context, and IT Governance attempts to extend these practices into newer technology-oriented realms.

Risk

The second term in GRC is Risk (or Risk Management, per some sources), and man does it give us a lot of headaches! It seems like everything these days is described as risk-this and risk-that. We get vulnerability scans with high, medium, and low risks (sometimes "critical" risks, too!). There is risk in the financial world, risk in the economic world, risk in the legal world, and risk in the IT world. Humans intuitively understand risk in the physical sense, and they seem to have generally grokked financial risk (Wall Street and Fed failures aside), at least in the sense of "nothing ventured, nothing gained." However, when it comes to information risk, well, we're neophytes in the wilderness, unsure how to even measure or describe "risk," let alone how to properly manage it.

Dictionary Definition: "1. exposure to the chance of injury or loss; a hazard or dangerous chance"

OCEG "Red Book" 2.0 Definition: "Risk, in this context, is the measure of the likelihood of something happening that will have an effect on achieving objectives; most importantly, but not exclusively, an adverse effect. Thus, Risk Management is the systematic application of processes and structures that enable an organization to identify, evaluate, analyze, optimize, monitor, improve, or transfer risk while communicating risk and risk decisions to stakeholders. The overriding goal of risk management is to realize potential opportunities while managing adverse effects of risk."

From Jack Jones at Risk Management Insight, creator of FAIR:
* "Risk isn't a 'thing.' It's a derived value, much like speed."
* "Risk = the probable frequency and probable magnitude of future loss"

In Practical Terms: One of the first problems I have with "risk" in general is this: what's the unit of measurement? Or, is it even something that you can measure? I'm not convinced it is. Just as "security" is a state or feeling, so risk also tends to be fuzzy and, frankly, somewhat emotional. When we talk about risk, what we're really talking about is probability as it relates to loss. Don't let others confuse you on this point. Sure, you can "take a risk" and benefit from it, but it's not usually the positives that cause us to give pause and consider things; it's the negatives!

"Risk" in the context of GRC deals with how we make decisions. As such, it's really just a component of Governance, which provides our overall framework for managing, operating, and, frankly, making decisions. If Governance tells us the rules within which we must operate, then "Risk" informs our decisions as we attempt to push the envelope within (or on the edge of) those rules. Pretty much everything we do in life - whether it be writing a blog post or buying a product or driving our car around town or selling professional services - comes with a degree of risk (be it financial, legal, physical, or otherwise). Making reasonably-well-informed decisions that properly account for the chance of a (significant) loss is then imperative to good decision-making as part of Governance. In the future, my expectation is that we will likely see risk management evolving into a larger decision analysis discipline of which risk analysis is one (very key) component.

Compliance

Generically...

Dictionary Definition: "1. the act of conforming, acquiescing, or yielding"

OCEG "Red Book" 2.0 Definition: "[The] act of adhering to, and the ability to demonstrate adherence to, mandated requirements defined by laws and regulations, as well as voluntary requirements resulting from contractual obligations and internal policies."

Specifically... compliance is the responsibility of organizations to understand, meet, and manage their regulatory and governance burdens. Or, put another way, organizations have a responsibility to be compliant with their regulatory and governance burdens. Of the three terms in GRC, Compliance is probably the easiest to understand, and yet it's also become one of the most misused and abused terms around. It seems like the vast majority of "security" efforts these days are attributed to Compliance, when, in fact, Compliance should merely be a footnote in the overall scheme of things.

Within the context of GRC, Compliance speaks to Compliance Management, which is the process of managing compliance requirements and the associated remediation and support efforts that go along with those requirements. Simply put: Compliance Management looks at your regulatory, contractual, and policy obligations and helps the organization make a best effort at meeting them.

Anything more than that simple definition should be severely questioned. Unfortunately, due to historic resistance to security improvements (and a historically poor job done by infosec in explaining the need for infosec), we've instead seen Compliance used as a stick to drive orgs to do things. It seems today that the lion's share of IT and infosec budgets are spent on compliance today when, in fact, it should account for a minimal overhead cost.

With respect to Governance and Risk, Compliance is merely a subset. Under Risk, Compliance is the subset that deals with the likelihood that fines or other negative impacts will occur as a result of not meeting an obligation. Under Governance, Compliance merely amounts to taking note of requirements (external and internal) and making a reasonable effort to meet these obligations as best as possible.

What About Security?

One of the more common questions that we're left with in pondering this GRC vertical is this question of where "security" fits with it. My take here is perhaps not consistent with the mainstream today, though I do believe that it will become the common approach in the future (please note that I also speak to the question a bit in my post "Defining GRC (the discipline)"). To understand my thinking, let's first start with version 2 of the Total Enterprise Assurance Management (TEAM) Model.

If you look at this overall picture, then you will note a few things:
1) "Governance" and "Compliance" aren't anywhere to be found.
2) "Risk" exists, but only as a subset of the overall system.
3) "Security" is only on there once.

Here are the key take-aways from this diagram:
1) Governance is the whole picture. And, really, this is just the IT subset of Governance, which should integrate fully with existing management structures.
2) Compliance informs Requirements with respect to what external and internal obligations exist. Compliance is then enacted through the Policy Framework, which is in turn met through both Information Security Management (operations) and through Quality & Performance Management activities (e.g., audit). Specifically, actions necessary to meet external and internal obligations are addressed under both of these areas depending on the nature of the obligation.

So... why isn't "security" part of GRC? For the same reason that the TEAM Model is not a "security" model. Security is a desirable attribute of a system; an emerging property. Security is not an activity, but a descriptor. All services, all applications, and all systems should be designed, built, and operated in a secure manner that meets the survivability requirements established as part of the overall risk management strategy, which in turn supports the direction of the company as is communicated and managed by the Governance system.

How Does It All Fit Together?

The big, final question: Now that we know what Governance, Risk, and Compliance mean, how do we fit them all together? It's an interesting question, to which very few have successfully developed a good answer. I think that there are probably a few different considerations to bear in mind.

First, Michael Rasmussen says that GRC is about "corporate integrity." I think, to a degree, that is true. In my mind, what he's saying is that GRC platforms, in particular, help keep executives informed and honest. As a discipline, GRC means adopting formalized methods for corporate governance, IT governance, risk assessment, decision analysis, etc. These are all Good Things (tm). However, that being being said, we also have to be careful to which organizations we apply this thinking. A full-scale GRC program, supported by a major GRC platform deployment, is probably not a good fit for your average Mom & Pop shop. How, then, can we scale GRC back to meet their needs?

Another thought of mine involves these GRC tools/platforms... honestly, as it stands today, I really don't care much about them. Before you can make use of tools, you first must get your house in order. You need to start defining formalized governance structures. You need to understand risk management and have reasonably sound ways to leverage it in decision-making. You need to have decent policies and you must have technical controls implemented that help you manage your organization and your risk. Until all of these pieces are in place, there's very little room for a GRC product.

Unfortunately, what we oftentimes see is organizations waking up to "APT" or "StuxNet" or HIPAA+HITECH compliance or PCI DSS or whatever the day's hot-button topic might be and they conclude that "if only we had a GRC solution, then we could magically solve all our problems." Nothing could be further from the truth. You do not need a GRC solution. A GRC solution is a nice-to-have item that can make running your GRC program more effective while reducing overhead, but that's only true if you already have a GRC program in place.

In the end, then, GRC is all about putting together a quality management program within your organization, regardless of size or scale, that helps your organization more effectively manage itself, its activities, its people, and its resources. Governance provides the framework within which to manage, risk analysis provides improved data points that lead to better decision-making processes, and compliance management ensures that we're properly apprised of our external and internal obligations. In many ways, we can analogize GRC as being the brain and nervous system of the body, helping regulate functions, but without actually performing said functions. As such, it's a vital component to any organization, though it's not the only component, but rather is part of the overall complex system.