GDPR and your CRM: the operational minimum every SME should have in place

If your company runs a CRM, it holds a file of personal data. Nothing more is needed for the GDPR to apply: names, email addresses, phone numbers, meeting notes. The decision this article helps you make is what operational minimum you should have in place for that data — why you hold it, who can access it, how long you keep it — so the CRM doesn't become a risk nobody is watching. One clarification before anything else, and it deserves to be taken seriously: this is operational data-management judgement, not legal advice. Your company's specific obligations depend on its activity and its processing, and reviewing that is a job for a legal professional. What we can offer is the groundwork that makes any legal review shorter, cheaper and less eventful.

The CRM is where the problem accumulates

A CRM doesn't fill up overnight: it fills up by accumulation. Imports from years back, trade-fair contacts, lists someone uploaded once whose origin nobody remembers, duplicates nobody ever merged. And the data doesn't stay put: it gets exported to spreadsheets, synced with the marketing email tool, copied to a local file "to work more comfortably".

That is why the CRM is the first place to look, but not the whole perimeter. It's the centre of gravity: if order doesn't exist there, it doesn't exist in any of the copies either. Everything that follows starts from that idea.

Why you hold each record

The operational question is simple: if any contact in your CRM asked you "why do you have my data?", could you answer without making something up?

You don't need to memorise the regulation's legal bases to see the pattern. Data with a real relationship behind it — customers under contract, suppliers, people who asked you for something specific — explains itself. Data that arrived "from somewhere" doesn't, and that's where it pays to stop: an inherited list of unknown origin isn't a commercial asset, it's a liability. Using it for mass campaigns is exactly the kind of processing that holds up worst when someone starts asking questions.

The minimum exercise isn't a report: it's being able to separate, inside the CRM, the contacts with a relationship that justifies holding them from the ones without. That separation also improves the commercial work itself — nobody sells well against a database of unknown provenance.

Who can access it, and what they can do

In many small and mid-sized companies the honest answer is "everyone, to everything". It's convenient, and it's a risk, through three specific doors:

• Shared accounts. If several people log in as the same user, nobody is accountable for anything: there is no way to know who exported, who deleted, who changed a record.
• Exports. Every export to a spreadsheet is a copy of the file that leaves the CRM's perimeter and stops being governed. The point isn't to ban exports — it's to know they exist and to stop them becoming each salesperson's parallel CRM.
• Access nobody revokes. Former employees, agencies whose project ended, the supplier who configured the system years ago. Access that never gets revoked is the most avoidable leak there is, and the most common.

The operational minimum: one user per person, permissions by role — not everyone needs to export the full database — and an access review whenever someone leaves, as routinely as their email account is closed.

How long you keep it

A CRM without a retention rule only ever grows. Contacts with no activity for years, companies that closed, people who changed jobs three times: it all stays, because deleting is tedious and "just in case".

The specific periods depend on the type of data and the obligations that apply — contractual and invoicing records have their own — and setting them is a good task for your legal adviser. What is operational, and yours, is something else: that a written rule exists, that it distinguishes what you're obliged to keep from what you keep out of inertia, and that someone actually applies it with a periodic purge. That isn't just compliance: a base full of dead contacts pollutes every report and every campaign that comes out of it.

The access-request test

One test sums up most of the above: if a contact asked tomorrow to see their data, or to have it deleted, could you locate every copy?

In the CRM, probably yes. In the email tool that syncs with it? In the exported spreadsheets? In that local file on a salesperson's laptop? Honouring the request is a legal obligation; being able to honour it is a data-order problem. If the honest answer is "I wouldn't know where everything is", the issue isn't legal yet: it's that you don't control where your data lives — and that would cost you just as much in a migration, a breach or a sale of the company.

What should never be written down

Free-text fields — notes, observations, visit comments — are where things end up that shouldn't sit in any file: health conditions, family situations, personal opinions about the customer. All of that is personal data, some of it in specially protected categories, and it travels in every export.

The internal rule fits in one sentence: never write anything about a contact you wouldn't be comfortable with that contact reading. It's easy to remember, it covers most of the risk, and it raises the quality of your sales notes as a side effect.

Five questions before you call your CRM sorted

1. Could you explain, for any contact, why you hold their data?
2. Who can view, edit and export the database — and is anyone on that list who shouldn't be?
3. Does a written retention rule exist, and does anyone apply it?
4. If a contact asked you to delete their data, could you find every copy?
5. What is written in your free-text fields?

Answering them doesn't replace a legal review; it makes one cheaper, because the professional doing it will find an ordered processing operation rather than a junk drawer. At Dateliers, that order in the data is part of how we look at any system — if you want the full picture, this is how we work.