GDPR compliance for US companies: A step-by-step guide

Due to growing awareness of data privacy risks, organizations face mounting pressure from regulators to safeguard sensitive personal information. For many US companies, that pressure shows up from multiple directions—state privacy laws (like California’s), sector rules (like HIPAA in healthcare), and international requirements when you sell into global markets.

One key regulation to understand is the General Data Protection Regulation (GDPR), the EU’s data protection law that can apply to organizations outside the EU when they process EU personal data.

This guide covers:

What the GDPR is (and why it matters for US teams)
When GDPR applies to US companies (even without an EU office)
How GDPR compares to common US privacy requirements
A step-by-step GDPR compliance checklist you can operationalize

When you realize “we have EU users” changes everything

GIF via GIPHY

Related guides:

Key takeaways

GDPR can apply to US companies without a European office. If you offer goods/services to people in the EU or monitor their behavior, you may be in scope.
You’ll need a defensible “why” for every processing purpose. GDPR’s lawful basis requirement is more explicit than what most US teams are used to.
Data subject rights are operational work. You need real workflows (intake, identity verification, fulfillment, audit trail)—not just policy language.
Cross-border transfers are a recurring risk area. Transfer mechanisms and “adequacy” decisions (like the EU–US Data Privacy Framework) can change over time.
Treat GDPR as a living program. The fastest route is clear scoping, vendor contracts, documented decisions, and evidence you can reuse during audits and customer reviews.

The GDPR is a comprehensive EU regulation designed to protect the personal data rights and freedoms of people in the EU/EEA. It sets standards for how organizations collect, use, store, and share personal information—and it gives individuals meaningful control over how their data is used.

Compliance is mandatory for in-scope organizations, and violations can lead to corrective actions and significant financial penalties. In practice, GDPR enforcement risk depends on your facts (scope, data types, controls, and incident handling), but the baseline expectation is the same: you should be able to justify and prove what you do with personal data.

Yes—often. The GDPR is commonly described as “location-agnostic” because it can apply to organizations that process EU personal data regardless of where the organization is based.

Two common applicability triggers are:

Establishment: If your organization has an office, branch, or subsidiary in the EU, processing “in the context of” that establishment may fall under GDPR (even if the processing happens elsewhere).
Targeting: If you don’t have an EU presence, GDPR may still apply if you offer goods/services to EU residents (even if no payment is required) or monitor their behavior (for example, certain tracking and profiling activities).

If you’re unsure, a practical first step is to answer two scoping questions:

Do we have EU customers, users, leads, or employees?
Do we collect identifiers, telemetry, or behavioral data from people in the EU?

Unlike the EU’s unified GDPR model, the US privacy landscape is a patchwork of state and sector rules. Many US teams assume that meeting one state law requirement is “close enough” for GDPR. In practice, GDPR tends to be more demanding in areas like lawful processing, cross-border transfers, and individual rights workflows.

Here’s a simplified comparison to help you spot common gaps:

Topic	GDPR (EU)	US privacy landscape (simplified)	What US teams typically need to add for GDPR
Scope	Broad, covers most personal data processing	Varies by state/sector; definitions and thresholds differ	A unified inventory of processing + consistent governance
Legal basis	Required (six lawful bases)	Often notice/choice oriented; varies	Documented legal basis per processing purpose
Data subject rights	Explicit set of rights with expectations for fulfillment	Rights vary by state and context	Intake + identity verification + fulfillment workflows + logs
Cross-border transfers	Structured rules and safeguards for transfers outside the EU	No EU-style transfer regime domestically	A transfer strategy + vendor contracts + ongoing monitoring
Accountability	Strong emphasis on demonstrable compliance	Increasing, but uneven	RoPA, DPIAs where needed, training, and evidence hygiene

One extra watch-item for US companies is cross-border transfer posture. The EU’s adequacy determinations (including the EU–US Data Privacy Framework) can change, and those changes can affect how you structure transfers and vendor relationships.

