Before a lead is listed, previewed, purchased, or synchronized, document who decides why the personal data is processed, who acts on instructions, what each party will do, what the person was told, which fields are necessary, how long each copy remains, and who handles rights and incidents. The answers depend on the real service, parties, jurisdiction, and contract. This checklist structures the review; it is not legal advice or a conclusion that a transfer is lawful.
1. Map the parties by decision, not label
List the originating agency, marketplace operator, prospective buyer, CRM and infrastructure providers, verification services, and any sub-processors. For each processing activity, record who determines the purpose and essential means, who follows documented instructions, and whether two parties jointly determine a purpose. Do not assume the marketplace is always a processor or that the buyer inherits the seller’s original purpose.
The UK Information Commissioner’s Office explains that controller and processor status follows actual responsibilities, not the name used in a contract. Start with the ICO’s controllers and processors guidance, then obtain qualified advice for the exact workflow.
2. Define one purpose for every stage
| Stage | Purpose to document | Evidence |
|---|---|---|
| Eligibility | Decide whether a non-fit lead may enter the marketplace workflow. | Rule version, reviewer, source fields, exclusions. |
| Masked preview | Help an authorized buyer evaluate fit without unnecessary identity data. | Preview schema and field-level suppression test. |
| Acceptance | Permit the named buyer to receive the approved handoff record. | Terms version, timestamp, price, accepted record snapshot. |
| Follow-up | Allow the buyer to perform its documented outreach or qualification workflow. | Buyer purpose, notice, suppression and outcome controls. |
If the purpose changes, reopen the review. “Business development” is usually too broad to explain a multi-party transfer. Connect this stage map to the non-fit lead decision guide.
3. Record the lawful-basis and transparency analysis
For every purpose and party, record the proposed lawful basis, who approved it, source documents, balancing or consent evidence where applicable, and the next review date. Keep this separate from commercial permission to use the marketplace. A contract between businesses does not automatically resolve duties owed to an individual.
Compare the actual journey with the notice a person received. Can they understand the categories of recipients, new purpose, contact path, retention, and choices before or at the required time? Preserve the notice version linked to the lead’s source event. Do not backfill a new disclosure as if it existed when the data was collected.
4. Minimise the preview and accepted packet
Define two schemas: the masked preview and the post-acceptance handoff. For each field, name the decision it supports, whether a less identifying value would work, and when it is revealed. Remove free-text notes that may contain unrelated people, health information, credentials, or confidential customer details. The ICO’s current data minimisation guidance describes personal data as needing to be adequate, relevant, and limited to what is necessary for the purpose.
Use the partner-ready lead record to separate facts, attributed statements, inferences, freshness, and unnecessary data.
5. Put processor and sharing terms beside controls
Where a processor relationship exists, record the written terms, instructions, confidentiality, security, sub-processor, assistance, deletion/return, audit, and international-transfer provisions required for the context. Where parties act as separate or joint controllers, document responsibilities for transparency, rights, records, security, and incidents rather than forcing the relationship into a processor template.
Translate terms into tests: which role can reveal identity, export a record, change retention, reconnect a CRM, or view audit history? A contract and an interface that permit different behavior create an operational gap.
6. Define retention, rights, correction, and suppression
Set clocks for rejected previews, expired reservations, accepted handoffs, disputes, audit evidence, backups, and buyer copies. Name the deletion trigger, owner, exception, and verification evidence. Document how access, rectification, restriction, objection, deletion, and suppression requests reach each relevant party. A lead must not reappear from a CRM sync after a valid suppression or correction.
Link correction handling to the dispute evidence packet and freshness handling to the lead freshness SLA.
7. Assign security and incident ownership
Record authentication, least-privilege roles, encryption boundaries, export controls, logs, alerts, credential rotation, buyer offboarding, and recovery. Define who investigates suspected unauthorized access, preserves evidence, contacts other parties, evaluates notification duties, and stops further transfer. Test a scenario in which a buyer account is compromised after a purchase and another in which a webhook sends the wrong record.
Release gate
- Every processing stage has a named purpose, party analysis, owner, and source document.
- The live notice and contract match the implemented data path.
- Preview and handoff schemas pass field-level minimisation review.
- Retention, rights, correction, suppression, and incident paths are tested.
- Material assumptions, jurisdictions, unresolved questions, and review dates are visible.
Sources and next step
Primary references: the ICO’s controller and processor guidance and data minimisation guidance. Verify current law and regulator guidance for every applicable jurisdiction.
Next, define what the buyer must accept before purchase with the buyer acceptance criteria checklist.