CRM software: recording consent and withdrawals

What to take away

What UK GDPR and the ICO expect from a CRM consent record

UK GDPR governs most personal data processing in the United Kingdom. The Data Protection Act 2018 sits alongside it, with provisions about the Information Commissioner and a separate regime for law-enforcement processing.

If you run a small business, your CRM is usually the system of record for names, email addresses, phone numbers, purchase history and marketing preferences. That makes it the centre of any data protection question.

The ICO's UK GDPR guide covers the principles, the rights and the obligations, and it is the reference point for how a CRM should be set up.

The ICO does not prescribe a particular CRM product or a particular field layout. It looks at outcomes: can you show what you collected, why, when, and on what basis? Can you show that the person agreed, or that you had another lawful basis? Can you show what happened when they asked you to stop?

A consent record in a CRM is not just a tick box. It is the evidence that ties a contact to a purpose. For a newsletter, the purpose is email marketing. For a loyalty scheme, it might be profiling and offers. Each purpose needs its own record, because consent is specific.

Record the source of the consent too. Was it a website form, a paper sign up at a trade show in Birmingham, or a phone call? The source matters when someone challenges whether they ever agreed, and it matters when you audit your own list.

Timestamps are part of the record. You need the date and time of consent, and the date and time of any withdrawal. A CRM that overwrites the old value with the new one destroys the history you may need later.

Finally, the ICO expects you to keep consent records for as long as you rely on the consent. If you stop marketing to someone, you may still need to keep a suppression record so you do not contact them again by mistake. That is a legitimate use of their data, and it should be explained.

Lawful basis choices for CRM contact data, in plain terms

There are six lawful bases under UK GDPR. Most small businesses use three of them in a CRM: consent, legitimate interests and contract. The others are legal obligation, vital interests and public task, which rarely apply to routine marketing lists.

PECR generally requires prior consent for email and SMS marketing to individual subscribers, subject to the limited soft opt-in exception. UK GDPR also requires a lawful basis for processing the personal data. Where consent is the basis, it has to be given freely, be clear, be specific and leave no doubt. A pre-ticked box is not consent. A condition of service that forces consent is not freely given.

Legitimate interests can work for some business to business marketing and for existing customer relationships, but it needs a balancing test. You have to weigh your interest against the person's rights and expectations, and record that you did the test.

Contract is often misunderstood. It covers data you need to deliver something the person asked for, such as a delivery address for an order. It does not cover adding that person to a newsletter. That is a separate purpose and needs its own basis.

Special category data, such as health information or trade union membership, needs more than a lawful basis. It needs a condition under Article 9. Most CRMs should not be collecting this at all unless there is a clear reason.

Marketing to individuals also brings in the Privacy and Electronic Communications Regulations, usually called PECR. PECR sits on top of UK GDPR and governs electronic marketing. When you choose a CRM, check how it handles PECR, accessibility, migration and exit, because those are the points that bite later.

For a fuller treatment of matching purposes to minimum fields, see our note on data protection designed around real purposes and minimum fields.

A simple rule: if you cannot explain the lawful basis for a contact in one sentence, the record is not ready. The ICO's guidance on the principles behind this is set out in its data protection principles resources.

Configuring consent capture, audit trails and withdrawal in CRM software

Configuration is where policy becomes reality. A CRM can either make compliance easy or make it impossible, depending on how the fields, forms and workflows are built.

Start with the capture points. Every form that feeds the CRM should record the exact wording the person saw, the date and time, and the source. If the wording changes later, the old record should keep the old wording.

Build separate consent fields for separate purposes. One field called marketing consent is too blunt. Use one for email, one for SMS, one for phone, one for profiling, and one for sharing with partners if you do that.

Add a withdrawal path that is as easy as the sign up. The ICO is clear that withdrawing consent should not be harder than giving it. A link in every email, plus a way to record the withdrawal in the CRM, is the minimum.

Use an audit trail that records who changed what and when. This is not just for regulators. It protects you when a member of staff edits a record and a customer later disputes it.

Here is a worked example for a small firm in Leeds selling subscriptions.

Use this checklist before you consider the configuration finished.

One common failure is importing a purchased list and marking everyone as consented. That is not consent, and it is one of the fastest ways to attract a complaint.

Another failure is deleting a contact entirely when they object. You often need to keep a minimal suppression record, and deletion can destroy the evidence that you honoured the objection. Our article on a CRM disclosure policy with an owner for every disclosure type covers how to assign responsibility for these decisions.

Keeping consent evidence in CRM records

Storage limitation is one of the seven principles in UK GDPR. It says you must not keep personal data for longer than you need it. The ICO's guidance on this principle is part of its data protection principles resources, and it is the basis for any retention schedule you build.

The practical tool is a data retention schedule. This is a table that names each type of record, the retention period, and the reason. In a CRM, the schedule should map to record types, not to vague categories like customer data.

A schedule that lives in a spreadsheet and never touches the CRM is close to useless. Put the retention period into the CRM as a field or a rule, and let the system flag records that are due for review or deletion.

Tax and accounting rules matter here. HMRC expects business records to be kept for a set period, and those records may sit in the same CRM or a linked finance system. Do not delete something the law requires you to keep, and do not keep marketing data just because it sits in the same table.

