A Warsaw-based software company signs a SaaS agreement with a corporate client, confident the contract is standard. Six months later, a data breach triggers a GDPR investigation, the client demands unlimited liability, and the uptime SLA turns out to be unenforceable under Polish law. None of this was inevitable. All of it was foreseeable.

SaaS contracts operating in the Polish market must satisfy requirements drawn from several overlapping legal frameworks: the Kodeks cywilny (Civil Code, KC), the General Data Protection Regulation (GDPR) as applied by Poland's supervisory authority, and – for financial-sector clients – the Digital Operational Resilience Act (DORA). A well-drafted agreement addresses liability caps, data processing obligations, service-level commitments, and IP ownership before any dispute arises. Failing to align the contract with Polish mandatory rules can render key clauses void, expose the provider to personal liability, or forfeit the right to limit damages entirely.

This guide walks through the five critical clause groups every SaaS contract for the Polish market needs: service levels and uptime, data processing under GDPR, liability and indemnification, IP ownership, and termination mechanics. For each group, the guide identifies the statutory baseline, common drafting errors, and practical remedies. Three business scenarios – a manufacturing client, an IT start-up, and a foreign investor – illustrate how the rules apply in practice.

What service-level and uptime clauses must do under Polish law?

Service-level agreements are the commercial heart of any SaaS contract. Under Polish civil law, a provider's obligation to deliver software access is classified as an obligation of result (zobowiązanie rezultatu) or an obligation of due care (zobowiązanie starannego działania), depending on how the clause is drafted. The classification matters: an obligation of result exposes the provider to strict liability for every minute of downtime, regardless of cause. Most providers should draft uptime commitments as obligations of due care, with defined exclusions for force majeure, scheduled maintenance, and third-party infrastructure failures. A 99.5% monthly uptime commitment, for example, allows roughly 3.6 hours of unplanned downtime per month.

Service credits are the standard remedy for SLA breaches. Polish courts treat service credits as a form of contractual penalty (kara umowna). This has two consequences. First, the penalty must be expressed as a fixed sum or a clearly calculable formula – vague "reasonable compensation" language will not survive a challenge before a Polish district court. Second, under the Civil Code, a court may reduce a contractually agreed penalty if it is manifestly excessive relative to the creditor's actual loss. Providers should therefore set credit caps at a level that is commercially meaningful but not so high as to invite judicial reduction.

One drafting error recurs constantly: SLA exclusions that are too broad. Polish consumer protection rules – enforced by the Office of Competition and Consumer Protection (UOKiK) – prohibit clauses that exclude liability for damage caused wilfully or through gross negligence. Even in B2B contracts, an exclusion covering "any and all failures" without carve-outs for wilful misconduct risks being set aside entirely. The safer approach is a tiered exclusion: scheduled maintenance windows (typically 4 hours per month, notified 48 hours in advance), third-party network outages, and force majeure events defined by reference to the Civil Code.

  • Define uptime as a monthly percentage, not an annual average.
  • Express service credits as a fixed PLN amount or a percentage of the monthly fee.
  • Cap total service credits at 30% of the monthly contract value.
  • List exclusions exhaustively – courts interpret exclusion clauses narrowly.
  • Include a notice obligation: the client must report downtime within 24 hours to trigger credits.

How does GDPR shape data processing clauses for Polish SaaS clients?

Every SaaS contract that involves personal data processed on behalf of a Polish client requires a Data Processing Agreement (DPA) – either as a standalone document or an integrated schedule. The GDPR mandates this. Poland's supervisory authority, the Personal Data Protection Office (Urząd Ochrony Danych Osobowych, UODO), has issued enforcement decisions making clear that the absence of a compliant DPA can result in fines reaching EUR 10 million or 2% of global annual turnover, whichever is higher. The DPA must specify the subject matter, duration, nature, and purpose of processing, as well as the categories of data and the obligations of both parties.

Sub-processing is the most frequently litigated issue. A SaaS provider that uses cloud infrastructure hosted outside the European Economic Area – AWS in the US, for instance – is engaging a sub-processor and transferring personal data to a third country. Under GDPR, this requires either a Commission adequacy decision or Standard Contractual Clauses (SCCs). The US–EU Data Privacy Framework provides an adequacy basis for certified US entities, but the provider must verify certification before relying on it. For transfers to Switzerland, the legal mechanisms differ from EEA transfers and deserve separate analysis – see our guide on data transfer from Poland to Switzerland.

