What Legal Documents Does a Startup Need Before Signing Its First Enterprise Customer?

Before signing its first enterprise customer, a US startup should prepare a master services agreement, an order form or statement of work, confidentiality terms, and any privacy or security addenda required by the data and systems involved. The company should also confirm who can approve and sign the deal, what intellectual property it can actually license, and whether the promised service levels, insurance, support, and security controls match reality. The exact package depends on the product, customer, data, and governing law, so use this as a readiness checklist and have qualified counsel adapt the documents to the transaction.

Educational information only. This is not legal advice.

Start with the transaction map, not a stack of templates

Enterprise agreements are easier to review when each document has one job. A common structure is:

a master services agreement, or MSA, for the reusable legal terms;
an order form for pricing, subscription length, users, products, and renewal;
a statement of work, or SOW, when implementation or custom services need detailed scope;
a data-processing addendum, or DPA, when the startup processes personal data for the customer;
a security exhibit or SLA when the customer requires specific controls, uptime, support, or incident commitments.

Some companies combine these documents. That can work, but the combined agreement should still answer the same questions without contradictions.

Before drafting, write down the commercial deal in plain language:

What is the customer buying?
When does the subscription or project start?
How and when will the customer pay?
What must happen before the customer accepts the service?
What data and systems will the startup access?
Which promises are standard, and which were negotiated for this customer?

This short transaction map prevents the legal documents from drifting away from the sales conversation.

Use the MSA for the reusable legal terms

The MSA should describe the legal relationship that can apply across multiple orders. Typical sections address:

services and customer responsibilities;
fees, invoices, taxes, and late payment;
confidentiality;
intellectual-property ownership and license rights;
acceptable use and restrictions;
warranties and disclaimers;
indemnification;
limits of liability;
term, termination, suspension, and the effect of termination;
governing law, disputes, notices, assignment, and changes.

Do not treat these as boilerplate headings. Each one allocates a real risk. A liability cap, for example, should be considered alongside the contract value, data handled, insurance coverage, indemnities, and any exceptions to the cap.

The confidentiality section also supports trade-secret protection. Under 18 U.S.C. § 1839, information qualifies as a trade secret only if, among other requirements, its owner takes reasonable measures to keep it secret. A signed confidentiality obligation is one useful measure, but the company should also limit access and handle confidential material consistently in practice.

Put the actual purchase in an order form or SOW

The order form should make the first transaction easy to understand without rewriting the MSA. It usually states:

the legal names of the vendor and customer;
product, plan, quantity, usage limits, and included support;
fees, payment schedule, and currency;
start date, initial term, renewal, and cancellation mechanics;
referenced documents and their order of precedence;
any approved special terms.

Use an SOW when the startup will configure, migrate, integrate, train, or build something for the customer. Define deliverables, dependencies, milestones, acceptance, change control, staffing assumptions, expenses, and what happens if the customer delays an input.

Avoid vague promises such as "full implementation support" or "enterprise-grade customization." Describe the work the team can actually deliver and the customer actions required to deliver it.

Add a DPA when personal data is involved

If the startup processes personal data on the customer's behalf, the customer may require a DPA that covers instructions, confidentiality, security, subprocessors, individual-rights requests, incident support, audits, deletion, and return of data.

California law can make contract terms mandatory. California Civil Code § 1798.100(d) requires covered businesses that disclose personal information to a service provider or contractor to use an agreement that specifies limited purposes, imposes applicable privacy obligations, permits compliance steps, requires notice if the recipient can no longer comply, and allows remediation of unauthorized use. The California Privacy Protection Agency's contract regulation adds detail for service-provider and contractor agreements.

If the EU General Data Protection Regulation applies, Article 28 of the GDPR requires processing by a processor to be governed by a binding contract or other legal act containing specified terms. Cross-border transfers may require a separate transfer mechanism in addition to the processor terms.

Do not add a generic DPA merely because the customer asks for one. First map:

categories of personal data;
people the data concerns;
processing purposes;
hosting and access locations;
subprocessors;
retention and deletion behavior;
security controls;
whether any regulated or especially sensitive data is involved.

The contract should match that data map.

Make security promises the product can support

Enterprise customers often send a security questionnaire and request a security exhibit. The legal answer should match the technical answer.

The FTC's Start with Security guide recommends putting appropriate security standards into service-provider contracts and verifying compliance rather than relying only on promises. The FTC's small-business cybersecurity guidance similarly recommends specific vendor-contract provisions covering data use, retention, deletion, access, encryption, and changing threats.

The NIST Cybersecurity Framework 2.0 treats supplier security as a lifecycle issue and calls for relevant requirements to be integrated into contracts and other agreements. It is a risk-management framework, not a universal certification.

Before accepting a security exhibit, verify:

incident-notification timing and process;
encryption statements;
access-control and authentication commitments;
backup, recovery, and business-continuity claims;
vulnerability and patching practices;
audit reports or certifications referenced;
subprocessor oversight;
deletion and return commitments;
insurance requirements.

If the startup does not have a promised control, do not sign first and hope to build it later. Narrow the commitment, document a dated remediation plan if the customer accepts one, or decline the term.

Confirm IP ownership before licensing the product

The startup cannot grant rights it does not own or control. Before the first enterprise agreement, confirm that:

founders, employees, and contractors assigned relevant IP to the company;
open-source components are tracked and used under compatible licenses;
third-party models, datasets, APIs, libraries, and content can be used as promised;
customer-specific development has a clear ownership and license structure;
the contract does not accidentally transfer the core product to the customer;
the customer grants the rights needed to process its inputs and data.

Separate ownership from permission. The startup may retain ownership of its platform while granting a limited subscription license. The customer may retain its data while authorizing the startup to process it for the contracted service. Custom deliverables may need their own treatment.

Approve the deal inside the company

A signed customer contract should have an internal record that shows:

the final documents and exhibits;
the authorized signer;
commercial approval for price and payment terms;
security and privacy approval for relevant commitments;
finance approval for credits, refunds, insurance, or unusual liability;
a list of nonstandard terms and their operational owners;
renewal and notice dates;
the system where the executed agreement will be retained.

Founders often approve an early contract themselves, but the company should still record the decision. As the team grows, this record becomes the starting point for a repeatable deal-desk process.

A practical first-enterprise-customer checklist

Before signature, confirm that:

the MSA matches the product and business model;
the order form contains the actual commercial deal;
any SOW has measurable scope, dependencies, acceptance, and change control;
confidentiality terms cover both parties' sensitive information;
the DPA and transfer terms match the real data flow when applicable;
the security exhibit matches implemented controls;
service levels and support obligations are operationally achievable;
IP ownership and third-party dependencies have been reviewed;
liability, indemnity, insurance, and warranty terms have named internal owners;
the signer is authorized;
the final executed package, renewal date, and notice deadlines will be stored and tracked.

The goal is not to eliminate every risk. It is to make the accepted risks visible, owned, and consistent with what the startup can deliver.

Frequently asked questions

Does every startup need an MSA for its first enterprise customer?

Not always. A single agreement can combine the legal and commercial terms. An MSA plus order form is useful when the startup expects repeat purchases, multiple products, or future SOWs because the reusable terms do not need to be renegotiated for every order.

Is an NDA enough before a pilot?

No. An NDA addresses confidential information, but it does not define the pilot scope, fees, IP rights, data processing, security obligations, liability, acceptance, or termination. Use an NDA only for the confidentiality problem and document the pilot itself.

Should a startup sign the customer's paper?

Sometimes, especially when the customer has mandatory procurement terms. Review it against the startup's actual product, data, insurance, security, and risk capacity. Track every nonstandard obligation, even when the customer will not change the language.

When is a DPA required?

It depends on the data, roles, locations, and laws involved. A DPA is commonly required when the startup processes personal data on the customer's behalf. Counsel should confirm the applicable regimes and whether additional transfer or sector-specific terms are needed.