Handling DSARs for data you bought from a broker

What is a DSAR and how must it be lodged?

A Data Subject Access Request is a formal request by an individual exercising their right of access under Article 15 of the UK General Data Protection Regulation. The individual is asking you to confirm whether you process personal data about them and, if so, to provide a copy of that data along with specific supplementary information.

Under UK GDPR, a DSAR can be submitted in any format: email, letter, social media message, or even verbally. There is no requirement for the requester to use a formal form, quote Article 15, or use the words "data subject access request". If someone writes "Can you tell me what information you hold about me?", that counts. You cannot make a valid response conditional on the request being submitted via a particular channel.

Organisations that receive high volumes of requests often publish a DSAR form on their website to streamline the process, but this is an administrative convenience, not a legal requirement. The obligation to respond attaches the moment you receive a request by any means.

The one-month deadline: when does it start and what extends it?

The one-month clock begins on the day you receive the request. If the request arrives on 21 May, your deadline is 21 June (or the equivalent date in the following month, adjusted for weekends and bank holidays where the relevant date falls on a non-working day).

One exception applies to identity verification. If you have reasonable doubt about who is making the request, you may ask for verification before starting the clock. Be proportionate: asking a requester who submits their full name, company name, and the specific email address you hold for them to send you a passport copy is disproportionate. Asking a requester who provides only an email address to confirm their postal address (which you also hold) is reasonable.

A two-month extension is available where requests are complex or numerous. To rely on it, you must inform the requester within the first month that you need more time and explain why. Saying "your request is complex" without any specifics is unlikely to satisfy the Information Commissioner's Office (ICO) if challenged. Genuine complexity might include records held across several legacy systems, or a requester who also lodges an erasure request alongside the access request at the same time.

What must a DSAR response include for purchased data?

Article 15(1) sets out a specific list of what the response must cover. For a record purchased from a data broker, each item has a practical implication.

Article 15(1) requirement	What this means for purchased data
The personal data itself	Provide a copy of every field you hold: name, email address, telephone number, job title, company, postal address, and any profiling or segmentation tags you have applied.
The purposes of processing	State that the data is used for [e.g.] direct marketing to B2B decision-makers, or for postal marketing to consumer households.
The lawful basis	For B2B purchased data this is typically legitimate interests under Article 6(1)(f). For B2C purchased data it is consent under Article 6(1)(a). Name the basis and give a brief rationale.
Recipients or categories of recipients	Name any marketing agency, email service provider, CRM platform, or other processor that also receives the data on your behalf.
Retention period (or criteria)	State the specific period (e.g. "24 months from date of purchase") or the criteria you use to determine it.
Source of the data	Name the data broker. You cannot withhold this on commercial-confidentiality grounds. Where possible, also describe the category of source (e.g. "a B2B contact data provider compiled from public corporate sources").
Rights of the data subject	Remind them of their rights to rectification (Article 16), erasure (Article 17), restriction (Article 18), and objection (Article 21). For legitimate-interests processing, the right to object is particularly important.
Right to complain	Tell them they can lodge a complaint with the ICO at ico.org.uk.

The source disclosure requirement is the item buyers of third-party data most often get wrong. Contracts with data suppliers sometimes include confidentiality clauses, but those clauses cannot override a data subject's statutory rights. If your supplier contract prevents you from naming them in a DSAR response, that clause is unenforceable as against the data subject, and you should take legal advice on renegotiating the contract. See our article on ICO guidance on marketing data for how the regulator approaches supplier accountability more broadly.

How to handle identity verification when you only have an email address

This situation comes up constantly in practice. A DSAR arrives from an email address. You hold that email address in a purchased list. Can you verify the requester without asking for documents?

Yes, in most cases. The ICO's guidance on verifying identity for DSARs says you should use the minimum information necessary and take into account the risk level of the data you hold. For a standard marketing list containing a name, job title, business email, and telephone number, asking a requester to confirm their job title and company name (fields you already hold) is usually sufficient. You are checking that they are who they claim to be, not performing a KYC check.

Where the data is more sensitive (for example, a consumer file containing financial profiling, health-related interests, or family composition), slightly more verification is reasonable. Even then, asking for a passport is disproportionate unless there is specific evidence of attempted identity fraud.

A practical approach for lower-risk marketing data: send a short reply confirming receipt, state that you are processing the request, and ask them to confirm one piece of information that only the genuine data subject would know, such as the postal address you hold on file. If they confirm it correctly, you have reasonable grounds to proceed.

Step-by-step procedure for responding to a DSAR on purchased data

