Tag: Negotiation

Data Destruction Contract Clauses Are a Hot Topic

Morgan Stanley’s recent payment of $60M to settle a civil proceeding for failing to properly dispose of customer data is a reminder of the importance of knowing applicable data disposal laws and drafting appropriate data destruction clauses in technology agreements.

Sources of Obligations

The sources of obligations to destroy or dispose of personal data are myriad. Direct and indirect federal requirements include the Gramm-Leach-Bliley (“GLB”) Interagency Guidelines Establishing Information Security Standards, the GLB Safeguards Rule, the Health Insurance Portability and Accountability Act (“HIPAA”) Privacy Rule, the HIPAA Security Rule, and the Fair and Accurate Credit Transactions Act Disposal Rule. Unfair and deceptive acts and practices laws, both federal and state, may also apply. In addition, at least 35 states have unique data disposal laws.

Common law negligence, invasion of privacy, and unjust enrichment are just a few other claims that may be brought against companies failing to properly destroy personal information. And, apart from these requirements, technology agreements typically include provisions requiring deletion or return of confidential information.

The data disposal requirements are not simple or easy to navigate, either. Numerous companies besides Morgan Stanley have suffered lapses, including, for example, American United Mortgage Company, Cornell Prescription Pharmacy, FileFax, CVS Pharmacy, Searchtec, Home Depot, and RadioShack.

Data Destruction Tips for Technology Customers

That said, for customers contracting for technology services or products that require the use or availability of personal data, several steps are available to reduce  data disposal risks.

  • Know what personal information destruction and disposal laws apply. Must the destruction efforts be reasonable or must the data be rendered unreadable or undecipherable? Must the data also be unusable?
  • Include agreement provisions requiring the vendor to destroy (or return) the data upon request and, in all cases, upon termination or expiration of the agreement. Add that, upon request, the vendor certify or acknowledge the destruction. Follow through on this requirement.
  • Contractually require the vendor to qualitatively destroy the information so that it is permanently irretrievable, unreadable, inaccessible, and indecipherable. Mandate that paper media be shredded, disintegrated, incinerated, pulverized, or pulped.
  • Include in the contract a right to audit the vendor’s data disposal or destruction and ensure that the vendor’s obligation to establish and implement reasonable security measures aligns with the data destruction requirements.

Data Disposal Tips for Technology Vendors

For technology vendors, which may also have legal obligations to destroy or dispose of data, contractual and operational mitigations also exist.

  • Before contracting, know the personal information destruction and disposal laws that apply. For example, is the vendor a business associate under HIPAA?
  • Proactively include language in the agreement permitting vendor destruction or disposal of the data.
  • Utilize best industry practices to destroy or erase the data – even if the technology agreement does not require it.
  • Segregate each customer’s personal data from other customers’ data, to facilitate discrete and expedient destruction or disposal.

These mitigations for technology customers and vendors are even more important, given the volume and dynamic nature of data destruction and disposal requirements and corresponding challenges for these companies.

Cyber Insurance: No Lifeline for Enterprise Technology Customers

Recent major cyber attacks have kickstarted a cyber insurance buying frenzy. However, because cyber insurance coverage is unpredictable on many levels, it is critical that technology customers take meaningful steps to address insurance risks and to contract appropriately with their technology vendors.

Cyber Insurance Challenges

Cyber insurance sounds great on paper but is difficult to implement effectively. Policies notably are not uniform or standard in providing coverage for particular occurrences, parties, or losses. Even within a particular insurance provision, contract language is unpredictable and varies widely across insurers. For example, cyber attacks initiated by state actors may or may not be covered, depending on whether the attack is considered terrorism, an act of war, or a warlike action.

Moreover, insureds and insurers routinely disagree as to the coverage and intent of cyber insurance policies. Litigation involving Mondelez, Payless Shoesource, Alorica, National Bank of Blacksburg, Sony, Target, and SS&C Technologies is just the tip of the iceberg. As for pace, let’s just say that two months ago, Home Depot filed suit against three insurers to seek to obtain coverage under its policies in connection with the massive date breach it suffered seven years ago.

