Launching a Product in Poland? Address These 7 GDPR Issues Before You Go Live

Launching a Product in Poland? Address These 7 GDPR Issues Before You Go Live

The product is ready. The team is waiting for approval to launch. Then someone asks: “What about GDPR?”

In many companies we work with, that question comes too late. Changing the way data is collected or used can then mean weeks of delay—and rebuilding a product that already works.

Enforcement is one reason to plan ahead. In 2025, the President of Poland’s Personal Data Protection Office (Urząd Ochrony Danych Osobowych, or UODO) imposed fines totaling PLN 64.3 million, more than three times the 2024 total. Those fined included Poczta Polska (PLN 27.1 million), ING Bank Śląski (PLN 18.4 million), and McDonald’s Polska (PLN 16.9 million). Violations of Articles 24, 25, and 32 of the EU General Data Protection Regulation (GDPR), including failures to design appropriate data protection measures, are consistently penalized.

A fine is not the only risk. Project delays, confusion between teams, loss of user trust, and post-launch changes to forms, consent mechanisms, and terms can all be costly. They can also be anticipated.

This article covers seven areas to address before launching a new product, service, sales channel, or tool involving personal data in Poland. The aim is not to block the launch. It is to give the team a workable plan before changes become expensive.

Key terms for a project involving personal data

1. Map data flows before development begins

Before writing code or configuring a new tool, answer four questions:

1. Where does the data come from? A form, API, import, or partner integration?
2. Where does it go? A database, CRM, analytics tool, or provider’s cloud?
3. Who can access it? Product, marketing, sales, or an external provider?
4. What happens to it? Storage, segmentation, scoring, personalization, or profiling?

The record of processing activities under Article 30 GDPR is a useful tool for this exercise. It records the controller’s details, processing purposes, categories of individuals and data, recipients, information about transfers outside the EU, retention periods, and a description of safeguards.

Why do this before launch? If a data flow changes after launch, you may need to update the record, privacy notices, terms, and data processing agreements. Discovering gaps late can also mean redesigning forms, obtaining consent again, and revising documentation.

The Polish Chamber of Digital Economy’s “e-Accurate 2024” report puts the average annual cost of compliance with GDPR, the Omnibus Directive, and the DSA in the e-commerce sector at PLN 159,500 per company, or approximately PLN 55.4 billion across the market. The report’s figures represent approximately 6% of the sector’s annual sales and 18–20% of its margin. A significant share of these costs comes from fixing issues after implementation.

2. Establish who is the controller, processor, or joint controller

When outside providers or partners are involved, determine each party’s role before personal data starts flowing. The answer drives both documentation and accountability.

Unclear roles create practical risk. In a UODO decision, DPD Polska was fined a total of more than PLN 11 million, among other things, for not having data processing agreements with external carriers, in breach of Article 28(3) GDPR, and for lacking adequate organizational measures.

Before launch:

1. List every provider, partner, and tool involved in the project.
2. Assess separately whether each party is a processor, joint controller, or independent controller.
3. Put the appropriate agreements in place before the data flow begins.
4. Plan periodic processor reviews—at least annually and when you suspect a breach.

3. Identify a legal basis for each processing purpose

A consent clause in the terms does not, by itself, resolve a project’s GDPR obligations. One product can involve several distinct uses of personal data, and each purpose needs its own legal basis.

For a new SaaS or e-commerce product, the source gives this typical breakdown:

The important distinction is between analysis used to support a business decision and analysis that has legal or similarly significant effects on an individual under Article 22 GDPR. Scoring leads in a CRM is different from automatically rejecting a loan application. If scoring automatically excludes people from a service, additional safeguards are needed and a DPIA may be required.

If you need help identifying the legal bases for a particular project, contact us.

4. Decide whether the project needs a DPIA

Not every new project requires a DPIA. Every project does, however, need a deliberate, documented decision about whether one is necessary.

