MVPing your Legal Terms and Policies

Intended audience: Startup execs and tech lawyers.

tl;dr

• Knowing what customer-facing documentation you’ll need at various stages of your startup’s evolution can both help you prepare for growth and be choosy about when to invest in costly legal documentation.
• To start your company, all you’ll likely need is a Master Services Agreement and a Privacy Policy.
• As you grow, you’ll need to create a bunch of additional terms and policies (like a Data Processing Addendum, list of subprocessors, Acceptable Use Policy, Standard Contractual Clauses, and security policy).
• Which terms and policies you'll need depends on whether your customers are serving EU individuals and whether your customers are themselves in the EU.

Disclaimer: What follows isn't legal advice; it's general legal information. Consult an attorney to match legal requirements to your particular situation.

You now need more customer-facing terms and policies than ever before.

The volume of customer-facing legal documentation has exploded in the last two years.

In the old days, like three years ago, you could start your company using just a Master Services Agreement and a Privacy Policy. Now, if you look at established startups’ legal documentation pages, you see epic lists of legal terms like these:

Why so many? Because processing personal data is now as heavily-regulated as operating an airline (well, almost). The EU’s General Data Protection Regulation is the main culprit, but U.S. regulations, like California’s Consumer Privacy Act (CCPA), are doing their part to make life more annoying.

If you’re a founder, you didn’t start a company to spend your time wading through various regulatory requirements and legal documents. And it may be unsettling to rely on your paid-by-the-hour outside counsel to advise you on what is economical. So this post. I hope it gives you the information you need to be a sophisticated consumer of legal services.

The Setup

You: A U.S.-located B2B startup processing your customers’ personal data.

Your customers: Companies that service individuals.

Level 1 Documentation: Serving U.S. customers that serve U.S. consumers requires relatively little legal documentation.

If you’re operating in the U.S. and selling to small-to-medium-sized U.S. companies, here are the required documents:

• Master Services Agreement
• Privacy Policy
• Acceptable Use Policy (optional)
• Service Level Agreement (optional)

Notes:

• Separate customer data from website data. You’re going to need to treat customer data differently than website traffic data (like email addresses when sales prospects sign up for a mailing list). One elegant solution is to insert a confidentiality provision in your MSA for customer data and draft your Privacy Policy to address website traffic data exclusively.
• Standalone Acceptable Use Policies tend to work better. Changes in the law or customers figuring out creative ways to abuse your services will cause you to periodically adjust your Acceptable Use Policy, so it’s better to put it in a standalone document.
• Standardized Service Level Agreements are clutch. Your customers will demand a Service Level Agreement for high-ACV sales. When that happens, it’s much better to have one ready that is both reasonable and manageable. You will want to avoid signing any non-standard SLA’s because they are a monstrous pain to calculate and administer in the event of an outage.

Level 2 Documentation: Serving U.S. customers that serve consumers around the world requires much more.

As you expand your business, you’ll likely serve larger customers who serve, among others, EU individuals. That means you have to provide GDPR-compliant documentation to help your customers satisfy their GDPR obligations. Here’s the updated list of required documents (additions in bold):

• Master Services Agreement
• Privacy Policy
• Acceptable Use Policy (optional)
• Service Level Agreement (optional)
• Data Processing Addendum (aka DPA)
• List of subprocessors
• Vendor DPA (best practice)
• Security addendum (best practice)

Notes:

• Article 28(3) of the GDPR tells us what we need in our DPA. Almost every DPA is drafted to match those elements and will include limitations only to use the data pursuant to the customer’s instructions, to assist it with audits, to take appropriate security measures, and to delete data at the customer’s request.
• Customer demand for these additional docs may be inconsistent. The obligation to comply with the GDPR is on your U.S. customers and they may not be spending too much time on that, in which case they will be indifferent to you offering these additional documents.
• You should put DPAs in place with your vendors. The DPA’s contractual requirements (again, outlined in Section 3 of Article 28 of the GDPR) flow down to all service providers in the supply chain. The good news is that all your major vendors, like AWS or Zendesk, will offer you a DPA or have automatically built one into their online terms.
• Creating a security addendum is a good idea. Your DPA requires you to implement appropriate “technical and organisational security measures” and a good way to prove you’ve done that is to write out a public-facing security policy. It will also reassure your customers that you’re serious about security. For more, see Create a Written Information Security Program, Please.

