SaaS compliance: a deep-dive on the main EU regulations

What is a “pure” SaaS product?

SaaS or software as a service refers to software that is run on a central server or cloud and accessed remotely. This model revolutionised the way software was sold. Allowing companies to move from a per-license to recurring revenue sales model. Arguably, this is what sparked the huge tech boom we have seen over the past 15+ years.

However, very few services are “pure” SaaS nowadays. That’s because there has been a push to offload some of the processing load to edge devices and local clients. Often, services that were once pure SaaS now ship with native clients for mobile and desktop devices. These clients may primarily be a frontend for the service, but they are almost de facto moving some of the processing on-device.

So, why does this matter?

Of course, there’s always a philosophical argument to be had, looking at how computing has gone through cycles of centralised and decentralised processing. But in fact there’s a much more real discussion around how this affects your compliance. Especially when it comes to EU regulations.

Cyber Resilience Act (CRA)

The CRA will enter into full force late in 2027. It is an extremely broad act aimed at improving cybersecurity for connected products sold within the EU. It places significant obligations on companies including:

• Secure by default. Any product that can connect to the internet must be secured by default. That means it must be secure without the user needing to configure or change anything.
• Declaration of conformity. Products are obliged to declare they conform with the CRA requirements. Often, this is a self-reported declaration, but some riskier products like any wearable marketed to children will need to be assessed by a notified body.
• Vulnerability tracking. Every vulnerability and suspected or proven cybersecurity incident must be reported on a central ENISA platform.
• Lifecycle security updates. You must issue security patches for the entire lifecycle of the product, which is 5 years by default. You must also clearly state on which date these patches will no longer be provided.

Pure SaaS excluded?

The CRA excludes certain products even if they are “connected”. For instance, it doesn’t apply to products that are already required to be secure by other regulations (e.g. medical devices under MDR). The relevance for this article is that the CRA doesn’t apply to pure SaaS services. But importantly, SaaS services that are supported by a local client or which are connected to any device must comply with the CRA. This may make companies think twice before launching a local client for their service if it doesn’t actually provide any additional benefits to the user.

GDPR

GDPR has strong implications for SaaS products. These include data residency (where the data is stored and processed), data reliability, and data subject rights.

Data residency

Which cloud provider you choose can really matter for GDPR. This is because so many of these cloud providers like Google, AWS or Azure are US-based. At present, this isn’t a problem, but that hasn’t always been true. Roll back a few years and we faced major issues triggered by the Schrems II judgement at the ECJ. One key requirement for GDPR is that data can only be processed within the EU or within a jurisdiction that the EDPB has declared has “equivalent” data protection laws. The Schrems II judgement stated that the US didn’t cross that threshold. Essentially, that made it required companies to put place additional security measures and legal controls in order to use US cloud providers. Currently, there is an EU-US treaty in place that has been shown to give sufficient protections. But periodically, we see new legal cases trying to overturn the status quo.

Some SaaS services also choose to sidestep some of the harder parts of GDPR by keeping all personal data on the local device and only processing anonymous data in the cloud. A good example is Apple’s use of differential privacy to secure their device monitoring logs.

Data reliability

Another issue relates to your obligations to data subjects. One of these is the obligation to protect any personal data you hold and to make it easy for them to access it. That means you need to think about backup, service reliability and disaster recovery. All too often, companies have backups but no plan for how to restore the data if something goes wrong. Or worse, their backups have been poisoned by a slow degradation in the production database that is then replicated within the backups.

Our advice: make sure you do proper disaster planning, and test that you can successfully recover data from your backups. Also, remember to store your periodic backups in a different location from your production cluster.

AI Act

The AI Act has real implications for SaaS firms, especially when it comes to processing training data. Your specific obligations will depend on the risk level of your AI product.

Low and medium-risk AI systems

Any AI system must comply with the AI Act transparency obligations. This means that you must:

• Inform users that they are interacting with an AI system. For instance, your chatbot must tell the user that they are talking to an AI.
• Ensure that your AI behaves ethically. That means it:
  • Doesn’t use any manipulative techniques
  • It doesn’t perform social scoring
  • It mustn’t exploit any vulnerabilities

High-risk AI systems

The AI Act defines high risk systems as those posing significant threats to health, safety, or fundamental rights. That means many AI systems used in healthcare or critical infrastructure are categorised as high risk. These must meet additional stringent requirements.

• Put in place a risk management system that is kept up-to-date throughout the whole product lifecycle
• Ensure good data governance. That means things like using high quality training data, trying to minimise bias in your data, and checking for model drift or data poisoning.
• Maintain complete technical documentation that can be used to prove your compliance.
• Implement audit logging and ensure you have traceability of all model outcomes.
• Meet additional transparency requirements such as explaining to users how the system operates and any limitations.
• Human oversight. Ensure there’s always a human overseeing the system. This can be human-in-the-loop (HITL) or human-on-the-loop (HOTL).
• Ensure the accuracy, security, and robustness of the system.

Local regulations

Last but not least, we see countless local regulations right across the EU that can have a significant impact on SaaS services. There are dozens  of these local regulations that might have an impact on how your design and deliver your SaaS product. Broadly, the 3 main impacts are going to be related to:

• Data residency: For instance, which country is the data allowed to be processed in?
• Data reliability: E.g. are there any rules around where backups have to be stored?
• Cybersecurity: Are there specific certifications or controls you must put in place?

In some cases, these rules only apply to certain sensitive data like health records. But others are much more broad in their scope. Here are 3 examples:

• C5. Germany’s Cloud Computing Compliance Criteria Catalogue was originally intended to define security controls for cloud providers. However, it has increasingly become a de facto requirement for any SaaS used in hospitals or insurance companies.
• HDS. The French Hébergeur de Données de Santé defines strict rules for the processing of health data. It defines strict security controls across 6 areas including physical data centers, cloud infrastructure services, and outsourcing backups. SaaS health products can only run on HDS-certified cloud providers
• ENS. The Spanish Esquema Nacional de Seguridad is a mandatory cybersecurity standard that applies to all digital services in Spain. Products are classified as low, medium or high risk, with different requirements depending on risk.

‍