GDPR compliance feels like paperwork until the regulator comes knocking — and then it feels like archaeology. Where did this contact's consent come from? When did they ask to be deleted, and did anyone act on it? How long have you kept this data, and why? Your CRM is the system where most of those questions get answered, or where the answers go missing. Here is how to make your CRM do the heavy lifting on GDPR.
Why the CRM is the centre of GDPR gravity
Almost every GDPR obligation touches personal data, and for most businesses the CRM holds more personal data than any other system: names, emails, phone numbers, enquiry details, purchase history, marketing preferences, notes from calls. The data subject rights — access, rectification, erasure, portability, objection — all ultimately mean "find everything you hold on this person and do something with it". If that data is scattered across spreadsheets, inboxes, and three different tools, a subject access request becomes a forensic exercise.
A well-configured CRM changes the equation. One searchable record per person, a complete history of consent and communication, retention rules applied automatically, and an audit trail of who did what. That is not just convenience — it is the difference between responding to a request in days and scrambling for a month. Our GDPR and SEO guide covers the marketing-data side of the same problem; this article is about the operational core.
Consent tracking: the record that matters most
Under UK GDPR, consent must be freely given, specific, informed, and unambiguous — and you must be able to demonstrate it. "They've been on our list for years" is not a demonstration. Your CRM should record, for every contact:
- What they consented to: marketing emails, phone calls, SMS, profiling — each as a separate, granular preference, not a single "opted in" flag.
- When and how: the timestamp, the source (website form, event, phone call), and ideally the exact wording they agreed to. Screenshots or stored form versions matter if consent is ever challenged.
- Every change: when they opted out, opted back in, or narrowed their preferences. The history is as important as the current state.
Build consent capture into every form and every manual contact creation. If a salesperson adds a business card to the CRM, there should be a required field for the lawful basis — consent, legitimate interest, or contract — because "I'll fill it in later" means it never gets filled in. And wire unsubscribes directly into the CRM: an unsubscribe link that updates the email tool but not the CRM is how people get emailed after opting out, which is exactly the complaint the ICO takes seriously.
Handling data subject requests without panic
Individuals have the right to access their data, correct it, erase it, restrict processing, take it elsewhere, and object to certain uses. You have one calendar month to respond (extendable for complex requests), and the clock starts when you receive the request, not when you get around to it.
Your CRM should make each right operational:
- Access (SARs): one search should surface every record, note, email, and attachment tied to the person. If your CRM cannot export a complete contact history in a portable format, a SAR will expose that gap painfully.
- Rectification: corrections made in the CRM should propagate to connected systems — email tools, support desks, billing. A correction that only fixes one system is half a correction.
- Erasure ("right to be forgotten"): define a deletion workflow: anonymise or delete the contact record, remove them from synced systems, and record that the request was fulfilled and when. Note the exceptions — you may need to keep some records for legal or tax reasons, in which case document the basis rather than just keeping everything.
- Objection and restriction: suppression lists are as important as mailing lists. An objected contact must be flagged so thoroughly that no campaign, automation, or manual export can reach them. The classic failure is a sales rep exporting "all contacts" to a spreadsheet and emailing people who opted out months ago.
Log every request and its outcome in the CRM itself. If the ICO ever asks how you handled a complaint, "here is the record" beats "we think we dealt with it" every time.
Retention rules: stop keeping data "just in case"
UK GDPR requires you to keep personal data no longer than necessary. "Just in case" is not a retention policy. Define retention periods by data type and build them into the CRM:
- Prospects who never became customers: a common standard is 12–24 months from last meaningful contact, then anonymise or delete. Holding five-year-old enquiry data "in case they come back" is hard to justify.
- Customers: keep for the relationship plus a defined period afterwards (often aligned with tax record requirements — six years for financial records in the UK — but marketing data does not need to ride along for the whole period).
- Marketing engagement data: opens, clicks, and browsing behaviour age fast. Decide what you actually use and drop the rest on a schedule.
Automate the enforcement. Most modern CRMs support retention workflows: flag records past their retention date, notify an owner, then anonymise or delete after a grace period. Manual retention reviews do not happen; automated ones do. Document the policy and the schedule — the ICO cares that you have a reasoned policy and follow it, not that you picked any particular number of months.
Audit trails and access control
Accountability is a GDPR principle, not a suggestion. Your CRM should record who viewed, created, modified, exported, or deleted personal data, and when. This serves two purposes: investigating incidents (who exported that list?) and demonstrating control to the regulator.
Access control matters as much as logging. Apply the principle of least privilege: salespeople see their own contacts, managers see their team's, and nobody exports the whole database without a reason and a record. Review user access when people join, change roles, and leave — ex-employees with active CRM logins are a breach waiting for a headline.
For international transfers — relevant if your CRM provider or any integration stores data outside the UK — check where the data sits and what transfer mechanism covers it. Most major CRM vendors publish this; if yours does not answer clearly, that is an answer.
Making it real: a practical checklist
- Every contact has a recorded lawful basis, consent timestamp, and source.
- Unsubscribes and objections sync to the CRM immediately and are enforced everywhere.
- One search produces a complete exportable history for SARs.
- A documented erasure workflow exists and has been tested.
- Retention periods are defined per data type and enforced automatically.
- User access follows least privilege and is reviewed on role changes.
- An audit trail records access, exports, and deletions.
- Staff know the one-month SAR deadline and who owns requests.
None of this requires exotic technology — it requires a CRM configured deliberately for compliance rather than just for sales. If your CRM was set up years ago and has never had a compliance review, that review is overdue. Our CRM development team builds and configures CRMs with these workflows from the start — talk to us if yours needs bringing up to standard.
FAQs
Can a CRM make my business GDPR compliant on its own?
No — compliance is about policies, processes and people, not just software. But a properly configured CRM is the operational backbone: it centralises personal data, records consent, enforces retention, and produces the audit trail the ICO expects. Without it, compliance is mostly good intentions.
How long should we keep prospect data in the CRM?
Only as long as necessary — a common standard is 12–24 months from last meaningful contact for prospects who never became customers. Define the period, document your reasoning, and automate deletion or anonymisation. "Just in case" is not a lawful retention policy.
What is the deadline for responding to a subject access request?
One calendar month from receipt, extendable by two further months for complex or numerous requests (you must inform the requester of the extension within the first month). The clock starts when the request arrives, so make sure requests are recognised and routed immediately.
Do we need to delete everything if someone exercises the right to erasure?
Delete or anonymise their personal data across the CRM and connected systems, and record that you did so. Limited exceptions exist — for example, records you must keep for tax or legal reasons — but document the specific basis rather than keeping everything by default.
How do unsubscribes relate to GDPR?
Marketing emails generally need consent (or the soft opt-in for existing customers), and every marketing email must offer a working unsubscribe. The critical operational point: unsubscribes must sync into the CRM immediately and be enforced across all systems, so no campaign or manual export can contact someone who opted out.