An 8-step GDPR compliance checklist for US companies

If GDPR is new to your team, focus on turning requirements into repeatable operations. These eight steps are a practical starting point.

Step 1: Identify EU personal data you process

Start by identifying how you collect, use, and store personal data of individuals in the EU. Build (or update) a data map that includes:

Data categories (identifiers, contact info, device IDs, billing data, support data, HR data)
Sources (product, marketing site, analytics, support tooling, recruiting)
Systems of record and storage locations
Vendors/subprocessors that receive or can access data
Retention and deletion rules

Flag special category data (GDPR Article 9) early, because it typically requires a higher bar and additional safeguards. This can include information about health, biometrics, religious beliefs, sexual orientation, and more.

Also document cross-border data flows between EU and US systems. Teams often rely heavily on a single transfer posture and don’t revisit it as vendors, regulators, or legal interpretations change.

Step 2: Establish a lawful basis

Before processing personal data under GDPR, you need a lawful basis for each processing purpose. GDPR recognizes six common lawful bases:

Consent: freely given, specific, informed, unambiguous
Contract: necessary to fulfill a contract with the individual
Legal obligation: required to comply with EU or Member State law
Vital interests: necessary to protect someone’s life
Public task: required for public interest/official authority
Legitimate interests: necessary for a legitimate purpose that doesn’t override individual rights

Consent is important, but it’s not required for every purpose. What matters operationally is that you:

Assign a lawful basis per processing purpose
Keep your rationale in a place you can audit later
Align your product UX (notices, toggles, cookie choices) with that basis

Step 3: Appoint a DPO and EU representative (if required)

A Data Protection Officer (DPO) is responsible for monitoring GDPR compliance and advising the organization. Not every company needs a DPO, but you may if your core activities involve large-scale processing or processing that creates high risk to individuals’ rights.

If your organization has no EU establishment, you may need to appoint an EU representative to act as a point of contact with regulators and data subjects (with some exceptions).

Even when not strictly required, assigning clear ownership helps avoid a common failure mode: “privacy is everyone’s job,” which usually becomes “privacy is no one’s job.”

Step 4: Run a DPIA when processing is high risk

A Data Protection Impact Assessment (DPIA) is typically required when a processing activity is likely to result in high risk to individuals’ rights and freedoms.

Activities that commonly trigger DPIAs include:

Large-scale processing of sensitive/special category data
Systematic monitoring of publicly accessible areas
Intensive profiling or automated decision-making
Using new technologies in ways that materially impact individual rights

A practical DPIA workflow usually includes:

Describe the processing and purpose
Assess necessity and proportionality
Identify risks to individuals
Define measures to mitigate risks (technical + organizational)

If you have a DPO, involve them or keep them informed throughout the DPIA.

Step 5: Put data processing agreements in place

If you’re a controller, you’re responsible for ensuring your processors meet GDPR requirements. If you’re a processor, your subprocessors must meet similar expectations.

That typically means putting a GDPR-aligned Data Processing Agreement (DPA) in place that clarifies:

Processing purpose and instructions
Security and organizational measures
Subprocessor rules and approvals
Breach reporting and response obligations
Data subject request cooperation
Data return/deletion at termination

From an operations perspective, the goal is simple: when a vendor changes, you shouldn’t be scrambling to re-figure out whether you can legally and safely use them.

Step 6: Build an incident response plan for the 72-hour window

GDPR includes strict breach notification expectations. Once a breach is detected, organizations commonly have 72 hours to notify the relevant supervisory authority (depending on the facts and risk). Processors must notify controllers without undue delay.

Your incident workflow should define:

How you detect, triage, and classify incidents
Who makes the “notification required?” decision (and how it’s documented)
Templates and checklists for regulator and data subject communications
How you coordinate with vendors and subprocessors

US companies should also align this workflow with other obligations (for example, HIPAA breach response, if relevant) to avoid conflicting timelines and duplicated work.

