Category Archives: Contracts

The California Consumer Privacy Act: Why (and How) to Start Preparing Now

Posted on by
Reply

By now most companies have heard about the California Consumer Privacy Act (“CCPA”).  Privacy as an inalienable right has been enshrined in the California Constitution since 1972, and California has developed a reputation as being at the forefront of state privacy legislation. California is also known for grassroots-driven legislation through the ballot initiative process known as “Propositions.” The Cambridge Analytica scandal led to a combination of the two – a proposed data privacy law with extremely burdensome obligations and draconian penalties garnered enough signatures to appear on the ballot in November 2018.  To prevent this from happening, the California legislature partnered with California business and interest groups to introduce and pass the California Consumer Privacy Act. It went from introduction to being signed into law by the governor of California in a matter of days in June of 2018, resulting in withdrawal of the ballot initiative. No major privacy legislation had ever been enacted as quickly. The law will become effective as early as January 1, 2020 – the effective date is six (6) months after the California Attorney General releases implementing and clarifying regulations which are expected sometime in 2019. Given the speed at which it was enacted, CCPA has numerous drafting errors and inconsistent provisions which will need to be corrected. In addition, as of the date of this article, the implementing regulations are not yet released. 

Other states have introduced statutes similar to CCPA, and there is some discussion in Congress about a superseding national data privacy law. Because of this, companies may want to look at CCPA compliance from a nationwide, and not California, perspective. For companies hoping that CCPA will be scaled back or repealed, that’s not likely to happen.  The clock is ticking for businesses to develop and implement a compliance plan. When determining what compliance approach to take, consider the wisdom of the “Herd on the African Savanna” approach to compliance – the safest place to be in a herd on the African savanna is right in the center. It’s almost always the ones on the outside which get picked off, not the ones in the center. The ones more likely to be “picked off” through an investigation or lawsuit are the ones at the front of the herd (e.g., those who desire to be viewed as a leader in compliance) and the ones at the back of the herd (e.g., those who start working on compliance too late or don’t make serious efforts to be in compliance). For many companies, being in the center of the herd is the optimal initial position from a compliance perspective. Once additional compliance guidance is released, e.g., through clarifying regulations, press releases, or other guidance from the state Attorney General, companies can adjust their compliance efforts appropriately.

In this article, I’ll talk through steps that companies may want to consider as a roadmap towards CCPA compliance. (This is a good place to note that the information in this article does not constitute legal advice and is provided for informational purposes only. I summarize and simplify some of CCPA provisions for ease of discussion; you should look at the specific language of the statute to determine if a provision applies in your case. Consult your own internal or external privacy counsel to discuss the specifics of CCPA compliance for your own business.)

 

A Quick CCPA Refresher

The first problem with the “California Consumer Privacy Act” is its name. It applies to personal information collected about any California resident (not just consumers) in either a business-to-consumer (“B2C”) or business-to-business (“B2B”) context. It applies to almost every business entity that collects personal information about California residents, their affiliates, their service providers, and other third parties with which personal information is shared or disclosed. The use of “service provider” and “third party” are somewhat similar under the CCPA – both are businesses to which a company discloses a person’s confidential information for a business purpose pursuant to a written contract. The difference between the two is whether the information is being processed on behalf of the disclosing company. For example, SalesForce would be a service provider – it is processing personal information on behalf of your company. However, if the company with whom you share personal information processes it for its own benefit, not yours, it’s a “third party” under the CCPA.

“Personal Information” is defined extremely broadly under CCPA, in some ways even more broadly than under the EU’s General Data Protection Regulation (“GDPR”).  It is information that identifies, relates to, describes, is capable of being associated with, or could reasonably be linked, directly or indirectly, with a particular person or household. It includes but is not limited to IP address, geolocation data, commercial information, professional and employment-related information, network activity, biometric information, audio/video, and behavioral analytics about a person.  CCPA covers businesses which “collect” a California resident’s personal information, defined as actively or passively obtaining, gathering, accessing or otherwise receiving personal information from a person, or by observing the person’s behavior. It also covers “selling” personal information, which is another bad choice of a defined term – “selling” personal information under the CCPA includes selling, renting, sharing, disclosing, or otherwise communicating (by any means) personal information to another business or third party for monetary or other valuable consideration, with some significant exceptions.

CCPA creates five (5) rights for California residents:

  • The Right to Know – California residents have a general right to know the categories and purposes of personal information collected, sold, or otherwise disclosed about them.
  • The Right to Access and Portability – California residents have a specific right to know how, why and what personal information about them is being collected, sold or disclosed, and if information is provided electronically, to receive it in a portable format.
  • The Right to Deletion – California residents have a right to request the deletion of personal information about them collected by a business, with some exceptions.
  • The Right to Opt Out – California residents have a right to say “no” to a company’s sale, sharing or transfer of their personal information with third parties.
  • The Right to Equal Service & Pricing – California residents have a right to equal service and pricing whether or not they choose to exercise their CCPA rights.

Creating and Implementing a CCPA Compliance Plan

For companies that have not already gone through a GDPR compliance effort, CCPA compliance can seem daunting. However, creating a solid compliance plan and getting started now maximizes the chance your company will be in good shape for CCPA once it becomes effective. Here are some things to consider as you create and implement a CCPA compliance plan for your business. (Please note that if your company has already gone through a GDPR compliance effort, some of these may already be fully or mostly in place.)

1. Identify CCPA Champions within your business

An important initial step towards CCPA compliance is to identify the person(s) within your company that will lead the CCPA compliance effort. CCPA compliance will require a cross-departmental team. This often includes Legal (to advise on and help to interpret the statutory and regulatory requirements and to monitor for new developments both on CCPA and similar federal and state legislation, and to create a compliance plan for the business if the company does not have a data governance team); Development and Information Technology (to implement the necessary technical and operational systems, processes, and policies which enable CCPA compliance); Sales leadership (for visibility into CCPA compliance efforts and to help manage inbound requests for CCPA compliance addenda); Customer Support (as CCPA requires customer support personnel be trained on certain aspects of CCPA compliance); Security (if your company has a Chief Information Security Officer or other information security person or team); Data Governance (if your company has a data governance person or team); and an executive sponsor (to support the CCPA compliance efforts within the C-Suite). Depending on your company, there may be other involved groups/parties as well.

2. Determine how CCPA applies to your business

A key early step in CCPA compliance is determining how CCPA applies to your business.  There are different compliance requirements for companies that collect personal information, companies that process personal information as a service provider for other companies, and companies that “sell” personal information or disclose it for a business purpose.  

  • Does your business collect information directly from California residents, e.g., through online web forms, through customer support contacts, from employees who are California residents, through creation of an account, etc.?  If so, it must comply with CCPA requirements for companies that collect personal information (a “data controller” in GDPR parlance).
  • Does your business receive and process personal information on behalf of customers or other third parties?  If so, it must comply with CCPA requirements for companies acting as a service provider (a “data processor” in GDPR parlance.) If you are a service provider, you must ensure your service offerings enable customers to comply with their own obligations under CCPA.  If not, expect a lot of requests for assistance from your customers, which could result in significant manual effort.
  • Does your business (a) “sell” personal information to affiliates, service providers or third parties (other than for the excluded purposes under CCPA), and/or (b) disclose or otherwise share personal information with an affiliate, service provider or third party for operational or other notified purposes?  If so, it must comply with CCPA requirements for companies that “sell” personal information or disclose it for a business purpose. It’s important to note that under Section 1798.40(t)(2) of the CCPA, there are certain exceptions that when satisfied mean a company is not “selling” personal information under the CCPA. For example, a business does not “sell” personal information if a person uses that business’s software or online system, or gives consent for a business, to disclose their personal information to a third party, as long as that third party is also obligated not to “sell” the personal information. As another example, a business does not “sell” personal information when it shares it with a service provider, as long as certain conditions are met.

3. Inventory your data assets, data elements and data processes

One of the most important steps in CCPA compliance, and data privacy compliance in general, is to conduct a data inventory.  For CCPA purposes, consider inventorying your data assets (programs, SaaS solutions, systems, and service providers in which data elements are stored for use in data processes), data elements (elements of personal and other information stored in data assets), and data processes (business processes for which data elements are stored and processed in data assets).  This inventory should also collect information on service providers and other third parties with whom data elements are shared or disclosed by your business, and the purposes for which information is shared or disclosed.  Companies should try to complete this inventory as quickly as possible.  The CCPA compliance team should work to create a list of internal individuals who should complete this inventory; once all responses are received, the compliance team should consolidate the responses into a master table.

The data inventory is a snapshot in time.  It’s also important to refresh the data inventory on a regular basis, e.g., quarterly, to capture changes to data collection and usage over time.

4. Cease any unnecessary collection and/or storage of personal information (“data minimization”)

Once the data asset/element/process inventory is created, businesses should be encouraged to use the opportunity to conduct a “data minimization” exercise.  One of the central principles of data privacy is data minimization – limiting the collection and storage of personal information to only what is directly necessary and relevant to accomplish a specified business purpose.  The CCPA compliance team should consider both (a) identifying data elements without an associated data process, which I call “orphaned data elements,” and purging and ceasing the further collection of stored orphaned data elements; and (b) identifying data collection which is not associated with an associated business purpose, which I call “orphaned data transfers,” and cease any further orphaned data transfers and terminate the associated contracts.  Also consider validating that record retention policies are being followed so that data is promptly irretrievably deleted once it is no longer needed for a business purpose.

5. Implement a compliance plan for the 5 CCPA privacy rights

The heart of a CCPA compliance plan is implementing compliance with the 5 privacy rights created by the CCPA.  A solidly-constructed plan should cover compliance requirements where the business acts as a data collector, a service provider, or a company selling or otherwise disclosing personal information.

a. The Right to Know

One of CCPA’s core requirements is to publicly provide the necessary disclosure of the CCPA privacy rights, including the specific methods by which a person can submit requests to exercise those rights.  Many companies will likely add this to their privacy policy, as well as any California-specific disclosures already made by the business. Don’t forget this disclosure needs to be added not only to websites, but to mobile apps.  The disclosures must include a list of the categories of personal information collected, sold or disclosed for business purposes during the previous 12 months, as well as a list of the business purposes for which the categories are used. If this information is collected as part of the data inventory, it can greatly simplify the process of creating this disclosure.  The implementation plan should include a process for updating these disclosures as needed to reflect a rolling 12-month period.

b. The Right to Access and Portability

Another key requirement is the implementation of a process to respond to verifiable requests from data subjects for the following information covering the 12-month period preceding the request date.  Companies will need to provide information including:

  • The categories of personal information collected about that person
  • The categories of sources from which the personal information is collected
  • The business/commercial purpose for collecting/selling personal information
  • The categories of third parties to which their personal information is shared/disclosed
  • The specific data elements collected about that person for the 12-month period preceding the request date (this could be read to conflict with data destruction policies or data minimization best practices, but I suspect that destruction policies or data minimization best practices will trump this disclosure requirement)
  • If a person’s personal information is sold or is disclosed for a business purpose by your business unit, additional information must be provided

If the data inventory is done right, it can be a source of data for this response (except for the requestor’s specific data elements). Companies must provide at least 2 methods for a person to submit a verifiable request – a toll-free number and website address are both required.  The California Attorney General will release regulations on how to “verify” a request. Information must be disclosed within 45 days of receipt of the request, but there is a process under CCPA to extend the time period to 90 days if necessary. If information is provided electronically, they must be provided in a portable format (e.g., an .xml file). The team that is responsible for fulfilling verified requests should be trained on how to prepare a response, and should test it before the CCPA effective date to validate that the process is working properly. You can’t require someone to have an account with you in order to submit a request. Don’t forget to train your website and customer service personnel on how to handle consumer requests.

Also, if you are a service provider, your clients will look to you to ensure they are able to pull information from your systems necessary for them to comply with the right to access and portability. Don’t overlook including in your compliance plan a review of your customer portal and interfaces (e.g., APIs) to ensure customers are able to satisfy their CCPA compliance obligations.

c. The Right to Deletion

Another key requirement is to implement a process to delete collected personal information of a person if that person submits a verified request for deletion, and to direct your service providers to do the same. Note that this does not apply to third parties with whom information has been shared or disclosed who are not service providers.  As with the right to access and portability, you can’t require someone to have an account with you to exercise this right.

There are many important exclusions to the right of deletion.  These include:

  • Completing a transaction with, providing a good or service requested by or reasonably anticipated under a business relationship with, or otherwise needed to perform a contract with, a person
  • Security purposes
  • Debugging and error resolution
  • Conducting formal research (many conditions apply)
  • “Solely internal uses” that are reasonably aligned with a person’s expectations based on the person’s relationship with the business
  • Compliance with a legal obligation
  • Internal uses in a lawful manner that is compatible with the context in which the person provided the personal information
  • Other limited exceptions under CCPA

d. The Right to Opt Out

This one may be the most challenging for many companies to implement.  It applies if a business “sells” personal information to third parties, or otherwise shares personal information with a third party (e.g., a data sharing agreement).   CCPA appears to provide that an opt-out would not apply to information provided to a company’s own service providers to further the company’s own business purposes, as long as there are certain contractual requirements in place with the service provider.

CCPA requires companies to implement a “Do Not Sell My Personal Information” opt-out page linked to from the homepage footer on a website, and from their mobile apps.  (The description of a person’s rights under CCPA in section (a) above should include a description of the right to opt out.) Creating a process to verify requests (pending guidance from the California Attorney General) is especially important here since opt-out requests can be submitted by a person or that person’s “authorized representative.”  Once a request has been verified, the personal information of the data subject cannot be shared with third parties (e.g., by associating an opt-out flag with the personal information) until the person later revokes the opt-out by giving the business permission to share his or her personal information with third parties. However, you cannot ask for permission for at least 12 months from the opt-out date.  Companies must train their customer service representatives on how to direct persons to exercise their opt-out rights.

e. The Right to Equal Service and Pricing

As part of a CCPA compliance plan, businesses should consider ways to make sure that they do not charge more or otherwise “discriminate” against a person who chooses to exercise one of their CCPA rights.  A business can offer financial incentives to persons for the collection, sale or retention of their personal information, as long as that incentive is not unjust, unreasonable, coercive or usurious.

5. Verify you have CCPA-compliant written contracts in place with service providers and third parties receiving personal information