Decision-Making Concerns

Of concern, then, enterprise technology customers frequently base their decision to accept cyber-related contractual indemnities and limitations of liability from their vendors based on the mere fact that the vendors – or the customers – have cyber liability insurance. The customers often accept the risks without evaluating the vendors’ purported policies and without revisiting their own coverages based on the particular technology transaction. Even obligating the vendor to implement reasonable security measures is not enough.

Contractual and Operational Mitigations

The following contractual and operational tips may help enterprise customers identify and mitigate cyber liability insurance related risks under their technology agreements.

  • Read your policies. Technology customers should carefully review and evaluate their insurance policies, including their cyber liability policy, to determine the extent of coverage for the cyber risks for the particular technology transaction and vendor. In some cases, standard business policies (such as property insurance, crime insurance, or commercial general liability coverage) may include cyberattack losses.
  • Summarize your policies for internal stakeholders. Your technology contract negotiation team will be much better able to assess applicable cyber risk for a particular technology transaction if they know the specific scope and extent of your own cyber and other insurance policies.
  • Monitor policy changes. The technology agreement should require the vendor to provide prompt notice of changes in the vendor’s insurance coverages. The agreement should establish that vendor breaches of insurance provisions specifically give rise to customer termination rights.
  • Increase insurance coverages. When the customer’s business team insists that the particular technology vendor is the best resource for the deal, but the vendor does not have adequate cyber insurance, the customer should consider obligating the vendor to procure sufficient coverage, even if only for the particular transaction. Be aware, however, that the vendor may seek to burden the customer with the cost of the additional coverage.

And, do keep in mind that businesses commonly underestimate the cyber coverage they need to mitigate cyber risks.

Is Your Technology Non-Compete Enforceable?

Frequently, software license agreements, cloud agreements, and other technology contracts include restrictive covenants or non-compete clauses that prohibit a customer from using the vendor’s technology to develop competitive or substantially similar products or services. The court in Triage Logic Management and Consulting v. Innovative Triage Services examined the issue and provided a road map for saving such provisions. Hint: Like online terms and conditions, careful contracting is critical.

Triage Logic Case

In Triage Logic, the software vendor sued the customer for contracting with a third party to develop software similar to the vendor’s licensed product. The vendor-customer agreement prohibited the customer from “develop[ing] similar software, services or product offerings substantially similar to the System” described in the agreement. The clause expressly survived the termination of the agreement.

The court concluded that the non-compete provision contradicted state antitrust law and, thus, was unenforceable, based on the particular restraint being indefinite and perpetual. Applicable state law barred the court from reforming the restrictive covenant to make it enforceable.

State Law Does Matter

Because the Triage Logic case was decided under North Carolina law, it invites comparison to other state laws. For example, under the Texas Free Enterprise and Antitrust Act of 1983, a covenant not to compete is enforceable if it is ancillary to or part of an otherwise enforceable agreement and contains reasonable and limited parameters as to time, geography, and scope. Unlike North Carolina law, the Texas statute requires courts to reform covenants that are not reasonable and limited.

A covenant not to compete is enforceable under Delaware law if it meets general contract law requirements, is reasonable in scope and duration, advances a legitimate economic interest, and balances equities. Delaware courts may, but are not required to, reform otherwise unenforceable provisions. New York law imposes a “simple rule of reason” analysis to non-compete provisions in ordinary commercial contracts (such as license agreements). New York permits blue-penciling of non-compete provisions only when the unenforceable portion of the provision is not essential, among other requirements.

Help is Available

