The Importance of Vendor Risk Assessments

When buying a car, do you rush right out to the dealership and purchase the first car you find online? Or, do you perform your research and kick the tires, taking it for a test drive? Most of us will conduct our “due diligence” before buying a car and this includes researching the types of cars we’d like to buy, taking several test drives and checking out the mechanics of the car.  This same due diligence should be done for each of the vendors that you plan to use within your company in the form of a vendor risk assessment, regardless of their size. In fact, current vendors within your company should be reviewed every one to two years. For example, did someone review their financials? Do you know if you can get your data back if they go bankrupt? Do you know if they’re governed by laws outside of your country?

In larger companies, vendor risk assessments are typically performed by risk analysts, technology auditors, and information security folks, working in conjunction with the vendor management and procurement departments. In smaller companies, there may be a one or two person team responsible for conducting the vendor risk assessment. In many startup organizations, vendor risk assessments can be an afterthought. If you don’t perform a vendor risk assessment on your vendors today, take a look at this Risk Assessment Toolkit from the State of California’s Department of Technology, Information Security Office to get you started. There are many other sample templates and resources available online, as well. This is a great video on assessing technology vendor risk and security from Monte Ratzlaff, Security Manager, at UC Davis Health System, as he presents “Vendor Risks: Evaluating the Security of New Technology”.

At this point, some of you may think, “well, I don’t need a risk assessment on ____ vendor (insert name of vendor), they’re huge!”. Right? Wrong. I’ve worked with technology audit professionals on the review of hundreds (if not thousands) of technology vendors and yes, some of those “huge” vendors can have red flags for you and your company. Whether it’s the fact that they’re in the middle of a merger, they’re outsourcing their development team, or they don’t have enough insurance to cover you in the event of a breach, the scenarios can vary, depending upon what your company considers a risk and how that risk is categorized. If you need a tool to understand risks associated with the project you’re considering, take a look at this post by BrightHub PM, it has a lot of great info on creating a risk matrix and how to use it.

In the end, just think of a vendor risk assessment as a way to kick the tires of the prospective vendor before buying a lemon whose carburetor is going to explode once you drive it off the lot. If you’re interested in performing a proof of concept or proof of technology with the vendor once they pass the vendor risk assessment, check out a former post that I wrote on this topic and good luck!

Integration: Klingons vs. Elves

Integration is largely dismissed by those interested in purchasing software these days. Quotes like “don’t worry, we’ll make it happen” or “oh, it’ll all come together in the end” are heard in meetings as everyone rushes to sign the vendor’s contracts before the end of the fiscal year. Unfortunately, six months later the same people are saying “the vendors weren’t upfront in their demos with us!” and “I don’t understand what’s so difficult about all this, why can’t they just make it work!”.

If you’ve ever integrated different systems together, you know that integration is where the rubber meets the road so to speak. From a technical perspective, I’m not a fan of bolting two (or more) different systems onto each other and forcing them to talk to one another. However, many times it has to be done and if that’s the case, it needs to be planned accordingly. The best way I can explain an integration effort is this:

System 1, a.k.a. “Worf”: A Klingon who hails from the planet Kronos. Worf has been characterized as a “swarthy humanoid”, doesn’t like cold weather and enjoys a bloody battle. Speaks Klingon.

System 2 a.k.a. “Enel”: An Elf who hails from Valinor in Middle-earth. Wise and immortal, Enel is a skilled hunter and has pledged to preserve the world. Speaks Elvish.

Worf and Enel couldn’t be more different. In fact, they’re completely different in every way imaginable. So, how the heck do you make them talk to one another? Hire an interpreter (i.e. 3rd party software tool) to assist in the language barrier? What similarities does Worf have that Enel can understand (i.e. temporary tables)? What symbol of understanding can be passed between them (i.e. Web Services or APIs)?

To ensure that the Klingons don’t invade the Elven continent of Middle-earth and destroy an ancient civilization, it’s important that you get your Supreme Council in a room (i.e. project stakeholders) along with your Trusted Advisors (i.e. IT architects, etc.) and determine the best way (or ways) for Worf and Enel to communicate with one another before you join their people together as a nation. Otherwise, prepare for Worf’s battle cruiser to enter Middle-earth airspace and it won’t be pretty.

Are You Using “Test” Data in the Cloud?

CloudSecurityKeyhole_468Yes, you read that correctly. The word test is in quotation marks, as in “is it really test data that you have in the vendor’s cloud?”. Astonishingly enough, at least 85% of financial institutions are using live data in their test environments [1]. Could this be you and are you protecting your organization against a data breach effectively?

When a cloud technology vendor makes an offhand remark like, “yeah, we can create a test environment for you and load your test data into the cloud while we work through a Non-Disclosure or Proof of Concept agreement with your legal team”, be afraid. Be very afraid.

Now, I’m not knocking the technology vendors. In fact, to them this is a natural part of the engagement. What you have to be aware of is whether your company’s test data is truly “test data” or not. For example, if you’re in the financial or healthcare sectors where a data breach could expose Personal Health Information (PHI) or Personally Identifiable Information (PII), you should understand your test data thoroughly.