Step 7: Implement data subject rights workflows

GDPR data subject rights are where many programs become real. Commonly referenced rights include:

Right to be informed
Right of access
Right to rectification
Right to erasure (“right to be forgotten”)
Right to restrict processing
Right to data portability
Right to object
Rights related to automated decision-making and profiling

To operationalize this, you typically need:

A request intake channel (web form + email)
Identity verification steps (proportionate to risk)
A fulfillment workflow per right (with owners and SLAs)
A log of requests, actions taken, and outcomes (for accountability)

Step 8: Update your privacy notices and cookie disclosures

GDPR expects clear, accessible notices that explain what you collect and why. Your privacy notice typically needs to cover:

What data you collect and the purposes (and lawful bases)
Who you share data with (including categories of processors/subprocessors)
Whether data is transferred outside the EU (and safeguards used)
Individual rights and how to exercise them
Retention and deletion practices

For many US teams, this also means tightening cookie and tracking disclosures and ensuring your consent mechanisms match your tracking behavior—not just your policy text.

GDPR data audit requirements for US-based organizations

GDPR doesn’t universally mandate internal or external audits, but audits are widely considered a best practice to verify that your controls remain effective as systems and vendors change.

A practical GDPR audit often includes:

Mapping data flows and processing activities
Reviewing lawful bases and notices for alignment
Testing data subject request workflows end-to-end
Verifying third-party risk management and vendor DPAs
Evaluating technical safeguards (access control, logging, encryption, backups)
Documenting gaps, remediation, and evidence

One high-leverage artifact is your Record of Processing Activities (RoPA). Keeping it current supports GDPR’s accountability principle and makes customer due diligence and regulatory questions much easier to handle.

Common challenges for US teams pursuing GDPR compliance

Even teams familiar with US privacy requirements can run into GDPR-specific friction:

Complexity across multiple regimes: GDPR plus state privacy laws can create inconsistent rights and notice requirements.
Data mapping at scale: cross-border data flows and vendor sprawl make “where data lives” surprisingly hard to answer.
Ongoing monitoring: changes in tracking, new vendors, and product launches can quietly break compliance assumptions.
Documentation drift: policies, RoPA, and DPIAs fall out of date when ownership is unclear.
Regulatory updates: interpretations and transfer mechanisms can evolve, impacting cross-border processing decisions.

The common theme is operational: manual, scattered workflows don’t scale.

Streamline GDPR compliance with SecureSlate

GDPR compliance is easier when it runs like a system: clear scope, assigned owners, repeatable workflows, and audit-ready evidence that stays current as your tools and vendors change.

SecureSlate helps teams:

Centralize GDPR documentation (RoPA inputs, policies, DPIAs, vendor artifacts) in one place
Assign owners and deadlines for remediation and recurring reviews
Track vendor risk and DPA status without spreadsheet churn
Maintain a clean evidence trail for customer reviews and audits

Get started for free to turn GDPR requirements into clear, trackable execution.

FAQ

It can. If you offer goods/services to people in the EU or monitor their behavior, you may be in scope even without an EU establishment.

Start with scoping and data mapping: identify EU personal data you process, where it lives, which vendors touch it, and what purposes/lawful bases apply.

Do we need a Data Protection Officer (DPO)?

Not always. Some organizations must appoint a DPO based on the nature and scale of processing. Many teams still assign an internal privacy owner even when a formal DPO isn’t required.

Not universally, but periodic audits are a best practice to verify controls, policies, and workflows remain effective as systems and vendors change.

Disclaimer (legal note)

SecureSlate is not a law firm, and this article does not constitute or contain legal advice or create an attorney-client relationship. When determining your obligations and compliance with respect to GDPR and related regulations, you should consult a licensed attorney.

GDPR compliance for US companies: A step-by-step guide

Key takeaways

What is the GDPR?

Does the GDPR apply to US companies?

How does GDPR compare to major US privacy laws?