When negotiating a non-compete clause in a technology agreement, technology vendors should consider the following drafting tips to increase the likelihood that the restrictive covenant is upheld.

  • Duration. A perpetual or otherwise excessive duration for a non-compete provision is unlikely to be enforced, whether the duration is identified in the clause, itself, or the provision expressly survives agreement termination.
  • Pencil Color. If the governing state law does not afford blue-penciling or equitable reformation, the non-compete provision may be salvageable if the contract includes a clear and permissive severability clause. Even if the governing law favors reformation, avoid a severability clause that merely instructs deletion of the offending provision.
  • Express Rescue. To seek to save a non-compete clause from unenforceability, include express fallback positions in the contract to operate if primary terms (such as those regarding duration, scope, and geography) are held invalid.
  • Purpose. A restrictive covenant stating a blanket prohibition, rather than one being specifically limited to competitive conduct, is less likely to be held enforceable.

On the other hand, customers seeking to defeat the application of a non-compete clause should do the opposite….

Contracting Conundrum: “Reasonable Security Measures”

In technology contracts between customers and vendors, it is common to obligate one or both parties to implement “reasonable security measures” to protect applicable data and information. Typically, the obligation is a function of risk allocation or legal requirements. The recently enacted (and more recently amended) California Consumer Privacy Act’s authorization of a private right of action against businesses that fail to implement reasonable security procedures and practices highlights the issue. But, what are “reasonable security measures?” And, which contracting party decides?

The Market Speaks

Often, technology contracts merely reference, but do not explain, reasonable security measures. A contract may require a party simply to “implement reasonable security measures” to safeguard applicable information. Alternatively, a contract may obligate the party to “implement reasonable security measures as required by applicable law” or to “comply with applicable data privacy and security laws, including those regarding security measures.” Both customers and vendors can find these examples appealing.

Pushing the Envelope

Less often, but frequently when the technology transaction involves financial services companies, the contract may impose more stringent requirements based on statute or regulation. For example, the vendor may be obligated to “implement administrative, technical, and physical safeguards to insure the security and confidentiality of customer records and information, to protect against any anticipated threats or hazards to the security or integrity of such records, and to protect against unauthorized access to or use of such records or information which could result in substantial harm or inconvenience to any customer.”

Similarly, technology contracts involving healthcare information can mirror applicable federal regulations and obligate a party to “implement administrative, physical, and technical safeguards that reasonably and appropriately protect the confidentiality, integrity, and availability of the information.” For EU personal data, the Standard Contract Clauses (which will likely soon change) may be invoked.

Although usually advocated by technology customers, because these more specifically stated obligations track legal requirements, they are often acceptable to the customers’ vendors.

Breaking the Envelope

In a few cases, customers or vendors may choose to sidestep the vagueness of the above options. For example, agreements with ties to California may explicitly reference the 2016 California Data Breach Report, which specifically states that an organization’s failure to implement all twenty controls in the Center for Internet Security’s Critical Security Controls constitutes a lack of reasonable security. When payment card information is in scope, the contracting vendor may be directed to comply with the PCI Data Security Standards.

Increasingly more common, a technology customer – or vendor – may expressly set out detailed, bespoke security measures. The contractual statement of these measures can range from one, to three, to five or more pages.

Clearly, there are many ways for contracting parties to reach agreement on applicable security measures to be implemented under a technology contract. Be sure that what you sign up for works best for your company – all costs, risks, and consequences considered.

Post-COVID Help for Corporate Legal Departments

Updating in-house contract templates and negotiation playbooks is not sexy, nor is it directly related to a particular revenue-generating transaction. However, it may be an efficient way to address the increased pressure on in-house counsel to close more deals in less time – with fewer in-house resources and with smaller outside counsel budgets – brought on by COVID-19.

Your peers are already doing it.

Precarious State of In-House Transaction Support

Drafting and negotiating contracts is much more challenging since the outbreak of COVID-19. According to a recent Altman Weil survey, 44% of Legal departments plan to cut their 2021 budgets. HBR Consulting’s 2020 Law Department Survey reveals that 84% of Legal departments are experiencing increased workloads and 18% are planning layoffs.

The Legal departments surveyed did, however, identify responsive measures. HBR Consulting reported that 70% of Legal departments have adopted templates for standard contracts and that 32% of departments plan (or have begun) to implement negotiation playbooks.

