GDPR Vendor Risk Management for Lead Data

Before I share lead data with a vendor, I check whether GDPR applies, where the data goes, and what the vendor does with it. A signed data processing agreement (DPA) is only part of that review.

I use five checks to guide approval:

• Map the data: Record fields, purposes, recipients, access countries, and deletion dates.
• Check legal grounds and roles: Identify a lawful basis for each purpose and confirm who controls the processing.
• Review vendors and contracts: Check security, Article 28 terms, sub-processors, and support for individual rights.
• Verify transfers: Confirm a valid transfer mechanism and assess safeguards for each cross-border route.
• Test and monitor: Test deletion and breach response, assign owners, and review changes.

My rule: <u>approve the data flow, not just the paperwork</u>. I also keep breach deadlines straight: processors notify controllers without undue delay; controllers generally have 72 hours to notify authorities when notification is required.

GDPR Vendor Questionnaire (12 Questions) | TPRM | SAFE Security

sbb-itb-5f36581

Assess Vendor Risk Before Onboarding

Use the flow map and role assignments from the prior section to score each vendor before any lead data moves. Review only the services, fields, and recipients enabled for that data.

Article 28 requires controllers to choose processors that provide sufficient guarantees. Document your checks in proportion to the risk. Marketing and sales define the workflow scope and data sensitivity. Security reviews technical safeguards. Privacy and legal review processor terms, transfers, and sub-processor authorization. Procurement holds the signature until evidence and approvals are on file.

Review Security and Privacy Evidence

Confirm the legal entity, service scope, processing locations, and incident history. Identify every processor and sub-processor in the chain, along with their contacts.

Security should assess Article 32 safeguards against the level of risk and review ISO 27001 or SOC 2 reports, test summaries, and remediation records. Check dates, service coverage, exclusions, and unresolved findings. A certification offers little assurance if it doesn’t cover the service you’ll use.

Test Rights Requests, Breach Response, and Deletion

Once you’ve reviewed the evidence, test whether the vendor can meet its obligations in practice.

Before approval, test exports and support for applicable rights requests. Verify that objections stop follow-up messages and that suppression changes reach connected systems.

Test deletion across active records, caches, integrations, and sub-processors. Check that failed CRM syncs cannot restore deleted records. Require documented backup expiration and deletion verification. Also confirm that the process for sub-processor change notices and objections works.

Do not apply the controller’s 72-hour notification deadline to processors. Processors must notify controllers of personal data breaches without undue delay; contracts often shorten that window to 48 hours. Controllers must notify authorities within 72 hours of awareness. Test escalation contacts and confirm that the vendor can supply breach information in time.

Score Risk and Set Approval Requirements

Rate impact and likelihood separately for each factor below, then record the residual risk after controls. Approval cannot waive legal requirements. Sensitive data or extensive profiling may require a DPIA before processing starts.

Check DPAs and Processor Duties

After the vendor risk review, put the approved terms into the contract.

Article 28 requires a binding written contract or another binding legal instrument when a vendor processes lead data on your behalf. The DPA makes the onboarding review enforceable. Click-accept terms count if they’re binding, retrievable, and include every Article 28 term. Save the accepted version, acceptance record, effective date, and incorporated annexes.

Each document has a different job. Service terms cover commercial matters, privacy notices inform individuals, security addenda specify safeguards, and transfer mechanisms address international transfers. Properly completed Standard Contractual Clause modules may also include Article 28 duties.

Verify Required Article 28 Terms

Match the processing annex to your approved field inventory, purposes, and categories of data subjects.

Examples of fields to include, where applicable: names, business email addresses, job titles, and submission timestamps.

Use this checklist to check whether the contract matches the approved vendor risk profile. Fill in the status during review.

Checklist based on Article 28 requirements and related guidance.

Match Contract Terms to Vendor Practices

Compare permitted uses with the vendor’s privacy notice and operating documents for form submissions, CRM syncs, enrichment, analytics, and downstream deletion. Check breach escalation, support access, retention settings, integration copies, and sub-processor practices. Investigate any language that allows sale, profiling, dataset combination, or independent product development.

Processing for the vendor’s own purposes needs a separate role assessment. A vendor that decides the purposes and means for that activity becomes a controller under Article 28(10). Document the lawful basis, notice duties, and role allocation instead of treating those uses as processor instructions.

For a proposed workflow using Reform, check the current DPA and security documents against actual data locations, transfer terms, retention settings, and deletion procedures. Record each gap, owner, deadline, and closure evidence. Use these documented data paths to confirm cross-border routes in the next section.

Check International Transfers and Sub-Processors

