How to answer a customer asking what personal data you hold

TL;DR — When a customer asks what data you hold about them, do three things in order: verify their identity, collect their data from the systems you actually use, and send a plain-English reply with the data categories, source, purpose, retention (how long you keep it), and next steps. The most common failure is replying before identity is checked or forgetting data in tools like email, billing, support, and backups. Reading time: ~5 min

Goal

By the end of this guide, you will have sent a complete, privacy-safe response to the customer that lists the personal data you hold about them, where it came from, why you use it, how long you keep it, and how they can ask for correction or deletion.

Prerequisites

• Access to the customer's original request email, ticket, or contact form message
• Access to the systems where you may store customer data, such as:
  • your email inbox or helpdesk
  • your CRM (customer record system)
  • your billing system
  • your app admin area or database export tool
  • your file storage or shared drive
• Your company's privacy policy or retention schedule, if you have one
• The customer's identifying details, ideally at least two of these:
  • full name
  • email address
  • account ID
  • invoice number
  • company name
• A reply channel to send the response securely, usually the same verified email address they used
• Optional: a colleague or manager who handles privacy requests, if your company requires approval before sending

Steps

Step 1: Confirm the request and pause any immediate reply

Open the customer's message and copy it into your internal case notes or ticket.

Exact action:

Create an internal note with this text:
"Privacy request received on YYYY-MM-DD. Request type: access request. Do not send customer data until identity is verified."

What you should see when this succeeds: the request is logged in your ticket or notes with today's date and the request type.

Step 2: Verify the customer's identity

Reply only with an identity check if you are not already certain the request came from the customer's usual verified address.

Copy and send this exact message:

Subject: We can help with your data request

Hi [Customer name],

We can help with your request to see what personal data we hold about you.

Before we send any account information, please reply with these two details:
- the email address used for your account
- one of these: your latest invoice number, account ID, or company name on the account

If you are writing from the email address already attached to your account, we will use that as part of the verification.

Thanks,
[Your name]

What you should see when this succeeds: you receive a reply that matches the account details you already hold.

Step 3: Search every system where customer data may exist

Use the same identifier in each system, starting with the email address. Search these locations one by one.

Exact menu paths to use, depending on your tools:

• Email/helpdesk: your provider's dashboard (for example, mailbox search or Helpdesk → Tickets → Search) → search the customer's email address
• CRM: Customers or Contacts → Search → paste the customer's email address
• Billing: Invoices or Customers → Search → paste the customer's email address or invoice number
• App admin: Users or Accounts → Search → paste the customer's email address or account ID
• Shared drive/file storage: Search bar → paste the customer's full name and email address

If you have database access and your team allows exports, use a read-only query like this:

SELECT id, email, full_name, created_at
FROM users
WHERE email = 'customer@example.com';

What you should see when this succeeds: a list of matching records from each system, or a clear "no results" in systems where nothing is stored.

Step 4: Record exactly what data you found

Create a simple table in your notes. Do not skip systems with no results; note them too.

Use this format:

What you should see when this succeeds: one completed table covering every system you checked.

Step 5: Remove anything you should not send

Do a quick review before replying. Remove other people's data, internal notes that are legally privileged, secrets such as API keys, and security-only details that would create risk if disclosed.

Exact action:

Review each record and delete from your response draft any line containing:
- another customer's name or email
- internal-only comments unrelated to the customer's data
- passwords, password hashes, API keys, access tokens, secret URLs

What you should see when this succeeds: your draft contains only the requesting customer's personal data and plain-English explanations.

⚠️ Do not send raw database dumps, full ticket exports, or screenshots that include other customers, staff comments, or secrets. Those mistakes create a new privacy incident.

Step 6: Draft the response in plain English

Send a response that covers the data categories, source, purpose, retention, and next steps. Use this template and replace the bracketed text.

Copy and send this exact message:

Subject: Your request for the personal data we hold

Hi [Customer name],

Thanks for your request. We have checked the systems we use to provide our services and support.

We currently hold the following personal data about you:

1. Account and contact details
- Data: [name, email address, phone number]
- Source: [provided by you when you signed up / provided by your employer]
- Purpose: [account setup, service delivery, communication]
- Retention: [while your account is active, then 90 days]

2. Support records
- Data: [support emails, tickets, attachments]
- Source: [provided by you when contacting support]
- Purpose: [troubleshooting and customer support]
- Retention: [24 months after the last support interaction]

3. Billing records
- Data: [billing name, billing address, invoices, payment status]
- Source: [provided by you or your finance team]
- Purpose: [billing, accounting, fraud prevention]
- Retention: [7 years where required by law]

4. Service usage or security records
- Data: [login times, IP addresses, audit logs]
- Source: [generated when you use the service]
- Purpose: [security, abuse prevention, service reliability]
- Retention: [90 days / your actual period]

We did not find personal data about you in these systems:
- [list systems with no results]

If you want, you can reply to ask us to:
- correct inaccurate data
- delete data where we are allowed to delete it
- explain any item in more detail

If you would like a copy of specific records, reply with the category you want and we will provide it in a suitable format.

Thanks,
[Your name]

What you should see when this succeeds: your reply is specific, readable, and does not include unexplained internal jargon.

Step 7: Save the final response and close the case

Store a copy of what you sent and when you sent it.

Exact action:

Add an internal note:
"Access request completed on YYYY-MM-DD. Identity verified by [verified email + invoice/account ID]. Response sent by [email/ticket]. Systems checked: [list]."

What you should see when this succeeds: the case history shows what was checked, how identity was verified, and when the response was sent.

Verify it works

Check these three things after sending:

1. The sent message includes all five items:

- what data you hold
- where it came from
- why you use it
- how long you keep it
- what the customer can ask for next

1. Your internal note shows identity verification and the systems checked.
2. If the customer replies with a follow-up question, you can trace every statement in your response back to a system record or policy.

A completed request should be easy to audit: one incoming request, one identity check, one search record, and one final response.

Common pitfalls

Replying before identity is verified

Mistake: sending account details to an unverified email address.

Symptom: the requester uses a different address from the one on file, or gives vague details that do not match the account.

Fix: send the Step 2 verification message first and wait for a matching reply.

Only checking the main app and forgetting other systems

Mistake: searching the product database but not email, support, billing, or shared files.

Symptom: the customer replies with "You missed my invoices" or "What about my support tickets?"

Fix: use the Step 3 system list and note both results and no-results.

Sending raw exports instead of a reviewed summary

Mistake: attaching a CSV, SQL export, or screenshot without review.

Symptom: the file includes other users, internal notes, or secrets.

Fix: send the Step 6 summary first; only send specific records after reviewing and redacting them.

Using vague wording like "we may process data"

Mistake: answering with policy language instead of the actual data held for this person.

Symptom: the customer asks again because the response does not tell them what you actually have.

Fix: replace generic wording with the exact categories and values you found in Step 4.

Forgetting legal retention limits

Mistake: promising deletion of invoices or tax records that must be kept.

Symptom: you later have to correct yourself or refuse a request you already agreed to.

Fix: list retention per category in the response and say "where required by law" for records you must keep.

Not keeping an internal record of the response

Mistake: sending the answer but not logging what was checked.

Symptom: a later complaint or audit cannot be reconstructed.

Fix: add the Step 7 note immediately after sending the reply.

This article was written by an AI system and published pending human review. Verify anything you intend to act on.