Contract Templates and Negotiation Playbooks to the Rescue

Any investment in developing, or merely updating, contract templates or negotiation playbooks is likely to pay off. The following contract issues are appearing more often and in a new light. Expedite your negotiations by proactively formalizing your attack (and fallbacks).

  • Force Majeure. More frequently, force majeure clauses are no longer only two or three sentences, but are much longer. They now often additionally address notice timing, notice details, and minimum duration of non-performance for an event to qualify as force majeure.
  • Changes in Laws. Changes in laws provisions are becoming more common. Customers and vendors are reacting to the prospect of unforeseen legislative and regulatory activity and are looking to avoid having no contractual mechanism to deal with events like the passage of the future version of California’s consumer privacy law or the invalidation of the Privacy Shield.
  • Business Continuity and Disaster Recovery. Often secondary to force majeure, now more contracts are requiring ongoing and uninterrupted performance even in disaster situations. Many agreements now tie these (new) obligations to force majeure rights.
  • Remote workers. Working remotely is likely to last long beyond the pandemic. For both vendors and customers of technology, new contract terms and terminology addressing remote access and use are gaining traction as to software licensing, cloud access, and other technology user-based provisions, as well as cyber security commitments.
  • Data Security. More customer template contracts are including comprehensive data security terms. Although previously common among customers in financial services, healthcare, energy, and other regulated industries, more vendors are seeing template schedules and detailed provisions from non-regulated entities.

You don’t need to do a front 4½ pike into the deep end of the template and playbook pool to reap benefits. Wading into the shallow end will still generate meaningful returns.

One Technology Agreement + One Separate Non-Disclosure Agreement = One Mess

The current COVID-19/coronavirus crisis has forced many companies to buy or sell new technology under a previously unseen sense of urgency. While this speed is critical – and absolutely understandable – take care to ensure that today’s deal structure does not undo tomorrow’s benefit. This is especially true as to non-disclosure and confidentiality issues.

If your corporate contracting practice involves establishing a non-disclosure agreement (or confidentiality agreement or NDA) with a potential technology customer or supplier, and then later contracting under a different agreement for the actual business you wish to transact with the other party, now is the time to examine whether that practice is achieving its objectives. As recently learned by one technology supplier, in these cases the terms of the NDA may be rendered ineffective by the subsequent technology contract. iSentium v. Bloomberg Finance (S.D.N.Y. 2020).

iSentium, a technology vendor, entered into a pre-transaction NDA with Bloomberg, pursuant to which Bloomberg considered whether it was interested in iSentium’s artificial intelligence technology. The parties later entered into a technology contract covering Bloomberg’s purchase and use of iSentium’s technology. Both the NDA and the commercial contract included confidentiality terms. iSentium later sued Bloomberg for misappropriation of iSentium’s confidential information. The district court dismissed iSentium’s action based on a one-year limitations period stated in the commercial contract, despite that the NDA included no such limitation. In reaching its decision, the court highlighted the merger provision and precedence language in the commercial contract.

Read the Technology Agreement and Non-Disclosure Agreement

It is not uncommon for a company to have a pre-transaction non-disclosure agreement and a separate commercial agreement with a business partner. However, in many cases, the two agreements are not carefully read together and end up including inconsistencies that are not clearly addressed in the later commercial agreement. Sometimes the commercial agreement is wholly silent as to the existence of the NDA. Other times, the commercial agreement incorporates by reference the inconsistent NDA. In still other cases, like in iSentium, the commercial agreement expressly merges the inconsistent separate NDA.

Inconsistencies between the NDA and commercial agreement can reach matters such as, for example, specific confidentiality requirements, governing law, indemnification, limitations of liability, representations and warranties, disclaimers, and dispute resolution. Often, the inconsistencies may arise after having had to negotiate a suboptimal NDA, as discussed in an earlier blog post.

