Privacy laws in many jurisdictions give individuals rights over their personal data, such as asking what an organization holds about them, correcting it, or asking for it to be deleted. The CRM is usually the first place a request lands, because it holds the contact records. Organizations that handle requests well are not the ones with the cleverest tools. They are the ones with a defined process, clear ownership, and a CRM whose data is organized well enough to answer the question.
Know Which Rights Apply to You
The specific rights, deadlines, exemptions, and verification rules differ by jurisdiction, industry, and your role as a controller or processor of the data. This article describes a general operating process, not legal advice. Ask your legal or privacy advisers which regulations apply and what response timelines you must meet, then build those into the workflow below.
Step One: Intake and Logging
Give people one obvious route to submit requests, such as a dedicated form or mailbox, and make sure staff know to forward any request that arrives elsewhere, including through sales or support. Log each request in a central register the moment it arrives: date received, type of request, requester, the deadline you calculated, and the person responsible. The clock often starts at receipt, so an unlogged request sitting in an inbox is a risk in itself.
Step Two: Verify the Requester
Before disclosing or deleting anything, confirm the person is who they claim to be. Disclosing records to an impostor is itself a privacy breach. Verification should be proportionate: matching the request to the email address on file may be enough for a low-risk request, while a deletion or a full export may justify stronger checks. Avoid collecting more identity information than necessary just to verify.
Step Three: Locate the Data
This is where CRM hygiene pays off. Search across contacts, leads, accounts, activities, notes, attachments, support cases, marketing lists, and custom objects. Then follow the data outward to connected systems: email marketing platforms, data warehouses, billing tools, call recordings, and spreadsheets people exported earlier. A data map that lists where personal data flows makes this step quick; without one, requests become detective work.
Step Four: Decide and Act
Different requests lead to different actions. Access requests need a readable export. Correction requests need updates across every location holding the data. Deletion requests need careful review, because some records may need to be kept for legal, tax, or contractual reasons. Restriction or objection requests, such as stopping marketing, may require suppression rather than deletion so you remember not to contact the person again.
| Request type | Typical CRM action | Watch out for |
|---|---|---|
| Access | Compile records and activity into a readable export | Including other people’s data in the same notes |
| Correction | Update the record and downstream copies | Stale copies in exports and connected tools |
| Deletion | Delete or anonymize, after checking retention duties | Backups, legal holds, and records you must keep |
| Marketing opt-out | Suppress and sync the preference everywhere | Re-import from an old list reintroducing the contact |
| Restriction | Flag the record and limit processing | Automations still firing on the flagged record |
Step Five: Respond and Record
Reply within your required timeframe, explain what you did in plain language, and be honest about anything you did not do and why, such as records retained for a legal obligation. Keep a record of the request, the verification, the actions, and the response. That record is your evidence of good faith if a regulator ever asks.
Design the CRM to Make This Easier
A few structural choices reduce effort on every future request. Keep personal data in structured fields rather than scattered across free-text notes where possible. Record the source and the lawful basis or consent status for each contact. Use consistent identifiers so one person is not duplicated across five records. Limit free-form attachments, and train staff not to paste sensitive details into notes casually. Set retention rules so old, unneeded records are removed routinely instead of waiting for a request to surface them.
A Realistic Example
Suppose a customer emails a company asking for all their data to be deleted. The privacy coordinator logs the request, verifies the sender against the account email, and searches the CRM, finding the contact, three open opportunities, support cases, and a marketing subscription. The finance team confirms invoices linked to this customer must be kept under the company’s record-keeping obligations. So the coordinator removes the marketing profile, anonymizes non-essential notes, suppresses the email address to prevent future outreach, and retains the invoice records with restricted access. The reply explains what was deleted, what was retained, and why. The whole process is documented in the register.
Common Pitfalls
Teams often miss data in connected systems, leaving the person deleted from the CRM but still in the email platform. Another frequent mistake is deleting a record without suppression, after which a list import quietly recreates it. Some organizations also let requests circulate among busy sales staff with no owner. Finally, avoid promising deletion from backups on a timeline you cannot meet; explain your actual backup rotation honestly, and check what your legal advisers recommend.
Frequently Asked Questions
Do we have to delete everything when someone asks? Not always. Rights are often subject to exceptions, such as legal retention duties or ongoing contractual needs. The right answer depends on jurisdiction and circumstance, so confirm with qualified legal advice.
How long do we have to respond? Deadlines are set by the applicable law and sometimes can be extended in defined situations. Check with your privacy adviser and build the deadline into your register at intake.
What if the request covers data in a tool we no longer use? You still need to consider where the data resides. Maintain a record of systems that have held personal data, and confirm whether former vendors still retain it.
Can we charge for handling a request? Whether fees are allowed varies by jurisdiction and request type. Treat it as a legal question rather than a CRM question.
Who should own the process? A named privacy or compliance lead, supported by a CRM administrator who can search and act on records, and by legal advisers for edge cases.
Next Step
Run a practice request on a test contact this week: log it, verify it, locate every copy, and time how long it takes. The gaps you uncover are your improvement list. Consult qualified privacy professionals for the rules that apply to you.
By CRMCyberSec Editorial · Updated November 4, 2026
- data subject requests
- CRM data privacy
- right to erasure
- personal data