EU DIGITAL LAW: What legal obligations will providers of SaaS (Software as a Service) services face in the future?

Cloud-based software solutions ("Software as a Service," SaaS) have become a central component of operational processes and digital business models for many companies. Production and operating data are processed in real time via central platforms, applications are made available across locations, and functions can be scaled flexibly. This development creates efficiency and new value-added opportunities, but at the same time leads to growing dependence on external services, networked systems, and complex data flows. This also brings legal requirements more into focus. Companies are faced with the task of designing their SaaS solutions, both contractually and technically, in such a way that they comply with regulatory requirements while ensuring operational flexibility. In the following, we highlight the relevant legal issues and show how SaaS can be used in a legally compliant and future-proof manner in a corporate context.

I. Overview: SaaS in the context of EU regulation

SaaS services occupy a special position in the European digital legal framework because they are simultaneously infrastructure, data processing environments, and often components of products or business processes. Their classification determines which obligations apply to data access, security, interoperability, or responsibility; the requirements vary considerably depending on the scope of functions. In addition, different regulatory logics overlap: platform regulation, security law, product law, and access rules each pursue their own protective purposes and regularly intersect in SaaS environments. This creates a challenge for companies to consistently align technical, contractual, and organizational decisions with the appropriate regulatory classification.

II. SaaS and the Data Act

With the Data Act coming into force in September 2025 and the Commission's proposals for the Digital Omnibus now available, which clarify key terms and relax or redefine individual obligations (we reported), companies will have a clear but challenging legal framework for dealing with SaaS services.

1. SaaS as a "connected service" (Art. 2 No. 6)

SaaS services become "connected services" when they are functionally linked to a networked product and enable or significantly expand its use in practical operation. This is often the case when machines, vehicles, or devices do not process their operating data locally, but instead make it available, evaluate it, or exchange it with each other via a cloud application. The cloud platform then becomes part of the product ecosystem because without it, users would not be able to access the data generated or use key functions of the product. For the provider, this means that it acts as the data owner within the meaning of the Data Act and must provide users with legally secure access to product and service data ( ). Users are entitled to information and to the transfer of data to third parties of their choice, and the technical design of the service must ensure that this data access is actually feasible. This applies in particular to real-time retrieval, the provision of technical interfaces, and the obligation not to impede data transfer through contractual or technical barriers (we reported).

In practice, this becomes relevant, for example, when the SaaS service analyzes the operating status of machines, enables remote access, or serves as a communication interface between individual products. Such constellations mean that data that was previously held exclusively by the manufacturer is now available to the user and can also be made available to competitors at the user's request. At the same time, the provider must ensure that trade secrets are protected and only disclosed under appropriate confidentiality requirements. The Digital Omnibus draft strengthens these protective mechanisms by explicitly clarifying that data owners may refuse disclosure if there is a high risk that trade or business secrets could be disclosed in third countries with an inadequate level of protection. However, the refusal must be justified and remains limited to narrowly defined exceptional cases.

2. SaaS as a "data processing service" (Art. 2 No. 8)

Beyond specific product integration, many SaaS offerings fall under the regime for data processing services. This chapter of the Data Act applies to all cloud services that store, process, or provide data in a platform environment. The central objective is to remove barriers to switching and promote interoperability between services. This creates an obligation for SaaS providers to design their systems in such a way that customers can export data in a practical form and transfer it to another service. Contracts must contain clear information about the scope of services, technical dependencies, and the conditions for changing providers; in particular, switching or data exports must not be hindered by excessive fees or proprietary formats.

The Digital Omnibus addresses several practical problems in this regard. For SaaS services that are not "off the shelf" but have been highly customized to meet the individual requirements of a customer, the switching obligations are mitigated. Since such services are often not functional without extensive preconfiguration, their complete migration should not be enforced. The draft also provides relief for smaller providers: They are granted longer transition periods, are allowed to continue certain contract models, and can make exit procedures more pragmatic without jeopardizing the goal of the Data Act—the gradual elimination of lock-in effects. At the same time, key principles remain in place, such as the foreseeable ban on egress fees, which is considered essential for an open cloud market.

III. SaaS and the Digital Services Act

For many SaaS offerings, in addition to the Data Act, the question arises as to their classification as a hosting service within the meaning of the Digital Services Act. The decisive factor here is not so much whether a service is publicly accessible or restricted to a specific group of users, but rather whether users – be they companies, employees, or external partners – upload content, data, or other information to the system "on their own initiative." This requirement is regularly met by modern SaaS applications, as they typically provide functions for uploading, exchanging, or storing data. This means that they are subject to the general obligations for hosting services and must have procedures in place that enable the responsible handling of reported illegal content.

The DSA does not differentiate between B2C and B2B contexts; the only decisive factor is the provider's role as an intermediary for third-party content. As a result, SaaS providers must establish clear processes for reporting illegal content, make transparent decisions about its removal, and inform affected users. In addition, providers are expected to actively protect the integrity of their service and, in the event of serious criminal offenses, enable appropriate reports to be made to the authorities.

These requirements apply regardless of the size of the provider or the scope of the service. Unlike the additional obligations for very large online platforms, the basic obligations apply to all hosting providers and thus to almost all SaaS constellations. Companies that provide or use SaaS solutions should therefore ensure that their platforms have transparent reporting channels, structured review processes, and traceable documentation of decisions. This is particularly important when platforms are used as part of larger ecosystems, for example, to store technical documentation, communicate with customers, or manage machine-generated data.

