GDPR Before a Project Launch. 7 Things You Need to Put in Order Before Implementing a New Product.

The new product is ready. The team is waiting for the green light. And then someone asks: what about GDPR? In most companies we work with, this question comes too late—when changing anything means delaying the launch by weeks and rebuilding something that already works.

Meanwhile, the data speaks for itself. In 2025, the President of the UODO imposed fines totaling PLN 64.3 million—more than three times the amount imposed in 2024. The entities 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 GDPR—in other words, failure to properly design data protection measures—are consistently penalized.

But a financial penalty is not the only risk. Project delays, chaos between departments, loss of user trust, and costly redesigns of forms, consent mechanisms, and terms and conditions after launch—this is a scenario that can be anticipated and prevented.

In this article, I cover 7 GDPR areas you should address before launching a new product, service, sales channel, or tool. Not to hold up implementation, but to accelerate it—with a clear plan and no risk of having to make changes after launch.

Before you begin—the terms you need to know

Before we move on to the specifics, let us establish a common language. The following terms appear in every project involving the processing of personal data.

With these terms covered, we can move on to the specific steps.

1. Map data flows before development begins

This is the starting point. Before you write the first line of code or configure a new tool, answer four questions:

1. Where is the data collected from? (form, API, import, partner integration)
2. Where does it go? (database, CRM, analytics tool, provider’s cloud)
3. Who has access to it? (product team, marketing, sales, external provider)
4. What operations are performed on it? (storage, segmentation, scoring, personalization, profiling)

The record of processing activities required by Article 30 of the GDPR is a natural tool for this analysis. It contains the controller’s details, the purposes of processing, categories of individuals and data, recipients, information on transfers outside the EU, retention periods, and a description of the safeguards used.

Why is this important now rather than after launch? Every change to the data flow after the product has been launched requires updates to the record, privacy notices, terms and conditions, and data processing agreements. If you do it once, before launch, you save time and money. If you discover gaps after launch, you will have to redesign forms, obtain consent again, and amend your documentation.

According to data from the Polish Chamber of Digital Economy (the “e-Accurate 2024″ report), the e-commerce sector spends an average of PLN 159.5 thousand per company per year on compliance with the GDPR, the Omnibus Directive, and the DSA, totaling approximately PLN 55.4 billion for the entire market. This represents approximately 6% of the sector’s annual sales and 18–20% of its margin. A significant share of these costs is generated by post-implementation remediation.

2. Establish roles: who is the controller, who is the processor, and who is the joint controller

For every new project involving external providers, you must determine who is responsible for what in relation to personal data. This is not a formality—it is the foundation on which all documentation and accountability rest.

The three most common scenarios:

A lack of clarity in this area is one of the most common sources of problems. An example from a UODO decision: DPD Polska was fined a total of more than PLN 11 million, among other things, for failing to have data processing agreements with external carriers (a violation of Article 28(3) of the GDPR) and for failing to implement adequate organizational measures.

What to do:

1. Review the list of all providers, partners, and tools involved in the project.
2. For each entity, determine whether it acts as a processor, joint controller, or independent controller.
3. Prepare the appropriate agreements before the data flow begins.
4. Plan regular reviews of processors—at least once a year and whenever a breach is suspected.

3. Determine the legal basis for processing—separately for each purpose

This is the mistake I see most often: a company assumes it has “taken care of GDPR” because its terms and conditions include a consent clause. In reality, a single project generates several separate processing purposes—and each of them requires its own legal basis.

A typical breakdown for a new SaaS or e-commerce product:

The boundary between lawful analytics and high-risk profiling lies where data analysis begins to produce legal effects or similarly significant effects for an individual (Article 22 of the GDPR). Lead scoring in a CRM is not the same as automatically rejecting a loan application. But if your scoring system automatically excludes customers from accessing a service, you enter the area of automated decision-making, which requires additional safeguards and may require a DPIA.

Contact us if you need support in determining the legal bases for a specific project.

4. Assess whether your project requires a DPIA

Not every new project requires a DPIA. But every project requires a conscious decision as to whether a DPIA is necessary—and that decision must be documented.

When is a DPIA required?

The announcement of the President of the UODO dated 17 June 2019 (Monitor Polski, item 666) identifies 12 categories of processing operations for which a DPIA is required. The rule is: if your project meets at least two of the following criteria, conduct a DPIA.

Important: If your project meets two criteria but you nevertheless believe that a DPIA is not necessary, you must document and justify this in detail. The more criteria an operation meets, the more evident the need to conduct an assessment.

