The Right to Be Forgotten and CRM Data

The right to be forgotten — formally the "right to erasure" under GDPR Article 17 — requires businesses to delete personal data about an individual when that individual requests it, provided certain conditions are met. For CRM systems, this creates a specific operational challenge: customer records, deal histories, email threads, and notes may all contain personal data subject to erasure requests. This guide explains exactly what you're required to do, where most businesses fail, and how to build a compliant process.

What the Right to Erasure Actually Requires#

Article 17 of GDPR gives individuals the right to request that you delete their personal data in the following circumstances:

• The data is no longer necessary for the purpose it was collected
• The individual withdraws consent (where consent was the legal basis for processing)
• The individual objects to processing and you have no overriding legitimate grounds
• The personal data was unlawfully processed
• The data must be deleted to comply with a legal obligation

Note what this doesn't say: it's not an absolute right to have all data deleted under any circumstances. There are exemptions — you can retain data you need for legal claims, for compliance with legal obligations, or for public interest purposes.

In practice for a typical B2B CRM: if a former prospect asks you to delete their data, you generally need to comply. If a customer who has an active contract asks you to delete their data, you may be able to retain it during the contract term under legitimate interest. If a former employee asks you to delete their data from your systems, the analysis is more complex.

Where CRMs Create Erasure Compliance Problems#

1. Data Is Scattered Across Systems#

Your "CRM data" is rarely just the CRM. A single contact record may have associated data in:

• The CRM itself (contact details, deal history, custom fields)
• Your email tool (sent/received email threads)
• Your calendar tool (meeting records)
• Your marketing automation platform (email campaign records, form submissions)
• Call recording systems (sales call recordings, transcripts)
• Enrichment tools (data appended from third-party sources)
• Analytics platforms (behavioral data, session recordings)
• Support ticketing systems

A compliant erasure request requires deletion across all of these systems, not just the CRM. Most businesses don't have a map of where a single person's data actually lives.

Action: Build a data map for each contact record. Identify every system that holds personal data about contacts and map the deletion process for each.

2. Backups and Archives#

Deleting a record from your active CRM doesn't delete it from backups. GDPR's guidance on this recognizes the operational reality: you're not required to rebuild your backup infrastructure to enable per-record deletion from backup tapes. You are required to ensure that if you restore from a backup, you re-apply any erasure requests that had been processed before the backup was taken.

In practice, this means keeping an erasure log — a record of every deletion request you've processed — and re-applying those deletions if you ever restore from backup.

Action: Maintain an erasure log separate from your CRM. When processing an erasure request, log it with a timestamp and the identifier used to find the record. If you restore from backup, re-run the erasure log.

3. AI Training Data#

If your CRM vendor has used your customer data for AI training (see: AI Data Retention Risks), a GDPR erasure request creates a very awkward question: can you delete a person's data from an AI model?

The short answer: not really, with current technology. Once data has been used to train a neural network, the specific training examples can't be removed without retraining the model from scratch. Regulatory guidance on this is evolving, but this is a real compliance gap.

The safer position: ensure your CRM vendor contractually commits not to use your customer data for AI training, or use a local-first CRM where the question doesn't arise.

4. Deal and Transaction Records#

A common source of confusion: you received a deletion request from a former customer. Do you delete the deal record?