The inconsistencies frequently create ambiguities or vagueness that can impair or deny a party’s ability to enforce the deal or the rights it thought it had. They also can require significant expense and executive and management time to address, and they can unnecessarily occupy the energy and efforts of internal Legal resources to resolve.

Make Sure the Technology Agreement and Non-Disclosure Agreement are Consistent

There are several ways to address the problems created by inconsistencies between a separate technology agreement and non-disclosure agreement. A few include:

  • Don’t be silent. Include in the technology agreement language explicitly stating that all inconsistencies, ambiguities, and conflicts between it and the NDA will be resolved in favor of the technology agreement – whether or not the NDA is integrated into or merged with the technology agreement. Identify silence on a matter in the NDA as a conflict.
  • Set a clear path. Specifically provide in the technology agreement which confidential information is controlled by the terms and conditions of the technology agreement and call out which confidential information is governed by the NDA.
  • Terminate the NDA. Ensure that the technology agreement addresses, in all respects, the relevant confidentiality and other terms, and then include language in the technology agreement that terminates the NDA’s prospective effect.
  • Apply all terms. State in the technology agreement that its applicable terms (including, for example, limitations of liability, governing law, and dispute resolution) apply to the NDA and the exchange of confidential information under the NDA, despite anything different in the NDA.

This is not an exhaustive list of options. Which (and whether any) alternative works for you may depend on any number of factors or considerations.

Most importantly, to avoid a situation where (1) you have an NDA and a separate, later technology agreement covering the same subject matter, but (2) you might not be able to enforce the agreement you want to enforce due to conflicting or inconsistent terms, carefully read the two agreements and clearly and unequivocally state the resolution of the conflict or inconsistency in the later technology agreement.

Eight Ways to Close Your Year-End Deals on Time

With less than four weeks until the end of the calendar year, many buyers and sellers of software, SaaS, cloud, cybersecurity, and other IT products and services have too many deals – and not enough time – to get everything done. Having been on both sides of year-end technology transactions, I’ve not yet seen a magic wand that provides the sales and procurement teams a stress-free year-end contracting experience.

That said, there are several different tactics to try to help technology buyers and sellers conclude year-end transactions that meet their needs and goals – despite the timing stress. The key is creativity. For example, requiring each party to set aside eight hours every day for team-to-team negotiations until the agreement is finalized – when each team has ten other deals they’re also trying to close by year-end – is impractical.

As you sprint toward the year-end finish line, consider whether one or more of the following contract approaches may help you to close a transaction that still reflects a good deal for your client or company:

Shorten the Term. If your year-end deal is troubling because your client’s or company’s obligations and responsibilities extend for three, five, or more years, shorten the duration of the contract and include optional renewals or extensions to get to the originally proposed longer term.

Extend Payments. If you are unsure whether the other party will perform its contractual obligations over the short-term, spread out the buyer’s payment obligations over a period of time. (The seller’s obligations to continue to provide technology products or services could be tied to the buyer’s extended payment obligations, as well.)

Termination Rights. To address uncertainty as to the other side’s near-term performance, build in to the agreement certain for-convenience termination rights that deal with unmet milestones or benchmarks that wouldn’t otherwise be material breaches of the agreement.

Aggressive Limitations of Liability. If you are not confident that your client or company will easily perform all of its obligations under the proposed year-end contract, aggressively limit your client’s or company’s liability under the agreement in the event of non-performance.

Current Scope Only. Some year-end deals try to accomplish too much – that is, they seek to include products or services that won’t be provided for many months or even years after signing. Limit the subject of the year-end deal to only those products and services that are immediately in scope, and temporarily postpone contracting for items that are to be provided separately, later.

Agree on Details Later. Some year-end transactions contemplate comprehensive professional services that are provided in stages, where the requirements of each later stage depend on the outputs from the earlier stages. Rather than trying to exhaustively detail each stage’s requirements and outputs all at once, expressly defer the details until later in the contract term – and build in to the contract appropriate mechanisms and outcomes if the details are not agreed.