A DPIA must be conducted before processing begins—not after the project has been launched.

5. Implement privacy by design and privacy by default in the product architecture

Article 25 of the GDPR is not bureaucracy. It is an element of a good product. Implementing the principles of privacy by design and privacy by default at the design stage protects against costly changes after launch.

Privacy by design (Article 25(1)) means that data protection is incorporated at the design stage rather than “bolted on” afterwards. It includes both technical measures (encryption, pseudonymization, access control) and organizational measures (policies, procedures, training).

Privacy by default (Article 25(2)) means that the product’s default settings process the minimum amount of data. There are four dimensions you need to check:

1. Scope of data collected—by default, do not collect more than necessary. Review every form and remove fields that are not essential.
2. Scope of processing—data collected for one purpose should not be used for other purposes by default.
3. Retention period—set up automatic deletion or anonymization of data once the necessary period has expired.
4. Accessibility—by default, data should be accessible only to those who need it. Predefined roles, masking of unnecessary information, and restricted permissions.

A UODO decision confirms the consequences of failing to implement privacy by design: In case DKN.5131.4.2024, the President of the UODO imposed fines totaling more than PLN 1,145,891 for violations including Article 25(1) of the GDPR—the failure to implement adequate technical measures when processing data using external storage media. In another decision (DKN.5131.17.2022), a fine of PLN 32,832 was imposed for failing to conduct a risk analysis and implement measures to protect medical records.

The guidelines of the European Data Protection Board (EDPB, Guidelines 4/2019) emphasize that Article 25 applies throughout the entire system life cycle: planning → design → implementation → operation → monitoring → updating → decommissioning. Every significant system modification, change of provider, or migration to the cloud requires these requirements to be reconsidered.

Practical tip for SaaS: In SaaS projects, implementation often comes down to configuring software, creating user accounts, and granting permissions. Despite the simplified implementation process, the obligations of privacy by design and by default still apply—configure roles, permissions, and default privacy settings before making the product available to users.

6. Prepare documentation before launch—not afterwards

Complete GDPR documentation must be ready before the project is launched. The list of documents depends on the nature of the project, but the following set covers most scenarios:

The cost of inaction: A data breach must be reported to the UODO within 72 hours of becoming aware of the incident (Article 33 of the GDPR). If you do not have a data breach response procedure, you will not make the deadline. A court enforcement officer was fined a total of approximately PLN 21 thousand for failing to report a breach and notify the affected individual.

Consent management in marketing automation tools: If you are implementing a CRM or marketing automation tool, configure the consent management module before launching a campaign. This includes managing multiple consents for different purposes, recording the history of consent changes (who changed the wording, when, and how), subscription and unsubscribe statistics, and displaying consent information on the contact timeline.

7. Take the AI Act into account if you are implementing artificial intelligence tools

Since 2 February 2025, the first provisions of the AI Act (EU Regulation 2024/1689) have applied, including:

1. A ban on the use of emotion recognition systems in workplaces and educational institutions.
2. An AI literacy requirement—organizations deploying AI systems must ensure that the people operating those systems have an appropriate level of competence.
3. Full application of the AI Act provisions for high-risk systems will begin on 2 August 2026.

Relationship between the AI Act and the GDPR: Article 2(7) of the AI Act explicitly states that the regulation does not affect obligations arising from the GDPR. This means that implementing an AI tool requires compliance with both regulations in parallel.

If your new project includes a chatbot, an automated customer service tool, a recommendation system, or AI-based scoring, check:

1. What personal data is fed into the AI system and on what legal basis.
2. Whether the AI provider acts as a processor or an independent controller.
3. Whether the processing requires a DPIA (scoring, profiling, automated decisions—see section 4).
4. Whether the system falls into a prohibited or high-risk category under the AI Act.
5. Whether the team operating the tool has the required competence (AI literacy).

The AI Act also introduces an obligation to conduct an FRIA (fundamental rights impact assessment, Article 27 of the AI Act) for high-risk AI systems—this is a separate assessment from a DPIA, although the two may complement each other.

GDPR checklist for a new project—9 self-assessment questions

Before involving a lawyer, go through the following questions with the project owner. The answers will show you where the gaps are and what needs to be addressed.

If you do not have an answer to any of these questions, it is a sign that the issue should be addressed before launch.

Who is responsible for GDPR in a new company project

This question comes up with every implementation: is GDPR the responsibility of the CEO, the product owner, marketing, or IT?