Once you understand your test data, think about putting together a more robust agreement with the vendor besides a Non-Disclosure or Proof of Concept agreement. Non-Disclosure and Proof of Concept agreements typically do not contain the language to protect your company against a data breach. A Master Services Agreement or Subscription Services Agreement should be reviewed by your legal or contracts team to determine if your company will be protected while using the vendor’s cloud if there is a breach with regard to the test data.

Karen Hsu of Informatica explains that “because data stored in a cloud-based ‘sandbox’ environment for testing purposes is vulnerable, it should be masked to protect sensitive information” [2]. She recommends using an automated masking tool to assist with the protection of your data. Regardless of what tools you use, your “test” data should be understood before loading any of it into a vendor’s cloud environment.

References:

[1] Dark Reading News. (2010, March). Live Data In Test Environments Is Alive And Well — And Dangerous. Retrieved from http://www.darkreading.com/risk/live-data-in-test-environments-is-alive-and-well—-and-dangerous/d/d-id/1133220?

[2] Hsu, Karen. (2013, March). Masking Test Data in the Cloud. Retrieved from http://www.bankinfosecurity.com/interviews/masking-test-data-in-cloud-i-1822

Preventing a Cloud Data Breach

Breach-WordsMany of you reading this have not (thankfully) experienced a cloud data breach with your technology vendors. However, a cloud data breach is always on the forefront as more businesses embrace cloud technology.

What are the chances that your organization could have a cloud data breach? According to research performed by the Ponemon Institute most companies will have small data breaches rather than large data breaches [1]. Does this mean you can breathe easy? Not so fast. For those of you in the retail and public sectors, your likelihood of experiencing a data breach is higher than those of you in the transportation, communications or even financial sectors [1]. However, each sector is impacted and the average cost of managing a data breach per organization is approximately $5.9 million with the average cost spent per breached record at $201 [1]. 41% of the respondents surveyed in the Ponemon Institute’s research said that malicious or criminal attacks were responsible for their data breach and 31% said that employee negligence was the root cause [1].

With those facts in mind, how do you prevent a cloud data breach?  The Ponemon Institute’s research states that “the most profitable investments companies can make seem to be an incident response plan, a strong security posture, the involvement of business continuity management and the appointment of a CISO with enterprise-wide responsibility” [1]. In addition to this, asking potential (and current) vendors about their cloud technology is also key. This is a nice article written by Julie Lopez that focuses on the right questions businesses should ask their technology vendors.  Her article mainly focuses on health care, but makes a lot of great points that everyone should read regarding vendor management. Speed to market is critical these days and cloud technology gives organizations this benefit. However, this speed to market mentality must be tempered with a sound risk mitigation strategy in order to reduce the chances of a costly data breach.

References

[1] Ponemon Institute. (2014, May). 2014 Cost of Data Breach Study: United States. Retrieved from http://essextec.com/sites/default/files/2014%20Cost%20of%20Data%20Breach%20Study.PDF

Unlimited Liability for Breach of Confidentiality in SaaS / Cloud Contracts

I recently opened up a contact form for readers if they had any questions about technology vendor management and I received this great question from a reader. It does step into the legal realm of contract management and since I’m not an attorney, please understand that my below response isn’t legal advice, it’s based on years of working with technology vendors and technology contracts.

Unlimited liability for breach of confidentiality: Is it practical to expect SaaS suppliers to accept that risk in this era of very public security breaches?  

It’s not unreasonable or impractical to include this type of language in your SaaS (Software as a Service) / Cloud contract. From my experience, including unlimited liability for breach of confidentiality in your vendor’s contract hinges on one thing: your data.  What type of data do you want to remain confidential?  Is there financial, corporate information, protected health information (PHI), or personally identifiable information (PII) being stored within the SaaS / Cloud product?  Where will the confidential data reside? Offshore, onshore, nearshore, offsite, onsite? If it’s a true cloud provider, your data will be sliced and diced on servers across the globe. Do you have the option of a private or hybrid cloud with this vendor? Will there be any vendor resources performing patch / breakfix / maintenance work to the product that will see this confidential data? If so, where are they located and what data would they see as they performed this work?

In addition to the initial research regarding the type of confidential data to be stored, it’s important to perform a complete risk assessment of the project and the vendor’s products in the beginning of the purchasing engagement (preferably in the sourcing phase, not the contracting phase). My most recent post digs more into vendor vetting and it includes a great video from Monte Ratzlaff, Security Manager, at the UC Davis Health System, who elaborates on the issue of vendor risk.

From a contractual standpoint, vendors typically take issue with unlimited liability of any kind. That’s not to say that you can’t add the unlimited liability for breach of confidentiality language in your contract for the first draft and see what the vendor comes back with as far as redlines. Vendor pushback on unlimited liability is to be expected and I would recommend finding a back fence position if they don’t accept it. This back fence position could be anything from including a monetary cap in the contract (i.e. the vendor will pay $1 million related to the breach and then you’re responsible for any fees over the cap) to other remedies that would effectively make your company whole in the case of a breach. If you’re in an industry such as finance or healthcare, a public breach of confidential information could have severe ramifications for your business and if the monetary cap is too low, your company will be picking up the tab for any additional fines past the amount of the initial cap.

