GDPR Compliance Checklist for US Companies (2026)

Last updated July 2026. GDPR applies to a US company with no European office if it offers goods or services to people in the EU or monitors their behavior. That is Article 3(2), and it catches far more American businesses than most realize: a SaaS product with EU customers, an e-commerce site that ships to Germany, an analytics or advertising tool that tracks EU visitors. Having no EU entity does not put you outside the regulation. It usually just means you also need an Article 27 representative.

This checklist is written for US companies working out what GDPR actually requires of them, in the order the work makes sense. It is practical guidance, not legal advice, and if you process sensitive categories of data or run large-scale profiling you should have counsel look at your specific situation.

Does GDPR apply to my US company?

Work through three questions. First, do you offer goods or services to people in the EU or UK? The test is intent, not accident: pricing in euros, shipping to EU countries, translating your site, or running EU-targeted ads all count, while a single unsolicited EU signup on an otherwise US-only product generally does not. Second, do you monitor the behavior of people in the EU? Cookies, analytics, session recording, ad retargeting and device fingerprinting all qualify. Third, do you process EU personal data as a vendor for a customer who is themselves subject to GDPR? If so you are a processor, and your customer's data processing agreement will push most obligations onto you contractually regardless of the territorial test.

A yes to any of those means GDPR applies. Note also that the UK left the EU but kept the regulation as UK GDPR, so selling into both means satisfying two near-identical regimes with two separate representative requirements.

The GDPR compliance checklist

1. Build a record of processing activities

Article 30 requires a written record of what personal data you process, why, on what lawful basis, who you share it with, where it goes, and how long you keep it. Everything downstream depends on this, and it is the first document a supervisory authority asks for. Build it from the actual systems rather than from memory: pull the list of tools that touch customer data from your SSO, your vendor spend and your engineering inventory, because the marketing stack is where the surprises hide.

2. Establish a lawful basis for every purpose

You need one of six lawful bases under Article 6 for each processing purpose, and you must document which one you picked before you start processing. Consent, contract, legal obligation, vital interests, public task, or legitimate interests. Two practical notes for US teams: consent under GDPR must be freely given, specific, informed and unambiguous, so a pre-ticked box or an implied-consent cookie banner does not qualify. And if you rely on legitimate interests, write the balancing test down at the time, because reconstructing it later carries no weight.

3. Appoint an Article 27 EU representative

This is the requirement US companies miss most often. If GDPR reaches you under Article 3(2) and you have no EU establishment, you must designate a representative in an EU member state where your data subjects are, name them in your privacy notice, and give supervisory authorities and individuals a way to contact them. Selling into the UK means a separate UK representative. Limited exemptions exist for occasional, low-risk processing that excludes sensitive data, but they are narrower than most companies assume.

4. Decide whether you need a Data Protection Officer

Article 37 requires a DPO if you are a public authority, if your core activities involve regular and systematic monitoring of individuals at scale, or if you process special categories of data at scale. Many US companies do not meet the threshold, but if you do, the DPO must be independent, report to the highest management level, and cannot be someone who decides how the data gets used, which rules out your CTO or head of marketing.

5. Write a privacy notice that meets Articles 13 and 14

A US-style privacy policy usually falls short. GDPR requires you to tell people your identity and your representative's, your DPO's contact if you have one, each purpose and its lawful basis, your legitimate interests if you rely on them, recipients of the data, transfers outside the EU and the safeguard used, retention period, all their rights including withdrawal of consent and complaint to a supervisory authority, and whether any automated decision-making happens. In clear, plain language.

6. Build a data subject request process that runs in a month

Individuals have rights of access, rectification, erasure, restriction, portability, objection, and to not be subject to solely automated decisions. You have one month to respond, extendable by two more for complex requests, and you cannot charge unless the request is manifestly unfounded or excessive. Test the process end to end before you receive a real request. The access and erasure rights are the ones that hurt: they require knowing every system holding a given person's data, which is where an incomplete record of processing turns a one-month deadline into a fire drill. Companies that handle high request volumes typically automate the search-and-delete step across systems the same way removing an individual's records from data brokers is automated, because doing it by hand does not scale past a few requests a week.

7. Handle international transfers properly

Sending EU personal data to the US is a restricted transfer and needs a valid mechanism. The EU-US Data Privacy Framework adequacy decision, adopted in July 2023, covers transfers to US organizations that have self-certified to the DPF. It remains valid in 2026 and survived its first General Court challenge in September 2024, but it is under continued legal scrutiny and a further CJEU ruling is expected. Given the history of Safe Harbor and Privacy Shield, the prudent posture is to certify to the DPF if it fits and also keep Standard Contractual Clauses with a documented transfer impact assessment in place as a fallback, so an invalidation does not stop your data flows overnight.