IV. SaaS and AI Regulation

In the case of SaaS solutions that provide AI functionalities, the first question that arises is who is to be classified as the provider and who as the operator of the system within the meaning of the AI Regulation. These roles are not mutually exclusive, but may coincide or be distributed among several actors, depending on the organizational model. The decisive factor is the actual control over the system and the responsibility for how it is used. A company that develops an AI system itself or has it created for its own purposes is regularly both the provider and the operator because it controls both the technical design and the practical use. If, on the other hand, only the outputs of an AI system are used without controlling the technical processes or the operating environment, the company is merely a user of outputs, not an operator. The distinction is important because providers and operators are subject to different obligations under the AI Regulation.

For SaaS models, the constellation in which a provider makes the AI system available via a cloud-based platform and retains complete technical control over the system – i.e., the infrastructure, the model, and the background processes – is particularly relevant. In such cases, the customer decides when and for what purpose the AI system is used, while the provider ensures functionality, updates, monitoring mechanisms, and technical supervision. From the perspective of the AI Regulation, this suggests that the customer is the operator because they define the purposes of use, determine the input data, and evaluate the output, while the SaaS provider is to be classified as an additional provider if they market or make the AI system available for use under their own brand. The fact that the computing processes take place on the SaaS provider's servers does not change the customer's role as operator; in this respect, the provider acts within the customer's sphere of control and merely provides the necessary technical components.

The distinction between roles becomes particularly relevant in areas where SaaS-based AI systems are used in highly regulated fields of application, such as the processing of HR data or in imaging procedures. The AI Regulation classifies systems that make decisions about access to employment, personnel development, or performance evaluation, as well as systems that evaluate learning progress, exam performance, or study ability, as high-risk AI. This means that SaaS providers and operators are subject to far-reaching requirements in terms of data quality, documentation, human oversight, and risk management. For SaaS providers, this means that as soon as their system is used for such purposes, they must not only meet technical requirements, but also clarify whether they themselves are to be classified as providers, downstream providers, or operators. For customers, on the other hand, this means that when using an AI SaaS service for HR or educational purposes – such as automated application analysis, skills assessment, or adaptive learning systems – they are regularly considered operators and are therefore subject to the full high-risk regime themselves.

V. SaaS and other EU regulations

Beyond the Data Act, the DSA, and the AI Regulation, SaaS services are affected by other European regulations, although their scope of application varies depending on the nature of cloud-based services. This is particularly evident in the Cyber Resilience Act, which primarily targets "products with digital elements" and thus primarily covers hardware or locally installed software. Purely cloud-based SaaS services that are provided entirely via the provider's servers and do not require local components are expressly excluded from the scope of the CRA, according to Recital 12. Instead, depending on their design, they are subject to the requirements of NIS2, in particular if the SaaS service is classified as an essential or important service with relevance for corporate or sector security.

Another factor is the Accessibility Enhancement Act, which requires digital services to be designed to be accessible if they provide consumer-oriented functions. For SaaS providers, this becomes relevant, for example, if booking, service, or interaction processes that directly affect end users are handled via the application . An online booking function within a SaaS platform may therefore be sufficient to trigger the requirements for accessibility, perceptibility, and operability. This can also become important in the B2B environment as soon as a service is used not only internally but also as a customer interface.

Finally, the E-Evidence Regulation creates a binding procedure for the cross-border request of electronic evidence by law enforcement authorities. SaaS providers are thus obliged to respond to orders within very short deadlines – usually ten days, or eight hours in emergencies – and to provide stored communication or usage data. Since the regulation is aimed directly at digital service providers, SaaS providers must implement procedures to identify, review, and respond to requests in a timely manner. For companies that use SaaS services, this creates an additional layer of compliance because data processed or transmitted as part of the service may potentially be subject to such orders.

VI. Recommendations

For companies that offer or use SaaS services, it is becoming increasingly important to align technical and contractual structures with the new regulatory requirements at an early stage. The starting point should be a clear classification of the respective service, as the roles of connected service, data processing service, hosting provider, or AI operator trigger different obligations. In the area of connected products, it is advisable to design your own architecture in such a way that data access, transfer options, and protective measures for trade secrets are taken into account from the outset. Even SaaS providers without a product reference should check the extent to which change processes and data exports are technically feasible and what adjustments are necessary in the drafting of contracts.

When dealing with AI functionalities, careful role and risk classification is essential. Companies should document whether they are providers, operators, or users of an AI system and which processes need to be implemented for quality assurance, human oversight, and model management. Finally, it is advisable to create internal compliance structures that also take into account the requirements of the DSA, the E-Evidence Regulation, or the BFSG. These include documented reporting channels, transparent decision-making processes, security concepts in accordance with NIS2, and reliable procedures for responding to regulatory inquiries. Early coordination between legal, IT, product development, and purchasing makes it easier to effectively fulfill these obligations while maintaining operational flexibility.

VII. Conclusion

In the future, SaaS services will be operated in almost all areas of business under a significantly tighter European legal framework. With the Data Act, the DSA , and the AI Regulation, regulations are in place that fundamentally influence the operation, data architecture, and provider relationships of SaaS. The current draft of the Digital Omnibus provides additional clarity by redefining key terms and at the same time providing for transition periods and exemptions. 

This article was created in collaboration with our student employee Emily Bernklau.