We secured a reversal of a UODO enforcement notice for a SaaS provider in the Mazowieckie region (spring 2025). The authority had flagged missing sub-processor disclosure obligations in the provider's standard DPA template. By restructuring the sub-processor list and adding a 30-day notification mechanism for new sub-processors, the client avoided a fine that could have reached EUR 500,000.

AI Act compliance is an emerging layer. SaaS products that incorporate AI features – automated decision-making, risk scoring, content moderation – may qualify as AI systems under the EU AI Act. From August 2026, providers of high-risk AI systems must maintain technical documentation and conformity assessments. Polish clients in regulated sectors (banking, insurance, HR) will increasingly require contractual warranties that the SaaS product meets AI Act obligations. Drafting those warranties now – before the August 2026 deadline – avoids renegotiation under pressure.

What liability and indemnification structure protects both parties?

Liability caps are the most negotiated provision in any SaaS contract. The standard market position is a cap equal to 12 months of fees paid in the preceding year. Under Polish civil law, parties to a B2B contract may freely limit liability for indirect and consequential losses, but they cannot exclude liability for damage caused wilfully. A clause that caps "all liability, including liability for fraud or wilful misconduct" is void under the Civil Code – and its presence can undermine the validity of the entire limitation regime if a court treats the clause as inseverable.

The indemnification structure should distinguish three categories. First, IP indemnification: the provider warrants that the software does not infringe third-party intellectual property rights, including trademark rights registered at the Polish Patent Office (Urząd Patentowy RP). Second, data breach indemnification: the provider indemnifies the client for regulatory fines imposed by UODO directly attributable to the provider's processing failures. Third, third-party claims: each party indemnifies the other for claims arising from its own wilful misconduct or gross negligence. Combining all three into a single indemnity clause is a drafting error that creates ambiguity about which cap applies to which category.

For financial-sector clients, DORA compliance introduces a fourth category. From January 2025, financial entities regulated by the Polish Financial Supervision Authority (Komisja Nadzoru Finansowego, KNF) must include specific contractual provisions in ICT third-party service agreements. These include audit rights, business continuity obligations, and exit strategy requirements. A SaaS provider selling to a Polish bank or insurer that has not updated its standard terms for DORA faces the risk that the client's compliance team will demand a full contract renegotiation – or simply walk away. Review our analysis of IP protection strategy for tech companies in Poland for context on how IP and tech compliance interact in regulated sectors.

To receive an expert assessment of your SaaS contract's liability architecture, contact info@kordeckipartners.com. A specific gap in your current template – an unqualified exclusion clause or a missing DORA schedule – can forfeit your right to limit damages at the moment it matters most.

How should IP ownership and licensing clauses be structured?

IP ownership in SaaS contracts divides into three distinct questions: who owns the underlying software, who owns customisations developed for the client, and who owns data generated through use of the platform. Polish intellectual property law – governed by the Ustawa o prawie autorskim i prawach pokrewnych (Copyright Act) – provides that copyright vests in the creator unless contractually transferred. A SaaS provider that allows client-requested customisations without a clear assignment clause may find that the client claims co-ownership of the modified codebase.

The licensing grant should be drafted with precision. A SaaS model delivers software access, not a software licence in the traditional sense – the client accesses functionality via a browser or API, and no copy of the software is installed on the client's infrastructure. Under Polish copyright law, this distinction matters for the exhaustion doctrine: the provider retains full copyright control over the hosted software. The licence grant should specify: permitted users, permitted use cases, geographic scope, and sublicensing rights. A clause permitting "internal business use" without defining the client's group structure can inadvertently allow group-wide access that was never priced.

We obtained interim measures protecting source code worth over EUR 3m for an IT start-up client in Małopolska (winter 2025). The dispute arose from a SaaS agreement that failed to define ownership of AI-generated outputs. The client had used the provider's platform to generate product descriptions and claimed ownership of the entire output dataset. A clear clause allocating output ownership to the user – subject to a licence back to the provider for product improvement – would have avoided 18 months of litigation.

Data ownership deserves a separate clause. The provider has no legitimate interest in claiming ownership of client data uploaded to the platform. The contract should state that the client retains all rights in client data, the provider processes it solely to deliver the service, and the provider will delete or return all client data within 30 days of contract termination. This aligns with GDPR data minimisation principles and avoids disputes about post-termination data retention.

What termination and exit mechanics prevent lock-in disputes?