Overall, I would say that it’s perfectly reasonable to include unlimited liability for breach of confidentiality in your company’s SaaS / Cloud contracts depending upon the type of confidential data to be stored and your line of business. However, keep in mind that many vendors may take issue with it, and if this is the case, be prepared with a back fence position that will protect your company.

Surviving a Technology Vendor Acquisition

Oracle sign at Oracle Corporation hea...

(Wikipedia)

In the wake of recent acquisitions this month by IBM (who bought Aspera) and Oracle (who bought Responsys), I put together a technology vendor acquisition survival kit.  As with any acquisition, there will be changes and if your vendor is being acquired by a much larger technology vendor (think Big Blue or Larry E.) the changes could be dramatic.

So, if you’ve found out that your vendor is being acquired and are currently lost in the wilderness of vendor acquisition, this collection of great posts and resources is for you.

  1. Merger Madness – What to Do
  2. What to Do When Your Software is Purchased By Another Vendor
  3. Software Vendor Consolidation
  4. Did Your Software Vendor Get Acquired? Now What?

As mentioned in many of the posts above, create an acquisition strategy for your organization. Don’t sit back and wait for your procurement or legal department to engage you, because they may not be aware of it.  As soon as you’re aware of the acquisition, give your procurement or legal department a call and let them them know what’s going on, engaging them upfront in order to use their expertise.  Be proactive and remember that the key to surviving an acquisition is knowledge and knowledge is power.

Negotiating Vendor Cloud Computing Contracts

cloud

I stumbled across this phenomenal paper entitled Negotiating Cloud Contracts: Looking At Clouds From Both Sides Now, written by W. Kuan Hon, Christopher Millard and Ian Walden. It was published in Stanford’s Technology Law Review in the Fall of 2012.  What’s fascinating is that it’s the first paper I’ve seen which objectively reviews the negotiating process that takes place between both buyers and sellers of cloud computing software.

In the first part of their paper, the writers describe the cloud market, “The top ten strategic trends for 2013 include, are based on, or incorporate cloud computing; those trends include personal cloud, hybrid information technology and computing, cloud-based analytics, in memory computing and integrated technology ecosystems. However, the cloud market is still relatively immature. The state of providers’ standard contract terms seem to reflect this” (Hon, Millard, Walden, 80-81).

After reading those sentences, I almost fainted. For those of you that are negotiating vendor cloud contracts alongside me, you probably just fainted as well.  This is what I’ve been jumping up and down about for the past year, that cloud vendor contracts are very poor and are not in favor of the customer.  Is “the cloud” just that bright and shiny?

I think it is and I’ll tell you why. When a customer who has been dragging around an old, patched version of an enterprise software solution is told by the cloud vendor that they can migrate that customer’s enterprise data in about ten weeks to a cloud version that doesn’t require patches, downtime, or Charlton Heston’s cast of thousands to maintain it on a regular basis, all they can think of is “Where do I sign??!!”.

I was told once that these cloud vendors are “too large to negotiate with”.  Really? My answer to that is no, they aren’t too large to negotiate with and you can negotiate with them, either from a pricing perspective, contracting perspective or both. However, the key to negotiating with cloud vendors is to plan up front.

If you’re a small organization, you can leverage your buying power. You may not have a lot of funds to spend on external counsel, but that doesn’t mean you have to take the contractual negotiations lying down. Push for business items that you need in your contract and see how far you can get. Most importantly, you can still purchase with power.  Just as the adage of the crow adding the pebbles to the jar in order to drink the rainwater, you’ll eventually have enough purchasing power to feel the leverage. Don’t allow your team to purchase $10,000 or $30,000 licenses from the same vendor separately. Plan your cloud spending so that you’re putting down a large chunk of change at one time…then ask for that discount!

For those of you who spend millions of dollars a year in enterprise cloud solutions, meet with your procurement / sourcing,  legal and IT departments to holistically understand where you’re spending now, how much is being spent and who you’re spending it with.  Is your legal department open to creating your company’s own cloud agreement? Given the paper stated above, most cloud vendor agreements are woefully inadequate. Why not come up with your own template that you can use repeatedly with multiple cloud vendors? From a pricing perspective, you are the big fish. You should remain in control, regardless of what the vendor tells you on pricing. Push for the discount and request it each time. If you don’t, you’re missing out on saving your company millions of dollars a year.

For negotiations with cloud vendors to work, the purchasing department / legal department need to work side-by-side with the business. This includes coordinated efforts with the vendor during negotiations, both pricing and contractual negotiations. Unfortunately dear customers, the cloud vendors are counting on you to be so desperate that you will swallow any bitter pill they bestow upon you and your colleagues during pricing and contract negotiations. In a previous post, I wrote about the hard truths of cloud vendor SLA’s.  However, I encourage you to truly understand the power you have when negotiating  with a cloud vendor. Take your time to choose the vendor that will support your organization and don’t settle for the scraps you’re thrown.