The GRC (platform) Fallacy

There’s a common mythos perpetuated by many security vendors (or, at least, by their sales forces) that you can buy a tool, install it, and problems will be solved. This mythos oftentimes short-circuits problem solving processes, jumping to “solutions” without doing earlier steps, such as defining the problem. More often than not we see this sales approach coupled with a heavy dose of FUD, intended to “prove” to a prospective customer that there is a great “risk” (term used incorrectly) that must be mitigated. If you buy their tool, then you’ll be saved! Or not, as the case more likely is…

One area where I’m increasingly seeing this nonsense is in the GRC (Governance, Risk, Compliance) space. Vendors are making a push these days to add customers, and they’re apparently willing to do it at any cost. Specifically, they’re aggressively pushing their solution onto customers who don’t have a GRC program. That is, these customers typically will have old, weak policies, and no real formalization to their governance or risk management processes. They may or may not have a compliance management program. In short, they have little or no process, policy, or documentation. The vendors are seizing upon these entities and selling them a pipedream; that buying their tool will magically imbue their organizations with a GRC program by virtue of buying a GRC tool/platform. To say the least, this is a dishonest sales practice.

There is no substitute for doing the base work in establishing a GRC program. If your organization does not have a reasonable base of policies, processes, and documentation, then adding a tool will not make this situation any better. In fact, it’ll probably make things worse. Why is that? Simply put: if you buy a tool first, then you will have to change your organization to match the tool. Taking such an approach is a recipe for disaster, because organizational transformation is itself extremely difficult and costly, and even more so when the changes are arbitrary to match a piece of technology. More importantly, all of the GRC program development work will still need to be done, but in buying a tool you will now hamstring your efforts by limiting your options.

The most important lesson here is this: You do not need a GRC tool/platform in order to have a GRC program. In fact, it’s better that you don’t have a tool at first, since it can unnecessarily limit or hinder your program development efforts. Instead, build a program that makes sense for your organization. Once you have the fundamental components in place, then and only then should you consider a GRC platform. In this scenario, you can then properly define requirements for what you need the tool to do, which will let you make a better selection. You’ll find that this is a far more worthwhile approach, and that you will then be able to demonstrate the value from such an acquisition.