The answer: responsibility for GDPR compliance rests with the data controller—in other words, your company, represented by its management board. Operationally, however, coordination should be handled by the project owner, with the involvement of representatives from product, marketing, sales, and IT.

What we recommend:

1. Organize a GDPR kick-off involving the project owner and representatives of every team that will come into contact with personal data.
2. Agree on a shared list of compliance activities and assign responsibility—who prepares the notices, who configures the tools, and who signs the data processing agreements.
3. Appoint one person to coordinate the process—this does not have to be the DPO (data protection officer), but it should be someone who monitors deadlines and ensures that the documentation is complete.
4. Prepare a brief decision-making document for the management board: a summary of risks, a list of conditions for a safe launch, and a go/no-go recommendation from a data protection perspective.

Without a single list of activities and one coordinator, chaos ensues—marketing collects data without a legal basis, sales launches a campaign without privacy notices, and IT integrates a tool without a data processing agreement.

How much does getting it right cost, and how much do post-launch fixes cost?

The lack of precise empirical research on GDPR remediation costs in the SaaS and e-commerce sectors is a confirmed gap. However, the available indirect data makes it possible to build an estimate.

Intrum Justitia data indicates that the average cost of the initial GDPR implementation in SMEs is approximately PLN 32 thousand, and in large corporations—approximately PLN 270 thousand. More than half of Polish companies were unable to estimate these costs.

SaaS specifics (multi-tenant architecture): A design flaw in a system where one instance serves multiple customers requires a correction that affects all customers at once. A campaign to obtain consent again (re-consent) results in a real decline in the number of marketing contacts—the success rate for renewed consent is lower than for initial consent.

Estimated ROI from a preventive approach: approximately 100% over a multi-year horizon—assuming that the difference between prevention and remediation costs is approximately PLN 120 thousand.

Get GDPR in order before launch—not after the first inspection

Getting GDPR in order before launching a new product is not an additional obligation that slows down implementation. It is something that accelerates the launch—because it eliminates the risk of rework, gives the team clear rules, and protects the company from remediation costs.

The seven areas described in this article are the minimum you should cover before every new project:

1. Mapping data flows.
2. Establishing roles (controller, processor, joint controller).
3. Determining the legal bases for processing.
4. Assessing the need for a DPIA.
5. Implementing privacy by design and by default.
6. Preparing documentation.
7. Taking the AI Act into account when using AI tools.

If you are planning a new product, service, or sales channel and want to check whether your implementation is ready from a GDPR perspective—contact us. We will help you get your obligations in order before problems arise, not afterwards.

Frequently asked questions

I am launching a new product in 6 weeks—do I have enough time to get GDPR in order?

Yes, provided that you start by mapping data flows and establishing roles with providers. Most documentation (notices, terms and conditions, data processing agreements) can be prepared within 3–4 weeks if you have a clear picture of the project. A DPIA—if required—takes additional time, so decide whether to conduct one as soon as possible.

How do I know whether my project requires a DPIA?

Check the 2019 list published by the President of the UODO (Monitor Polski, item 666)—it contains 12 categories of operations. If your project meets at least two criteria (e.g., profiling + large-scale processing), a DPIA is generally required. The assessment should be conducted by the data controller—usually in cooperation with the DPO or an external adviser.

I am implementing a CRM and marketing automation—will signing an agreement with the provider be enough?

No. The agreement with the provider is a commercial agreement. In addition, you need a data processing agreement (Article 28 of the GDPR) governing the processing of data on your behalf. You must also configure the tool for privacy by default: limit the data collected by default, set access roles, and configure the consent management module.

If I only collect an email address and first name on a landing page, do I need to worry about GDPR?

Yes. An email address and first name are personal data. You must have a legal basis for processing (usually consent to marketing communications), a privacy notice available alongside the form, and an entry in the record of processing activities. If the data is sent to an external tool (e.g., Mailchimp, HubSpot), you also need a data processing agreement.

Who in the company should be responsible for GDPR in a new project?

Legal responsibility rests with the management board (the data controller). Operationally, coordination should be handled by the project owner, with the involvement of representatives from product, marketing, sales, and IT. Appoint one person to monitor deadlines and ensure that the documentation is complete—this does not have to be the DPO.

Where is the boundary between lawful analytics and high-risk profiling?

The boundary lies where data analysis begins to produce legal effects or similarly significant effects for an individual (Article 22 of the GDPR). Segmenting customers in a CRM for campaign purposes is not the same as automatically rejecting an application for a service based on an algorithm. If your scoring system automatically excludes people from accessing a service, you enter the area of automated decision-making, which requires a DPIA and additional safeguards.