Posted by: David Schneier
assessment, Audit, compliance, FDIC, Federal Reserve Bank, FRB, GLBA, NCUA, OCC, OTC, regulations, regulatory, Regulatory Compliance, risk, risk assessment, vendor, Vendor Management, vendor risk, vendor risk rating
I don’t think I’m due to post about vendor management again at least until January 2012 (I try to limit topics to twice a year) but I’ve had something kicking around my head for a few days now and it needs a proper vetting.
Does anyone know why vendor management is such a big issue for banking regulators? I mean, I’ve long advocated that most of what GLBA covers makes sense and should be part of a healthy business strategy anyway. But when working with clients I’m often surprised to discover that they just see it as another something they have to do and don’t fully appreciate why that is. So does anyone know?
One of the basic tenets of GLBA, perhaps the MOST basic goal is to protect customers sensitive data. Sure you can make the argument that it has hooks into disaster recovery and business continuity planning, both also covered by regulatory requirements. And you can also claim it has to do with service level agreements and gauging the vendors performance. But really in the end the primary driver behind why your regulator wants you to do a better job of managing your vendors is to make sure they’re protecting your customers where applicable. Think about it, it’s so simple it’s almost too simple.
Which is why I’m always amazed how so many institutions fail to not only figure out what they need to do but also never really seem to get where they need to be. It so often becomes about the document collecting game; do they have a SAS 70? Do they have an Information Security Program? Who cares? That’s not what vendor management is intended to address. What you’re really supposed to do is step back and assess the nature of the relationship, the types of products and/or services the vendor provides and try and identify where threats to your customers sensitive information may exist. Vendor management is seldom a thinking exercise but rather an attempt to standardize on what artifacts are required in order to prove compliance with the program. It blows me away how this important activity gets boiled down to something little better than a baseball card collection.
I offer for example my favorite blind spot in every vendor management program I’ve ever conducted a first ti me review of. Where’s the information for the vendor who cleans the facilities? It’s almost always contracted out and the vendor who owns the contract is responsible for staffing the work. Where’s proof that they properly screen the people they’re sending into your allegedly secure facilities to make sure they’re not convicted felons? Where’s proof that they properly police their crews to make sure they’re not behaving in a reckless manner and perhaps letting their friends and family into your secured facilities to drop off dinner or stop by and say “hello”? When I challenge the clients on this relationship they look at me like I’m nuts. Almost all of them fail to even include that particular vendor (and those who do tend to include every single vendor they’ve ever done any business with – another big issue). But all you’ll ever need to do in order to see why this is a potentially huge threat is to walk around the office after hours and see what’s been left out on desks, in printer and fax queues and examine what sort of documentation has been tossed in with the regular trash.
And because vendor management is never truly approached from the right angle it fails to address the very spirit of the exercise and why the three senators who authored GLBA wanted you to pay more attention to it. But it really reveals a fundamentally bigger issue with most of the compliance domain – no one really approaches most of the work with a true risk oriented perspective. Compliance isn’t simply about creating checklists and ticking off all the to-do’s – it’s about really trying to identify relevant risks and make sure your institution has controls in place to manage them properly. And I know for those of you who read my blog with any regularity you’re thinking I’ve written about this before. That’s true, I bring this up every chance I get because it’s still a huge issue and those of us who have any practitioners attention need to constantly bang on this particular drum.
This is one of the reasons why whenever I’m given a chance to discuss how any of my clients approaches vendor management I try never to tell them what they need to do but rather try and instead have a conversation about what they think they should be doing. The back-and-forth often helps them expand on their thinking and come up with better, more effective ways in which they can properly categorize and assess their business relationships.
Oh and as for my “Who cares” comment about collecting documentation, there’s a place for that to be sure. But when you tell your examiner or auditor that you’re OK because the vendor provided a recent SAS 70 and can’t really discuss any of the details you’ve fallen way short of what you needed to do. Waving documentation in my face never convinces me you’ve done your job and it absolutely never proves that your customers sensitive information is protected. Remember, SAS 70′s (and now SSAE 16) are subjective and what each one covers can vary wildly from one to another. And it absolutely does not prove that they’ve successfully addressed all the items in your checklist either. One of my favorite cut-through-the-weeds tricks is to pick a single checklist item and ask the person waving the report to show me where that’s addressed in the report. I’ve met a few who could do it and prove to me they’ve actually read the thing but most just start flipping through pages like a poorly prepared student during an open book exam.
Why is this so hard for so many to do a reasonable job on?