What Is GDPR and When Does It Apply to US Companies?

The question usually arrives one of two ways. A European customer sends over a data processing agreement and asks you to sign it, or somebody notices the signup form has been collecting addresses in Berlin for eighteen months. Either way the answer starts in the same place: one article of an EU regulation that decides whether any of the rest applies to you.

Most American companies get that answer from a vendor's blog, and vendor blogs are written to sell software, so they tend toward the widest possible reading. If Europeans can reach your website, you are in scope. That is not what the regulation says, nor what the regulators who enforce it say. The genuine test is narrower than the marketing version, the headline fine number is the wrong one for most security failures, and the obligation US companies miss most often is not one the summaries lead with.

What Is GDPR?

GDPR stands for General Data Protection Regulation, formally Regulation (EU) 2016/679 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data. It replaced a 1995 directive that each member state had implemented in its own way. The switch from directive to regulation is the part worth understanding: a regulation applies directly in every member state, so the text itself is the law rather than a template for twenty-seven laws.

It divides the world into two roles. A controller "determines the purposes and means of the processing of personal data." A processor "processes personal data on behalf of the controller." You are a controller for your own customer list and your own employees, and a processor for whatever customers upload into your product. Most software companies are both at once, which is why the data processing agreement an enterprise customer sends you spends its first page settling which role applies to what.

Enforcement sits with national supervisory authorities rather than any single European agency: Ireland's Data Protection Commission, France's CNIL, the German state authorities. The European Data Protection Board coordinates them and publishes the guidelines that decide how the text gets read in practice, and several of those guidelines say things a US company would never guess from the regulation alone.

Does GDPR Apply to US Companies?

Often, yes, and the deciding clause is Article 3. It has three triggers and a US company needs only one.

Article 3(2) is the clause that reaches across the Atlantic, and it turns on intent rather than on network traffic. The European Data Protection Board's guidelines on the territorial scope of the GDPR set the test at whether the controller's conduct "demonstrates its intention to offer goods or a services to a data subject located in the Union," then list what does not count: the mere accessibility of your website in the Union, an email address or other contact details on it, and the use of a language generally used in your own country are each insufficient on their own. What makes the intention apparent is naming an EU member state alongside the product, quoting prices in euros with the ability to order in them, paying a search engine for referrals aimed at consumers in the Union, or naming EU customers on the site.

Two footnotes. The regulation protects people in the Union rather than EU citizens as such, so a French national living in Ohio is outside Article 3(2) while an American on a business trip in Lisbon can be inside it. And the United Kingdom kept the text after leaving the EU as UK GDPR, enforced by the Information Commissioner's Office, so British customers need the same analysis under a separate statute.

What Counts as Personal Data Under GDPR

Article 4(1) defines personal data as any information relating to an identified or identifiable natural person, and names the identifiers that count: a name, an identification number, location data, an online identifier, or factors specific to that person's physical, physiological, genetic, mental, economic, cultural or social identity.

Two consequences surprise teams working from a US definition of personally identifiable information. An online identifier is personal data, which brings IP addresses, cookie identifiers and device identifiers inside the perimeter with no name attached. And business contact data is personal data: a work email address, an employer and a job title relate to an identifiable person, so a B2B database is not outside the regulation because nothing in it is consumer data.

Pseudonymized data, where identifiers are replaced by a key held separately, is still regulated, because the person stays identifiable to whoever holds the key. Truly anonymized data sits outside the regulation. The honest question about any dataset is who could put the pieces back together, not whether your own team currently can.

What Are the GDPR Principles and Lawful Bases?

Article 5 lists the principles every processing operation has to satisfy. Article 6 lists the six grounds on which processing can happen at all. They stack: you need a lawful basis, and the processing still has to honor the principles.

