A customer fills out a form, clicks “send”, and within three seconds their data passes through three different legal regimes. Your product team sees one endpoint. The supervisory authority will see three roles — and three sets of obligations. And if you earn a commission on a confirmed contract, a single field in the form determines whether your billing model has a legal basis.
If you operate a platform that connects customers with contractors — a marketplace, lead generation service, or comparison site with a contact form — this article is for you. I will explain why lead generation platforms and the GDPR are an area where an error in role architecture costs more than an error in a privacy notice. You will learn how to assign the correct role to each stage of the data flow, why a survey confirming whether a contract has been concluded requires separate consent, and what to do to ensure that your privacy policy reflects how your product actually works.
Key concepts you need to know
Before we move on to the role map, let us establish the terminology. The following concepts appear in every document, agreement, and inspection — and misunderstanding them is the source of most problems.
| Concept | What it means for the platform operator |
|---|---|
| Controller | An entity that independently determines the purposes and means of processing personal data. If you decide why you collect data and what you do with it — you are the controller |
| Processor | An entity that processes data solely on the controller’s documented instructions. It does not determine the purposes — it follows instructions |
| Joint controller | Two or more entities that jointly determine the purposes and means of processing. This requires a formal arrangement under Article 26 of the GDPR |
| Legitimate interest (Article 6(1)(f) of the GDPR) | A legal basis for processing that requires a documented balancing test: your interest vs. the individual’s rights. The burden of proof lies with you (GDPR, Recital 69) |
| Commercial communication (Article 398 of the PKE) | Any form of communication intended to promote the goods, services, or image of a business. Telephone or electronic contact for this purpose requires prior consent (PKE, Article 398) |
| Record of processing activities | Two separate documents: a record of your own processing activities (Article 30(1) of the GDPR — for the controller) and a record of categories of processing activities (Article 30(2) of the GDPR — for the processor) |
Three roles of a lead generation platform operator in relation to the same data
The most common mistake? Treating the platform as a single legal entity throughout the entire data flow. In reality, a role is not a feature of the system — it is a feature of a particular stage in the data flow. The same set of data (name, telephone number, inquiry description) passes through three different legal regimes before anyone calls the customer.
Stage 1: collecting the inquiry — the operator as controller
The customer fills out a form on your platform. At this point, you determine:
- What data you collect (the scope of the form fields)
- For what purpose (matching the customer with a contractor, verification, commission settlement)
- How long you retain it
- Who you will disclose it to
Since you independently determine the purposes and means of processing — you are the controller within the meaning of Article 4(7) of the GDPR. This entails the full set of obligations: the information notice under Article 13, a legal basis under Article 6, and a record of processing activities under Article 30(1).
The obligation under Article 13(1)(e) of the GDPR requires you to display the name of the contractor who will receive the inquiry before the form is submitted. Not in the confirmation email. Not in the terms and conditions. On screen, before the customer clicks “send”.
Stage 2: delivering the lead — the contractor as a separate controller
Once the inquiry has been delivered, the contractor independently decides whether to contact the customer, when to do so, what offer to make, and how long to retain the data. The contractor determines the purposes and means independently.
Therefore, the contractor receiving the lead is a separate controller, not a joint controller. Joint controllership under Article 26 of the GDPR requires the joint determination of purposes and means — whereas here, each party acts independently.
Consequences:
- The contractor has its own information obligation under Article 14 of the GDPR towards the customer whose data it has received
- You do not need a joint controllership arrangement — you need a precise description of the roles in the privacy policy
- In the confirmation email, provide the recipient’s registration details and a link to its privacy policy
Stage 3: the contractor dashboard — the operator as processor
The contractor logs in to the dashboard and uploads photos of completed projects, service descriptions, and the contact details of its employees. The contractor enters this data for its own purposes and under its own responsibility. You provide the tool.
In this respect, you are a processor — you process data on the instructions of the contractor (the controller). Article 28 of the GDPR applies to you: a data processing agreement, acting solely on documented instructions, and an obligation to report breaches.
And this is where the trap I see most often arises.
When a processor becomes a controller — the marketing trap
Your marketing team finds a project photo in the contractor’s dashboard — a smiling crew against the backdrop of a finished interior. They post it on the platform’s social media channels. At that point:
- You have gone beyond the controller’s (contractor’s) instructions
- You have used entrusted data for your own purpose
- Under Article 28(10) of the GDPR, you have become the controller of that data
- You are processing people’s images without a legal basis and without fulfilling the information obligation
If the material is to be used in advertising for the platform — obtain separate consent for the use of the person’s image, granted directly to the operator. Without it, every such use constitutes an infringement.
Role map — overview of obligations at each stage
The table below organises the obligations assigned to each role. Use it as the foundation for your privacy policy and agreements.
| Stage of the data flow | Operator’s role | Operator’s obligations | Other party’s obligations |
|---|---|---|---|
| Collecting the inquiry (form) | Controller | Information notice under Article 13, legal basis under Article 6, record of processing activities under Article 30(1), displaying the recipient’s name before submission | — |
| Delivering the lead to the contractor | Controller (disclosing party) | Information about the recipient in the confirmation email, procedure for forwarding requests under Articles 17 and 19 of the GDPR | Contractor: its own information obligation under Article 14 of the GDPR |
| Contractor dashboard (data uploaded by the contractor) | Processor | Data processing agreement under Article 28, acting on instructions, reporting a breach within 36 hours, record of categories of processing activities under Article 30(2) | Contractor: controller of its employees’ data and materials |
| Survey after the lead is delivered | Controller | Separate consent to be contacted (optional checkbox), separate email/SMS consents, contact schedule in the privacy policy | — |
| Platform marketing using contractors’ materials | Controller (Article 28(10)) | Separate consent for the use of a person’s image, full liability for the absence of a legal basis | — |
Survey after delivering the lead — why legitimate interest is no longer enough
The commission model looks simple: the operator earns money when it confirms that the customer and contractor have signed a contract. The only way to confirm this is to contact the customer — after 30, 60, and 90 days, and after 6 and 11 months.
Until now, many operators have based this contact on the controller’s legitimate interest under Article 6(1)(f) of the GDPR. The argument was: “I need to verify whether the transaction took place so that I can settle the commission”.
The problem is that this argument requires a documented balancing test. And the balancing test takes into account the reasonable expectations of the individual at the time the data is collected (GDPR, Recital 47). A customer who has submitted an inquiry about a bathroom renovation does not expect to receive calls and emails for the next 11 months asking whether they have signed a contract.
Additional restriction under the Electronic Communications Law
Article 398(1) of the Electronic Communications Law prohibits the use of telephones and terminal equipment to send commercial communications without prior consent — including in B2B relationships. This provision replaced the previous regulations under the Act on the Provision of Electronic Services and the Telecommunications Law.
The dividing line is as follows: purely verification-related contact (confirming data or status) is generally not covered by Article 398 of the PKE. However, if other offers are recommended during the conversation or in the message, or if it includes encouragement to make a purchase or any promotional element — the contact becomes a commercial communication and requires prior consent.
Note: there is no unequivocal position from either the President of UKE or the President of UODO directly determining whether a telephone satisfaction survey or verification survey constitutes a “commercial communication”. The distinction is based on the interpretation of Article 398 of the PKE and depends on the actual content of the contact, not its label.
What this means for your form
You need a separate, optional checkbox for consent to be contacted to verify whether a contract has been concluded. Failure to select it must not prevent the inquiry from being submitted — otherwise, the consent will not be freely given (Article 7(4) of the GDPR).
| Form element | Required | Prevents the inquiry from being submitted? |
|---|---|---|
| Inquiry details (name, telephone number, description) | Yes | Yes |
| Acknowledgement of the privacy policy | Yes (notice, not acceptance) | Yes |
| Acceptance of the terms and conditions | Yes (separate action) | Yes |
| Consent to email contact for verification | Optional | No |
| Consent to SMS contact for verification | Optional (separate field) | No |
| Consent to email marketing | Optional (separate field) | No |
| Consent to SMS marketing | Optional (separate field) | No |
Consent to email and consent to SMS are two separate consents, not one. Separate fields are required for different processing purposes (UODO — consent is not always the legal basis for processing).
Without optional consent to the survey — you have no evidentiary basis for commission settlements. The entire settlement model rests on uncertain ground.
Consent layer, cookie banner, and technical pitfalls
Consent banner — equal prominence of the reject option
Article 7 of the GDPR requires consent to be freely given, specific, informed, and unambiguous. Pre-ticked boxes do not meet this standard. The EDPB has adopted guidelines on dark patterns in interfaces — visually prioritising “Accept” while hiding “Reject” in subsequent layers may undermine the validity of consent.
The safe approach: make both options equally accessible on the first layer of the banner. There are no binding guidelines requiring the buttons to look identical, but the requirement is functional — the authority assesses the overall experience to determine whether the user could easily refuse.
Analytics and advertising pixels
Article 399(3) of the PKE provides a “strictly necessary” exemption only for session cookies. It does not cover analytics or advertising pixels. These tools must be blocked until consent has been obtained.
A separate pitfall: enhanced conversions in advertising tools. If your team enables “advanced matching” on forms, the customer’s hashed email address and telephone number are sent to the advertising platform without a legal basis. Disable this feature.
The CJEU judgment in Case C-40/17 (Fashion ID) confirmed that deliberately embedding an element serving a shared purpose (e.g. an advertising pixel) may create joint controllership for the collection and disclosure phase (CJEU press release). The assessment must be operational — it depends on the specific mechanism, not the product’s name.
Inquiry deduplication — a hidden breach
If your system compares telephone numbers for deduplication and displays the message “this inquiry has already been submitted” — you disclose to the person at the keyboard that the given number is in the database. This constitutes a breach affecting a third party.
The safe solution: for logged-in users — a server-side flag; for guests — a session cookie only. Never compare telephone numbers and never display a message revealing that a number is present in the database.
Document vs. product — what the supervisory authority will actually inspect
The most common flaw in projects of this kind is not an incorrect privacy notice, but a promise made in a document that the product does not fulfil. The outcome of an inspection is determined by the discrepancy between the privacy policy and the system’s actual behaviour.
Examples of discrepancies I regularly encounter:
| What the document states | What the product does | Risk |
|---|---|---|
| “We jointly control data with advertising providers” (heading) | The body of the same section describes them as separate controllers | An inconsistency that undermines the credibility of the entire document |
| “We retain data for 12 months” | No automatic deletion, backups with no overwrite cycle | Breach of the storage limitation principle |
| “You can withdraw your consent at any time” | No toggle in the dashboard, no unsubscribe link in messages | A separate infringement of Article 7(3) of the GDPR |
| “We will notify recipients that the data has been erased” | No automatic notification to contractors following a request under Article 17 of the GDPR | Erasure request fulfilled only in part |
Before publishing your privacy policy, check it line by line to ensure that every promise has a counterpart in the code and configuration.
Operational deadlines you need to know
The following deadlines arise from the GDPR, the PKE, and standard data processing agreements. Record them and assign them to specific members of your team.
| Deadline | Event | Responsible party |
|---|---|---|
| 180 seconds | Validity of the SMS code used to verify the inquiry | Product / backend |
| 36 hours | Notification to the contractor (controller) of a breach involving entrusted data | DPO / compliance |
| 72 hours | Notification of your own breach to the President of UODO | DPO / management board |
| 3 business days | Forwarding a data subject’s request to the contractor | Customer service / DPO |
| 14 days | Advance notice to contractors of a change of subprocessor | Legal / operations |
| 30 days | Deletion of entrusted data after the agreement ends | Product / backend |
| 12 months | Commission settlement period from the delivery of the inquiry | Finance / legal |
| 3 years | Retention related to the limitation period for claims (until the end of the calendar year) | Legal |
| 5 years | Retention of accounting records | Accounting |
Two records of processing activities — why one is not enough
A platform operator that acts as both controller and processor must maintain two separate records:
- Record of its own processing activities (Article 30(1) of the GDPR) — as controller: customer data from forms, settlement data, marketing data
- Record of categories of processing activities carried out on behalf of contractors (Article 30(2) of the GDPR) — as processor: contractors’ employee data, offer materials, photos
The exemption from the record-keeping obligation for entities with fewer than 250 employees does not apply if the processing is not occasional (GDPR, Article 30(5)). A lead generation platform processes data regularly — the exemption does not apply.
Additionally, make the list of subprocessors available in the contractor dashboard, with notice of changes given 14 days in advance (Article 28(2) of the GDPR). Changing a subprocessor without the controller’s (contractor’s) prior written authorisation constitutes a breach of the data processing agreement.
Data processing agreements across the entire vendor stack
Signing data processing agreements with vendors is not a formality that can be postponed. Every vendor that processes personal data on your behalf requires an agreement under Article 28 of the GDPR.
A typical vendor stack for a lead generation platform:
| Vendor | Data categories | Data processing agreement required? | Transfer outside the EEA? |
|---|---|---|---|
| Hosting / database | All platform data | Yes | Check server locations |
| CMS | Content data, account data | Yes | Check |
| SMS provider | Telephone numbers, message content | Yes | Check |
| Email provider | Email addresses, correspondence content | Yes | Check |
| Analytics tool | Identifiers, behavioural data | Yes (or joint controllership) | Check |
| Advertising platform | Hashed contact data | Yes or joint controllership | Check |
| Consent management platform (CMP) | Consent logs | Yes | Check |
| Accounting firm | Settlement data | Yes | Usually not |
For transfers outside the EEA: the mere fact that infrastructure is located in the US or general declarations of compliance with the Data Privacy Framework are not sufficient. Check whether the vendor is certified in the DPF register. If not — use the standard contractual clauses (SCCs) under Article 46 of the GDPR together with an assessment of the law and practices of the recipient country (EDPB Recommendations 01/2020).
Additional DSA and P2B obligations — what overlaps with the GDPR layer
If your platform enables consumers to conclude contracts with businesses, you are also subject to obligations under the Digital Services Act (DSA) and the P2B Regulation.
The most important obligations that overlap with the personal data layer:
- Verification of traders’ identities and retention of identification data for 6 months after the end of the business relationship (Article 30 of the DSA)
- Statement of reasons for a moderation decision specifying the type of restriction, the facts, the legal or contractual basis, information on the use of automated means, and available means of redress (Article 17 of the DSA)
- Statement of reasons for restricting or suspending a service provided to a business user, supplied on a durable medium (Article 4 of the P2B Regulation)
- Point of contact for authorities and recipients of the service (Articles 11–12 of the DSA)
- Internal complaint-handling system (Article 11 of the P2B Regulation)
The same moderation decision (e.g. suspending a contractor’s account) may need to meet the statement-of-reasons requirements under both regulations. Add three separate addresses to the website footer: general contact, personal data matters, and a point of contact for content reports (DSA).
Implementation order — where to start
You do not need to do everything at once. The sequence below organises the work from the highest priority. The minimum realistic implementation time for a platform with a limited number of integrations is approximately 4–8 weeks — the GDPR does not specify implementation deadlines, but the longer you delay, the longer you operate without a legal basis.
| Week | Action | Owner |
|---|---|---|
| 1 | Inventory data flows and assign roles (controller / processor) to each stage | Legal + product |
| 1–2 | Determine the legal basis for each operation and conduct a balancing test for legitimate interests | Legal |
| 2–3 | Redesign the form: separate the checkboxes, display the recipient’s name, create a consent log | Product + frontend |
| 2–3 | Prepare the first-layer notice and a privacy policy that reflects the product | Legal |
| 3–4 | Sign data processing agreements with vendors and verify transfers outside the EEA | Legal + operations |
| 3–4 | Configure the consent banner, block analytics and pixels until consent is obtained, disable enhanced conversions | Marketing + product |
| 4–5 | Set up two records of processing activities | Legal / DPO |
| 4–5 | Implement the breach procedure (36h / 72h) and the request-forwarding process (3 business days) | DPO + customer service |
| 5–6 | Review survey content — remove promotional elements and add an opt-out option to every contact | Marketing + legal |
| 6–8 | Audit the consistency of documents with the product, testing, monitoring | Legal + QA |
How we can help your platform
We conduct a platform data journey audit — from the form to commission settlement. We assign a legal role to each stage of the data flow, verify the consent layer and consent logs, prepare data processing agreements with vendors, and check whether the privacy policy reflects how your product actually works.
Three levels of engagement:
- Operational minimum — a map of roles assigned to each stage + improved checkboxes and first-layer notice
- Solid foundation — documents + data processing agreements with vendors + two records of processing activities + breach and request-handling procedures
- Full protection — implementation with the product team, audit questionnaires for contractors, operational templates (statement of reasons for a moderation decision, response to a GDPR request, statement of reasons for suspending a business partner)
We combine law with product context. We do not create documents “just in case” — we design rules where the risk actually arises.
Lead generation platforms and the GDPR in 2026 — what to implement now
One data flow, three legal roles, one optional checkbox determining the legality of the commission model. If you operate a platform that connects customers with contractors, your legal architecture must reflect your product architecture — stage by stage.
Start with the role map. Separate the checkboxes. Sign data processing agreements. Check whether your privacy policy describes what your product actually does. And if you need help organising these areas — contact us.
Frequently asked questions
Is my platform a joint controller together with the contractors?
Usually not. Joint controllership under Article 26 of the GDPR requires the joint determination of the purposes and means of processing. If the contractor independently decides whether and when to contact the customer, what offer to make, and how long to retain the data — it is a separate controller. Your role changes depending on the stage: controller when collecting the inquiry, processor when operating the contractor dashboard. A joint controllership arrangement is not required — you need a precise description of the roles in the privacy policy and a data processing agreement covering the dashboard data.
Will an additional survey consent checkbox reduce my form conversion rate?
An additional field increases the number of actions required from the user — that is a fact. However, there are no verified numerical benchmarks (e.g. “one checkbox reduces conversion by X%”) in Polish-language official sources or primary research (UODO — consent is not always the legal basis for processing). Without this checkbox, you risk losing the evidentiary basis for commission settlements — the cost of that risk is higher than the potential drop in conversion. The checkbox must be optional and must not prevent the inquiry from being submitted.
As a company with fewer than 250 employees, do I need to maintain two records of processing activities?
Yes, if the processing is not occasional. A lead generation platform processes data regularly — the exemption under Article 30(5) of the GDPR does not apply. You maintain a record of your own processing activities (Article 30(1)) as controller and a record of categories of processing activities (Article 30(2)) as processor for contractors.
How long can I retain lead data if the commission is settled over 12 months?
Retention depends on the purpose. Data used to settle the commission — 12 months from delivery of the inquiry. Data related to the limitation period for claims — up to 3 years, calculated until the end of the calendar year. Accounting records — 5 years. Once each of these periods expires, data associated with the relevant purpose should be deleted. Implement automatic deletion with a defined backup overwrite cycle.
Can I activate analytics and pixels before obtaining consent if the data is hashed?
No. Article 399(3) of the PKE permits the “strictly necessary” exemption only for session cookies. Hashing does not change the fact that the data is sent to an advertising platform without a legal basis. Disable advanced matching and enhanced conversions on forms. Block analytics and pixels until consent has been obtained through the banner.
What will the authority actually inspect during an audit — the wording of the privacy policy or the product’s behaviour?
Both — but the discrepancy between them will determine the outcome. The President of UODO has imposed fines for processing the data of customers and prospective customers without a legal basis. If the policy declares mechanisms that the product does not provide (automatic deletion, recipient notifications, a consent withdrawal toggle), the document itself becomes evidence of the infringement. Check line by line whether every promise in the policy has a counterpart in the code.