Use the approved processing terms to check where lead data is accessed, transferred, and backed up.

Map access - not just server locations - before processing starts. For form submissions, distinguish the contracting entity from the entities handling hosting, backups, support, and downstream processing. Before approval, record each entity’s name, contact details, task, country, and onward recipients. Sub-processor approval is incomplete until you’ve mapped both the contract and the transfer path.

Remote access from outside the EEA is a restricted transfer when a separate recipient can access the data - even if the server stays in the EEA. Use this inventory to assign a legal mechanism and a review trigger to each route.

Map Transfer Routes and Legal Mechanisms

Assign a mechanism to every restricted transfer, including onward transfers. Check that any adequacy decision remains in force and covers the recipient.

If you rely on the EU–U.S. Data Privacy Framework, confirm that the specific legal entity is actively certified on the official list. Its certification must also cover the lead data involved. Otherwise, verify the correct SCC module or another safeguard for each route.

Use a transfer-control table to link each route to its evidence and approval decision.

Do not use Article 49 derogations for recurring lead transfers. Consent or contractual necessity should not serve as a standing fallback. For onward transfers, check the exporter’s mechanism and assessment. Your team’s responsibility does not disappear because it isn’t the direct exporter. Review a sample of downstream contracts to check vendor claims.

Assess Transfer Risks and Added Safeguards

If a route relies on SCCs or another safeguard, check whether that protection works in practice. Where required, review the transfer impact assessment (TIA) against destination-country law, government access practices, and the actual processing.

Test encryption, key separation, pseudonymization, access limits, logging, and support controls against what the recipient can actually access. Encryption does not resolve plaintext-access risks if the recipient holds the keys or needs to read the data.

Keep the assessment and supporting evidence. Reassess when recipients, laws, access, or processing volume change. Block or suspend transfers when effective protection cannot be established - even if SCCs are signed.

Monitor Vendors and Fix Compliance Gaps

After onboarding, keep vendor controls up to date with scheduled reviews and evidence checks.

Assign one accountable owner from privacy, legal, or compliance. Maintain a central vendor register that records the owner, processing scope, locations, risk tier, review date, contracts, safeguards, incidents, corrective actions, and exceptions. Give every open exception an end date.

Set Risk-Based Review Schedules

Review technical and organizational measures at least annually, with more frequent reviews for high-risk processing. Reassess at renewal and whenever collection purposes, security architecture, sub-processors, data storage locations, or third-country support access change. Require vendors to notify the named owner directly about these changes.

Schedule repeat checks and document the results. Track failures in rights handling, deletion, and breach tests. Give each issue an owner, a deadline, and a closure check. Suspend sharing if updated security evidence is missing, a sub-processor change goes unreported, or deletion cannot be demonstrated within the required timelines. When a vendor relationship ends, verify deletion through logs or certificates, including removal from all connected systems.

Complete the Compliance Evidence Checklist

Use the register to keep one audit-ready file for each vendor.

Conclusion: Key Controls and Common Gaps

Keep lawful bases, processor safeguards, transfer arrangements, and monitoring up to date. Check for incomplete DPAs, undisclosed processing changes, outdated evidence, and unverified deletion. Close gaps with tested fixes - not updated paperwork alone.

FAQs

Does GDPR apply to my U.S. business’s lead forms?

Yes. GDPR applies if your U.S. business handles personal data from people located in the EU or EEA. If your lead forms collect that data, you must meet GDPR requirements. That includes a signed Data Processing Agreement (DPA) with vendors that process the data on your behalf.

Cross-border transfers also require a valid transfer mechanism, such as the Data Privacy Framework or Standard Contractual Clauses (SCCs).

Can I rely on legitimate interests to share lead data?

You may rely on legitimate interests for expected B2B follow-up when a form shows clear buying intent. Document why you’re processing the data, complete a formal balancing test, and record this lawful basis alongside your processing activities.

Legitimate interests generally aren’t suitable for optional marketing, newsletters, or behavioral tracking. These activities require active, informed consent. Whatever lawful basis you use, provide a clear notice when you collect the data.

Can a vendor use my lead data to train AI?

Generally, no. A vendor acting as a data processor must follow your documented instructions. Using your lead data to train its own AI models would typically count as an “own purpose” use - and a major compliance red flag.

Your Data Processing Agreement (DPA) should limit processing to the contracted service and prohibit other uses. Also, check the vendor’s privacy policy for language about AI training or secondary data use.

Related Blog Posts

• Questions to Ask Vendors About GDPR Compliance
• Data Processing Agreement: SaaS Guide
• GDPR-Compliant Form APIs
• How Processors Handle Lead Data Rules