The following sequence works for most marketing-data scenarios. Adapt it for your team size and systems.

1. Log the request. Record the date received, the requester's name and contact method, and assign a reference number. Your one-month deadline runs from this date (or from the date identity is confirmed, if verification was needed).
2. Assess whether identity verification is needed. If the request is unambiguous and the data risk is low, proceed. If there is genuine uncertainty, send a brief verification question within a few days. Do not ask for more than is proportionate.
3. Search all relevant systems. Check your CRM, marketing automation platform, email tool, suppression lists, raw data files, and any backups within retention scope. Do not limit the search to live systems if archived records are still within your stated retention period.
4. Identify the data source. Note which data supplier provided the record. Retrieve the relevant data schedule or licence agreement so you can accurately describe the source in your response.
5. Compile the response. Assemble the personal data found, the lawful basis, the retention period, the source name, and the list of any processors or recipients. Draft the response letter in plain English, not legal boilerplate.
6. Review for third-party data. If the response would reveal personal data about another individual (for example, a note in your CRM that names a colleague of the requester), redact that third-party data before sending.
7. Send securely within the deadline. Email responses should go to a confirmed address. Postal responses should go to the address the requester provided. Do not send to an address you hold on file if the requester used a different address to contact you.
8. Update your suppression list if requested. A DSAR often accompanies a request to stop marketing. If the individual also objects to processing, add them to your suppression file immediately regardless of the DSAR timeline.
9. Document and retain the record. Keep a copy of the request, your search notes, and the response. Three years is a reasonable minimum; longer if litigation is possible.

Manifestly unfounded and excessive requests: when can you refuse?

Article 12(5) allows you to refuse a DSAR, or charge a reasonable fee, if the request is manifestly unfounded or excessive. The threshold is deliberately high, and the ICO takes a sceptical view of refusals.

A request is manifestly unfounded when the individual has no genuine intention of exercising their rights and is clearly making the request to harass, cause disruption, or extract a benefit unconnected to their rights. A professional DSAR harvester sending hundreds of identical requests to data brokers with the sole aim of obtaining databases for resale might qualify. A marketing prospect who simply wants to know what you hold about them does not.

Excessive means repetitive requests that place an unreasonable burden on your organisation without providing a corresponding benefit to the data subject. Receiving two requests from the same person in six months is unlikely to be excessive. Receiving the same detailed request weekly from the same IP address, using slightly different names to probe your data, might be.

If you decide to refuse, you must tell the requester within one month, explain why, and tell them they can complain to the ICO or seek a court remedy. Document your reasoning thoroughly. Note that disliking the purpose of the request (for example, a journalist investigating your data sourcing practices) is not grounds for refusal.

Charging a fee: when is it permitted?

For the standard first copy of personal data, the response must be free. A fee is only permitted for additional copies of the same data, or where the request is demonstrably excessive. The fee must be based on the actual administrative cost, not a deterrent figure. Charging £50 for a routine response would be very difficult to justify to the ICO.

What if you hold no data on the requester?

This is a legitimate and complete response. A data subject has the right to ask; you are obliged to tell them whether you hold data or not. If your search returns nothing, send a 'no data found' response that:

• Confirms you have conducted a thorough search across all relevant systems.
• States that no personal data relating to the requester was found.
• Notes the date of the search (in case the data is added later and a further request arrives).
• Reminds them of their right to complain to the ICO if they believe you have mishandled the request.

Keep a record of the search itself. If the ICO receives a complaint and asks how you conducted the search, "we checked our CRM and marketing database by name and email address, returning zero results" is a defensible answer. "We had a look around" is not.

If you purchased a list that included the individual but you have since deleted that record (for example, because your retention period expired), state that clearly. Article 15 applies to data you currently hold; you are not required to restore deleted records. However, confirming that you previously held the data and deleted it in line with your retention policy is good practice and reduces the risk of a complaint.

Privacy notices and transparency obligations before a DSAR arrives

The best DSAR response is one that surprises nobody. Under Articles 13 and 14 of UK GDPR, when you acquire data from a third party you must provide a privacy notice to the data subject at the point of first contact (or within one month of acquiring the data, whichever comes first). That notice must include the source of the data.

This means your first marketing touchpoint to a purchased list should include a brief transparency statement: something along the lines of "Your contact details were provided to us by [Supplier Name]. Our privacy policy explains how we use this data and your rights." This is both a legal obligation and practical risk management. A data subject who received proper notification is far less likely to escalate a DSAR to a formal ICO complaint. For practical guidance on structuring your lawful basis for B2B prospects, see our article on legitimate interests for B2B data in the UK.