Assessing the TCO of Your GRC Tech Project

Implementing GRC technology is probably one of the least pleasant tasks compliance officers have to do. I have literally had one compliance officer call me to complain, “We were using Vendor A, and they stunk, so we’re trying Vendor B,” followed by another compliance officer who said, “We were using Vendor B, and they stunk, so we’re trying Vendor A.”

This is fascinating for me on the outside, because I know many of the vendors, too. They are smart people. They can explain GRC problems well, and on the white board their solutions seem like they would work perfectly. And yet, I still get the phone calls.

One big challenge seems to be defining “total cost of ownership” for GRC technology. TCO is one of those business buzzwords you want to ignore, but unfortunately you can’t—in fact, compliance officers in particular probably need to do a more sophisticated TCO analysis than most. If you can’t discern what the costs to your organization for some GRC technology strategy truly are, you can’t determine whether the solution will work. Even worse, you can’t give a good answer when the board or CFO ask about return on the investment you want them to make.

The conventional definition of TCO is plain enough: the total cost of everything you need to make your solution work. For technology purchases, those costs can include physical computer equipment, software, implementation sprints, maintenance agreements, extra staff, new workflows, and the like. You also have opportunity costs: all the other tasks you wish you could be doing, instead of sitting through yet another meeting with software developers talking about system requirements or end-user testing.

All those costs can add up quickly for any project, but GRC projects have an additional level of pain because after implementation comes the endless drone of changing regulatory requirements—so whatever you install on Day 1, you’ll need to update soon enough.

We all know what comes next: someone preaching the wisdom of cloud-based GRC technology, or even outsourcing your compliance function altogether. And there is a lot of wisdom in that idea, which is why we have a lot of GRC software vendors running around.

Cloud-based GRC does ease a lot of your total cost of ownership pains. Many of those fixed investment costs (equipment and maintenance, for example) go away, in exchange for one fixed monthly or quarterly payment for using the cloud-based service. You still have some costs for the cloud-based vendor to custom-fit its technology to your existing IT systems, although you’ll also have no shortage of vendor sales engineers promising that implementation will be a breeze. Some of them might even be sincere when they say that.

Above all, however, you trade away your worries of keeping technology or data current (updating your list of OFAC specially designated nationals, say, or installing security patches); and if you start outsourcing staff operations, you can even trade away your need for skilled workers. The vendor provides it all, regardless of whether “all” is software code or brainpower.

What you’ve really done is this: reduced your personnel and technology risks (because your vendor takes care of them), in exchange for higher price and supplier risks (because now you’re relying on the vendor).

Put a Price on It

Well, all risks have a cost, if you want to avoid them happening. So even if you move to a cloud-based GRC vendor, and exchanged one set of risks for another—you still need to weigh the TCO of those new, cloud-based risks too. That can get tricky, and failing to assess your risks accurately will lead to you misjudging the total cost of ownership for that great cloud-based GRC software implementation you want.

For example, one of the most important documents you’ll sign in a cloud-based GRC arrangement is the service-level agreement: the outline of what level of performance your vendor promises to deliver. Aside from all the services your vendor is promising to you, however—what cannot fail on your end if your cloud-based GRC is going to work? That’s a question too many CCOs overlook, or don’t answer thoroughly. But it all feeds into your TCO.

A few answers to that question are: data feeds you send to the vendor; Internet access for compliance and audit staff using the program; security protocols; training. You also need to consider insurance coverage, should your vendor go out of business, or suffer a cyber breach, or fail in some other way. All of those concerns have a cost attached to them somehow, and you need to calculate it as part of your TCO.

In coming weeks I’ll take more looks at GRC technology projects, and how to make them succeed when so many seem to miss the mark. For now, calculating the TCO for your project is a good start—because as hard as the chore may be before an implementation, just try it after an implementation, with an unhappy board breathing down your neck.