The General Data Protection Regulation has been in force since May 2018, and the volume of incorrect information about what it requires of US companies still vastly exceeds the volume of correct information. Many US SMBs either believe they have no GDPR obligations (some don't, but more do than assume), or they've been sold an over-complicated compliance program that exceeds what their actual risk profile requires. This guide tries to describe what GDPR actually requires of a US-based SMB that has European customers or website visitors, with particular attention to the IT infrastructure and service provider implications.
This is not legal advice. GDPR compliance has legal dimensions that require counsel. But it does provide a practical framework for understanding what's actually required versus what's vendor or consultant upsell.
Does GDPR Apply to Your US Company?
GDPR's territorial scope is broader than many US companies realize. Under Article 3, GDPR applies to organizations established in the EU/EEA, but it also applies to organizations not established in the EU/EEA if they:
- Offer goods or services to individuals in the EU/EEA (regardless of whether payment is required), or
- Monitor the behavior of individuals in the EU/EEA (including website analytics, tracking cookies, profiling)
This means: if your US SaaS product has European users, GDPR applies to you. If you run Google Analytics on your website and European visitors are tracked, you're processing EU personal data and GDPR principles apply to that processing. If you have no European users, customers, employees, or website visitors, GDPR probably doesn't apply — but few US companies can credibly claim that last condition.
The practical question is not "does GDPR technically apply?" but "what level of compliance is proportionate to our exposure?" A US SMB with 5% of customers in the EU has a different risk profile than one where 50% of customers are European enterprises subject to their own GDPR obligations.
What GDPR Actually Requires: The Seven Principles
GDPR is organized around seven data processing principles that apply to all personal data processing:
Lawful basis. Every processing activity needs a lawful basis. For business-to-business processing (your customers using your product), contract performance and legitimate interests are the most commonly applicable bases. For marketing, consent is often required. Document your lawful basis for each type of processing.
Purpose limitation. Collect data for specific, legitimate purposes and don't reuse it for incompatible purposes. Don't collect customer support data and use it to feed advertising analytics without a separate lawful basis.
Data minimization. Collect only what you actually need. This has direct IT infrastructure implications: if you're logging more personal data than you need for operational purposes, that's a GDPR risk surface.
Accuracy. Keep personal data accurate and up to date. Practical implication: you need processes for updating customer records when data changes.
Storage limitation. Don't keep personal data longer than necessary. This requires retention policies — how long do you keep customer data after contract termination? How long do you keep support tickets? Employee records? Retention policies need to be documented and enforced.
Integrity and confidentiality (security). Implement appropriate security measures. This is where GDPR directly intersects with your IT provider relationships — your MSP and all other processors of EU personal data need to implement appropriate technical and organizational security measures.
Accountability. Document your compliance program. GDPR requires that you be able to demonstrate compliance, not just assert it.
Data Processing Agreements: The IT Provider Requirement
Under GDPR Article 28, when you use a third-party service provider who processes EU personal data on your behalf (a "processor"), you must have a Data Processing Agreement (DPA) in place. This is one of the most common practical gaps for US SMBs.
Your IT providers who process EU personal data on your behalf include: your MSP (who accesses systems containing customer data), your cloud infrastructure provider (AWS, Azure, GCP — all provide DPAs as part of their service agreements), your SaaS tools (CRM, marketing automation, help desk software — most major platforms provide DPAs on request or as part of their terms), your email service provider, and your backup provider.
DPAs specify: what data the processor processes, for what purpose, for how long, with what security measures, and what happens at contract termination. AWS, Azure, GCP, Microsoft 365, and most major enterprise SaaS providers have DPAs available — usually in their online terms as a Data Processing Addendum that you can execute online or request. Your MSP, if they process EU personal data, should be willing to execute a DPA.
An MSP that refuses to execute a DPA for GDPR purposes is signaling either unfamiliarity with GDPR (acceptable for very small local MSPs with no EU-facing clients) or unwillingness to accept the accountability that comes with processing EU personal data. For any US company with material EU exposure, this is a meaningful issue in MSP selection.
Data Transfers to the US: The Legal Mechanism Requirement
GDPR Chapter V restricts transfers of EU personal data to countries outside the EU/EEA unless an adequate legal mechanism is in place. The US has historically been considered inadequate for EU data transfers; the current mechanism is the EU-US Data Privacy Framework (DPF), effective July 2023.
If your US company transfers EU personal data to the US (which, practically speaking, includes processing EU customer data on US-based cloud infrastructure), you need a legal transfer mechanism. The most common options for US SMBs:
EU-US Data Privacy Framework (DPF). US organizations that self-certify under the DPF are considered to provide adequate protection for EU personal data. Check whether your major cloud and SaaS providers are DPF-certified (most major US cloud providers are). If you want to rely on DPF yourself, your company can self-certify through the US Department of Commerce.
Standard Contractual Clauses (SCCs). EU-approved contract clauses for data transfers. SCCs are embedded in the DPAs of most major cloud providers. If your vendors' DPAs include SCCs, the transfer mechanism is covered.
Breach Notification Requirements
GDPR requires notification to the relevant supervisory authority within 72 hours of becoming aware of a personal data breach that is likely to result in a risk to the rights and freedoms of individuals. If the breach is likely to result in a high risk, affected individuals must also be notified without undue delay.
The 72-hour clock is aggressive by US standards. It requires that you have incident detection capability (so you actually know when a breach has occurred), a defined escalation process for potential GDPR-notifiable incidents, and a documented decision process for whether a breach meets the notification threshold.
Your MSP or MSSP's incident response process should be evaluated against this requirement. Can they provide timely breach notification support? Do they have experience with GDPR supervisory authority notification? See our incident response guide for the broader framework.
What a Proportionate GDPR Program Looks Like for a US SMB
For a 20–200 person US company with moderate EU exposure (less than 30% of customers in the EU/EEA), a proportionate GDPR compliance program includes:
- A data mapping exercise documenting what personal data you collect, from whom, for what purpose, where it's stored, and who has access
- A privacy policy that accurately describes your processing activities (the cookie banner on your website is part of this)
- DPAs with your major IT vendors and service providers
- A process for handling data subject rights requests (access, deletion, portability)
- A documented retention policy and process for executing it
- An incident response process that includes GDPR breach notification capability
- Appropriate technical security measures (which you should have for security reasons regardless of GDPR)
This is not a $500,000 compliance program. For many SMBs, a focused GDPR readiness engagement with a privacy attorney and a technical consultant runs $15,000–$50,000 for initial implementation, with ongoing maintenance of a few days per year.
Frequently Asked Questions
Do we need a Data Protection Officer (DPO)?
GDPR requires a DPO for: public authorities, organizations that conduct large-scale systematic monitoring of individuals, and organizations that process special categories of data (health data, biometric data, etc.) at large scale. Most US SMBs don't meet these criteria. If you're a small software company with EU customers, you almost certainly don't need a mandatory DPO. You may benefit from appointing a data protection point of contact internally, but that's different from the mandatory DPO role.
Do we need to register with an EU data protection authority?
Non-EU companies subject to GDPR may need to designate an EU representative (under Article 27) — an EU-based entity that can serve as a point of contact for supervisory authorities and data subjects. This applies to organizations that are not established in the EU but are subject to GDPR (the Article 3(2) extraterritorial scope) and are not a public authority. Several services offer EU GDPR representative services.
How does GDPR interact with US state privacy laws?
US state privacy laws (California CPRA, Virginia VCDPA, Texas TDPSA, Colorado CPA, Connecticut CTDPA, and others) have similar principles to GDPR but are not identical. A GDPR-compliant program addresses most US state privacy law requirements, but the specifics differ. The practical approach: design your privacy program around GDPR's stricter requirements, then verify state-specific requirements for the states where your customers are concentrated. See our NY DFS cybersecurity regulation guide for an example of how sector-specific requirements add additional layers beyond general privacy law.
What should I do if a European customer asks for their data to be deleted?
This is a GDPR data subject rights request (specifically, the right to erasure under Article 17). You have one month to respond, with a possible extension of two additional months for complex requests. You must delete the personal data unless you have a legitimate basis to retain it (ongoing contract, legal obligation, etc.). Your IT infrastructure needs to support this — data that is spread across multiple systems (CRM, support ticketing, analytics, backups) needs to be identifiable and removable. This is one of the reasons data mapping (knowing where you store what) is a GDPR prerequisite.
← IT Services RFP Template | Cybersecurity Insurance Costs →