How to Negotiate Your IT/Tech NDA Faster (or, Living with a Suboptimal NDA)

Recently I found myself watching a past episode of HBO’s award-winning tech comedy series, Silicon Valley. If you’ve never watched it, it’s about a Silicon Valley tech start-up and its struggles, successes, and missteps. Although at times the show can be a bit gratuitous, part of its interest derives from the proximity – at least on some conceptual level – of many of its plot lines to reality.

Because I routinely help clients with non-disclosure agreements (NDAs) and related issues, I cringed watching the “Runaway Devaluation” episode from the second season. In this episode, the start-up (a data compression company called Pied Piper) is invited to an initial meeting with a potential funding source (Branscomb Ventures), which has already invested in a competing compression company, Endframe. Shortly after the meeting begins, the Pied Piper team begins sharing critical details of how its data compression technology is built and works. Later, realizing that Branscomb’s intention for the meeting was only to gather these details for the improvement of Endframe’s products, Pied Piper storms out of the meeting.

While it appears there was no NDA between Pied Piper and Branscomb Ventures covering the meeting’s discussions, in reality it is routine for parties to potential IT and technology transactions to put an NDA in place. Vendors, customers, and others in the IT/technology industry generally understand the need to protect their trade secrets and other valuable information when sharing them to evaluate potential relationships with vendors who provide software, hosting, outsourcing, professional technology services, and data breach investigation and remediation services. Among typical participating parties, the need to put in place an NDA is rarely disputed, and many NDA terms and conditions are quite common.

That said, NDA negotiations can nonetheless become time-consuming or contentious. Whether based on a party’s bad experience in a previous situation, defensive or offensive tendencies, or need to avoid deviations from company policies, otherwise common NDA terms can lead to uncommonly protracted negotiations. For a vendor looking to sell to a new customer, lengthy or difficult NDA negotiations can cause the potential customer to view the vendor as being difficult to deal with, or, worse, to drop the vendor from consideration entirely. For a customer wanting to urgently find a vendor to provide services to address a data breach, time to negotiate an NDA is not a luxury.

Even with NDAs, though, there are ways to speed up the negotiations – which, additionally or alternatively, can also provide mitigations to living with a less-than-desirable NDA. The following steps are a few that may allow an NDA party to get comfortable with otherwise problematic NDA terms in a specific case. (Importantly, these measures should not be implemented if contrary to a contractual obligation or law, nor should they replace sound judgment and risk management.)

For a disclosing party that:

(1) After discussions start, is concerned that the receiving party may not handle or treat its confidential information in way that is satisfactory (or that the NDA’s confidentiality terms are not optimal), the disclosing party can do as Pied Piper did and cease providing any more information. (Though, this may stifle productive business discussions, and the party should attempt to put a retroactive NDA in place.)

(2) Believes that the confidentiality terms are not ideal or has concerns about the receiving party’s handling or treatment of its confidential information, the disclosing party can proactively intentionally limit disclosure to only its least sensitive information. (This step, too, may hamper meaningful discussions between the parties.)

(3) Is concerned that the duration of the NDA may cover discussions too far in the future to be appropriately covered under the NDA, the disclosing party can terminate the NDA after the then-presently contemplated discussions.

(4) Has concerns about the information protections provided by the NDA or the receiving party, the disclosing party can conspicuously mark all information disclosed as “CONFIDENTIAL” – that is, even if the NDA doesn’t require it. And, after disclosing confidential information orally, the disclosing party can follow each such disclosure with a written notice expressly identifying the orally disclosed information as “CONFIDENTIAL.”)

For a receiving party that:

(1) Has concerns about its ability to fully adhere to the NDA’s limitations on use and disclosure of the disclosing party’s information, the receiving party can actively limit the number of its personnel who see or have access to the information.

(2) Is concerned about its risk of non-compliance with the NDA’s confidentiality terms, the receiving party can consciously limit the number of copies it makes of the disclosing party’s information (including copies in the form of email attachments). (This assumes copying is permitted.)

(3) Has concerns that it may struggle to meet the NDA’s limitations on disclosure and use of the disclosing party’s information, the receiving party can immediately destroy (or return) the information once it is no longer needed.

As for Pied Piper, it turns out that Endframe did indeed improve its products using Pied Piper’s technology. However, whether due to the lack of an NDA – or, more likely, the constraints of a ten-episode television season for Silicon Valley – Pied Piper was forced to take other, non-legal actions to advance its interests.

Getting Your Data Back – a Hostage Crisis?

One of the key differences between a cloud computing delivery model and a customer-hosted solution is the service provider, not the customer, possesses the customer’s data under a cloud computing delivery model. At the end of such a relationship the customer needs its data returned. Many service providers’ form agreements, however, do not address when and in what format the data will be returned. Given the vital importance of data to a company’s business, a customer should address this issue prior to entering into such an agreement.

What seems like a relatively simple provision to implement can sometimes lead to surprisingly protracted discussions. Customers often request their data be returned at expiration or termination of the contract (or during the termination / expiration period) in the format requested by the customer. Service providers’ concerns with such a requirement is the customer might request a format that is different than that being used, resulting in expensive and time-consuming file conversion. Or the customer might request some of its data in paper and electronic format, requiring the service provider to print reams of paper. These concerns lead service providers to counter with a provision requiring the service provider to return the data in its then-current format.

This typically leads to the customer raising its concern that the data could be returned in a format that is no longer compatible with the customer’s systems, requiring the customer to undertake the expensive and time-consuming conversion process and causing a material adverse impact to the customer’s business.

