Lead Generation Platforms in Poland: Mapping GDPR Roles to Your Data Flows
A customer completes a form and clicks “Send.” In the seconds that follow, the data may move through three different legal roles. Your product team sees one workflow; a regulator may see three sets of obligations. If your platform earns a commission when a customer signs a contract with a contractor, the way you obtain consent for follow-up contact may also affect your ability to verify that commission.
This matters if you operate a marketplace, lead generation service, or comparison site that connects customers with contractors in Poland. The central task is to assign the right role to each processing activity—not to give the entire platform one label. Your privacy policy must then describe what the product actually does.
The terms behind the role map
The EU General Data Protection Regulation (GDPR), known in Poland as RODO, uses roles that depend on who determines the purposes and means of a particular processing activity.
| Term | What it means for a platform operator |
|---|---|
| Controller | The entity that determines why and how personal data is processed. If you decide why to collect inquiry data and what to do with it, you act as a controller for that activity. |
| Processor | An entity that processes data on a controller’s documented instructions, without setting its own purposes for that processing. |
| Joint controllers | Two or more entities that jointly determine purposes and means. Article 26 GDPR requires an arrangement between them. |
| Legitimate interests | A possible legal basis under Article 6(1)(f) GDPR. It calls for a documented balancing test between your interest and the individual’s rights; you must be able to substantiate your position (GDPR, Recital 69). |
| Commercial communication | Communication promoting a business’s goods, services, or image. Telephone or electronic contact for that purpose requires prior consent under Article 398 of Poland’s Electronic Communications Law, commonly abbreviated PKE (Article 398 PKE). |
| Processing records | Article 30 GDPR provides for a controller’s record of its processing activities and a processor’s record of categories of activities carried out for controllers. A platform acting in both roles needs to address both. |
One platform, different roles at different stages
A GDPR role belongs to a processing activity, not to a software system. A customer’s name, telephone number, and inquiry description can be handled under different roles as the inquiry moves from your form to a contractor and into the contractor’s dashboard.
1. Collecting the inquiry: the operator as controller
When a customer submits your form, you decide which fields it contains, why the data is collected, how long it is kept, and which contractor receives it. The purposes may include matching, verification, and commission settlement.
For this stage, you are a controller under Article 4(7) GDPR. You need an Article 6 legal basis, an Article 13 privacy notice, and a controller’s processing record under Article 30(1).
The approved approach in the source is to display the name of the contractor who will receive the inquiry before the customer submits the form, addressing the recipient information under Article 13(1)(e). Do not leave that identification solely for a confirmation email or buried terms: show it on screen before the customer clicks “Send.”
2. Delivering the lead: the contractor as a separate controller
After receiving the inquiry, the contractor decides independently whether and when to contact the customer, what to offer, and how long to retain the data. On that model, the contractor is a separate controller, not a joint controller with the platform. Joint controllership under Article 26 requires jointly determined purposes and means; the fact that both businesses handle the same lead does not, by itself, establish that arrangement.
The practical consequences are distinct:
- The contractor has its own Article 14 GDPR information obligation to the customer whose data it receives.
- Your privacy policy should explain the separate roles; on this model, you do not need a joint-controllership arrangement for delivering the lead.
- The platform’s confirmation email should provide the recipient’s registration details and a link to its privacy policy.
The platform remains the disclosing controller when it delivers the lead. It also needs a process for handling and forwarding relevant erasure and recipient-notification requests under Articles 17 and 19 GDPR.
3. Hosting contractor dashboard data: the operator as processor
A contractor may upload employee contact details, service descriptions, and photographs of completed work to its dashboard. Where the contractor supplies and controls that material for its own purposes and you provide the tool, you act as a processor for that processing.
Article 28 GDPR then calls for a data processing agreement, processing on documented instructions, and breach-reporting arrangements. You also need the processor’s Article 30(2) record of categories of processing carried out for contractors.
When dashboard content becomes platform marketing
Suppose your marketing team takes a photograph from a contractor’s dashboard and posts it on the platform’s social media account. That is no longer merely providing the dashboard:
- You have moved beyond the contractor’s instructions.
- You are using entrusted material for the platform’s own purpose.
- Under Article 28(10) GDPR, the operator becomes a controller in respect of that processing.
- If identifiable people appear, the use raises legal-basis and information-notice issues.
If the photograph is to advertise the platform, the source’s practical instruction is to obtain separate consent to use the person’s image, granted directly to the operator. Do not treat access to contractor-uploaded material as permission to use it in your own campaigns.
Role map for the main workflows
| Data-flow stage | Operator’s role | Operator’s main obligations | Other party |
|---|---|---|---|
| Customer submits an inquiry | Controller | Article 13 notice; Article 6 basis; Article 30(1) record; display the receiving contractor’s name before submission | — |
| Platform delivers the lead | Disclosing controller | Identify the recipient in the confirmation email; maintain a process for relevant Articles 17 and 19 requests | Contractor acts as a separate controller and provides its Article 14 information |
| Contractor uploads dashboard material | Processor | Article 28 agreement and instructions; agreed breach notification; Article 30(2) record | Contractor controls its employee data and uploaded material |
| Platform sends a post-lead verification survey | Controller | Separate, optional contact consent; separate email and SMS choices; disclose the contact schedule | — |
| Platform uses contractor material in its marketing | Controller for that use under Article 28(10) | Separate image-use consent as described above; responsibility for a legal basis | — |
Commission verification: design the form around the follow-up
A commission model may depend on confirming whether the customer and contractor signed a contract. In the example described here, the platform contacts customers after 30, 60, and 90 days, and again after 6 and 11 months.
Operators have relied on legitimate interests under Article 6(1)(f) GDPR to justify this contact: they need to establish whether a commission is due. That position requires a documented balancing test. One factor is the customer’s reasonable expectations when the data was collected (GDPR, Recital 47). Someone requesting a bathroom renovation quote may not expect calls and messages about the resulting contract for the next 11 months.
Poland’s Electronic Communications Law adds a separate question
Article 398(1) of the PKE prohibits using telephones and terminal equipment to send commercial communications without prior consent, including in B2B relationships. It replaced earlier provisions in Poland’s electronic-services and telecommunications legislation.
The source draws a distinction between a contact confined to verifying data or contract status, which is generally outside Article 398, and a contact that recommends other offers, encourages a purchase, or contains another promotional element, which becomes a commercial communication requiring prior consent.
This boundary is not conclusively settled for surveys. Neither the President of the Office of Electronic Communications (UKE) nor the President of the Personal Data Protection Office (UODO) has issued an unequivocal position directly resolving whether a telephone satisfaction or verification survey is a “commercial communication.” The actual content matters more than calling it a survey.
Make verification consent optional and specific
The source’s recommended form design uses a separate, optional checkbox for contact to verify whether a contract was concluded. A customer must still be able to submit the inquiry without selecting it; otherwise, the consent may not be freely given under Article 7(4) GDPR.
| Form element | Required or optional | Blocks inquiry submission if incomplete? |
|---|---|---|
| Inquiry details, such as name, telephone number, and description | Required | Yes |
| Confirmation that the customer has been shown the privacy policy | Required as information, not acceptance of the policy | Yes |
| Acceptance of terms and conditions | Required as a separate action | Yes |
| Consent to verification by email | Optional | No |
| Consent to verification by SMS | Optional; separate field | No |
| Consent to email marketing | Optional; separate field | No |
| Consent to SMS marketing | Optional; separate field | No |
Keep email and SMS choices separate, and do not combine verification with marketing. Different purposes call for distinct choices (UODO guidance on consent as a legal basis). Record the choices and explain the proposed follow-up schedule in the privacy policy.
Without optional consent for the survey, the source warns that the platform may lack a reliable evidentiary basis for verifying commission settlements. That is a business-model risk as well as a form-design issue.
Consent banners, advertising tools, and deduplication
Make rejecting cookies easy
GDPR consent must be freely given, specific, informed, and unambiguous. Preselected boxes do not meet that standard. The European Data Protection Board’s guidance on deceptive interface patterns is relevant where a banner emphasizes “Accept” but hides “Reject” behind another layer.
The safer design is to make both options readily available on the first layer of the cookie banner. The source does not claim that binding guidance requires identical-looking buttons. The functional question is whether users can refuse easily when the interface is assessed as a whole.
Hold analytics and pixels until consent
The source treats the necessity exception in Article 399(3) PKE as applying only to session cookies, not to analytics or advertising pixels. On that basis, block those tools until consent is obtained.
Also check advanced matching and enhanced conversions on your forms. If enabled, they may send hashed customer email addresses and telephone numbers to an advertising platform. Hashing does not, in the source’s analysis, supply a legal basis for that transfer; its instruction is to disable the feature.
An advertising integration may also change the role analysis. In Case C-40/17, Fashion ID, the Court of Justice of the European Union addressed how deliberately embedding a third-party element serving a shared purpose may create joint controllership for the collection and transmission phase (CJEU press release). Assess the actual mechanism, rather than relying on a vendor’s product label.
Do not reveal database membership through deduplication
A form that compares telephone numbers and responds, “This inquiry has already been submitted,” may tell whoever is using the form that another person’s number is in your database. The source characterizes this as a breach affecting that third party.
Its proposed design is a server-side flag for logged-in users and a session cookie for guests. Do not compare telephone numbers for this purpose or display a message that reveals a number’s presence in the database.
Make the privacy policy match the product
A polished notice cannot compensate for controls that do not exist. Before publication, check each commitment against the code, integrations, support procedures, and backup configuration.
| What the document says | What the product does | Risk |
|---|---|---|
| A heading says advertising providers are joint controllers | The same section’s text calls them separate controllers | An internally inconsistent explanation of roles |
| “We retain data for 12 months” | No automated deletion or backup overwrite cycle exists | Storage-limitation risk |
| “You can withdraw consent at any time” | No dashboard control or withdrawal link is available | Article 7(3) GDPR risk |
| “We will notify recipients of erasure” | Contractors are not notified after an Article 17 request | Erasure and recipient-notification process remains incomplete |
The useful test is simple: can the team demonstrate the operational counterpart of every promise in the policy? A Polish UODO decision concerning processing without a legal basis also illustrates why a written explanation is no substitute for a working basis and process.
Put legal deadlines and operational commitments on one calendar
The source combines GDPR reporting periods with platform settings, retention periods, and timelines commonly set in processing agreements. They are not all statutory deadlines. Assign an owner to each and document which obligation or contract establishes it.
| Period | Event or operational commitment | Suggested owner |
|---|---|---|
| 180 seconds | Validity of the SMS code verifying an inquiry | Product / backend |
| 36 hours | Notify the contractor-controller of a breach involving data processed for it, under the agreed process | DPO / compliance |
| 72 hours | Assess and, where required, report the platform’s own breach to the President of UODO | DPO / management |
| 3 business days | Forward a relevant data subject request to the contractor | Customer service / DPO |
| 14 days | Give contractors advance notice of a subprocessor change under the proposed arrangement | Legal / operations |
| 30 days | Delete entrusted data after the agreement ends under the agreed process | Product / backend |
| 12 months | Commission settlement period from delivery of the inquiry | Finance / legal |
| 3 years | Retention linked to limitation of claims, calculated to the end of the calendar year as described in the source | Legal |
| 5 years | Retention of accounting documentation | Accounting |
Build the 36-hour and three-business-day commitments into your contractor agreements and procedures rather than assuming that every figure in the table is written directly into the GDPR. For your own breach, the 72-hour notification entry requires an assessment of whether reporting is required.
Keep two Article 30 records
An operator acting both as controller and processor should maintain:
- A controller’s record of processing activities under Article 30(1) GDPR, covering, for example, customer inquiries, commission settlement, and marketing data.
- A processor’s record of categories of processing under Article 30(2), covering work done for contractors, such as hosting employee details, offer materials, and photographs.
The exemption for organizations with fewer than 250 employees does not apply where processing is not occasional (Article 30(5) GDPR). A lead generation platform handling inquiries regularly should not assume that its size removes the record-keeping obligation.
Make the subprocessor list available in the contractor dashboard and, under the source’s proposed arrangement, give 14 days’ advance notice of a change. Article 28(2) GDPR requires the contractor-controller’s prior specific or general written authorization for engaging subprocessors; manage changes consistently with that authorization and the processing agreement.
Review the whole vendor stack and international transfers
Do not postpone Article 28 agreements for vendors that process personal data on your behalf. The categories below are a working inventory, not a substitute for checking each vendor’s actual role and data flow.
| Vendor type | Typical data | Processing arrangement to check | Transfer outside the EEA? |
|---|---|---|---|
| Hosting / database | Platform data | Article 28 agreement | Check server locations |
| Content management system | Content and account data | Article 28 agreement | Check |
| SMS provider | Numbers and message content | Article 28 agreement | Check |
| Email provider | Addresses and correspondence | Article 28 agreement | Check |
| Analytics tool | Identifiers and behavioral data | Processing agreement or joint-controllership analysis | Check |
| Advertising platform | Hashed contact details | Processing arrangement or joint-controllership analysis | Check |
| Consent management platform | Consent logs | Article 28 agreement | Check |
| Accounting firm | Settlement data | Article 28 agreement in the source’s vendor map | Usually not |
For transfers outside the European Economic Area (EEA), a US server location or a general claim of compliance with the EU–US Data Privacy Framework is not enough. Check whether a relevant US vendor is certified in the Framework’s register. If it is not, the source directs operators to use standard contractual clauses under Article 46 GDPR together with an assessment of the recipient country’s law and practices (EDPB Recommendations 01/2020).
Check whether DSA and P2B duties overlap
The privacy work may sit alongside duties under the EU Digital Services Act (DSA) and platform-to-business (P2B) Regulation. The source flags these obligations for a platform that enables consumers to conclude contracts with businesses; check their application to your actual service model.
The operational items it identifies are:
- Trader identity verification, including retention of identification data for six months after the business relationship ends (Article 30 DSA).
- Reasons for a moderation decision, addressing the restriction, facts, legal or contractual basis, automated means, and redress options (Article 17 DSA).
- Reasons for restricting or suspending service to a business user, provided on a durable medium (Article 4 P2B).
- Points of contact for authorities and service recipients (Articles 11–12 DSA).
- An internal complaint-handling system (Article 11 P2B).
Suspending a contractor’s account may trigger reason-giving requirements under both regulations. As an operational measure, the source recommends three distinct website-footer addresses: general inquiries, personal data matters, and a DSA contact for content reports.
An implementation sequence for product and legal teams
For a platform with relatively few integrations, the source estimates approximately four to eight weeks as a minimum realistic implementation window. That is a project estimate, not a GDPR grace period. Prioritize activities that currently lack a workable legal basis or control.
| Week | Action | Owner |
|---|---|---|
| 1 | Inventory data flows and assign controller or processor roles by activity | Legal + product |
| 1–2 | Identify a basis for each operation; document any legitimate-interests balancing test | Legal |
| 2–3 | Separate form choices, show the recipient’s name, and log consent choices | Product + frontend |
| 2–3 | Draft the first-layer notice and a privacy policy that matches the product | Legal |
| 3–4 | Put vendor processing agreements in place and review non-EEA transfers | Legal + operations |
| 3–4 | Configure the banner; hold analytics and pixels pending consent; disable enhanced conversions | Marketing + product |
| 4–5 | Establish both Article 30 records | Legal / DPO |
| 4–5 | Implement breach and request-forwarding procedures, including the agreed 36-hour and three-business-day targets | DPO + customer service |
| 5–6 | Remove promotional content from verification surveys and add an opt-out to every contact | Marketing + legal |
| 6–8 | Test product behavior against documents and monitor the controls | Legal + QA |
How we can help
We audit a platform’s data journey from inquiry form to commission settlement. That includes mapping roles by activity, reviewing consent choices and logs, preparing vendor processing agreements, and checking whether the privacy policy describes the live product.
The work can be scoped at three levels:
- Operational minimum: a stage-by-stage role map, corrected form choices, and a first-layer privacy notice.
- Solid foundation: documentation, vendor agreements, both Article 30 records, and breach and request-handling procedures.
- Full implementation: work with the product team, contractor audit questionnaires, and operational templates for moderation reasons, GDPR request responses, and contractor suspensions.
The aim is not documentation for its own sake. It is to put controls where the platform actually creates risk. Contact us if you need help connecting the legal design to the product.
Frequently asked questions
Is the platform a joint controller with its contractors?
Usually not on the workflow described here. If a contractor independently decides whether and when to contact a lead, what to offer, and how long to keep the data, it acts as a separate controller. The platform is a controller when collecting and disclosing the inquiry, but may be a processor for material the contractor uploads to its dashboard. Explain those roles in the privacy policy and use an Article 28 agreement for the dashboard processing; do not assume an Article 26 arrangement is needed merely because both parties handle the lead.
Will an extra survey checkbox reduce form conversions?
It adds an action for the customer, but the source identifies no verified numerical benchmark in Polish official sources or primary research showing that one checkbox reduces conversion by a particular percentage (UODO guidance). The source considers the risk of losing reliable evidence for commission settlement more significant than a possible conversion reduction. The verification choice must remain optional and must not block the inquiry.
Do we need two processing records if we have fewer than 250 employees?
Yes, on the source’s model of regular lead processing. The Article 30(5) exception does not apply where processing is not occasional. Maintain an Article 30(1) record for your controller activities and an Article 30(2) record for categories of work carried out as a processor for contractors.
How long can we retain a lead if commissions are settled over 12 months?
Distinguish the purposes. The source specifies 12 months from delivery for commission-settlement data, up to three years calculated to the end of the calendar year for data connected with claims, and five years for accounting documentation. Delete data associated with a purpose when its applicable period ends, with automatic deletion and a defined backup overwrite cycle.
Can we run analytics or pixels before consent if contact data is hashed?
No, under the source’s approach. It treats the Article 399(3) PKE necessity exception as limited to session cookies, not analytics or advertising pixels. Hashing does not itself provide a basis to send customer contact details to an advertising platform. Disable advanced matching and enhanced conversions on forms, and hold analytics and pixels until banner consent is obtained.
What will a regulator examine: the privacy policy or the product?
Both. A policy promising deletion, recipient notifications, or easy consent withdrawal creates a clear point of comparison with the system and support process. The President of UODO has imposed penalties concerning processing customer and prospective-customer data without a legal basis. Check every policy commitment against a functioning control.
The starting point is a role map tied to real data flows. From there, separate the form choices, put processing agreements in place, and test whether each privacy-policy statement is true in the live platform.