Introduction
Your product is built, the launch button is right there, and then your first serious customer’s procurement team sends over a checklist demanding documents you have never heard of. The code is the exciting part of building software, but a small stack of documents quietly determines whether you get sued, get funded, or get acquired. Founders tend to treat these as post-launch housekeeping, which is precisely backwards, because almost every one of them is far cheaper to create before there is a counterparty on the other side of the table.
One rule governs everything that follows: your documents must match where your users are, not merely where you are incorporated. Article 3 of the GDPR applies the Regulation both to processing in the context of an establishment in the Union and, under Article 3(2), to controllers and processors outside the Union who offer goods or services to data subjects in the Union or monitor their behaviour. A template drafted for a US company does not cover your European users, and it does not cover your Californian ones either. This article sets out the stack in three tiers, from the documents every SaaS needs on day one, through the ones that close business-to-business deals, to the tier that determines whether your company actually owns its own product.
Tier One: The Public-Facing Trio
Three documents belong on your website from the day you accept your first user.
Your Terms of Service are your contract with every user. They set the rules of use, allocate risk, govern payment and renewal, establish your dispute resolution and governing law position, and give you the right to suspend or remove abusive accounts. Without them, your relationship with users falls back on default national law, which is rarely drafted with your interests in mind. One important qualification: the freedom to cap liability that founders assume belongs to business-to-business terms. Where your SaaS is sold to consumers, Directive 93/13/EEC applies its fairness test to every term that was not individually negotiated, and one-sided liability caps, unilateral modification rights, and inconvenient forum clauses can be struck out as unfair. Consumer-facing terms therefore need to be drafted to a different standard than enterprise terms.
Your Privacy Policy becomes mandatory the moment you process personal data, and an email address alone is enough. Articles 13 and 14 of the GDPR prescribe in detail what you must tell people, including the identity of the controller, the purposes and legal basis for each processing operation, recipients, retention periods, international transfers, and the full list of data subject rights. This is one document where a template is actively dangerous, because Article 5(1)(a) requires transparency and the policy must describe what your product genuinely does. A privacy policy that describes a different product is not compliance, it is a written admission.
Your cookie consent mechanism is a separate legal requirement, and founders routinely assume the privacy policy covers it. It does not. Article 5(3) of the ePrivacy Directive 2002/58/EC requires consent before storing information on, or accessing information already stored in, a user’s terminal equipment, with a narrow exception for what is strictly necessary to provide the service the user requested. Analytics and advertising pixels do not fall within that exception. The consent standard is the GDPR standard, which the Court of Justice confirmed in Case C-673/17 Planet49 means a pre-ticked box does not constitute valid consent. In practice this means no non-essential script fires before the user actively opts in.
Tier Two: The Documents That Close B2B Deals
If you sell to other businesses, this tier is where deals stall.
The question founders search for most is whether they need a Data Processing Agreement, and the answer is almost always yes. Where you process personal data on behalf of your business customers, they are the controller and you are the processor, and Article 28(3) of the GDPR requires that the relationship be governed by a contract binding on the processor which sets out the subject matter, duration, nature and purpose of the processing, the types of personal data and categories of data subjects, and a prescribed list of processor obligations covering documented instructions, confidentiality, security measures, sub-processing, assistance with data subject rights, breach notification, deletion or return at the end of the service, and audit rights. That contract is the DPA.
Your cloud provider’s terms do not satisfy this. The DPA you have with AWS or Google Cloud governs their processing of data on your behalf and says nothing about your relationship with your customer. Under Article 28(2) and (4), you also need your own agreements in place with every sub-processor you engage, including your hosting provider, payment processor, email service, and analytics tools, and those agreements must impose the same data protection obligations you owe your customer. You remain fully liable to your customer for your sub-processors’ performance. When an enterprise buyer’s procurement team asks for your DPA and your sub-processor list and you have neither ready, the deal does not fail dramatically. It simply stops moving.
Alongside the DPA, enterprise buyers will expect a Service Level Agreement covering uptime commitments, support response times, escalation paths, and the service credits or termination rights that apply when you miss them. There is no statute requiring an SLA in general, but there is sectoral law that effectively does. If you sell into EU financial services, Article 30 of the Digital Operational Resilience Act, Regulation (EU) 2022/2554, prescribes mandatory contractual provisions for ICT third-party service providers, and a regulated customer cannot lawfully sign your standard terms without them.
A newer obligation deserves attention because many SaaS contracts have not caught up with it. The EU Data Act, Regulation (EU) 2023/2854, has applied since 12 September 2025 and treats SaaS as a data processing service. Its switching provisions require your contracts to contain specific exit terms, including a right for the customer to switch on a maximum notice period of two months, a defined transition window, and a clear statement of the categories of data and digital assets that can be ported. Reduced switching charges are permitted for a transitional period, and from 12 January 2027 switching charges are prohibited altogether. This affects existing contracts as well as new ones, so your standard terms almost certainly need revision.
Tier Three: Does Your Company Actually Own Itself?
This is the tier almost nobody gets right, and it decides whether your company owns the thing you are selling.
Start with intellectual property assignment. Where you commissioned a freelancer or an agency to write code, your company does not automatically own it. In most European jurisdictions the author is the initial owner of copyright, and paying an invoice transfers no rights absent a written agreement, so the developer may hold rights in part of your product. The same applies to anything a founder built before the company existed. The employment position is more favourable and worth stating precisely: Article 2(3) of Directive 2009/24/EC on the legal protection of computer programs provides that where a program is created by an employee in the execution of their duties or following the employer’s instructions, the employer exclusively is entitled to exercise all the economic rights, unless the contract says otherwise. So your payroll developers are largely covered by default for software, though not necessarily for design assets, written content, or other non-software works. Contractors, agencies, advisors, and pre-incorporation founder work are the real exposure. None of this surfaces until you raise capital or sell, at which point due diligence asks one question that has no soft answer, which is whether you own your intellectual property. If the paperwork is missing, the price drops or the transaction fails.
Second, register your trade marks. The European Union operates a first-to-file system, so priority generally goes to whoever files first rather than whoever used the name first. Registering your product name and logo as an EU trade mark through the EUIPO, gives you the rights conferred by Article 9 of Regulation (EU) 2017/1001 against identical and confusingly similar signs. Waiting until a copycat or an opportunistic filer registers your name turns a routine filing into an expensive dispute.
Third, protect the code and the know-how behind it. Directive (EU) 2016/943 protects trade secrets, but Article 2(1) makes protection conditional: the information must be secret, have commercial value because it is secret, and have been subject to reasonable steps under the circumstances to keep it secret. Confidentiality agreements, access controls, and documented internal policies are therefore not merely prudent, they are the legal precondition for having a trade secret at all. Watch your open source dependencies at the same time. The distinction that matters for SaaS is that GPLv2 and GPLv3 obligations are triggered by distribution, which hosted software generally does not do, whereas the AGPL closes precisely that gap by treating interaction with users over a network as triggering the obligation to offer corresponding source. A single AGPL dependency in a hosted product can therefore create a disclosure obligation that GPL dependencies would not.
One More You Will Regret Skipping
If you have co-founders, put a founders’ agreement in place covering equity splits, vesting and cliffs, roles and decision-making, what happens on departure, and how intellectual property created by each founder vests in the company. Teams skip this because everyone is currently friends, which is exactly the circumstance in which it is cheap to agree and exactly the group that will need it later. Add a note on your product roadmap as well: if you are building AI features, the EU AI Act adds a further layer. Its transparency obligations under Article 50 began applying on 2 August 2026, while the Digital Omnibus, Regulation (EU) 2026/1744, which entered into force on 27 July 2026, postponed the high-risk obligations for Annex III systems to 2 December 2027 and for Annex I systems to 2 August 2028.
Conclusion
In summary, the stack is short and the sequencing matters more than the volume. Every SaaS needs Terms of Service drafted for the right audience, a Privacy Policy that describes the actual product, and a genuine cookie consent mechanism that holds non-essential scripts until the user opts in. Selling to businesses adds a Data Processing Agreement, sub-processor agreements behind it, a Service Level Agreement, and Data Act compliant switching terms. And the tier that decides whether your company owns itself consists of documented intellectual property transfers from every contractor and founder, registered trade marks filed before somebody else files them, and real confidentiality measures backed by disciplined open source hygiene.
