Which EU Regulations Apply to Non-EU SaaS Companies?

Who this is relevant to

SaaS, software and platform companies headquartered outside the EU that sell to, or have users in, Europe, including teams that have not yet received a European customer request and want to know which facts to check before one arrives.

• —Founders and legal/security leads scoping EU exposure before a first European deal
• —Teams that have received a security questionnaire, DPA or compliance request from an EU customer
• —Companies deciding whether a dedicated EU compliance review is warranted yet
• —Anyone trying to separate what a specific EU law requires from what a specific customer is asking for

Selling into Europe does not switch on every EU digital regulation at once

Each EU regime now in force for technology companies uses its own trigger, and the triggers are not interchangeable. GDPR asks whether you offer goods or services to people in the EU, or monitor their behaviour there. NIS2 asks about the entity's own sector, size and service category under national implementing law. Some digital-infrastructure categories can be directly covered in their own right. DORA is addressed to EU financial entities, not their suppliers, unless a supplier is formally designated as critical. The AI Act turns on your role: provider, deployer, importer or distributor, and on the system's risk category. The Cyber Resilience Act concerns products with digital elements placed on the EU market, not services generally. A manufacturer-controlled remote component essential to such a product can be part of it. The Data Act concerns connected products and related services, and separately, its Chapter VI switching duties can reach an ordinary cloud or SaaS provider with no connected product at all. The ePrivacy Directive concerns tracking technologies and electronic marketing, and is implemented differently in each Member State.

Because the triggers differ, a fact pattern that puts a company squarely inside one regime can leave it outside another. "We sell SaaS to EU customers" is a starting fact, not a conclusion for any of them.

Direct, customer-driven, possible and guidance

RegRoute classifies every matched requirement into one of four categories. The distinction keeps direct obligations separate from customer-driven requirements, possible findings and guidance.

• —Direct: likely applies directly. The EU instrument places the obligation on your company, whether or not anyone asks about it.
• —Customer-driven: reaches you through your EU customers. A European customer must satisfy its own obligation and passes a requirement down through contract or procurement, even though the EU rule does not name your company.
• —Possible: facts still need confirmation. An open question, not a finding that a requirement applies.
• —Guidance: context worth knowing, with no obligation identified. Useful background that is not itself an obligation.

Why you may receive EU compliance requests even when a law does not directly regulate you

A European customer that is itself regulated, such as a bank, an essential-sector operator or a public authority, usually has to manage risk from its own suppliers. It does that through procurement and contract, not by making its regulator's rules apply to you directly. That is why a request can be commercially real and urgent without being proof of direct legal scope.

The specific request varies by customer and sector. None of the following is universal, and no single EU buyer typically asks for all of it at once.

• —Security questionnaires covering certifications, access control and incident response
• —Contractual security and confidentiality clauses
• —Incident-notification commitments with a stated timeframe
• —Audit rights or access rights over your environment or records
• —A current subprocessor list with change notification
• —Business-continuity and disaster-recovery evidence
• —An exit plan for ending the relationship without service disruption
• —Data-processing terms describing roles, data categories and international transfers

Common misconceptions

“We sell SaaS into the EU, so every EU digital regulation applies to us directly.”

Each regulation has its own trigger. Selling into the EU is relevant background, not a conclusion for GDPR, NIS2, DORA, the AI Act, the CRA, the Data Act or ePrivacy individually.

“Our customer is NIS2-regulated, so our SaaS product is directly subject to NIS2.”

The customer's own NIS2 obligations can create security and supply-chain requirements passed down by contract. Whether the supplier itself is directly within NIS2 scope depends on the supplier's own entity, sector, size and the applicable national implementation. The customer's status alone does not decide it.

“Our customer is an EU bank, so DORA regulates us directly.”

DORA is addressed to EU financial entities. Most technology suppliers meet it through mandatory contract terms the financial entity must put in place, not as directly regulated entities themselves. A narrow exception exists only for providers formally designated as critical ICT third-party providers. That is a formal status, not something inferred from having a bank as a customer.

“We call a third-party AI API, so we are a high-risk AI provider under the AI Act.”

Using AI is a starting fact, not a classification. Role (provider, deployer, importer, distributor, integrator), market activity, EU-use nexus and risk category all need to be established before any conclusion follows, and high-risk status has its own separate conditions.

“We are a SaaS company, so the Cyber Resilience Act covers us like everyone else.”

The CRA concerns products with digital elements placed or made available on the EU market. A standalone software service is not automatically the same thing as a covered product. The product and distribution facts have to be established first.

What facts should I collect?

