How to Handle Customer Data Export Requests

When a customer asks for “all my data,” treat the message as a potential privacy-rights request—not merely a technical export task.

Record the request immediately, confirm what the customer wants, identify the applicable law, verify their identity proportionately, collect the relevant data, review it for third-party or protected information, and deliver it securely. Keep an internal record of every decision and date.

The exact legal requirements depend on where your business and customer are located. This guide provides a practical workflow for small SaaS teams, but it is not legal advice.

Understand what the customer is requesting

“Please export my data” can mean several different things:

• A copy of the customer’s personal data
• A portable file they can import into another service
• A copy of their company workspace
• Account deletion after the export
• A combination of access, portability, correction, and deletion

These requests are not legally interchangeable.

Under the EU GDPR, the right of access generally covers a copy of the person’s personal data plus information about how it is processed. The separate right to data portability applies only in certain circumstances, including when automated processing is based on consent or a contract. Portable data must be provided in a structured, commonly used, machine-readable format. The European Data Protection Board identifies CSV, JSON, and XML as common examples and notes that a PDF alone is not sufficient for portability (EDPB small-business guidance).

In California, a qualifying business may receive a CCPA “request to know” covering specific pieces and categories of personal information. The law does not apply to every business, and certain information and organizations are exempt (California Attorney General’s CCPA guidance).

If the request is unclear, ask a focused question such as:

To make sure we prepare the right information, would you like a copy of your personal data, a portable export of your account content, or both? If you also want the account deleted afterward, please confirm that separately.

Do not use clarification simply to delay the response or pressure the customer into narrowing a valid request.

Start a request record and calculate the deadline

Create a simple internal record as soon as the request arrives. Include:

• Customer name and account identifier
• Original message and date received
• Applicable jurisdiction
• Rights being exercised
• Identity-verification steps
• Systems and vendors to search
• Assigned owner
• Response deadline
• Decisions about redactions or withheld information
• Delivery method and completion date

Different laws use different deadlines. Under the GDPR, organizations generally must respond without undue delay and within one month, subject to limited extensions. California businesses subject to the CCPA generally have 45 calendar days and may extend the period by another 45 days if they notify the consumer (California Attorney General).

UK rules also generally require a response within one month. Current ICO guidance explains when the period begins and when an extension may be available for complex or numerous requests (ICO right-of-access guidance).

Set an internal deadline earlier than the legal deadline. Small teams need time to search backups, review support conversations, remove third-party information, and correct export errors.

Confirm whether you are the controller or processor

A small B2B SaaS company may process data in two different roles:

• As a controller for billing contacts, account administration, marketing, and its own customer-support records
• As a processor for personal data uploaded or generated by a business customer using the service

This distinction affects who should respond.

A controller determines why and how personal data is processed. A processor handles data on the controller’s instructions and generally assists the controller with rights requests. The contract between them should describe that assistance (EDPB controller and processor guidance).

For example, if an employee of your B2B customer asks you directly for an export of workspace data, you may need to notify the customer that controls the workspace instead of independently disclosing the data. Check the data-processing agreement and your documented instructions before responding.

Do not ignore the request while deciding. Acknowledge it, record it, and route it to the correct owner.

Verify identity without collecting unnecessary data

An export can contain email addresses, billing records, private messages, IP addresses, API activity, or confidential workspace content. Sending it to an impostor would create a serious security incident.

Verification should match the risk. Practical options include:

• Asking a signed-in customer to submit the request through their account
• Confirming control of the verified account email address
• Requiring a fresh login or step-up authentication
• Matching limited account details already held by the business
• Confirming that an authorized company administrator is permitted to request workspace data

Ask for formal identification only when less intrusive methods are insufficient. The ICO advises organizations to request identification reasonably and proportionately rather than automatically demanding an identity document (ICO subject-access guidance).

If an agent, lawyer, parent, administrator, or other third party submits the request, verify both the requester’s identity and their authority to act for the customer.

Record how verification was completed, but avoid retaining extra verification documents longer than necessary.

Build a complete data map

Searching only the main customer table is rarely enough. Personal data may exist across:

• Account and profile tables
• Authentication and security logs
• Billing and subscription systems
• Product usage and event logs
• Uploaded files and generated content
• Email and support conversations
• App store review responses
• Customer relationship or marketing tools
• Analytics platforms
• Error-monitoring systems
• Internal notes and issue trackers
• Data warehouses
• Active backups
• Vendors and subprocessors

Support systems deserve particular attention. A conversation may contain the customer’s original message, internal notes, attachments, AI-generated drafts, human edits, and the final reply. Determine which of those records contain personal data about the requester and fall within the applicable request.

Do not silently create new categories of data merely to answer the request. Search the information you actually hold and document systems that were checked.

Separate personal data from entire documents

A person’s name appearing in a document does not always mean the entire document must be disclosed. The task is usually to provide the relevant personal data and required contextual information.

Before releasing the export, review it for:

• Personal data about other people
• Confidential customer or employee information
• Authentication secrets and password hashes
• Private API keys or access tokens
• Security details that could expose other accounts
• Legally privileged material
• Trade secrets or protected intellectual property
• Information covered by a specific statutory exemption

Where possible, extract or redact only the protected material while preserving the requester’s information. The ICO advises organizations to consider consent, confidentiality, the sensitivity of third-party information, and whether disclosure without consent would be reasonable (ICO guidance on third-party data and redaction).

Redaction must remove the underlying content, not merely place a visible black box over it. Check exported PDFs, spreadsheets, comments, hidden columns, revision history, file metadata, and embedded attachments.

If the case involves legal privilege, disputed ownership, sensitive employee records, or competing rights, obtain qualified legal advice rather than relying on a generic template.

Choose formats the customer can actually use

The best format depends on the purpose of the request.

A practical export package might contain:

• README.txt or README.md explaining the files
• profile.json for account and profile fields
• activity.csv for chronological events
• conversations.json or individual text files for support history
• An uploads directory containing original customer files
• A PDF for information intended primarily for reading

Use stable field names, ISO 8601 dates, clear time zones, UTF-8 text, and documented identifiers. Explain codes that would otherwise be meaningless.

For an access request, a readable electronic format may be appropriate. For GDPR portability, use a structured, commonly used, machine-readable format such as CSV or JSON when the right applies. Do not substitute screenshots or an image-only PDF for reusable data.

Validate the completed package before sending it:

1. Open every file.
2. Check that dates, characters, and attachments render correctly.
3. Confirm that the export belongs to the correct customer.
4. Search for another customer’s email address or identifier.
5. Verify that redacted information cannot be recovered.
6. Scan the package for credentials and secrets.
7. Have a second person review high-risk exports when possible.

For a solo developer, even a short pause followed by a separate scripted check can reduce the risk of sending the wrong archive.

Deliver the export securely

Match the delivery method to the sensitivity and size of the data. Suitable options may include:

• A time-limited download inside an authenticated account
• A secure file-transfer portal
• An encrypted archive with the password sent through a separate channel
• Encrypted email where both parties can use it correctly

Avoid attaching a sensitive export to an ordinary email without evaluating the risk. Confirm the destination address immediately before sending, restrict access to the intended recipient, and expire downloadable files after a reasonable period.

UK guidance says organizations must take reasonable steps to supply access-request information securely and may provide it through a secure remote system (ICO subject-access guidance).

Do not place secrets inside the export. Password hashes, session tokens, recovery codes, private keys, and full payment-card details are not useful account data and may expose the customer or other users to harm.

Explain what you provided

Send a short response that states:

• The request completion date
• What the package contains
• The covered account or date range
• The file formats
• How to access the export
• When the download will expire
• Any information withheld or redacted and the applicable reason
• How the customer can raise a concern or use an applicable complaint right

Where required, include supplementary information about processing purposes, data categories, recipients, retention, sources, and relevant privacy rights. A raw database dump may not satisfy an access request by itself.

Do not claim that the export contains “everything” unless you have verified that statement. More precise wording is safer: “We searched the systems listed below and included the personal data within the scope of your request.”

Keep the export separate from deletion

Exporting data does not automatically authorize account deletion. Likewise, a deletion request does not necessarily require erasing every record immediately.

If the customer asks for both, record them as related but separate requests. Complete and securely deliver the export before deleting data that is needed to prepare it, unless the customer instructs otherwise or applicable law requires a different sequence.

Retention obligations and exceptions may apply to invoices, fraud-prevention records, disputes, security logs, or other regulated information. Document what was deleted, what was retained, the reason for retention, and any scheduled deletion date.

Finally, remove temporary export files from laptops, shared folders, and transfer systems according to your retention procedure. Keep the request log and decision record, but do not retain an extra copy of the full export without a defined need.

A compact workflow for small teams

A repeatable process can remain simple:

1. Recognize and log the request.
2. Acknowledge receipt.
3. Identify the applicable law, right, deadline, and organizational role.
4. Clarify the scope only when necessary.
5. Verify identity and authority proportionately.
6. Search every relevant system and processor.
7. Review for third-party data, secrets, and lawful exemptions.
8. Create readable and, where required, machine-readable files.
9. Test the export and redactions.
10. Deliver it through a secure channel.
11. Explain the contents and any limitations.
12. remove temporary files and preserve the decision log.

Document this workflow before the first request arrives. A lightweight checklist is usually more reliable than reconstructing the process under deadline pressure.

Conclusion

Handling a customer data export request well requires more than downloading a database row. The essential steps are to recognize the legal request, verify the requester, search all relevant systems, protect other people’s information, use an appropriate format, and deliver the result securely. A documented process makes those decisions faster and more consistent without adding enterprise-level bureaucracy.

References

• European Data Protection Board: Guidelines on the right of access
• European Data Protection Board: Data protection guide for small business
• UK Information Commissioner’s Office: A guide to subject access
• California Attorney General: California Consumer Privacy Act
• EUR-Lex: General Data Protection Regulation