Personal information governed by CCPA may only be disclosed to a service provider or third party under a written contract. Businesses should work with their internal or external Legal resource to validate that written contracts are in place with all service providers and third parties to which personal information is disclosed, and that there is a valid business purpose for disclosing the personal information. If no written agreement exists, work with your Legal resource to negotiate and execute a CCPA-compliant agreement. For existing written agreements, a CCPA contract addendum will likely be required which adds into the agreement the obligations and commitments required under CCPA. Don’t forget to look at any data sharing with your corporate affiliates which is likely under an inter-company agreement.

6. Prepare for compliance requests where your company is a service provider

If your company is a service provider to other businesses, you should expect to start receiving questions about, and contract amendments/addenda related to, CCPA.  It’s the inverse of #5 above. Consider how to most efficiently handle these requests. Some companies may want to consider whether to have a standard CCPA compliance addendum for use with customers, or to have a CCPA compliance statement on a public facing website that can be referred to as needed.  Work with Sales and account managers to educate them as to why the company cannot accept a customer’s own CCPA addenda, which may include more than just CCPA compliance terms.

 7. Take steps to permit continued use of de-identified personal information

Finally, a CCPA compliance plan should include implementation of appropriate steps as needed so your company can continue to use de-identified personal information (an information record which is not reasonably capable of being identified with, relating to, describing, being associated with or being directly/indirectly linked to the source person) and aggregated personal information (information relating to a group or category of persons from which individual identities have been removed, and which is not linked or reasonably linkable to a person or device).  CCPA talks about de-identified data only with respect to the following requirements, but the same safeguards and processes would likely apply to aggregated personal information.

  • Implement technical safeguards to prohibit re-identification of the person to whom de-identified personal information pertains.
  • Implement business processes that specifically prohibit re-identification of de-identified personal information.
  • Implement business processes to prevent the inadvertent release of de-identified personal information.

Your company can only use de-identified personal information as long as it makes no attempt to re-identify the de-identified personal information (whether or not that attempt is successful).  If your company begins re-identifying personal information, cease any use of de-identified personal information immediately.

8. Review your security procedures and practices, and consider encryption and data redaction options

Finally, business are encouraged to review their security procedures and practices to ensure they are reasonable and appropriate to protect personal information in their possession or control. CCPA creates a private right of action for consumers whose un-encrypted or un-redacted personal information is subject to an unauthorized “access and exfiltration,” theft, or disclosure as the result of a business’s violation of its duty to implement and maintain reasonable security procedures and practices to protect personal information appropriate to the nature of the information. For this private right of action, CCPA specifically uses a different definition of personal information, the one found in California Civil Code § 1798.81.5(d)(1)(A). Here, “personal information” means a person’s first name or first initial and last name coupled with the person’s (i) social security number, (ii) driver’s license number or California identification card number, (iii) account number, credit or debit card number, in combination with any required security code, access code, or password that would permit access to an individual’s financial account, (iv) medical information, and/or (v) health insurance information, where such information is not encrypted or redacted. Any private right of action is sure to spawn a cottage industry of class action lawsuits. If your company collects and/or receives personal information as defined above, consider a review of your company’s security procedures and practices to ensure that they are reasonable and appropriate to protect such personal information given the nature of the information.

In 2016, the California Attorney General issued a Data Breach Report in which the Attorney General stated that “[t]he 20 security controls in the Center for Internet Security’s Critical Security Controls identify a minimum level of information security that all organizations that collect or maintain personal information should meet. The failure to implement all the Controls that apply to an organization’s environment constitutes a lack of reasonable security.” Given this, all companies are encouraged to review the Center for Internet Security’s Critical Security Controls to ensure that they meet the California AG’s minimum definition of “reasonable security.”

The California Attorney General’s report included other recommendations, such as use of multi-factor authentication on consumer-facing online accounts containing sensitive personal information, and the consistent use of strong encryption to protect personal information on laptops, portable devices, and desktop computers. Companies may want to evaluate whether implementing encryption at rest on servers, workstations, and removable media, and/or redacting personal information (e.g., through tokenization and deletion of the source data or another data redaction technique), would make sense as a part of its security procedures and practices.

 

Eric Lambert is counsel for the Transportation division of Trimble Inc., an geospatial solutions provider focused on transforming how work is done across multiple professions throughout the world’s largest industries. He supports the Trimble Transportation Mobility and Trimble Transportation Enterprise business units, leading providers of software and SaaS fleet mobility, communications, and data management solutions for transportation and logistics companies. He is a corporate generalist and proactive problem-solver who specializes in transactional agreements, technology/software/cloud, privacy, marketing and practical risk management. Eric is also a life-long techie, Internet junkie and avid reader of science fiction, and dabbles in a little voice-over work. Any opinions in this post are his own. This post does not constitute, nor should it be construed as, legal advice.

Defend, Indemnify and Hold Harmless: What They Mean and How To Use Them

Posted on by
Reply

Some phrases turn up regularly in contracts, e.g., a party that “represents, warrants and covenants” something; the grant of a “right and license”; a set of “terms and conditions”; and a party owning all “right, title and interest” to something. When drafting, reading and/or interpreting a contract, you may view each of these phrases as a single concept. However, the component terms in these phrases often have different meanings. I have previously written about the differences between representations, warranties and covenants, and why those differences can be extremely important.

A core element of every contract is risk allocation. Most agreements contain risk allocation clauses such as limitation of liability, disclaimer of consequential damages, insurance obligations, and indemnification obligations. A contractual indemnification provision often begins with a statement that a party shall “indemnify, defend and hold harmless” one or more other parties from and against losses, damages, etc. arising from or relating to certain acts, omissions or occurrences. There are three separate and distinct concepts in this phrase – an obligation to indemnify, a duty to defend, and an obligation to hold harmless. Should these always be used together? Or are there circumstances when only one or two should be used, or used separately? Understanding what each of these concepts mean and how to use them strategically (as a whole or in parts) is critical to ensuring an agreement contains the right risk allocation.

Here’s a handy summary chart to differentiate these three concepts:

The obligation to indemnify

An “indemnity” is a core risk shifting provision of a legal contract, obligating one party (the “indemnitor” or the “indemnifying party”) to compensate and reimburse (or “indemnify”) the other party (the “indemnitee” or the “indemnified party”) for certain losses such as monetary costs and expenses (the “indemnified losses”) which arise from, result from or relate to certain acts, omissions or occurrences defined in the contract (the “scope of the indemnity.”) Properly defining the scope of the indemnity and any exclusions to scope, the indemnified parties, and the indemnified losses are especially critical. For example, the scope of an indemnity may include, among other things, the material breach of a representation or warranty; a violation of a law, rule or regulation; a party’s negligent, grossly negligent, and/or willful acts or omissions; a breach of confidentiality or security obligations; and a claim that a product infringes the intellectual property of a third party. Common indemnified losses include attorneys’ fees and costs (whether or not the contract includes a duty to defend), losses, expenses, costs, damages, fines, and penalties.

Indemnification obligations can be either “third party” (protection against damages and losses claimed by a third party and not the other contractual party) or “first party” (protection against damages and losses claimed by the other contractual party). Most parties do not use a first-party agreement in contractual indemnification clauses, preferring that any damages and/or losses claimed by the other contractual party be governed by general breach of contract principles. Some courts have interpreted an indemnity as a third-party indemnity absence express language as to the parties’ intention to cover first party claims.

If you are thinking this sounds a lot like insurance, you’re right – an insurance policy is a form of an indemnity pursuant to which the insurer (the indemnitor) agrees to compensate and reimburse a policy holder (the indemnitee) for losses and damages relating to losses, expenses, or other damages suffered by the policy holder in connection with an indemnified claim. Another important point is that indemnification is not automatic – it requires the indemnitor to accept its obligation to indemnify for a particular claim, or alternatively a finding by a court, arbitrator, or similar that the claim giving rise to the loss or damage was within the scope of the indemnity. For example, if Party A is required to indemnify Party B for third party damages and losses (including attorneys’ fees) arising from Party A’s negligence, and a third party (Party C) sues Party B for damages arising from Party A’s negligence, if the court finds that Party A was negligent, then Party A’s indemnification obligations are triggered. An indemnitor may sometimes contest their obligation to indemnify, which can lead to additional litigation over the obligation to indemnify itself.

The duty to defend

Like indemnity, the duty to defend has its roots in insurance. If you tender a claim to your insurance carrier and the carrier accepts your claim, your carrier will “step into your shoes” to defend you, by either having their in-house attorney handle the matter, or more commonly, by hiring an attorney to defend you against the claim. Similarly, if in a contract you accept a duty to defend the other party in the event that other party receives a claim, is sued, or some has other cause of action or proceeding commenced against it arising from certain specified occurrences, you are agreeing to step into their shoes and be responsible for their defense, whether or not you are also sued. This includes hiring attorneys, retaining experts, retaining e-discovery providers, and taking on other obligations associated with the defense of the claim. A duty to defend includes an obligation to bear the costs of providing the defense such as attorneys’ fees, expert witness fees, electronic discovery fees, court fees, and the like. Keep in mind that the defended party will still need to be involved the defense of the claim. While a party imposing a duty to defend on the other party gives up their ability to defend the claim as they see fit, the cost-shifting generally outweighs the loss of control.

If a party feels it must maintain direct control, e.g., where the reputational risk from a claim is so significant that they want to call the shots or where a party has outside counsel that they feel is essential for a particular type of claim), that party may want to negotiate out a duty to defend and rely solely on the duty to indemnify for reimbursement of incurred defense costs. However, this is often not palatable to indemnitees who insist on a right to defend; the most common argument is that if a party has the obligation to indemnify against costs of a judgment or settlement, that party must have control over the defense of the claim so they control the outcome. Some parties shifting the duty to defend will preserve the right to retain their own counsel at their expense in the procedures section, so they retain some say in the defense strategy. Remember that the damage from a legal proceeding may be non-monetary, e.g., reputational damage, so having a say in the other party’s defense may be important.

When offering a duty to defend and an obligation to indemnify, consider separate but sequential obligations to defend and to indemnify to narrow the scope of both obligations. In this approach, a party would provide a duty to defend the other party against third party claims arising from certain acts, omissions, and occurrences, and with respect to such claims, would indemnify the other party from and against defense costs (attorneys’ fees and other litigation expenses), indemnitor-agreed settlements, and court-awarded damages resulting from such claims. This approach avoids applying the broad categories of “damages, losses, expenses, costs,” etc. to either the duty to defend or the obligation to indemnify, which language often results in a broader risk shifting to the indemnitor than was intended.

The obligation to hold harmless

A hold harmless is an agreement by a party to assume responsibility for, and to not hold the other party liable for, damages resulting from the occurrence of certain acts, circumstances or events. In practice, a hold harmless and an indemnity are functionally equivalent in that both require a party to assume responsibility for losses incurred by another party in connection with certain acts and circumstances. Some argue that while an indemnity shifts losses, a hold harmless shifts both losses and liability. However, shifting liability is often not realistic or achievable. There is no way to assume responsibility for negative and equitable intangible liabilities such as damage to reputation, bad press, a public court record, an injunction or specific performance requirement, etc.; a party can only compensate the other monetarily for such intangible liabilities.

There is one important difference between a hold harmless and an indemnity – a party granting a hold harmless not only shifts risk to itself by taking responsibility for another’s losses associated with that risk, but also assumes the risk directly and agrees not to shift it to the other party even if the other party is ultimately responsible. This may prevent a party granting a hold harmless from shifting liability to the other party if the other party turns out to be the one that caused that liability to occur. Consider whether to ensure contractually that a contractual indemnity and hold harmless excludes liability and damages caused by the other party’s own acts and omissions.

To limit the scope of risk you or your client will accept, consider providing a duty to defend and obligation to indemnify only, and negotiating or leaving out an obligation to hold harmless. If the paramount concern is shifting as much risk as possible, ask for a hold harmless as well. A hold harmless provision can be unilateral (one party retains risk) or mutual (each party retains its own risk associated with certain acts, events or occurrences). Be very careful with mutual indemnity and hold harmless provisions. If you receive an indemnity, granting a hold harmless back for the same acts or circumstances as the two provisions may result in two conflicting provisions that may cancel each other out and leave you without indemnification protections.

Final thoughts

Using the obligation to indemnify, the duty to defend, and the obligation to hold harmless properly in contracts helps ensure a party is taking on the right amount of risk under the relationship. Use of common legal phrases without thinking through whether that use is correct for a particular circumstance may cause your company or your client to take on more risk than they realized, or to give up rights you thought you had. The obligation to indemnify, duty to defend, and obligation to hold harmless also relate directly to, and may be impacted by, the language in other contractual provisions, including indemnification procedures and exclusions; disclaimer of consequential damages; limitation of liability; and insurance provisions. Working with your in-house attorney, or retaining a subject matter expert, is often a worthwhile an investment of time and resources up front to help you navigate the risk allocation terms in your agreement — such as the obligation to indemnify, duty to defend, and obligation to hold harmless — to ensure the risks you take are properly balanced against the expected rewards.

Eric Lambert is counsel for the Transportation division of Trimble Inc., an geospatial solutions provider focused on transforming how work is done across multiple professions throughout the world’s largest industries. He supports the Trimble Transportation Mobility and Trimble Transportation Enterprise business units, leading providers of software and SaaS fleet mobility, communications, and data management solutions for transportation and logistics companies. He is a corporate generalist and proactive problem-solver who specializes in transactional agreements, technology/software/cloud, privacy, marketing and practical risk management. Eric is also a life-long techie, Internet junkie and avid reader of science fiction, and dabbles in a little voice-over work. Any opinions in this post are his own. This post does not constitute, nor should it be construed as, legal advice.

The Promise of, and Legal Issues and Challenges With, Blockchain and Distributed Ledger Technology

Posted on by
Reply

[Originally published in December 2016. Updated on April 7, 2018 to clarify the explanation of blockchain and distributed ledger technology and to add more information on the legal risks and challenges.]

Blockchain and distributed ledger technology is poised to revolutionize many aspects of the world around us. It may prove to be as disruptive and innovative of a force as augmented reality. Many people associate “blockchain” with “Bitcoin,” whose meteoric rise as a cryptocurrency has been well reported. However, they are not one and the same. Bitcoin is an application; blockchain and distributed ledger technology are the methods behind it.  But what is it? How might it change the world? And what legal and other risks does it bring?

What is Distributed Ledger Technology and Blockchain?