1. 01Home country and whether you have an EU legal entity, branch or representative
2. 02Company size (employee band)
3. 03What you provide: SaaS, consumer software, professional services, AI-enabled features, hardware, or a product with digital elements
4. 04How you touch Europe: selling to EU businesses, consumers or public-sector bodies; processing EU personal data; offering goods/services to, or monitoring, people in the EU
5. 05Who you sell to: sector (financial services, healthcare, critical infrastructure, digital infrastructure, general enterprise, consumers)
6. 06Your role where AI is involved: provider, deployer, importer, distributor, or integrator of a third-party system
7. 07Whether your product is a connected product or includes digital elements placed on the EU market, and whether any cloud/backend component is manufacturer-controlled and functionally essential to it
8. 08Whether your own service itself falls into a named NIS2 category (cloud, data centre, CDN, managed service/security, DNS, TLD registry) or meets the Data Act's data-processing-service definition (IaaS/PaaS/SaaS), independent of any connected product
9. 09Whether an EU customer has already referenced a specific regulation (NIS2, DORA) in a security or procurement request
10. 10What evidence you already hold: security policy, incident-response plan, DPA template, subprocessor register

What this guide can and cannot tell you

The seven-regime overview separates direct legal-scope questions from customer-driven procurement pressure and points to the facts worth collecting before a European deal reaches its security and legal review stage.

It cannot classify your company. Each regulation's actual scope test depends on facts specific to your product, customers and role, several of the regimes are directives whose national implementation varies by Member State, and none of this is legal advice. The free assessment applies the same deterministic rules to your specific answers and keeps direct, customer-driven, possible and guidance findings separate.

The regulations at a glance

A summary map, not a substitute for checking your own facts. Each row condenses a regime that can turn on many more details than fit in one cell.

GDPR: when it may directly matter, and when it arrives through a customer

GDPR can apply directly when a company offers goods or services to people located in the EU, or monitors their behaviour there. An EU office is not required for either route. A separate route runs through contract: when an EU customer gives the company personal data to process on its behalf, the resulting processor relationship is contractual, but the customer must put prescribed terms and controls in place.

A direct obligation can be pursued by a supervisory authority independently of any one customer relationship. A customer-driven obligation is experienced through the contract and the evidence the customer needs for its own accountability. One company can carry both roles for different data sets at once.

• —Direct: the company determines purposes or targets people in the EU in a relevant way
• —Customer-driven: the company processes data on documented instructions from a European customer

NIS2: a directive, not a single EU-wide test for suppliers

NIS2 can reach a technology company two different ways, and they need to be checked separately. The first is direct: NIS2 Annex I and II name specific entity and service categories, including cloud computing service providers, data centre service providers, content delivery network providers, managed service providers, managed security service providers, DNS service providers and TLD name registries. A company that falls into one of these categories has grounds to check its own direct scope under the applicable Article 2 size thresholds and other conditions in the relevant Member State's implementing law. Falling into a named category is a fact worth checking, not a conclusion: Article 2 also carries category-specific conditions and exceptions, so the category label alone does not settle direct scope, and being, say, a cloud provider does not by itself mean NIS2 applies.

The second route runs through procurement, independent of the first: an EU customer within NIS2 scope may ask suppliers for security governance, incident-handling, continuity or supply-chain evidence because of its own obligations, without that request making the supplier a directly regulated entity. Direct scope is never assumed from a label such as "SaaS vendor" or from a customer's own status.

Keep the two tracks recorded separately: a supplier can need strong evidence for a customer's review even while its own direct NIS2 status remains unresolved or genuinely different from the customer's. A company can also have a direct question of its own alongside that customer-driven pressure.

• —Direct: your own entity/service category (if any) and the applicable Article 2 conditions, including sector, size and any category-specific exception, under the relevant national implementation
• —Customer-driven: an EU customer passes security, incident or supply-chain requirements through the relationship, independent of your own direct status

DORA: addressed to EU financial entities, felt by their suppliers through contract

DORA addresses EU financial entities directly and requires them to manage ICT risk, including risk introduced by suppliers. A SaaS vendor normally encounters that requirement through the contract its EU financial customer must put in place. The customer, not the vendor, remains accountable to its regulator for supplier risk. A narrower route exists for providers formally designated as critical ICT third-party providers by the European Supervisory Authorities. That is a formal status, never something inferred from a customer's size or reputation.

• —Direct: a formally designated critical ICT third-party provider is subject to direct EU oversight
• —Customer-driven: the normal vendor relationship carries mandatory contract clauses and evidence requests

EU AI Act: role and risk category decide the obligations, not AI use alone

The AI Act is a risk-based instrument that does not treat every AI-enabled feature, system, model, provider and deployer the same way. The first questions are factual: what system or model is involved, who develops or supplies it, who deploys or uses it, whether it is placed on the market or put into service, and where the relevant use or output occurs. The Act contains distinct concepts for prohibited practices, high-risk systems, transparency duties and general-purpose AI models. A role or product label alone does not decide which, if any, apply.