A notice issued by the President of UODO on June 17, 2019 (Monitor Polski, item 666) identifies 12 categories of processing operations for which a DPIA is required. The approach set out here is to conduct a DPIA if the project meets at least two of the following criteria:

If two criteria are present but you conclude that a DPIA is unnecessary, document and justify that conclusion in detail. The more criteria the processing meets, the stronger the case for conducting the assessment.

Complete a required DPIA before processing begins—not after launch.

5. Build privacy by design and by default into the product

Article 25 GDPR is a product-design issue, not simply a documentation exercise. Addressing privacy by design and privacy by default early helps avoid costly changes later.

Privacy by design, under Article 25(1), means considering data protection during design rather than adding it after implementation. Measures can be technical—such as encryption, pseudonymization, and access controls—or organizational, such as policies, procedures, and training.

Privacy by default, under Article 25(2), means checking what the product does before a user changes any settings. Review four dimensions:

1. Data collected: Remove form fields that are not necessary by default.
2. Uses of data: Do not automatically reuse data collected for one purpose for another.
3. Retention: Configure deletion or anonymization after the necessary period.
4. Access: Give access only to those who need it, using defined roles, restricted permissions, and masking where appropriate.

UODO decisions illustrate the consequences of inadequate measures. In case DKN.5131.4.2024, the President of UODO imposed fines totaling more than PLN 1,145,891 for violations including Article 25(1) GDPR, involving inadequate technical measures when processing data with external storage media. In DKN.5131.17.2022, a PLN 32,832 fine concerned the absence of a risk analysis and measures to protect medical records.

The European Data Protection Board’s Guidelines 4/2019 emphasize that Article 25 applies throughout the system life cycle: planning, design, implementation, operation, monitoring, updates, and decommissioning. Revisit the requirements when making a significant system change, changing providers, or moving to the cloud.

For SaaS, implementation may consist largely of configuration: creating accounts, assigning permissions, and setting defaults. That does not remove the Article 25 obligations. Configure roles, permissions, and privacy defaults before users receive access.

6. Have documentation and response procedures ready before launch

The precise documents depend on the project, but the following list covers many common scenarios.

An incident is a poor time to design a response process. The source identifies a 72-hour deadline for reporting a breach to UODO after becoming aware of it under Article 33 GDPR. Without a breach response procedure, meeting that deadline may be difficult. A Polish court enforcement officer was fined approximately PLN 21,000 in total for failing to report a breach and notify the affected person.

If the launch includes a CRM or marketing automation tool, set up consent management before the first campaign. The configuration should cover separate consents for different purposes, a history of consent changes—including who changed wording, when, and how—subscription and unsubscribe statistics, and consent information on each contact’s timeline.

7. Check the AI Act alongside GDPR when deploying AI

The first provisions of the EU AI Act (Regulation (EU) 2024/1689) have applied since February 2, 2025. The source highlights:

1. A ban on emotion-recognition systems in workplaces and educational institutions.
2. An AI literacy requirement: organizations deploying AI systems must ensure that people operating them have an appropriate level of competence.
3. The full application of AI Act provisions for high-risk systems from August 2, 2026.

Article 2(7) of the AI Act states that it does not affect GDPR obligations. An AI deployment may therefore require work under both regulations.

For a chatbot, automated customer service tool, recommendation system, or AI-based scoring system, ask:

1. What personal data enters the system, and on what legal basis?
2. Is the AI provider a processor or an independent controller?
3. Does the processing call for a DPIA—for example, because it involves scoring, profiling, or automated decisions?
4. Could the system fall into a prohibited or high-risk AI Act category?
5. Does the team operating it have the required AI literacy?

The AI Act also introduces a fundamental rights impact assessment (FRIA) under Article 27 for high-risk AI systems. It is separate from a GDPR DPIA, although the assessments can complement each other.

A nine-question pre-launch GDPR checklist

Work through these questions with the project owner before seeking legal advice. Unanswered questions show where further work is needed.

