GDPR Isn't Just a European Law: When a US-Based MSP's Client Actually Falls Under It

Most US-based MSPs treat GDPR as someone else's problem — a European regulation for European companies, irrelevant to a client base clustered in three states and zero EU subsidiaries. That assumption is wrong often enough to be dangerous, and the reason is Article 3(2) of the regulation itself, which extends GDPR's reach based on what a company does, not where it's incorporated.

The two triggers that pull a US client into scope

GDPR applies to any organization processing personal data of people located in the EU when that processing relates to either of two activities: offering goods or services to those individuals, or monitoring their behavior. Neither trigger requires an EU entity, an EU office, or even EU revenue. A US-based e-commerce client that ships to European customers and prices in euros is offering goods to EU data subjects. A US-based SaaS client running analytics or ad-tracking scripts that profile EU visitors' browsing behavior is monitoring EU data subjects — even if the company has never signed a European contract. 'We don't have EU customers' is frequently untrue in ways the client hasn't checked; it's closer to 'we haven't looked at our web analytics logs closely enough to know.'

What actually determines whether a client is in scope

• Does the client's website or app deliberately target EU visitors — localized pricing, EU-specific marketing, language options aimed at EU markets, shipping to EU addresses — as opposed to merely being reachable by anyone with a browser
• Does the client run analytics, advertising pixels, or behavioral tracking that could profile or monitor individuals physically located in the EU, regardless of the client's own location
• Does the client have any EU-based employees, contractors, or job applicants, whose data is being processed by US-based HR or payroll systems

Where the MSP itself sits in this picture

An MSP servicing a GDPR-scoped client isn't off the hook by virtue of being a vendor. If the MSP's tools touch that client's personal data — backup systems that replicate customer databases, RMM agents pulling telemetry that includes user-identifiable data, a helpdesk platform storing EU end-user support tickets — the MSP is very likely a processor under GDPR's definitions, obligated to operate under a data processing agreement, restrict sub-processors, and support the controller's breach notification obligations on the regulation's timeline, not the MSP's own. That 72-hour breach notification clock starts when the controller becomes aware, which means the MSP's own incident detection and reporting speed becomes the controller's compliance risk.

'We don't do business in Europe' and 'no EU resident's data ever touches our systems' are two different claims, and most MSPs have only verified the first one.

This is exactly the kind of determination that shouldn't be made casually, and it isn't one Nexus's tooling makes for a client — whether GDPR actually applies is a legal judgment call that depends on facts about a specific business the platform doesn't have authority to render. What the compliance module's three-state, evidence-attached model is built for is exactly this kind of fragmented, framework-specific posture tracking — it's the same structure used for SOC 2 or FERPA controls today, and extending it to a GDPR-specific control set once a client's actual legal exposure has been determined is a natural fit for that model, not a feature to assume is already configured out of the box. Worth checking directly against the current framework list before assuming coverage, rather than taking it on faith.