Top Five Issues. Although rarely a favorite option of technology buyers or sellers, limiting one party or both parties to raising and negotiating only its top five contract issues will likely expedite the process of concluding the year-end deal.

Post-Signing Diligence. Allow one or both parties a short period of time after contract signing to perform deal diligence that they weren’t able to conclude before signing. If the diligence reveals material concerns with the signed agreement, permit the parties to renegotiate any impacted contract terms or to otherwise address the gaps.

Note: Several of the above tactics may be seen by technology sellers as untenable due to potential negative effects on their ability to recognize revenue for a particular deal. In some cases, however, whether in return for a larger or longer deal or otherwise, sellers may be willing to negotiate unique terms in order to close the year-end deal.

Good luck in your negotiations!

2019 Case Law Mash-Up: Can you assign exaggerated representations and warranties to a locked-in vendor?

Mash-up (noun): (slang) a creative combination of content or elements from different sources.

Several court cases in 2019 dealt with (or are still dealing with) key issues faced by parties to commercial contracts, including contracts for technology products and services. This post briefly discusses four of those cases and their corresponding issues of contract assignment, representations and warranties, and data security.

Can You Assign?

According to the court in Barrow-Shaver Resources v. Carrizo Oil & Gas (Tex. 2019), the answer to the question, “Can you assign?” is “No.” Bottom line: Make sure your contract clauses are clear and unambiguous, and don’t plan to rely on prior negotiations, drafts, or margin comments to explain away terms you don’t like.

The contract in question included an unambiguous non-assignment clause that read, “The rights provided to [Barrow-Shaver] under this Letter Agreement may not be assigned, subleased or otherwise transferred in whole or in part, without the express written consent of Carrizo.”

The court concluded that Carrizo was within its contractual rights to simply refuse to provide consent to Barrow-Shaver’s requested assignment – without more. Neither the contract language nor applicable law required Carrizo, in withholding consent, to exercise good faith, to be reasonable, to satisfy certain conditions, or to provide a reason for withholding consent.

The court rejected arguments that, notwithstanding the contract language: industry custom and usage should be applied to interpret when consent may be withheld; prior to contracting, Carrizo assured Barrow-Shaver that Carrizo would provide its consent; and, the parties’ prior negotiations and an early draft of the contract should be considered.

Exaggerated Representations and Warranties

Two 2019 cases highlight the sales and contracting processes for big-ticket IT services. In IBM v. Lufkin Industries (Tex. 2019) (“Lufkin”), Lufkin Industries contracted with IBM for the provision and implementation of a new software solution to run Lufkin Industries’ operations systems. In Hertz v. Accenture (S.D.N.Y., not yet decided) (“Hertz”), Hertz contracted with Accenture to build a transformed web site and mobile application. A key takeaway from both cases is that well-drafted contractual disclaimers and integration clauses, absent explicit contractual representations or warranties, can defeat warranty breach, inducement, and misrepresentation claims.

In Lufkin, IBM made several pre-contractual representations regarding the timing and ease of implementation of the new software solution. Some representations were made orally, others appeared in sales materials. The project implementation process ultimately failed. In Hertz, Accenture is alleged to have delivered versions of contracted work product that failed to meet contractual timing requirements, specifications, and warranties. Hertz terminated Accenture’s contract before the project was completed.

In 2019, Hertz filed a lawsuit against Accenture for breach of contract and unfair and deceptive practices. In its motion to dismiss, Accenture specifically called out the contract’s integration clause and conspicuous warranty disclaimer provision. In Lufkin, IBM prevailed against Lufkin Industries’ claims for inducement and misrepresentation. The contract included clearly drafted language disclaiming IBM representations, disclaiming Lufkin Industries’ reliance on IBM representations, and establishing the contract as the entire agreement between the parties.