If you cannot answer one of these questions, resolve it before launch.

Assign ownership across the business

The controller—typically the company, represented by its management board—is responsible for GDPR compliance. Day-to-day coordination should sit with the project owner, working with product, marketing, sales, and IT.

We recommend:

1. Holding a GDPR kickoff with the project owner and each team that will handle personal data.
2. Creating one shared compliance task list with named owners for notices, tool configuration, and provider agreements.
3. Appointing one coordinator to track deadlines and documentation. This does not have to be the data protection officer (DPO).
4. Giving the management board a short decision paper: key risks, conditions for a data-protection-ready launch, and a go/no-go recommendation.

Without a shared list and coordinator, teams can move in different directions: marketing may collect data without an identified legal basis, sales may start a campaign before notices are ready, and IT may connect a tool before a data processing agreement is in place.

Compare preparation costs with post-launch remediation

There is no precise empirical study of GDPR remediation costs for SaaS and e-commerce in the material discussed here. The available indirect figures do, however, support an illustrative estimate, not a budget for every project.

Intrum Justitia data puts the average cost of initial GDPR implementation at approximately PLN 32,000 for small and medium-sized enterprises and PLN 270,000 for large corporations. More than half of Polish companies could not estimate those costs.

Architecture matters too. In a multi-tenant SaaS system, where one software instance serves many customers, a design error may require a fix affecting every customer. A campaign to obtain consent again can reduce the available marketing contact list: renewed consent has a lower success rate than initial consent collection.

The source estimates a return on investment of approximately 100% over several years for a preventive approach, assuming a difference of about PLN 120,000 between preparation and remediation costs. Treat that as a scenario based on stated assumptions, not a guaranteed result.

Get GDPR ready before the launch decision

A pre-launch GDPR review should give decision-makers clear conditions for going live, not an open-ended reason to delay. Cover these seven areas:

1. Map data flows.
2. Establish controller, processor, and joint-controller roles.
3. Identify the legal basis for each purpose.
4. Assess whether a DPIA is required.
5. Implement privacy by design and by default.
6. Complete documentation and breach procedures.
7. Address the AI Act if the project uses AI.

If you are planning a product, service, or sales channel involving personal data in Poland, contact us to review its GDPR readiness before problems arise.

Frequently asked questions

We plan to launch in six weeks. Is there enough time?

Yes, if you begin with data-flow mapping and provider roles. With a clear picture of the project, most notices, terms, and data processing agreements can be prepared in three to four weeks. A required DPIA takes additional time, so decide whether one is needed as early as possible.

How do we know whether a DPIA is required?

Check the President of UODO’s 2019 list (Monitor Polski, item 666), which identifies 12 categories of operations. Under the approach described above, a project meeting at least two criteria—such as profiling and large-scale processing—generally requires a DPIA. The controller should make the assessment, usually with the DPO or an external adviser.

Is our commercial contract with a CRM provider enough?

No. Where the provider processes personal data on your behalf, you also need a data processing agreement under Article 28 GDPR. Configure the tool before use: limit default data collection, assign access roles, and set up consent management.

Does GDPR matter if a landing page asks only for a first name and email address?

Yes. Those are personal data. Identify a processing basis—usually consent to marketing communications in the scenario described here—make a privacy notice available beside the form, and include the activity in the record of processing activities. If an outside tool, such as Mailchimp or HubSpot, processes the data on your behalf, put a data processing agreement in place.

Who should lead GDPR work on the project?

The company as controller, represented by its management board, remains responsible for compliance. The project owner should coordinate the work with product, marketing, sales, and IT. Assign one person to monitor deadlines and documentation; that person need not be the DPO.

When does analytics become higher-risk profiling?

The distinction becomes particularly important where analysis produces legal or similarly significant effects for an individual under Article 22 GDPR. CRM segmentation for a campaign differs from automatically rejecting a service application. If scoring automatically excludes people from a service, additional safeguards are needed and a DPIA may be required.