Vendor Management

Rethinking compliance software

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.

Was 2009 the year regulatory compliance became a good thing?

When I sat down to write my last blog post for 2009, I was planning to write either about my predictions for 2010 or a retrospective of 2009. But that’s just so clichéd; everyone does that or tries to. And as I’d wrote in a recent post about the Verizon report on security threats, sometimes there’s not a whole lot that changes year-over-year and so my bold predictions for 2010 would likely look almost exactly like those I made for 2009.

Instead what’s on my mind isn’t so much a revelation or prediction but rather an observation.

When I first started focusing on the banking vertical a few years back, I was often depressed by how so many institutions did what they did because they had to and not because they viewed any inherent value in the exercise. Information security policies were dust collecting binders, business continuity plans (BCP) were a collection of basic documents that described what needed to be done but rarely provided direction on how to do it, and vendor management was typically just a spreadsheet with a some key data elements. Rarely did any of these artifacts provide real value or come anywhere near close enough to address the spirit of the regulations that required them to exist.

That’s definitely changing.

I’m currently working on two projects that deal directly with business continuity planning. For the first project, I’m rewriting a clients plan and taking it from the aforementioned collection of basic documents and remodeling it into an actionable plan that will allow them to use it as a road map to steer them through various types of business disruptions (they’re not all disasters, sometimes it’s just a power outage or a burst water pipe). They knew they needed to make changes to their existing plan and management saw the inherent value in having something that would actually drive the decision-making process when necessary and increase their chances of successfully navigating through a crisis. The second project is actually an IT general controls audit in which the project sponsor has requested increased scrutiny be placed on BCP related activities. They wanted to make sure that their plan was well designed and properly tested and would at least meet, if not exceed regulatory requirements. The amount of work their management team poured into the plan and its related activities was clearly reflected in the evidence I reviewed. They not only have a viable plan but have tested it from several entry points, have identified potential glitches and fixed them so that should they need to implement the plan, they have a high degree of confidence that it will work. Both of these projects underscore something that’s significant: financial institutions are embracing the value of complying with the regulations. Having a formal BCP is not just a way to make the examiners happy; it’s the best way to successfully manage the unexpected.

And this more than subtle shift has been noted in other key regulatory areas.

Vendor management has moved from a clerical exercise into something that’s more day-to-day, where contracts are being scrutinized and performance measured. We have an ever-growing client list on that front where they aren’t concerned about the regulators so much as making sure that they’re protecting themselves and their customers/members from unnecessary risks and exposure. We’re seeing it with Red Flags – Identity Theft and Incident Response plans where the banks and credit unions want to leverage the “have to” and convert it into something that helps them manage risk better. Regarding Red Flags, we’ve found that most institutions have their plans up and running but haven’t implemented it properly and are using it more as a Suspicious Activity Reporting (SAR) mechanism rather than the its intended use. But when we bring that up in our reports, the response has been refreshingly positive where management wants to get it right. That’s what’s different from previous years.

I’ve long advocated for doing it right as long as you have to do it and now it appears that management is coming around to embracing that idea.  Perhaps that’s what 2009 will reveal itself to be in the rear-view mirror: The year when our industry matured from “have to” to “want to” when addressing information security. A year when it wasn’t about having a board-approved document but rather a viable plan or program. Now, that would have to be considered a good year.

Happy New Year. May it be a good one filled with an improved economy, fewer breaches and an increase in management oversight.

Information security officers are a must

I was talking with a client last week about a perceived gap in their organization.  Despite having to address multiple regulations cutting across several oversight bodies, they were lacking a single point of contact or central coordinator for all information security related activities.  Their sense was that they were long overdue for some form of a chief information security officer (CISO) and I had to agree.

The same point was underscored earlier this week during a kick-off meeting with a client regarding a pending audit.  Almost all of the requests for information, including policy and procedure documentation were redirected to their most senior IT person.  As we were wending our way through the items on the list and they kept verbally pointing to the IT person, I started wondering how he could be responsible for all of these information security related items and perform his regular IT duties.  The answer of course is that he can’t, not effectively anyway.

There’s a discipline involved with regards to regulatory and industry compliance that requires someone be committed to both understanding what needs to be done and then making sure that it’s happening.  This isn’t a new consideration; I’ve blogged in the past how we’ve moved from an age where you simply needed documentation to one where actionable steps are required.  It’s not enough to have an information security policy in place, you also need to comply with it and then be able to prove that fact upon request.  You can’t talk about how you restrict access to systems and information and not be able to provide a recent access review/report.