The Old – Centralized Ledgers

Centralized ledgers (a database, list, or other information record) have played an important role in commerce for millennia, recording information about things such as physical property, intangible property including financial holdings, and other assets. The most recent innovation in centralized ledgers has been the move from physical ledgers (paper, stone tablets, etc.) to digital ledgers stored electronically. A “centralized ledger” is a ledger maintained and administered in a single, central location (e.g., a computer database stored on a server) accessible by anyone without use of access controls (public) or through an access control layer by persons or organizations with valid login credentials (permissive). This is a “hub-and-spoke” system of data access and management. Centralized ledgers have historically had many benefits, such as minimized data redundancy, limited number of access points to the data for security purposes, centralized administration, and centralized end user access. However, there are also disadvantages, such as greater potential for loss or inaccessibility if the central location suffers a hardware failure or connectivity outage, inability to recover lost data elements, and a dependence on network connectivity to allow access to the ledger by its users.

The New – Distributed Ledgers

Distributed ledgers seek to address these disadvantages by distributing (mirroring) the ledger contents to a network of participants (aka “nodes”) through a software program so that each participant has a complete and identical copy of the ledger, and ensuring all nodes agree on changes to the distributed ledger. Nodes can be individuals, sites, companies/institutions, geographical areas, etc. There is no centralized administrator or “primary node” — if a change is made to one copy of the ledger, that change is automatically propagated to all copies of the ledger in the system based on the rules of the system (called a “consensus algorithm“) which ensures that each distributed copy of the ledger is identical. For example, in Bitcoin, each node uses an algorithm that gives a score to each version of the database, and if a node receives a higher scoring version of the ledger, it adopts the higher scoring version and automatically transmits it to other nodes. Since the distributed ledger software on each node validates each addition to the distributed ledger, it’s extremely difficult to introduce a fraudulent transaction (to put it another way, transactions are audited in real time). Essentially, each node builds an identical version of the distributed ledger using the information it receives from other nodes. The use of distributed models in computing goes back to the origins of the Internet itself — ARPANET, which evolved into what we know today as the Internet, used a distributed model instead of a linear model to manage the transfer of data packets between computer networks.

The software on each node uses cryptographic signatures to verify that it is authorized to view entries in, and make changes to, the distributed ledger. If a participant with rights to modify the ledger (e.g., a digital token giving the participant the right to record a transaction) makes an addition to the ledger using the participant’s secure keys (e.g., a record of a change in ownership of an asset or recording of a new asset), the addition to the ledger is validated by the consensus algorithm and propagated to all mirrored copies of the ledger, which helps to ensure that the distributed ledger is auditable and verifiable. A key difference between centralized and distributed ledgers is that a distributed ledger cannot be forked — if you make a copy of a centralized ledger and store it somewhere else, it will be out of sync with the original copy, whereas each copy of a distributed ledger is kept identical by the client software.

Thus, the five typical characteristics of a distributed ledger are:

  1. distributed copies among nodes via client software;
  2. cryptographic signatures, or “keys,” to allow nodes to view, or add to, the distributed ledger in an auditable and verifiable fashion;
  3. a digital token (better known as a cryptocurrency) used within many distributed ledger networks to allow participants to record ledger entries;
  4. a consensus algorithm to ensure distributed copies of the ledger match among participants without the need for a centralized administrator; and
  5. record permanency so that verified entry accepted to the ledger via the consensus algorithm becomes permanent (it can be corrected via a later addition to the ledger but never removed).

Blockchain

While most press reporting around blockchains equates blockchain with distributed ledgers, a “blockchain” is a specific type of distributed ledger. Each record of new value added to the ledger and each transaction affecting entries in the ledger (which we will collectively call a “block“) includes a timestamp and a cryptographic verification code based on a data signature or “hash” from the previous block which “chains” it to the previous block, forming a “chain of blocks,” or “blockchain,” within the nodes hosting the blockchain. Because each block is cryptographically tied to the previous block via one-way hash, the entire chain is secure – a client can verify that a block in the blockchain validates against the previous block, but it does not allow someone to trace the blockchain forward. If a block in the chain is altered, it changes the hash value and no longer matches the hash stored in later blocks, and the alteration will be rejected by the nodes on the blockchain network. In a blockchain, transactions entered into the system during a specified period of time are bundled together and added to the blockchain as a new block.

There are three primary types of blockchain networks – public, private, and permissioned.

  • Public blockchains allow anyone to participate, and therefore rely more heavily on a strong consensus algorithm to ensure the requisite level of trust between blockchain participants.
  • Private blockchains are limited to a discrete and specified group of participants, are usually small, and may not require use of a cryptocurrency given the inherent level of trust amount private blockchain participants. Private blockchains often do not require a strong consensus algorithm.
  • Permissioned blockchains function much like public blockchains, but require participants have permission to access, transact on, or create new blocks within a blockchain.

Tennessee’s recent state law on blockchain, Tn. Stat. § 47-10-201, contains a good summary definition.  It defines “blockchain technology” as “distributed ledger technology that uses a distributed, decentralized, shared and replicated ledger, which may be public or private, permissioned or permissionless, or driven by tokenized crypto currencies or tokenless.  The data on the ledger is protected with cryptography, is immutable and auditable, and provides an uncensored truth.”  Arizona’s statutory definition (which predates Tennessee’s) is almost identical, except that “crypto currencies” is replaced with “crypto economics.”

Bitcoin is an early, and famous, example of a public blockchain application. Nodes on the Bitcoin blockchain network earn new bitcoins as a reward for solving a cryptographic puzzle through computing power, or “mining.” Transactions for the purchase and sale of bitcoins are also recorded in a block in the Bitcoin blockchain – the blockchain is the public ledger of all Bitcoin transactions. In other blockchain applications, the cyrptocurrency is used as payment for blockchain transactions.

Blockchain and distributed ledger technology is not intended to fully replace existing centralized ledgers such as databases. If a number of parties using different systems need to track something electronically that changes or updates frequently, a distributed ledger may be a good solution. If those needs are not there, or if there is a continuing need to rely on paper transaction records, a centralized ledger continues to be the better choice. Companies need to ensure there is a compelling ROI and business case before implementing a blockchain development and implementation program.

Smart Contracts

An important concept in blockchain technology is the “smart contract.”  Tennessee’s blockchain law defines a smart contract as “an event-driven program, that runs on a distributed, decentralized, shared and replicated ledger and that can take custody over and instruct transfer of assets on that ledger.” Arizona’s definition is identical other than an additional reference to state.  In other words, a smart contract is a computer program encoded into a blockchain that digitally verifies, executes, and/or enforces a contract without the need for human intervention. Where a traditional contract involves risk that a party will fail to perform (e.g., a shipper delivers products but the recipient fails to make payment for the products), smart contracts are self-executing and self-verifying.  In a smart contract for the purchase of goods tracked via blockchain, the seller and buyer would program a smart contract into the blockchain.  Once the delivery record is added to the blockchain, the smart contract automatically validates the shipper’s performance, and automatically triggers payment from the buyer.  Since execution of a smart contract is part of the blockchain, it is permanent once completed. Blockchain protocols such as Ethereum have developed programming languages for smart contracts.

How Might Blockchain and Distributed Ledgers Change the World?

The impact of new technology presents at first as rapidly disruptive (positively and negatively), but often manifests organically and transparently to change the world over time.

Roy Amara, a former president of the Institute of the Future, said that people overestimate a technology’s effect in the short term and underestimate it in the long run, a statement known as “Amara’s Law.” However, I think a corollary is in order – the impact of new technology presents at first as rapidly disruptive (both positively and negatively), but often manifests organically and transparently to change the world over time at a proportional rate to the maturity of the commercially available applications, to consensus on technological standards, and to decreasing costs to implement (and increasing ROI from implementing) the technology in practical business and consumer situations. For example, RFID technology was touted early on as a “change the world” technology, and it has — but most prominently through integration of the technology organic and innovative improvements to supply chain and inventory management. Social networking is viewed by many as a “killer app” (a catalyst that accelerates the adoption of a new technology) which helped usher in the third Age of the Internet, and it has changed the world by changing how we connect with others. Both took years to become pervasive in society and industry.

