The customer data request SOP for DTC brands

A customer emails: delete everything you have on me. Five words, and a legal clock starts ticking. Under GDPR and CCPA, you have a set window to comply, usually 30 to 45 days, and the penalty for getting it wrong is not a slap. GDPR fines run up to 20 million euros or 4 percent of global turnover, whichever is larger. For a growing DTC brand, that's not a line item; it's an extinction event.

The hard part isn't the law. It's that the customer's data isn't in one place. It's in Shopify, in Klaviyo, in Gorgias, in your retargeting pixel, in your 3PL's system, in the reviews app you installed last year and forgot about. Deleting the profile in one of them doesn't touch the others, and each has its own process. Most brands have no plan for this, so a single request turns into a scramble, and the easiest mistakes, missing a system or missing the deadline, are the ones that get you fined.

A data request SOP turns that scramble into a routine. This is the one we use with DTC brands: what the law actually asks of you, how to map where customer data lives so you can act on it, the step-by-step for handling a request across your whole stack, and how to keep the proof that you did. It's the operational side of privacy, written for a team without a legal department.

Why data requests need an SOP

Privacy requests are rare enough that no one builds a habit around them, and high-stakes enough that improvising is dangerous. That combination is exactly what an SOP is for. Without one, the first request lands on whoever happens to see the email, who figures it out from scratch, under a deadline, probably missing a system or two.

The risk isn't only the fine. A request handled badly, a deletion that misses a tool, a customer who has to ask twice, an access request you can't actually fulfill, is a trust problem and a paper trail working against you. The point of the SOP is that the tenth request is handled exactly like the first: completely, on time, and documented, no matter who's holding it.

What the law actually requires

You don't need to be a privacy lawyer, but your team needs the shape of the obligation in plain terms. Boiled down, the major privacy laws give customers a handful of rights over their data, and give you a deadline to honor them:

• The right to access: tell the customer what data you hold on them, and often provide a copy.
• The right to deletion, the right to be forgotten: erase their personal data on request, with some exceptions you're allowed to keep for legal or transactional reasons.
• The right to correction: fix inaccurate data.
• The right to opt out: stop the sale or sharing of their data, the core of CCPA, and stop marketing on request.

Two practical points matter more than the legal detail. First, the clock: you generally have 30 to 45 days to respond, depending on the law, and the deadline is real, so the SOP has to move fast. Second, the scope: these rights apply to the data wherever it lives, not just the copy in Shopify. That's why the map comes before the process.

Which laws apply depends on where your customers are, not where you are. Sell to someone in California or the EU and their rights travel with them. For a DTC brand shipping nationally or internationally, the safe assumption is that you're on the hook for the strictest rule your customer base spans.

Build your data map first

Everything downstream depends on knowing where customer data lives, so the first artifact isn't a procedure; it's a map. List every system that touches customer personal data, what it holds, and how you delete or export from it. For a typical DTC stack, that list is longer than people expect:

• Shopify: orders, addresses, contact details, accounts. Your system of record, and the one with the trickiest deletion rule.
• Email and SMS (Klaviyo, Postscript, Attentive): profiles, contact info, behavioral and consent data.
• Support (Gorgias, Zendesk): tickets, contact details, conversation history.
• Ad platforms and pixels (Meta, Google): hashed customer data uploaded for targeting and retargeting.
• Your 3PL and any subscription, loyalty, reviews, or returns apps: each holds a slice, and each is easy to forget.

Build the map once and keep it with the SOP. For each system, note who has access, how a deletion or export is done (a button, an API, a support request to the vendor), and any quirks. The map is the difference between confidently honoring a request and hoping you got all of it.

The request-handling process

With the map in hand, the request itself becomes a sequence. Five steps, every time:

1. Log the request and start the clock. Capture the date received, the customer, and what they're asking for. The deadline is counted from this date, so it goes on the calendar immediately.
2. Verify the requester's identity. Before you delete or hand over anyone's data, confirm the person asking is who they claim to be, usually by confirming they control the email or account on file. Acting on an unverified request is its own data breach.
3. Fulfill it across every system on the map. Work the map system by system: delete, export, or opt out in each one. This is where the map pays for itself, because skipping a system is the most common and most expensive error.
4. Respond to the customer securely. Confirm what you did, and if it's an access request, deliver the data by a secure method you can track, not a plain email attachment.
5. Log the completion with proof. Record what you did in each system, when, and who handled it, so you can show the request was honored fully and on time.