I’m routinely amazed by how few of my clients understand the growing need for the role of a CISO despite their awareness and sensitivity to the increasing regulatory burden.  Many financial institutions will offer up that they have a BSA officer and some will introduce a compliance “person” who is almost always focused on AML/Patriot Act activities and not much else.  I’ve interviewed several dozen people over the years who were included in the audit or assessment process because I asked to speak to their head compliance person and it turned out that they had very little if anything at all to do with information security and GLBA-related activities.  How is that possible?

How can you expect someone who is an expert in technology to to also be an expert in information security and GLBA?

The answer is obvious, you can’t.  First, there’s a very real conflict of interest in asking the person who owns many of the required controls to also monitor themselves.  Second, I’ve yet to meet a technology person in all but the largest institutions who didn’t end the day with more to do than when they started it.  Third, it’s very unlikely that a technologist will interpret and apply the myriad rules around information security for all in-scope regulations and apply them correctly.  I’ve been doing this sort of work for more than a decade and it’s a full-time job just keeping up with the changes let alone figuring out how to properly comply.

There needs to be an assigned gatekeeper for information security, plain and simple.  And the size of your institution doesn’t matter.  I’ve worked with very small financial institutions (under $100m in assets) that had a single, non-IT person in charge and it worked out quite well.  In one case the individual was also responsible for business continuity and vendor management, which oddly enough isn’t so odd.  Both of those require a certain degree of expertise that exceeds what you’d expect a technology person to have and more importantly, both of those activities need to cover the entire organization, not just what runs on the network.   When I worked within the technology infrastructure, I never understood why these things always got dumped there and now that I’m on the other side of things I know that it doesn’t make sense.

When the examiners or auditors ask to speak to your CISO, ISO, head security person, compliance officer or compliance manager, you need to have a name to give them not some vague answer or explanation about how it’s done piecemeal.  This is 2009 and the demands of compliance are great and they’re real.  Ignoring the obvious or incorrectly assuming that this is a part-time job is no longer acceptable.

What vendor management is really all about

I received an email from a colleague last week in regards to my recent post about the BITS Shared Assessments Program.  In the entry I offered my high opinion of the framework but went out of my way to point out that by itself the assessment is not a vendor management program.  The subject line for the email was “Why not?”.

Semantics aside, there’s an important distinction between assessing and managing.  Assessing how a vendor conducts business within their own infrastructure is not the same as monitoring contractual obligations and service-level agreements that govern your relationship with that vendor.  That the vendor has an information security program is a good thing, that the vendors information security program supports what regulations require you to do is a better thing.

The Shared Assessments Program does a great job of providing a consistent set of measurements by which every vendor can be assessed.  But it does not offer a determination as to whether or not what the vendor does is sufficient for your own needs or purposes.  It’s still incumbent upon your institution to form that opinion and act accordingly.  And even so, that’s still just one piece of the vendor management puzzle.

FFIEC guidance breaks out vendor management into several separate and distinct parts with the assessment piece only being one element of the ongoing monitoring phase.  Assuming you’ve conducted the necessary and expected steps to enter into a contract with a vendor you still need to review their performance against specific contractual obligations and measure them against the various elements of the service level agreement.  And this needs to occur annually with a determination formed as to whether or not the contract is being adhered to and if not, what remedial steps are required to continue forward with the vendor.  The Shared Assessments Program doesn’t do that for you.

One of my reasons for beating this drum is because of the popular misconceptions circulating out in the market place as to what’s needed to address vendor management.  There are people I’ve worked with who offer themselves as industry experts pushing the Shared Assessments approach on even the smallest financial institutions trying to convince them that they need to have one completed for all of their high risk vendors in order to appease the examiners.  This is simply not true and is really, in my opinion, just a ploy to try and generate revenue within an industry that’s hyper-sensitive to regulatory scrutiny.  Basically what’s required is that the vendor, where applicable, provides its customers with something akin to a SAS70 report in which they demonstrate that their infrastructure is properly secured and managed.   And that’s the point where I’m predicting that the Shared Assessments framework will become the standard, that it will replace SAS70’s and generic audit/assessment programs as the truest way to measure a technology service provider.  And again, this represents only a portion of the work required to address vendor management.  But rest assured, if all you have to show your examiner/regulator/auditor next time they ask to see your vendor management program is a few recently completed shared assessment reports you’re asking  for trouble.