Consent is the basis everyone names first and the one that fits worst. It has to be freely given, specific, informed and unambiguous, as easy to withdraw as to give, and withdrawal stops the processing. For running a paid service the natural basis is performance of a contract; for invoices and tax records, legal obligation; for fraud prevention, network security and most marketing to existing business contacts, legitimate interests, documented in a balancing assessment you keep.

Accountability in Article 5(2) is what turns the rest into work. Complying is not enough, because you have to show the working, which is why a supervisory authority's first request in an investigation is usually documentation rather than logs.

What GDPR Requires of a US Company

The obligations that follow are specific, and several are lighter for a small company than the summaries suggest.

Read Article 30(5) carefully before relying on it. The exemption falls away if the processing is "not occasional," and a company handling its European customers' data every day is not doing something occasional. Most software companies under 250 people keep the records anyway.

Article 35 requires a data protection impact assessment before processing likely to result in a high risk, and makes one mandatory for systematic and extensive automated evaluation producing legal or similarly significant effects, large scale processing of special category or criminal conviction data, and systematic monitoring of a publicly accessible area on a large scale. Article 37 requires a data protection officer in three situations only: public authorities, core activities requiring regular and systematic monitoring of data subjects on a large scale, and core activities involving large scale processing of special category or criminal data. A US software company with a few thousand European users usually needs neither, and appointing a DPO you do not need brings an obligation to give that person independence you had not planned for.

Articles 13 and 14 govern the privacy notice, which names the controller, the purposes, the lawful basis, the recipients, the retention period, the rights available and any transfers outside the EU. The security work underneath is ordinary: multi-factor authentication on every account that reaches production data, access reviews, patching and logging. Article 32 prescribes no controls, so the program that satisfies a customer's security questionnaire generally satisfies it, provided you can evidence the testing in Article 32(1)(d).

Do You Need an EU Representative Under Article 27?

This is the obligation US companies miss most, largely because the popular explainers leave it out. If Article 3(2) put you in scope, the regulation expects a named point of contact inside the Union.

The three conditions in that exemption are cumulative, so failing any one keeps the obligation, and continuous processing fails the first. A representative is not a data protection officer, and the EDPB treats the two roles as incompatible for one person. It is an address in Europe that regulators and individuals can write to, commonly provided by a law firm or a specialist service, and it moves no liability off your company.

GDPR Breach Notification and the 72 Hour Rule

Article 4(12) defines a personal data breach as a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. That is wider than the American sense of a data breach: ransomware that encrypts data you cannot restore is a breach of availability even if nothing left the building.

Article 33(1) sets the clock. The controller notifies the competent supervisory authority without undue delay and, where feasible, not later than 72 hours after becoming aware of the breach, unless it is unlikely to result in a risk to people's rights and freedoms. A later notification has to carry reasons for the delay. Article 33(3) fixes the contents: the nature of the breach with approximate numbers of data subjects and records, a contact point, the likely consequences, and the measures taken or proposed.

Two details decide whether a US company can meet this. The first is what awareness means. The EDPB's guidelines on personal data breach notification put it at the point the controller has "a reasonable degree of certainty that a security incident has occurred that has led to personal data being compromised," and note the parallel duty to have measures that establish immediately whether a breach has happened. A weekend of quiet triage before anyone declares an incident does not pause the clock.

The second is worse, and almost nobody outside privacy practice knows it. The one-stop-shop mechanism, where a company deals with a single lead supervisory authority, depends on having a main establishment in the Union. Paragraph 73 of those guidelines is explicit that "the mere presence of a representative in a Member State does not trigger the one-stop-shop system" and that "the breach will need to be notified to every supervisory authority for which affected data subjects reside in their Member State," with responsibility resting on the controller. A US company with customers in nine member states can owe nine notifications, in nine portals, inside 72 hours. That is a rehearsal problem rather than a policy problem, and it belongs in the incident response plan.

Article 34(3)(a) is the one genuine relief valve. Communication to individuals is not required where the controller had implemented appropriate protection measures, applied to the affected data, that render it unintelligible to anyone unauthorized, and the article names encryption as the example. Data encrypted at rest with keys the attacker never took can change the outcome of an incident.

