UK GDPR CRM requirements for small businesses

For a small business, UK GDPR CRM requirements are practical. Your CRM should hold only the data you need, show why you have it, restrict who can see it, and let you correct, export, retain, and delete records without awkward workarounds. In day-to-day use, that usually means separating prospects, customers, and marketing preferences, keeping a clear record of lawful basis, and making access requests, consent changes, and deletions manageable. The law does not demand one perfect CRM setup, but it does expect your system and processes to make compliance workable.

What UK GDPR means for a CRM in plain English

A CRM is not just a contact list under UK GDPR. It helps shape what personal data you collect, why you collect it, who can use it, how long you keep it, and how you respond when someone asks for their data.

In practice, your CRM should support data minimisation, purpose limits, security, retention, and data subject rights. It should also make it easier to record the lawful basis for each main use of the data, such as contract, legal obligation, legitimate interests, or consent, depending on the relationship and the activity.

For most small businesses, the CRM is used by a data controller, while the software vendor may act as a data processor for hosted systems. That distinction matters because you remain responsible for handling decisions, even if the vendor runs the platform. The ICO and the DPA 2018 are the places to check current guidance when your setup, vendor terms, or data flows change.

Criteria: how to judge a CRM for UK GDPR

Choose a CRM based on what it lets you control in daily use, not on marketing claims.

• Can you show why each contact exists and what the record is for?
• Can you keep marketing preferences separate from service, sales, and account records?
• Can you limit access by role, team, field, or record type?
• Can you see who changed, merged, exported, or deleted a record, and when?
• Can you search, correct, export, archive, and delete records without hand-built spreadsheets?
• Can you apply retention rules to records, attachments, tasks, and synced email?
• Can the vendor explain hosting, backups, subprocessors, and export options in plain terms?

If the answer is no to several of those, the problem is usually the setup or the contract as much as the software.

Entries: what the CRM needs to support

Lawful basis by contact type

A CRM should let you record the reason you are holding and using each record. For prospects, that is often legitimate interests for limited sales follow-up, or consent where you are sending marketing that needs it. For customers, contract is often the basis for service and order handling, while legal obligation may apply to records you must keep for tax or accounting reasons. For marketing, the basis is often consent for email or text where the rules require opt-in, or legitimate interests where that is allowed and the person has a real right to object. The exact basis depends on the activity, so check the current ICO guidance before you standardise it across the business.

Prospect records

For prospects, the CRM should store only enough information to manage the relationship and decide whether to follow up. That usually means name, business contact details, company name, source, notes about the inquiry, and any stated preferences. It should not force you to keep large amounts of background detail just because the form has room for it.

Customer records

For customers, the CRM usually needs to hold order history, service notes, account contacts, billing or delivery details where needed, and records of complaints or support issues. Keep a clean distinction between data needed to fulfil the contract and data used for optional marketing or profiling.

What data to avoid collecting unless there is a clear need

Only collect data that has a clear business, legal, or service purpose. Common fields to avoid unless you really need them are date of birth, home address, personal phone numbers, copies of ID documents, and free-text notes that wander into gossip, speculation, or unrelated personal detail. Special category data such as health information, union membership, or religion should stay out of the CRM unless you have a specific reason, a lawful basis for the main processing, and the extra safeguards that go with it. If you do need unusual or sensitive data, record why it is needed, who approved it, and how long you will keep it.

Consent and preferences

The CRM should separate consent from ordinary contact details. A customer can be a valid service contact without being a marketing contact, and a marketing opt-in should not be treated as permission for everything else. Preference fields should show what channel was agreed to, what message type it covers, when it was captured, and how the person can change it later. If consent is your lawful basis for a specific activity, you should be able to show when it was given and how it was withdrawn.

Records and logs that should exist in or alongside the CRM

You need enough records to show what you did and why. That usually means a lawful-basis or purpose record, marketing preferences, consent history where relevant, source of the data, retention category, communication history, and change or deletion history. You may also need a separate record of processing activities, vendor contracts, privacy notices, and staff instructions outside the CRM itself. The CRM does not have to hold every compliance document, but the business should be able to connect the record to the rule that governs it.

Access control and audit trails

Different staff need different access. Sales may need lead details, service staff may need order history, and only a few people should see full notes, attachments, merge tools, or export functions. Check that permissions can be limited by role, team, record type, or field, not just by login. An audit trail should show who changed what and when, including edits, merges, exports, and deletions. That helps with internal checks, disputes, and subject access requests.

Access rights, correction, and portability

The CRM should let you find a person quickly, see the data held on them, correct errors, and export a usable copy without hunting through hidden fields. Subject access requests are usually easier if notes, attachments, synced email, and custom fields can all be found in one place. Portability is narrower than a full subject access request, but the system should still make export practical when the request applies.

Retention and deletion

A good CRM lets you set retention rules, archive records where needed, and remove records when they are no longer needed. Old leads should not sit forever just because nobody has made a decision about them. Your process should say when a record is archived, anonymised, restricted, or deleted, and who checks that the rule is followed. If deletion is manual only, stale records tend to pile up.

Vendor hosting, access control, backups, and exports

Ask the vendor who can access your data, where it is hosted, what subcontractors they use, how backups are handled, how long deleted data stays in backups, and how exports work if you leave. Check whether admin access is logged, whether customer data is encrypted in transit and at rest, and whether you can remove users quickly when someone leaves. If the vendor cannot explain their processor terms, breach notification process, or export format clearly, that is a warning sign. Because products and terms change, check the current vendor documentation rather than relying on old setup notes.

Common setup mistakes that create UK GDPR problems

Keeping old leads forever is a common one. So is using one yes/no field for both service contact and marketing consent. Another frequent problem is giving too many people full access, including export and delete rights, because role design was never tightened after the CRM went live. Many businesses also lose control of data outside the CRM, in spreadsheets, shared inboxes, or downloaded lists that have no audit trail or deletion rule. Free-text notes are another trap: if the form structure is poor, staff tend to store too much, including opinions and sensitive detail that should never have been entered. The final recurring issue is having no clear rule for deletion or archiving, so the CRM becomes permanent storage by default.

How to choose or fix a CRM setup

Use this as a practical check before you buy a CRM or tidy up an existing one.

1. Confirm what the CRM is for. Write down whether it is for sales follow-up, customer service, account management, marketing, or all four. The lawful basis and the data you need may differ for each use.

2. Separate contact types. Make sure prospects, customers, suppliers, and marketing contacts are not all forced into the same field logic.

3. Build the minimum record set. Remove fields you do not need, and decide which fields are required, optional, or blocked for sensitive data.

4. Set permissions before rollout. Decide who can view, edit, merge, export, and delete records. Review those rights when roles change.

5. Put consent and preference tracking in place. Record what was agreed, when, and for which channel. Do not assume a general relationship covers marketing.

6. Define retention and deletion rules. Set a schedule for active customers, old prospects, and closed records, and apply the same rule to attachments and synced email where possible.

7. Test subject access handling. Check whether you can find, export, correct, and delete a record without manual workarounds.

8. Review the vendor terms. Confirm hosting, access control, backups, subcontractors, breach notice terms, and export options against the current contract and product documentation.

If a CRM passes those checks, you still need a privacy notice, internal rules, and staff training. The software helps, but the business has to make the legal decisions and keep them consistent.