Blockchain and distributed ledger networks have the potential to change the way many systems and business processes work across industries. Financial and currency transactions are a prominent emerging application of distributed ledger networks and blockchain technology. Since blockchain and distributed ledger networks are platform-agnostic, a distributed ledger could be stored in different hardware/software configurations across different nodes, reducing the need for expensive and time-consuming upgrades to support the distributed model. For example, a permissioned blockchain model could help an organization such as the US Veterans Administration better manage appointment scheduling across a large number of hospitals and clinics (in fact, a resolution was recently passed in the US House of Representatives promoting just that, “to ensure transparency and accountability.” Industry groups, such as the Blockchain in Transport Alliance (BiTA), have sprung up to help develop and promote industry-specific blockchain standards and applications.

The technology could also be used in applications such as better and more secure management of governmental records and other services; tracking tax collection and receipts; managing assets; identity verification; decentralized voting; managing and tracking inventory levels and B2B/B2C product fulfillment; tracking the “data supply chain” for the flow of data among systems; managing system access controls; protection of critical public and privacy infrastructure; tracking royalties due to artists for the use of their works; and use of smart contracts to digitally create, execute, and enforce agreements between parties via blockchain transactions. Distributed ledger networks have the advantage of being more secure as the consensus algorithm makes it considerably difficult for a cyber-attacker to successfully alter the distributed ledger. It could also allow for greater access transparency, a central tenet of many privacy principles, by allowing individuals to access records in the ledger relating to them or containing their information.

Blockchain and Distributed Ledger Legal Risks and Issues

As with any new technology, blockchain creates some interesting conflicts with existing laws and regulations and raises interesting and complex legal and compliance issues.  These include:

Data privacy issues. Distributed ledger technology such as blockchain is inherently designed to share information among every participant and node. If information in a ledger transaction or block contains private information, such as an account number or company confidential information, it will be visible to every user of every node. This is one of the reasons permissive and privacy distributed ledgers are a focus of many companies seeking to innovate in the space. Additionally, as nodes in a distributed ledger network can be geographically disparate, rules and requirements for the transfer of data between geographies may play a major role. It is also possible that at some point in the future decryption technology will evolve to the point where cryptographic signatures used in blockchain and distributed ledgers may no longer be considered safe.

EU personal data and the “Right to be Forgotten.”  In the EU, personal privacy is considered a fundamental human right under the Charter of Fundamental Rights of the European Union. The General Data Protection Regulation (GDPR) is Europe’s new comprehensive data protection framework that as of May 25, 2018 has the force of law in every EU member state.  Under Article 17 of the GDPR, EU data subjects have a “right to be forgotten” which requires companies to erase personal information about that data subject if certain conditions are met (e.g., the personal data is no longer necessary in relation to the purposes for which they were collected or otherwise processed). This right has cropped up in the United States as well, for example, in California for minors under 18 with respect to websites, social media sites, mobile apps, and other online services under Cal. Bus. & Prof. Code § 22580-81.  The “right to be forgotten” creates a direct conflict with the permanency of blockchain.  Companies should factor the “right to be forgotten” into their blockchain development planning, e.g., consider hashing technologies to pseudonymize personal data before encoding it into a blockchain, or other ways to avoid this conflict.  Developments in blockchain and distributed ledger technology may also arise to address this issue.

Jurisdictional issues.  The nodes in a blockchain are often in multiple jurisdictions around the country and/or around the world.  As each is a perfect copy, this can create issues from a jurisdictional perspective.  Legal concepts such as title, contract law, regulatory requirements, etc. differ from jurisdiction to jurisdiction. Does a blockchain network need to comply with the laws of every jurisdiction in which a node is operated?  Cross-border enforcement may become an issue – will one jurisdiction seek to impose its laws on all other nodes of a blockchain network? Blockchain network operators should consider how to specify, in a binding manner, a single choice of law and venue to govern disputes arising from the blockchain network and provide specificity as to compliance requirements.  This jurisdictional issue will likely lead to races between jurisdictions to establish themselves as a “blockchain and distributed ledger friendly” jurisdiction, just as Delaware established itself as a “corporation-friendly” jurisdiction in which many corporations choose to incorporate.  Jurisdictional issues will also impact discovery of data within the digital ledger network, e.g., through subpoenas.  The rules regarding document discovery differ from state to state.  A company seeking to obtain blockchain data through judicial process may have the ability to engage in “forum shopping” to find the most convenient, and friendly, jurisdiction in which to file a document discovery request.

Record retention risks. One of the features of blockchain and distributed ledger networks is record permanency. This permanency may be incompatible with statutory requirements for data to be destroyed and deleted after a period of time, such as credit/debit card data under PCI rules and HR data under various regulatory requirements, and under privacy frameworks such as the GDPR.  It also likely conflicts with a company’s existing record retention policies.  Given these factors, companies looking to introduce blockchain technology should review their record retention policies and create a separate “permanent” category for data stored in blockchain applications.  At the same time, a blockchain is permanent so long as the blockchain itself still exists.

Service Level Agreements.  Many companies include a service level agreement (SLA) in their service agreements, which provides committed minimum service levels at which the service will perform, and often includes remedies for a breach of the SLA.  SLAs are relatively easy to offer when they are limited to a company’s own systems and infrastructure.  However, a blockchain (other than perhaps a small private blockchain) may by its very nature be distributed beyond a company’s own network.  SLAs often exclude from downtime issues outside of its control, e.g., downtime caused by a third party’s hardware or software.  Does a third-party node still fit within this? Many SLAs also address latency, i.e., the time it takes for a system to respond to an instruction. Companies will also need to think about what measure of latency (if any) should apply to transactions via blockchain and other distributed ledgers, and how to address blockchain in their SLAs.

Liability and Force Majeure issues. Companies routinely implement controls (processes and procedures) to manage their systems and operations, which controls may be audited by customers/partners or certified under standards such as SOC 2. But who is accountable for a database distributed across geographies and companies? Use of a distributed ledger system with nodes outside of a company’s systems means ceding some control to an automated process and to a decentralized group of participants in the distributed ledger/blockchain. An error in a record in a distributed ledger becomes permanent and can be corrected but never removed. Is an issue with a third-party node considered a force majeure event which excuses performance under an agreement? Is the type of network (public, private or permissioned) a factor?  Companies will need to think about how blockchain should tie into an agreement’s general force majeure provision, and how to allocate blockchain risk within a contract (through indemnities, limitation of liability, etc.).

Insurance issues.  Any new technology is quickly tested under insurance policies.  Companies will begin to tender claims under their electronic errors and omissions policies, commercial general liability policies, and possibly specialized cyber policies.  As insurance companies build up experience with blockchain claims, companies will likely see new endorsements and exclusions limiting insurance carriers’ liability under standard policies for blockchain-related losses.  This is often closely followed by the emergence of custom policy riders (for additional premium) to provide add-on insurance protection for blockchain-related losses.  Companies implementing blockchain technologies may want to discuss blockchain-related losses with their insurance carriers.

Intellectual property issues.  As with any new technology, there has already been a flood of patent applications by companies “staking their claim” in the brave new frontier of blockchain and distributed ledger. While the core technology is open source, companies have created proprietary advancements in which they may assert patent or other intellectual property rights.  Dozens of companies have already obtained blockchain patents.  Technology and other financial companies have undoubtedly already filed large numbers of blockchain patents that are working their way through the Patent and Trademark Office.  As is often the case with new technologies, there will likely be a flurry of patent infringement lawsuits as new patent holders seek to enforce their exclusive rights to their inventions.  Adopters of blockchain using custom applications or non-standard implementations should be especially sensitive as to whether their application or implementation could potentially be infringing filed or issued blockchain patents.  Consulting external patent counsel knowledgeable in blockchain technology will become more and more important for these types of adopters.

Confidentiality issues. Information placed into a node of a public blockchain – even if that node is within a company’s own servers – is no different than putting code into GitHub. The result is that the information enters the public domain. Even with a private or permissioned blockchain, information encoded into the blockchain becomes visible to all participants with access rights.  A company’s use of a blockchain or distributed ledger to store confidential information, such as information subject to an NDA or the company’s own trade secrets, creates a risk of a breach of confidentiality obligations or loss of trade secret protection.  Companies should consider how to prevent confidential and other sensitive company information from being stored in blockchains in a manner that could result in a breach of confidentiality. Additionally, agreements routinely require the return or destruction of the discloser’s confidential information and other provided data and/or materials upon termination or expiration. An exception for data encoded onto a blockchain must be considered.

Discovery and Subpoenas.  Information encoded into a public blockchain may be considered in the public domain.  When litigation arises, will companies be able to push back on a discovery request encompassing data in a blockchain by stating that it is publicly available?  If a person can find the identity of other nodes in a blockchain network, we may see an increase in subpoenas directed to a node for blockchain data within the copy of the blockchain or digital ledger hosted at that node (possibly based on favorable jurisdiction as noted above). Since every node maintains their own copy of a distributed ledger, and no one node owns or controls the data, this may affect the ability of a company to keep information out of third party hands as they may not have the ability to quash a subpoena directed at an independent node.

Application of existing legal structures to blockchain, smart contracts, and distributed ledgers. As is often the case, one of the challenges for lawyers and others is determining how existing laws and regulations will likely be interpreted to fit new technologies such as blockchain and distributed ledger technology; what new laws and regulations may be coming and how permissive or restrictive they may be; and how enforcement and penalties in connection with the new technologies under both new and existing laws will play out. “Smart contracts” that rely on computer algorithms to establish the formation and performance of contracts may challenge the nature and application of traditional legal principles of contract law such as contract formation and termination, and the traditional focus of laws on the acts of persons (not automated technologies), making it difficult for courts to stretch traditional contract law principles to the new technology.

Emerging laws.  It is axiomatic that law lags technology. The companies that immediately benefit from a new disruptive business method such as blockchain are those which seek to innovate applications of the method to monetize it, obtain a first mover advantage, and ideally seize significant market share for as long as possible. Industry groups and trade associations form to seek to promote it, and legislators take notice (especially given the meteoric rise of bitcoin prices during 2017). Legislators often jump to regulate something they don’t fully understand and whose potential is not fully realized, which can impede development and proliferation of the new technology.  A handful of states (including Arizona, Nevada, Tennessee, Delaware, Illinois, Vermont, and Wyoming) have already adopted blockchain-specific legislation, and this number will likely grow substantially in the next couple of years. Fortunately, the legislation enacted to date appears to support, rather than inhibit, blockchain technology. Other states have introduced or enacted legislation to study blockchain technology.

Disruptive technologies such as blockchain and distributed ledger technology bring both benefits and potential risks. If the benefits outweigh the risks on the whole, the public interest is not served when the legal, regulatory and privacy pendulum swings too far in response. The spread of blockchain and other distributed ledger technologies and applications will be dependent on the creation and fostering of a legal, regulatory, and privacy landscape that fosters innovation in the space.

Eric Lambert is the Commercial Counsel for the Transportation and Logistics division of Trimble Inc., an integrated technology and software provider focused on transforming how work is done across multiple professions throughout the world’s largest industries. He is counsel for the Trimble Transportation Mobility (including PeopleNet, Innovative Software Engineering, and Trimble Oil and Gas Services) and Trimble Transportation Enterprise (including TMW and 10-4 Systems) business units, leading providers of software and SaaS fleet mobility, communications, and data management solutions for transportation and logistics companies. He is a corporate generalist and proactive problem-solver who specializes in transactional agreements, technology/software/cloud, privacy, marketing and practical risk management. Eric is also a life-long techie, Internet junkie and avid reader of science fiction, and dabbles in a little voice-over work. Any opinions in this post are his own. This post does not constitute, nor should it be construed as, legal advice.

Best Efforts, Commercially Reasonable Efforts, and Good Faith Efforts: How They Differ and How to Use Them Effectively

Posted on by
Reply

“Best efforts,” “commercially reasonable efforts,” and “good faith efforts” are three of the most common performance standards used in contracts. For example, Party A may agree to use best efforts to market Party B’s products; Party B may agree to use commercially reasonable efforts to complete a task; or both parties may agree to use good faith efforts to discuss additional business opportunities. Unlike objective performance measures, these three performance standards are highly subjective. What are “best” efforts? What is considered “commercially reasonable?” How do you define “good faith?” Many view these subjective performance standards to be three different levels of performance on a spectrum (good/better/best). However, this perception differs from the reality in the courts where definitions of these standards can differ significantly from jurisdiction to jurisdiction.

Parties find these subjective performance standards convenient where they can’t or do not want to be too specific or objective as to the level of performance required. Contract negotiations can get bogged down when one party insists on a subjective performance standard to which the other party is opposed. Where parties can’t fully agree, a slightly vague subjective standard can be used to “bridge the gap” and let the parties finalize contract terms. However, that’s just papering over a failure to achieve a true “meeting of the minds” on the terms of the agreement. A later disagreement in how to define and apply a subjective performance standard can lead to a foundering of the business relationship, a contract dispute, allegations of breach, and/or litigation or arbitration. Understanding the differences between these subjective performance standards, and knowing when and how to best use them, is therefore critical.

In this article I’ll talk through the commonly perceived differences between these three key subjective performance standards, and cover things to look out for when using these terms. I’ll also discuss why it is important to consider on a case-by-case basis whether including a specific definition for a subjective performance standard or using an objective performance measure may be a better approach.

Defining “best efforts,” “commercially reasonable efforts,” and “good faith efforts”

There is not a lot of case law, or consistency in case law, from which to draw definitions. In other words, there are no universally accepted definitions for these subjective performance standards. Here is how I differentiate them:

Things to consider and watch for when using these standards

Isn’t a “good faith efforts” standard already implied? US contract law has long provided that the performance of every contract is subject to an implied duty of good faith and fair dealing. Given this, every performance obligation in an agreement requires good faith efforts, unless a higher standard for a particular obligation is expressly stated in that agreement. Since good faith efforts is the default, is there any reason to expressly include good faith efforts in an agreement? Yes. A non-breaching party to a contract will want the ability to assert the strongest claims possible. Instead of having to rely on breach of an implied duty as the basis for a claim, a party may prefer to be able to claim a breach of the express terms of the contract as well. If “good faith efforts” are expressly stated, a party may have multiple causes of action in the event of a failure to meet those efforts. Also, as noted above, some courts have held that an express good faith efforts requirement should be interpreted as a higher performance standard.

Consider whether it makes sense to try to add boundaries to a “best efforts” obligation. If your company is on the performing side of a “best efforts” obligation that the other party will not agree to remove, one way to address the uncertainty and subjectiveness of the performance obligation is to “box it” with additional language that puts some boundaries around the obligation and defines which stones must be left unturned. For example, if XYZ asks for language stating “ABC will use best efforts to market XYZ’s product,” consider seeking a revision to “ABC will use best efforts to market XYZ’s product, provided such efforts will not require ABC to incur costs or expenses not expressly contemplated herein which in ABC’s reasonable judgment may negatively impact its business operations and operating results.” This revised language makes clear that in performing to the “best efforts” standard, ABC is not required to incur costs and expenses that could negatively impact it. ABC could also consider whether to add a lower standard to a “best efforts” clause, such as “reasonable best efforts” or “good faith best efforts,” which could lead to a court interpreting the language as a lower standard than best efforts and which ABC can argue more realistically characterizes the efforts to be expended in compliance with that performance obligation.

Avoid using qualifiers which can enhance, or muddy, a subjective performance standard. Consider avoiding adding qualifiers such as “all,” “every,” or “diligent” to a subjective standard e.g., “diligent good faith efforts,” “all commercially reasonable efforts,” or “commercially reasonable efforts to [do x] as soon as feasible.”  Qualifiers can add another layer of subjective complexity, and/or create a more onerous obligation than may have been intended. For example, if “commercially reasonable efforts” by definition does not require a party to leave no stone unturned and does not require continuous performance, requiring “all” or “diligent” commercially reasonable efforts may effectively convert it to a “best efforts” standard.

Subjective performance obligations may not play nicely with revenue recognition rules. Subjective performance standards like “best efforts,” “commercially reasonable efforts,” and “good faith efforts” may mean different minimum levels of effort to different parties. In order to evaluate performance under a contractual obligation, the parties must be able to (1) define the specific obligation to be performed, and (2) objectively measure whether that performance obligation has been satisfied. This is a core tenet of the new revenue recognition rules under ASC 606, which requires a contract to be broken into separate performance obligations so that revenue recognition occurs on a per-performance obligation basis when that performance obligation has been satisfied. Determining when a subjective performance obligation has been satisfied for ASC 606 purposes can be problematic as the parties may not agree when the obligation has been satisfied. It is advisable to try to use objective criteria, and not subjective performance standards, for performance obligations tied to revenue recognition.

Consider whether including a definition or an objective measure would work better

Parties should try to avoid ambiguity in contracts, and seek to use quantifiable and measurable obligations where possible. Using subjective performance standards such as “best efforts,” “commercially reasonable efforts,” and “good faith efforts” is often an easy way to agree on a performance obligation without being too specific on what level of effort is required to achieve it. There are times when using a minimum subjective standard instead of an objective one is a tactical approach in negotiation, such as where your company wants to be able to make an argument that its performance was sufficient without the need to demonstrate satisfaction of an objective measure.

> Consider using definitions. If you do use a subjective performance standard in an agreement, consider whether to include a definition of that standard in the agreement. By defining a standard such as “commercially reasonable efforts,” the parties are fencing in what is considered satisfactory performance of that standard, making it less subjective and easier to gauge performance if a dispute arises as to whether a party has satisfied the associated performance obligation.

> Consider whether an objective measure would work better. In a number of cases, an objective measure such as a maximum time period, a minimum required spend, a minimum number of generated leads or orders, or a minimum service level may make it easier for both parties to determine whether a party has minimally satisfied a performance obligation. Ask the other party what they would consider an acceptable result from the required efforts, and consider making that the contractual measure of minimum acceptable performance. For example, instead of saying that “ABC will use commercially reasonable efforts to generate sales leads during each term of the Agreement,” if the parties agree that 10 leads per year is the minimum acceptable performance, say “ABC will generate a minimum of ten (10) sales leads during each term of the Agreement.” If all ABC generates is 10 leads in a given year and the other party was hoping for more, the other party can choose to exercise its termination rights and find another partner.

Search your contracts and templates for subjective performance standards, and see if any can be replaced with objective measures – it could mean the difference in measuring satisfaction of performance obligations and avoiding costly contract disputes over subjective performance terms.

Eric Lambert has spent most of his legal career working in-house as a proactive problem-solver and business partner. He is a corporate generalist who specializes in transactional agreements, technology/software/e-commerce, privacy, marketing and practical risk management. Any opinions in this post are his own. This post does not constitute, nor should it be construed as, legal advice. He is a technophile and Internet evangelist/enthusiast. In his spare time Eric dabbles in voice-over work and implementing and integrating connected home technologies.

Aggregate Data Clauses – Accept or Push Back?

Posted on by
Reply

Before reflexively rejecting a vendor/provider’s aggregate data clause, determine whether pushing back is really necessary.

More than ever before, data is the driver of business. Companies are inundated with new data on a daily basis, which creates a number of business challenges. One of the more prominent challenges of late has been how best to protect data within a company’s infrastructure from inadvertent and improper access and disclosure. Another important challenge is how best to “mine” data sets through data analytics, the quantitative and qualitative techniques businesses use to analyze data in order to develop business insights, conclusions, strategies, and market trend data in order to provide guidance on operational and strategic business decisions. “Aggregate data” is key to data analytics; companies take existing data, anonymize it by removing any personal or other information that can be used to identify the source of the data, and aggregate it with other anonymized data to create a new set of data on which data analytics can be performed.

The strength of the conclusions and insights learned through data analytics is directly proportional to the amount of source data used. Aggregate data comes from two primary sources: (1) internal data sets within the company’s possession or control, such as transactional data, customer data, server data, etc.; and (2) external data sets such as free online databases of government data (e.g., US Census data) and data available from data brokers who have compiled aggregate data sets for purchase and use by businesses.

To ensure businesses have the right to use customer data in their possession for data analytics purposes, SaaS, cloud, software, and other technology agreements often contain an aggregate data clause. This clause gives a vendor/provider the right to compile, collect, and use aggregate data from customer information for the vendor/provider’s own business purposes. Many vendors/providers work hard to craft an aggregate data clause that fairly and adequately protects their data sources. Before reflexively rejecting a vendor/provider’s aggregate data clause, consider the analysis and questions in this article to determine whether pushing back is really necessary to protect your company’s interests.

The vendor/provider’s perspective

Customers often push back on aggregate data clauses for a variety of reasons, such as “it’s our policy not to give this right,” “why should you benefit from our data?” and “how can you guarantee someone won’t be able to figure out it’s us?” On the other side, a vendor or provider may argue that the aggregate data clause is a “table stakes” provision in their agreement. Under this argument, analytical data is used to generate macro-level insights which benefit both the vendor/provider and its customers, and as long as it is used in a way that does not identify a specific customer or client there is no potential harm to the customer in allowing its use for data analytics. Additionally, many vendors argue that the systems used to anonymize and aggregate data do not allow for exceptions on a per-customer basis. Additionally, vendors/providers often share insights and other conclusions drawn from data analytics with their customers and clients, e.g., through client alerts, newsletters, conferences, etc., and therefore clients benefit from allowing their data to be used in the vendor/provider’s data analytics efforts. Data analytics are often a critical part of a vendor/provider’s business plans and operations, and access to client data for analytics purposes is baked into the cost of using the service.

Is the aggregate data clause well-drafted and balanced?

Many vendors/providers take the time to craft an aggregate data clause that is fair and does not overreach. As long as the vendor/provider has protected the customer’s rights and interests in the underlying customer data, the use of a customer’s data for analytics purposes may be perfectly acceptable as a part of the overall contractual bargain between the parties. A well-drafted clause usually contains the following core provisions:

  • Grant of rights – A right for the vendor/provider to compile, collect, copy, modify, publish and use anonymous and aggregate data generated from or based on customer’s data and/or customer’s use of its services, for analytical and other business purposes. This is the heart of the clause. This clause gives the vendor/provider the right to combine aggregate data from multiple internal and external data sources (other customers, public data, etc.).
  • Protection of source data – A commitment that the customer will not be identified as the source of the aggregate data. While this is really restating that the data will be “anonymous,” some customers may want a more express commitment that the aggregate data can’t be traced back to them. I’ll talk more about this later in this article.
  • Scope of usage right – Language making clear either that the vendor/provider will own the aggregate data it generates (giving it the right to use it beyond the end of the customer agreement), or that its aggregate data rights take precedence over obligations with respect to the return or destruction of customer data. The common vendor/provider reason for this is that aggregate data, which cannot be used to identify the customer, is separate and distinct from customer data which remains the property (and usually the Confidential Information) of the customer under the customer agreement. Additionally, the vendor/provider often has no way to later identify and remove the aggregate data given that it has been anonymized.

Things to watch for

When reviewing an aggregate data clause, keep the following in mind:

Protection of the company’s identity. While language ensuring that a customer is not identified as the source of aggregate data works for many customers, it may not be sufficient for all. Saying a customer is not identified as the source of aggregate data (i.e., the vendor/provider will not disclose its data sources) is not the same as saying that the customer is not identifiable as the source. Consider a customer with significant market share in a given industry, or which is one of the largest customers of a vendor/provider. While the vendor/provider may not disclose its data sources (so the customer is not identified), third parties may still be able to deduce the source of the data if one company’s data forms the majority of the data set. Customers that are significant market players, or which are/may be one of a vendor’s larger clients, may want to ensure the aggregate data clause ensures the customer is not identified or identifiable as the source of the data, which puts the onus on the vendor/provider to ensure the customer’s identity is neither disclosed nor able to be deduced.

Ownership of aggregate data vs. underlying data. As long as the customer is comfortable that aggregate data generated from customer data or system usage cannot be used to identify or re-identify the customer, a customer may not have an issue with a vendor/provider treating aggregate data as separate and distinct from the customer’s data. Vendors/providers view their aggregate data set as their proprietary information and key to their data analytics efforts. However, a well-drafted aggregate data clause should not give the vendor/provider any rights to the underlying data other than to use it to generate aggregate data and data analytics.

Scope of aggregate data usage rights. There are two ways customer data can be used for analytics purposes – (1) to generate anonymized, aggregate data which is then used for data analytics purposes; or (2) to run data analytics on customer data, aggregate the results with analytics on other customer data, and ensure the resulting insights and conclusions are anonymized. Customers may be more comfortable with (1) than (2), but as long as the vendor/provider is complying with its confidentiality and security obligations under the vendor/provider agreement both data analytics approaches may be acceptable. With respect to (2), customers may want to ask whether the vendor/provider uses a third party for data analytics purposes, and if so determine whether they want to ensure the third-party provider is contractually obligated to maintain the confidentiality and security of customer data and if the vendor/provider will accept responsibility for any failure by the third party to maintain such confidentiality and security.

Use of Aggregate Data. Some customers may be uncomfortable with the idea that their data may be used indirectly through data analytics to provide a benefit to their competitors. It’s important to remember that data analytics is at a base level a community-based approach – if the whole community (e.g., all customers) allows its data be used for analytics, the insights and conclusions drawn will benefit the entire community. If this is a concern, talk to your vendor/provider about it to see how they plan to use information learned through analytics on aggregate data.

Duration of aggregate data clause usage rights. Almost every vendor/provider agreement requires that the rights to use and process customer data ends when the agreement terminates or expires. However, vendors/providers want their rights to use aggregate data to survive the termination or expiration of the agreement. A customer’s instinct may be to push back on the duration of aggregate data usage rights, arguing that the right to use aggregate data generated from the customer data should be coterminous with the customer agreement. However, if the data has truly been anonymized and aggregated, there is likely no way for a vendor/provider to reverse engineer which aggregate data came from which customer’s data. This is why many vendors/providers cannot agree to language requiring them to cease using aggregate data generated from a customer’s source data at the end of the customer relationship. One approach customers can consider is to ask vendors/providers when they consider aggregate data to be “stale” and at what point they cease using aged aggregate data, and whether they can agree to state that contractually.

Positioning an objection to the aggregate data clause. As noted earlier, the right to use data for analytics purposes is considered to be a cost of using a vendor/provider’s software or service and a “table stakes” provision for the vendor/provider, and the ability to use data for analytics purposes is already baked into the cost of the software or service. Some customers may feel this is not sufficient consideration for the right to use their data for analytics purposes. If that is the case, customers may want to consider whether to leverage an objection to the aggregate data clause as a “red herring” to obtain other concessions in the agreement (e.g., a price discount, a “give” on another contract term, or an additional service or add-on provided at no additional charge).

The GDPR view on use of aggregate data

The European Union’s new General Data Protection Regulation (GDPR), which becomes effective on May 25, 2018, makes a significant change to the ability to use personal data of EU data subjects for analytics purposes. Under the GDPR, a blanket consent for data processing purposes is no longer permitted – consent to use data must be specific and unambiguous. Unfortunately, this directly conflicts with data analytics, as the ways a data set will be analyzed may not be fully known at the time consent is obtained, and there is no right to “grandfather in” existing aggregate data sets. Simply saying the data will be used for analytics purposes is not specific enough.

Fortunately, the GDPR provides a mechanism for the continued use of aggregate data for analytics purposes without the need to obtain prior data subject consent – Pseudonymization and Data Protection by Default. Pseudonymization and data protection principles should be applied at the earliest possible point following acquisition of the data, and vendors/providers must affirmatively take data protection steps to make use of personal data

  • Pseudonymization – Pseudonymization is a method to separate data from the ability to link that data to an individual. This is a step beyond standard tokenization using static, or persistent, identifiers which can be used to re-link the data with the data source.
  • Data Protection by Default – This is a very stringent implementation of the “privacy by design” concept. Data protection should be enabled by default (e.g., an option in an app to share data with a third party should default to off).

 

Data analytics is an important part of every company’s “big data” strategy.  Well-crafted aggregate data clauses give vendors and providers the ability to leverage as much data as possible for analytics purposes while protecting their customers.  While there are reasons to push back on aggregate data clauses, they should not result in a negotiation impasse. Work with your vendors and providers to come up with language that works for both parties.

Eric Lambert has spent most of his legal career working in-house as a proactive problem-solver and business partner. He is a corporate generalist who specializes in transactional agreements, technology/software/e-commerce, privacy, marketing and practical risk management. Any opinions in this post are his own. This post does not constitute, nor should it be construed as, legal advice. He is a technophile and Internet evangelist/enthusiast. In his spare time Eric dabbles in voice-over work and implementing and integrating connected home technologies.

Use the Right Intellectual Property Contract Terms To Protect Against IP Risk

Posted on by
Reply

In most technology and service agreements, one or both parties use or license the other party’s intellectual property (IP), or one party uses or licenses its own intellectual property for the other party’s benefit. However, using or benefiting from another party’s IP carries certain risks, including the risk of an infringement claim, ownership or licensing disputes, open source software, and risks arising from a bankruptcy of the IP owner/licensor.  Where managing the risks from that IP usage is important, having the right contract clauses in place to shift and mitigate this risk can be critical.

There are a number of contract clauses that can be employed to manage and shift IP risk. Two contract clauses in particular – the IP representation/warranty and the IP indemnity – may seem complimentary but can expose a party to unintended liability if used together.

IP Representation/Warranty and IP Indemnity

There are two clauses which can shift the risk of intellectual property infringement – an express representation/warranty of non-infringement and an indemnity against non-infringement. (I will not cover implied warranties of non-infringement under the Uniform Commercial Code, which are very frequently disclaimed in technology and service agreements.)

A representation/warranty of non-infringement is a statement of fact (rep) or statement or promise of condition (warranty) that intellectual property licensed and/or used does not infringe the intellectual property or other proprietary rights of third parties. An IP rep/warranty may be knowledge-qualified, i.e., “to the best of [owner/licensor’s] knowledge.” An IP rep/warranty allows the IP owner/licensor to stand behind its intellectual property, and allows the IP user/licensee to assert an “innocent infringer” defense to certain IP claims. However, like other reps and warranties, there are potentially meaningful consequences if they are breached. Like other breaches of representations, a breach could give rise to a right to void the contract and rescission damages.  Like other warranties, a breach can give rise to contract remedies, a right to withhold or cease performance under the agreement, and/or a right to terminate the agreement for cause.  The user/licensee is required to prove damages resulting from a breach of an IP representation or warranty.

An intellectual property indemnification is an obligation to defend, indemnify, and hold harmless the other party from and against losses, damages, and expenses arising or resulting from a third-party IP infringement claim. (Most service providers avoid first-party IP indemnity clauses, as they are effectively an insurance clause.)  This can be a standalone IP indemnity clause, or an indemnification obligation for breaches of reps/warranties where the agreement contains an IP rep/warranty. As it’s very difficult for an IP user/licensee to determine or mitigate the risk of infringement itself, the IP indemnity allocates this risk to the owner/licensor (subject to the limitation of liability) without the need for the user/licensee to prove damages or other losses. Watch the geographic scope of the indemnity to ensure it matches where the IP will be used – if it’s limited to US patents/trademarks, for example, a user/licensee would not be protected from a claim that their use violates an EU patent. IP indemnification clauses usually include procedures for tendering a claim for defense and language governing who controls the defense, assistance provided by the indemnified party, and settlement of an indemnified claim. A major benefit of an IP indemnity is that the indemnified party does not have to incur or prove damages resulting from an IP infringement claim first; as long as an indemnified claim is brought against the indemnified party, the indemnification obligations apply. As long as the indemnifying party complies with its defense and indemnification obligations, the indemnified party does not have a right to terminate the agreement.

Service providers will often put contours around the scope of the intellectual property indemnity by including limitations to the obligation to indemnify based on certain acts or omissions of the indemnified party. These include where the user/licensee uses IP outside the scope of the license or terms; where the user/licensee modifies the IP other than as authorized by the IP owner/licensor; where the infringement claim results from the combination of the IP with other products or technology not provided by the IP owner/licensor; and where the user/licensee fails to accept or use an updated version of a product or service provided by the IP owner/licensor which has been modified to be non-infringing. Some parties also exclude IP protection where the claim results from open-source software used in their products or systems. One thing to watch for is whether the exclusions are comparative (claims are excluded “to the extent” that an exception applies) or absolute (if any of the exceptions applies, indemnification is not provided).

Savvy service providers and IP licensors understand that including both of these clauses into an agreement can have unintended consequences, such as the potential for remedy “double-dipping.” If a contract contains both an IP indemnity and IP warranty protecting Party B, and a third-party IP claim is asserted against Party B, Party B may be able to both assert a breach of rep/warranty claim and seek damages for breach of the warranty or seek to terminate the agreement for cause, while also tendering the third party claim to Party A for defense and indemnification. Because of this, many licensors and vendors will offer an IP indemnity, but not an IP warranty. However, this eliminates the ability for the user/licensee to rely on the rep/warranty as an innocent infringer. If both the rep/warranty and indemnity are used, one approach to harmonizing them is to add language to the IP warranty stating that the sole and exclusive remedy for breach of the IP warranty is indemnification pursuant to the IP indemnity. This gives the user/licensee the “innocent infringer” benefits of the IP warranty protection as well as the IP indemnity protection, while ensuring that a breach of the IP warranty does not result in a claim outside of indemnification obligations.

Other Intellectual Property Risk Protections

In addition to IP reps/warranties and IP indemnities, there are other contractual protections which can be used to protect against IP risk.

Indemnification Remedy Clause

Where infringement occurs, the IP user/licensee often wants more than just to be protected — they want the right to keep using the IP for the duration of the agreement. In the event of actual infringement, neither an IP rep/warranty nor IP indemnity forces the IP owner/licensor to remedy the infringement. This is why many agreements include an additional IP infringement remedy clause which generally commits an IP owner/licensor facing a claim or judgment of IP infringement to obtain the right to continue to use the impacted IP, to modify the IP so that it is non-infringing, or to replace the impacted IP with a non-infringing alternative. In some cases, if none of the remedies are feasible, one or both parties may be given the right to terminate the agreement; where a termination right exists, users/licensees should consider whether to ask for a prorated refund of license/usage fees for the remaining terminated period of the agreement. Watch for language on the timing of the remedy – in most cases, it’s when the indemnifying party is found to be infringing by a court of competent jurisdiction (and not when the claim is first asserted), which generally does not impact the user/licensee as the defense and indemnification obligations should apply prior to that point.

Allocation of risk (limitation of liability) Cause

While an IP indemnity and rep/warranty shifts risk to the IP owner/licensor, the amount of risk shifted is allocated between the parties through the limitation of liability clause. Is the indemnifying party willing to provide uncapped liability for its IP indemnification obligations? Some service providers have not priced unlimited liability into its fees, or is unwilling to provide uncapped liability as a policy or due to insurance limitations. The user/licensee usually wants to negotiate the broadest liability cap possible; one common compromise is to negotiate a “super-cap” for IP indemnification obligations above the base limitation on direct damages but short of uncapped.

It’s important to also look at the disclaimer of consequential damages. An indemnified claim can include consequential damages as part of the third-party claim (e.g., lost profits).  If the disclaimer of consequential damages does not specifically exclude indemnification obligations, any such damages claimed by a third party may not be indemnifiable which may not be what one or both parties want.  It’s important to note that there is a significant difference between third-party consequential damages awarded in connection with an indemnified claim, and first-party consequential damages related to an indemnified claim (e.g., the indemnifying party should not have to pay for a company’s lost profits due to an executive having to travel and participate in a deposition in connection with an indemnified claim). An exclusion to the disclaimer of consequential damages for third party damages awarded in connection with, or included in the settlement of, an indemnified claim may provide a finer point on the exclusion.

IP Ownership Clause

Another contract provision which can be leveraged to mitigate IP risk is the IP ownership clause, which addresses ownership of each party’s pre-existing IP as well as any new IP created in connection with the agreement. This clause is ideally located up front in a base agreement between the parties, but sometimes will be placed in a Statement of Work (“SOW”) or other ancillary document instead (order of precedence language in the base agreement can be critically important in that case). Ensure that each party retains ownership of its own IP (except to the extent ownership is transferred to the other party), and that each party is prohibited (to the extent permitted by law) from reverse engineering, disassembling, de-compiling, creating derivative works from, renting, selling, leasing, acting as a service bureau regarding, or otherwise attempting to learn the source code of the other party’s IP. If neither company will acquire ownership rights to the other’s IP (even IP created in connection with the agreement), make sure the ownership clause clearly covers this.  If one company will transfer ownership of developed IP (a “deliverable”) to the other, ensure the agreement clearly defines the deliverable and states that the deliverable is considered “works made for hire” as defined in the US Copyright Act, and consider adding language regarding transfer and assignment of the IP rights in and to the deliverables (which may be tied to payment for the deliverable). If a deliverable contains the developer’s pre-existing IP, consider asking for a perpetual, irrevocable, worldwide right and license to sue the pre-existing IP as part of the deliverable (this may cause the IP indemnity to survive in perpetuity).

IP Insurance Clause

Another way to mitigate and shift the risk arising from IP is through intellectual property insurance. IP insurance can be obtained through specialized policies such as a cyber liability policy and media liability policy. Coverage for IP infringement claims may not be available under comprehensive general liability (CGL) coverage – check your policy or walk through coverage with your insurance broker to ensure you understand what your IP insurance policies (or typical policies) cover and don’t cover. Users/licensees may want to ask the IP owner/licensor about IP insurance they carry, and request that the owner/licensor be obligated to maintain their insurance and protect the user/licensee under the policy, e.g., by tying the contractual limitation of liability to the policy coverage.

Open source software Clause

In many cases, companies use open source software (“OSS”) in their IP. There are a number of good reasons companies do this, including lower costs, better quality, and a large support community. As IP owners/licensors did not create the OSS they use, many will disclaim OSS from IP representations, warranties, and indemnities. However, there are risks to OSS usage. For example, under some OSS license types, software which uses OSS governed by one of those licenses becomes governed by that same license, which can include requirements to disclose the source code upon request or other limitations. Users/licensees may want to consider including an OSS representation/warranty that any IP or other deliverables provided to it will not contain open source software which has not been disclosed in the agreement or a SOW.

Rights in Bankruptcy (§ 365(n)) Clause

Licensees under software license agreements have a special tool for mitigating risk arising from a bankruptcy of the software licensor. When a company enters bankruptcy, the licensee (or debtor-in-possession) has certain rights to “affirm” or “reject” the debtor’s executory contracts, including some license agreements. 11 U.S.C § 365(n) gives licensees certain rights to continue to use licensed software in the event of the bankruptcy of the software licensor. To ensure these protections are available, consider including a clause in the agreement protecting the licensee’s rights under this section.

Software Escrow Clause

Finally, consider whether to include a contractual requirement for the owner/licensor to escrow licensed software.  For more on software escrow, please see my earlier post on software escrow.

An earlier version of this post first appeared as an article on my blog, Notes from the Trenches.

Eric Lambert has spent most of his legal career working in-house as a proactive problem-solver and business partner. He specializes in transactional agreements, technology/software/e-commerce, privacy, marketing, compliance and practical risk management, and is a technophile and Internet evangelist/enthusiast. In his spare time Eric dabbles in voice-over work and implementing and integrating connected home technologies. Any opinions in this post are his own. This post does not constitute, nor should it be construed as, legal advice.

The What, Why and How of SLAs, aka Service Level Agreements (part 2)

Posted on by
Reply

Every company uses technology vendors, such as Software-as-a-Service providers, to provide critical components of their business operations. One pervasive issue in technology vendor agreements is the vendor’s commitment to the levels of service the customer will receive.  A representation to use commercially reasonable efforts to correct product defects or nonconformity with product documentation may not be sufficient for a customer relying on a technology vendor’s service for a mission-critical portion of its business. In this situation, the vendor may offer (and/or a customer may require) a contractual commitment as to the vendor’s levels of service and performance, typically called a “Service Level Agreement” or “SLA.” Service Level Agreements (SLAs) ensure there is a meeting of the minds between a vendor and its customer on the minimum service levels to be provided by that vendor.

In Part 1 of this post, I walked through uptime and issue resolution SLAs.  In this second part, I cover other types of technology SLA commitments, SLA remedies, and other things to watch for.

Other Types of Commitments in SLAs

Other common types of SLAs in technology agreements include latency SLAs and customer service SLAs.

Latency SLAs. “Latency” is the time it takes for a server to receive a server request, process it, and send a response. For example, when you load a webpage, a server request is sent to a web server to deliver the webpage, the server processes the request, and sends a response with the code to render the page in the user’s web browser. Latency can be affected by a number of factors, including the geographic location of servers, network/Internet capacity, and server optimization. For companies using a vendor to provide services as part of its client-facing systems (e.g., an address verification service), minimizing latency to ensure a high level of performance is critical. A latency SLA is a commitment to a maximum roundtrip response time for a vendor server request. Latency SLAs typically exclude the time it takes to get from the customer’s server to the boundary of the vendor’s network, and vice versa (as this is outside of the vendor’s control).

Customer Service SLAs. In some vendor relationships, ensuring the prompt provision of customer support is a critical component of the relationship. For example, if a vendor is providing support to a customer’s clients or employees, or is providing level 2 escalation support, customer support SLA commitments may be important to the customer to ensure a high level of service.  Customer support commitments often include commitments on time to first response (the time from the submission of a request to the time an agent opens the support ticket to begin working on it); time to resolution (total time needed to resolve the issue); average speed to answer (the percent of calls answered within a maximum time, e.g., 85% of calls within 30 minutes, or percent of emails answered within a maximum time, e.g., 90% of emails within 4 business hours); and/or abandonment rate (the maximum number of calls being abandoned in queue before a support agent picks up the call).

SLA Remedies

In order to ensure the service level commitments made by a vendor have teeth, the SLA should have remedies available to the customer in the event of a failure to meet one or more SLA commitments. The remedies are often the most heavily negotiated section of the SLA. There are a variety of remedies that can be applied in the event of a SLA failure.

Service Credits. One of the more common forms of remedy is a service credit, often a percentage of fees paid by the customer for the period in which the SLA failure occurred.  For example, if a vendor fails to meet a 99.9% monthly SLA, a service credit equal to a percentage of the monthly fees paid by the customer would be applied to the next monthly invoice.  A credit is often provided on a tiered basis, up to 100% of the fees for the relevant period based on the size of the SLA miss. Vendors may want to include language ensuring that if multiple credits are available for the same reporting period (e.g., a credit for failure to meet the uptime SLA as well as the issue resolution SLA), only the greater credit will apply.  The credit is usually applied to the next invoice, or if there will be no additional invoice, paid directly to the customer.  For a service credit related to an uptime SLA commitment, instead of a percentage of fees some vendors will offer a credit equal to the fees earned by the vendor during the period of time during which the Service was unavailable during the previous measurement period (or an average of the amount during previous measurement periods), under the theory that the credit is an accurate reflection of the actual fees that would have been earned by the vendor had the service been available in compliance with the SLA.  Customers should carefully consider what fees are used to calculate the credit – customers will want this to be as inclusive as possible.

Termination. In the event of a SLA failure, another remedy commonly offered by vendors is a right to terminate. Vendors typically put restrictions around the exercise of this right, e.g., termination is the sole and exclusive remedy available; termination is limited to the service subject to the SLA failure, not the entire service agreement; it is offered on a “use it or lose it” right which can only be exercised for a period of time following the measurement period in which the SLA failure giving rise to the termination right arose; or the right to terminate is only triggered by multiple failures, such as failure to meet its SLA commitments in three (3) consecutive months or any two (2) out of three (3) consecutive calendar quarters. Customers should carefully consider whether the limits on these rights are appropriate (e.g., ensure that “sole and exclusive remedy” applies only to a SLA failure, and would not preclude the customer enforcing its rights and remedies for any other breaches of the vendor agreement; ensure a right to terminate extends to the entire service agreement if the affected service component is a significant portion of the value of the relationship to the customer; etc.)

Other creative remedies. Vendors and customers should consider whether other creative remedies for a breach of the SLA, such as waiver of fee minimums, waiver or imposition of other contractual obligations, or provision of additional services (e.g., a certain number of free hours of professional services), may be an appropriate remedy for the customer and an appropriate motivator for the vendor to meet its SLA commitments.

Closing Thoughts – Things to Watch For

  • Remember that most vendors are trying to provide as close to 100% uptime as possible, and the best possible service they can to their clients. A SLA is intended to be a floor on performance, not a ceiling.
  • Some vendors do not include a SLA in their standard service agreement, instead letting customers ask for one. In my experience, less customers will ask for a SLA than you’d think.  It’s always a good idea to ask a vendor to ensure they include their SLA with the service agreement at the outset of the contract negotiation process.
  • If the vendor will not agree to include a SLA, ask them why.
    • In some cases, vendors will not provide a SLA with credits to all but their largest clients, relying on the fact that as a multi-tenant platform all clients receive the benefit of the SLAs provided to their largest clients. In this event, customers should consider whether to fight for a direct SLA or rely on their commitments to larger clients (which commitments may change over time).
    • If you can’t get a SLA from a vendor, customers should consider whether to push for a termination for convenience right (and refund of prepaid but unaccrued fees) in the event they are dissatisfied with the service levels they are receiving from the vendor.
    • Customers should also ask whether the service is truly a mission-critical service. If not, it may be worth considering how hard to fight for the SLA, or if the customer can offer to concede the SLA to win on another open negotiation point of greater importance.
  • Customers should watch for language in the vendor agreement that gives the vendor the right to unilaterally change terms of the agreement, instead of having changes mutually agreed upon. This unilateral right is often broad enough to allow a vendor to change the terms of the SLA as well. If so, customers may seek to limit the scope to exclude the SLA, or ensure that the agreement includes a termination right as described above.

Eric Lambert has spent most of his legal career working in-house as a proactive problem-solver and business partner. He specializes in transactional agreements, technology/software/e-commerce, privacy, marketing and practical risk management. Any opinions in this post are his own. This post does not constitute, nor should it be construed as, legal advice. He is a technophile and Internet evangelist/enthusiast. In his spare time Eric dabbles in voice-over work and implementing and integrating connected home technologies.

The What, Why and How of SLAs, aka Service Level Agreements (part 1)

Posted on by
Reply

Every company uses technology vendors, such as Software-as-a-Service providers, to provide critical components of their business operations. One pervasive issue in technology vendor agreements is the vendor’s commitment to the levels of service the customer will receive.  A representation to use commercially reasonable efforts to correct product defects or nonconformity with product documentation may not be sufficient for a customer relying on a technology vendor’s service for a mission-critical portion of its business. In this situation, the vendor may offer (and/or a customer may require) a contractual commitment as to the vendor’s levels of service and performance, typically called a “Service Level Agreement” or “SLA.” Service Level Agreements (SLAs) ensure there is a meeting of the minds between a vendor and its customer on the minimum service levels to be provided by that vendor.

At a high level, a SLA does three things:

  1. Describes the types of minimum commitments the vendor will make with respect to levels of service provided by the vendor;
  2. Describes the metrics by which the service level commitments will be measured; and
  3. Describes the rights and remedies available to the customer if the vendor fails to meet their commitments.

In many cases, a SLA is presented as an exhibit or appendix to the vendor agreement (and not a separate agreement). In others, a SLA may be presented as a separate document available on a vendor’s website.  Think of the former as a customer-level SLA which is stated directly in (and quite often negotiated on a customer-by-customer basis as part of) the service agreement with that customer, and the latter as a service-level SLA which the vendor wants to apply equally to every user of its service.

In this two-part post, I’ll explain the contents of, reasons for, and important tips and tricks around technology SLAs.  Part 1 will cover uptime and issue resolution SLAs.  Part 2 will cover other types of technology SLA commitments, SLA remedies, and other things to watch for.

Common types of commitments in SLAs

The most common types of commitments found in technology SLAs are the uptime commitment and the issue resolution commitment.

Uptime SLA Commitment

An uptime commitment is generally provided in connection with online services, databases, and other systems or platforms (a “Service”). A technology vendor will commit to a minimum percentage of Service availability during specified measurement periods.  This percentage is typically made up of nines – e.g., 99% (“two nines”), 99.9% (“three nines”), 99.99% (“four nines”), 99.999% (“five nines”), etc.  Some SLAs will use “.5” instead of “.9”, for example, 99.5% or 99.95%”.   Uptime is typically calculated as follows:

(total minutes in the measurement period - minutes of Downtime in that period) / Total minutes in the measurement period

Definitions are key. The right definitions can make all the difference in the effectiveness of an uptime SLA commitment. Vendors may gravitate towards a narrower definition of “Downtime” (also called “Unavailability” in some SLAs) to ensure they are able to meet their uptime commitment, e.g., by excluding a slowdown that makes the Service hard (but not impossible) to use. Customers should look carefully at this definition to ensure it covers any situation in which they cannot receive substantially all of the value of the Service. For example, consider the difference between Unavailability/Downtime as a period of time during which the Service fails to respond or resolve, versus a period of time during which a material (or non-material) function of the service is unavailable. The SLA should define when the period of Unavailability/Downtime starts and ends, e.g., starting when the vendor first learns of the issue, and ending when the Service is substantially restored or a workaround is in place; customers should look at this carefully to ensure it can be objectively measured.

Mind the measurement period. Some vendors prefer a longer (e.g., quarterly) measurement period, as a longer measurement period reduces the chance a downtime event will cause a vendor to miss its uptime commitment. Customers generally want the period to be shorter, e.g., monthly.

Consider whether the uptime percentage makes sense in real numbers. Take the time to actually calculate how much downtime is allowed under the SLA – you may be surprised. For a month with 30 days:

  • 99% uptime = 432 minutes (7 hours, 12 minutes) of downtime that month
  • 99.5% uptime = 216 minutes (3 hours, 36 minutes) of downtime that month
  • 99.9% uptime = 43.2 minutes of downtime that month
  • 99.99% uptime = 4.32 minutes of downtime that month

One critical question customers should ask is whether a Service is mission-critical to its business.  If it’s not, a lower minimum uptime percentage may be acceptable for that service.

Some vendors may offer a lower uptime commitment outside of business hours, e.g., 99.9% from 6am to 10pm weekdays, and 99% all other times. Again, as long as this works for a customer’s business (e.g., the customer is not as concerned with downtime off-hours), this may be fine, but it can make it harder to calculate.

Ensure the Unavailability/Downtime exclusions are appropriate. Uptime SLAs generally exclude certain events from downtime even though the Service may not be available as a result of those events. These typically include unavailability due to a force majeure event or an event beyond the vendor’s reasonable control; unavailability due to the equipment, software, network or infrastructure of the customer or their end users; and scheduled maintenance.  Vendors will often seek to exclude a de minimis period of Unavailability/Downtime (e.g., less than 5/10/15 minutes), which is often tied to the internal monitoring tool used by the vendor to watch for Service unavailability/downtime. If a vendor wouldn’t know if a 4-minute outage between service pings even occurred, it would argue that the outage should not count towards the uptime commitment.

Customers should make sure there are appropriate limits to these exclusions (e.g., force majeure events are excluded provided the vendor has taken commercially reasonable steps to mitigate the effects of such events consistent with industry best practices; scheduled maintenance is excluded provided a reasonable amount of advance written notice is provided.  Customers should watch out for overbroad SLAs that try to exclude maintenance generally (including emergency maintenance).  Customers may also want to ensure uptime SLAs include a commitment to take reasonable industry-standard precautions to minimize the risk of downtime (e.g., use of no less than industry standard anti-virus and anti-malware software, firewalls, and backup power generation facilities; use of redundant infrastructure providers; etc.)

Don’t overlook SLA achievement reporting. One important thing customers should look for in a SLA is how the vendor reports on SLA achievement metrics, which can be critical to know when a remedy for a SLA failure may be available. Vendors may place the burden on the customer to provide notice of a suspected uptime SLA failure within a specified amount of time following the end of the measurement period, in which case the vendor will review uptime for that period and verify whether the failure occurred. However, without proactive metrics reporting, a customer may only have a suspicion of a SLA failure, not actual facts. Customers using a mission-critical system may want to consider asking for proactive reporting of SLA achievement within a certain amount of time following each calendar month.

Issue Resolution SLA Commitment

Of equal importance to an uptime commitment is ensuring that a Service issue (downtime or otherwise) will be resolved as quickly as possible.  Many technology SLAs include a service level commitment for resolution of Service issues, including the levels/classifications of issues that may occur, a commitment on acknowledging the issue, and a commitment on resolving the issue.  The intent of both parties should be to agree on a commitment gives customers assurances that the vendor is exerting reasonable and appropriate efforts to resolve Service issues.

Severity Levels. Issue resolution SLAs typically include from 3-5 “severity levels” of issues.  Consider the following issues:

Impact Example Classification
Critical The Service is Unavailable
High An issue causing one or more critical functions to be Unavailable or disrupting the Service, or an issue which is materially impacting performance or availability
Medium An issue causing some impact to the Service, but not materially impacting performance or availability
Low An issue causing minimal impact to the Service
Enhancement The Service is not designed to perform a desired function

Issue resolution SLAs typically use some combination of these to group issues into “severity levels.”  Some group critical and high impact issues into Severity Level 1; some do not include a severity level for enhancements, instead allowing them to be covered by a separate change order procedure (including it in the SLA may be the vendor’s way of referencing a change order procedure for enhancements). Vendors may include language giving them the right to reclassify an issue into a lower severity level with less stringent timeframes. Customers should consider ensuring whether they should have the ability to object to (and block) a reclassification if they disagree that the issue should be reclassified.

Acknowledgment Commitment. Issue resolution SLAs typically include a commitment to acknowledge the issue. As with the uptime SLA, the definition of the acknowledgment timeframe is important (when it starts and when it ends). A vendor will typically define this as the period from the time it is first notified of or becomes aware of the issue to the time the initial communication acknowledging the issue is provided to the customer.  Customers should look at the method of communication (e.g., a post to the vendor’s support page, tweet through their support Twitter account, an email, a phone call from the customer’s account representative required, etc.) and determine if a mass communication method versus a personal communication method is important.

For critical and high impact issues, vendors (especially those operating multi-tenant environments) will often not offer a specific acknowledgment commitment, instead offering something like “as soon as possible depending on the circumstances.”  The argument for this is that for a critical or high impact issue, a vendor wants all available internal resources triaging and working the problem, not reaching out to customers to tell them there is a problem. In many cases, this may be sufficient for a customer provided there is some general acknowledgment provided to a support page, support Twitter account, etc. to alert customers that there is an issue. In others, a customer may want to push for their account representative, or a vendor representative not involved in triaging the problem such as an account executive, to acknowledge the issue within a fixed amount of time, putting the burden on the vendor to ensure it has appropriate internal communication processes in place.

Resolution Commitment. Issue resolution SLAs also typically include a time commitment to resolve the issue. One important thing to focus on here is what “resolve” means.  Vendors may define it as the implementation of a permanent fix or a workaround that temporarily resolves the problem pending the permanent fix; in some cases, vendors may also define it as the commencement of a project to implement a fix.  Customers should ensure that a vendor promptly implement a permanent fix if a workaround is put in place, and that failure to do so is a failure under the SLA. Many vendors are reluctant to provide a firm issue resolution timeframe, as the time required to resolve or implement a workaround is dependent on the issue itself, and are often unwilling to negotiate the resolution commitment or commit to a fixed timeframe for resolution.  Customers should ensure the resolution commitment is reasonable and that the vendor is doing everything it can to correct issues.  For example, for critical and high impact issues, consider an issue resolution commitment of “as soon as possible using continuous diligent efforts” – as long as the vendor is working diligently and continuously to fix the issue, they’re in compliance with the SLA. For lower impact issues, consider a commitment to implement a fix or workaround in the ordinary course of business.

In part 2, I’ll cover other types of technology SLA commitments, SLA remedies, and other things to watch for.

Eric Lambert has spent most of his legal career working in-house as a proactive problem-solver and business partner. He specializes in transactional agreements, technology/software/e-commerce, privacy, marketing and practical risk management. Any opinions in this post are his own. This post does not constitute, nor should it be construed as, legal advice. He is a technophile and Internet evangelist/enthusiast. In his spare time Eric dabbles in voice-over work and implementing and integrating connected home technologies.

The New Revenue Recognition Standards Are Coming – Will You Be Ready?

Posted on by
Reply

Most companies measure their financial performance by the revenues and other compensation they earn through their business operations, which in many cases means the sale of goods or provision of services. Knowing when to recognize the proceeds from a sale of good or provision of services as revenue is therefore critical to financial reporting. For many years, two different rules by two different standards organizations governed revenue recognition:

  1. The Financial Accounting Standards Board (“FASB“)’s Accounting Standards Codification (“ASC“) provide US generally accepted accounting principles (“GAAP“), including those governing revenue recognition. Under the current GAAP revenue recognition rule in ASC 605, revenue recognition varies by industry and in some cases by transaction, which makes revenue recognition a complex and difficult exercise in many situations.
  2. The International Accounting Standards Board (“IASB“)’s International Accounting Standards (“IAS“) provide an international standard for financial statements and accounting. Under the current international revenue recognition rule known as IAS 18, revenue recognition also varies by industry and transaction type, but IAS 18 provides less guidance than ASC 605 making it harder for companies to recognize revenue in a consistent fashion. The IASB is the successor to the International Accounting Standards Council (“IASC“) which originally promulgated the IAS.

Beginning in 2001, the IASB began replacing the IAS with new International Financial Reporting Standards (“IFRS“). In 2002, the FASB and IASB began collaborating on developing an improved. stronger, more robust, more useful, more consistent revenue recognition standard to make revenue recognition simpler and easier to consistently apply. This collaboration bore fruit 12 years later in May 2014, when the FASB and IASB released a converged revenue recognition standard titled Revenue from Contracts with Customers, codified as ASC 606 by FASB and IFRS 15 by IASB. Since 2014, there have been a few amendments (and implementation delays) by the FASB and IASB, and there have been a few small areas where the standards have diverged (e.g., the definition of what “probable” means). Despite this, for the most part the goal of a unified revenue recognition standard remains intact. These new standards will go into effect in December 2017 (for ASC 606) and January 2018 (for IFRS 15). All this background can be summarized in the following table:

A tabular representation of the history behind the ASC 606 / IFRS 15 revenue recognition standard.Here’s what you need to know about the new twin revenue recognition standards (for simplicity, this analysis is based on ASC 606):

How Revenue Recognition Works Under ASC 606/IFRS 15

To recognize revenue under the new standard, companies must do 5 things: (1) identify a customer contract, (2) identify the distinct performance obligations under that contract, (3) determine the transaction price (expected revenue), (4) allocate the expected revenue to the performance obligations, and (5) recognize allocated revenue when (or as) each performance obligation is satisfied. As stated in ASC 606, “an entity should recognize revenue to depict the transfer of promised goods or services to customers in an amount that reflects the consideration to which the entity expects to be entitled in exchange for those goods or services.” As we go through each step, keep this visual representation in mind:

ASC 606 Revenue Recognition DiagramStep 1 – Identify the contract(s) with a customer. The first step of the revenue recognition process is to identify a contract, i.e., an agreement creating enforceable rights and obligations among two (or more) parties. A contract must be signed or otherwise approved by the parties, must have identifiable rights and payment terms, have commercial substance, and it must be probable that one party will receive the revenue or other consideration expected from the performance of its obligations (e.g., provision of goods or services). Remember that a contract does not have to be in writing to be considered a contract for revenue recognition purposes – oral or implied contracts may satisfy these requirements.

Step 2 – Identify the contract’s distinct performance obligations. For goods and services contracts, a “performance obligation” is promise to transfer a good or provide a service to another party. A “distinct” performance obligation is one that benefits the recipient alone or with other readily available resources (e.g., delivery of a computer that is usable with power and Internet access obtained separately) and can be identified separately from other obligations under the contract (e.g., a company is delivering 5 computers, delivery of all 5 computers should be combined into a single performance obligation). A series of distinct performance obligations that are substantially similar can still be treated as individual performance obligations (e.g., delivery of a new computer at the start of each quarter during a calendar year, 4 new computers total). In a services agreement such as a SaaS contract, implementation obligations and the provision of services may be separate obligations. A SaaS company may look at its distinct performance obligation as providing a service each day during the term of the Agreement, so each day would be a distinct performance obligation.

Step 3 – Determine the transaction price. The “transaction price” is the expected payment and other consideration to be paid/provided in return for satisfaction of the performance obligations. Financial consideration can usually be grouped into fixed (stated in the contract) vs. variable (contingent on the occurrence or non-occurrence of a future event). For variable consideration, companies should look at the expected value taking into account the potential for changes in the variable payment component. If compensation for a performance obligation will be deferred, and not paid contemporaneously with the satisfaction of the performance obligation, the present value of the deferred compensation should be considered. Non-cash compensation (e.g., bartered goods or services) should be measured at fair value, or if not available the standalone selling price. Other consideration such as coupons or vouchers may need to be deducted from the transaction price. For SaaS companies that use a tiered pricing structure and monthly or annual minimums, calculating the expected revenue can be tricky (e.g., by using a probability-weighted methodology).

Step 4 – Allocate the transaction price to the performance obligations. If your contract has one performance obligation, you’re already done with this step. If not, the next step is to allocate the transaction price among each distinct performance obligation, i.e., to separate the transaction price into each discrete “piece” of consideration a party expects to receive from satisfying the associated performance obligation. This can be done by allocating the standalone selling price (i.e., the price at which the good would be sold separately) to the performance obligation, or where that standalone price is not available, the selling entity should estimate it by utilizing as many observable data points as possible to come up with the best estimate possible. ASC 606 includes examples of estimation methods. If a company provides a discount, the discount should be allocated proportionally among the expected revenue for the performance obligations to which the discount applies.

Step 5 – Recognize allocated revenue when (or as) the performance obligations are satisfied. The final step is to recognize each allocation of the transaction price as each distinct performance obligation is satisfied (i.e., the promised good or service is transferred to the recipient). For physical assets, transfer occurs when the recipient obtains control of the asset. For services, a performance obligation is satisfied when the benefits from the provider’s performance are received and utilized, the provider’s performance creates and/or enhances an asset in the recipient’s control, or the provider’s performance creates a payment right without creating an asset with an alternative use to the recipient (e.g., a company is contractually restricted from using a provided service for other purposes). Performance obligations may be satisfied on a specific date (e.g., for delivery of goods) or over a specific time period (e.g., for delivery of services). If satisfied over a time period, revenue may be recognized based on the progress towards satisfying the performance obligation.

Get Prepared Now

While it may seem like there is plenty of time to prepare for the implementation of the new revenue recognition standard, there’s a lot of work that needs to be done to be ready, including the following:

  • Learn the details. It’s important to note that this article represents a very high-level summary of the new revenue recognition standard. Having a more in-depth understanding of the new standard and how it applies to your company and its costing models/contracts is critical. There is an abundance of articles, seminars, and other publicly-available materials available on ASC 606 and IFRS 15. Also, talk with your accounting firm on what they have done as a firm to prepare, and their recommended action plan for your business – they may have some great materials they can provide to get you and your company up to speed.
  • A lot of work be done proactively. Conduct a proactive review of existing contracts, contractual obligations, and other revenue sources that may be classified as a “contract” subject to the new revenue recognition standard. Analyze each to determine the distinct performance obligations, and determine the transaction price. Work with your accountants to allocate the transaction price among the performance obligations.
  • Review (and update if necessary) contract templates. Accounting should partner with Legal and Sales to review sales proposal templates and contract templates describing or creating performance obligations. Review all standard variations of pricing offered to clients to identify any issues under the new revenue recognition standards. Consider whether warranties, returns language, or other contractual terms create distinct performance obligations and how they can be satisfied. Make any updates as necessary to ensure your templates align with the new standards going forward.
  • Create a plan. Assign a resource to manage the process of preparing for the new standard. Consider creating a cross-departmental group to meet regularly to discuss progress and assign tasks. Consider what internal education will need to be done to prepare employees and groups for the new standard, what changes to internal or third party systems may be required, what additional disclosure requirements may be required, whether internal policies will need to be updated or created, and what changes may be needed to internal processes. Secure the support of executive sponsors, such as the CFO and CEO. If you have personnel who were involved in rolling out SOX compliance in the early 2000s, talk to them about lessons learned to avoid repeating the mistakes of the past.

Eric Lambert is Assistant General Counsel and Privacy Officer at CommerceHub, a leading cloud services provider helping retailers and brands increase sales and delight shoppers through supply solutions to expand product assortment, demand solutions to promote and sell products on the channels that perform, and delivery solutions to enable rapid, on-time customer delivery. Any opinions in this post are his own. This post does not constitute, nor should it be construed as, legal advice. Eric works primarily from his home office outside of Minneapolis, Minnesota. He is a technophile and Internet evangelist/enthusiast. In his spare time, Eric dabbles in voice-over work and implementing and integrating connected home technologies.

6 Contract Templates Every Company Should Have at the Ready

Posted on by
Reply

One of my favorite sayings is “opportunity is equal parts luck and preparation.” In other words, being proactively prepared for an opportunity puts you in a better position to take advantage of one when it comes along. When a business opportunity arises that requires a contract or other legal document, being prepared includes having a well-written template ready to go. It can help avoid missing critical terms and points when rushing to draft a document for the opportunity, minimize the time and effort required to respond, and turn a “fire drill” into a routine but urgent request. Conducting business on a handshake agreement, or on a hastily drawn-up set of terms, to save time can backfire if the opportunity turns into a dispute. Having a well-drafted, legally binding agreement in place ensures the parties both understand their rights and obligations in connection with a business opportunity, and gives your company the protection it needs if and when the need arises.

Here are six contract templates every company should have drafted and ready for use when the opportunity arises. If your company does not have in-house counsel, consider whether having outside counsel prepare some or all of these templates for you is a worthwhile investment. If you have (or are) in-house counsel, check to ensure that you have up-to-date versions of these agreements in place. Consider whether to take this opportunity to freshen them up.

1) Mutual and unilateral NDA templates

Companies use non-disclosure agreements (aka “confidentiality agreements” or “NDAs”) for protective, contractual, and strategic purposes. NDAs ensure there are adequate (and binding) protections for your confidential information before you share it with another party. If your company has trade secrets, failing to put confidentiality obligations in place with third parties who have access to your trade secrets can cost you your trade secret protection. NDAs may also satisfy a contractual obligation to a third party (e.g., not to disclose a company’s confidential information unless the recipient is also subject to written confidentiality obligations). They can help ensure that a third party is truly interested and serious about discussions with your company. (I discussed the why, when and how of NDAs in depth in a previous LinkedIn article.) If your company and a prospective business partner want to “pull back the curtain” to share confidential information as part of discussions about a proposed relationship, you’ll want to have an NDA template ready for use.

Companies should have a minimum of two NDA template “flavors” at the ready – mutual (where both parties are providing confidential information to the other) and unilateral (where only your company is sharing confidential information). Use the template that best matches the actual disclosures occurring, and avoid putting a mutual NDA in place where you don’t expect (and don’t want) confidential information from the other party. For example, if you want to share financials and future business plans with a candidate for employment, a unilateral NDA is likely your best bet. Some companies use other flavors of NDAs as well (e.g., a specific version for M&A opportunities, one for interview candidates, etc.)

NDAs should also be drafted as fairly as possible – the last place you want to get bogged down in negotiation is over the NDA (tripping up your business discussions before they even start). Consider avoiding contentious language such as residuals clauses and first-party indemnities in your NDA templates. Also consider having your NDA template as a PDF with fillable form fields to minimize negotiation and simplify the process of completing the NDA.

2) Professional Services/Independent Contractor Agreement template

