Compliance Software: To Buy or Not to Buy (Part 2)

Pros, cons, costs and keys to success

Note: This is the second post in a two-part series on the decision-making strategy around building and buying compliance software—including guidance on how to effectively frame, analyze and socialize the decision within your own organization. To read Part 1, click here.

On the heels of our recent webinar, Compliance Technology: To Buy or Not to Buy, our last blog post laid the initial framework for companies debating whether to purchase or build compliance software. Having already covered the importance of setting project requirements, along with some of the fundamental ways to easily distinguish when it’s best to build versus buy a solution (or vice versa), we’ll jump right into some of the key things to consider before deciding to build or buy compliance technology, including the pros, cons and costs.



You theoretically can get exactly what you want, but you may not really understand what you fully want or need.
—Michael Rasmussen
GRC 20/20

    In short, the major advantage of building a proprietary system is that you can build it entirely to spec. You can meet your unique requirements for security, APIs and functionality, only paying for what you absolutely want. It also allows you to drive innovation where you feel service providers may be falling short and maintain total control and ownership over the system.
    Conversely, having total control and ownership over the system might not be something you have time or want ultimate accountability for. It also requires significant time and resources in order to build, test, maintain and enhance the product on an ongoing basis.
    This brings us to prioritization (or lack thereof). For most organizations, development will be done by borrowed resources from IT or external engineers. This means that your project may be continually pushed or delayed for more critical, customer-facing or profitable work. Any changes or oversights in the requirements can result in lengthy and costly delays. As a result, internal builds typically have much longer ramp-up times than purchased software.
    With long ramp-up comes long commitment; internal builds are hard to move off once you’ve invested in them. We typically hear from companies who are “stuck” with their proprietary system for a few years before they can justify replacing it again. This can be especially difficult for teams or businesses that undergo a change that shifts what’s fundamentally needed in the software—quickly making a proprietary solution obsolete.

    “You theoretically can get exactly what you want, but you may not really understand what you fully want or need,” said Michael Rasmussen from GRC 20/20 Research. “Your approach might be somewhat limited in understanding what the capabilities are out there, or what your process should look like.”
    As your team turns over, you may lose your product specialists. New hires are more likely to be familiar with off-the-shelf functionality (or something close to it) than your in-house solution.
    It also can be harder to envision and build for the “big picture” when you’re doing it on your own, missing opportunities for system integration and data centralization. “A lot of times when people build something, they’re very focused on something like policy management,” said Rasmussen. “But they’re not thinking about, ‘How can this really integrate with investigations? When I have investigation, I want to find which policies were violated, which might mean policy language should change or become more clear, or be reinforced with training.’ People really don’t think through that integrated information architecture, because when they go to build, they’re building for a very specific piece of it, and not the bigger picture.”
    All of this can significantly bring down the return on investment you’ll realize with an internal solution. Sure, the upfront, direct costs may appear lower than your proposals from compliance software vendors, but over the long term internal builds are usually more expensive and risky.



You get the wealth of experience from a variety of customers, not just your concept of how the solution should work.
—Michael Rasmussen
GRC 20/20

    One of the major challenges of buying an off-the-shelf solution can be unfulfilled requirements or unused features. Indeed, most software solutions (especially SaaS or cloud-based software) is built to address a majority of the needs of a majority of the market. There will always be examples of requirements or use cases that aren’t met or extraneous features you’re paying for but don’t use.

    “Just because you’re buying a product, doesn’t necessarily mean that it’s not built to spec,” cautions Autumn Sanelli, Solutions Consultant for Convercent. “You can still buy a highly configurable or customizable product. There may be incremental costs associated with the higher levels of customization, but you can still get a bulk of that product to work for you, and meet your specific needs.”
    And while it’s typically easier to migrate away from a software vendor than it is an internal build, it’s advisable to exercise due diligence and caution when selecting your vendors (more on that later) to avoid “vendor lock-in,” which can saddle you with a multi-year contract with subpar customer or end of life support. This can be especially true and troublesome for companies that outgrow their vendors who don’t invest in, enhance and innovate their product to keep pace with evolving customer requirements and needs.
    On the whole, you can usually get up and running faster by purchasing a solution than by building one from the ground up—which can be critical if you have a pressing need or the project is highly visible within your executive team or board. This time to value can also extend to configuration changes and expanding the scale of the product—all significantly easier and faster for vendors who routinely help customers adjust the size and scale of their implementation.
    Consider the future of your team, program and organization. When you buy a solution, the vendor takes on the work and onus of advancing the product; isolating and correcting of product issues; and supporting the migration, training around and deployment of enhancements. You’ll also be able to benefit from the features and functions that are included in product enhancements being driven by the market or other customer requests. The availability of technical support and service shouldn’t be overlooked, either, as this can get de-prioritized internally and create huge obstacles, time drains and headaches for your team if you try to build internally.

    “A lot of compliance solutions have best practices built into their solutions,” said Rasmussen. “You can get the wealth of experience from a variety of their customers, not just your concept of how the solution should work and look like. On top of that, there’s some more advanced functionality in some areas of integration of different types of content, or systems, that can be quite difficult, time consuming or even impossible to implement and integrate yourself.”
    It’s also more likely that these products will be built to be more configurable and agile in order to meet ranging customer needs—thereby allowing you to adapt to changes in your business or program.



