What Is GDPR Compliance? What U.S. Companies Need to Know

I've seen enough U.S. companies make expensive mistakes with GDPR to know the confusion is real. The General Data Protection Regulation sounds like a European problem, but American businesses processing data from EU residents face the same requirements, the same enforcement mechanisms, and the same potential fines as companies headquartered in Brussels or Berlin. The question isn't whether GDPR applies to you. The question is whether you understand what it actually requires when it does.

GDPR went into effect in May 2018, and the early wave of enforcement actions taught us which assumptions got companies in trouble. Most weren't deliberately reckless. They either misunderstood the jurisdictional triggers, assumed their existing privacy practices were sufficient, or treated GDPR compliance as a checklist exercise instead of a shift in how they handle personal data. None of those approaches worked.

This article covers what GDPR compliance actually means for U.S. companies: when the regulation applies, what the core principles require in practice, and what you need to implement beyond the marketing materials your privacy vendor handed you.

When GDPR Applies to U.S. Companies

The jurisdictional scope of GDPR catches more American companies than most executives realize. You don't need an office in the EU. You don't need EU employees. You need to process personal data of people located in the EU, and you need to do it in one of two ways the regulation calls out specifically.

First, you're covered if you offer goods or services to people in the EU. This isn't about intent—it's about targeting. If your website shows prices in euros, ships to EU addresses, or runs marketing campaigns aimed at European customers, you've triggered the regulation. I've seen companies argue they're only passively accepting orders from wherever they come in, but if you've configured shipping zones for France or optimized your SEO for German search terms, that argument won't hold.

Second, you're covered if you monitor the behavior of people in the EU. This includes tracking cookies, behavioral advertising, location tracking, and profiling. If you're running ad retargeting campaigns that follow EU visitors around the web, you're monitoring behavior. If you're collecting analytics beyond basic server logs, you're likely monitoring behavior.

The pattern I see most often: U.S. companies that assume they're exempt because their "real" customer base is domestic. Then I look at their Google Analytics, their email platform, or their CRM, and there are EU IP addresses throughout the data. That's processing. That's covered.

What Counts as Personal Data

GDPR defines personal data broadly: any information relating to an identified or identifiable natural person. Names and email addresses, obviously. But also IP addresses, cookie identifiers, device IDs, location data, and anything else that can be linked back to a person, directly or indirectly.

The "indirectly" part creates problems. If you can combine data points to identify someone—even if no single field would do it—you're processing personal data. That session replay tool recording mouse movements? Personal data. That heatmap tracking where users click? Personal data. The CRM notes field where your sales team types whatever they want? Almost certainly personal data, and possibly special category data if they're recording health information or other sensitive details.

The Core Principles That Actually Matter

GDPR is built on seven principles. Most companies I work with can recite them. Fewer can explain what they mean in practice. Even fewer have implemented controls that demonstrate compliance when an auditor or regulator shows up.

Lawfulness, Fairness, and Transparency

You need a lawful basis for every processing activity. GDPR provides six options: consent, contract, legal obligation, vital interests, public task, and legitimate interests. Most U.S. companies default to consent because it sounds familiar, but consent under GDPR is not the same as the checkbox theater we're used to.

Consent must be freely given, specific, informed, and unambiguous. Pre-ticked boxes don't work. Bundled consent doesn't work—you can't condition service on agreeing to unrelated processing. Consent for "improving our services" is too vague. And you need to be able to prove you obtained valid consent, with records showing what the person agreed to, when, and how.

In my experience, most U.S. businesses are better served by legitimate interests as their lawful basis for analytics, fraud prevention, and other processing that benefits both the company and the user. But legitimate interests require a balancing test—documented evidence that your interests don't override the individual's rights. I don't see many companies doing that assessment properly, or at all.

Purpose Limitation

You collect data for a specific purpose, and you use it for that purpose. You don't repurpose data without a new lawful basis or explicit consent. This principle breaks most of the "data-driven culture" advice vendors have been selling for the past decade.