Contracting for large IT projects can be challenging. The projects are often complex and time-consuming and frequently involve developing or evolving parameters and requirements. Almost certainly, notable time is spent drafting contractual representations, warranties, disclaimers, and integration clauses. But, to address potential issues, also duly consider project scoping provisions and acceptance terms (including whether the RFP (if one) will be part of the contract). If possible, stay connected with your sales or procurement team throughout the sales process to ensure alignment and relevant project-specific contract terms.

Locked-In Vendor

Tightly drafted contracts are a valuable asset – but they are not the exclusive source of risk mitigation and avoidance. If you can, do more.

A class-action lawsuit was brought against Delta Air Lines following a data security breach affecting 800,000 Delta customers. See McGarry v. Delta Air Lines (C.D.Cal. 2019). The breach involved a hack of Delta’s service provider, 24[7] (a Philippines company). Delta subsequently sued 24[7] for damages arising from the breach.

The security terms in Delta-24[7] were robust and comprehensive. In addition, 24[7] represented that it had achieved five different industry-recognized privacy/security certifications. Although the contract terms and representations ultimately may be sufficient to award Delta damages, the contract doesn’t assure Delta’s full recovery. What other help is there?

For customers, even if it’s not required, pre-contract service provider diligence can be quite informative; for vendors, ensure that you can do what you contractually sign up for. When contracting with foreign companies, consider parent guarantees or other contractual mitigations. And, for customers and vendors, closely review your own insurance policies to evaluate coverage in the event of a security incident; also for customers, consider reviewing the service provider’s policies if you have coverage concerns.

Your Emoji Use Just Formed a Contract

Or, did it?

As confirmed in a very recent Wall Street Journal article, the legal impacts and effects of using emojis and emoticons in business and workplace communications and dealings are growing. For attorneys, contract professionals, and business executives and teams discussing, negotiating, and communicating about technology, business, deals, and transactions, the use of emojis (pictographs) and emoticons (punctuation marks, letters, and numbers) should be a concern.

Depending on the circumstances, using an emoji or emoticon to respond to another party’s email or message may have the same effect as if precisely crafted words had been used. Unless the author of the email or message is careful, casually sending a 👍, :-), 👌, or ☺ in response to an email putting forth a proposal or offer to do business may be the same as stating, “I agree to your terms.” At a minimum, replying to a message with an emoji may convey contractual intent. Bottom line, before using emojis or emoticons in emails and other communications, it is critical to consider how they may be received or interpreted.

The use of emojis clearly is on the rise. In its November 2016 report, Emogi reported that 2.3 trillion messages incorporating an emoji would be sent in 2016 – and the report did not include the use of emojis in emails. In addition, the Unicode Consortium recently announced that 157 new emojis have been added in 2018, bringing the total number of standard emojis to 2,823. As more of the business world adopts technology to communicate, it becomes more important for business leaders, procurement and purchasing professionals, and others to be mindful of their use of emojis and emoticons in emails, texts, and other message formats. To those businesses and companies that have “careful communications” policies, has your policy been updated to address the use of emojis?

Aside from general contract concerns, the use of emojis has and will increasingly impact parties’ legal rights and obligations. This includes in the areas of labor and employment, promissory estoppel, jury instructions, and criminal cases. According to research by Santa Clara University law professor Eric Goldman, for the set of reported cases that he was able to identify as mentioning “emoji” or “emoticon” over the 2004-2016 period, over 30% of the cases were from 2016, and nearly 50 were from 2015 and 2016.

And, if you needed another reason to be overly cautious when using emojis and emoticons in correspondence and communications, be aware that the true meaning attributed to any particular emoji may be vague, at best, or non-existent, at worst. Moreover, the form and appearance of the emoji you send may not be the same as the form and appearance seen by the recipient. In addition, different cultures, generations, and geographic regions interpret emojis differently. (The most confusing emoji? It’s 🤗.)

The reality is that emojis are easy to use and can be fun and communicative. They are, and will continue to be, used in emails, texts, and communications between and among business parties, their advisors, and others. Just be sure to 👀 before you 🏃.

Lessons Learned: Vendor Sued in Class Action Suit for Security Misses

