Privacy law is genuinely one of the areas where specifics (applicability thresholds, required disclosures, exact consent mechanics) matter a great deal and change over time — this is a plain-language orientation to the concepts, not a compliance audit of your specific site. Confirm current requirements with a privacy attorney, particularly once your site handles a meaningful volume of customer data or expands into new markets.

Why a US-based seller might need to care about GDPR at all

The EU's General Data Protection Regulation applies based on whose data you're processing, not where your business is located — if your DTC site has EU visitors/customers and you're collecting their personal data (which includes basic things like an email address or IP address, not just obviously sensitive information), GDPR can apply to you regardless of where your company is based. This surprises a lot of US-based sellers who assume a US business is automatically outside GDPR's reach.

What GDPR generally asks for

  • A documented lawful basis for each way you process personal data — consent, contractual necessity (fulfilling an order), legitimate interest, and a few other bases each work for different purposes; marketing emails, for example, generally need a different (typically consent-based) basis than the data processing needed just to ship someone's order.
  • Clear, specific consent for non-essential uses — particularly for things like non-essential cookies, marketing communications, and third-party ad tracking. "Pre-checked" or ambiguous, buried-in-fine-print consent generally doesn't meet GDPR's bar; consent needs to be a genuinely informed, specific, affirmative action.
  • Data subject rights — EU individuals generally have rights to access the personal data you hold about them, request correction, request deletion ("right to be forgotten"), and receive their data in a portable format, and your site needs a real process (not just a policy statement) for actually fulfilling these requests within a set timeframe.
  • A public, specific privacy policy — describing what data you collect, why, how long you keep it, who you share it with (including any third-party tools — analytics, ad platforms, email providers), and how someone can exercise their rights.
  • Data Processing Agreements (DPAs) with your vendors — any third-party service that processes personal data on your behalf (your email marketing platform, your analytics tool, your payment processor) generally needs a DPA in place, since you remain responsible for how your vendors handle data you've shared with them.
  • Breach notification obligations — a data breach involving personal data generally triggers a notification obligation to a regulator and, in some cases, to affected individuals, within a set timeframe from when you become aware of it.

What CCPA/CPRA generally asks for (California)

California's California Consumer Privacy Act, as amended by the California Privacy Rights Act, works differently from GDPR in structure but covers similar ground:

  • Applicability is generally threshold-based — tied to factors like revenue, the volume of California consumers' data processed, or the proportion of revenue from selling/sharing personal data, with the specific current thresholds set by the statute and its regulations. Confirm current thresholds directly rather than assuming a specific dollar or record-count figure, since these are exactly the kind of details this article deliberately avoids stating as fixed facts.
  • Rights to know, delete, and correct personal data collected about a California resident, generally through a verifiable consumer request process your site needs to support.
  • A right to opt out of the "sale" or "sharing" of personal data — this is broader than a literal cash sale of data; sharing data with third-party advertising/analytics platforms in certain ways can qualify as a "sale" or "share" under CCPA/CPRA's specific definitions, which is why many sites display a "Do Not Sell or Share My Personal Information" link even if they've never literally sold a data file to anyone.
  • Sensitive personal data protections — CPRA added a category of "sensitive" personal data (certain identifiers, precise geolocation, and other categories) with additional restrictions on use beyond what applies to personal data generally.

The practical overlap for most DTC sellers

Even without memorizing every distinction between the two regimes, a reasonably safe practical baseline for a DTC site includes:

  • A clear, specific, genuinely accurate privacy policy (not a generic template that doesn't reflect your actual data practices) — see Return, Refund, and Privacy Policy Templates for a starting structure.
  • A cookie consent mechanism appropriate to your actual visitor base — genuinely optional/rejectable consent for non-essential cookies if you have meaningful EU traffic, at minimum a clear disclosure and opt-out mechanism for US traffic.
  • A working process to actually respond to a data access, deletion, or opt-out request — not just a policy statement promising you'll honor one, but an internal process (even a simple one) for actually doing it within the applicable timeframe.
  • DPAs in place with your key vendors that touch customer personal data (email platform, analytics, ad pixels, helpdesk/CRM tool).
  • A "Do Not Sell or Share" link and mechanism if your site uses third-party advertising/analytics tools in ways that could qualify as a sale or share under CCPA/CPRA's definitions — many sites include this proactively rather than trying to determine precisely whether their specific setup crosses the threshold.

Common mistakes

  • Assuming GDPR doesn't apply because your business isn't based in the EU.
  • Assuming CCPA doesn't apply because you're "too small," without actually checking the current applicability thresholds against your specific numbers.
  • Using a generic privacy policy template that doesn't accurately describe your actual data collection and sharing practices.
  • Having a privacy policy that promises rights (access, deletion, opt-out) without an actual internal process to fulfill a request when one comes in.
  • Not having DPAs in place with vendors who process customer data on your behalf.
  • Treating cookie consent banners as a "check the box and move on" implementation rather than confirming the underlying consent mechanics are genuine (real opt-out, not just a dismiss button that leaves tracking on).

FAQs

  • Do I need to comply with GDPR if I never explicitly market to the EU? Even without deliberately targeting EU customers, if your site is genuinely accessible to and used by EU visitors and you process their personal data, GDPR can potentially apply — confirm your specific exposure with a privacy attorney rather than assuming passive accessibility is automatically outside scope.
  • What counts as "personal data" under these laws? Generally much more than sellers expect — an email address, an IP address, a device identifier, and browsing behavior tied to an identifiable person can all qualify, not just obviously sensitive categories like financial or health information.
  • Is a cookie banner enough to be compliant? Not by itself — the banner needs to actually implement genuine, specific, rejectable consent for non-essential tracking (for GDPR) and a genuine opt-out mechanism (for CCPA/CPRA), not just a dismiss button that doesn't change what's actually being tracked.