Every company, big and small, uses subcontractors, vendors and service providers (collectively, “contractors”). Contractors are often brought in where a company needs additional support or services its employees cannot provide (or want to outsource), where it needs subject matter expertise it does not have, or where it needs to temporarily augment its existing personnel or other resources. There are many benefits to using contractors, from avoiding the need to pay payroll-related costs to having the ability to “target” spend on subject matter expertise when needed. Having a written agreement in place with your contractors, and a template Independent Contractor Agreement (also called an “ICA” or “Professional Services Agreement”) ready for use, is critical to protect your company’s rights.

Most ICAs are a master set of terms governing each work engagement, and use “statements of work,” “work orders,” or “project assignments” for each discrete project (collectively, “SOWs”). Among other things, ICAs typically cover the scope of work performed; the independent contractor relationship between the parties (misclassification of independent contractors by companies is a current “hot button” issue for the IRS); testing, acceptance and ownership of deliverables; payment terms, expenses and taxes; representations, warranties and remedies around the work and/or deliverables; and insurance. SOWs generally include sections on the scope of services, in-scope and out-of-scope items, deliverables, timeline and milestones, fees (e.g., time and materials, not to exceed amount) and payment schedule, and change order procedure.

Companies may also want to consider using the core provisions of their ICA to create a set of “Vendor Terms & Conditions” that exist on a URL on the company’s domain. Companies can incorporate Vendor Terms & Conditions by reference into a vendor’s purchase order or invoice, with language ensuring a term in the Vendor Terms & Conditions governs over any conflicting terms in the vendor’s own terms, to avoid the need to negotiate every services order or contract. This can be a simple and cost-effective way to ensure a base set of standard risk allocation and other terms apply to each vendor even where the vendor spend or vendor size does not warrant the use of significant Legal or Procurement resources.