You’re thinking that something about the title of this post sounds familiar, right? Information technology (IT) vendors and third party service providers have been in the spotlight for security breaches for some time (see, for example, vendor-based security lapses affecting Target, CVS, and Concentra, as just a few), and it doesn’t sound surprising that an IT vendor has been sued related to a security incident. After all, whether you’re an IT vendor or an IT customer, if you draft or negotiate contracts for a living, these situations are what you try to contract for, right?

Right…but…the recent federal class action suit filed in Pennsylvania against Aetna and its vendor surfaces several new privacy and security considerations for vendors and their customers. The vendor in question was not an IT vendor or service provider. Instead, the plaintiff’s allegations relate to Aetna’s use of a mailing vendor to send notification letters to Aetna insureds about ordering HIV medications by mail. According to the complaint, the vendor used envelopes with large transparent glassine windows – windows that did not hide the first several lines of the enclosed notification letters. The plaintiff asserts that anyone looking at any of the sealed envelopes could see the addressee’s name and mailing address – and that the addressee was being notified of options for filling HIV medications. As a result, the vendor and Aetna are alleged to have violated numerous laws and legal duties related to security and privacy.

For all vendors and service providers, but especially those that don’t focus primarily on privacy and security issues, the Aetna complaint is enlightening. To these vendors and service providers, and to their customers: Do your customer-vendor contracts and contract negotiations contemplate what Aetna and its mailing vendor may not have?

Do your contracts for non-IT and non-healthcare services fully consider the risk of privacy and security litigation? A noteworthy facet of the Aetna case is that the mailing vendor was sued for privacy and security violations that were not exclusively due to the customer’s acts or omissions. That is, while the contents of the mailer certainly were key, the vendor’s own conduct as a mailing services provider (not an IT or healthcare provider) was instrumental in the suit being filed against the vendor (and Aetna). Vendor services that previously didn’t, or ordinarily don’t, warrant privacy or security scrutiny, may, after all, need to be looked at in a new light.

Do your contract’s indemnification and limitation of liability clauses contemplate the possibility of class action litigation? Class action litigation creates a path for plaintiffs to bring litigation for claims that otherwise could not and would not be brought. Class action litigation against data custodians and owners for security breaches is the norm, and the possibility and expense of class action litigation is frequently on the minds of their attorneys and contract managers who negotiate contracts with privacy and security implications. But, for vendors and service providers providing arguably non-IT services to these customers – the idea of being subject to class action litigation is often not top-of-mind.

Before entering into a contract, have you considered whether the specific vendor services being provided to the particular customer in question implicate laws you hadn’t considered? Vendors that operate in the information technology space – and their customers – generally are well-aware of the myriad of privacy and security laws and issues that may impact the vendors’ business, including, as a very limited illustration, the EU General Data Protection Regulation, HIPAA, New York Cybersecurity Requirements, Vendors that aren’t “IT” vendors (and their customers), on the other hand, may not be. For example, the Aetna mailing vendor may not have contemplated that, as alleged by the Aetna plaintiff, the vendor’s provision of its services to Aetna would be subject to the state’s Confidentiality of HIV-Related Information Act and Unfair Trade Practices and Consumer Protection Law.

Have you considered which specific aspects of vendor services may directly impact potential legal liability, and have you adequately identified and addressed them in the contract? No, this is not a novel concept, but it nonetheless bears mention. A key fact to be discovered in the Aetna litigation is whether it was Aetna, or the vendor, that made the decision to use the large-window envelopes that, in effect, allegedly disclosed the sensitive and personally identifiable information. Given the current break-neck pace at which many Legal and Contract professionals must draft and negotiate contracts, however, unequivocally stating in a contract the details and descriptions of every single aspect of the services to be provided is often impractical (if not impossible). But, some contract details are still important.

Whether or not this class action suit is an outlier or is dismissed at some point, consider data security and other privacy and security issues in contracts and how vendor or service provider conduct may give rise to a security breach or security incident.