EXPERT ADVICE

Future-Proofing Vendor Management in the IT Shop

“Do you remember where you were on Y2k?”

Ask that of most IT professionals and you’re almost sure to get a conversation started. While the non-IT crowd was off partying like it’s 1999, many of us spent the new year in the office, on call or tied to our pager. Even those of us who weren’t directly involved in the actual change-over probably still remember the grueling months (or years) of effort that went into making sure everything was ready for the big day.

I bring up Y2k not because it’s a “success story” for IT (far from it), but because it’s a great illustration of the value of future-proofing.

Specifically, we all know that the costs of Y2k were enormous. However, how much of that expense would have been prevented if the developers who wrote the problematic code knew back then what we know now? If our firms had given the developers a mandate, a budget, and the time to develop code for 20 years ahead, what would have been the overall benefit to the firm in terms of cost savings? Probably a lot, right?

Beyond the Tactical

The unfortunate reality of IT is that most of the time, circumstances keep us thinking tactically. After all, if we barely have the resources to put out today’ fires, how can we possibly expect to foresee and capitalize on what might pay off years down the road?

Every once in a while, though, we do get a rare opportunity to step beyond the tactical and make a decision that not only pays off today but continues to pay off for years ahead. Seeing those opportunities and capitalizing on them is what, in my opinion, separates the great IT shops from the rest of the pack.

I think those opportunities are very infrequent, but we’re absolutely at one now when it comes to vendor governance.

Vendors, Vendors and More Vendors

Most of our firms are struggling daily with the challenge of managing vendors. Almost every firm lives or dies by a fantastically complex web of relationships with partners, outsourcers, vendors, service providers, consultants and numerous others.

In other words, all of these third parties — potentially hundreds or thousands of firms — have a role to play in the effective operation of our businesses. However, keeping track of them all and making sure they “toe the line” when it comes to safeguarding our data can be an absolute nightmare.

For most large organizations and many small or mid-size ones, it can incredibly difficult to even get an understanding of the basics. For example, trying to understand how many vendors there are, what services they provide, how they fit in to the overall business, and who are the stakeholders overseeing the relationship can be an extremely difficult question to answer.

Complexity Is the Enemy

Dig a little deeper and you start getting into the really sticky issues — how these vendors store your data, how they transport it from place to place, how they manage their facilities, how they grant and revoke access to data, etc. — not to mention the fact that each of these vendors will, in turn, have their own third parties that they do business with.

Now add to this incredibly complex scenario a sea of regulation like HIPAA, SOX, the PCI DSS, FISMA, etc. All of these have something to say about how you should oversee and manage these vendors: how you should communicate with them, how you should monitor them to ensure compliance, what sorts of agreements you should have with them, and even what training you should provide. You’ll find that the equation gets very complicated very fast.

Let’s face it — complexity, particularly when it comes to your competitive advantage (i.e., your data), is the enemy.

The Business Need Is Just the First Step

If your organization is like most, you’ve probably invested heavily in consolidating how it tracks, evaluates and governs third parties. You may have created a review process for evaluation of their information security, their facilities, their processes and procedures.

However, this is just the first step. To go back to the analogy of Y2k, setting up the review process is sort of like the initial exercise of writing the software: sure, it meets the business need, but does it do in a way that would be just as useful years down the line?

Many organizations fall into the trap of developing their vendor review process to address the current business and regulatory environment, but without thinking of how that vendor review process might be used two, three, four or more years from now.

For example, if you review a vendor today, do you have a timetable for when that vendor would need to be reviewed again? How about if the nature of the contract changes and they start supporting you from a different facility? Is there a process in place for the business to pull you in should the nature of the contract change? What about incident response and e-discovery? Have you structured it so that you are informed in the event that there is an incident at the vendor that impacts your data, and have you set up a process that enables you to contact a representative at the vendor should you need to retain transaction logs for litigation purposes?

Don’t Get Boxed In

If you haven’t thought through exactly how these issues will play out, you can save yourself a lot of hassle by doing so now rather than waiting. It saves you the hassle of having to modify the process down the road, and when you change the process you invalidate any metrics that you may have collected prior to the change. In other words, if part of your goal is to track a vendor’s progress over time (and why shouldn’t that be part of how you use these results?), you lose valuable data if you change the process in mid-stream.

Also, be cognizant of the fact that changing a process while it’s still in its infancy is much easier than changing one that’s been around for a while. For example, quite a bit of the Y2k problem was caused because of the sheer volume of software that needed to be validated, checked and updated. If you do already have a vendor review process in place that perhaps it doesn’t meet all your requirements, changing it now (when only a small fraction of the vendors have been through it) is going to be orders of magnitude easier than changing it once you have a history of using it for years.


Ed Moyle is currently a manager withCTG’s information security solutions practice, providing strategy, consulting and solutions to clients worldwide, as well as a founding partner ofSecurity Curve. His extensive background in computer security includes experience in forensics, application penetration testing, information security audit and secure solutions development.


Leave a Comment

Please sign in to post or reply to a comment. New users create a free account.

LinuxInsider Channels