What’s the right answer? Each negotiation will be different depending on factors such as the importance of the data, the leverage of the parties, and the amount of data at issue. Service providers, however, must be sensitive to the customer’s concerns of the data being the customer’s lifeblood, and the customer not wanting to be held hostage at the end of the relationship. I’ve seen parties eventually agree that the service provider must return the data upon expiration or termination in a format reasonably usable by the customer at no additional cost to the customer, or in a format reasonably requested by the customer and commonly used in the industry based on the type of data.


Negotiating Cloud Contracts

We’ve all heard the phrase. Cloud vendors speak it in somber, authoritative tones as frustrated customers grumble and curse. The phrase? “Sorry, we don’t make changes to our standard contract.”

A virtual fight has been brewing over “the phrase” in the last few weeks. The first volley was fired by Bob Warfield in a blog post called “Gartner: The Cloud is Not a Contract” where Mr. Warfield argues that it’s perfectly reasonable for a cloud provider to use “the phrase.” In fact, he says, if a cloud provider doesn’t say it at every opportunity, the provider risks becoming *gasp* a mere datacenter. He says:

What [the Cloud] is about is commoditization through scale and through sharing of resources which leads to what we call elasticity. That’s the first tier. The second tier is that it is about the automation of operations through API’s, not feet in the datacenter cages.

* * *

Now what is the impact of contracts on all that? First, a contract cannot make an ordinary datacenter into a Cloud no matter who owns it unless it addresses those issues. Clouds are Clouds because they have those qualities and not because some contract or marketer has labeled them as such. Second, arbitrary contracts have the power to turn Clouds into ordinary hosted data centers: A contract can destroy a Cloud’s essential “Cloudness”!

* * *

How do we avoid having a contract destroy “Cloudness?” This is simple: Never sign a contract with your Cloud provider that interferes with their ability to commoditize through scale, sharing, and automation of operations. If they are smart, the Cloud provider will never let it get to that stage.

Mr. Warfield goes on to argue that any deviation to a cloud provider’s contract that impacts scale, sharing, or automated ops essentially destroys the benefit of cloud computing, and results in turning a cloud contract into a managed data center contract. In other words, if a provider is not a “pure” cloud provider, they are a datacenter provider.

Lydia Leong at Gartner quickly escalated the battle, responding in a blog post entitled “The Cloud and Customized Contracts.” Ms. Leong counters that cloud providers should be careful in using “the phrase” since it might not align with their business goals. At the same time, she also cautions that customers looking for substantive customizations to a cloud offering might undermine the cost savings they are seeking:

[A] cloud provider has to make decisions about how much they’re willing to compromise the purity of their model — what that costs them versus what that gains them. This is a business decision; a provider is not wrong for compromising purity, any more than a provider is right for being totally pure. It’s a question of what you want your business to be, and you can obtain success along the full spectrum. A provider has to ensure that their stance on customization is consistent with who and what they are, and they may also have to consider the trade off between short-term sales and long-term success.

* * *

Customers have to be educated that customization costs them more and may actually lower their quality of the service they receive, because part of the way that cloud providers drive availability is by driving repeatability. Similarly, the less you share, the more you pay.

* * *

. . . I believe that customers will continue to make choices along that spectrum. Most of them will walk into decisions with open eyes, and some will decide to sacrifice cost for customization. They are doing this today, and they will continue to do it. Importantly, they are segmenting their IT portfolios and consciously deciding what they can commoditize and what they can’t. . . . [U]ltimately, the most successful IT managers will be the ones who be the ones that manage IT to business goals.

So should a customer negotiate a cloud contract or not? As Ms. Leong states, it depends on the customer’s business demands. If the business demands the lowest cost and is willing to bear additional risk, then a non-negotiated “pure” cloud contract might be best. On the other hand, if the business demands that costs and risks be balanced, or that risk mitigation take priority over cost savings, then a negotiated contract is likely the best option.

Fortunately for customers, market forces are already influencing cloud providers to make their contracts more detailed and customer-friendly. In a recent article about cloud predictions for 2011, journalist George Lawton writes:

As cloud providers compete for new customers, many will begin to extend more elaborate guarantees, concrete remedies and better data transit awareness. The guarantees will provide better legal protection on the control of data. Confident providers will also include more detailed service-level agreements (SLAs) and financial remedies, covering all aspects of the cloud service, that could affect the customer’s business performance. Cloud providers will also offer to provide improved visibility into the movement of data to maintain legal requirements.

If this trend continues and cloud providers include reasonable protections for customers in their standard contracts, then hearing “the phrase” might not be so bad after all. In the meantime, customers must continue to balance cost savings with risk mitigation, and negotiate (or not) accordingly.

Is Your Data in the Cloud Backed Up and Recoverable?

In 2011, Acronis, a backup and recovery solutions provider, launched a Global Disaster Recovery Index for small and medium-sized businesses to measure IT managers’ confidence in their backup and recovery operations. Notably, businesses in the United States scored poorly in their confidence in their ability to execute disaster recovery and backup operations in the event of a serious incident, either in their own environment or a third-party cloud environment.

As companies move various functions to a cloud environment, they can increase their confidence by contractually agreeing to data backup and recovery requirements with their cloud providers. Indeed, customers can specify, as a service level or other contractual requirement, the (a) recovery point objective (“RPO”), which is the point in time to which the provider must recover data, and (b) recovery time objective (‘RTO”), which defines how quickly the provider must restore the data to the RPO.

Too often, however, companies sign cloud agreements without clearly specifying these metrics. Indeed, when a disaster or disruption occurs, many companies are surprised to find their contracts silent on these metrics, and the cloud provider operating under a much less stringent RPO and RTO than the company expected.