From intake to audit trail: the complete compliance checklist for your platform

Compliance does not start at delivery to a buyer: it starts the first second a request lands on your platform. That is the moment you determine whether a lead can be processed lawfully at all, and anything you miss here can never be reconstructed later. A request without a recorded source is a request without evidence, no matter how many publishers are active on your platform.

Start by mapping the channels through which leads reach your operation: your own forms, publisher landing pages, partner APIs, import files or telephony. Each channel has its own risk profile. A publisher you have onboarded and manage yourself is easier to account for than a batch import from an unknown third party. Make sure you know, per channel and per publisher, who supplies the data and under which agreements.

Provenance is the answer to the question: where does this request come from and how did it come about? For a supervisory authority, a buyer, or a data subject asking for an explanation, this is the heart of your accountability as a lead generator. Without traceable provenance, a lead is, in legal terms, a black box, and that risk sits with you as the operator of the platform, not with the individual publisher.

So record more than just a source name. Think of the specific landing page or campaign, the publisher that supplied the request, the time, the IP address or the technique used to make the request, and any intermediaries involved. The richer your provenance data per publisher, the stronger your position when a lead is disputed or a complaint comes in.

For lead processing, consent is by far the most commonly used and usually the cleanest legal basis. But consent only counts if it is valid: freely given, specific, informed and with an unambiguous affirmative action. A pre-ticked box, a hidden condition or an unclear purpose make consent invalid, and with it the entire processing unlawful. As the operator, you carry that responsibility even when the consent was collected by a publisher.

It is not enough to ask for consent; you must also be able to prove it, per publisher and per lead. Record which text the data subject saw, at what moment and through which channel they agreed, and make sure withdrawing is just as easy as giving. Keep the consent evidence linked to the lead in your platform, so you can produce it separately later, even if the publisher is no longer active by then.

A lawful lead is not automatically a usable lead. Verification checks whether the data is correct and consistent before it is routed to a buyer: does the email address exist, is the phone number valid, does the request match the source, and are there signals of fraud or duplicate entry? Quality at the gate prevents you from passing on incorrect or fraudulent data under your own label, which is both a compliance and a reputational risk for your entire lead network.

The accuracy principle of the GDPR requires that you work with data that is correct and traceable. So record not only the outcome of a check, but also that a check was performed, and which publisher supplied the lead. That way you can demonstrate later, to a buyer or a supervisory authority, that every delivered lead met a quality threshold, regardless of which publisher supplied it.

Matching determines which buyer receives a lead. From a compliance perspective the central rule here is: do not share more than necessary and not with more parties than the consent was given for. Data minimisation means a buyer only receives the fields they need for their purpose, not the full profile just because it happens to be available in your system.

Also guard purpose limitation: a lead collected via a publisher for purpose A may not simply be passed to another buyer for purpose B. Matching rules should stay within the bounds of the consent given. Make those bounds explicit in your routing logic, so a processing operation never accidentally steps outside the agreed framework, not even when you run multiple labels or verticals on a single platform.

Routing is the actual moment of sharing: the lead leaves your platform and reaches a buyer. This is a processing operation with legal weight, because this is where the transfer you promised the data subject takes place. Every delivery must therefore be traceable: who received what, when, via which publisher it was supplied, and on which basis.

Treat a failed or duplicate delivery just as carefully as a successful one. A lead that accidentally goes to two different buyers can be a breach of purpose limitation and directly affects the reliability of your entire lead network. Record the status of every delivery (delivered, rejected, in dispute) so your accountability matches what actually happened, platform-wide and per buyer.

The audit trail is the backbone of your accountability as an operator. The GDPR requires not only that you process carefully, but that you can demonstrate it, for every lead, from every publisher, to every buyer. An audit trail that records every processing step immutably, from intake and consent to matching, delivery and deletion, turns “we do it right” into “here is the evidence”, regardless of how many parties come together on your platform.

A usable audit trail is complete, immutable and exportable. Complete, so there are no gaps in the chain, not even between publisher and buyer. Immutable, so the evidence is reliable. Exportable, so you can actually produce it on request or under audit, to a buyer or a supervisory authority. Anyone who only tries to assemble the audit trail afterwards is, by definition, missing the steps they did not log.

The storage limitation principle requires that you do not keep personal data longer than necessary for the purpose. In practice that means: a period per lead status, and automatic deletion once that period is reached, across all your publishers and buyers. A rejected lead should not stay around as long as a delivered lead with an ongoing guarantee towards a buyer.

Make retention periods concrete and enforce them actively at the platform level. Manual cleanup is forgotten sooner or later, especially as volume grows; automated expiry runs according to policy. Deletion is a real processing operation: the data actually disappears from active storage, while the audit trail records that and when a record expired.

A data breach is any incident in which personal data is unintentionally accessed, altered, leaked or destroyed. The GDPR obliges the controller to report a notifiable breach to the supervisory authority within 72 hours of discovery, and to inform the data subjects too where the risk is high. Under that time pressure, a pre-defined procedure always beats improvisation, especially when an incident affects multiple publishers or buyers.

Make sure the route is ready: how you detect, assess, escalate internally and report, including when an incident occurs at an onboarded publisher. As a processor you report an incident to the controller without undue delay, so they can make the legal notification in time. Keep the whole course of events traceable: handling a breach is itself something you must be able to demonstrate as the operator.

Who is responsible for what? The GDPR distinguishes the controller (who determines the purpose and means) from the processor (who processes on instruction). Lack of clarity about who holds which role is one of the most common compliance mistakes in lead chains, and precisely as an operator running multiple publishers, labels and buyers on a single platform, things go wrong quickly without clear agreements.

Record the division of roles explicitly and conclude a suitable agreement with every publisher, buyer and processor you onboard. In addition, work with role-based access within your platform: no one, whether publisher, buyer or team member, sees more data than their function requires. Keep an up-to-date register of processing activities and sub-processors, so you can show at any moment who is involved and under which conditions, regardless of how many parties your platform now serves.