Notice that the work is mostly in step three, and step three is only as good as the map. A documented sequence keeps a stressed person from skipping verification or forgetting the pixel at 4pm on a deadline.

The per-tool reality

Each system on your map deletes differently, and a few have quirks worth knowing before a request lands, not during one:

• Shopify won't delete a customer's personal data if they've placed an order in the last 180 days, because it needs the record in case of a chargeback. You can request the deletion, but it completes after the window. Know this so you can give the customer an accurate timeline instead of assuming it's instant.
• Klaviyo offers a data privacy API that deletes a profile by email, phone, or ID in line with GDPR and CCPA. It's a clean delete, but it's separate from Shopify; doing one does nothing to the other.
• Gorgias deletes the customer's data within Gorgias when you action a request, and only within Gorgias. Same story for every other tool.
• Pixels and ad platforms hold uploaded customer lists. Removing someone means suppressing or deleting them in the ad platform, which teams routinely forget because it's out of sight.

The throughline: every platform operates independently. There is no master delete button across your stack unless you've bought a tool that builds one, and most brands at this stage haven't. The map plus the per-tool steps are your master delete button.

Keep proof and hit the deadline

Compliance you can't prove is compliance you can't defend, and on a deadline-driven obligation, proof and timing are the whole game:

• Track the deadline from the day the request lands. Put it on a shared calendar with a buffer, because 30 days disappears fast when a request needs a vendor's help to fulfill.
• Keep a log of every request: who asked, what they wanted, what you did in each system, and the date you completed it. This is your evidence that you honored the request fully and on time.
• Save the identity verification too. If you ever delete the wrong person's data because you didn't verify, the record of how you verified is what protects you.

A brand that can produce a clean request log handles a regulator's question in an afternoon. A brand that handled requests ad hoc, with no record, is negotiating from nothing, which is the same lesson as every other compliance surface: the proof is the protection.

Who owns data requests

Privacy requests fall through the cracks precisely because they're rare and cross-functional. Assign them clearly:

• One owner for data requests, usually ops or whoever holds compliance, who receives them, runs the SOP, and keeps the log and the data map current.
• A monitored intake. Requests arrive however the customer sends them, a support ticket, a privacy email, a webform, so make sure they route to the owner and aren't lost in a shared inbox. Many brands add a privacy request form to keep intake clean.
• Vendor contacts noted in the map, so when a system needs the vendor to action a deletion, the owner knows who to email instead of starting a support thread cold under deadline.

This doesn't need a privacy officer. It needs one named owner, a clean intake, and the map and log kept current. That's enough for a DTC brand to handle requests calmly instead of treating each one as an emergency.

Keep the SOP current

A data request SOP goes stale on two sides. Your stack changes: you add a reviews app, a new pixel, a loyalty tool, and now there's customer data in a place your map doesn't list and your process doesn't touch. And the law changes: the wave of US state privacy laws keeps widening who has rights and what you owe them, so an SOP scoped to last year's rules can quietly fall short.

Review the SOP and the data map every quarter, and update the map immediately whenever you add or remove a tool that touches customer data. This is ordinary documentation drift, and on a privacy SOP it shows up as a deletion request you fulfilled everywhere except the one system you forgot you had, which is the kind of gap that becomes a complaint.

Where to start this week

Don't wait for a request to build this. Do the one thing that makes every future request manageable: write the data map. List every tool that holds customer data and, for each, how you delete and export from it. That single document turns the next delete-my-data email from a panic into a checklist.

Then write the five-step process on one page, assign an owner, and set up a clean way for requests to reach them. You don't need a privacy platform to be compliant at your stage. You need to know where your data is and have a documented way to act on it.

ReccordSOP turns a process like this into a documented SOP with timestamped screenshots, and flags drift when your stack or your obligations change underneath it. Generate your first SOP free at reccordsop.com.