Serg Nvns - Fotolia

Manage Learn to apply best practices and optimize your operations.

Vendor relationship management: Breaking up is hard to do

Ending a security vendor relationship is a tricky process and should be handled with care. Expert Mike O. Villegas discusses how and when to end vendor contracts safely.

All vendor contracts should have a termination clause, with or without cause. But if an enterprise decides to terminate a contract or not renew it, there are some factors to consider before transitioning to a new setup. These are important if it is a security vendor or managed security service provider (MSSP), and especially if the product is well-embedded in the enterprise's critical infrastructure.

When to hit the brakes

There are three reasons to terminate a vendor relationship or change the vendor product or service: product or service limitations, quality of service and cost structure.

Product or service limitations: When you first purchase a product or service, you expect it to meet your expectations. However, what if, over time, you find that it does not provide the level of protection or monitoring that you expected, but the investment put into making it work is substantial? No one likes to admit they made a mistake, but to continue using a product or service that doesn't meet the company's needs is futile. Terminate the use of the product or service and do what is right for the enterprise.

Quality of service: Vendor contracts should include service-level agreements (SLA). SLAs commonly include a definition of services, performance measurement, problem management, customer duties, warranties, disaster recovery and termination of agreement. If the vendor is not meeting the SLA requirements, you have recourse to terminate the agreement. One factor that may not be in the SLA, but should be, is the vendor relationship. If customer service or support acts curt or bothered when it responds to your query, it weighs heavy on customer satisfaction.

Cost structure: When you purchase a package or service, you need to perform a total cost of ownership (TCO) study. Sometimes enterprises perform a proof-of-concept (POC) and negotiate a purchase or lease agreement, but a TCO is essential to determine if there are other costs that were not factored into the decision. The formula for TCO includes a junction of total cost of technology (TCT), total cost of risk (TCR) and total cost of maintenance (TCM).

Typically TCT is considered during the purchase or lease decision-making process, but the cost of the technology should not be the only factor. Enterprises should also factor in TCR, which is the estimated cost to not deploy resources, processes or technology surrounding compliance risk, security risk, legal risk and reputation risk. TCM -- the cost of maintaining the information security tools and services, including the cost of people, skills, training, flexibility, scalability and comprehensiveness of the system(s) deployed -- is important, too. Without taking TCM into account, over time, experience with the product or service will prove the actual cost to maintain it, but by that time it's possible the enterprise will have spent a regretfully large investment.

Transitioning to a new security vendor contract

When you decide to end a security vendor relationship and pursue a new one, first ensure the new vendor product or service is the right one. Follow the same steps as before: perform a POC, perform a TCO study, negotiate the cost, and decide on terms and conditions. In addition, make sure the new agreement includes assistance from the new vendor during the transition. It is not enough to know that the products work in the environment and will satisfy the enterprise's needs; you need to be sure the total cost of the acquisition will not outweigh the benefit.

There are four methods for transitioning into a new security vendor relationship:

Direct transition:  Remove the old system and flip the switch to the new one. The old system will no longer be available for use from that point on. However, the risk may be greater than anticipated if, once in production, it doesn't function properly. The resulting gaps may affect the level of protection or monitoring required.

Parallel transition: Run both systems at the same time for a predetermined amount of time. There is an element of redundancy and some financial burden, but the switch to the new system and deactivation of the old occurs when everyone is confident the new system is performing well.

Phased transition: This involves a gradual introduction of the new system, while at the same time replacing elements of the current system until the current system is completely replaced by the new system.

Pilot transition: This involves setting up the new system for a small group of users or devices, while the remaining majority still interacts with the current system. At some calculated period in time, the pilot system is fully installed and the current system is then deactivated.

Regardless of the transition methodology, the key is to ensure there are no adverse effects on the production environment, no loss of log data, reporting requirements are met, and most importantly, the level of protection needed is still in effect.

Re-evaluating your vendor relationships

Transitioning from an old vendor system requires planning with the goal of minimal or no impact to the production environment and continued protection of critical assets.

The vendor also may have made an investment in you and your enterprise. They might have offered a significant discount in the current system to get your business, but don't let that interfere with doing what is right for your enterprise at the risk of marring vendor relations.

Next Steps

Weigh the pros and cons of managed security service providers for your enterprise

Learn how to start the vendor management process and how to manage vendor access to industrial control systems security

This was last published in December 2015

Dig Deeper on Security vendor mergers and acquisitions