Level 3 Documentation: Serving EU customers that serve consumers around the world requires the most documentation.

As your company grows, you’ll want to start selling to EU businesses. To do that, you’ll be transferring data directly from your EU customer to process it in the United States, which triggers a separate EU regulator requirement and requires an additional agreement. You’ll also be selling directly to Europeans, which requires an updated privacy policy and a cookie banner. Here’s the updated list of required documents (additions in underline):

• Master Services Agreement
• Privacy Policy (revised for GDPR compliance)
• Acceptable Use Policy (optional)
• Service Level Agreement (optional)
• Data Processing Addendum
• List of subprocessors
• Vendor DPA (best practice)
• Security addendum (best practice required)
• Cookie banner
• Standard Contractual Clauses
• Privacy Shield certification (RIP)

Notes:

• Standard Contractual Clauses allow your customers to transfer data to you lawfully. Article 46 of the GDPR requires companies to transfer EU people’s data only to countries with “appropriate safeguards.” Right now, the SCCs are the one viable way for a startup to satisfy that obligation.
• Because you’re collecting data from EU prospects, your Privacy Policy needs to account for the fundamental GDPR rights of transparency, access, deletion, correction, suspension, and transfer. The GDPR requires you to tell users about their rights and then help them satisfy those rights. Big companies have automated this process, but you can do it by hand. Create an alias like GDPRcompliance@[yourcompany].com and, if someone writes in with a request, help them out.
• The EU requires cookie banners. There are many companies that can help you do this. Don’t install one that doesn’t stop cookies (that sounds obvious, but many companies got caught doing this).
• You’ll likely need an Article 27 representative. If you’re selling into the EU, the GDPR requires this.
• To my knowledge, no EU Data Protection Authority has tried to enforce the GDPR against a U.S. company operating solely within the United States. Just saying.

FAQ

What if my company doesn’t process personal data? That’s unlikely. As I explain in Who's Asking? Defining “Personal Data” Under the GDPR, all the data you have about an identifiable person is personal data. And, it doesn’t take much to identify a person (zip code and last name suffices so does IP address). However, if you aren’t processing any personal data, you don’t need all of the GDPR documentation referenced above.

Why not do everything now? The time value of money is probably the best reason. Plus, you’ll have to keep all of these docs updated, which is an added headache.

Won’t we look more sophisticated if we have all the documentation? Maybe. It depends on who you’re selling to and how they vet their vendors. The more polished your legal documents look, the better.

How do I account for the California Consumer Privacy Act? Under the CCPA, you don’t want your customers to be “selling” data to you, so you need language in your agreement which specifies that you’re a “Service Provider”. Here’s how Dropbox does it:

This Agreement constitutes Customer’s instructions to Dropbox to Process Customer Data. Dropbox, Dropbox personnel and its Subcontractors will only Process, access, use, store, and transfer Customer Data as Customer instructs in order to deliver the Services and to fulfill Dropbox’s obligations in the Agreement.

How do we ensure we never have to negotiate our terms? The short answer is to refuse to do it. That lets you tell prospective customers, “we’ve never done this and don’t have the capability to do so. It’s one way we keep costs down.” To limit the extent to which your customers will negotiate with you, put your terms online and provide an industry-standard limitation of liability and warranty.

What if a customer insists on modifying the terms? If you do need to vary the terms, like removing an automatic-renewal provision, put that on the order form instead of modifying your online terms. It will be much easier to track the changes that way and you can develop standard variance language that you can use across your customer base.

When you refer to the EU, do you also mean the UK? Yes.

Is this post a counterpoint to the argument that complying with the GDPR is painless? Yes.

Should your attention to your terms and policies grow along with your sales volume? Yes. The more contracts you sign, the higher the likelihood that you’ll get into a dispute over them and the more useful it will be to have well-crafted contracts that anticipate them.

What if I spin up an EU sales office? If you do that, you could have your EU entity contract with your EU customers, which may simplify your customer contracts and policies.

Fin.