3) Employee Confidentiality and Inventions (and Non-Solicit and Non-Compete) Agreement and Employee Offer Letters

As a condition of employment, most companies require their employees (1) to maintain the confidentiality of the company’s confidential and proprietary information, and any similar information of the company’s clients, vendors and service providers, that the employee may receive or have access to during the term of his/her employment, and (2) to agree that the company owns any inventions or other “work product” created by the employee in connection with his/her employment. Some companies also require employees to agree, during the term of employment and for a period of time afterwards, not to solicit the company’s clients or employees, and/or to not compete with the company on behalf of another company (these are known collectively as “restrictive covenants”). To ensure these obligations are in place and legally enforceable, every company must have a well-drafted Employee Confidentiality and Inventions Agreement (or “ECIA”).

The ECIA is the type of agreement that is worth a little of outside employment counsel’s time to ensure it is both well-written and legally enforceable. If your company has offices or employees in multiple states, the laws around the enforceability of these types of agreements, especially restrictive covenants, differs widely. For example, in California, restrictive covenants are generally void, but in other states such as Minnesota, restrictive covenants can be enforceable if they are reasonable in time and scope and satisfy other legal requirements such as supported by consideration and supporting a legitimate employer interest. Consideration itself is an important consideration that varies from state to state — you may not be able to enforce a new (or updated) ECIA against existing employees unless it is supported by additional non-token consideration provided to the employee. Also, NDAs and partner agreements often require that a company only disclose the other party’s information to employees who have a need to know the information and are bound by written obligations of confidentiality to protect it, and a properly worded ECIA can satisfy this requirement.