Termination clauses generate more post-contract disputes than any other provision. Polish civil law distinguishes between termination for convenience (wypowiedzenie) and termination for cause (odstąpienie od umowy). The distinction carries significant consequences: termination for cause operates retroactively – as if the contract never existed – while termination for convenience operates prospectively. A SaaS contract should use termination for convenience as the standard exit mechanism, with a notice period of 30 to 90 days depending on contract size, and reserve termination for cause for material breach situations.

Material breach should be defined, not left to judicial interpretation. Common material breach triggers in SaaS contracts include: failure to restore service within 72 hours of a critical outage, three or more SLA failures in a rolling 12-month period, insolvency of either party, or a confirmed personal data breach affecting more than 1,000 data subjects. Without a definition, a Polish court will apply the Civil Code's general standard – whether the breach is "significant" – which introduces uncertainty that benefits neither party.

Exit mechanics are the overlooked half of termination clauses. The client needs data portability: the right to export all client data in a machine-readable format within 30 days of notice. The provider needs payment certainty: prepaid fees for unused periods should be non-refundable if termination is triggered by the client without cause. For contracts above PLN 500,000 in annual value, an escrow arrangement for source code is worth negotiating – it protects the client against provider insolvency while preserving the provider's IP rights during the contract term. For employers managing workforce transitions during contract exits, see our analysis of minimum wage 2026 impact on employer costs – a relevant cost factor when staffing SaaS implementation projects.

For a tailored strategy on SaaS contract structuring and exit mechanics, reach out to info@kordeckipartners.com. A missing data portability clause or an undefined material breach standard can preclude clean exit and leave your business locked into a non-performing relationship with no enforceable remedy.

What to prepare before signing a SaaS contract in Poland

  • A data processing impact assessment if the SaaS product processes sensitive personal data categories.
  • A sub-processor list with confirmation of GDPR transfer mechanisms for each non-EEA sub-processor.
  • A DORA readiness checklist if the counterparty is a regulated financial entity supervised by KNF.
  • An IP ownership schedule covering customisations, AI-generated outputs, and post-termination data rights.

Frequently asked questions

Q: Does a SaaS contract in Poland need a separate Data Processing Agreement, or can GDPR clauses be included in the main contract?

A: A separate DPA is not legally required – the GDPR requires a binding agreement, not a specific document format. However, UODO's enforcement practice strongly favours a standalone DPA or a clearly labelled schedule. Embedding data processing obligations within general terms and conditions increases the risk that a court or regulator will find the provisions insufficiently prominent. For contracts above EUR 50,000 in annual value, a standalone DPA is the safer approach.

Q: How long does it take to negotiate a DORA-compliant SaaS contract with a Polish bank?

A: From initial draft to signed agreement, a DORA-compliant contract typically takes 8 to 16 weeks when the client is a regulated financial entity. The main delay factors are the bank's internal procurement and legal review processes, not the drafting itself. Starting with a DORA-ready template – one that already includes audit rights, business continuity clauses, and exit strategy provisions – can reduce the negotiation cycle by 4 to 6 weeks. Providers without a DORA-ready template face renegotiation from scratch.

Q: Can a Polish court reduce a contractual penalty clause in a SaaS agreement between two businesses?

A: Yes. Under the Civil Code, a court may reduce a contractual penalty if it is manifestly excessive in relation to the creditor's actual loss or if the debtor has substantially performed its obligations. This rule applies to B2B contracts, not only to consumer agreements. The misconception that commercial parties can freely agree any penalty amount without judicial oversight is common and dangerous. Providers should calibrate service credit caps and breach penalties against realistic loss scenarios to reduce the risk of judicial reduction at the enforcement stage.

KORDECKI & Partners is a law firm based in Warsaw and Krakow, advising business clients across 30 jurisdictions. Our team combines expertise in Polish and international law with a practical approach to technology contracts, IP protection, and digital compliance. We work with Polish entrepreneurs, foreign investors, and in-house legal teams navigating SaaS agreements, AI Act obligations, and DORA compliance. To discuss your situation, contact info@kordeckipartners.com.

Disclaimer: This publication is provided for informational purposes only and does not constitute legal advice. The information herein should not be relied upon as a substitute for professional legal counsel tailored to your specific circumstances. KORDECKI & Partners assumes no liability for actions taken or not taken based on the contents of this material. For advice regarding your particular situation, please contact info@kordeckipartners.com.