A master service agreement, or MSA, sets the standing commercial terms for a customer relationship. It typically covers payment, confidentiality, liability, and termination, while an order form identifies what the customer buys. Zecca Ross’s MSA explainer covers those mechanics in more depth. For a hosted SaaS product, the MSA or accompanying terms must also address access to the service. General MSA language does not, by itself, settle what happens to customer data.
A data processing agreement, or DPA, addresses the provider’s handling of personal data on a customer’s behalf. It can specify processing instructions, security measures, subcontractor conditions, and what happens to data when processing ends. The parties’ roles and applicable privacy law determine which terms the deal needs. Calling an MSA a “SaaS agreement” does not supply missing processing terms.
A software license agreement grants rights to use software under stated conditions. For installed software, those rights may cover installation and copying, and they may address modification if the customer needs that right. A hosted subscription usually gives the customer access to software that the provider runs, without granting the same installation rights. A subscription may still contain a limited license to access or use the service, so the agreement’s title matters less than the rights it actually grants.
For founders, Zecca Ross would start with how you deliver the product and handle customer data, then draft the documents around those facts. A template may help identify topics to discuss, but counsel should review the terms when installed software, customer data, or negotiated obligations make the documents overlap.
A hosted subscription, a data processing agreement, and an installed-software license can appear in the same deal because each governs a different obligation.
A customer can buy hosted access and installed software from the same SaaS company, but the two products need different rights. Suppose a Delaware-incorporated startup sells a browser-based inventory dashboard to a California retailer. The SaaS MSA sets the standing commercial terms, and an order form identifies the subscription, price, and term. The retailer can use the dashboard during its subscription, but it does not receive a copy of the software to install.
Now suppose the retailer also buys a module that runs on its own servers. The contract needs license terms stating who may install the module, how many copies they may run, and whether the retailer may modify it. The hosted subscription’s access grant does not answer those questions. The installed module may also need separate terms for updates, support, and security responsibilities because the retailer controls its servers.
Data handling depends on what each product does. If the startup processes personal data on the retailer’s behalf through the hosted dashboard, the parties should assess whether a DPA is required. If the startup can access data in the installed module for support, they should assess that access separately rather than assume one set of processing terms fits both products.
Delaware incorporation determines the startup’s corporate law, not every rule governing its customer contracts. The parties can negotiate a governing-law clause, but that choice does not by itself displace applicable privacy requirements in California or elsewhere.
A DPA is required when an applicable privacy law calls for processing terms, not simply because a customer buys SaaS. Under the GDPR, a controller decides why and how personal data is processed, while a processor handles it on the controller’s behalf. If your customer controls the purpose of processing and your SaaS company processes that data for the customer, GDPR Article 28 requires a binding contract or other legal act covering that work. The terms can sit in a separate data processing agreement or in the MSA, but ordinary confidentiality language will not cover the required processing obligations.
The roles depend on the data and the activity. An EU-based customer might control the employee records it uploads to your platform, making your company its processor for that service. Your company may separately act as a controller when it uses customer contact details for its own billing. Article 28 terms should describe the processing and address matters such as documented instructions, confidentiality, security, subprocessors, assistance with data requests, and what happens to the data when services end. If the GDPR does not apply and no other applicable law or customer commitment requires those terms, a DPA is not automatically necessary.
U.S. requirements need a separate check. Under California’s CCPA framework, a covered business sharing personal information with a service provider or contractor needs contract terms that govern how the recipient may use it. The California Privacy Protection Agency’s regulatory materials list the applicable CCPA regulations and updates. Other state privacy laws may call for different processor-contract terms. Before reusing one DPA across customers, check which laws apply, each party’s role, and the current requirements in the relevant states.
A DPA also does not, by itself, settle international transfer requirements. For certain transfers out of the EU or EEA, the European Commission’s standard contractual clauses provide an approved contractual safeguard. The United Kingdom and Switzerland use adaptations, while some other jurisdictions have separate model clauses. If your SaaS company receives data across borders, check the current adequacy status of the destination and the available transfer mechanism for that specific route. Zecca Ross would review that route alongside the processing terms rather than assume a standard DPA covers every transfer.
An order form puts the commercial details of a SaaS deal in writing. It typically identifies the subscription plan, permitted users or usage limits, price, start date, and term. The MSA supplies standing legal terms, while the order form identifies what the customer is buying under those terms. If the customer later adds a product, a new order form can record the change without replacing the MSA.
An SLA records measurable service and support promises. It may define how the provider calculates uptime, which outages it excludes, how quickly support responds, and whether a customer can claim a service credit. An order form that lists a subscription price does not tell the customer what happens when the service goes down. The SLA should make that answer specific.
A security exhibit describes the safeguards the provider promises to maintain, such as access controls, encryption practices, and security testing. You should check those promises against what your product actually does. The exhibit does not replace a DPA when the deal requires processing terms. Likewise, a DPA does not automatically supply a measurable uptime commitment or a complete description of your security practices.
Zecca Ross reviews these attachments together because their terms can pull in different directions. An MSA might define “confidential information” more narrowly than a security exhibit defines protected customer data. An SLA might call service credits the customer’s exclusive remedy for downtime, while the MSA preserves broader remedies. A security exhibit might promise a testing schedule that differs from another attachment. Those differences need review before the documents go to a customer, not after someone invokes them.
Conflicting remedies can change what a customer receives after an outage. Suppose a SaaS MSA lets the customer terminate and recover prepaid fees after a prolonged outage, but the SLA calls service credits the customer’s sole remedy for missed uptime. The customer may seek both termination and a refund, while the vendor may argue that credits replace both. The documents should say whether a prolonged outage triggers an exception, whether credits reduce any refund, and how the MSA’s liability cap applies.
Definitions can create quieter conflicts. An MSA might define “Customer Data” as everything a customer uploads, while a security exhibit promises safeguards only for “Confidential Information.” If those terms do not cover the same files, the parties may disagree about which uploads receive the promised protections. A DPA’s processing obligations also need to remain clear when the MSA uses broader or narrower data terms.
A precedence clause should give each document authority over its subject matter. The order form can control price and subscription term, the SLA can control availability remedies, the security exhibit can control stated safeguards, and the DPA can control processing obligations. The MSA then governs matters the attachments do not expressly change. Counsel should also state whether an attachment overrides the MSA’s liability cap, rather than assuming that subject-specific priority answers that separate question.
A generic clause saying “exhibits prevail” may give an unintended promise priority. Zecca Ross’s lawyer-led review can identify those conflicts and draft a hierarchy around the deal’s actual terms, rather than relying on a template that leaves the parties to resolve them after a dispute.
These documents can sit in one contract stack. Zecca Ross reviews how they fit together for SaaS founders, including Delaware-incorporated startups, rather than relying on a single template. Its scoped flat-fee approach gives founders direct attorney involvement and more predictable pricing than open-ended BigLaw billing when the documents need to be drafted or reconciled.
Getting the agreement stack right requires coordinated drafting, not a choice among forms. Your MSA, DPA, order form, and any software license must describe the same deal without conflicting promises. A template cannot tell you which privacy terms apply or resolve a contradiction between an SLA and the MSA.
Zecca Ross Law Firm offers lawyer-led SaaS contract work, including its flat-fee SaaS Starter and SaaS Launch Legal packages. The flat-fee structure gives founders a defined scope and predictable price for attorney involvement, rather than a stack assembled from templates. If you are building or scaling SaaS contracts, including for a Delaware-incorporated startup, talk to Zecca Ross before your next customer deal.
Legal clarity starts here. Partner with Zecca Ross Law Firm to transform complexity into opportunity.