In the world of tech contracts, business-people and lawyers tend to screw up the same handful of clauses, in roughly the same ways. If you can avoid those mistakes—five of them—you’ll greatly improve your contracts and protect your bottom line.
Ready to get your contracts in order? Explore contract management software solutions in the Capterra directory.
This article is for tech customers, as opposed to vendors. (Vendors have their own common mistakes.) It’s meant to help you license software, buy software-as-a-service (SaaS) and other cloud computing offerings, and hire tech services vendors.
1. Don’t pay for maintenance or support before you need it.
Imagine your software relationship starts with implementation or some other type of customization. That work begins on day one of your work with the vendor, and so does the maintenance and support plan—along with maintenance fees.
Wait a second! Why do you need maintenance and support on the first day? You’re not using the software yet. At least, in most deals you won’t use the software until the vendor’s finished with customization—possibly after months or longer. It’s the vendor’s customization/implementation team who’s working on the software, and they don’t need support. They’re the experts. And if updates or upgrades become available, the vendor’s team can install them, as part of customization. So if monthly or annual maintenance fees start before customization is done, you may pay for nothing.
That’s why you should always try to delay the start of maintenance and support until after customization—after the system goes live. In your contract, define “Go-Live” as completion of customization, or maybe acceptance of the final customization deliverable. Then, provide that maintenance begins on Go-Live. By reducing the time span of maintenance—eliminating fees for periods you don’t need—you save money, possibly a great deal.
One caveat: some vendors actually do have a good reason to start maintenance before go-live. The vendor might have set software fees artificially low, planning to make it up through maintenance fees. So if maintenance payments fell (thanks to a shorter/later-starting maintenance term), the vendor would lose money on the deal. The vendor also might actually need some maintenance or support during customization. Maybe the maintenance team can do things the customization team can’t. So you should listen to your vendor with an open mind. But if you don’t ask, you’ll never know. And some vendors have no good reason to start fees before go-live.
You can find sample language, pushing maintenance back to go-live, in the clause library at your humble author’s portal, TechContracts.com. See the last sentence of the last example on the linked page. (You can also learn more about maintenance start-dates from The Tech Contracts Handbook: Cloud Computing Agreements, Software Licenses, and Other IT Contracts, for Lawyers and Businesspeople, 2nd Ed., by David W. Tollen (ABA IP Section 2015), pp. 77-78. See also, “Must the Buyer Pay for Technology or Maintenance if Implementation Doesn’t Happen?”)
2. Don’t use NDA’s for data security.
One of the most common tech buyer mistakes is to rely on nondisclosure agreements (NDA’s), or nondisclosure clauses, to protect data. Nondisclosure terms protect trade secrets, not data held or accessed by the vendor—and certainly not private data.
A nondisclosure clause says the recipient won’t use confidential information for any purpose other than whatever’s intended in the contract—and won’t share it with anyone else. It’s a great tool for protecting secret recipes, business plans, customer lists, source code, and the like. But nondisclosure terms end where data security terms should start. Nondisclosure terms generally say nothing about procedures to protect information, or they simply say the recipient will take “reasonable precautions.” A data security clause, on the other hand, is all about those procedures.
Nondisclosure terms also let humans look at confidential information, while a data clause should generally forbid human access and only allow computer access. And nondisclosure clauses misfire in many other ways. (For more on the difference between data and nondisclosure clauses, see The Tech Contracts Handbook, Chap. II.H.4.)
A real data clause should cover procedures for protecting data: encryption, passwords, dual control restrictions, physical protection of servers, etc. Many data clauses also require employee background checks, data breach response and notification, and possibly most important, outside audits of data security (with names like “SOC 2,” “SSAE-16,” and “ISO 27001”). And data clauses should address compliance with laws and privacy policies, as well as e-discovery policies, which cover when and how the vendor can give data to the other party in a lawsuit. You can find sample data clauses—real ones—at the TechContracts.com portal, item II.H.
Of course, not every data clause covers all these topics, and not every vendor will make detailed promises about them. But if you start with a real data clause, you’re at least addressing the right topics.
3. Don’t buy or rely on useless SaaS escrows.
One of the customer’s silliest mistakes is paying for a “software-as-a-service escrow,” or even relying on one.
Customers ask for SaaS escrows because they worry the vendor will go out of business—and mission critical SaaS will evaporate. The parties solve the problem by giving the software running the SaaS app to an escrow agent, who will release it to the customer if the vendor goes under. Then the customer can run the SaaS offering itself. Or can it?
Whenever I review a SaaS escrow for a customer client, I ask the vendor if the customer could actually use the software if it ever came out of escrow. Could the customer install the software and run it as SaaS? So far, the answer has always been a sheepish “no.” The SaaS won’t run without a platform of hardware and software from third parties, which the customer couldn’t recreate. And the software isn’t particularly easy to understand or use, since the vendor wrote it for internal management, on its own platform, not for distribution. (Remember, with SaaS, the vendor keeps the software on its own computers and just gives the customer access, not copies.)
So most likely a SaaS escrow will do you no good, and you shouldn’t pay for one or rely on one. Unless your vendor’s SaaS is unusually easy to install and operate, focus on protecting your data, not on the vendor’s software. Make sure you have rights to access and back up the data, before and after trouble comes up. And consider better protections against vendor bankruptcy, like insurance requirements or financial reporting clauses, which give you a chance to review vendor books and records and, ideally, detect financial collapse in advance, when you have time to replace the vendor and save your data.
Again, the TechContracts.com portal has sample clauses on data backup and management (subsection (b) on the linked page), insurance, and financial reporting. (Also, for more on SaaS escrows, and for an expensive alternative, the “cloud services pseudo-escrow,” see The Tech Contracts Handbook, Chap. II.S.4.)
4. Don’t let the exceptions swallow your IP indemnity.
In many IT contracts, the vendor indemnifies the customer for intellectual property (IP) suits about the vendor’s technology. If a third party sues the customer, saying use of the vendor’s tech infringes a patent, copyright, or trade secret, the vendor defends and pays the lawyers and any settlements or judgments. But the standard indemnity language includes several exceptions, and that’s where customers get tripped up. (You can see typical exceptions at the TechContracts.com portal: items II-J.3 and II-J.4.)
One of the most typical indemnity exceptions says the vendor doesn’t have to indemnify suits about “use of Vendor’s Technology in combination with hardware or software not provided by Vendor.” Sounds fair. If the customer combines the vendor’s product with tech from a third party, the vendor’s not on the hook for cases about the combination or interface between the two products. But many customers fail to think this through. Every piece of hardware or software works in combination with third party products: computers, operating systems (OS’s), office systems (e.g., MS Word, Excel), other apps, etc. What if the customer uses the the vendor’s tech with something it needs to operate the system, like an OS or browser? What if the vendor’s manual told the customer to use that browser or OS? Most customers would be pretty stunned to find they have no indemnity covering those unavoidable combinations.
The solution is a narrower exception. The clause could say the vendor’s off the hook for IP cases about combinations with third party products, “unless such combination achieves functionality described in the Documentation or Specifications.” That way, the vendor does cover suits about combinations with third party products if the combination was authorized: if the customer was just using the vendor’s system for its intended purpose. On the other hand, if the customer went off and combined the system with something the vendor never could have predicted, to achieve some unexpected goal, there’s no indemnity. Or you might try something more complicated but a little more favorable to the vendor. The vendor’s off the hook for IP cases about third party product combinations, “unless the Documentation or Specifications refers to a combination with such hardware or software, without directing the user not to perform such a combination.” You can see full sample clauses for both of these options at the TechContracts.com portal.
Another common IP indemnity exception says the vendor doesn’t have to cover claims triggered by “Vendor’s modification of the Software per specifications from Customer.” That seems sensible. If you (the Customer) wrote specs that allegedly infringed a third party’s IP, and the vendor just followed them, why should be vendor have to defend the suit? But the typical language eliminates any case related to your specifications. What if you just sent very high-level specifications about a new system, and the vendor’s choices about how to write the software triggered the IP suit? Or what if you sent detailed specs, but then the vendor built the system using someone else’s software, without a license (a.k.a. “stealing”)? Why should the use of your specifications excuse the vendor in either case?
You can solve this with a few simple words. The vendor’s IP indemnity obligations are excused, “to the extent the alleged infringement results from specifications provided by Customer.” Or they’re excused if the alleged infringement “arises directly out of specifications provided by Customer.”
Of course, some vendors will simply say, “not at this price” to all these suggestions (often their best argument). But as with all these suggestions, you get nothing if you don’t try. (You can learn more about IP indemnity exceptions in The Tech Contracts Handbook, Chap. II.J.3.)
5. Include, read, and edit specifications (even if you’re IT-illiterate).
It’s amazing how often tech contracts fail to say what the technology is supposed to do. It’s amazing too how many contracts do explain the technology’s function, but in terms so vague that they’re useless.
We’re not buying pencils here, or office furniture or forklifts. Everyone knows what those products are supposed to do, so their purchase contracts need little in terms of specifications. IT is adaptable and flexible. It can do countless complex things, so we can’t just assume everyone agrees what it’s supposed to do. Or to put it in starker terms, the salesperson may have told you the software can do X, Y, and Z, but if the contract doesn’t say so, it’s probably not required. Warranties become vague or meaningless without good specs, because a warranty promises that the tech will work, and no one knows what “work” means. The same goes for maintenance and acceptance clauses, which say the vendor will fix software or deliverables that don’t work. You may have a firm idea what “work” means, but the vendor could have different ideas—possibly thanks to an honest misunderstanding.
If the vendor is customizing software, the contract should have customized specifications, describing the features and functions you need. If the vendor’s giving you something off-the-shelf, the vendor’s standard specifications may do the trick. Find them and read them. And if they don’t describe the functions you need, supplement them. Write your own description of those missing functions.
In many case, you can describe the functionality you need in simple everyday English. (You’ll be writing “functional specifications.”) But if your description needs technical details, you may want an IT specialist to write it. (That will often lead to “technical specifications.”) Get a specialist—and don’t hesitate to let the vendor’s specialists create the first draft, or start with the vendor’s standard draft. But no matter who creates the first draft, if you’re responsible for the deal, you should make sure those specifications describe the technology you need. And, yes, you can. There’s no such thing as “technicalese” (or “legalese,” for that matter), and if you can read English, you can edit specifications. If a term or phrase isn’t clear, you can look it up—and if the meaning remains confusing, you can define it in the specifications, in terms you do understand, so there’s no doubt.
Once you have specifications, the rest of your contract becomes more effective. Your warranty doesn’t say the software will “work”; it says the software will “function materially according to the specifications on Exhibit B (the ‘Specifications’).” Your maintenance clause says the vendor will repair any technology not “functioning according to its Specifications.” And your acceptance clause will say you can reject any deliverable that “fails materially to perform as required in its Specifications.”
As with all my advice here, this isn’t always an option. Some vendors offer standard specs, and they’re not negotiable. But try. Don’t let fear of technical language lead you to ignore the contract’s most important terms. Technical specifications lie at the heart of your deal.
Looking for a visual walkthrough on negotiating software contracts? The following video shares five tips to get better at it.