Quite often, I encounter prospective software buyers who ask the question, “Is this product pick-your-regulation compliant?” But this really isn’t a valid question because the pick-your-regulation of interest is almost always a process compliance regulation that relates to how they conduct their business, not how a tool used in that process works.

“Almost always,” I typically concede. I do so because there are some compliance regulations that relate to how computer software is built. So in those scenarios, the software may or may not have been manufactured in compliance with such regulations, and determining that compliance state when making a purchasing decision is a valid inquiry. But the reality is this is rarely the true nature of the question being asked.

More often, what is really meant is: “Will this software make my business pick-your-regulation compliant?” And the answer to this question is unequivocally, “No, it won’t.” The only thing that will make a business compliant is defining, implementing, monitoring, and auditing business processes that are defined in those regulations.

However, selecting the right software and implementing it properly can certainly help you in defining, implementing, monitoring or auditing those business processes so your business can be compliant. There are several classes of software you should be aware of and consider implementing:

• Configuration Management: Configuration management software helps you standardize device configurations of switches, routers and firewalls to ensure they’re configured in a manner that will enforce compliance requirements, and in some cases can be used to evaluate what-if scenarios to help identify compliance failures before they are implemented.
• Event and Information Management: Event and information management software tracks events as they occur, and uses intelligent analysis to identify events that are inconsistent with compliant behaviors, quite often providing alerts of aberrant behaviors before they result in a compliance violation.
• Patch Management: Part of what makes your organization compliant is maintaining operating systems and application software in a timely manner and closing known vulnerabilities before they can be exploited. Patch management software is specifically designed to ease this process.

Nevertheless, merely implementing such software is not a fast road to compliance. Let’s look at a few everyday examples that you should keep in mind as you implement software to support compliant processes.

• Health Insurance Portability and Accountability Act (HIPAA): Perhaps the most significant provision of HIPAA is the protection of patient health information. For health service providers using primitive methodologies, this means not leaving patient charts laying around and not discussing patient care issues in the reception area, among many other practices.
  
  Many health service providers have attempted to address the former issue by implementing electronic medical records (EMR) software. But merely having EMR software isn’t going to prevent a HIPAA violation. You must configure the software and use the software in a manner that prevents unauthorized disclosure. Giving all users administrative rights or displaying patient information on a 72-inch monitor hanging on the wall fed by that software are sure fire ways to be non-compliant; having reception-area computer monitors in full view of patients and other persons in the reception area completely defeats the point of having the EMR software.

• Payment Card Industry Data Security Standard (PCI DSS): Is there anybody who doesn’t know the Target data breach story at this point? And there’s another half-dozen similar exposures that have occurred simultaneously. The restaurant chain P.F. Chang switched to paper-based credit card transactions because they no longer trusted their electronic system (as if paper with ink-imprinted credit cards is going to be any more secure).
  PCI DSS purports to establish standards by which credit card transaction information is stored and used by merchants. The PCI DSS standard is pretty specific in its requirements for managing and securing credit card transaction data, but nothing in the standard specifies, endorses or precludes any particular vendor’s computer software product.
• Sarbanes-Oxley Act (SOX): Perhaps the original of the contemporary compliance regulations, SOX was born out of some pretty ugly things that were happening at Enron, WorldCom, Tyco and a few others. This regulation is probably the least often associated with any particular computer software product, possibly because most corporations have had electronic financial records since the creation of the mainframe in the 1960s. In fact, it was the very existence of electronic systems that so easily facilitated what happened at Enron.
  
  What SOX is designed to do is to preclude certain practices that can lead to fraudulent activity, or even be fraudulent. My personal favorite example is a CFO who asks the IT director to execute a database UPDATE statement on the opening balances table of the corporate finance software because it’s not correct. Complicating the matter, of course, is that the IT director reports directly to the CFO. This particular company was not subject to SOX regulations because it was privately held by a foreign corporation, but the example rings true. It doesn’t matter what the software does or what the software can prevent or restrict if the software can be bypassed or used inappropriately.

So, software itself is typically not “compliant” — unless there’s a specific regulation that requires the software to provide a function or perform a task in a specific manner — and it can’t automatically make your business compliant, but it can help you be compliant. The real questions you need to ask when evaluating a software product to be used in a process subject to compliance regulations are these:

• Are the processes in our business compliant with the regulations?
• What is the expected response in our organization when non-compliant activities occur?
• What is the expected response if somebody attempts to circumvent the processes put in place to ensure compliance?
• How will the software be implemented to ensure existing compliance states are not violated?