What Rights Do GDPR Data Subjects Have?

Chapter III gives individuals rights a US company has to service on a deadline from wherever it operates. Article 15 is access, a copy of the data plus information about its use. Article 16 is rectification. Article 17 is erasure, the right people call being forgotten, which is qualified rather than absolute. Article 18 is restriction. Article 20 is portability, a machine readable copy. Article 21 is objection, unconditional for direct marketing. Article 22 covers decisions based solely on automated processing that produce legal or similarly significant effects.

Article 12(3) sets the deadline: information on the action taken goes to the individual without undue delay and in any event within one month of receipt, extendable by two further months where the request is complex or numerous, provided the controller gives notice of the extension and the reasons inside the original month. A refusal follows the same timetable. The cost is architectural rather than legal, because answering an access request means knowing every system and every processor holding a copy of that person's data, which is the inventory Article 30 already asks for.

How Do EU to US Data Transfers Work Under GDPR?

Chapter V restricts moving personal data out of the EU, and this is where American companies most often buy paperwork they do not need.

Start with whether a transfer is happening at all. The EDPB's guidelines on the interplay between Article 3 and Chapter V set three cumulative criteria: the exporter is subject to the GDPR for that processing, the exporter discloses or makes the data available to another controller or processor, and the importer is in a third country. If any one fails there is no transfer and Chapter V does not apply. The guidelines' own example is a person in Italy booking a room on a New York hotel's website, where the data passes directly from the individual to the controller and no transfer takes place. Direct collection from your European customer is not a Chapter V transfer. Passing that data to a subprocessor is.

Where a transfer does happen, two routes cover almost every case. Article 45 allows transfers to a country the European Commission has found adequate, and on 10 July 2023 the Commission adopted its adequacy decision for the EU-US Data Privacy Framework, under which personal data can flow freely from the EU to US companies that participate. Participation is not automatic. As the FTC's page on the Data Privacy Framework sets out, a company self-certifies to the Department of Commerce that it complies with the framework's principles, and a participant's failure to comply "may violate Section 5 of the FTC Act's prohibition on unfair and deceptive acts." The promise is enforceable in the United States, by an American regulator, against the company that made it. Article 46 covers everyone else, most often through standard contractual clauses adopted by the Commission plus an assessment of the destination country's laws.

What Are the GDPR Fines and Penalties?

The 20 million euro figure everyone quotes is real, and it is the wrong number for most security failures. Article 83 has two tiers, and which applies depends on which article was infringed.

Read the article numbers against the tiers. Security of processing is Article 32 and breach notification is Article 33, both inside the range 25 to 39, so both sit in the lower tier of 10 million euros or 2 percent. The upper tier is for processing without a lawful basis, ignoring people's rights, and unlawful transfers. A company that suffers a breach and handles it properly is exposed under the lower tier; a company that was collecting the data unlawfully is exposed under the higher one, and the breach is what makes the collection visible. Turnover means the whole undertaking's worldwide revenue rather than the subsidiary's, and the percentage applies where it exceeds the fixed sum, so below roughly 500 million euros of revenue the fixed amounts bite first.

What GDPR Does Not Require

The boundary is as useful as the obligations, because a US company that misreads it spends money in the wrong place.

No US regulator enforces GDPR as such. The Federal Trade Commission enforces Data Privacy Framework commitments under Section 5 of the FTC Act, and it enforces companies' own privacy promises, but a European supervisory authority is the body that fines under Article 83. Nor does GDPR displace anything on the US side: state breach notification statutes still apply on their own timetables, the HIPAA Security Rule still binds covered entities and business associates, and PCI DSS is still enforced by contract with the card brands. GDPR is an addition to that stack and simplifies no part of it. It also does not require you to store European data in Europe: residency is a commercial commitment some vendors make, not an obligation any article imposes.