• —Direct: depends on the relevant system or model, your role, market activity and EU-use facts
• —Customer-driven: documentation, safeguards and evidence requested by an EU customer because of its own risk controls

Cyber Resilience Act: a product question, not a services-wide rule

The CRA establishes cybersecurity requirements for products with digital elements across their lifecycle. The relevant object is the product and its economic-operator chain. Market placement or making the product available in the EU is a central fact, decided by commercial and distribution facts rather than by the company's headquarters country or a generic EU-customer relationship.

A cloud or remote component can be pulled into that same scope as a "remote data processing solution": the CRA treats data processing at a distance as part of the product where the software is designed and developed by the manufacturer, or under the manufacturer's responsibility, and the product could not perform one of its functions without it. For example, a mobile app may depend on the manufacturer's own backend API to work. This is narrower than "any cloud service connected to a device": a general-purpose or third-party service that is not manufacturer-controlled, or that the product does not actually depend on for one of its functions, is a different question. The product-architecture facts have to settle it, not a label.

Where the CRA applies to a product and role, an EU customer or channel partner may separately ask for security information, vulnerability processes, update commitments or documentation as part of procurement. That is commercially important, but it does not by itself convert every supplier into a direct CRA addressee.

• —Direct: determined from the product, EU-market availability, economic-operator role, and whether any remote-processing component is manufacturer-controlled and functionally essential to the product
• —Customer-driven: security, documentation or update evidence requested in a commercial relationship

Data Act: two separate questions

The Data Act's design obligation (Article 3) and user-access right (Article 4) apply to connected products and related services, turning on whether a company is the manufacturer or related-service provider, or the data holder, for a given product or service offered in the EU. The Regulation applies generally from 12 September 2025, with the Article 3(1) design duty applying to relevant connected products and related services placed on the market from 12 September 2026. A pure software service with no connected-product element is a different question from a data-generating device or an app tightly coupled to one. The product/service boundary and your role are the facts to establish first.

Separately, Chapter VI creates switching, exit and interoperability duties for providers of "data processing services": a technology-neutral definition covering on-demand network access to a shared, scalable and elastic pool of computing resources, which the Regulation itself discusses in terms that include IaaS, PaaS and SaaS delivery models. This route does not depend on having any connected product at all. An ordinary cloud or SaaS offering can qualify in its own right if it meets that definition, so pure SaaS is not irrelevant to the Data Act merely because there is no connected product in the picture.

Neither route applies automatically merely because a company calls its product "SaaS": a connected-product/related-service company still needs the role facts above, and a company providing a cloud or SaaS offering still needs to check that offering against the Regulation's own data-processing-service definition rather than assume every cloud product qualifies for Chapter VI.

• —Direct: your role (manufacturer/related-service provider or data holder) for a connected product or related service; or, separately, providing a data-processing service that meets the Regulation's definition
• —Customer-driven: user or data-holder access requests and related data-sharing terms; customer requests to exercise switching or exit rights

ePrivacy Directive: cookies and marketing, decided at national level

The ePrivacy Directive covers tracking technologies (Article 5(3)) and electronic marketing (Article 13). Because it is a directive, the actual rules come from each Member State's implementing law rather than one EU-wide test. A company using tracking technologies or sending electronic marketing to people in the EU has grounds to screen this against the relevant national law rather than assume a single answer covers every Member State.

This is treated as a screening/guidance matter rather than a directly scored requirement in RegRoute's model, precisely because the applicable rule depends on national implementation.

Official EU sources

Every conclusion on this page traces back to the primary legal text. We link only to official EU sources.

• Regulation (EU) 2016/679 — General Data Protection Regulation · Read on EUR-Lex (CELEX 32016R0679)Verified 2026-08-17

• Regulation (EU) 2022/2554 — Digital Operational Resilience Act · Read on EUR-Lex (CELEX 32022R2554)Verified 2026-08-17

• Directive (EU) 2022/2555 — NIS2 Directive · Read on EUR-Lex (CELEX 32022L2555)Verified 2026-08-17

• Regulation (EU) 2024/1689 — Artificial Intelligence Act · Read on EUR-Lex (CELEX 32024R1689)Verified 2026-08-17

• Regulation (EU) 2024/2847 — Cyber Resilience Act · Read on EUR-Lex (CELEX 32024R2847)Verified 2026-08-17

• Regulation (EU) 2023/2854 — Data Act · Read on EUR-Lex (CELEX 32023R2854)Verified 2026-08-17

• Directive 2002/58/EC — ePrivacy Directive · Read on EUR-Lex (CELEX 32002L0058)Verified 2026-08-17