Regulatory Reality

Feb 23 2010   4:17AM GMT

Rethinking compliance software

David Schneier David Schneier Profile: David Schneier

Here’s me about to eat crow.

After nearly a decade of railing against software as a solution to address the challenges of regulatory/industry compliance, I’m being forced to reconsider my position.

I’ve long advocated that an institution or organization could just as easily develop manual policies and procedures that would pass examiner/auditor scrutiny without having to spend additional money on a related software-based solution.  I’d encountered too many instances where an application was purchased to automate the related steps and it either fell short, was too complicated or was really designed to do something else and was poorly retrofitted just so the vendor could pursue a new market.

But my experiences this past year have revealed another side to this story that I hadn’t really considered.  In the spirit of full disclosure, I need to share with you that my company has developed a regulatory compliance solution and I’ve been heavily involved in its design and development.  Because of this experience and because of the myriad conversations and meetings I’ve participated in, I have a new found perspective on all of this.

First and foremost, it turns out that the foundation of my bias was formed on solid logic.  Many of the solutions that started popping up nearly a decade ago were born from desperation as an endless number of vendors watched their Y2K-centric solutions pushed to the edge of extinction as the new millennium came and went.  Many of these products morphed into network utility-ish software, some reinvented themselves and created a new market (e.g. portfolio management) and many others unfortunately died from the effects of irrelevance.  But some languished on the sidelines, barely existing and surviving on small crumbs of opportunity.

Then along came SOX and PCI and suddenly there were new revenue stream opportunities.  Vendors rushed to reinvent their products by re-branding, adding some cosmetic enhancements and the full force of a marketing campaign.  As I encountered many of these solutions out in the field, I formed a bias because so many of these “solutions” weren’t really solving anything, at least not the way they promised they would.  After developing less expensive and more effective manual compliance programs, I decided that was the better way to go.

But I sort of threw out the baby with the bath water.  What I didn’t consider were solutions that were designed by people who understood the purpose of the exercise and knew where and when to automate.  I hadn’t encountered very many, if any at all, that I felt were tightly aligned with the work that really needed to be done.  Those that I did like were often bloated, complicated and required a more advanced skill set than most of my clients possessed (e.g. disaster recovery).  At some point, I stopped even paying much attention to the details and more or less put all of them into a single category.

This past year, though, has served as a slap upside the head.  It turns out that there are some fantastic compliance-centric software solutions kicking around addressing a wide range of challenges that my clients are confronted with.  In hearing from the banking community what they liked, what they didn’t like and more importantly, what they needed versus what they didn’t, they shared real-world examples based on existing products.  It seems that some of the solutions I’d shunned since hanging my shingle in the banking sector years ago were making a difference for the better.

It didn’t take long to figure out what separated these vendors from the rest of the pack though.  Most of them were run by people who understood the underlying business drivers that created the market.  They also understood the behaviors of the user community and how they’d use the software.  Perhaps the most notable trait was that they were almost laser-like in what requirements they addressed and how that fit into an institution’s overall framework.  They were designed to address specific needs and solve specific problems.  They didn’t just solve part of a problem, they solved the entire problem, all of it with one well-designed solution.

Before recommending that anyone run out and purchase a “silver-bullet” solution to appease their examiners, I offer the following advice:

  • Know what you need a product to accomplish in order to meet regulatory demands.
  • Qualify a solution based on real results from recent customer experiences; did the software live up to expectations?
  • Test the vendor’s knowledge of the related regulation and gauge the depth of their expertise in complying with same.
  • Find out what the examiners thought of the solution.  While they won’t endorse a product/solution they are quick to let an institution know when they like something.
  • Be realistic in terms of how much effort is required to get a product installed and running right.  Even the best software needs to be populated with data and that takes time.
As for the possibility that this post may be perceived as self-serving, I would share with you that when conducting audits and assessments, I still advocate using manual programs to address gaps and deficiencies. Oh and another thing, don’t get used to my admitting I may be wrong; it’s a very rare event indeed.

 Comment on this Post

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: