How to Handle Customer Data Subject Access Requests Using a CRM

A subject access request is a request for personal information, not merely an instruction to export a customer contact from CRM. A small UK trading company may hold the same person's information in account records, quotations, order correspondence, support tickets, email attachments and notes created by colleagues. Handling a request properly means recognising it, calculating the applicable deadline, checking the requester's identity where necessary, carrying out a reasonable and proportionate search and reviewing the information before secure disclosure. The CRM is a useful case-management tool for that work; it is not the legal decision maker.

The Information Commissioner's Office updated its introductory subject access guidance on 16 July 2026 to reflect changes associated with the Data (Use and Access) Act 2025. An old template that unconditionally starts a one-month countdown without considering identification, authorised representatives or legitimate clarification may be inaccurate. This guide describes the controls a small business should put around its CRM, while leaving the interpretation of difficult exemptions, competing rights and any disputes to a responsible person using current official guidance.

Recognise the request and preserve its original wording

A person need not quote the UK GDPR, use the phrase subject access request or complete the company's preferred web form. An ordinary email asking what information the business holds about them may be enough. The ICO explains that requests may be verbal or written, including via social media, and can be made by an appropriately authorised representative. Employees receiving calls or customer-service messages need a simple route to refer a possible request immediately.

Record the actual wording, date received, contact route and responsible handler in a restricted CRM task or case. Keep a link to the source communication rather than unnecessarily copying all its personal details into multiple places. Do not dismiss a request simply because it arrives while a customer has an unresolved complaint or because it was addressed to a salesperson instead of the privacy contact.

When the intended scope is uncertain, ask a focused question rather than silently narrowing the request. Staff should be trained to recognise rights language and escalate it; they are not expected to decide alone whether unusual correspondence is a legally valid request.

Calculate the deadline from the relevant facts

The ICO says organisations must normally respond without undue delay and within one month of receipt, subject to particular rules. Its July 2026 guide explains when the relevant clock begins following necessary confirmation of identity, authority of a representative or an applicable fee, and that a reasonably required request for clarification can pause the clock. The time resumes after the clarification is received. A complex request, or several requests from the same person, may justify an extension of up to a further two months; the person must be informed and given reasons within the applicable initial period.

A CRM reminder should therefore store the original request time, any identity or authority checks, actual clarification sent and received, approved extension decision and calculated response date. It should not apply an automatic pause merely because an employee moved the case to a generic waiting state. Equally, do not assume that a request is complex simply because it spans several customer systems.

Review these events promptly. A team that delays requesting necessary proof of identity may create avoidable delay. A person responsible for the request should check the case against the current ICO guidance rather than treating a software timer as legal advice.

Verify identity proportionately and handle representatives

Sending personal information to the wrong person is a serious failure. The ICO advises organisations to be satisfied about the requester's identity and, where someone acts on another's behalf, their authority. However, identification steps must be reasonable and proportionate. A customer who has already been reliably identified through an appropriate authenticated channel should not automatically be forced to supply excessive identity documents.

Decide what evidence is necessary for the circumstances. A request for an ordinary account record may present different risks from one concerning sensitive support material. If extra evidence is necessary, request it securely and explain why. Avoid putting copies of identity documents into an unrestricted CRM attachment area. Limit access, record the verification outcome and manage supporting material in line with the organisation's retention policy.

When a representative makes the request, retain sufficient evidence of their authority and clarify the permitted disclosure route. Do not assume that knowing the customer's order number authorises access to all personal information relating to the account.

Build a search plan that reaches beyond the contact screen

Identify where the relevant personal information may actually reside. For a trading firm this can include CRM contacts, company associations, support conversations, customer-service mailbox searches, quotation history, delivery instructions and permitted records in connected tools. Distinguish information about the individual from information merely about a corporate customer. The ICO's detailed search guidance requires reasonable and proportionate efforts, not an unlimited hunt through every imaginable system.

Use recorded identifiers such as verified contact addresses, account references, previous names where relevant and linked ticket identifiers. Document which systems were searched, the methods used, the dates covered and any material limitations. An old email address may reveal correspondence that searching only the current contact address would miss.

A CRM contact CSV is not proof the search is complete, because activity notes or attachments can hold additional personal information. Conversely, exporting an entire company account indiscriminately can reveal other people's information. An authorised reviewer must determine the appropriate search and treatment.

Review third-party information and relevant restrictions

Customer service notes may mention employees, family members, other customers or suppliers. A requester does not automatically gain an unrestricted copy of everybody else's information because it appears in the same CRM case. Nor is every document containing a person's name necessarily wholly disclosable. The correct review can involve third-party rights, legal privilege, relevant restrictions or specific exemptions.

Keep collection separate from disclosure decisions. The person gathering records may identify potential concerns and label them for a qualified reviewer, but should not rely on a generic redaction automation as a final legal judgement. Where the business is uncertain, use the ICO's current right-of-access guidance and suitable professional advice.

Preserve the reasoning for a material redaction, withheld item or extension. Do not erase an inconvenient note or retrospectively rewrite the source because a request has arrived. Good recordkeeping should make the process explainable without adding speculative commentary about the requester.

Prepare an accessible and secure response package

The ICO states that a response normally includes a copy of the relevant personal information and required supplementary information. Think about the format and whether the requester can use it. For an electronically made request, a commonly used electronic format will generally be appropriate unless the individual requests otherwise. A spreadsheet full of internal field codes may require explanation even when the values are technically readable.

Use a secure delivery route suitable for the material and the recipient. Check addresses, permissions on shared links and the contents of attachments before sending. An automatically generated export may combine records from unrelated people or omit necessary context. Perform a final review of the actual package, not just its filename and reported record count.

Record when the response was made and through which authorised channel, without scattering duplicate copies through unnecessary systems. Where a request is partly refused or an exception relied upon, follow applicable notification requirements rather than sending a generic completed template.

Keep a defensible case log without over-collecting

A concise case log can record receipt, identity and authority review, search plan, systems checked, decision makers, final package review, correspondence and response date. It provides accountability and supports handovers if the responsible colleague is away. Separate access rights for the privacy case from routine sales users; a customer’s request may reveal sensitive material beyond ordinary relationship management.

Test access permissions with a representative scenario. An employee receiving the initial message should be able to route it safely, whilst only approved reviewers can open documents containing confidential third-party information. Audit who accessed or changed the case where the CRM provides suitable facilities.

Delete or retain temporary working files under the organisation's legitimate retention schedule. A right-of-access process should not create a larger uncontrolled collection of personal data simply to demonstrate compliance.

Use the completed request to improve the underlying CRM

After closing the case, review which searches were difficult. Duplicate contacts, inconsistent notes, missing relationship identifiers and broken links to support platforms are operational problems that affect ordinary service as well as subject access. Assign corrections to the proper system owners, preserving necessary history and avoiding unjustified mass deletion.

Rehearse one case involving a former email address, a linked support ticket and a third-party mention. Ask someone outside the configuration team to reconstruct the request date, search scope, reviewer decisions and response evidence. If the answer depends on one person's memory, make the workflow clearer.

Do not measure success solely by the number of exports produced. A good response is timely under the actual rules, proportionate in its search, careful about other people's rights, accessible to the requester and appropriately secured. For a small business, that standard is attainable through clear ownership, reliable source records and current ICO guidance rather than a large compliance application.