If you collected email addresses for order confirmations, you can't add those addresses to your marketing list without separate consent. If you gathered location data for delivery logistics, you can't feed it into your advertising algorithms without a lawful basis for that new purpose. The pattern I see: companies treating their database as a general-purpose asset they can use however they want. That's not how GDPR works.

Data Minimization

Collect only the data you actually need for your stated purpose. This principle runs counter to the default posture in U.S. tech: collect everything, figure out how to use it later.

Data minimization requires you to ask why you're collecting each field before you add it to your form or your tracking script. Do you need the phone number, or do you want it? Do you need to log full IP addresses, or would the first three octets suffice for your geo-targeting? Do you need birthdate, or just age verification?

I've reviewed intake forms with 40 fields where 12 would have done the job. Every unnecessary field is risk—risk of breach, risk of misuse, risk of regulatory attention. GDPR formalized what should have been common sense: don't collect data you don't need.

Accuracy

Personal data must be accurate and kept up to date. You need processes to correct or delete inaccurate information. This sounds straightforward until you consider how many systems hold copies of the same record, how often people move or change jobs, and how rarely companies have a master data management strategy that works.

When someone submits a correction request, you need to identify every system that holds their data and update all of them. Most companies I work with can't answer that question without a multi-week discovery process.

Storage Limitation

You keep personal data only as long as necessary for your stated purpose. This requires retention schedules, automated deletion processes, and documentation explaining why you're keeping data for the period you've chosen.

U.S. companies often struggle here because storage is cheap and deletion is hard. Databases grow indefinitely. Backups accumulate. Email archives stretch back years. GDPR doesn't care that it's technically easier to keep everything. If you don't need it, delete it.

Integrity and Confidentiality

You must protect personal data with appropriate security measures. This principle overlaps with security frameworks you may already follow—NIST, ISO 27001, CIS Controls—but GDPR adds a requirement to document your risk assessment and explain why your controls are appropriate for the types of data you process.

Encryption, access controls, logging, and incident response aren't optional. Neither is vendor due diligence for any third party that processes data on your behalf.

Accountability

You must demonstrate compliance, not just claim it. This means documentation: data processing records, privacy impact assessments, vendor agreements, consent logs, training records, and evidence that you're actually following the policies you've written.

Accountability is where most compliance programs fail. The policies exist. The processes are half-implemented. The documentation is incomplete or outdated. When a regulator asks to see proof of GDPR compliance, you're assembling it for the first time instead of maintaining it continuously.

What GDPR Compliance Requires in Practice

Understanding the principles is step one. Implementing them requires specific artifacts, processes, and controls. Here's what I look for when I'm assessing whether a company has actually achieved GDPR compliance or just updated their privacy policy.

Records of Processing Activities

You need a documented inventory of all processing activities: what data you collect, why you're collecting it, what your lawful basis is, where it's stored, who has access, how long you keep it, and which third parties receive it. This isn't a one-time exercise. Your processing activities change every time you add a new tool, launch a new feature, or start a new marketing campaign.

Most companies I work with don't have current records of processing activities. They completed an inventory during the initial GDPR rush in 2018, then never updated it. That document is now evidence of noncompliance, not compliance.

Privacy Notices That Actually Inform

Your privacy notice must explain what data you collect, why, what your lawful basis is, who you share it with, how long you keep it, and what rights individuals have. The notice must be clear, accessible, and written in plain language.

I see two failure modes here. First, notices so vague they're meaningless: "We collect information you provide to us to improve our services." That tells me nothing. Second, notices copy-pasted from a template without customization. If your privacy notice says you process health data but you don't, or fails to mention the advertising platforms you actually use, you've created a compliance liability.

Data Processing Agreements with Vendors

Any vendor that processes personal data on your behalf is a processor under GDPR. You're the controller. You need a data processing agreement (DPA) with each processor, and that agreement must include specific terms GDPR requires: the subject matter and duration of processing, the nature and purpose of processing, the types of data and categories of data subjects, your obligations and rights as controller, and the processor's obligations around security, subprocessors, breach notification, and deletion.