8. Get your processor agreements in order

Article 28 requires a written contract with every processor covering the subject matter, duration, nature and purpose of processing, the categories of data and subjects, and specific obligations including confidentiality, security, sub-processor authorization, assistance with data subject rights, deletion or return at the end, and audit rights. You also need to satisfy yourself that each processor offers sufficient guarantees, which means actual due diligence rather than a signed DPA in a folder. Given how many vendors touch customer data at a typical SaaS company, this becomes a third-party risk exercise, and the same vendor risk management process that serves your SOC 2 program covers most of it.

9. Implement Article 32 security measures

GDPR does not prescribe controls; it requires measures appropriate to the risk, and names pseudonymization, encryption, confidentiality, integrity, availability and resilience, restoration after an incident, and regular testing of effectiveness. In practice, if you already run a SOC 2 or ISO 27001 control set you have most of this, and the crosswalk is direct. What is often missing is the documented evidence that you test effectiveness regularly rather than just having the controls.

10. Run DPIAs where required

Article 35 requires a data protection impact assessment before processing likely to result in high risk: large-scale systematic monitoring of public areas, large-scale processing of special category data, or systematic automated evaluation producing legal or similarly significant effects. Supervisory authorities publish their own lists of processing that always requires one. Do the DPIA before the processing starts, because a retrospective one is evidence of the wrong thing.

11. Prepare for the 72-hour breach clock

You must notify the lead supervisory authority within 72 hours of becoming aware of a personal data breach unless it is unlikely to result in risk to individuals, and notify affected individuals without undue delay when the risk is high. Seventy-two hours is not much time to determine scope, so decide in advance who declares a breach, which authority is your lead, what the notification contains, and how you will assess risk. Document breaches you decide not to report along with the reasoning, because Article 33(5) requires that record too.

12. Apply data minimization and retention limits

Collect only what you need for the stated purpose, and delete it when that purpose ends. Set a retention period per data category, write it in the record of processing, and actually enforce it in the systems. Automated deletion beats a calendar reminder, and holding data indefinitely because storage is cheap is exactly the posture regulators penalize.

What are the GDPR fines for US companies?

Two tiers. Administrative fines up to €10 million or 2% of total worldwide annual turnover for the preceding financial year, whichever is higher, for obligations like records, security and DPIAs. Up to €20 million or 4% of worldwide turnover for breaches of the core principles, lawful basis, data subject rights and international transfer rules. Turnover means global group revenue, not EU revenue, which is what makes the numbers meaningful for a US company with modest European sales. Enforcement against US companies without an EU establishment is harder in practice, but supervisory authorities can order processing to stop, which for a SaaS business serving EU customers is the more immediate commercial problem.

Is CCPA compliance enough for GDPR?

No, though it helps. Both give access and deletion rights and both require disclosure. The structural differences matter: GDPR requires a documented lawful basis before processing, CCPA is largely opt-out for sale and sharing while GDPR often requires opt-in consent, GDPR covers any personal data of anyone in scope rather than California residents, GDPR imposes the 72-hour breach notification and DPIA obligations CCPA does not, and GDPR restricts international transfers. If you built for CCPA you have the request-handling machinery, which is real progress. You still need the lawful basis analysis, the record of processing, the representative and the transfer mechanism.

How long does GDPR compliance take?

For a mid-sized US SaaS company starting from a CCPA-level baseline, three to six months of real work is typical, and most of it is the record of processing and the vendor contracts rather than anything technical. Starting from nothing, budget six to twelve months. The pace is set by how many systems hold personal data and how quickly your vendors will sign updated DPAs, which is frequently the long pole and is worth starting on day one.

Keeping it true after the project ends

The trap with GDPR is that it is written as a continuous obligation and gets run as a one-time project. Records of processing go stale the week after a new tool is adopted, retention rules quietly stop being enforced, and a vendor gets added without a DPA. The controls that stay accurate are the ones something checks automatically, which is the same argument that applies to every framework here: your Article 32 security measures largely overlap SOC 2 and ISO 27001, so mapping them once and evidencing them continuously through GDPR compliance software costs far less than treating each regime as its own program. If you are early in that mapping, our explanation of how governance, risk and compliance fit together covers why the crosswalk pays off.