Companies should also have well-drafted employee offer letters. The offer letter is signed by the company and agreed and acknowledged by the new employee, and contains both a summary of the employment terms and important protections for the company. A well-drafted and properly worded offer letter can help avoid later issues if there is dispute over terms such as the details of the employment offer or the employee’s conduct. Companies should have separate offer letter templates for exempt and non-exempt employees. Consider including, among other provisions, the start date; the title of the position and name/title of the supervising employee; the base salary and payment cycle; probation period language; information on vacation & holidays, benefits, and equity grants (if applicable); pre-employment screening requirements; and continuing obligations (e.g., there are no existing restrictive covenants that would prevent the candidate from working for the company; the candidate will not bring any confidential or proprietary data from a former employer onto company systems; etc.). Ensure the offer of employment is labeled “contingent” so that in the event of an issue, the applicant was not truthful on the employment application, you have the right to revoke it where allowed by law. Offer letters should also be reviewed by outside employment counsel to ensure they comply with the state laws applicable to your business.

4) Business Referral Agreement

Companies looking to grow their business may happen upon a person or company willing to refer potential clients to them (e.g., a company in a complimentary business whose clients may also be interested in your company’s products or services, or a person with deep connections in the industry who can facilitate introductions with executives at some of your company’s top sales targets), typically in return for a bounty per referral or a percentage of the fees earned by the company from the referred client. When a referral opportunity arises, have a business referral agreement template ready for use.