Most SaaS vendors now offer a standard DPA. Some make you ask for it. A few still don't have one, which tells you they're not taking GDPR seriously. If a vendor processes EU personal data and won't sign a DPA, find a different vendor or accept that you're noncompliant.

Mechanisms to Handle Individual Rights Requests

GDPR grants individuals specific rights: access, rectification, erasure, restriction of processing, data portability, objection, and rights related to automated decision-making. You need processes to receive, verify, fulfill, and document requests for each of these rights, typically within one month.

The right to erasure—often called the right to be forgotten—causes the most operational difficulty. When someone requests deletion, you need to remove their data from production databases, backups, logs, archives, and any third-party systems. You also need to notify any recipients of that data so they can delete it too. Most companies can't do this without manual intervention and a week of engineering time.

I've seen companies ignore erasure requests, claim technical infeasibility, or respond months late. None of those approaches ends well. If you can't handle rights requests efficiently, you're not GDPR compliant.

Breach Notification Procedures

If you suffer a breach involving personal data that poses a risk to individuals' rights and freedoms, you must notify the relevant supervisory authority within 72 hours. If the breach poses a high risk, you must also notify affected individuals without undue delay.

The 72-hour timeline is aggressive. You need an incident response plan that includes privacy impact assessment, legal review, regulatory notification templates, and communication workflows. You need to know which supervisory authority has jurisdiction—usually the authority where your main EU establishment is located, or if you don't have one, where most of your EU data subjects are located.

This isn't theoretical. EU supervisory authorities have issued significant fines for breach notification failures: late notifications, incomplete notifications, failure to notify at all. The breach is bad enough. The notification failure makes it worse.

Privacy Impact Assessments: When and How

If your processing is likely to result in high risk to individuals' rights and freedoms, you must conduct a Data Protection Impact Assessment (often called a Privacy Impact Assessment or PIA) before you begin processing. High risk typically means large-scale processing of special category data, systematic monitoring of public areas, automated decision-making with legal or significant effects, or processing of vulnerable populations.

The assessment must describe the processing, assess necessity and proportionality, evaluate risks to individuals, and document the measures you'll implement to address those risks. If risks remain high even after mitigation, you need to consult the supervisory authority before proceeding.

I wrote about this in more detail in my article on privacy impact assessments, but the key point is this: PIAs aren't optional for high-risk processing, and "we didn't think we needed one" isn't a defense. If you're deploying facial recognition, processing health data at scale, or using AI to make employment decisions, you need a PIA.

Cross-Border Data Transfers and U.S. Companies

If you're a U.S. company processing EU personal data, that data has likely been transferred out of the EU to your U.S. servers. GDPR restricts transfers of personal data to countries outside the European Economic Area unless those countries provide adequate protection or you've implemented appropriate safeguards.

The U.S. is not considered adequate. For years, the primary mechanism for transfers was Privacy Shield, until the European Court of Justice invalidated it in the Schrems II decision in 2020. The replacement framework—the EU-U.S. Data Privacy Framework—was adopted in 2023, but it faces legal challenges and may not survive long-term.

If you're not certified under the Data Privacy Framework, you need an alternative transfer mechanism. The most common is Standard Contractual Clauses (SCCs), which are model contract terms approved by the European Commission. You execute SCCs with your EU customers or partners, and those SCCs impose specific obligations on you as the data importer.

But SCCs alone may not be enough. Post-Schrems II, you must also conduct a transfer impact assessment to evaluate whether U.S. surveillance laws undermine the protections the SCCs are supposed to provide. If they do, you need supplementary measures—technical controls like encryption, pseudonymization, or data localization that reduce the risk that U.S. government access would compromise the data.

This is complex, evolving, and not well settled. If you're a U.S. company handling significant volumes of EU personal data, you need legal counsel who specializes in cross-border data transfers, and you need to document your transfer mechanisms and impact assessments.

