I talk to people all day about various security concepts, including GRC. While certain things in tech are pretty well known, GRC is one of those things that seems to mean different things to different people. I suppose the reality is that people tend to want different things from a GRC program, therefore they just describe it in different terms. Some folks might have an emphasis on board level risk management and, as a result, really focus on identifying and communicating high-level business risks. Others may have challenges in the area of third-party risk management and want to focus on workflows and automation around vendors. All of these things are part of GRC, for sure. But, I think these aspects of GRC are perhaps more rewards of a functional GRC program (and advanced examples, to boot) as opposed to core elements of GRC.
When I think of what GRC is, I think of the basic building blocks: (1) Governance, (2) Risk, and (3) Compliance. Those pillars have a relationship to one another and we should start there. In my opinion, many GRC initiatives fail because organization lose sight of these basic things and focus instead on those more advanced concepts before they tackle the basics. So, if you’re starting your own GRC program, my recommendation is to keep it simple.
I start many of my conversations by describing the relationships of core GRC components, just so we have a starting point. Let’s go over those now…
In the graphic above, I try to break things down into things we need to do, things we say we do, and things we actually do. Let’s look at those areas:
Things We Need to Do
This tends to be one of the key drivers for most GRC initiatives. Organizations need to comply with something, so they want to track it. These typically fit within one of the following categories:
| Industry requirements | Requirements can often be imposed by specific industries. This can also be called “self-regulation.” Perhaps the most common form of self-regulation is the PCI-DSS, which is a requirement not set in law, but established by the payments industry itself. It is enforced through contracts and also through risk transference. Those organizations that do not become PCI compliant may absorb some of the risk otherwise accepted by the card brands. |
| Laws | These are the requirements established through state or federal legislative decree. Examples of information security and privacy laws would be CA SB 1386, the California Consumer Privacy Act (CCPA), and the Gramm-Leach-Bliley Act (GLBA). |
| Regulations | Regulations are the close cousin to laws. Instead of being created by legislative bodies, regulations are promulgated by government agencies. An example would be the regulations established by the Federal Financial Institution Examination Council (FFIEC), which are then enforced through organizations like the Federal Deposit Insurance Corporation (FDIC), the National Credit Union Association (NCUA), and the Office of the Comptroller of the Currency (OCC), among others. |
| Contracts | We sometimes forget about contracts, but they can be a big driver for what an organization needs to do. For example, a contract with a key client may dictate that an organization implement multifactor authentication (MFA) or that the company adhere to complete frameworks, like PCI-DSS. |
Things We Say We Do
Under this umbrella, we find the stuff that we document. If PCI-DSS says you need to have an information security program, guess what? You draft one. That program is going to say that you do a bunch of stuff… whether you do or not is a different story. The types of things that contain what we say we do include:
| Policies | Policies are high-level statements of management intent from an organization’s executive leadership that are designed to influence decisions and guide the organization to achieve the desired outcomes. |
| Standards | Standards are mandatory requirements in regard to processes, actions, and configurations that are designed to satisfy Control Objectives |
| Guidelines | These are recommended practices that are based on industry-recognized secure practices. |
| Procedures | Procedures are a documented set of steps necessary to perform a specific task or process in conformance with an applicable standard |
Things We Actually Do
Most of the GRC space (and our security posture as a whole) comes down to what we actually do. After all, saying we need to implement MFA doesn’t actually make it so. The proof, as they say, is in the pudding. We look at what we actually do as “controls”.
| Controls | Controls are the nexus used to manage risks through preventing, detecting or lessening the ability of a particular threat from negatively impacting business processes. |
Controls can come in a number of forms. Usually, these are either technical, physical, or administrative. Saying you have to lock your front door would be an administrative control, installing a lock could be a physical control, and installing a lock that automatically locks after 5 minutes would be a technical control.
Once we identify the stuff we need to do, the stuff we say we do, and the stuff we actually do, we need to put it all together. This means control testing. First, does the design of the control satisfy the requirements? For example, if the requirement calls for a wall around my house, but I only have a wall around my garden, it doesn’t meet the requirement. Next we need to test if the control is effective. If I put a wall around the entire house, but it’s only 12″ tall, it probably isn’t going to serve the desired purpose. Or, if the wall is so weak it blows over when my neighbor sneezes, it just wasn’t implemented well. In either case, the control would fail.
If we have a control fail, we mark it as a finding, which is to say that we log it as a problem. When doing so, we want to identify why it’s a problem. That comes in two forms: (1) we can identify that a failure of a control is a problem because we are not doing what we need to do, which is a compliance problem, but (2) we can identify a risk that emanates from that control deficiency. In the wall example, the lack or dysfunction of the wall could allow unwanted visitors entry to my property. In addition to identifying the risk, it is a good idea to identify the potential solution (a project). Now, this can get tricky as you may not know the exact solution. But, you want to be as specific as you can. In the wall example, you may not know the specific material or desired height. But, you may know that the minimum solution is a solid, sturdy wall of at least six feet. Both the risk and the solution are critical pieces to the GRC puzzle, as we want to be able to evaluate our collective risks and prioritize remediation activities. Some people ask me why the solution is relevant, since they think the highest risk items should be enough for prioritization. But, I tend to see that businesses, like people, want to know what they can get for their money. If, based on the potential solutions available (given their cost, speed to implement, etc.), the business is able to solve more of the lower risk items with their available budget, time, and skills, they may choose to go that route.
I hope this discussion of basic GRC principles was helpful to understand what GRC is and how it can be used. My intent in going through this is to help you focus on the foundational elements of a GRC program before you move on to advanced topics. The way I see it, if you have a GRC program that effectively identifies the primary legal/regulatory drivers, establishes associated governance artifacts, and successfully and routinely evaluates the controls in place to meet those requirements, you’re ahead of the game.
I plan to have future parts of this series to help drive your GRC initiative beyond these basics. Until then, cheers!