Getting SaaS Off to a Legal Start. What to Put in Place Before You Scale Sales

Your SaaS has paying customers, a quarterly roadmap, and ambitious sales plans. But if an enterprise client asked for a DPA, an SLA, and clear rules on data responsibility tomorrow, how long would your team need to respond? If the answer is more than one day, this article is for you.

The SaaS sales model is developing faster than the documentation. The product works, customers are paying, and the team is growing, yet the rules governing use of the service, data processing, and billing still rely on a generic terms-of-service template or do not exist at all. This is the first sign of impending operational chaos.

Below, you will find a structured overview of the legal groundwork you need to put in place before scaling SaaS sales. I discuss specific obligations under Polish and EU law, the risks of overlooking them, and practical steps, from the operational minimum to comprehensive protection.

Key concepts you need to know

Before we continue, here are a few terms that will appear throughout the article.

Which laws apply to your SaaS

A SaaS provider operating in Poland is subject to several pieces of legislation at the same time. None of them expressly uses the term “SaaS”, but each covers this business model within its scope.

Act on the Provision of Electronic Services

Article 2(4) defines a service provided electronically as one performed remotely, without the parties being simultaneously present, through the transmission of data at the individual request of the service recipient. SaaS meets all these criteria.

Article 8(1) requires you to have terms of service and make them available to the user free of charge before the agreement is concluded, in a way that allows the content to be accessed, reproduced, and retained.

The minimum required content of the terms of service (Article 8(3)):

1. Types and scope of services
2. Conditions of service provision (technical requirements, prohibition of unlawful content)
3. Conditions for entering into and terminating agreements
4. Complaint procedure

Consequence: if the terms of service have not been made available in the required manner, the user is not bound by them (Article 8(2)). As the service provider, you bear the burden of proof.

GDPR, obligations relating to user and customer data

In the B2B SaaS model, the business customer is the controller of its users’ data, while you, as the provider, are the processor. With respect to your own data processing activities (billing, marketing, analytics), you are the controller. These two roles require separate documentation.

Consumer Rights Act

If you sell to consumers (B2C) or use a mixed model:

1. Article 27, a consumer has the right to withdraw from a distance contract within 14 days without giving a reason
2. If you do not inform the consumer of this right, the period is extended to 12 months
3. Articles 12-17, extensive pre-contractual information obligations: the main characteristics of the service, the trader’s details, the total price, payment methods, and the right of withdrawal

Failure to provide reliable information about the right of withdrawal may be classified by UOKiK as a practice infringing the collective interests of consumers.

Digital Services Act (DSA)

The DSA has applied directly since 17 February 2024. Any SaaS service that stores data entered by users at their request (a CRM, project management tool, or e-learning platform) is at least a hosting service within the meaning of the DSA.

The good news is that microenterprises (fewer than 10 employees, turnover of up to EUR 2 million) and small enterprises (fewer than 50 employees, turnover of up to EUR 10 million) are exempt from the most burdensome DSA obligations. However, they are still required to:

1. Establish a point of contact for authorities and users
2. Clearly set out any restrictions and content moderation practices in their terms and conditions
3. Implement a mechanism for reporting illegal content
4. Refrain from using dark patterns, manipulative interfaces

The VLOP/VLOSE thresholds (45 million active monthly users) and the DMA threshold (turnover of EUR 7.5 billion) do not apply to Polish SaaS startups. Fines for DSA infringements can reach up to 6% of annual worldwide turnover.

Contact us, we will help you determine which laws apply to your model and what they mean for your documentation.

Risks created by inadequate documentation

Generic terms of service taken from a template provide only the illusion of protection: they will not help in a dispute, answer a B2B customer’s questions, or pass due diligence. Below are the specific risks, organised by category.

Legal and financial risks

UODO fines. In 2024, the President of UODO issued 22 decisions imposing financial penalties. Although none directly concerned a company described as “SaaS” (UODO does not categorise decisions by business model), many involved entities operating in digital environments and processing data in IT systems. Examples include:

1. V. sp. z o.o., a fine of PLN 3,819,960 for failing to implement appropriate security measures for ICT systems and breaching the principle of data integrity and confidentiality (source: UODO)
2. Morele.net, a fine of more than PLN 3.8 million for data security breaches that led to a major customer data leak
3. McDonald’s Polska, fines totalling PLN 16,932,657 for the controller and PLN 183,858 for the processor, UODO examined the actual allocation of roles between the parties rather than relying solely on contractual labels

UOKiK fines. In 2024, UOKiK imposed fines totalling more than PLN 937 million, including more than PLN 263 million for infringements of consumers’ collective interests and unfair contract terms. It initiated 41 proceedings and concluded 70 cases by issuing decisions. Canal+ Polska was charged with adding services for consumers without their express consent, a principle that also applies to automatically activating paid SaaS features.

Operational and sales risks

Risks during an investment round

An investor conducting due diligence will review your legal documentation. If the terms of service do not match the model, no DPA exists, and supplier relationships have no contractual basis, the valuation drops or the investment round is delayed. The cost of putting things in order at the outset is a fraction of the cost of catching up under the pressure of a deadline, dispute, or funding round.

What to put in order and in what sequence

You do not have to do everything at once. Below are three levels of SaaS legal maturity, from the operational minimum to comprehensive protection.

Three levels of SaaS legal readiness

Terms of service, not a template, but a reflection of your model

SaaS terms of service are not a “box-ticking document”. They set out the rules governing the entire relationship with the user, from registration and payment through use of the service and support to termination and data deletion.

A generic online template does not account for the specifics of your model: whether you offer a free trial, whether the trial automatically converts into a paid plan, what happens to data after the trial ends, what limitations apply to the demo, or how the enterprise plan differs from the standard plan.

What to pay attention to:

1. Legal classification of the agreement, a SaaS agreement is better described as a “right to access the service” than as a licence. The user does not perform acts covered by the copyright holder’s exclusive rights (they do not copy the code). This classification affects the scope of liability, the procedure for terminating the agreement, and the nature of claims.
2. Rules for amending the terms of service, a unilateral right to make changes without a valid reason and without giving the user a right to cancel may be considered an unfair contract term (Article 385¹ of the Polish Civil Code).
3. Exit plan, procedures for exporting customer data, the retention period after the service ends, and the right to transfer data to another provider. Enterprise customers look for this information in the documentation before signing an agreement.
4. B2B vs. B2C differences, different consumer rights (14 days to withdraw), different liability clauses, and different complaint procedures. If you use a mixed model, you need separate versions or clearly marked sections.

DPA, the document you need to sell to enterprise customers

An enterprise customer will ask about a DPA before asking about the price. Without a ready-made data processing agreement, every deal requires individual negotiation, slowing sales and generating legal costs.

What a DPA must contain under Article 28(3) of the GDPR:

1. The subject matter and duration of processing
2. The nature and purposes of processing
3. The type of data and categories of data subjects
4. The obligations and rights of the controller (the customer)
5. A commitment to process data only on the controller’s documented instructions
6. Confidentiality obligations for persons authorised to process the data
7. Security measures under Article 32 of the GDPR
8. Conditions for engaging subprocessors (hosting, APIs, integrations), where general authorisation is given, an obligation to provide notice of changes and a right to object
9. Assistance to the controller in fulfilling data subject rights (access, deletion, portability)
10. Deletion or return of data after the service ends

The McDonald’s Polska case shows that UODO examines the actual allocation of roles between the controller and processor, simply assigning labels in an agreement is not enough if the actual relationship looks different.

SLA, even a simple one is better than none

SaaS providers rarely guarantee an SLA, and when they do, it is usually standardised and limited. B2B customers, however, expect specific parameters.

A typical benchmark is 99.9% monthly availability, which means a maximum of approximately 43 minutes of downtime per month. Even if you cannot guarantee this level initially, document what you can offer:

1. Guaranteed availability level (e.g. 99.5%)
2. Definition of maintenance windows (scheduled interruptions that do not count as downtime)
3. Response times for support requests (e.g. critical, 4 hours, standard, 24 hours)
4. Compensation for failure to meet the agreed parameters (e.g. a subscription extension or account credit)
5. Support channels and support availability hours

No SLA does not mean no liability, it means no clear rules, which leads to disputes and damages claims from B2B customers.

Allocation of responsibility for security

In a standard SaaS agreement, responsibility for security is divided between the provider and the customer:

This division must be clearly documented. In the event of an incident, a lack of precise rules means chaos, and a risk that all liability will fall on you.

What changes when you expand internationally

Documentation prepared for the Polish market is not enough when scaling into EU or US markets.

Differences within the EU

1. GDPR applies throughout the EU, but individual countries have different implementing provisions (e.g. the age of digital consent and requirements relating to DPOs)
2. Directive 2019/770 on contracts for the supply of digital content and digital services, implemented in Poland as of 1 January 2023, imposes additional obligations toward consumers
3. NIS2, a cybersecurity directive whose Polish implementation (an amendment to the Act on the National Cybersecurity System) is in progress. If your SaaS operates in a sector covered by NIS2 (energy, transport, healthcare, digital infrastructure, finance), additional information security management obligations will apply

Data transfers outside the EEA

If you use US infrastructure (AWS, GCP, Azure) or sell to customers in the US:

1. EU-US Data Privacy Framework, the European Commission’s decision of 10 July 2023 allows data to be transferred to certified entities in the US without additional safeguards
2. Standard Contractual Clauses (SCCs), Decision 2021/914, required for transfers to non-certified entities or to countries without an adequacy decision
3. US regulatory differences, an opt-out model (as opposed to the European opt-in model); state privacy laws: CCPA/CPRA (California), VCDPA (Virginia), MODPA (Maryland), and others

Conclusion: when expanding internationally, you need to verify whether your documentation meets the requirements of the target market, and whether data transfer mechanisms are contractually secured.

Infrastructure providers, the hidden risk in the chain

Your SaaS relies on hosting, APIs, integrations, and analytics tools. Each of these providers may be a subprocessor of your customers’ data.

What to check:

1. Whether you have written agreements with every infrastructure provider
2. Whether the agreements contain DPA clauses (entrustment of data processing)
3. What SLAs your providers guarantee, and whether your SLA to customers promises more than your providers deliver
4. How liability is allocated along the chain: hosting provider → you → your customer
5. Where the data is physically stored (data centre locations)
6. What happens to the data after your relationship with the provider ends

A lack of supplier contracts shifts all the risk to you. If your hosting goes down and you have no contractual basis for claiming compensation, you cover the losses out of your own pocket and remain liable to your customers.

How to implement documentation so that it actually works

Documentation that merely “exists” but does not support onboarding, sales, and customer service is a dead layer of formality, it costs money without protecting you. A few principles will increase the likelihood that the documents are actually used:

1. Prepare a checklist for the sales team, what to tell customers about the terms, where to direct them for details, and how to respond to questions about DPAs and SLAs
2. Synchronise documentation with the product roadmap, every change to the pricing model, new feature, new market, or new customer segment should trigger a review of the documents
3. Schedule regular reviews, for example, quarterly, aligned with the product development cycle
4. Train the team, sending a link to the terms of service is not enough. People working with customers need to understand why the documentation is structured the way it is
5. Decide who is responsible for updates, the founder, COO, Head of Operations, or external legal adviser, but not “nobody”

How we can help you

Putting your SaaS legal framework in order is not about “drafting a few documents”. It means translating your product and sales model into a set of rules that can be implemented and support the team’s day-to-day work.

We work with founders, CTOs, and product leaders at technology companies, from startups to scale-ups. We understand how SaaS teams operate: rapid iterations, parallel projects, limited resources, and pressure to deliver results.

Our support includes:

1. SaaS model assessment, we map the customer journey from registration through payment, use, and support to service termination, and compare it with the current documentation
2. Drafting terms of service that reflect how the product actually works, separately for B2B and B2C if you use a mixed model
3. Structuring the GDPR layer, the parties’ roles, DPA, privacy policy, record of processing activities, and breach notification procedure
4. Defining the SLA and support rules, tailored to the company’s stage and the expectations of its customer segment
5. Reviewing supplier agreements, hosting, APIs, and integrations, with regard to DPAs, SLAs, and liability along the chain
6. Preparing the company for due diligence, organising legal and operational documentation before a funding round

We do not create documents “just in case”. We design rules where risks or value actually arise, from development to sales.

Put the foundations in order before you scale

Scaling SaaS without a well-structured legal framework is like building on a foundation no one has inspected. It may hold, but every new customer, new market, and new funding round increases the load.

Three final takeaways:

1. Terms of service, DPAs, SLAs, and privacy policies are not formalities, they are tools that accelerate sales, reduce disputes, and build trust among B2B customers
2. The cost of putting documentation in order at the outset is a fraction of the cost of catching up under the pressure of a deadline, dispute, or funding round
3. Documentation must reflect how the product actually operates, a generic template will not protect you in a dispute or during due diligence

If you are planning a launch, entering the B2B segment, or preparing for a funding round, get in touch. Let’s discuss your SaaS model and determine what should be put in order before the next step.

Frequently asked questions

What exactly do I need to have legally in place before my first commercial SaaS sale?

At a minimum, you need: terms of service compliant with Article 8 of the Act on the Provision of Electronic Services (types of services, technical requirements, rules for entering into and terminating agreements, complaints), a privacy policy compliant with Article 13 of the GDPR, cookie information, and clear payment and service termination terms. If you sell to consumers (B2C), you must also inform them of their right to withdraw from the agreement within 14 days, otherwise, the period is extended to 12 months.

Are template terms of service enough to get started?

A generic template may meet the minimum formal requirements, but it will not reflect your actual SaaS model, trial rules, automatic conversion to a paid plan, upgrades/downgrades, or the exit plan. In a dispute or during a UOKiK inspection, what matters is whether the terms reflect the actual conditions under which the service is provided. If your sales promises do not match the documentation, you risk customer claims and allegations of using unfair contract terms.

What is a DPA and when do I need one?

A DPA (data processing agreement) is a document required under Article 28 of the GDPR when you process personal data on behalf of a customer. In the B2B SaaS model, your customer is the data controller and you are the processor. You need to have a DPA ready before your first sale to a business customer. Enterprise customers will not sign an agreement without a DPA, the absence of this document blocks sales and slows contract closure.

How does SaaS documentation differ between B2B and B2C?

In the B2C model, consumer rights laws apply: a 14-day right of withdrawal, extensive information obligations, and a prohibition on unfair contract terms enforced by UOKiK (with fines of up to 10% of turnover). In the B2B model, the parties have greater contractual freedom, you can limit liability, exclude the right of withdrawal, and negotiate individual SLA terms. If you use a mixed model, you need separate versions of the terms of service or clearly marked sections for each segment.

How should I prepare for enterprise customer questions about SLAs and data security?

Document what you can offer, even if it is simple at first. Define the guaranteed availability level, maintenance windows, support request response times, and compensation for failure to meet the agreed parameters. Describe the allocation of responsibility for security: you are responsible for the infrastructure and application, while the customer is responsible for managing user access. Prepare information about data locations, subprocessors, and backup procedures. Even a simple document provides a point of reference and demonstrates provider maturity.

How long does it take to put the legal foundations of a SaaS business in order?

It depends on the complexity of the model and the company’s stage. The operational minimum (terms of service, privacy policy, payment terms) can be prepared within 2-4 weeks. A solid foundation including a DPA, SLA, and separate B2B/B2C documentation takes 4-8 weeks. Comprehensive protection involving a subprocessor audit, review of supplier agreements, and due diligence preparation takes 2-3 months. Putting things in order does not have to delay the launch, you can start with the minimum and expand the documentation as you scale.