Enforcement and What It Looks Like

GDPR grants supervisory authorities the power to issue fines up to €20 million or 4% of annual global turnover, whichever is higher. The headlines focus on the massive fines—€746 million against Amazon, €405 million against Instagram, €225 million against WhatsApp—but those are outliers targeting the largest tech companies.

Most enforcement actions are smaller but still significant. Fines in the six-figure range for failures like inadequate security, unlawful processing, invalid consent mechanisms, or improper vendor agreements. U.S. companies are not exempt. The Irish Data Protection Commission has gone after U.S. tech companies operating in Ireland. Other EU authorities have pursued U.S. firms with EU customers or users.

The risk isn't just regulatory. GDPR also grants individuals the right to seek compensation for material or non-material damage resulting from GDPR violations. Class actions are less common in the EU than in the U.S., but they're growing, particularly in the UK post-Brexit where litigation rules differ.

Beyond fines and lawsuits, there's reputational risk. A public enforcement action or data breach notification signals to your customers, partners, and investors that you're not managing privacy risk competently. That matters more in some industries than others, but it always matters.

How GDPR Relates to U.S. State Privacy Laws

If you're subject to GDPR and you're also dealing with California's CPRA, Virginia's CDPA, Colorado's CPA, or any of the other U.S. state privacy laws, you'll notice significant overlap in principles and requirements: transparency, purpose limitation, data minimization, individual rights, vendor agreements.

The overlap means that implementing GDPR compliance gets you partway toward compliance with U.S. state laws. But there are differences. Consent standards vary. Definitions of personal data and sensitive data aren't identical. Enforcement mechanisms differ. Some states grant private rights of action; GDPR doesn't. Some states have broader exemptions for certain types of data or entities.

I've written about the differences between CCPA and CPRA and about the broader landscape of U.S. state privacy laws. The strategic point is this: if you're building a privacy program that needs to cover both GDPR and U.S. state laws, design for the highest common requirements rather than trying to maintain separate compliance tracks. That approach scales better as more states adopt privacy laws.

What GDPR Compliance Signals to Leadership

GDPR compliance isn't just a legal checkbox. It's a signal about how seriously you take data governance, risk management, and operational discipline. Companies that handle personal data responsibly—minimizing what they collect, securing what they store, deleting what they don't need, respecting individual rights—build trust with customers, reduce breach impact, and operate more efficiently.

The inverse is also true. Companies that treat privacy as an afterthought, that collect data indiscriminately, that can't answer basic questions about where data lives or who has access, are exposing themselves to regulatory risk, security risk, and operational risk that leadership often doesn't understand until it's too late.

If you're a U.S. company processing EU personal data, GDPR compliance is mandatory. But even if your EU exposure is minimal, the discipline GDPR requires—data inventories, retention schedules, vendor oversight, documented processes for individual rights—makes you better at managing data generally. Privacy regulation is expanding, not contracting. The skills and systems you build for GDPR will serve you as more jurisdictions adopt similar requirements.

The companies getting this right aren't treating GDPR as a compliance project. They're treating it as an operating model for how they handle personal data everywhere, for everyone. That's the approach that scales. That's the approach that reduces risk. And that's the approach that positions you to adapt as privacy regulation continues to evolve.

For executives and boards navigating privacy risk, I work with leadership teams to design privacy programs that meet regulatory requirements without creating unnecessary friction or cost. The goal isn't perfect compliance—it's sustainable compliance that fits your business model and your risk tolerance. If you're trying to figure out what GDPR compliance actually requires for your organization, or how to integrate it with your broader privacy and security strategy, that's a conversation worth having.

Privacy is no longer optional. Understanding what compliance requires, and building the capabilities to deliver it, is a leadership responsibility. GDPR set the standard. U.S. laws are following the same path. The companies that get ahead of this trajectory will compete better than the ones still arguing about whether they need to comply.