The answer depends on what's in the deal record and what your retention obligations are. Financial transaction records may need to be retained for tax, audit, or legal purposes — typically 5-7 years depending on jurisdiction. Personal data that's incidental to the record (the contact's personal email, for example) might be erasable while the core transaction data is retained.

Approach: Separate the "personal data about this individual" from the "business record of this transaction." You may be able to pseudonymize (replace the name and personal identifiers with an anonymous token) while retaining the transaction data.

Building a Compliant Erasure Process#

Here's a step-by-step process you can implement regardless of which CRM you use:

Step 1: Create an erasure request intake#

Set up a dedicated email address or form for data deletion requests. Response is required within one month under GDPR.

Required intake fields:
- Requester's email address (to verify identity)
- Their relationship to your organization (prospect, customer, former employee)
- Any additional identifiers they can provide (company name, job title)
- Date of request (starts your one-month clock)

Step 2: Verify identity#

Before deleting anything, verify that the requester is who they say they are. For a former prospect: send a confirmation email to the address they provided. For a current customer: more robust verification may be appropriate.

Step 3: Locate all their data#

Run a systematic search across every system in your data map:

Search checklist:
□ CRM: search by email address, name, company, phone number
□ Email tool: search inbox and sent mail for their email domain
□ Calendar: search for meetings with their name/email
□ Marketing automation: search subscriber lists, form submissions
□ Call recordings: search for calls with their number or email
□ Support tickets: search for their email
□ Analytics: check if user-level tracking can be tied to them
□ Third-party enrichment: contact the enrichment provider

Step 4: Assess what can be deleted vs. what must be retained#

For each piece of data found:

• Is there a legal, contractual, or legitimate business reason to retain it?
• If yes: can the personal identifiers be removed (pseudonymization) while retaining the business record?
• If no: delete it.

Step 5: Execute deletion#

Delete records in each system. For CRM records: delete or anonymize the contact. For email threads: archive or delete threads containing personal communications.

Step 6: Log the erasure#

Record in your erasure log:

• Date of request
• Date of completion
• Identifier used to locate records (anonymized — don't log the personal data you just deleted)
• Systems where data was found and deleted
• Any data retained with legal basis noted

Step 7: Confirm to the requester#

Send written confirmation that the erasure has been completed, within the one-month deadline.

How Local-First CRM Simplifies Erasure Compliance#

When your CRM data lives locally in DuckDB (as it does with DenchClaw), erasure compliance has one major advantage: you have complete, direct control over your data.

There's no "submit a deletion request and wait for the vendor to process it." There's no "check whether our third-party processor received the deletion request." The data is in a database on your machine. You run a query. The record is deleted.

-- Example: delete a contact and associated records from DenchClaw
BEGIN TRANSACTION;
 
-- First, record what we're deleting (for the erasure log)
SELECT id, name FROM contacts WHERE email = 'subject@example.com';
 
-- Delete the contact record
DELETE FROM contacts WHERE email = 'subject@example.com';
 
-- Remove from deal relationships (keep the deal, remove the person)
UPDATE deal_contacts SET contact_id = NULL, contact_anonymized = true 
WHERE contact_id IN (SELECT id FROM contacts WHERE email = 'subject@example.com');
 
-- Log the erasure
INSERT INTO erasure_log (request_date, completion_date, identifier_hash, systems)
VALUES (NOW(), NOW(), SHA256('subject@example.com'), 'denchclaw_crm');
 
COMMIT;

This is not a feature of DenchClaw specifically — it's a property of having direct database access. When you own your data stack, compliance operations become database operations.

The Third-Party Processor Obligation#

GDPR requires that if you use third-party processors (vendors) who handle personal data on your behalf, you must have Data Processing Agreements (DPAs) with them, and deletion requests must cascade to those processors.

This means:

• Your CRM vendor must have a DPA with you
• When you delete a record, your CRM vendor must also delete it from their systems (including backups, within their stated retention period)
• If your CRM vendor uses sub-processors (cloud infrastructure providers, AI APIs), those must also be covered

This is an area where many businesses are non-compliant not through malice but through ignorance. Audit your vendor relationships and ensure DPAs are in place.

Frequently Asked Questions#

What happens if I receive an erasure request and I've already deleted the record? Good news: if the data is already gone, you've complied. Confirm this to the requester. Keep a note of the request and your response.

Can I charge a fee for responding to erasure requests? Normally, no — GDPR requires responding to requests free of charge. If a request is "manifestly unfounded or excessive" (e.g., repeated requests designed to be disruptive), you may charge a reasonable fee or refuse, but you must be able to justify this.

Does the right to erasure apply to B2B contact data (business email addresses)? Yes, if the data relates to an identifiable natural person. A business email address like sarah@acme.com identifies Sarah — it's personal data. A generic address like info@acme.com may not be personal data.

How long do I have to respond to an erasure request? One month from receipt of the request. You can extend by a further two months for complex or numerous requests, but you must notify the requester of the extension within the first month.

What's the penalty for non-compliance? GDPR fines can reach €20 million or 4% of global annual turnover, whichever is higher — though regulators typically reserve these for serious or repeat violations. More common: formal warnings, reprimands, and orders to bring processing into compliance. The reputational cost of a public enforcement action can exceed the fine.

Ready to try DenchClaw? Install in one command: npx denchclaw. Full setup guide →