GDPR and CRM Data: How to Manage Your Contact Database Compliantly
Your CRM might be your biggest GDPR liability — especially if it was built before 2018.
Most organisations focus their GDPR efforts on the website: cookie banners, privacy policies, consent flows. But the contact database sitting in your CRM is often a far more serious risk. It contains thousands of individual records — many collected over years without proper consent, with inconsistent data quality, connected to marketing automation tools that broadcast to everyone in the database regardless of how they got there.
GDPR CRM compliance is one of the most commonly neglected areas of privacy law, and one of the most actively enforced. This guide covers everything you need to know: lawful basis by contact type, consent tracking, retention policies, re-permission campaigns, vendor DPAs, and how to handle DSARs from your CRM.
What Your CRM Actually Collects
Before you can establish lawful basis, you need to understand what your CRM holds. Modern CRMs collect far more than a name and email address:
- Contact details: name, email, phone, job title, company, LinkedIn URL
- Interaction history: emails sent and opened, calls logged, meetings attended, support tickets
- Lead scores and lifecycle stage: calculated fields that represent a judgment about the contact
- Custom fields: anything your team has added — budget range, product interest, competitor tools used
- Tags and lists: segmentation data that often reveals the contact's relationship with you
- Notes: free-text fields where salespeople write observations about individuals
- Associated deals and transactions: revenue data linked to a person
- Enrichment data: data added from third-party enrichment services like Clearbit or Apollo
All of this is personal data under GDPR. Notes about an individual, lead scores, and enrichment data are just as much personal data as an email address — and the same rules apply.
The Lawful Basis Question for CRM Contacts
GDPR requires a lawful basis for every processing activity. In a GDPR CRM context, this means you need a documented reason for holding each category of contact — and that reason must be one of the six lawful bases in Article 6.
For most CRM use cases, the relevant bases are consent, contract, and legitimate interest. Here's how they apply by contact type:
Customers
For existing customers, you can rely on contract (Article 6(1)(b)) for data processing necessary to deliver the service — invoicing, account management, technical support. You can also rely on legitimate interest for some marketing to existing customers, particularly in B2B contexts.
The key word is "necessary." If you're storing data beyond what's needed to service the customer relationship, you need a different justification.
Inbound Prospects
Contacts who downloaded content, signed up for a trial, or filled in a contact form are inbound leads. They've voluntarily engaged with you, which gives you more flexibility — but not unlimited flexibility.
Consent is cleanest here. If your lead magnet form explicitly states "by downloading this, you agree to receive follow-up emails," and consent is granular and recorded, you're on solid ground.
Legitimate interest is also defensible for inbound prospects in a B2B context, provided you've conducted and documented a legitimate interests assessment (LIA). The contact chose to engage with you; there's a reasonable expectation of follow-up.
Cold Outreach Contacts
This is where GDPR CRM compliance gets complicated, and where most violations occur.
For B2B cold outreach, the UK's PECR (Privacy and Electronic Communications Regulations) allows marketing emails to corporate contacts under a "soft opt-in" equivalent — provided it's relevant to their role, you give an easy opt-out, and you can demonstrate legitimate interest. This doesn't give you a free pass, but B2B cold email has a defensible legal position if done carefully.
For B2C cold outreach, the rules are much stricter. You need consent from individuals for direct marketing emails. You cannot cold email consumers based on legitimate interest alone.
Importantly: legitimate interest requires a balancing test. You have to weigh your business interest against the individual's reasonable privacy expectations. An unsolicited cold email to someone who has never heard of your company is much harder to justify than follow-up to a warm lead.
Bought or Scraped Lists
This is almost always a GDPR violation — and it creates liability for your entire database.
When you import a purchased list into your GDPR CRM, you're importing records where:
- The consent (if any) was obtained by a third party for a different purpose
- The consent language almost certainly doesn't cover your specific marketing
- You have no record of when or how consent was given
- The data may be out of date, inaccurate, or apply to people who have since opted out
Supervisory authorities across the EU have issued significant fines specifically for bought list marketing. The ICO (UK), CNIL (France), and the Irish DPC have all taken enforcement action in this area. If you have imported lists in your CRM, they need to come out — or you need to run an aggressive re-permission campaign with the expectation that most contacts will not opt in.
The Data Minimisation Problem
GDPR's data minimisation principle (Article 5(1)(c)) requires that personal data be "adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed."
Most CRM setups violate this in two ways:
Custom fields nobody uses. Over time, CRMs accumulate custom fields created for campaigns that never launched, experiments that ended, or requirements that changed. These fields may contain personal data — job function, budget range, notes on personal circumstances — that serve no current purpose. Audit your fields annually. Delete what you don't use.
Enrichment data. Third-party enrichment services automatically populate fields with data the individual never provided — company size, estimated revenue, technology stack, personal social media profiles. This is processed without the contact's knowledge. Unless you have a clear legitimate interest and it's disclosed in your privacy policy, enrichment data is high-risk.
Consent Tracking in Your CRM
If consent is your lawful basis, you must be able to demonstrate it. Article 7 of GDPR places the burden of proof on the controller — you have to prove consent was given, not just assert it.
In a GDPR CRM context, this means recording:
- The date and time consent was given
- The specific form, page, or mechanism through which it was collected
- The exact consent language shown to the individual at that point
- The version of your privacy policy in effect at that time
- Any subsequent withdrawals or changes
Most CRMs support custom fields for this — a "Consent Date," "Consent Source," and "Consent Language" field on the contact record. If yours doesn't, you need a connected system that can.
Critically: consent must be specific, informed, and freely given. A generic "by submitting this form, you agree to our privacy policy" checkbox doesn't constitute valid consent for marketing emails if the privacy policy doesn't make that clear. And consent is not a one-off — if someone withdraws consent, you must act on it promptly across all systems.
Data Accuracy: Keeping Your Database Current
Article 5(1)(d) of GDPR requires that personal data be "accurate and, where necessary, kept up to date." For CRM data, this is a practical as well as legal requirement.
An email address that bounced two years ago, a job title that's three companies out of date, a phone number for someone who's left the organisation — these represent inaccurate personal data that you're still holding and likely still processing.
Practical approaches to maintaining accuracy in your GDPR CRM:
- Automated bounce handling: Hard bounces should trigger immediate review of the contact record, not just suppress emails
- Regular data cleanse cycles: Quarterly or semi-annual review of stale records
- Enrichment on update, not just import: If you use enrichment, schedule re-enrichment to catch role changes
- Self-service profile updates: Give contacts a way to update their own data via email preferences or a profile page
Retention Periods for CRM Contacts
Storage limitation (Article 5(1)(e)) is one of GDPR's most commonly violated principles, and CRM databases are a primary offender. Companies accumulate contacts for years without a deletion policy.
The general principle is that you should not hold personal data longer than necessary for the purpose it was collected. In CRM terms, this means defining retention periods by contact category:
| Contact Type | Typical Retention Period |
|---|---|
| Active customers | Duration of contract + legal minimum (often 7 years for financial records) |
| Churned customers | 2-3 years from last transaction |
| Prospects who engaged | 2-3 years from last interaction |
| Prospects who never engaged | 12-18 months from collection |
| Contacts who unsubscribed | Delete or suppress, retain suppression record |
These are starting points, not legal standards. Your retention periods should be documented in your privacy policy and reflect your actual business needs, not just the maximum you could defensibly argue.
Critically: define what "last interaction" means. Opening an email should not reset the clock indefinitely — regulators have challenged this approach. A meaningful interaction — a reply, a purchase, a meeting — is a more defensible reset point.
Running a Re-Permission Campaign: The GDPR Database Cleanse
If your CRM was built before May 2018 — GDPR's enforcement date — or has accumulated contacts from sources you can no longer verify, you need a re-permission campaign.
A re-permission campaign sends a direct communication to contacts asking them to confirm they want to remain in your database and continue receiving communications. Those who don't respond are removed.
How to structure it:
Segment your database by confidence in lawful basis. Contacts with clear, documented consent are low priority. Contacts from unclear sources are high priority.
Draft a plain-English email explaining that you're updating your contact list, what you'd like to send them, and asking them to click to confirm they want to stay in touch.
Set a response deadline — typically 2-4 weeks. Anyone who doesn't respond is removed from active marketing.
For confirmed opt-outs and non-respondents, move to a suppression list (don't delete immediately if you need to prove you complied with their opt-out).
Document the process — who was emailed, when, what the response rate was, how non-respondents were handled.
Re-permission campaigns typically result in 10-30% of a database confirming. The rest leave. This feels painful, but the 20% who opted in are people who actually want to hear from you — and you're no longer exposed on the other 80%.
CRM as a Data Processor: DPAs with Your CRM Vendor
Under GDPR, your CRM vendor is a data processor — they process personal data on your behalf. Article 28 requires you to have a Data Processing Agreement (DPA) in place with every processor.
The major CRM vendors all offer DPAs:
- Salesforce: Available via the Salesforce Data Processing Addendum in your account settings
- HubSpot: Available through HubSpot's Data Processing Agreement, accessible in the legal section of your account
- Pipedrive: Available through their DPA request process and standard in their Terms of Service for EU customers
Review these DPAs. They should cover: the nature and purpose of processing, the types of personal data involved, security obligations, subprocessor notifications, and breach notification timelines. If your CRM vendor cannot provide a DPA, that's a significant red flag.
International Transfers: US CRMs Processing EU Data
Most major CRM platforms are US companies. When EU contact data flows to US servers, that's an international transfer under GDPR Chapter V — and it requires additional legal safeguards.
Since the EU-US Data Privacy Framework (DPF) was adopted in 2023, transfers to US companies that are DPF-certified are covered. Salesforce, HubSpot, and most major CRM providers are DPF-certified.
However: check your vendor's certification is current (the DPF framework requires active certification, not a one-off sign-up), and check whether EU data is processed on EU-based servers if your DPA specifies that. Some enterprise CRM plans offer EU data residency — worth evaluating if you have a heavily EU-focused contact database.
Handling DSARs from Your CRM
GDPR gives individuals the right to access all personal data you hold on them (Article 15), the right to have it deleted (Article 17), and the right to receive it in a portable format (Article 20).
Your GDPR CRM setup must support this. When a DSAR arrives:
Search across all CRM objects: contacts, deals, companies, notes, emails, activities, custom objects. The individual's data may span all of these.
Export the full record: Most CRMs have a contact export function that covers the standard fields. Notes and activities often require separate exports.
Include associated data: Emails sent to the individual may be logged in your CRM. If so, they're in scope for a DSAR.
Handle erasure across all systems: Deleting a contact in your CRM doesn't remove them from connected tools — your email platform, your marketing automation, your support desk. Erasure must be systematic.
Document the response: Keep a log of DSARs received, the date, how they were handled, and when the response was sent. The one-month deadline (extendable by two months for complex requests) starts from the date of receipt.
Practical Checklist: 8 Things to Audit in Your CRM Setup
- Lawful basis documented: Every contact category has a documented lawful basis in your records of processing activities
- Consent fields populated: If consent is your basis, you have date, source, and language recorded per contact
- Suppression list maintained: Unsubscribes and opt-outs are on a suppression list, not just deleted
- Retention policy defined and enforced: You have documented retention periods and a process to enforce them
- DPA signed with CRM vendor: You have a current DPA in place with your CRM provider
- International transfer safeguards: You've verified your vendor's DPF certification or EU data residency
- DSAR process tested: You've run a test DSAR to confirm you can export all data held on an individual
- Re-permission campaign run (or scheduled): Pre-2018 contacts and unclear-source contacts have been re-permissioned or removed
The Data That Reaches Your CRM Starts on Your Website
Fixing your CRM is essential — but it's downstream. The data that lands in your contact database starts being collected on your website: forms, lead magnets, trial signups, chat tools.
Before you can have clean, compliant GDPR CRM data, you need to understand what your website is actually collecting and sending to your CRM, what consent is being captured (or not) at the point of collection, and which third-party tools are loaded before consent is given.
Scan your website with Custodia to get a complete picture of your tracker exposure, data collection points, and compliance gaps in 60 seconds. It's free, and it shows you the full picture — before it reaches your CRM.
Last updated: March 27, 2026. This post provides general information about GDPR CRM compliance. It does not constitute legal advice. Consult a qualified privacy professional for advice specific to your contact database and business context.
Top comments (0)