Which leads to another reason for my beating this drum.  There are only a small percentage of vendors for whom the Shared Assessments Program even applies.  When reviewing my clients’ vendor management programs I’m often confronted with the “high risk vendor” logic in which some arbitrary algorithm is applied to determine which vendors are included and which are excluded from the program.  There’s almost no evidence of this assessment having been conducted and it never holds up under scrutiny.  But with regards to which vendor would/should be required to provide an external and independent assessment of their infrastructure I could easily make the case for limiting it to only “high risk vendors.”  As a matter of fact I can even offer a viable rule by which to make that determination.  Does the vendor process, store or transmit non-public, personal information (NPPI) within their infrastructure?  If the answer is “yes,” demand a SAS70 or equivalent.  Otherwise you’re free to decide your threshold for pain and make the rules accordingly.  But rest assured, if you have recently completed shared assessment reports for your high risk vendors  to show your examiner/regulator/auditor as part of your vendor management program the next time they ask, you’re in  for a lot less trouble.

Keep an eye on Shared Assessments.

About thirty seconds after I posted my last blog an item on the SearchFinancialSecurity.com homepage caught my eye.  It was an interview conducted by Marcia Savage with Michelle Edson and Charlie Miller from the Sante Fe Group about the Shared Assessment Program.

For those of you who aren’t already familiar with the Shared Assessment Program it’s a framework to assess third-party service providers that has been gaining in popularity over the past few years.  Created by BITS, “ a non-profit industry consortium whose members are 100 of the largest financial institutions in the United States”, it’s fast becoming synonymous with vendor management.  I’m hard pressed to recall a recent conversation with someone in the industry where, when the subject of vendor management was brought up, didn’t make reference to Shared Assessment somehow.

I’ve grown fond of saying that what CobIT became to SOX, the Shared Assessment Program  is becoming to vendor management.  Now, I’m an experienced hand with vendor management and some might even consider me an expert (though not for me to say about myself) and I’m hard-pressed to think of a better framework or approach to use when actually trying to determine what controls are in place and functioning at someone else’s company.  Conceptually it presents itself as a SAS 70 process but unlike a SAS 70 this has clear, concise and repeatable steps that remove any ambiguity from the process.  While it’s certainly true that the results are only as good as the people using it, the Shared Assessment approach at least serves as a relevant and comprehensive baseline.

I’m not going to offer a deep dive into the components of the program, feel free to check it out yourself.  What I will tell you is why you should be at least familiar with it and likely be using it for your own purposes.

First, it covers everything you’d want or need to within the virtual four walls of any company.  Take a look at what’s covered via the FFIEC guidance and related handbooks, take a look at any reasonable IT general controls audit program, read any SAS 70 report done for a technology service provider and map it back to the related Shared Assessment Program elements; it’s all in there.

Second, the language is clear and concise with almost no room for misinterpretation (I say “almost” only because I’ve learned never to underestimate or overestimate peoples ability to complicate the simple things).  Anyone can pick up the templates and start using them immediately with no direction or instruction.

Third, it’s great to use as a self-assessment guideline.  If you work for any organization in any business vertical and want to quickly get a snapshot of where your infrastructure is in terms of controls and their related activities open up the Standard Information Gathering questionnaire (SIG spreadsheet) and use the Lite version.  As a matter of fact, pass out copies to stakeholders in other areas of your infrastructure and ask them to fill it out and see what things look like from multiple perspectives.

Fourth, if you’re in an industry with strict regulatory oversight, particularly within the banking sector, this will help you standardize on not only what information you’ll need from your vendors but also what you want to be able to share with those external to your own organization.  When the examiners or external auditors show up to conduct their work and find that you’re using the Shared Assessment Program to measure and test yourselves it should engender confidence and reduce the amount of time necessary for them to conduct their own fieldwork.  That’s sort of what CobIT did during the early and insane days of SOX.  When the auditors showed up and discovered that you documented your controls so that they aligned with CobIT they tended to ease up a bit and place a greater dependency on management testing thus reducing time and (billable) expenses.  This is a similar opportunity and in this economy who can easily ignore the chance to potentially lower costs.

To be clear, Shared Assessments is not a vendor management program, it’s part of one.  You still have to conduct all of the other related activities involved (e.g. due diligence, contract compliance, etc.).  But for that all-important element where you need to obtain proof that the necessary controls are in place and functioning effectively at your third-party service providers (HEY BANKING COMMUNITY, PAY ATTENTION ‘CAUSE THIS IS IMPORTANT FOR GLBA) this is what you should require the vendor to be using.

Oh, and did I mention it’s free?