If your SaaS product logs IP addresses, records session logs, or tracks user activity on a dashboard, it processes personal data. Even if none of your forms asks for a first name, surname, or PESEL number.
The GDPR defines personal data broadly: any information relating to an identified or identifiable natural person, including online identifiers. An IP address, cookie identifier, and session ID all fall within the definition in Article 4(1) of the GDPR. This was confirmed by the Court of Justice of the EU in case C-582/14 (Breyer) and, in Poland, by the Supreme Administrative Court in judgment I OSK 1079/10.
For a founder or CTO, this means one thing: your SaaS agreement must address personal data from day one. Not after an audit. Not before an inspection by the Polish data-protection authority, UODO. From the moment the first user logs into the system.
This article explains when a SaaS provider becomes a data controller, which technical features of your product generate personal data, what most SaaS agreements are missing, and how to build GDPR compliance into the product backlog instead of last-minute documentation.
Personal data in SaaS: what to know before you go further
Before we get to specific scenarios, let’s clarify a few concepts used throughout this article.
| Term | Meaning in a SaaS context |
|---|---|
| Personal data (Article 4(1) GDPR) | Any information about an identifiable person, directly or indirectly, for example through an IP address, cookie identifier, or session ID |
| Data controller (Article 4(7) GDPR) | An entity that independently determines the purposes and means of processing, deciding why and how data is collected |
| Data processor (Article 4(8) GDPR) | An entity that processes data only on behalf of a controller and on its documented instructions |
| Data-processing agreement (Article 28 GDPR) | An agreement between the controller and processor setting out the scope, purpose, and rules of data processing |
| Privacy by Design (Article 25 GDPR) | The duty to account for data protection in product architecture from the design stage |
| Pseudonymization (Article 4(5) GDPR) | Processing data so it cannot be attributed to a specific person without additional information; the data remains personal data |
One point to remember: Recital 26 of the GDPR says that identifiability must be assessed by considering all means reasonably likely to be used, including the costs, time, and available technology. If your system stores an IP address alongside a user account ID, identification is not merely likely. It is trivial.
When your SaaS becomes a data controller: scenarios from everyday product architecture
Most SaaS providers assume they act only as processors because the client decides what data its users enter. That assumption may be wrong.
A SaaS provider becomes a controller for any processing purpose it determines independently. The question is not what the agreement calls the parties. It is who actually makes the decisions.
Criteria that determine controller status
| Criterion | Processor | Controller |
|---|---|---|
| Who decides what data is collected? | The client | The SaaS provider |
| Who sets the data-retention period? | The client | The SaaS provider |
| Who uses data for its own analytics? | No one; data is used only for the client | The SaaS provider |
| Who combines data from multiple clients? | No one; data is isolated by tenant | The SaaS provider |
| Who decides which form fields are mandatory? | The client | The SaaS provider |
Practical scenarios
Recruitment system (ATS). If the provider creates a central candidate database available to multiple employers or uses candidate data to build matching algorithms, it becomes a controller. A candidate may then have two controllers: the employer and the ATS provider.
Time-tracking system. If the provider stores data longer than required by labor law, for example, to produce sector statistics, it becomes a controller for that processing.
Analytics and benefits modules. If the provider generates reports such as “benefit preferences in the IT sector” or “effectiveness of incentive programs” and offers them as standalone products, it becomes a controller of the data used to create those reports.
Precedent: UODO decision concerning McDonald’s Polska (DKN.5131.5.2025)
The President of UODO found McDonald’s Polska to be a controller of the personal data of franchisees’ employees because the company determined the functionality of the SaaS workforce-scheduling system and the scope of data collected. The combined fine was over PLN 16.9 million for the controller and over PLN 183,000 for the processor.
Takeaway: designing a system and deciding on its functionality may lead to the SaaS owner being treated as the controller of all users’ data. The wording of the SaaS agreement does not change the objective nature of the relationship.
Multi-tenant architecture and controller status
If you combine data from different tenants to create global statistics, develop new features, or produce benchmarks, you become a controller of all users’ data. If data is processed only within a given tenant and is not combined, you may remain a processor.
The same logic applies to white-label architecture: if a white-label provider uses user data for its own purposes, it becomes a controller, even if it remains “invisible” to the end user.
IP addresses, cookies, and session logs: what counts as personal data in your web application?
Every web application generates technical data whenever a user connects. The question is not “Do you collect personal data?” but “How much do you collect, and are you aware of it?”
IP address
A dynamic IP address is personal data if the service provider has legal means to identify the user, for example by obtaining information from the internet service provider. That is what the CJEU held in case C-582/14 (Breyer). In judgment I OSK 1079/10, the Supreme Administrative Court confirmed that information relates to a person both when it refers to them directly and when it refers to their devices but can be linked to a specific person, and thus indirectly provides information about that person.
UODO treats IP addresses similarly to PESEL numbers and vehicle registration numbers.
Cookies
Recital 30 of the GDPR expressly mentions cookie identifiers as examples of online identifiers that may be used to create profiles of natural persons. UODO confirms that a cookie identifier and an IP address assigned to a device uniquely identify a natural person in the digital environment.
The CJEU judgment in case C-673/17 (Planet49) established that consent to cookies must involve an active action. Pre-ticked boxes are not valid consent. Read more about cookie consent.
Server logs and session logs
Typical HTTP server logs contain:
- The user’s IP address
- The date and time of the connection
- The requested URL
- The response status code
- The amount of data transferred
- Browser information (user agent)
- The logged-in user ID or session ID
Session logs document a user’s sequence of actions from login to logout: pages visited, actions performed, and time spent in each module. Combining an IP address, cookie identifier, and session logs allows detailed reconstruction of a specific person’s activity.
Standard server configurations store complete identifying data. Server logs are not anonymous by nature. Pseudonymization, replacing direct identifiers with random strings, reduces risk, but the data remains personal data under the GDPR.
Obligations that follow
| Data type | Typical legal basis | Information duty |
|---|---|---|
| IP addresses and session logs for security purposes | Controller’s legitimate interest (Article 6(1)(f) GDPR) | Yes, Article 13 GDPR |
| Analytics or marketing cookies | User consent (Article 6(1)(a) GDPR) | Yes, Article 13 GDPR and active consent |
| Behavioral data for profiling | Consent or legitimate interest, depending on context | Yes, Article 13 GDPR and profiling information (Article 22) |
A leak of server logs containing IP addresses and cookie identifiers may be a personal-data breach that must be reported to UODO within 72 hours (Article 33 GDPR). If the breach is likely to create a high risk, affected natural persons must be informed (Article 34 GDPR). See our guidance on reporting a GDPR personal-data breach.
What most SaaS agreements are missing: data processing, party roles, and processing scope
Article 28(3) of the GDPR specifies what a data-processing agreement must contain. Nevertheless, many commercial SaaS agreements do not meet these requirements.
Common gaps in SaaS agreements
1. No clear definition of the parties’ roles. Many SaaS terms do not expressly state that the client is the controller and the provider is the processor. They use vague wording such as “data processing in accordance with the privacy policy.” They also fail to consider joint controllership (Article 26 GDPR) or a change of role depending on the module.
2. Processing scope and purpose are not specific. The agreement should state which categories of data are processed, which categories of people are involved, for what purpose, and for how long. A generic phrase such as “data necessary to provide the service” is not enough.
3. No sub-processing rules. Article 28(2) GDPR requires that a processor not use another processor, for example, a cloud or analytics provider, without the controller’s prior specific or general authorization. Many SaaS agreements omit this or regulate it too vaguely.
4. No breach-notification procedure. A processor must inform the controller without undue delay about a personal-data breach. The agreement should specify the deadline, form, and communication channel. Without this clause, the controller may miss the 72-hour deadline for reporting to UODO.
5. No rules for deleting or returning data when the agreement ends. Article 28(3)(g) GDPR requires a processor, at the end of services, to delete or return the data, at the controller’s choice. Many SaaS agreements do not regulate the export process or the format in which data will be returned.
6. No data-location terms. The agreement should state where data is stored and whether it may be transferred outside the European Economic Area. The NASK template (EZD RP agreement) expressly prohibits transfers outside the EEA without the controller’s prior written consent. See our guidance on transfers of personal data outside the EEA.
7. No right to audit. Article 28(3)(h) GDPR requires a processor to provide the controller with information needed to demonstrate compliance and allow audits. Many SaaS agreements omit this right or limit it to an annual SOC 2 report.
8. No division of responsibility for security. SaaS agreements should clearly specify who is responsible for infrastructure and application security (the provider) and who manages user access and protects login credentials (the client). Without this division of responsibility, each party may assume the other is responsible. See our guidance on allocating responsibility in agreements.
UODO decision DKN.5112.11.2021 emphasized that both the controller and the processor are responsible for ensuring a proper data-processing agreement is concluded. A missing or incomplete agreement affects both parties.
Minimum elements of a SaaS data-processing agreement
| Element | GDPR requirement | Common gap in SaaS agreements |
|---|---|---|
| Subject matter and duration of processing | Article 28(3) | Vague wording |
| Nature and purpose of processing | Article 28(3) | Missing or too broad |
| Types of data and categories of people | Article 28(3) | No data list |
| Sub-processing rules | Article 28(2) | Missing or automatic authorization |
| Breach-notification procedure | Article 28(3)(f) | No deadlines or channels |
| Data deletion or return at the end | Article 28(3)(g) | No export process |
| Right to audit | Article 28(3)(h) | Missing or restricted |
| Data location | Article 28(3) | Location not specified |
Privacy by Design at the product stage: build GDPR compliance into the backlog
Article 25 GDPR requires controllers to implement appropriate technical and organizational measures both when determining how data will be processed and during processing itself. This is not a documentation duty. It is an architectural duty.
What this means for the product team
Privacy by Design requires data protection to be considered at the concept stage, not in documentation prepared just before release. In practice, this means building GDPR requirements into the Definition of Ready (DoR) and Definition of Done (DoD) for every user story that touches user data.
How to build GDPR into the backlog
- DoR (Definition of Ready), before work starts. Every user story involving user data should answer these questions before entering a sprint: what data is collected, on what legal basis, for how long, who has access, and whether user consent is required.
- DoD (Definition of Done), a condition for closing the task. The task is not complete until requirements are met: the privacy notice is updated if the data scope changed; mechanisms for user rights, including deletion, export, and restriction, are implemented; data minimization under Article 5(1)(c) GDPR is applied; and access controls are tested.
- Data Protection Impact Assessment (DPIA) for new features. Article 35 GDPR requires a DPIA when processing may create a high risk to people’s rights and freedoms. The EDPB identifies nine high-risk criteria, including profiling, large-scale processing, and combining datasets. The President of UODO published a list of processing operations requiring a DPIA on 17 June 2019. If a new SaaS feature meets even two of these criteria, conduct a DPIA before it enters development.
- User rights as functional requirements. The right to erasure (Article 17 GDPR), restriction of processing (Article 18), objection (Article 21), and not to be subject to automated decisions (Article 22) are not abstract legal concepts. They are product requirements. If an analytics dashboard automatically scores users based on activity logs, Article 22 GDPR requires that users be able to object.
- Data retention as a configurable setting. The storage-limitation principle (Article 5(1)(e) GDPR) requires data not to be kept longer than necessary for its processing purpose. Instead of hard-coding retention periods, make them configurable so each client, as controller, can set its own rules.
- Information duties as part of the user interface. Article 12 GDPR requires information about data processing to be given “in a concise, transparent, intelligible and easily accessible form, using clear and plain language.” This is a UX/UI requirement. A privacy policy hidden in the website footer as a PDF does not meet the standard. Article 13 GDPR requires at least 11 categories of information for the person whose data is collected, including the controller’s identity, processing purposes, data recipients, retention period, and profiling information. See our guide to a GDPR-compliant privacy and cookies policy.
Checklist: what to check in a SaaS agreement before an enterprise deployment
Before each enterprise deployment, review the points below. This is not an exhaustive list, but it covers areas where gaps most often arise.
Data-processing agreement
- Does the agreement expressly state who is the controller and who is the processor?
- Does it identify specific categories of personal data and the categories of people whose data is processed?
- Does it specify the purpose and scope of processing in relation to specific product features, rather than in generic terms?
- Does it regulate sub-processing, including the current list of subprocessors?
- Does it define the breach-notification procedure, including the deadline, form, and channel?
- Does it specify data location and rules for transfers outside the EEA?
- Does it regulate the controller’s right to audit?
- Does it specify how data will be deleted or returned at the end of the agreement, including the export format?
Product architecture
- Is each client’s data isolated by tenant, or is it combined for analytics?
- Can each client configure its own data-retention periods?
- Does the product support user rights, including data deletion, export, and restriction of processing?
- Do cookie-consent mechanisms require an active user action?
- Are server and session logs covered by retention rules and access controls?
Information duties
- Does the privacy policy cover online identifiers, including IP addresses, cookies, and session IDs?
- Is the privacy notice available in the product interface, not only in the terms of service?
- Are users informed about profiling and automated decision-making, if these occur?
Upcoming regulatory requirements
- Does the agreement account for obligations under the Data Act (Regulation 2023/2854): pre-contract information about a connected service, data-sharing rules, and the conditions for ending data sharing? These rules have applied since 12 September 2025.
- Is the division of security responsibilities clear: provider for infrastructure and application; client for access management and protection of login credentials?
SaaS agreements and data protection: how to organize both
Penalties for a controller’s violations can reach EUR 20 million or 4% of total worldwide annual turnover, whichever is higher (Article 83 GDPR). The McDonald’s Polska decision shows that penalties can affect both the controller and the processor. A properly concluded SaaS agreement with data-processing terms does not eliminate liability, but it clarifies roles and reduces risk for both parties.
If you are building a SaaS product, expanding into EU markets, or preparing an enterprise deployment, check whether your agreement and product architecture address the requirements described above.
We support founders and CTOs at technology companies with SaaS agreements, data-processing agreements, and implementing Privacy by Design in product architecture. We bring IT law, data protection, and contract law together in one model, from development through sales.
If you need your SaaS agreement reviewed or want to organize personal-data issues in your product, contact us.
Frequently asked questions
Is the IP address of a user of my SaaS personal data if I do not know their name?
Yes. In case C-582/14 (Breyer), the CJEU held that a dynamic IP address is personal data if the service provider has legal means to identify the user, for example by obtaining information from the internet service provider. In judgment I OSK 1079/10, the Supreme Administrative Court confirmed that information about a device that can be linked to a specific person indirectly relates to that person. UODO treats IP addresses similarly to PESEL numbers.
When does a SaaS provider stop being a processor and become a controller?
When it independently determines the purposes of processing, for example, by conducting market analysis on client data, building its own user database, combining data from multiple tenants for benchmarking, or developing recommendation algorithms. UODO’s McDonald’s Polska decision (DKN.5131.5.2025) confirmed that designing a system and deciding on its functionality and the scope of collected data may lead to the system owner being considered a controller.
What must a SaaS data-processing agreement include?
Article 28(3) GDPR requires the agreement to specify the subject matter and duration of processing, its nature and purpose, the types of personal data, the categories of people involved, and the controller’s duties and rights. The processor must undertake to process data only on the controller’s instructions, ensure confidentiality, implement security measures, follow sub-processing rules, assist with data-subject rights, delete or return data after services end, and allow audits.
Are session logs and behavioral data from an analytics dashboard personal data?
Yes, if they can be linked to a specific user. In a typical SaaS system with user accounts, this is standard. Recital 30 of the GDPR expressly says that online identifiers combined with information collected by servers may be used to create profiles and identify people. Combining an IP address, cookie identifier, and session logs enables detailed reconstruction of a specific person’s activity.
Do I need a DPIA before launching a new feature in a SaaS product?
Article 35 GDPR requires a DPIA if processing may create a high risk to people’s rights and freedoms. The EDPB identifies nine high-risk criteria, including profiling, large-scale processing, and combining datasets. The President of UODO published a list of processing operations requiring a DPIA on 17 June 2019. If a new feature meets at least two of these criteria, conduct a DPIA before it enters development.
What additional duties does the Data Act impose on SaaS providers?
Regulation 2023/2854 (the Data Act), which has applied since 12 September 2025, requires a provider, before entering into an agreement for a connected service, to inform the user about matters including the nature and frequency of data collection, the purposes of use, the identity of data processors, storage and retention arrangements, and how data sharing can be ended. This is an additional layer of information duties on top of the GDPR.