Automate where you can. A CRM that can run a scheduled job to flag stale records is far better than a manual review that never happens. If your CRM cannot do this, use a saved view and a recurring calendar reminder.

Document the schedule. If the ICO asks why you kept a record for a certain period, you should be able to point to a written reason. The reason can be commercial, legal or operational, but it should exist.

Review the schedule at least once a year, and whenever you change how you use the CRM. A new marketing channel or a new integration can create a new record type that nobody has assigned a retention period to.

Subject access requests and individual rights a CRM must serve

UK GDPR gives individuals a set of rights, and the CRM has to be able to serve them. The individual rights guidance covers access, erasure, rectification, restriction, portability and objection, and it is the reference for what your system must support.

A subject access request, usually shortened to SAR, is a request from a person to see the personal data you hold about them. You must respond without undue delay and within one month in most cases. You can extend by up to two further months for complex requests, but you should not treat that as routine.

A CRM must be able to search by person, not just by company or order. If your records are spread across a CRM, an email inbox and a spreadsheet, the SAR becomes a manual hunt. That is where mistakes and missed deadlines happen.

You can usually refuse or charge only in limited circumstances. For example, you can refuse a request that is manifestly unfounded or excessive, but you need to justify that. You cannot charge a fee just because the request is inconvenient.

Erasure, sometimes called the right to be forgotten, is not absolute. You may need to keep some records for legal reasons, such as tax, or to defend legal claims. The CRM should distinguish between data you can delete and data you must retain.

Rectification means correcting inaccurate data. If a customer says their address is wrong, the CRM should allow the correction and keep a note that it was made. Restriction means marking data so it is stored but not used, which is useful while a dispute is being resolved.

Portability applies where processing is based on consent or contract and is carried out by automated means. In practice, this means you should be able to export a person's data in a structured, commonly used format.

Objection is the right that most often affects marketing. If someone objects to direct marketing, you must stop. There is no balancing test for that specific case, which is why suppression records matter so much.

Test your SAR process before you need it. Pick a real record, run the search, and time how long it takes to assemble the response. If it takes days, fix the configuration now.

Controllers, processors and CRM vendor contracts

Your business is almost certainly the controller for the personal data in your CRM. The CRM vendor is almost certainly a processor, acting on your instructions. That distinction decides who is responsible for what.

As controller, you decide why and how the data is used. You answer to the individual and to the ICO. The processor must follow your documented instructions and must not use the data for its own purposes.

UK GDPR requires a written contract between controller and processor. It must cover the subject matter, duration, nature and purpose of processing, the type of personal data, and the obligations of both sides.

The contract must also cover security, confidentiality, sub-processors, assistance with individual rights, breach notification, and what happens to the data at the end. If your vendor will not sign a data processing agreement, that is a serious warning sign.

Check where the data is stored and who can access it. Some vendors use sub-processors in other countries, and international transfers need a lawful mechanism. This is not a reason to avoid cloud CRM, but it is a reason to read the paperwork.

Think about exit before you sign. Can you export all personal data in a usable format? How long does the vendor keep backups after termination? What happens to the data if the vendor is sold?

A CRM selection process that ignores these questions tends to produce a difficult exit later. Our gated CRM selection checklist covering PECR, accessibility, migration and exit is built for that stage.

Security is part of the controller's duty too. Access control, strong authentication and role based permissions in the CRM reduce the risk of a breach that you would have to report.

Breach reporting and accountability evidence

Breach reporting is the other core duty. If a personal data breach is likely to result in a risk to people's rights and freedoms, you must report it to the ICO within 72 hours of becoming aware of it. If the risk is high, you must also tell the individuals affected.

A CRM can help or hinder here. If your audit logs show what was accessed and when, you can assess the breach quickly. If you have no logs, you may have to assume the worst and report more broadly.

Accountability is the principle that ties all of this together. You must be able to show how you comply, not just say that you do. In practice, that means records of processing, a retention schedule, consent evidence, training notes and a breach log.

Keep these records in a form you can produce quickly. A folder of documents that nobody can find is not accountability. A short, current set of records that matches your CRM configuration is a practical way to show how you comply.

Review your breach process and your records at least once a year. If you use an outsourced IT provider, make sure the breach process says who calls whom, and within what time.

Reviewing CRM settings alongside the Data (Use and Access) Act 2025

The Data (Use and Access) Act 2025 is the most significant change to UK data protection since the Data Protection Act 2018. It amends UK GDPR and PECR rather than replacing them, so the core structure remains.

The ICO has published an explainer on the Data (Use and Access) Act 2025, and it should be the first place you check the detail before you change your configuration.

The Act amends UK GDPR and PECR, but the practical effect for a CRM depends on which provisions apply and current guidance. Before changing forms or workflows, check the current requirements rather than assuming a particular setting must change.

The core CRM controls described here still matter: record a lawful basis, capture relevant consent evidence and apply a documented retention schedule. Do not treat legislative change as a reason to stop keeping those records.

If you built your consent model on the pre 2025 rules, do not assume it is wrong. Do check it against the current ICO guidance, and update the wording and the CRM fields where something has changed.

The Act also touches on how the ICO operates and how it handles complaints. That matters to small businesses because it affects how quickly and how formally an issue may escalate.

A sensible plan for 2026 is to review your consent wording, your retention schedule and your vendor contracts once, in that order. Then update the CRM configuration to match, and record what you changed and why.

Common questions