Whether you’re going through the building or buying process, or weighing the costs of both options, nothing is going to be so straightforward as comparing apples to apples. It’s important, then, that you try to identify the total cost of ownership (TCO) for all viable options.


The cost of building may be less straightforward—and appear to cost less—because of time you’re using from internal resources. To estimate the cost of building a proprietary compliance solution, calculate the time these activities will take and multiply by the average hourly cost for the resources that will be performing the work. It’s also important to consider opportunity costs: building internally requires trade-offs, so it’s important to acknowledge what work internal resources will not be doing while they build the system. To accurately forecast TCO for building a system, be sure to take into account:

  • Software development resources
  • Software quality assurance (QA) and testing
  • Software configuration and deployment
  • Technology assets (e.g., servers/storage, apps, etc.)
  • End user training (onboarding and beyond)
  • Ongoing maintenance
  • Enhancements
  • End of life


If and when you settle on purchasing compliance software, vendors will present a variety of options and pricing structures. Bear in mind that these structures aren’t accidental—they’re priced according to each vendor’s strengths. Hidden or incremental fees based on number of administrators, volume of usage, training or configuration changes, for example, can quickly add up and leave you with a significantly larger invoice than you’d anticipated. Ask questions about items you don’t see on pricing proposals; it may help you avoid hidden fees for work the vendors consider “out of scope”—and you consider out of budget. The TCO of buying a solution should include:

  • Software licensing (number of administrators vs. flat fee, perpetual vs. subscription models)
  • Software implementation
  • Software integration
  • Customization/configuration
  • Volume/storage
  • Translation/localization
  • End user training
  • Ongoing maintenance and support
  • End of life

“Pay a lot of attention to the licensing,” advises Sanelli. “In order to get true use of the technology, you may need to have a significant number of administrative users. In that case, you’re going to want to look for a technology with a flat rate annual subscription, versus one that’s going to charge you licensing out per fee.”

It’s also important to understand the access you’ll have to product enhancements, and how frequently you might expect those enhancements to be made. “You’re usually purchasing software at a particular stage in the development process,” said Sanelli. “As that product evolves, will you get those upgrades and features for free? Or will you have to pay an upgrade fee?”

Once you calculate your TCO to buy compliance software, get validation from vendors’ customer references. “Ask them how many bills they get throughout the year,” advises Sanelli. “You may get that one annual proposal price, but then ask what’s tacked on as you start using the system. What about upgrades?”

Rasmussen also highlighted ease of use as a cost consideration. “Is this something that’s intuitive and easy to use? I’ve sat in front of some solutions and gotten a headache because I can’t figure out how it functions. That can be something to be aware of, particularly for those [solutions] that you have to build out a lot on your own. How long is it going to take to roll out and implement? That impacts total cost of ownership on the buy side.”



  1. Don’t overlook your employees. Get feedback from your end users in the decision-making process, including how easy it is for them to navigate through and use the system. If it’s hard for them to find or use it, they’re unlikely to do either.
  2. Get a demo. It’ll help you assess what’s currently available versus what’s “on the roadmap.” You also might think of additional use cases for the system and ways to improve the value it offers.
  3. Check references. Make sure you get feedback not just from executives, but the system’s day-to-day users. They might have a different perspective.
  4. Don’t overlook IT. Involve them early and often if they’ll ultimately have to vet and approve a software purchase. You can also leverage your vendor’s experience (if you’re buying) to help you address questions about systems already in place, security requirements, etc.


Compliance teams often have more than one way to deliver and manage their compliance program initiatives—and they can usually figure out a way to “make it work,” regardless of whether they choose to build, buy or improvise a solution. But in order to achieve maximum effectiveness and efficiency, and best align to your current organizational structures and requirements, it’s best to carefully investigate and consider your unique requirements against the availability, complexity and cost of solutions currently available on the market.

You can view the full recording of our recent webinar on this topic, including the presentation slides, here.