US companies should start by checking where the data subject was located at the moment the personal data was collected. If the individual was in an EU country, GDPR can apply, even if the company is based in the United States. That means organisations need a clear data collection map, documented legal basis, and controls that match the scope of EU privacy obligations.
How GDPR Applies to U.S. Companies Collecting EU Personal Data
For a U.S. company, the key question is not where the business is incorporated, but where the person was located when the personal data was collected. If the data subject was in the EU, GDPR can apply to that collection event. That usually means the company must treat the collection flow as a privacy-regulated process, not just a domestic data capture activity.
That location test matters because GDPR jurisdiction is tied to the circumstances of the data processing, not to the company’s headquarters alone. In practice, organisations need to know which collection channels, forms, apps, and customer journeys can involve people in the EU, because the legal basis, notices, retention, and rights handling may differ once EU personal data is in scope.
U.S. companies should also distinguish between a one-off EU visitor and an intentionally targeted EU market. Where a company actively offers goods or services to people in the EU, or monitors behaviour in the EU, the compliance burden is broader and more durable. A data collection map helps prove whether the company is dealing with incidental collection, repeated EU processing, or a business model that is clearly covered by GDPR.
What Organisations Need to Document Before They Decide
The practical decision should be built from evidence, not assumptions. Start with the collection point, the IP or location signals available at the time, the language and targeting of the service, and the privacy notice shown to the individual. If the organisation cannot tell whether EU residents can reach the collection flow, it cannot reliably decide whether GDPR obligations apply.
Once EU collection is plausible, the organisation should document the legal basis for processing, the categories of personal data collected, and the purpose of collection. That documentation becomes important when the business must justify consent, contract necessity, legitimate interests, or another lawful basis. It also helps determine whether a DPIA, cross-border transfer review, or updated retention rule is needed for the specific data flow.
Good practice is to treat this as a control design issue, not just a legal review. A company that maps identity controls to GDPR and other regulatory requirements is better positioned to keep its collection workflows aligned with the obligations that actually apply. For privacy handling and minimisation decisions, the Identity Data Privacy and Consent Guide is a useful companion for documenting lawful collection and retention limits.
How to Separate Jurisdiction, Data Scope, and Operational Controls
GDPR applicability is only the first decision. After that, the company has to align operational controls with the scope of the data flow. That includes privacy notices, consent or other legal basis records, access controls over collected data, retention limits, and a process for handling data subject requests from EU individuals. If the collection flow is embedded in broader identity or account workflows, the organisation should verify that the privacy controls follow the data, not just the system boundary.
This is also where data governance and security discipline overlap. A company that collects EU personal data through sign-up forms, support portals, or authentication flows needs to know which fields are mandatory, which are optional, and which are unnecessary for the stated purpose. The more the business relies on default collection without purpose scoping, the harder it becomes to defend the collection under GDPR principles such as minimisation and purpose limitation.
For companies that need a regulatory reference point, the EU General Data Protection Regulation (GDPR) remains the primary source for the processing principles, data protection by design, security of processing, and DPIA obligations that matter once EU personal data is in scope. For broader privacy engineering, the NIST Privacy Framework helps translate those obligations into data governance and risk-management practices.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while GDPR and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| GDPR | Art.5 — Principles relating to processing of personal data | Directly governs lawful collection, minimisation, and purpose limitation for EU personal data. |
| Art.25 — Data protection by design and by default | Requires privacy controls to be built into the collection flow from the start. | |
| Art.32 — Security of processing | Applies when EU personal data is collected and must be protected operationally. | |
| Recommendation — Apply Art.5 to document the lawful basis, purpose, and minimisation for EU data collection. Embed privacy controls into collection workflows before deploying EU-facing data capture. Implement appropriate security controls for the collected EU personal data. | ||
| NIST SP 800-53 Rev 5 | IA-8 — Identification and Authentication (Non-Organizational Users) | Relevant when EU customer or external-user collection flows rely on authenticated access. |
| AC-6 — Least Privilege | Supports limiting access to collected personal data to only what is needed. | |
| AU-2 — Event Logging | Supports evidence of collection events, notices, and access activity. | |
| Recommendation — Use IA-8 to secure external-user collection and account-access flows. Apply AC-6 to restrict staff and system access to EU personal data. Log collection and access events so EU data handling can be reviewed and evidenced. | ||
| ISO/IEC 27001:2022 | A.5.34 — Privacy and protection of PII | Directly addresses protection of personal data within an ISMS context. |
| A.5.12 — Classification of information | Helps classify EU personal data so handling controls match sensitivity and use. | |
| Recommendation — Use A.5.34 to align collection, retention, and protection of personal data. Classify EU personal data before defining access, retention, and sharing controls. | ||
Practitioner Guidance
What to verify: Confirm the location of the data subject at the moment of collection, not just the company location or server location. If the collection path can accept EU users, treat it as potentially in scope until the legal basis and notice model are documented.
Decision rule: If the company intentionally serves EU users or can reasonably expect EU collection, build GDPR controls into the flow by default. If EU collection is truly incidental, document the fact pattern and make sure the controls still capture the relevant data, not only the customer segment.
What practitioners underestimate: The hardest part is usually not the legal reading, but the completeness of the collection map. Teams often know where data is stored, yet cannot prove where and under what conditions it was first collected, which is the point that determines the compliance response.
Practitioner takeaway: For U.S. companies, the operational question is whether the collection event can be tied to a person in the EU, because that is what turns a normal intake flow into a GDPR-governed processing activity.
Related resources from NHI Mgmt Group
- How should US companies build a GDPR compliance programme when they collect or monitor EU personal data?
- How should Asia Pacific companies prepare for GDPR when they collect or transfer EU personal data?
- Why does GDPR force companies to change how they collect and use personal data?
- How should Canadian organisations handle GDPR compliance when they collect personal data from EU visitors or customers?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