A business referral agreement typically covers the process of submitting a lead and any rights of the company receiving the lead (the “recipient”) to reject it; the time frame for the recipient to close a business transaction with the referred lead; the fees payable for referring the lead, and the payment frequency and terms; what assistance the referring company will provide to the recipient in closing the business (if any); and audit rights to ensure the referral fees paid are accurate.

As with NDAs, consider having both a mutual referral template (where both parties are referring leads to the other) and a unilateral template (where a party is referring leads to your company only).

5) Letter of Intent/Term Sheet/Memorandum of Understanding

When negotiating a new business opportunity, there is often pressure to get something on paper as quickly as possible, even before the deal is fully negotiated. One way to do this is through a letter of intent (also called an “LOI” or “term sheet”) or memorandum of understanding (“MOU”). A LOI or MOU can act as a “snapshot in time” of the anticipated terms of the definitive agreement as of that date, highlighting both where the parties have already come to agreement and where further negotiation is needed. If done incorrectly, a LOI thought to be non-binding by one party could be held to be a legally enforceable agreement. Having a properly worded LOI or MOU template at the ready can help evidence the parties’ intent to move forward with negotiations and ensure they keep the focus on finalizing the terms for, and negotiations on, a definitive agreement, while protecting your company’s rights to walk away if a definitive agreement cannot be reached.

A LOI and MOU differ primarily in form: a LOI is typically in the form of a letter, where a MOU is typically in the form of a legal agreement. LOIs and MOUs typically include terms that can be grouped into two sections:

  • Non-binding terms. These are a summary of the terms that the parties intend, as of the date of the LOI or MOU, to include in the definitive agreement. When putting non-binding terms into a LOI or MOU, consider using non-binding terms such as “would,” “should,” and “may” instead of “will” and “shall.” Also consider a catch-all provision stating that all obligations in the non-binding section are prospective only and will not apply to the parties unless and until embodied in a definitive agreement to be negotiated and signed by both parties.
  • Binding terms. Many people believe that a LOI or MOU is completely non-binding, but that’s almost always not the case. The most common binding term is a commitment by both parties to continue negotiating in good faith toward a definitive agreement, and a statement that either party may cease negotiations at any time. Other binding terms to consider for your LOI or MOU include exclusivity or standstill obligations (e.g., the parties will negotiate exclusively with the other for a period of X months); confidentiality obligations or a reference to the existing NDA in place between the parties; non-solicitation obligations; and general legal boilerplate such as choice of law and an integration clause. Also include a statement that except for any binding terms, the LOI or MOU does not create (and is not intended to create) any binding or enforceable agreement or offer. Ensure the binding and non-binding terms are in separated sections.

I prefer to use a letter of intent when it’s non-binding (e.g., as a term sheet), with our without a commitment by the parties to continue negotiating in good faith. I use a memorandum of understanding when summarizing non-binding deal terms coupled with binding obligations. Whether you use a LOI or MOU, ensure it is signed by both negotiating parties.

6) Settlement and Release Agreement

Sooner or later, your company will have a dispute with a client, customer or vendor over fees, performance of obligations, use of deliverables, etc. Most often, business disputes are resolved by the parties without the need for formal dispute resolution such as mediation, arbitration, or litigation. When a dispute is resolved, it can be important to have a settlement template ready to memorialize the parties’ full and final resolution of the dispute, and to state any obligations the parties have to each other in connection with the resolution of the dispute. Without a well-written and legally enforceable settlement and release agreement, the parties may find that the settlement of a dispute is not as full or final as originally thought if one of them seeks to enforce the settlement terms.

Settlement templates generally include a description of the dispute being settled; the consideration to resolve the dispute (e.g., waiving certain accounts receivables, payment of an amount by one party to another) and any contingencies (e.g., payment must be received within 10 days); a release by both parties of any claims related to the dispute (ensuring this is properly worded is one of the most critical parts of the settlement agreement); confidentiality language; a non-disparagement clause if appropriate; and other appropriate legal boilerplate. There are state-specific requirements for settlement and release agreements, so consider having local counsel review your template to ensure it will be enforceable.

The easiest settlement agreement template to have at the ready can be used for the resolution of run-of-the-mill business disputes such a billing dispute. For significant or complex disputes or settlements to resolve pending or threatened litigation/arbitration and releases in cases of employee terminations, consult an attorney to ensure your template fully and completely covers the complexities or nuances of the specific case.

Eric Lambert is Assistant General Counsel and Privacy Officer at CommerceHub, a leading cloud services provider helping retailers and brands increase sales and delight shoppers through supply solutions to expand product assortment, demand solutions to promote and sell products on the channels that perform, and delivery solutions to enable rapid, on-time customer delivery. Any opinions in this post are his own. This post does not constitute, nor should it be construed as, legal advice. Eric works primarily from his home office outside of Minneapolis, Minnesota. He is a technophile and Internet evangelist/enthusiast. In his spare time Eric dabbles in voice-over work and implementing and integrating connected home technologies.